Amazon SCS-C02: Edge en Applicatiebeveiliging — Studiegids
Onderdeel van de AWS Security Specialty SCS-C02 — Studiegids. Oefen met geverifieerde antwoorden in het Amazon-examencentrum, of doe getimede oefentests op ExamRoll.io.
CloudFront Geo Restriction en blokkering op landniveau
CloudFront biedt twee mechanismen om verkeer per land te blokkeren, en de keuze hiertussen is belangrijk voor de kosten en functionaliteit. De ingebouwde geo restriction-functie (ook wel geoblocking genoemd) wordt direct op de distributie geconfigureerd en evalueert verzoeken aan de edge op basis van een allowlist of blocklist van landen, afgeleid van het IP-adres van de bezoeker. Het is gratis, vereist geen regelevaluatie en retourneert een HTTP 403 voordat er een origin fetch plaatsvindt. Voor eenvoudige compliancescenario’s — “blokkeer bezoekers uit land X” — is dit de goedkoopste en eenvoudigste optie.
Het alternatief is een WAF geo match statement, wat flexibeler is: je kunt landmatches combineren met URI-paden, headers, rate limits, of ze negeren (“sta land A alleen toe voor /admin”). WAF is vereist wanneer de logica conditioneel is; geo restriction alleen kan “blokkeer land X alleen voor een specifiek pad” niet uitdrukken. Kies voor de native geo restriction wanneer de eis een platte landenblokkade is en je de kosten per verzoek van WAF wilt vermijden.
Signed URL’s versus Signed Cookies voor private content
CloudFront ondersteunt twee manieren om geautoriseerde private content te serveren terwijl de origin (S3-bucket, ALB of Media origin) verborgen blijft achter een origin access control of een custom header:
Signed URL’s: elke URL bevat een handtekening en een policy. Ideaal voor een download van een enkel bestand of wanneer je per bestand toegangscontrole nodig hebt (bijv. een eenmalige link voor een software-installer).
Signed cookies: de client ontvangt eenmalig een set cookies (
CloudFront-Policy,CloudFront-SignatureenCloudFront-Key-Pair-Id) van je authenticatiedienst. Alle volgende verzoeken naar overeenkomende padpatronen worden automatisch geautoriseerd zonder dat de URL’s herschreven hoeven te worden.
Voor HLS-videostreaming, waarbij een enkele afspeelsessie duizenden .ts-segmenten ophaalt waarnaar in een manifest wordt verwezen, zijn signed cookies aanzienlijk eenvoudiger. Het herschrijven van elke segment-URL in het manifest met een unieke signed URL is mogelijk, maar voegt latency en complexiteit toe. Stel de cookie in nadat de abonnee zich authenticeert bij je interne user store, met een scope die beperkt is tot het padpatroon van de stream.
Een canonieke policy voor een wildcard signed cookie ziet er als volgt uit:
{
"Statement": [{
"Resource": "https://d123.cloudfront.net/videos/*",
"Condition": {
"DateLessThan": {"AWS:EpochTime": 1735689600},
"IpAddress": {"AWS:SourceIp": "203.0.113.0/24"}
}
}]
}
Combineer dit met een origin access control (OAC) of een geheime custom header die door WAF bij de origin wordt gevalideerd, zodat gebruikers CloudFront niet kunnen omzeilen en de origin rechtstreeks kunnen benaderen.
AWS WAF: Managed Rules, ATP en Rate-Based Rules
Koppel de Web ACL aan de CloudFront-distributie in plaats van aan een regionale ALB wanneer de workload zich achter CloudFront bevindt. Koppeling aan de edge beëindigt kwaadaardige verzoeken bij een van de honderden POP’s — dichter bij de aanvaller — wat de belasting op de origin tijdens een DDoS-aanval vermindert en de egress vanaf de origin verlaagt, omdat geblokkeerd verkeer nooit je VPC doorkruist. Als WAF alleen aan de ALB wordt gekoppeld, bereikt de volumetrische aanval nog steeds de regionale load balancer en verbruikt het LCU’s, en worden cross-regionale aanvallen afgehandeld door één enkele regio in plaats van door het wereldwijde edge-netwerk.
Belangrijke regelgroepen om te combineren:
AWS managed rule sets:
AWSManagedRulesCommonRuleSet(in de stijl van OWASP top 10),AWSManagedRulesKnownBadInputsRuleSetenAWSManagedRulesAmazonIpReputationListbieden een brede dekking met vrijwel geen afstemming.Account Takeover Prevention (ATP):
AWSManagedRulesATPRuleSetinspecteert het door jou opgegeven login-eindpunt, volgt patronen van credential stuffing, controleert ingediende inloggegevens aan de hand van een database met gecompromitteerde credentials en blokkeert bots die gelekte wachtwoorden hergebruiken. Configureer het met het exacte login-pad en de JSON-body veldnamen voor de gebruikersnaam en het wachtwoord.Rate-based rules: beperken het aantal verzoeken van een enkel IP-adres binnen een venster van 5 minuten (bijvoorbeeld 2.000 verzoeken). Beperk hun scope op basis van URI of methode, zodat het scrapen van
/searchhet anonieme browsen van/niet beïnvloedt. Rate rules beperken volumetrische Layer 7-aanvallen en brute-force enumeratie.
Een ingekort WAF-regelblok:
Rules:
- Name: RateLimitLogin
Priority: 1
Action: { Block: {} }
Statement:
RateBasedStatement:
Limit: 500
AggregateKeyType: IP
ScopeDownStatement:
ByteMatchStatement:
SearchString: /api/login
FieldToMatch: { UriPath: {} }
PositionalConstraint: STARTS_WITH
TextTransformations: [{ Priority: 0, Type: LOWERCASE }]
ACM-certificaten, DNS-validatie en CloudFront
Voor CloudFront moet het certificaat worden aangemaakt in ACM in us-east-1 (N. Virginia), ongeacht waar je origin zich bevindt. Dit is een harde vereiste omdat CloudFront een wereldwijde service is die certificaten uit die regio leest. Regionale services zoals ALB lezen certificaten uit de regio van de ALB zelf.
Gebruik altijd DNS-validatie met een CNAME-record in Route 53 voor elk publiek certificaat dat je automatisch wilt laten vernieuwen. ACM vernieuwt DNS-gevalideerde certificaten automatisch zolang de validatie-CNAME gepubliceerd blijft; Route 53 maakt dit triviaal (de console biedt tijdens de aanvraag de optie “Create records in Route 53”). E-mailvalidatie daarentegen stuurt een bevestiging naar vijf adressen op het domein (admin@, administrator@, hostmaster@, postmaster@, webmaster@) plus het WHOIS-contact. Deze mailboxen bestaan vaak niet of worden door bedrijfsmailfilters in quarantaine geplaatst, waardoor vernieuwingen 60 dagen voor de vervaldatum mislukken en vermijdbare storingen veroorzaken. Er is geen manier om de klikken voor e-mailvalidatie te automatiseren.
Het correcte vernieuwingspatroon voor multi-regionale ALB’s is: vraag per regio een DNS-gevalideerd ACM-certificaat aan, publiceer de validatie-CNAME eenmalig in Route 53, koppel het certificaat aan de ALB-listener en laat ACM de vernieuwing en herimplementatie afhandelen. Menselijke tussenkomst eindigt na de uitgifte.
DNSSEC en Route 53
Activeer DNSSEC signing op de Route 53 hosted zone om DNS-spoofing en cache poisoning tegen je domein te voorkomen. Route 53 beheert de KSK in KMS (een asymmetrische ECC-sleutel in us-east-1); je moet het DS-record publiceren bij de registrar. Let op: DNSSEC signing beschermt de resolutie van je zone — het versleutelt geen DNS-verkeer (dat is DoH/DoT) en heeft geen invloed op de TLS van CloudFront.
Responseheaders: Beleidsregels versus Lambda@Edge
CloudFront injecteert niet automatisch beveiligingsheaders zoals Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options of Content-Security-Policy. Als uw origin niet kan worden aangepast (een verouderde S3-site, een origin van een derde partij), heeft u twee opties:
Responseheadersbeleid: een native, declaratieve CloudFront-functie. Koppel een beheerd of aangepast beleid aan een cache behavior om HSTS-, CORS-, beveiligings- en aangepaste headers toe te voegen. Dit zou de standaardkeuze moeten zijn — geen code, geen cold starts, geen kosten per aanroep.
Lambda@Edge (viewer response of origin response): gebruik dit wanneer u dynamische logica nodig heeft, zoals het variëren van CSP nonces per request of het herschrijven van headers op basis van request-attributen. Ruilt eenvoud in voor flexibiliteit en voegt kosten per request toe.
Het beheerde responseheadersbeleid SecurityHeadersPolicy dekt de gebruikelijke basisvereisten in één koppeling.
Veelvoorkomende Valkuilen Uitgelegd
Het aanvragen van publieke ACM-certificaten met e-mailvalidatie is kwetsbaar, juist omdat de verlenging afhangt van mensen die e-mails lezen die naar generieke adressen worden gestuurd, welke de meeste organisaties niet monitoren of naar spam routeren. DNS-validatie met Route 53 elimineert de menselijke tussenkomst volledig.
Het koppelen van WAF alleen aan de ALB lijkt op papier gelijkwaardig, maar dwingt aanvalsverkeer uw Regio binnen en verbruikt ALB-capaciteit. Een aan de edge gekoppelde WAF op CloudFront blokkeert verkeer bij honderden POP’s, waardoor een gedistribueerde aanval wereldwijd wordt geabsorbeerd en de origin-egress laag blijft — cruciaal tijdens een DDoS.
Ervan uitgaan dat CloudFront automatisch beveiligingsheaders toevoegt, leidt tot mislukte penetratietesten. De distributie fungeert als proxy voor de headers die de origin verstuurt; u moet expliciet een responseheadersbeleid of een Lambda@Edge-functie koppelen om X-Frame-Options: DENY, HSTS en CSP te injecteren.
Praktijkprobleem: Gebruikersscenario
Scenario: Meridian Financial beheert een wereldwijd gedistribueerd klantenportaal en een intern rapportenportaal op AWS. Publiek verkeer wordt via Amazon CloudFront gerouteerd naar Application Load Balancers voor dynamische API’s en naar S3-origins voor privé-rapporten; DNS staat in Route 53 en TLS-certificaten worden uitgegeven door AWS Certificate Manager (ACM).
Uitdaging: Aanvallers zijn bezig met het ‘scrapen’ en ‘credential stuffen’ van accounts vanuit verschillende landen, waarbij ze CloudFront omzeilen door rechtstreeks de origin-endpoints aan te vallen om privé-rapporten te downloaden, wat leidt tot overbelasting van de origin en blootstelling van data.
Aanbevolen Aanpak:
- Configureer CloudFront als het enige publieke toegangspunt en pas CloudFront Geo Restriction toe om de aanvallende landen te blokkeren; schakel Origin Access Control (OAC) in en vergrendel de S3/ALB origin-policies zodat alleen CloudFront de origin-content kan ophalen.
- Dien per-gebruiker privé-rapporten op met CloudFront signed URLs (korte TTL) in plaats van signed cookies, zodat elke download individueel geautoriseerd en auditeerbaar is.
- Koppel AWS WAF aan de CloudFront-distributie met behulp van AWS Managed Rules, schakel AWS WAF Bot Control (geavanceerde dreigingsbescherming) in en maak rate-based rules plus CAPTCHA-uitdagingen om scraping en credential stuffing tegen te gaan.
- Provisioneer TLS-certificaten in ACM (us-east-1 voor CloudFront-distributies) met DNS-validatie via Route 53, en publiceer Route 53 Alias-records naar de CloudFront-distributie.
- Schakel DNSSEC in op de Route 53 hosted zone, activeer CloudFront- en WAF-toegangslogboeken naar S3, en maak CloudWatch-alarmen en optioneel AWS Shield Advanced voor DDoS-zichtbaarheid en alarmering.
Redenering: Door al het verkeer via CloudFront met OAC en WAF te forceren, wordt ’least-privilege’ toegang tot de origin afgedwongen. Geo Restriction en rate-based/WAF-beschermingen stoppen misbruikend verkeer, signed URLs bieden autorisatie per object, en ACM+DNS-validatie met DNSSEC zorgt voor betrouwbare TLS- en DNS-integriteit volgens de best practices van AWS.
AWS WAF Rules en Integratie met ALB en CloudFront
AWS WAF is een Layer 7-firewall die HTTP(S)-requests evalueert aan de hand van een Web ACL die is samengesteld uit geordende regels. Elke regel inspecteert request-attributen (URI, headers, body, query string, bron-IP) en retourneert een beëindigende actie (Allow, Block, Challenge, CAPTCHA) of een niet-beëindigende actie (Count). Web ACL’s worden gekoppeld aan CloudFront-distributies, Application Load Balancers, API Gateway, AppSync, Cognito user pools en App Runner-services. Wanneer gekoppeld aan CloudFront, draait de ACL aan de edge en moet deze worden aangemaakt in de us-east-1 (Global) scope; voor een ALB moet deze zich in dezelfde Regio bevinden als de load balancer.
Rate-based rules houden het aantal requests bij dat afkomstig is van één IP-adres (of een forwarded-IP header, of een geaggregeerde sleutel zoals een URI + IP-combinatie) gedurende een voortschrijdend venster van vijf minuten. Wanneer het aantal de geconfigureerde drempel overschrijdt, wordt de regelactie geactiveerd totdat de frequentie weer onder de limiet zakt. Omdat AWS WAF de lijst met overtreders continu binnen enkele seconden bijwerkt, zijn rate-based rules de standaardoplossing voor grootschalig misbruik vanaf een kleine, wisselende set van IP-adressen — u hoeft niet handmatig een IP-set samen te stellen, en de operationele overhead is na de initiële implementatie van de regel vrijwel nul.
{
"Name": "RateLimitPerIP",
"Priority": 10,
"Statement": {
"RateBasedStatement": {
"Limit": 2000,
"AggregateKeyType": "IP"
}
},
"Action": { "Block": {} },
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "RateLimitPerIP"
}
}
IP sets zijn herbruikbare lijsten van CIDR-reeksen waarnaar wordt verwezen door regels met een IPSetReferenceStatement. Ze zijn de juiste primitieve wanneer u een deterministische block/allow-lijst heeft — bijvoorbeeld voor geografisch beperkte admin-endpoints of bekende kwaadaardige reeksen uit threat intelligence feeds. Aangepaste regels combineren meerdere statements met logische AndStatement, OrStatement en NotStatement operatoren, waarmee u voorwaarden kunt uitdrukken zoals “blokkeer requests naar /login uit andere landen dan de VS die ook een specifieke header missen.”
CloudFront als DDoS-mitigatielaag en Origin-bescherming
CloudFront absorbeert volumetrische en state-exhaustion-aanvallen aan de AWS-edge, ruim voordat het verkeer uw ALB- of EC2-vloot bereikt. Elke edge-locatie draait automatisch AWS Shield Standard, wat zonder extra kosten mitigatie biedt tegen SYN-floods en reflection-aanvallen. Door CloudFront voor een ALB te plaatsen, wordt het aanvalsoppervlak verkleind tot het edge-netwerk en worden WAF op edge-niveau, geo-restrictie en TLS-terminatie mogelijk gemaakt.
De mitigatie is alleen effectief als aanvallers CloudFront niet kunnen omzeilen door rechtstreeks de DNS-naam van de ALB aan te spreken. Twee mechanismen beveiligen dit pad. Ten eerste, configureer CloudFront om een geheime custom origin header te injecteren (bijvoorbeeld X-Origin-Verify: <random-value>) en configureer een ALB listener rule die een 403 retourneert voor elk verzoek dat die exacte header-waarde mist. Roteer het geheim periodiek via AWS Secrets Manager. Ten tweede, beperk de security group van de ALB tot de door AWS beheerde prefixlijst com.amazonaws.global.cloudfront.origin-facing, die de IP-reeksen van de CloudFront-edge bevat.
ALBListenerRule:
Type: AWS::ElasticLoadBalancingV2::ListenerRule
Properties:
Actions:
- Type: fixed-response
FixedResponseConfig: { StatusCode: "403", ContentType: text/plain }
Conditions:
- Field: http-header
HttpHeaderConfig:
HttpHeaderName: X-Origin-Verify
Values: ["!Ref OriginSecret"]
- Field: http-header
HttpHeaderConfig: { HttpHeaderName: X-Origin-Verify, Values: ["*"] }
Priority: 1
Simpelweg een WAF ACL aan de ALB koppelen zonder het verkeer door CloudFront te forceren, laat het ALB-eindpunt publiek bereikbaar. Aanvallers die de DNS-naam ontdekken (via certificate transparency logs, historische DNS of subdomein-enumeratie) kunnen deze rechtstreeks aanvallen, waardoor alle edge-beveiligingen worden omzeild. Dit is de meest voorkomende architecturale fout in “CloudFront + ALB”-ontwerpen.
Shield Advanced Metrics, Alarms en Notificaties
Shield Advanced voegt verbeterde detectie, 24/7 toegang tot het Shield Response Team, kostenbescherming voor schalen tijdens aanvallen en zichtbaarheid van aanvallen op de applicatielaag toe. Het verstuurt echter niet automatisch e-mail of sms wanneer een aanval plaatsvindt. Notificaties moeten expliciet worden geconfigureerd via CloudWatch.
Shield Advanced publiceert de DDoSDetected metric (waarde 1 terwijl een aanval gaande is) en DDoSAttackBitsPerSecond, DDoSAttackPacketsPerSecond, en DDoSAttackRequestsPerSecond per beschermde resource in de AWS/DDoSProtection namespace. Maak een CloudWatch alarm aan op DDoSDetected >= 1 met een SNS-topic als de alarmactie; SNS verspreidt dit vervolgens naar e-mail, sms, chat of een Lambda-responder.
aws cloudwatch put-metric-alarm \
--alarm-name ShieldDDoSDetected \
--namespace AWS/DDoSProtection \
--metric-name DDoSDetected \
--statistic Maximum --period 60 --threshold 1 \
--comparison-operator GreaterThanOrEqualToThreshold \
--evaluation-periods 1 \
--alarm-actions arn:aws:sns:us-east-1:111122223333:secops-alerts
Aannemen dat Shield Advanced u “gewoon een e-mail stuurt” is een veelvoorkomend misverstand — zonder het CloudWatch-alarm plus SNS-abonnement zijn de enige signalen de Shield-console en de gebeurtenis in het AWS Health Dashboard.
AWS Network Firewall met geautomatiseerde Lambda-blokkering
Network Firewall is een stateful, aan een VPC gekoppelde Layer 3–7 firewall die verkeer inspecteert dat door subnet route tables gaat. Het beleid bestaat uit stateless en stateful rule groups; stateful rule groups gebruiken Suricata-compatibele syntax. Omdat de rule groups via een API worden beheerd, zijn ze ideale doelen voor event-driven automatisering.
Een veelgebruikt patroon reageert op GuardDuty-bevindingen (bijvoorbeeld UnauthorizedAccess:EC2/RDPBruteForce of Backdoor:EC2/C&CActivity). Security Hub aggregeert de bevinding, EventBridge matcht een event pattern en roept een Lambda-functie aan, en de Lambda roept UpdateRuleGroup aan om een drop rule in te voegen die gericht is op het aanvallende IP-adres of de ENI van de gecompromitteerde instance.
def handler(event, _):
ip = event["detail"]["findings"][0]["ProductFields"]["aws/guardduty/service/action/networkConnectionAction/remoteIpDetails/ipAddressV4"]
new_rule = f'drop ip {ip} any -> any any (msg:"GD-block"; sid:{sid()}; rev:1;)'
rg = nfw.describe_rule_group(RuleGroupArn=RG_ARN)
rules = rg["RuleGroup"]["RulesSource"]["RulesString"] + "\n" + new_rule
nfw.update_rule_group(
RuleGroupArn=RG_ARN,
UpdateToken=rg["UpdateToken"],
RulesSource={"RulesString": rules})
Network Firewall is de juiste keuze wanneer u bidirectioneel verkeer van/naar een EC2-instance of CIDR aan de rand van de VPC moet blokkeren — WAF inspecteert alleen HTTP-verzoeken die bestemd zijn voor ondersteunde Layer 7-eindpunten, dus het kan uitgaand C2-verkeer of niet-HTTP-protocollen niet stoppen.
Loggen, Monitoren en Veilige Uitrol met Count
Schakel WAF-logging in voor elke Web ACL en stream dit naar CloudWatch Logs, S3 of Kinesis Data Firehose. Logs bevatten de overeenkomende regel, de actie, request-headers en (met redactieregels) gesaneerde body’s. Gesamplede requests in de console geven een snel overzicht, maar bewaren alleen de laatste 3 uur en 100 samples per regel; volledige logs zijn noodzakelijk voor audits en forensisch onderzoek.
De Count-actie is essentieel voor een veilige uitrol van regels. Implementeer nieuwe beheerde regelgroepen (bijvoorbeeld AWSManagedRulesCommonRuleSet of de Bot Control-groep) waarbij de ‘rule action overrides’ eerst op Count zijn ingesteld. Houd de CountedRequests CloudWatch-metric en log-entries in de gaten voor false positives — legitiem verkeer dat anders geblokkeerd zou zijn. Pas nadat je de uitsluitingen hebt afgestemd, zet je de acties om naar Block. Het direct implementeren van beheerde regels met de Block-actie, zonder een Count-fase, veroorzaakt regelmatig storingen wanneer een regel zoals SizeRestrictions_BODY een legitiem eindpunt voor grote uploads blokkeert, of wanneer CrossSiteScripting_BODY wordt geactiveerd door de payload van een rich-text editor. De oplossing is niet om de hele groep uit te schakelen, maar om een ‘scope-down statement’ of een ‘rule action override’ toe te voegen voor de specifieke regel die onterecht wordt geactiveerd.
Koppel WAF-metrics (BlockedRequests, AllowedRequests, CountedRequests) aan CloudWatch-alarms zodat een plotselinge piek in blokkades — of een plotselinge daling in toegestaan verkeer — de on-call engineer alarmeert, waarmee de cirkel tussen edge-bescherming en operationeel bewustzijn wordt gesloten.
Praktijkprobleem: Gebruikersscenario
Scenario: Meridian Financial beheert een klantgerichte webapplicatie in een multi-AZ VPC met Application Load Balancers (ALB’s) die ECS-services aansturen, en distribueert statische en dynamische content via CloudFront. Het team gebruikt AWS WAF, maar heeft beperkte automatisering voor bedreigingen op de netwerklaag en inconsistente logging tussen de services.
Uitdaging: Een recente volumetrische en applicatielaag-verkeerspiek was gericht op login-eindpunten en veroorzaakte uitputting van de ALB CPU tijdens het zoeken naar mogelijkheden voor ‘credential stuffing’; het securityteam heeft snelle DDoS-mitigatie, consistente origin-bescherming, geautomatiseerde blokkering van kwaadwillende IP’s en veilige uitrol van strengere regels nodig.
Aanbevolen Aanpak:
- Schakel CloudFront in vóór de ALB voor wereldwijde edge-mitigatie, configureer de ALB om alleen verkeer van CloudFront te accepteren door een custom origin-header te valideren en de inkomende toegang te beperken met een door CloudFront beheerde prefixlijst of bekende IP-ranges.
- Implementeer AWS WAFv2 met beheerde AWS-regelsets plus custom rate-based en bot-detectieregels; koppel de WAF aan zowel de CloudFront-distributie als de ALB. Stel nieuwe custom regels in eerste instantie in op de COUNT-modus om telemetrie te verzamelen.
- Meld het account aan voor AWS Shield Advanced en koppel de CloudFront-distributie en ALB; maak CloudWatch-metricalarmen aan met behulp van Shield/DDoS-metrics en stuur alarmen door naar een SNS-topic voor on-call notificaties en het activeren van runbooks.
- Centraliseer logs: stream CloudFront-, ALB-, WAF- en AWS Network Firewall-logs naar Kinesis Data Firehose → S3 en schakel CloudWatch-metrics/dashboards in om het aantal overeenkomsten van regels in de COUNT-modus te monitoren.
- Implementeer AWS Network Firewall in de VPC met stateful regelgroepen en schakel de logging ervan in; maak CloudWatch-metricfilters voor verdachte patronen en een Lambda die door alarmen wordt geactiveerd om de Network Firewall-regelgroep automatisch bij te werken en de overtredende IP’s aan een ‘deny list’ toe te voegen.
- Nadat het verkeer in de COUNT-modus en via dashboards gedurende een afgesproken observatieperiode is geobserveerd, zet je de WAF-regels met een hoge betrouwbaarheid om naar BLOCK en behoud je de geautomatiseerde Network Firewall-updates met veilige rollbacks en versiebeheer van regelgroepen.
Redenering: Het gebruik van CloudFront als de edge-laag met WAF en Shield Advanced biedt gelaagde DDoS-bescherming, terwijl gecentraliseerde logging, validatie van regels in de COUNT-modus en geautomatiseerde, door Lambda aangestuurde Network Firewall-updates een veilige, observeerbare en geautomatiseerde netwerkverdediging bieden die consistent is met de best practices van AWS.
← Netwerken en VPC-beveiliging · Alle domeinen · Governance →
Oefen deze vragen → · Getimede oefening op ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Slaag voor je examen →