Amazon SCS-C02: Edge- und Anwendungssicherheit — Lernleitfaden
Teil des AWS Security Specialty SCS-C02 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.
CloudFront Geo-Restriktion und Blockierung auf Länderebene
CloudFront bietet zwei Mechanismen, um den Datenverkehr nach Ländern zu blockieren, und die Wahl zwischen ihnen ist für Kosten und Funktionalität von Bedeutung. Die integrierte Geo-Restriktion (auch Geoblocking genannt) wird direkt in der Distribution konfiguriert und wertet Anfragen am Edge anhand einer Zulassungs- oder Sperrliste für Länder aus, die von der IP des Betrachters abgeleitet wird. Sie ist kostenlos, erfordert keine Regelauswertung und gibt HTTP 403 zurück, bevor ein Abruf vom Ursprung stattfindet. Für einfache Compliance-Szenarien – „Besucher aus Land X blockieren“ – ist dies die günstigste und einfachste Option.
Die Alternative ist eine WAF Geo-Match-Anweisung, die flexibler ist: Sie können Länderübereinstimmungen mit URI-Pfaden, Headern, Ratenbegrenzungen kombinieren oder sie negieren („Land A nur für /admin zulassen“). WAF ist erforderlich, wenn die Logik konditional ist; eine reine Geo-Restriktion kann nicht ausdrücken: „Land X nur für einen bestimmten Pfad blockieren“. Wählen Sie die native Geo-Restriktion, wenn die Anforderung eine pauschale Ländersperre ist und Sie die Kosten pro Anfrage von WAF vermeiden möchten.
Signierte URLs versus signierte Cookies für private Inhalte
CloudFront unterstützt zwei Methoden, um autorisierte private Inhalte bereitzustellen, während der Ursprung (S3-Bucket, ALB oder Media-Ursprung) hinter einer Origin Access Control oder einem benutzerdefinierten Header verborgen bleibt:
Signierte URLs: Jede URL trägt eine Signatur und eine Richtlinie. Ideal für den Download einer einzelnen Datei oder wenn Sie eine Zugriffskontrolle pro Datei benötigen (z. B. ein einmaliger Link für ein Software-Installationsprogramm).
Signierte Cookies: Der Client erhält einmalig von Ihrem Authentifizierungsdienst ein Cookie-Set bestehend aus
CloudFront-Policy,CloudFront-SignatureundCloudFront-Key-Pair-Id. Alle nachfolgenden Anfragen an passende Pfadmuster werden automatisch autorisiert, ohne dass die URLs umgeschrieben werden müssen.
Für HLS-Videostreaming, bei dem eine einzige Wiedergabsession Tausende von .ts-Segmenten abruft, die in einem Manifest referenziert sind, sind signierte Cookies deutlich einfacher. Jede Segment-URL im Manifest mit einer eigenen signierten URL umzuschreiben, ist möglich, erhöht aber die Latenz und Komplexität. Setzen Sie das Cookie, nachdem sich der Abonnent bei Ihrem internen Benutzerverzeichnis authentifiziert hat, mit Geltungsbereich für das Streaming-Pfadmuster.
Eine kanonische Richtlinie für ein signiertes Wildcard-Cookie sieht wie folgt aus:
{
"Statement": [{
"Resource": "https://d123.cloudfront.net/videos/*",
"Condition": {
"DateLessThan": {"AWS:EpochTime": 1735689600},
"IpAddress": {"AWS:SourceIp": "203.0.113.0/24"}
}
}]
}
Kombinieren Sie dies mit einer Origin Access Control (OAC) oder einem geheimen benutzerdefinierten Header, der von WAF am Ursprung validiert wird, damit Benutzer CloudFront nicht umgehen und direkt auf den Ursprung zugreifen können.
AWS WAF: Verwaltete Regeln, ATP und ratenbasierte Regeln
Verknüpfen Sie die Web ACL mit der CloudFront-Distribution anstatt mit einem regionalen ALB, wenn der Workload hinter CloudFront liegt. Die Anbindung am Edge beendet bösartige Anfragen an einem von Hunderten von POPs – näher am Angreifer –, was die Last auf dem Ursprung während eines DDoS-Angriffs reduziert und den ausgehenden Datenverkehr (Egress) vom Ursprung senkt, da blockierter Verkehr niemals Ihre VPC durchläuft. Wenn WAF nur mit dem ALB verknüpft wird, erreicht die volumetrische Flut immer noch den regionalen Load Balancer und verbraucht LCUs, und regionsübergreifende Angriffe werden von einer einzigen Region statt vom globalen Edge-Netzwerk behandelt.
Wichtige Regelgruppen zur Kombination:
Von AWS verwaltete Regelsätze:
AWSManagedRulesCommonRuleSet(im Stil der OWASP Top 10),AWSManagedRulesKnownBadInputsRuleSetundAWSManagedRulesAmazonIpReputationListbieten eine breite Abdeckung mit nahezu keinem Abstimmungsaufwand.Account Takeover Prevention (ATP):
AWSManagedRulesATPRuleSetüberprüft den von Ihnen festgelegten Login-Endpunkt, verfolgt Credential-Stuffing-Muster, gleicht übermittelte Anmeldeinformationen mit einer Datenbank kompromittierter Anmeldedaten ab und blockiert Bots, die geleakte Passwörter wiederverwenden. Konfigurieren Sie es mit dem exakten Login-Pfad und den JSON-Body-Feldnamen für Benutzername und Passwort.Ratenbasierte Regeln: Begrenzen die Anzahl der Anfragen von einer einzelnen IP-Adresse über ein 5-Minuten-Fenster (zum Beispiel 2.000 Anfragen). Beschränken Sie ihren Geltungsbereich nach URI oder Methode, sodass das Scraping von
/searchdas anonyme Surfen auf/nicht beeinträchtigt. Ratenbasierte Regeln mildern volumetrische Angriffe auf Layer 7 und Brute-Force-Enumeration ab.
Ein gekürzter WAF-Regelblock:
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-Zertifikate, DNS-Validierung und CloudFront
Für CloudFront muss das Zertifikat in ACM in us-east-1 (N. Virginia) bereitgestellt werden, unabhängig davon, wo sich Ihr Ursprung befindet – dies ist eine zwingende Anforderung, da CloudFront ein globaler Dienst ist, der Zertifikate aus dieser Region liest. Regionale Dienste wie ALB lesen aus der eigenen Region des ALB.
Verwenden Sie immer die DNS-Validierung mit einem CNAME-Eintrag in Route 53 für jedes öffentliche Zertifikat, das Sie automatisch erneuern möchten. ACM erneuert DNS-validierte Zertifikate automatisch, solange der Validierungs-CNAME veröffentlicht bleibt; Route 53 macht dies trivial (die Konsole bietet während der Anforderung „Datensätze in Route 53 erstellen“ an). Die E-Mail-Validierung hingegen sendet eine Bestätigung an fünf Adressen der Domain (admin@, administrator@, hostmaster@, postmaster@, webmaster@) sowie an den WHOIS-Kontakt. Diese Postfächer existieren häufig nicht oder werden von unternehmenseigenen Mail-Filtern unter Quarantäne gestellt, sodass Verlängerungen 60 Tage vor Ablauf fehlschlagen und vermeidbare Ausfälle verursachen. Es gibt keine Möglichkeit, die Klicks zur E-Mail-Validierung zu automatisieren.
Das korrekte Erneuerungsmuster für Multi-Region-ALBs ist: pro Region ein DNS-validiertes ACM-Zertifikat anfordern, den Validierungs-CNAME einmal in Route 53 veröffentlichen, das Zertifikat dem ALB-Listener zuweisen und ACM die Erneuerung und erneute Bereitstellung überlassen. Menschliches Eingreifen endet mit der Ausstellung.
DNSSEC und Route 53
Aktivieren Sie die DNSSEC-Signierung für die gehostete Zone in Route 53, um DNS-Spoofing und Cache Poisoning gegen Ihre Domain zu verhindern. Route 53 verwaltet den KSK in KMS (asymmetrischer ECC-Schlüssel in us-east-1); Sie müssen den DS-Record beim Registrar veröffentlichen. Beachten Sie, dass die DNSSEC-Signierung die Auflösung Ihrer Zone schützt – sie verschlüsselt nicht den DNS-Verkehr (das ist DoH/DoT) und hat keine Auswirkungen auf das TLS von CloudFront.
Antwort-Header: Richtlinien versus Lambda@Edge
CloudFront fügt Sicherheits-Header wie Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options oder Content-Security-Policy nicht automatisch ein. Wenn Ihr Origin nicht modifiziert werden kann (eine ältere S3-Website, ein Drittanbieter-Origin), haben Sie zwei Möglichkeiten:
Richtlinie für Antwort-Header: eine native, deklarative CloudFront-Funktion. Hängen Sie eine verwaltete oder benutzerdefinierte Richtlinie an ein Cache-Verhalten an, um HSTS-, CORS-, Sicherheits- und benutzerdefinierte Header hinzuzufügen. Dies sollte die Standardwahl sein – kein Code, keine Cold Starts, keine Kosten pro Aufruf.
Lambda@Edge (Viewer Response oder Origin Response): verwenden, wenn Sie dynamische Logik benötigen, wie z. B. variierende CSP-Nonces pro Anfrage oder das Umschreiben von Headern basierend auf Anfrageattributen. Tauscht Einfachheit gegen Flexibilität und verursacht Kosten pro Anfrage.
Die verwaltete Richtlinie für Antwort-Header SecurityHeadersPolicy deckt die gängige Baseline mit einem einzigen Anhang ab.
Häufige Fallstricke erklärt
Das Anfordern öffentlicher ACM-Zertifikate mit E-Mail-Validierung ist fragil, eben weil die Erneuerung davon abhängt, dass Menschen E-Mails lesen, die an generische Adressen gesendet werden, welche die meisten Organisationen nicht überwachen oder die im Spam landen. Die DNS-Validierung mit Route 53 eliminiert die menschliche Komponente vollständig.
Das Anhängen von WAF nur an den ALB sieht auf dem Papier gleichwertig aus, zwingt aber Angriffsverkehr in Ihre Region und verbraucht ALB-Kapazität. Eine am Edge angebundene WAF auf CloudFront blockiert an Hunderten von POPs, sodass eine verteilte Flut global absorbiert wird und der Egress des Origins niedrig bleibt – entscheidend während eines DDoS-Angriffs.
Die Annahme, dass CloudFront automatisch Sicherheits-Header hinzufügt, führt zu fehlgeschlagenen Penetrationstests. Die Distribution leitet alle Header weiter, die der Origin sendet; Sie müssen explizit eine Richtlinie für Antwort-Header oder eine Lambda@Edge-Funktion anhängen, um X-Frame-Options: DENY, HSTS und CSP einzufügen.
Praktisches Problem: Anwendungsfallszenario
Szenario: Meridian Financial betreibt ein global verteiltes Kundenportal und ein internes Berichtsportal auf AWS. Der öffentliche Datenverkehr wird über Amazon CloudFront zu Application Load Balancers für dynamische APIs und zu S3-Origins für private Berichte geleitet; DNS befindet sich in Route 53 und TLS-Zertifikate werden vom AWS Certificate Manager (ACM) ausgestellt.
Herausforderung: Angreifer betreiben Scraping und Credential-Stuffing von Konten aus mehreren Ländern, umgehen CloudFront, indem sie direkt auf die Endpunkte des Origins zugreifen, um private Berichte herunterzuladen, und verursachen so eine Überlastung des Origins und eine Datenexposition.
Empfohlener Ansatz:
- Konfigurieren Sie CloudFront als einzigen öffentlichen Zugangspunkt und wenden Sie die Geo-Restriktion von CloudFront an, um die angreifenden Länder zu blockieren; aktivieren Sie Origin Access Control (OAC) und sperren Sie die S3/ALB-Origin-Richtlinien, sodass nur CloudFront Origin-Inhalte abrufen kann.
- Stellen Sie benutzerspezifische private Berichte mit signierten URLs von CloudFront (kurze TTL) bereit anstatt mit signierten Cookies, sodass jeder Download einzeln autorisiert und prüfbar ist.
- Hängen Sie AWS WAF an die CloudFront-Distribution an, verwenden Sie AWS Managed Rules, aktivieren Sie AWS WAF Bot Control (erweiterter Bedrohungsschutz) und erstellen Sie ratenbasierte Regeln sowie CAPTCHA-Challenges, um Scraping und Credential-Stuffing zu mitigieren.
- Stellen Sie TLS-Zertifikate in ACM (us-east-1 für CloudFront-Distributionen) mittels DNS-Validierung über Route 53 bereit und veröffentlichen Sie Route 53 Alias-Records für die CloudFront-Distribution.
- Aktivieren Sie DNSSEC für die in Route 53 gehostete Zone, aktivieren Sie die Zugriffsprotokollierung von CloudFront und WAF nach S3 und erstellen Sie CloudWatch-Alarme sowie optional AWS Shield Advanced für DDoS-Sichtbarkeit und -Alarmierung.
Begründung: Das Erzwingen des gesamten Datenverkehrs durch CloudFront mit OAC und WAF setzt den Zugriff auf den Origin nach dem Prinzip der geringsten Rechte (Least Privilege) durch, Geo-Restriktion und ratenbasierte/WAF-Schutzmaßnahmen stoppen missbräuchlichen Verkehr, signierte URLs bieten eine Autorisierung pro Objekt, und ACM+DNS-Validierung mit DNSSEC gewährleistet vertrauenswürdiges TLS und DNS-Integrität gemäß den AWS Best Practices.
AWS WAF-Regeln und Integration mit ALB und CloudFront
AWS WAF ist eine Layer-7-Firewall, die HTTP(S)-Anfragen anhand einer Web ACL auswertet, die aus geordneten Regeln besteht. Jede Regel prüft Anfrageattribute (URI, Header, Body, Query-String, Quell-IP) und gibt eine terminierende Aktion (Allow, Block, Challenge, CAPTCHA) oder eine nicht-terminierende Aktion (Count) zurück. Web ACLs werden an CloudFront-Distributionen, Application Load Balancers, API Gateway, AppSync, Cognito-Benutzerpools und App Runner-Services angehängt. Wenn sie an CloudFront angehängt wird, läuft die ACL am Edge und muss im Geltungsbereich us-east-1 (Global) erstellt werden; für einen ALB muss sie sich in derselben Region wie der Load Balancer befinden.
Ratenbasierte Regeln verfolgen die Anzahl der Anfragen, die von einer einzelnen IP-Adresse (oder einem forwarded-IP-Header oder einem aggregierten Schlüssel wie einer URI + IP-Kombination) innerhalb eines gleitenden Fünf-Minuten-Fensters eintreffen. Wenn die Anzahl den konfigurierten Schwellenwert überschreitet, wird die Regelaktion ausgelöst, bis die Rate wieder unter das Limit fällt. Da AWS WAF die Liste der Angreifer kontinuierlich in Sekunden aktualisiert, sind ratenbasierte Regeln die kanonische Antwort auf hochvolumigen Missbrauch von einer kleinen, wechselnden Gruppe von IPs – Sie müssen kein IP-Set von Hand kuratieren, und der Betriebsaufwand ist nach der erstmaligen Bereitstellung der Regel praktisch null.
{
"Name": "RateLimitPerIP",
"Priority": 10,
"Statement": {
"RateBasedStatement": {
"Limit": 2000,
"AggregateKeyType": "IP"
}
},
"Action": { "Block": {} },
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "RateLimitPerIP"
}
}
IP-Sets sind wiederverwendbare Listen von CIDR-Bereichen, auf die von Regeln mit einem IPSetReferenceStatement verwiesen wird. Sie sind das richtige Grundelement, wenn Sie eine deterministische Blockier-/Erlaubnisliste haben – zum Beispiel für geografisch eingeschränkte Admin-Endpunkte oder bekannte bösartige Bereiche aus Threat-Intelligence-Feeds. Benutzerdefinierte Regeln kombinieren mehrere Anweisungen mit den logischen Operatoren AndStatement, OrStatement und NotStatement, sodass Sie Bedingungen wie „blockiere Anfragen an /login aus anderen Ländern als den USA, die zudem einen bestimmten Header nicht haben“ ausdrücken können.
CloudFront als DDoS-Abwehrschicht und Schutz für den Origin
CloudFront fängt volumetrische Angriffe und State-Exhaustion-Angriffe am AWS-Edge ab, lange bevor der Traffic Ihre ALB- oder EC2-Flotte erreicht. Jeder Edge-Standort führt automatisch AWS Shield Standard aus und bietet so kostenlose Abwehrmaßnahmen gegen SYN-Floods und Reflection-Angriffe. Indem CloudFront vor einen ALB geschaltet wird, verkleinert sich die Angriffsfläche auf das Edge-Netzwerk und ermöglicht WAF auf Edge-Ebene, Geo-Restriktionen und die TLS-Terminierung.
Die Abwehrmaßnahme ist nur dann wirksam, wenn Angreifer CloudFront nicht umgehen können, indem sie direkt auf den DNS-Namen des ALB zugreifen. Zwei Mechanismen härten diesen Pfad ab. Erstens: Konfigurieren Sie CloudFront so, dass ein geheimer, benutzerdefinierter Origin-Header (z. B. X-Origin-Verify: <random-value>) eingefügt wird, und konfigurieren Sie eine ALB-Listener-Regel, die für jede Anfrage, der genau dieser Header-Wert fehlt, einen 403-Fehler zurückgibt. Rotieren Sie das Geheimnis regelmäßig über den AWS Secrets Manager. Zweitens: Beschränken Sie die Sicherheitsgruppe des ALB auf die von AWS verwaltete Präfixliste com.amazonaws.global.cloudfront.origin-facing, die die IP-Bereiche der CloudFront-Edge-Standorte enthält.
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
Wird eine WAF-ACL einfach an den ALB angehängt, ohne den Traffic durch CloudFront zu zwingen, bleibt der ALB-Endpunkt öffentlich auflösbar. Angreifer, die den DNS-Namen entdecken (über Certificate-Transparency-Logs, historische DNS-Einträge oder Subdomain-Enumeration), können ihn direkt angreifen und so alle Schutzmaßnahmen am Edge umgehen. Dies ist der häufigste Architekturfehler bei „CloudFront + ALB“-Designs.
Shield Advanced: Metriken, Alarme und Benachrichtigungen
Shield Advanced bietet erweiterte Erkennung, 24/7-Zugang zum Shield Response Team, Kostenschutz bei Skalierung während Angriffen und Einblick in Angriffe auf der Anwendungsebene. Es versendet jedoch nicht automatisch E-Mails oder SMS, wenn ein Angriff stattfindet. Benachrichtigungen müssen explizit über CloudWatch eingerichtet werden.
Shield Advanced veröffentlicht die Metrik DDoSDetected (Wert 1 während eines laufenden Angriffs) sowie DDoSAttackBitsPerSecond, DDoSAttackPacketsPerSecond und DDoSAttackRequestsPerSecond pro geschützter Ressource im AWS/DDoSProtection-Namespace. Erstellen Sie einen CloudWatch-Alarm für DDoSDetected >= 1 mit einem SNS-Thema als Alarmaktion; SNS verteilt die Benachrichtigung dann per E-Mail, SMS, Chat oder an einen 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
Die Annahme, dass Shield Advanced Ihnen „einfach eine E-Mail schickt“, ist ein häufiger Irrglaube – ohne den CloudWatch-Alarm und das SNS-Abonnement sind die einzigen Signale die Shield-Konsole und das Ereignis im AWS Health Dashboard.
AWS Network Firewall mit automatisierter Lambda-Blockierung
Network Firewall ist eine zustandsbehaftete (stateful), an eine VPC angebundene Layer-3-7-Firewall, die den Traffic überprüft, der Subnetz-Routing-Tabellen durchläuft. Ihre Richtlinie besteht aus zustandslosen (stateless) und zustandsbehafteten (stateful) Regelgruppen; zustandsbehaftete Regelgruppen verwenden eine Suricata-kompatible Syntax. Da die Regelgruppen per API verwaltet werden, sind sie ideale Ziele für ereignisgesteuerte Automatisierung.
Ein gängiges Muster reagiert auf GuardDuty-Findings (z. B. UnauthorizedAccess:EC2/RDPBruteForce oder Backdoor:EC2/C&CActivity). Security Hub aggregiert das Finding, EventBridge gleicht ein Ereignismuster ab und ruft eine Lambda-Funktion auf, und die Lambda-Funktion ruft UpdateRuleGroup auf, um eine Drop-Regel einzufügen, die auf die angreifende IP oder das ENI der kompromittierten Instanz abzielt.
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 ist die richtige Wahl, wenn Sie bidirektionalen Traffic zu/von einer EC2-Instanz oder einem CIDR am VPC-Edge blockieren müssen – WAF inspiziert nur HTTP-Anfragen, die für unterstützte Layer-7-Endpunkte bestimmt sind, und kann daher keinen ausgehenden C2-Traffic oder Nicht-HTTP-Protokolle stoppen.
Protokollierung, Überwachung und sicheres Rollout mit Count
Aktivieren Sie die WAF-Protokollierung für jede Web ACL und streamen Sie die Daten an CloudWatch Logs, S3 oder Kinesis Data Firehose. Die Protokolle enthalten die übereinstimmende Regel, die Aktion, die Anfrage-Header und (mit Schwärzungsregeln) bereinigte Body-Inhalte. Stichprobenartige Anfragen in der Konsole bieten einen schnellen Überblick, behalten aber nur die letzten 3 Stunden und 100 Stichproben pro Regel bei; für Audits und Forensik sind vollständige Protokolle unerlässlich.
Die Count-Aktion ist für ein sicheres Rollout von Regeln unerlässlich. Stellen Sie neue verwaltete Regelgruppen (z. B. AWSManagedRulesCommonRuleSet oder die Bot-Control-Gruppe) zunächst mit auf „Count“ gesetzten Regelaktions-Overrides bereit. Beobachten Sie die CloudWatch-Metrik CountedRequests und die Protokolleinträge auf False Positives – also legitimen Datenverkehr, der blockiert worden wäre. Erst nachdem Sie Ausschlüsse feinabgestimmt haben, stellen Sie die Aktionen auf „Block“ um. Die Bereitstellung verwalteter Regeln direkt mit „Block“ ohne eine Count-Phase führt regelmäßig zu Ausfällen, wenn eine Regel wie SizeRestrictions_BODY einen legitimen Endpunkt für große Uploads blockiert oder wenn CrossSiteScripting_BODY bei einem Rich-Text-Editor-Payload auslöst. Die Lösung besteht nicht darin, die gesamte Gruppe zu deaktivieren, sondern eine Scope-Down-Anweisung oder ein Rule-Action-Override für die spezifische, fehlerhaft auslösende Regel hinzuzufügen.
Kombinieren Sie WAF-Metriken (BlockedRequests, AllowedRequests, CountedRequests) mit CloudWatch-Alarmen, sodass ein plötzlicher Anstieg von Blockierungen – oder ein plötzlicher Einbruch des erlaubten Datenverkehrs – den diensthabenden Techniker alarmiert und so der Kreis zwischen Edge-Schutz und betrieblichem Bewusstsein geschlossen wird.
Praktisches Problem: Anwendungsfallszenario
Szenario: Meridian Financial betreibt eine kundenorientierte Webanwendung in einer Multi-AZ-VPC mit Application Load Balancers (ALBs) vor ECS-Services und verteilt statische sowie dynamische Inhalte über CloudFront. Das Team verwendet AWS WAF, hatte aber bisher nur begrenzte Automatisierung für Bedrohungen auf der Netzwerkebene und eine inkonsistente Protokollierung über die verschiedenen Dienste hinweg.
Herausforderung: Ein kürzlicher volumetrischer und auf der Anwendungsebene angesiedelter Traffic-Anstieg zielte auf Login-Endpunkte ab und verursachte eine CPU-Überlastung des ALBs, während nach Credential-Stuffing-Möglichkeiten gesucht wurde. Das Sicherheitsteam benötigt eine schnelle DDoS-Abwehr, einen konsistenten Schutz des Origins, eine automatisierte Blockierung bösartiger IPs und sichere Rollouts strengerer Regeln.
Empfohlener Ansatz:
- Aktivieren Sie CloudFront vor dem ALB für eine globale Edge-Mitigation. Konfigurieren Sie den ALB so, dass er nur Datenverkehr von CloudFront akzeptiert, indem Sie einen benutzerdefinierten Origin-Header validieren und den eingehenden Zugriff mit einer von CloudFront verwalteten Präfixliste oder bekannten IP-Bereichen einschränken.
- Stellen Sie AWS WAFv2 mit verwalteten AWS-Regelsätzen sowie benutzerdefinierten ratenbasierten und Bot-Erkennungsregeln bereit. Hängen Sie die WAF sowohl an die CloudFront-Distribution als auch an den ALB an. Setzen Sie neue benutzerdefinierte Regeln anfangs in den COUNT-Modus, um Telemetriedaten zu sammeln.
- Registrieren Sie das Konto bei AWS Shield Advanced und verknüpfen Sie die CloudFront-Distribution und den ALB. Erstellen Sie CloudWatch-Metrikalarme unter Verwendung von Shield/DDoS-Metriken und leiten Sie Alarme an ein SNS-Thema für Bereitschaftsbenachrichtigungen und Runbook-Trigger weiter.
- Zentralisieren Sie die Protokolle: Streamen Sie CloudFront-, ALB-, WAF- und AWS Network Firewall-Protokolle in Kinesis Data Firehose → S3 und aktivieren Sie CloudWatch-Metriken/Dashboards, um die Anzahl der Regelübereinstimmungen aus dem COUNT-Modus zu überwachen.
- Stellen Sie AWS Network Firewall in der VPC mit zustandsbehafteten (stateful) Regelgruppen bereit und aktivieren Sie deren Protokollierung. Erstellen Sie CloudWatch-Metrikfilter für verdächtige Muster und eine Lambda-Funktion, die durch Alarme ausgelöst wird, um die Network Firewall-Regelgruppe automatisch zu aktualisieren und die schuldigen IPs zu einer Deny-Liste hinzuzufügen.
- Nachdem der Datenverkehr im COUNT-Modus und auf den Dashboards für ein vereinbartes Beobachtungsfenster analysiert wurde, stellen Sie die WAF-Regeln, bei denen ein hohes Vertrauen besteht, auf BLOCK um und behalten Sie die automatisierten Network Firewall-Updates mit sicheren Rollbacks und Versionierung der Regelgruppen bei.
Begründung: Die Verwendung von CloudFront als Edge-Layer mit WAF und Shield Advanced bietet einen mehrschichtigen DDoS-Schutz. Gleichzeitig ermöglichen die zentralisierte Protokollierung, die Validierung von Regeln im COUNT-Modus und die automatisierten, Lambda-gesteuerten Updates der Network Firewall eine sichere, beobachtbare und automatisierte Netzwerkverteidigung, die den AWS Best Practices entspricht.
← Netzwerk- und VPC-Sicherheit · Alle Domänen · Governance →
Diese Fragen üben → · Zeitlich begrenzte Übung auf 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.
Bestehe deine Prüfung →