**Wir stellen vor: ein neues Konsolenerlebnis für AWS WAF**
Sie können das aktualisierte Erlebnis jetzt verwenden, um überall in der Konsole auf AWS WAF Funktionen zuzugreifen. Weitere Informationen finden Sie unter [Arbeiten mit der Konsole](https://docs.aws.amazon.com/waf/latest/developerguide/working-with-console.html).
Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# AWS Shield
Der Schutz vor Distributed Denial of Service (DDoS) -Angriffen ist für Ihre mit dem Internet verbundenen Anwendungen von größter Bedeutung. Wenn Sie Ihre Anwendung darauf aufbauen AWS, können Sie ohne zusätzliche Kosten Schutzmaßnahmen nutzen. AWS Darüber hinaus können Sie den AWS Shield Advanced Managed Threat Protection Service verwenden, um Ihre Sicherheitslage durch zusätzliche DDo S-Erkennungs-, Abwehr- und Reaktionsfunktionen zu verbessern.
AWS ist bestrebt, Ihnen die Tools, Best Practices und Services zur Verfügung zu stellen, mit denen Sie hohe Verfügbarkeit, Sicherheit und Widerstandsfähigkeit bei der Abwehr bösartiger Akteure im Internet gewährleisten können. Dieser Leitfaden soll IT-Entscheidungsträgern und Sicherheitsingenieuren helfen, zu verstehen, wie sie Shield und Shield Advanced verwenden können, um ihre Anwendungen besser vor DDo S-Angriffen und anderen externen Bedrohungen zu schützen.
Wenn Sie Ihre Anwendung darauf aufbauen AWS, erhalten Sie automatischen Schutz AWS vor gängigen volumetrischen DDo S-Angriffsvektoren wie UDP-Reflection-Angriffen und TCP-SYN-Floods. Sie können diese Schutzmaßnahmen nutzen, um die Verfügbarkeit der Anwendungen sicherzustellen, auf denen Sie ausgeführt werden, AWS indem Sie Ihre Architektur für S-Resilienz entwerfen und konfigurieren. DDo
Dieser Leitfaden enthält Empfehlungen, die Ihnen beim Entwerfen, Erstellen und Konfigurieren Ihrer Anwendungsarchitekturen für DDo S Resiliency helfen können. Anwendungen, die sich an die in diesem Leitfaden aufgeführten Best Practices halten, können von einer verbesserten Kontinuität der Verfügbarkeit profitieren, wenn sie von größeren DDo S-Angriffen und einer breiteren Palette von S-Angriffsvektoren DDo angegriffen werden. Darüber hinaus zeigt Ihnen dieser Leitfaden, wie Sie Shield Advanced verwenden, um einen optimierten DDo S-Schutzstatus für Ihre kritischen Anwendungen zu implementieren. Dazu gehören Anwendungen, für die Sie Ihren Kunden ein gewisses Maß an Verfügbarkeit garantiert haben, und Anwendungen, für die Sie AWS bei DDo S-Ereignissen Betriebsunterstützung benötigen.
Sicherheit ist eine gemeinsame Verantwortung von Ihnen AWS und Ihnen. Das [Modell der geteilten Verantwortung](https://aws.amazon.com/compliance/shared-responsibility-model/) beschreibt dies als Sicherheit *der* Cloud und Sicherheit *in* der Cloud:
+ **Sicherheit der Cloud** — AWS ist verantwortlich für den Schutz der Infrastruktur, auf der AWS Dienste in der ausgeführt AWS Cloud werden. AWS bietet Ihnen auch Dienste, die Sie sicher nutzen können. Die Wirksamkeit unserer Sicherheitsfunktionen wird regelmäßig von externen Prüfern im Rahmen des [AWS -Compliance-Programms getestet und überprüft](https://aws.amazon.com/compliance/programs/). Informationen zu den Compliance-Programmen, die für Shield Advanced gelten, finden Sie unter [AWS Services im Umfang nach Compliance-Programmen](https://aws.amazon.com/compliance/services-in-scope/).
+ **Sicherheit in der Cloud** — Ihre Verantwortung richtet sich nach dem AWS Dienst, den Sie nutzen. In Ihre Verantwortung fallen außerdem weitere Faktoren, wie z. B. die Vertraulichkeit der Daten, die Anforderungen Ihrer Organisation sowie geltende Gesetze und Vorschriften.
![\[Ein Diagramm zeigt ein Rechteck, das horizontal geteilt ist. Die obere Hälfte trägt den Titel Kunde: Verantwortung für die Sicherheit „in“ der Cloud und die untere Hälfte trägt den Titel AWS: Verantwortung für die Sicherheit „der Cloud“. Die obere Kundenhälfte besteht aus vier Stufen. Die oberste Kategorie sind Kundendaten. Die zweite ist Plattform-, Anwendungs-, Identitäts- und Zugriffsmanagement. Die dritte ist die Konfiguration von Betriebssystem, Netzwerk und Firewall. Die vierte und unterste Ebene für den Kundenbereich ist in drei Bereiche aufgeteilt, die nebeneinander liegen. Auf der linken Seite befinden sich die Bereiche Kundenseitige Daten, Verschlüsselung und Datenintegrität sowie Authentifizierung. Die mittlere ist serverseitige Verschlüsselung ( and/or Dateisystemdaten). Die richtige ist der Schutz des Netzwerkverkehrs (Verschlüsselung, Integrität, Identität). Damit ist der Inhalt des Topkunden zur Hälfte abgeschlossen. Die untere AWS Hälfte der Abbildung enthält oben eine Ebene mit dem Titel Software und darunter eine Ebene mit dem Titel Hardware/globale Infrastruktur AWS . Die Softwareebene ist in vier Unterabschnitte unterteilt, die nebeneinander liegen und die folgenden lauten: Compute, Storage, Database, Networking. Die Hardwareebene ist in drei Unterabschnitte unterteilt, die nebeneinander liegen und die folgenden lauten: Regionen, Availability Zones, Edge-Standorte.\]](http://docs.aws.amazon.com/de_de/waf/latest/developerguide/images/shared-responsibility-model.png)
# So funktionieren AWS Shield und Shield Advanced
Auf dieser Seite wird der Unterschied zwischen AWS Shield Standard und erklärt AWS Shield Advanced. Es beschreibt auch die Klassen von Angriffen, die Shield erkennt.
AWS Shield Standard und AWS Shield Advanced bieten Schutz vor Distributed-Denial-of-Service-Angriffen (DDoS) für AWS Ressourcen auf der Netzwerk- und Transportebene (Schicht 3 und 4) sowie auf der Anwendungsebene (Schicht 7). Ein DDo S-Angriff ist ein Angriff, bei dem mehrere kompromittierte Systeme versuchen, ein Ziel mit Datenverkehr zu überfluten. Ein DDo S-Angriff kann legitime Endbenutzer am Zugriff auf die Zieldienste hindern und das Ziel aufgrund des überwältigenden Datenverkehrs zum Absturz bringen.
AWS Shield bietet Schutz vor einer Vielzahl bekannter DDo S-Angriffsvektoren und Zero-Day-Angriffsvektoren. Shield Detection and Mitigation wurde entwickelt, um Bedrohungen abzuwehren, auch wenn sie dem Dienst zum Zeitpunkt der Entdeckung nicht ausdrücklich bekannt waren.
Shield Standard wird automatisch und ohne Aufpreis bereitgestellt, wenn Sie es verwenden AWS. Für einen höheren Schutz vor Angriffen können Sie AWS Shield Advanced abonnieren.
Zu den Kategorien von Angriffen, die Shield erkennt, gehören:
+ **Volumetrische Netzwerkangriffe (Schicht 3)** — Dies ist eine Unterkategorie von Angriffsvektoren auf Infrastrukturebene. Diese Vektoren versuchen, die Kapazität des Zielnetzwerks oder der Zielressource zu überlasten, um legitimen Benutzern den Dienst zu verweigern.
+ **Netzwerkprotokollangriffe (Schicht 4)** — Dies ist eine Unterkategorie von Angriffsvektoren auf Infrastrukturebene. Diese Vektoren missbrauchen ein Protokoll, um der Zielressource den Zugriff zu verweigern. Ein häufiges Beispiel für einen Netzwerkprotokollangriff ist eine TCP-SYN-Flood, die den Verbindungsstatus von Ressourcen wie Servern, Load Balancern oder Firewalls erschöpfen kann. Ein Netzwerkprotokollangriff kann auch volumetrisch sein. Eine größere TCP-SYN-Flut könnte beispielsweise darauf abzielen, die Kapazität eines Netzwerks zu überlasten und gleichzeitig den Status der Zielressource oder der Zwischenressourcen zu erschöpfen.
+ **Angriffe auf Anwendungsebene (Schicht 7)** — Diese Kategorie von Angriffsvektoren versucht, legitimen Benutzern den Dienst zu verweigern, indem eine Anwendung mit Abfragen überflutet wird, die für das Ziel gültig sind, wie z. B. Fluten von Webanfragen.
**Contents**
+ [AWS Shield Standard -Übersicht](ddos-standard-summary.md)
+ [AWS Shield Advanced -Übersicht](ddos-advanced-summary.md)
+ [Liste der AWS Ressourcen, die AWS Shield Advanced schützen](ddos-advanced-summary-protected-resources.md)
+ [AWS Shield Advanced Fähigkeiten und Optionen](ddos-advanced-summary-capabilities.md)
+ [Entscheidung, ob zusätzliche Schutzmaßnahmen abonniert AWS Shield Advanced und angewendet werden sollen](ddos-advanced-summary-deciding.md)
+ [Beispiele für DDo S-Angriffe](types-of-ddos-attacks.md)
+ [Wie AWS Shield erkennt man Ereignisse](ddos-event-detection.md)
+ [AWS Shield Erkennungslogik für Bedrohungen auf Infrastrukturebene (Schicht 3 und Schicht 4)](ddos-event-detection-infrastructure.md)
+ [Shield Advanced Erkennungslogik für Bedrohungen auf Anwendungsebene (Schicht 7)](ddos-event-detection-application.md)
+ [Shield Advanced Erkennungslogik für mehrere Ressourcen in einer Anwendung](ddos-event-detection-multiple-resources.md)
+ [Wie AWS Shield mindert man Ereignisse](ddos-event-mitigation.md)
+ [Liste der AWS Shield DDo S-Abwehrfunktionen](ddos-event-mitigation-features.md)
+ [AWS Shield Mitigationslogik für CloudFront und Route 53](ddos-event-mitigation-logic-continuous-inspection.md)
+ [AWS Shield Minderungslogik für Regionen AWS](ddos-event-mitigation-logic-regions.md)
+ [AWS Shield Risikominderungslogik für AWS Global Accelerator Standardbeschleuniger](ddos-event-mitigation-logic-gax.md)
+ [AWS Shield Advanced Schadensbegrenzungslogik für Elastic IPs](ddos-event-mitigation-logic-adv-eip.md)
+ [AWS Shield Advanced Schadensbegrenzungslogik für Webanwendungen](ddos-event-mitigation-logic-adv-web-app.md)
# AWS Shield Standard -Übersicht
AWS Shield ist ein verwalteter Dienst zum Schutz vor Bedrohungen, der den Perimeter Ihrer Anwendung schützt. Der Perimeter ist der erste Eintrittspunkt für Anwendungsdatenverkehr, der von außerhalb des AWS Netzwerks kommt.
Um zu ermitteln, wo sich Ihr Anwendungsperimeter befindet, sollten Sie berücksichtigen, wie Benutzer über das Internet auf Ihre Anwendung zugreifen. Wenn sich der erste Einstiegspunkt in einer AWS Region befindet, ist der Anwendungsperimeter Ihre Amazon Virtual Private Cloud (VPC). Wenn Benutzer über Amazon Route 53 zu Ihrer Anwendung weitergeleitet werden und zuerst über Amazon CloudFront oder auf die Anwendung zugreifen AWS Global Accelerator, beginnt der Anwendungsperimeter am Rand des AWS Netzwerks.
Shield bietet Vorteile bei der DDo S-Erkennung und -Abwehr für alle Anwendungen AWS, auf denen ausgeführt wird, aber die Entscheidungen, die Sie beim Entwurf Ihrer Anwendungsarchitektur treffen, wirken sich auf Ihre DDo S-Resilienz aus. DDoS-Resilienz ist die Fähigkeit Ihrer Anwendung, während eines Angriffs weiterhin innerhalb der erwarteten Parameter zu arbeiten.
Alle AWS Kunden profitieren ohne zusätzliche Kosten vom automatischen Schutz von Shield Standard. Shield Standard schützt vor den häufigsten, am häufigsten auftretenden Netzwerk- und DDo Transport-Layer-S-Angriffen, die auf Ihre Website oder Anwendungen abzielen. Shield Standard trägt zwar zum Schutz aller AWS Kunden bei, Sie profitieren jedoch besonders von Amazon Route 53-Hosting-Zonen, CloudFront Amazon-Distributionen und AWS Global Accelerator Standardbeschleunigern. Diese Ressourcen erhalten umfassenden Verfügbarkeitsschutz vor allen bekannten Angriffen auf Netzwerk- und Transportebene.
# AWS Shield Advanced -Übersicht
AWS Shield Advanced ist ein verwalteter Service, mit dem Sie Ihre Anwendung vor externen Bedrohungen wie DDo S-Angriffen, volumetrischen Bots und Versuchen zur Ausnutzung von Sicherheitslücken schützen können. Für einen höheren Schutz vor Angriffen können Sie AWS Shield Advanced abonnieren.
Wenn Sie Shield Advanced abonnieren und Ihre Ressourcen schützen, bietet Shield Advanced erweiterten DDo S-Angriffsschutz für diese Ressourcen. Der Schutz, den Sie von Shield Advanced erhalten, kann je nach Architektur und Konfiguration variieren. Verwenden Sie die Informationen in diesem Handbuch, um robuste Anwendungen mit Shield Advanced zu erstellen und zu schützen und um zu eskalieren, wenn Sie Hilfe von Experten benötigen.
**Shield Advanced-Abonnements und AWS WAF Kosten**
Ihr Shield Advanced-Abonnement deckt die Kosten für die Nutzung von AWS WAF Standardfunktionen für Ressourcen ab, die Sie mit Shield Advanced schützen. Die AWS WAF Standardgebühren, die durch Ihre Shield Advanced-Schutzmaßnahmen abgedeckt werden, sind die Kosten pro Schutzpaket (Web-ACL), die Kosten pro Regel und der Grundpreis pro Million Anfragen für die Prüfung von Webanfragen, bis zu 1.500 WCUs und bis zur Standardgröße.
Wenn Sie die automatische Abwehr auf Anwendungsebene DDo S von Shield Advanced aktivieren, wird Ihrem Schutzpaket (Web-ACL) eine Regelgruppe hinzugefügt, die 150 Web-ACL-Kapazitätseinheiten (WCUs) verwendet. Diese werden auf die WCU-Nutzung in Ihrem Protection Pack (Web-ACL) WCUs angerechnet. Weitere Informationen finden Sie unter [Automatisierung der Risikominderung auf Anwendungsebene DDo S mit Shield Advanced](ddos-automatic-app-layer-response.md), [Schutz der Anwendungsebene mit der Shield Advanced-Regelgruppe](ddos-automatic-app-layer-response-rg.md) und [Web-ACL-Kapazitätseinheiten (WCUs) in AWS WAF](aws-waf-capacity-units.md).
Ihr Abonnement AWS WAF für Shield Advanced deckt nicht die Nutzung von Ressourcen ab, die Sie nicht mit Shield Advanced schützen. Es deckt auch keine zusätzlichen, nicht standardmäßigen AWS WAF Kosten für geschützte Ressourcen ab. Beispiele für nicht standardmäßige AWS WAF Kosten sind die Kosten für Bot-Kontrolle, für CAPTCHA Regelaktionen, für Websites, die mehr als 1.500 ACLs Benutzer verwenden WCUs, und für die Überprüfung des Anfragetexts, der über die Standardgröße hinausgeht. Die vollständige Liste finden Sie auf der Seite mit den AWS WAF Preisen. Ihr Abonnement für Shield Advanced beinhaltet den Zugriff auf die Layer 7 DDo Anti-S Amazon Managed Rule-Gruppe. Im Rahmen Ihres Abonnements erhalten Sie in einem Kalendermonat bis zu 50 Milliarden Anfragen an geschützte Shield AWS WAF Advanced-Ressourcen. Anfragen über 50 Milliarden werden gemäß der AWS Shield Advanced Preisseite in Rechnung gestellt.
Vollständige Informationen und Preisbeispiele finden Sie unter [Shield Pricing](https://aws.amazon.com/shield/pricing/) and [AWS WAF Pricing](https://aws.amazon.com/waf/pricing/).
**Abrechnung des Shield Advanced-Abonnements**
Wenn Sie ein AWS Channel-Wiederverkäufer sind, wenden Sie sich an Ihr Account-Team, um Informationen und Beratung zu erhalten. Diese Rechnungsinformationen gelten für Kunden, die keine AWS Channel-Wiederverkäufer sind.
Für alle anderen gelten die folgenden Abonnement- und Abrechnungsrichtlinien:
+ Bei Konten, die Mitglieder einer AWS Organizations Organisation sind, werden die Shield Advanced-Abonnements mit dem Zahlerkonto der Organisation in AWS Rechnung gestellt, unabhängig davon, ob das Zahlerkonto selbst abonniert ist.
+ Wenn Sie mehrere Konten abonnieren, die sich in derselben [Kontenfamilie mit AWS Organizations konsolidierter Abrechnung](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html) befinden, deckt ein Abonnementpreis alle abonnierten Konten in der Familie ab. Die Organisation muss Eigentümer all ihrer Ressourcen sein. AWS-Konten
+ Wenn Sie mehrere Konten für mehrere Organisationen abonnieren, können Sie trotzdem eine Abonnementgebühr für alle Organisationen, Konten und Ressourcen zahlen, vorausgesetzt, Sie besitzen alle Konten. Wenden Sie sich an Ihren Kundenbetreuer oder AWS Support und beantragen Sie eine Gebührenbefreiung der AWS Shield Advanced Abonnementgebühren für alle Organisationen außer einer.
Detaillierte Preisinformationen und Beispiele finden Sie unter [AWS Shield Preisgestaltung](https://aws.amazon.com/shield/pricing/).
**Topics**
# Liste der AWS Ressourcen, die AWS Shield Advanced schützen
**Anmerkung**
Shield Advanced-Schutzmaßnahmen sind nur für Ressourcen aktiviert, die Sie ausdrücklich in Shield Advanced angegeben haben oder die Sie durch eine AWS Firewall Manager Shield Advanced-Richtlinie schützen. Shield Advanced schützt Ihre Ressourcen nicht automatisch.
Sie können Shield Advanced für erweiterte Überwachung und Schutz mit den folgenden Ressourcentypen verwenden:
+ CloudFront Amazon-Distributionen. Für CloudFront eine kontinuierliche Bereitstellung schützt Shield Advanced jede Staging-Distribution, die einer geschützten Primärdistribution zugeordnet ist.
+ Gehostete Zonen von Amazon Route 53.
+ AWS Global Accelerator Standardbeschleuniger.
+ Amazon EC2 Elastic IP-Adressen. Shield Advanced schützt die Ressourcen, die geschützten Elastic IP-Adressen zugeordnet sind.
+ EC2 Amazon-Instances durch Zuordnung zu Amazon EC2 Elastic-IP-Adressen.
+ Die folgenden Elastic Load Balancing (ELB) -Load Balancer:
+ Load Balancer für Anwendungen.
+ Classic Load Balancer.
+ Network Load Balancers über Verknüpfungen zu Amazon EC2 Elastic-IP-Adressen.
Weitere Informationen zum Schutz dieser Ressourcentypen finden Sie unter. [Liste der Ressourcen, die AWS Shield Advanced schützen](ddos-protections-by-resource-type.md)
# AWS Shield Advanced Fähigkeiten und Optionen
AWS Shield Advanced Das Abonnement umfasst die folgenden Funktionen und Optionen. Diese ergänzen die DDo S-Erkennungs- und Abwehrfunktionen, die Sie bereits mit AWS erhalten.
+ **AWS WAF Integration** — Shield Advanced verwendet AWS WAF Web ACLs, Regeln und Regelgruppen als Teil seines Schutzes auf Anwendungsebene. Weitere Informationen zu finden Sie AWS WAF unter[Wie AWS WAF funktioniert](how-aws-waf-works.md).
**Anmerkung**
Ihr Shield Advanced-Abonnement deckt die Kosten für die Nutzung von AWS WAF Standardfunktionen für Ressourcen ab, die Sie mit Shield Advanced schützen. Die AWS WAF Standardgebühren, die durch Ihre Shield Advanced-Schutzmaßnahmen abgedeckt werden, sind die Kosten pro Schutzpaket (Web-ACL), die Kosten pro Regel und der Grundpreis pro Million Anfragen für die Prüfung von Webanfragen, bis zu 1.500 WCUs und bis zur Standardgröße.
Wenn Sie die automatische Abwehr auf Anwendungsebene DDo S von Shield Advanced aktivieren, wird Ihrem Schutzpaket (Web-ACL) eine Regelgruppe hinzugefügt, die 150 Web-ACL-Kapazitätseinheiten (WCUs) verwendet. Diese werden auf die WCU-Nutzung in Ihrem Protection Pack (Web-ACL) WCUs angerechnet. Weitere Informationen finden Sie unter [Automatisierung der Risikominderung auf Anwendungsebene DDo S mit Shield Advanced](ddos-automatic-app-layer-response.md), [Schutz der Anwendungsebene mit der Shield Advanced-Regelgruppe](ddos-automatic-app-layer-response-rg.md) und [Web-ACL-Kapazitätseinheiten (WCUs) in AWS WAF](aws-waf-capacity-units.md).
Ihr Abonnement AWS WAF für Shield Advanced deckt nicht die Nutzung von Ressourcen ab, die Sie nicht mit Shield Advanced schützen. Es deckt auch keine zusätzlichen, nicht standardmäßigen AWS WAF Kosten für geschützte Ressourcen ab. Beispiele für nicht standardmäßige AWS WAF Kosten sind die Kosten für Bot-Kontrolle, für CAPTCHA Regelaktionen, für Websites, die mehr als 1.500 ACLs Benutzer verwenden WCUs, und für die Überprüfung des Anfragetexts, der über die Standardgröße hinausgeht. Die vollständige Liste finden Sie auf der Seite mit den AWS WAF Preisen. Ihr Abonnement für Shield Advanced beinhaltet den Zugriff auf die Layer 7 DDo Anti-S Amazon Managed Rule-Gruppe. Im Rahmen Ihres Abonnements erhalten Sie in einem Kalendermonat bis zu 50 Milliarden Anfragen an geschützte Shield AWS WAF Advanced-Ressourcen. Anfragen über 50 Milliarden werden gemäß der AWS Shield Advanced Preisseite in Rechnung gestellt.
Vollständige Informationen und Preisbeispiele finden Sie unter [Shield Pricing](https://aws.amazon.com/shield/pricing/) and [AWS WAF Pricing](https://aws.amazon.com/waf/pricing/).
+ **Automatische Abwehr von Anwendungsschicht DDo S** — Sie können Shield Advanced so konfigurieren, dass es automatisch reagiert, um Angriffe der Anwendungsschicht (Schicht 7) auf Ihre geschützten Ressourcen abzuwehren. Mit automatischer Abwehr erzwingt Shield Advanced eine AWS WAF Ratenbegrenzung für Anfragen aus bekannten DDo S-Quellen und fügt als Reaktion auf erkannte DDo S-Angriffe automatisch benutzerdefinierte AWS WAF Schutzmaßnahmen hinzu und verwaltet diese. Sie können die automatische Abwehr so konfigurieren, dass die Webanfragen, die Teil eines Angriffs sind, gezählt oder blockiert werden.
Weitere Informationen finden Sie unter [Automatisierung der Risikominderung auf Anwendungsebene DDo S mit Shield Advanced](ddos-automatic-app-layer-response.md).
+ **Gesundheitsbasierte Erkennung** — Sie können Amazon Route 53-Zustandsprüfungen mit Shield Advanced als Grundlage für die Erkennung und Abwehr von Ereignissen verwenden. Health Checks überwachen Ihre Anwendung gemäß Ihren Spezifikationen und melden fehlerfrei, wenn Ihre Spezifikationen erfüllt werden, und ungesund, wenn dies nicht der Fall ist. Die Verwendung von Integritätsprüfungen mit Shield Advanced hilft dabei, Fehlalarme zu verhindern und ermöglicht eine schnellere Erkennung und Abwehr, wenn eine geschützte Ressource fehlerhaft ist. Sie können die zustandsbasierte Erkennung für jeden Ressourcentyp außer für gehostete Route 53-Zonen verwenden. Das proaktive Engagement von Shield Advanced ist nur für Ressourcen verfügbar, für die die gesundheitsbasierte Erkennung aktiviert ist.
Weitere Informationen finden Sie unter [Gesundheitsbasierte Erkennung mithilfe von Zustandsprüfungen mit Shield Advanced und Route 53](ddos-advanced-health-checks.md).
+ **Schutzgruppen** — Sie können Schutzgruppen verwenden, um logische Gruppierungen Ihrer geschützten Ressourcen zu erstellen, um die gesamte Gruppe besser erkennen und abwehren zu können. Sie können die Kriterien für die Mitgliedschaft in einer Schutzgruppe so definieren, dass neu geschützte Ressourcen automatisch berücksichtigt werden. Eine geschützte Ressource kann mehreren Schutzgruppen angehören.
Weitere Informationen finden Sie unter [Gruppieren Sie Ihre Schutzmaßnahmen AWS Shield Advanced](ddos-protection-groups.md).
+ **Verbesserter Einblick in DDo S-Ereignisse und -Angriffe** — Shield Advanced bietet Ihnen Zugriff auf erweiterte Echtzeit-Metriken und Berichte für einen umfassenden Einblick in Ereignisse und Angriffe auf Ihre geschützten AWS Ressourcen. Sie können über die Shield Advanced-API und -Konsole sowie über CloudWatch Amazon-Metriken auf diese Informationen zugreifen.
Weitere Informationen finden Sie unter [Einblick in DDo S-Ereignisse mit Shield Advanced](ddos-viewing-events.md).
+ **Zentralisierte Verwaltung der Shield Advanced-Schutzmaßnahmen von AWS Firewall Manager** — Sie können den Firewall Manager verwenden, um den Shield Advanced-Schutz automatisch auf Ihre neuen Konten und Ressourcen anzuwenden und AWS WAF Regeln für Ihr Web bereitzustellen. ACLs Die Shield Advanced-Schutzrichtlinien von Firewall Manager sind für Shield Advanced-Kunden ohne zusätzliche Kosten enthalten. Sie können Ihre Shield Advanced-Überwachungsaktivitäten für Ihre Konten auch zentralisieren, indem Sie den Firewall Manager mit einem Amazon Simple Notification Service (SNS) -Thema oder verwenden. AWS Security Hub CSPM
Weitere Informationen zur Verwendung von Firewall Manager zur Verwaltung von Shield Advanced-Schutzmaßnahmen finden Sie unter [AWS Firewall Manager](fms-chapter.md) und[AWS Shield Advanced Richtlinien im Firewall Manager verwenden](shield-policies.md). Informationen zu den Preisen von Firewall Manager finden Sie unter [AWS Firewall Manager Preise](https://aws.amazon.com/firewall-manager/pricing/).
+ **AWS Shield Response Team (SRT)** — Das SRT verfügt über umfangreiche Erfahrung im Schutz AWS von Amazon.com und seinen Tochtergesellschaften. Als AWS Shield Advanced Kunde können Sie sich jederzeit an das SRT wenden, um Unterstützung bei einem DDo S-Angriff zu erhalten, der die Verfügbarkeit Ihrer Anwendung beeinträchtigt. Sie können auch mit dem SRT zusammenarbeiten, um benutzerdefinierte Abhilfemaßnahmen für Ihre Ressourcen zu erstellen und zu verwalten. Um die Dienste des SRT nutzen zu können, müssen Sie auch den [Business Support Plan oder den [Enterprise Support](https://aws.amazon.com/premiumsupport/enterprise-support/) Plan](https://aws.amazon.com/premiumsupport/business-support/) abonniert haben.
Weitere Informationen finden Sie unter [Verwaltete Reaktion auf DDo S-Ereignisse mit Unterstützung des Shield Response Team (SRT)](ddos-srt-support.md).
+ **Proaktives Engagement** — Bei proaktivem Engagement kontaktiert Sie das Shield Response Team (SRT) direkt, wenn die Amazon Route 53-Zustandsprüfung, die Sie mit Ihrer geschützten Ressource verknüpft haben, während eines von Shield Advanced erkannten Ereignisses fehlerhaft wird. Auf diese Weise können Sie schneller mit Experten in Kontakt treten, wenn die Verfügbarkeit Ihrer Anwendung durch einen vermuteten Angriff beeinträchtigt werden könnte.
Weitere Informationen finden Sie unter [Einrichtung eines proaktiven Engagements für das SRT, um Sie direkt zu kontaktieren](ddos-srt-proactive-engagement.md).
+ **Möglichkeiten zum Kostenschutz** — Shield Advanced bietet einen gewissen Kostenschutz vor Preisspitzen AWS , die durch einen DDo S-Angriff auf Ihre geschützten Ressourcen entstehen könnten. Dies kann die Deckung von Spitzenwerten bei den Gebühren für die ausgehende Datenübertragung (DTO) von Shield Advanced beinhalten. Shield Advanced bietet jeglichen Kostenschutz in Form von Shield Advanced-Servicegutschriften.
Weitere Informationen finden Sie unter [AWS Shield Advanced Nach einem Angriff eine Gutschrift beantragen](ddos-request-service-credit.md).
# Entscheidung, ob zusätzliche Schutzmaßnahmen abonniert AWS Shield Advanced und angewendet werden sollen
Sehen Sie sich die Szenarien in diesem Abschnitt an, um zu entscheiden, welche Konten Sie abonnieren AWS Shield Advanced und wo zusätzliche Schutzmaßnahmen angewendet werden sollten. Mit Shield Advanced zahlen Sie eine monatliche Abonnementgebühr für alle Konten, die unter einem konsolidierten Abrechnungskonto erstellt wurden, zuzüglich Nutzungsgebühren, die auf den übertragenen GB an Daten basieren. Informationen zu den Preisen von Shield Advanced finden Sie unter [AWS Shield Advanced Preise](https://aws.amazon.com/shield/pricing/).
Um eine Anwendung und ihre Ressourcen mit Shield Advanced zu schützen, abonnieren Sie Shield Advanced für die Konten, mit denen die Anwendung verwaltet wird, und fügen dann Schutzmaßnahmen zu den Ressourcen der Anwendung hinzu. Informationen zum Abonnieren von Konten und zum Schutz von Ressourcen finden Sie unter. [Einrichten AWS Shield Advanced](getting-started-ddos.md)
**Shield Advanced-Abonnements und AWS WAF Kosten**
Ihr Shield Advanced-Abonnement deckt die Kosten für die Nutzung von AWS WAF Standardfunktionen für Ressourcen ab, die Sie mit Shield Advanced schützen. Die AWS WAF Standardgebühren, die durch Ihre Shield Advanced-Schutzmaßnahmen abgedeckt werden, sind die Kosten pro Schutzpaket (Web-ACL), die Kosten pro Regel und der Grundpreis pro Million Anfragen für die Prüfung von Webanfragen, bis zu 1.500 WCUs und bis zur Standardgröße.
Wenn Sie die automatische Abwehr auf Anwendungsebene DDo S von Shield Advanced aktivieren, wird Ihrem Schutzpaket (Web-ACL) eine Regelgruppe hinzugefügt, die 150 Web-ACL-Kapazitätseinheiten (WCUs) verwendet. Diese werden auf die WCU-Nutzung in Ihrem Protection Pack (Web-ACL) WCUs angerechnet. Weitere Informationen finden Sie unter [Automatisierung der Risikominderung auf Anwendungsebene DDo S mit Shield Advanced](ddos-automatic-app-layer-response.md), [Schutz der Anwendungsebene mit der Shield Advanced-Regelgruppe](ddos-automatic-app-layer-response-rg.md) und [Web-ACL-Kapazitätseinheiten (WCUs) in AWS WAF](aws-waf-capacity-units.md).
Ihr Abonnement AWS WAF für Shield Advanced deckt nicht die Nutzung von Ressourcen ab, die Sie nicht mit Shield Advanced schützen. Es deckt auch keine zusätzlichen, nicht standardmäßigen AWS WAF Kosten für geschützte Ressourcen ab. Beispiele für nicht standardmäßige AWS WAF Kosten sind die Kosten für Bot-Kontrolle, für CAPTCHA Regelaktionen, für Websites, die mehr als 1.500 ACLs Benutzer verwenden WCUs, und für die Überprüfung des Anfragetexts, der über die Standardgröße hinausgeht. Die vollständige Liste finden Sie auf der Seite mit den AWS WAF Preisen. Ihr Abonnement für Shield Advanced beinhaltet den Zugriff auf die Layer 7 DDo Anti-S Amazon Managed Rule-Gruppe. Im Rahmen Ihres Abonnements erhalten Sie in einem Kalendermonat bis zu 50 Milliarden Anfragen an geschützte Shield AWS WAF Advanced-Ressourcen. Anfragen über 50 Milliarden werden gemäß der AWS Shield Advanced Preisseite in Rechnung gestellt.
Vollständige Informationen und Preisbeispiele finden Sie unter [Shield Pricing](https://aws.amazon.com/shield/pricing/) and [AWS WAF Pricing](https://aws.amazon.com/waf/pricing/).
**Abrechnung des Shield Advanced-Abonnements**
Wenn Sie ein AWS Channel-Wiederverkäufer sind, wenden Sie sich an Ihr Account-Team, um Informationen und Beratung zu erhalten. Diese Rechnungsinformationen gelten für Kunden, die keine AWS Channel-Wiederverkäufer sind.
Für alle anderen gelten die folgenden Abonnement- und Abrechnungsrichtlinien:
+ Bei Konten, die Mitglieder einer AWS Organizations Organisation sind, werden die Shield Advanced-Abonnements mit dem Zahlerkonto der Organisation in AWS Rechnung gestellt, unabhängig davon, ob das Zahlerkonto selbst abonniert ist.
+ Wenn Sie mehrere Konten abonnieren, die sich in derselben [Kontenfamilie mit AWS Organizations konsolidierter Abrechnung](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html) befinden, deckt ein Abonnementpreis alle abonnierten Konten in der Familie ab. Die Organisation muss Eigentümer all ihrer Ressourcen sein. AWS-Konten
+ Wenn Sie mehrere Konten für mehrere Organisationen abonnieren, können Sie trotzdem eine Abonnementgebühr für alle Organisationen, Konten und Ressourcen zahlen, vorausgesetzt, Sie besitzen alle Konten. Wenden Sie sich an Ihren Kundenbetreuer oder AWS Support und beantragen Sie eine Gebührenbefreiung der AWS Shield Advanced Abonnementgebühren für alle Organisationen außer einer.
Detaillierte Preisinformationen und Beispiele finden Sie unter [AWS Shield Preisgestaltung](https://aws.amazon.com/shield/pricing/).
**Identifizierung der zu schützenden Anwendungen**
Erwägen Sie die Implementierung von Shield Advanced-Schutzmaßnahmen für Anwendungen, für die Sie eine der folgenden Voraussetzungen benötigen:
+ Garantierte Verfügbarkeit für die Benutzer der Anwendung.
+ Schneller Zugang zu Experten zur DDo S-Abwehr, falls die Anwendung von einem DDo S-Angriff betroffen ist.
+ Information darüber AWS , dass die Anwendung von einem DDo S-Angriff betroffen sein könnte, und Benachrichtigung Ihrer Sicherheits- oder Betriebsteams über Angriffe AWS und deren Eskalation.
+ Vorhersehbarkeit Ihrer Cloud-Kosten, auch wenn sich ein DDo S-Angriff auf Ihre Nutzung von AWS Diensten auswirkt.
Wenn eine Anwendung oder ihre Ressourcen eines der oben genannten Dinge erfordern, sollten Sie in Erwägung ziehen, Abonnements für die entsprechenden Konten zu erstellen.
**Identifizieren der zu schützenden Ressourcen**
Erwägen Sie, für jedes abonnierte Konto jeder Ressource, die eines der folgenden Merkmale aufweist, einen Shield Advanced-Schutz hinzuzufügen:
+ Die Ressource dient externen Benutzern im Internet.
+ Die Ressource ist im Internet verfügbar und ist auch Teil einer kritischen Anwendung. Berücksichtigen Sie jede gefährdete Ressource, unabhängig davon, ob Sie beabsichtigen, dass Benutzer im Internet auf sie zugreifen.
+ Die Ressource ist durch eine AWS WAF Web-ACL geschützt.
Weitere Informationen zum Erstellen und Verwalten von Schutzmaßnahmen für Ihre Ressourcen finden Sie unter[Ressourcenschutz in AWS Shield Advanced](ddos-resource-protections.md).
Folgen Sie außerdem den Empfehlungen in diesem Handbuch, um sicherzustellen, dass Sie Ihre Anwendung für DDo S-Resilienz konzipieren und dass Sie die Funktionen von Shield Advanced für optimalen Schutz ordnungsgemäß konfiguriert haben.
# Beispiele für DDo S-Angriffe
AWS Shield Advanced bietet erweiterten Schutz vor vielen Arten von Angriffen.
In der folgenden Liste werden einige gängige Angriffsarten beschrieben:
**User Datagram Protocol (UDP) Reflection-Angriff**
Bei UDP-Reflection-Angriffen kann ein Angreifer die Quelle einer Anfrage fälschen und UDP verwenden, um eine umfangreiche Antwort vom Server auszulösen. Der zusätzliche Netzwerkverkehr, der auf die gefälschte, angegriffene IP-Adresse gerichtet ist, kann den Zielserver verlangsamen und legitime Endbenutzer daran hindern, auf die benötigten Ressourcen zuzugreifen.
**TCP-SYN-Flut**
Die Absicht eines TCP-SYN-Flood-Angriffs besteht darin, die verfügbaren Ressourcen eines Systems zu erschöpfen, indem Verbindungen in einem halboffenen Zustand belassen werden. Wenn ein Benutzer eine Verbindung zu einem TCP-Dienst wie einem Webserver herstellt, sendet der Client ein TCP-SYN-Paket. Der Server sendet eine Bestätigung und der Client sendet ebenfalls eine eigene Bestätigung – damit ist der "Dreiwege-Handshake" komplett. Bei einer TCP-SYN-Flood wird die dritte Bestätigung nie zurückgegeben, und der Server wartet auf eine Antwort. Dies kann verhindern, dass andere Benutzer eine Verbindung zum Server aufbauen.
**DNS Query Flood-Angriff**
Bei einer DNS-Abfrageflut verwendet ein Angreifer mehrere DNS-Abfragen, um die Ressourcen eines DNS-Servers zu erschöpfen. AWS Shield Advanced kann dazu beitragen, Schutz vor DNS-Query-Flood-Angriffen auf Route 53-DNS-Server zu bieten.
**HTTP Flood/Cache-Busting-Angriff (Layer 7)**
Bei einer HTTP-Flut, einschließlich `GET` und `POST` Floods, sendet ein Angreifer mehrere HTTP-Anfragen, die anscheinend von einem echten Benutzer der Webanwendung stammen. Cache-Busting-Angriffe zählen zu den HTTP Flood-Angriffen. Sie nutzen Abweichungen in der Abfragezeichenfolge der HTTP-Anforderung, damit die Inhalte nicht aus dem Cache eines Edge-Standorts gelesen werden, und erzwingen so den Inhaltsabruf vom ursprünglichen Webserver. Das wiederum sorgt für eine erhöhte und potenziell schädliche Auslastung des ursprünglichen Webservers.
# Wie AWS Shield erkennt man Ereignisse
AWS betreibt Service-Level-Erkennungssysteme für das AWS Netzwerk und einzelne AWS Dienste, um sicherzustellen, dass diese auch während eines DDo S-Angriffs verfügbar bleiben. Darüber hinaus überwachen Erkennungssysteme auf Ressourcenebene jede einzelne AWS Ressource, um sicherzustellen, dass der Datenverkehr zu der Ressource innerhalb der erwarteten Parameter bleibt. Diese Kombination schützt sowohl die AWS Zielressource als auch die AWS Dienste, indem Schutzmaßnahmen angewendet werden, die bekannte schädliche Pakete verwerfen, potenziell bösartigen Datenverkehr hervorheben und den Datenverkehr von Endbenutzern priorisieren.
Entdeckte Ereignisse erscheinen in Ihren Shield Advanced-Ereigniszusammenfassungen, Angriffsdetails und CloudWatch Amazon-Metriken entweder als Name des DDo S-Angriffsvektors oder als `Volumetric` ob die Bewertung auf dem Verkehrsaufkommen statt auf der Signatur basieren würde. Weitere Informationen zu den Dimensionen des Angriffsvektors, die in der `DDoSDetected` CloudWatch Metrik verfügbar sind, finden Sie unter[AWS Shield Advanced Metriken](shield-metrics.md).
**Topics**
+ [AWS Shield Erkennungslogik für Bedrohungen auf Infrastrukturebene (Schicht 3 und Schicht 4)](ddos-event-detection-infrastructure.md)
+ [Shield Advanced Erkennungslogik für Bedrohungen auf Anwendungsebene (Schicht 7)](ddos-event-detection-application.md)
+ [Shield Advanced Erkennungslogik für mehrere Ressourcen in einer Anwendung](ddos-event-detection-multiple-resources.md)
# AWS Shield Erkennungslogik für Bedrohungen auf Infrastrukturebene (Schicht 3 und Schicht 4)
Auf dieser Seite wird erklärt, wie die Ereigniserkennung für die Infrastrukturschicht (Netzwerk und Transport) funktioniert.
Die Erkennungslogik, die zum Schutz von AWS Zielressourcen vor DDo S-Angriffen in den Infrastrukturebenen (Schicht 3 und Schicht 4) verwendet wird, hängt vom Ressourcentyp ab und davon, ob die Ressource geschützt ist AWS Shield Advanced.
**Erkennung für Amazon CloudFront und Amazon Route 53**
Wenn Sie Ihre Webanwendung mit CloudFront und Route 53 bereitstellen, werden alle Pakete an die Anwendung von einem vollständig integrierten DDo S-Abwehrsystem überprüft, das keine beobachtbare Latenz verursacht. DDoS-Angriffe auf CloudFront Distributionen und auf Route 53 gehostete Zonen werden in Echtzeit abgewehrt. Diese Schutzmaßnahmen gelten unabhängig davon, ob Sie sie verwenden. AWS Shield Advanced
Verwenden CloudFront Sie nach Möglichkeit die bewährte Methode, Route 53 als Einstiegspunkt für Ihre Webanwendung zu verwenden, um DDo S-Ereignisse so schnell wie möglich zu erkennen und zu verhindern.
**Erkennung für AWS Global Accelerator und regionale Dienste**
Die Erkennung auf Ressourcenebene schützt AWS Global Accelerator Standardbeschleuniger und Ressourcen, die in AWS Regionen gestartet werden, wie Classic Load Balancers, Application Load Balancers und Elastic IP-Adressen (). EIPs Diese Ressourcentypen werden im Hinblick auf Datenverkehrserhöhungen überwacht, die auf das Vorliegen eines DDo S-Angriffs hinweisen könnten, für den eine Abwehr erforderlich ist. Jede Minute wird der Verkehr zu jeder AWS Ressource ausgewertet. Wenn der Verkehr zu einer Ressource erhöht ist, werden zusätzliche Prüfungen durchgeführt, um die Kapazität der Ressource zu messen.
Shield führt die folgenden Standardprüfungen durch:
+ **Amazon Elastic Compute Cloud (Amazon EC2) -Instances, EIPs, die an Amazon EC2 EC2-Instances angehängt** sind — Shield ruft Kapazität von der geschützten Ressource ab. Die Kapazität hängt vom Instance-Typ, der Instance-Größe und anderen Faktoren des Ziels ab, z. B. davon, ob die Instance Enhanced Networking verwendet.
+ **Classic Load Balancers und Application Load Balancers** — Shield ruft Kapazität vom Ziel-Load Balancer-Knoten ab.
+ **EIPs an Network Load Balancers angeschlossen** — Shield ruft Kapazität vom Ziel-Load Balancer ab. Die Kapazität ist unabhängig von der Gruppenkonfiguration des Ziel-Load Balancers.
+ **AWS Global Accelerator Standardbeschleuniger** — Shield ruft Kapazität ab, die auf der Endpunktkonfiguration basiert.
Diese Bewertungen beziehen sich auf mehrere Dimensionen des Netzwerkverkehrs, z. B. auf Port und Protokoll. Wenn die Kapazität der Zielressource überschritten wird, platziert Shield eine DDo S-Abwehr. Die von Shield eingeführten Abhilfemaßnahmen werden den DDo S-Verkehr reduzieren, ihn aber möglicherweise nicht beseitigen. Shield kann auch Abhilfemaßnahmen ergreifen, wenn ein Bruchteil der Kapazität der Ressource bei einer Verkehrsdimension überschritten wird, die mit bekannten DDo S-Angriffsvektoren konsistent ist. Shield gewährt dieser Abwehr eine begrenzte Gültigkeitsdauer (TTL), die verlängert wird, solange der Angriff andauert.
**Anmerkung**
Von Shield vorgenommene Abhilfemaßnahmen reduzieren den DDo S-Verkehr, verhindern ihn aber möglicherweise nicht. Sie können Shield um Lösungen wie AWS Network Firewall oder eine On-Host-Firewall erweitern, iptables um zu verhindern, dass Ihre Anwendung Datenverkehr verarbeitet, der für Ihre Anwendung nicht gültig ist oder nicht von legitimen Endbenutzern generiert wurde.
Die erweiterten Schutzmaßnahmen von Shield erweitern die bestehenden Shield-Erkennungsaktivitäten um Folgendes:
+ **Niedrigere Erkennungsschwellen** — Shield Advanced legt Schutzmaßnahmen auf die Hälfte der berechneten Kapazität fest. Auf diese Weise können Angriffe, die langsam zunehmen, schneller abgewehrt und Angriffe, die eine mehrdeutigere volumetrische Signatur aufweisen, eingedämmt werden.
+ **Schutz vor intermittierenden Angriffen** — Shield Advanced platziert Abhilfemaßnahmen mit einer exponentiell steigenden Gültigkeitsdauer (TTL), die auf der Häufigkeit und Dauer der Angriffe basiert. Dadurch bleiben die Abwehrmaßnahmen länger wirksam, wenn eine Ressource häufig angegriffen wird und wenn ein Angriff in kurzen Ausbrüchen erfolgt.
+ **Integritätsbasierte Erkennung** — Wenn Sie eine Route 53-Zustandsprüfung mit einer geschützten Shield Advanced-Ressource verknüpfen, wird der Status der Integritätsprüfung in der Erkennungslogik verwendet. Wenn bei einem erkannten Ereignis die Integritätsprüfung fehlerfrei ist, muss Shield Advanced erst dann darauf vertrauen, dass es sich bei dem Ereignis um einen Angriff handelt, bevor eine Abwehr eingeleitet wird. Wenn der Gesundheitscheck stattdessen fehlerhaft ist, kann Shield Advanced eine Abhilfemaßnahme vornehmen, noch bevor das Vertrauen hergestellt wurde. Diese Funktion hilft dabei, Fehlalarme zu vermeiden und ermöglicht schnellere Reaktionen auf Angriffe, die Ihre Anwendung betreffen. Informationen zu Integritätsprüfungen mit Shield Advanced finden Sie unter[Gesundheitsbasierte Erkennung mithilfe von Zustandsprüfungen mit Shield Advanced und Route 53](ddos-advanced-health-checks.md).
# Shield Advanced Erkennungslogik für Bedrohungen auf Anwendungsebene (Schicht 7)
Auf dieser Seite wird erklärt, wie die Ereigniserkennung für die Anwendungsebene funktioniert.
AWS Shield Advanced bietet die Erkennung von Webanwendungsebenen für geschützte CloudFront Amazon-Distributionen und Application Load Balancers. Wenn Sie diese Ressourcentypen mit Shield Advanced schützen, können Sie Ihrem Schutz eine AWS WAF Web-ACL zuordnen, um die Erkennung der Webanwendungsebene zu aktivieren. Shield Advanced verwendet Anforderungsdaten für die zugehörige Web-ACL und erstellt eine Datenverkehrsbasis für Ihre Anwendung. Die Erkennung von Webanwendungsebenen basiert auf der nativen Integration zwischen Shield Advanced und AWS WAF. Weitere Informationen zum Schutz auf Anwendungsebene, einschließlich der Zuordnung einer AWS WAF Web-ACL zu einer geschützten Shield Advanced-Ressource, finden Sie unter. [Schutz der Anwendungsschicht (Schicht 7) mit AWS Shield Advanced und AWS WAF](ddos-app-layer-protections.md)
Zur Erkennung von Webanwendungsebenen überwacht Shield Advanced den Anwendungsverkehr und vergleicht ihn mit historischen Ausgangsdaten, um nach Anomalien zu suchen. Diese Überwachung deckt das Gesamtvolumen und die Zusammensetzung des Datenverkehrs ab. Während eines DDo S-Angriffs erwarten wir, dass sich sowohl das Volumen als auch die Zusammensetzung des Datenverkehrs ändern werden, und Shield Advanced benötigt bei beiden eine statistisch signifikante Abweichung, um ein Ereignis zu deklarieren.
Shield Advanced führt seine Messungen anhand historischer Zeitfenster durch. Dieser Ansatz reduziert Fehlmeldungen aufgrund legitimer Änderungen des Verkehrsaufkommens oder aufgrund von Änderungen des Datenverkehrs, die einem erwarteten Muster entsprechen, z. B. bei einem Verkauf, der jeden Tag zur gleichen Uhrzeit angeboten wird.
**Anmerkung**
Vermeiden Sie Fehlalarme in Ihren Shield Advanced-Schutzmaßnahmen, indem Sie Shield Advanced Zeit geben, Baselines zu erstellen, die normale, legitime Datenverkehrsmuster darstellen. Shield Advanced beginnt mit der Erfassung von Informationen für seine Baseline, wenn Sie Ihrer geschützten Ressource eine Web-ACL zuordnen. Ordnen Sie Ihrer geschützten Ressource mindestens 24 Stunden vor einem geplanten Ereignis, das zu ungewöhnlichen Mustern im Webverkehr führen könnte, eine Web-ACL zu. Die Erkennung auf Webanwendungsebene von Shield Advanced ist am genauesten, wenn 30 Tage normalen Datenverkehrs beobachtet wurden.
Die Zeit, die Shield Advanced benötigt, um ein Ereignis zu erkennen, hängt davon ab, wie stark sich das Verkehrsaufkommen ändert. Bei Änderungen mit geringerem Volumen beobachtet Shield Advanced den Verkehr über einen längeren Zeitraum, um die Gewissheit zu stärken, dass ein Ereignis eintritt. Bei Änderungen mit höherer Lautstärke erkennt Shield Advanced ein Ereignis schneller und meldet es schneller.
Eine ratenbasierte Regel in Ihrer Web-ACL, unabhängig davon, ob sie von Ihnen oder durch die automatische Abwehr auf Anwendungsebene von Shield Advanced hinzugefügt wurde, kann einen Angriff abwehren, bevor er ein erkennbares Ausmaß erreicht. Weitere Informationen zur automatischen Risikominderung auf Anwendungsebene DDo S finden Sie unter. [Automatisierung der Risikominderung auf Anwendungsebene DDo S mit Shield Advanced](ddos-automatic-app-layer-response.md)
**Anmerkung**
Sie können Ihre Anwendung so einrichten, dass sie bei erhöhtem Traffic oder hoher Auslastung skaliert wird, um sicherzustellen, dass sie nicht durch kleinere Anforderungsfluten beeinträchtigt wird. Mit Shield Advanced sind Ihre geschützten Ressourcen durch einen Kostenschutz abgedeckt. Dies schützt Sie vor unerwarteten Erhöhungen Ihrer Cloud-Rechnung, die als Folge eines DDo S-Angriffs auftreten könnten. Weitere Informationen zum Kostenschutz von Shield Advanced finden Sie unter[AWS Shield Advanced Nach einem Angriff eine Gutschrift beantragen](ddos-request-service-credit.md).
# Shield Advanced Erkennungslogik für mehrere Ressourcen in einer Anwendung
Auf dieser Seite wird erklärt, wie die Ereigniserkennung für mehrere Ressourcen in einer Anwendung funktioniert.
Sie können AWS Shield Advanced Schutzgruppen verwenden, um Sammlungen geschützter Ressourcen zu erstellen, die Teil derselben Anwendung sind. Sie können wählen, welche geschützten Ressourcen in einer Gruppe platziert werden sollen, oder angeben, dass alle Ressourcen desselben Typs als eine Gruppe behandelt werden sollen. Sie können beispielsweise eine Gruppe mit allen Application Load Balancers erstellen. Wenn Sie eine Schutzgruppe erstellen, aggregiert Shield Advanced Detection den gesamten Datenverkehr für die geschützten Ressourcen innerhalb der Gruppe. Dies ist nützlich, wenn Sie über viele Ressourcen verfügen, von denen jede eine geringe Menge an Datenverkehr, aber ein großes aggregiertes Volumen aufweist. Sie können Schutzgruppen auch verwenden, um Anwendungsbasislinien beizubehalten, was bei blaugrünen Bereitstellungen der Fall ist, bei denen der Datenverkehr zwischen geschützten Ressourcen übertragen wird.
Sie können den Datenverkehr in Ihrer Schutzgruppe auf eine der folgenden Arten aggregieren:
+ **Summe** — Diese Aggregation kombiniert den gesamten Datenverkehr zwischen den Ressourcen in der Schutzgruppe. Sie können diese Aggregation verwenden, um sicherzustellen, dass neu erstellte Ressourcen über eine bestehende Basislinie verfügen, und um die Erkennungsempfindlichkeit zu verringern, wodurch Fehlalarme vermieden werden können.
+ **Mittelwert** — Bei dieser Aggregation wird der Durchschnitt des gesamten Datenverkehrs innerhalb der Schutzgruppe verwendet. Sie können diese Aggregation für Anwendungen verwenden, bei denen der Datenverkehr zwischen Ressourcen einheitlich ist, z. B. für Load Balancer.
+ **Max** — Diese Aggregation verwendet den höchsten Traffic aller Ressourcen in der Schutzgruppe. Sie können diese Aggregation verwenden, wenn mehrere Ebenen einer Anwendung in einer Schutzgruppe vorhanden sind. Beispielsweise haben Sie möglicherweise eine Schutzgruppe, die eine CloudFront Distribution, ihren Application Load Balancer Balancer-Ursprung und die Amazon EC2 EC2-Instance-Ziele des Application Load Balancers umfasst.
Sie können Schutzgruppen auch verwenden, um die Geschwindigkeit zu erhöhen, mit der Shield Advanced Abhilfemaßnahmen für Angriffe einsetzt, die auf mehrere mit dem Internet verbundene Elastic IPs - oder AWS Global Accelerator Standardbeschleuniger abzielen. Wenn eine Ressource in einer Schutzgruppe ins Visier genommen wird, stellt Shield Advanced Vertrauen für die anderen Ressourcen in der Gruppe her. Dadurch wird die Erkennung von Shield Advanced in einen Alarmzustand versetzt und der Zeitaufwand für die Erstellung zusätzlicher Schutzmaßnahmen kann reduziert werden.
Weitere Informationen zu Schutzgruppen finden Sie unter[Gruppieren Sie Ihre Schutzmaßnahmen AWS Shield Advanced](ddos-protection-groups.md).
# Wie AWS Shield mindert man Ereignisse
Auf dieser Seite wird vorgestellt, wie die Abwehr von AWS Shield Ereignissen funktioniert.
Die Abhilflogik, die Ihre Anwendung schützt, kann je nach Ihrer Anwendungsarchitektur variieren. Wenn Sie eine Webanwendung mit Amazon CloudFront und Amazon Route 53 schützen, profitieren Sie von Schutzmaßnahmen, die speziell auf Web- und DNS-Anwendungsfälle zugeschnitten sind und den gesamten Datenverkehr für die Services schützen. Wenn der Einstiegspunkt Ihrer Anwendung eine Ressource ist, die in einer AWS Region ausgeführt wird, variiert die Risikominderungslogik je nach Service, Ressourcentyp und Nutzung von. AWS Shield Advanced
AWS DDoS-Minderungssysteme werden von Shield-Technikern entwickelt und sind eng in die AWS Services integriert. Die Techniker berücksichtigen Aspekte Ihrer Architektur wie die Kapazität und den Zustand der Zielressourcen. Die Techniker von Shield überwachen kontinuierlich die Wirksamkeit und Leistung der DDo S-Abwehrsysteme und sind in der Lage, schnell zu reagieren, wenn neue Bedrohungen entdeckt oder erwartet werden.
Sie können Ihre Anwendung so gestalten, dass sie bei erhöhtem Datenverkehr oder hoher Auslastung skaliert wird, um sicherzustellen, dass sie nicht durch kleinere Anforderungsfluten beeinträchtigt wird. Wenn Sie Shield Advanced zum Schutz Ihrer Ressourcen verwenden, sind Sie gegen unerwartete Erhöhungen Ihrer Cloud-Rechnung abgesichert, die als Folge eines DDo S-Angriffs auftreten könnten.
**Maßnahmen zur Minderung der Infrastruktur**
Bei Angriffen auf die Infrastrukturebene sind AWS Shield DDo S-Abwehrsysteme an der AWS Netzwerkgrenze und an AWS Edge-Standorten vorhanden. Die Platzierung mehrerer Ebenen von Sicherheitskontrollen in der gesamten AWS Infrastruktur sorgt für defense-in-depth Ihre Cloud-Anwendungen.
Shield unterhält DDo S-Abwehrsysteme an allen Zugangspunkten aus dem Internet. Wenn Shield einen DDo S-Angriff erkennt, leitet es den Datenverkehr für jeden Eintrittspunkt durch die DDo S-Abwehrsysteme am selben Standort um. Dies führt zu keiner beobachtbaren zusätzlichen Latenz und bietet eine Abwehrkapazität von mehr als 100 TeraBits pro Sekunde (Tbps) in allen Regionen und allen Edge-Standorten. AWS Shield schützt Ihre Ressourcenverfügbarkeit, ohne den Datenverkehr an externe oder entfernte Scrubbing-Center umzuleiten, was die Latenz erhöhen könnte.
+ An der AWS Netzwerkgrenze verhindern DDo S-Abwehrsysteme für jeden AWS Dienst oder jede Ressource Angriffe auf Infrastrukturebene, die aus dem Internet kommen. Die Systeme führen ihre Abhilfemaßnahmen durch, wenn sie von Shield Detection oder von einem Techniker des Shield Response Teams (SRT) gemeldet werden.
+ An AWS Edge-Standorten überprüfen DDo S-Abwehrsysteme kontinuierlich jedes Paket, das an CloudFront Amazon-Distributionen und Amazon Route 53-Hosting-Zonen weitergeleitet wird, unabhängig von ihrer Herkunft. Bei Bedarf wenden die Systeme Schutzmaßnahmen an, die speziell für den Web- und DNS-Verkehr entwickelt wurden. Ein zusätzlicher Vorteil der Verwendung von Amazon CloudFront und Amazon Route 53 zum Schutz Ihrer Webanwendungen besteht darin, dass DDo S-Angriffe sofort abgewehrt werden, ohne dass ein Signal von der Shield-Erkennung erforderlich ist.
**Abwehr auf Anwendungsebene**
Shield Advanced bietet Schutzmaßnahmen auf Webanwendungsebene für die CloudFront Amazon-Distributionen und Application Load Balancer, für die Sie den erweiterten Schutz von Shield aktiviert haben. Wenn Sie den Schutz aktivieren, ordnen Sie der Ressource eine AWS WAF Web-ACL zu, um die Erkennung auf Webanwendungsebene zu aktivieren. Darüber hinaus haben Sie die Möglichkeit, die automatische Abwehr auf Anwendungsebene zu aktivieren, wodurch Shield Advanced angewiesen wird, den Schutz während eines DDo S-Angriffs für Sie zu verwalten.
Shield bietet nur benutzerdefinierte Abwehrmaßnahmen für Angriffe auf Anwendungsebene auf Ressourcen, für die Sie Shield Advanced aktiviert haben, und automatische Abwehr auf Anwendungsebene. Mit automatischer Abwehr erzwingt Shield Advanced eine AWS WAF Ratenbegrenzung für Anfragen aus bekannten DDo S-Quellen und fügt als Reaktion auf erkannte DDo S-Angriffe automatisch benutzerdefinierte AWS WAF Schutzmaßnahmen hinzu und verwaltet diese. Ausführliche Informationen zu Abhilfemaßnahmen dieser Art finden Sie unter. [So verwaltet Shield Advanced die automatische Schadensbegrenzung](ddos-automatic-app-layer-response-behavior.md)
Eine ratenbasierte Regel in Ihrer Web-ACL, unabhängig davon, ob sie von Ihnen oder durch die automatische Abwehr auf Anwendungsebene von Shield Advanced hinzugefügt wurde, kann einen Angriff abwehren, bevor er ein erkennbares Ausmaß erreicht. Weitere Informationen zur Erkennung finden Sie unter. [Shield Advanced Erkennungslogik für Bedrohungen auf Anwendungsebene (Schicht 7)](ddos-event-detection-application.md)
**Topics**
+ [Liste der AWS Shield DDo S-Abwehrfunktionen](ddos-event-mitigation-features.md)
+ [AWS Shield Mitigationslogik für CloudFront und Route 53](ddos-event-mitigation-logic-continuous-inspection.md)
+ [AWS Shield Minderungslogik für Regionen AWS](ddos-event-mitigation-logic-regions.md)
+ [AWS Shield Risikominderungslogik für AWS Global Accelerator Standardbeschleuniger](ddos-event-mitigation-logic-gax.md)
+ [AWS Shield Advanced Schadensbegrenzungslogik für Elastic IPs](ddos-event-mitigation-logic-adv-eip.md)
+ [AWS Shield Advanced Schadensbegrenzungslogik für Webanwendungen](ddos-event-mitigation-logic-adv-web-app.md)
# Liste der AWS Shield DDo S-Abwehrfunktionen
Die Hauptmerkmale von AWS Shield DDo S Mitigation sind die folgenden:
+ **Paketvalidierung** — Dadurch wird sichergestellt, dass jedes geprüfte Paket einer erwarteten Struktur entspricht und für sein Protokoll gültig ist. Zu den unterstützten Protokollvalidierungen gehören IP, TCP (einschließlich Header und Optionen), UDP, ICMP, DNS und NTP.
+ **Zugriffskontrolllisten (ACLs) und Shaper** — Eine ACL bewertet den Datenverkehr anhand bestimmter Attribute und verwirft den entsprechenden Datenverkehr entweder oder ordnet ihn einem Shaper zu. Der Shaper begrenzt die Paketrate für den entsprechenden Datenverkehr und verwirft überschüssige Pakete, um das Volumen einzudämmen, das das Ziel erreicht. AWS Shield Die Techniker des Detection and Shield Response Teams (SRT) können spezielle Ratenzuweisungen für den erwarteten Verkehr und restriktivere Ratenzuweisungen für den Verkehr mit Attributen bereitstellen, die bekannten DDo S-Angriffsvektoren entsprechen. Zu den Attributen, denen eine ACL entsprechen kann, gehören der Port, das Protokoll, die TCP-Flags, die Zieladresse, das Quellland und beliebige Muster in der Paketnutzlast.
+ Bewertung von **Verdachtsfällen** — Dabei wird das Wissen, das Shield über den erwarteten Datenverkehr hat, genutzt, um jedem Paket eine Bewertung zuzuweisen. Paketen, die sich eher an Muster für zweifelsfrei funktionierenden Verkehr halten, wird eine niedrigere Verdachtsbewertung zugewiesen. Die Beobachtung von bekannten schlechten Datenverkehrsattributen kann die Verdachtsquote für ein Paket erhöhen. Wenn es notwendig ist, Pakete mit einer Ratenbegrenzung zu begrenzen, verwirft Shield zuerst Pakete mit höheren Verdachtswerten. Auf diese Weise kann Shield sowohl bekannte als auch Zero-Day-S-Angriffe abwehren und gleichzeitig DDo Fehlalarme vermeiden.
+ **TCP-SYN-Proxy** — Dieser bietet Schutz vor TCP-SYN-Floods, indem TCP-SYN-Cookies gesendet werden, um neue Verbindungen herauszufordern, bevor sie an den geschützten Dienst weitergeleitet werden. Der von Shield DDo S Mitigation bereitgestellte TCP-SYN-Proxy ist zustandslos, was es ihm ermöglicht, die größten bekannten TCP-SYN-Flood-Angriffe abzuwehren, ohne dass eine State-Erschöpfung erreicht wird. Dies wird erreicht, indem AWS Dienste integriert werden, um den Verbindungsstatus zu übergeben, anstatt einen kontinuierlichen Proxy zwischen dem Client und dem geschützten Dienst aufrechtzuerhalten. Der TCP-SYN-Proxy ist derzeit auf Amazon CloudFront und Amazon Route 53 verfügbar.
+ **Ratenverteilung** — Dadurch werden die Shaper-Werte pro Standort kontinuierlich an das Eingangsmuster des Datenverkehrs zu einer geschützten Ressource angepasst. Dadurch wird verhindert, dass der Kundendatenverkehr, der möglicherweise nicht gleichmäßig in das Netzwerk gelangt, begrenzt wird. AWS
# AWS Shield Mitigationslogik für CloudFront und Route 53
Auf dieser Seite wird erklärt, wie Shield DDo S Mitigation kontinuierlich den Verkehr für CloudFront und Route 53 überprüft. Diese Dienste werden von einem weltweit verteilten Netzwerk von AWS Edge-Standorten aus betrieben, die Ihnen umfassenden Zugriff auf die DDo S-Abwehrkapazität von Shield bieten und Ihre Anwendungen von einer Infrastruktur aus bereitstellen, die sich näher an Ihren Endbenutzern befindet.
**Wichtig**
AWS Shield Advanced unterstützt keine CloudFront Mieter.
+ **CloudFront**— Durch Shield DDo S-Abhilfemaßnahmen kann nur Datenverkehr, der für Webanwendungen gültig ist, an den Dienst weitergeleitet werden. Dies bietet automatischen Schutz vor vielen gängigen DDo S-Vektoren, wie z. B. UDP-Reflection-Angriffen.
CloudFront unterhält persistente Verbindungen zu Ihrem Anwendungsursprung, TCP-SYN-Floods werden durch die Integration mit der Shield-TCP-SYN-Proxyfunktion automatisch abgemildert und Transport Layer Security (TLS) wird am Edge beendet. Diese kombinierten Funktionen stellen sicher, dass Ihr Anwendungsursprung nur wohlgeformte Webanfragen empfängt und dass er vor DDo S-Angriffen der unteren Schicht, Verbindungsfluten und TLS-Missbrauch geschützt ist.
CloudFront verwendet eine Kombination aus DNS-Verkehrsrichtung und Anycast-Routing. Diese Techniken verbessern die Widerstandsfähigkeit Ihrer Anwendung, indem sie Angriffe direkt an der Quelle abwehren, Fehler isolieren und den Zugriff auf Kapazitäten sicherstellen, um die größten bekannten Angriffe abzuwehren.
+ **Route 53** — Shield-Schutzmaßnahmen ermöglichen es nur gültigen DNS-Anfragen, den Dienst zu erreichen. Shield verhindert DNS-Abfragefluten mithilfe einer Verdachtsbewertung, bei der bekanntermaßen funktionierende Abfragen priorisiert und Abfragen, die verdächtige oder bekannte S-Angriffsattribute enthalten, depriorisiert werden. DDo
Route 53 verwendet Shuffle-Sharding, um jeder Hosting-Zone einen eindeutigen Satz von vier Resolver-IP-Adressen zur Verfügung zu stellen, sowohl für als auch. IPv4 IPv6 Jede IP-Adresse entspricht einer anderen Teilmenge von Route 53-Standorten. Jede Standortuntergruppe besteht aus autorisierenden DNS-Servern, die sich nur teilweise mit der Infrastruktur einer anderen Teilmenge überschneiden. Dadurch wird sichergestellt, dass eine Benutzerabfrage, falls sie aus irgendeinem Grund fehlschlägt, bei einem erneuten Versuch erfolgreich bearbeitet wird.
Route 53 verwendet Anycast-Routing, um DNS-Abfragen je nach Netzwerknähe an den nächstgelegenen Edge-Standort weiterzuleiten. Anycast fächert den DDo S-Verkehr auch an viele Edge-Standorte weiter, wodurch verhindert wird, dass sich Angriffe auf einen einzigen Standort konzentrieren.
Zusätzlich zur Geschwindigkeit der Schadensbegrenzung bieten Route 53 einen breiten Zugang zu den weltweit verteilten Kapazitäten von Shield. CloudFront Um diese Funktionen zu nutzen, nutzen Sie diese Dienste als Einstiegspunkt für Ihre dynamischen oder statischen Webanwendungen.
Weitere Informationen zur Verwendung von CloudFront und Route 53 zum Schutz von Webanwendungen finden Sie unter [So schützen Sie dynamische Webanwendungen vor DDo S-Angriffen mithilfe von Amazon CloudFront und Amazon Route 53.](https://aws.amazon.com/blogs/security/how-to-protect-dynamic-web-applications-against-ddos-attacks-by-using-amazon-cloudfront-and-amazon-route-53/) Weitere Informationen zur Fehlerisolierung auf Route 53 finden Sie unter [Eine Fallstudie zur globalen Fehlerisolierung](https://aws.amazon.com/blogs/architecture/a-case-study-in-global-fault-isolation/).
# AWS Shield Minderungslogik für Regionen AWS
Auf dieser Seite wird erklärt, wie die Shield-Ereignisabwehrlogik in AWS Regionen funktioniert.
Ressourcen, die in AWS Regionen eingesetzt werden, werden durch AWS Shield DDo S-Minderungssysteme geschützt, die von Shield auf Ressourcenebene erkannt werden. Zu den regionalen Ressourcen gehören Elastic IPs (EIPs), Classic Load Balancers und Application Load Balancers.
Vor der Einführung einer Risikominderung identifiziert Shield die Zielressource und ihre Kapazität. Shield verwendet die Kapazität, um den maximalen Gesamtverkehr zu bestimmen, den seine Abhilfemaßnahmen für die Weiterleitung an die Ressource zulassen sollten. Zugriffskontrolllisten (ACLs) und andere Shaper innerhalb der Abwehr können das zulässige Volumen für bestimmten Datenverkehr verringern, z. B. für Datenverkehr, der bekannten DDo S-Angriffsvektoren entspricht oder von dem nicht erwartet wird, dass er in großem Umfang übertragen wird. Dadurch wird der Umfang des Datenverkehrs, den die Abhilfemaßnahmen für UDP-Reflection-Angriffe oder für TCP-Verkehr mit TCP-SYN- oder FIN-Flags zulassen, weiter begrenzt.
Shield bestimmt die Kapazität und platziert die Abhilfemaßnahmen für jeden Ressourcentyp unterschiedlich.
+ Für eine Amazon EC2 EC2-Instance oder eine EIP, die an eine Amazon EC2 EC2-Instance angehängt ist, berechnet Shield die Kapazität auf der Grundlage des Instance-Typs und anderer Instance-Attribute, z. B. ob für die Instance Enhanced Networking aktiviert ist.
+ Für einen Application Load Balancer oder Classic Load Balancer berechnet Shield die Kapazität individuell für jeden Zielknoten des Load Balancers. DDoS-Angriffsabwehr für diese Ressourcen wird durch eine Kombination aus Shield DDo S-Abwehr und automatischer Skalierung durch den Load Balancer bereitgestellt. Wenn das Shield Response Team (SRT) an einem Angriff gegen eine Application Load Balancer- oder Classic Load Balancer Balancer-Ressource beteiligt ist, kann es die Skalierung als zusätzliche Schutzmaßnahme beschleunigen.
+ Shield berechnet die Kapazität für einige AWS Ressourcen auf der Grundlage der verfügbaren Kapazität der zugrunde liegenden AWS Infrastruktur. Zu diesen Ressourcentypen gehören Network Load Balancer (NLBs) und Ressourcen, die den Verkehr über Gateway Load Balancer weiterleiten oder. AWS Network Firewall
**Anmerkung**
Schützen Sie Ihre Network Load Balancer, indem Sie sie anhängen EIPs , die durch Shield Advanced geschützt sind. Sie können mit SRT zusammenarbeiten, um benutzerdefinierte Abhilfemaßnahmen zu erstellen, die auf dem erwarteten Datenverkehr und der Kapazität der zugrunde liegenden Anwendung basieren.
Wenn Shield eine Risikominderung einführt, werden die anfänglichen Ratenbegrenzungen, die Shield in der Risikominderungslogik definiert, gleichermaßen auf jedes Shield DDo S-Minderungssystem angewendet. Wenn Shield beispielsweise eine Risikominderung mit einem Limit von 100.000 Paketen pro Sekunde (pps) festlegt, werden zunächst 100.000 pps an jedem Standort zugelassen. Anschließend aggregiert Shield kontinuierlich Messwerte zur Risikominderung, um den tatsächlichen Verkehrsanteil zu ermitteln, und verwendet dieses Verhältnis, um das Ratenlimit für jeden Standort anzupassen. Auf diese Weise werden Fehlalarme verhindert und sichergestellt, dass die Maßnahmen nicht zu großzügig sind.
# AWS Shield Risikominderungslogik für AWS Global Accelerator Standardbeschleuniger
Auf dieser Seite wird erklärt, wie die Shield-Ereignisabwehrlogik für AWS Global Accelerator Standardbeschleuniger funktioniert. Durch Shield-Schutzmaßnahmen kann nur gültiger Datenverkehr die Listener-Endpunkte eines Global Accelerator-Standardbeschleunigers erreichen.
Standardbeschleuniger werden weltweit eingesetzt und stellen Ihnen IP-Adressen zur Verfügung, mit denen Sie den Datenverkehr an AWS Ressourcen in jeder Region weiterleiten können. AWS Die Ratenbegrenzungen, die Shield für eine Global-Accelerator-Minderung durchsetzt, basieren auf den Kapazitäten der Ressourcen, zu denen der Standard-Accelerator den Verkehr weiterleitet. Shield setzt Abhilfemaßnahmen ein, wenn der Gesamtverkehr die festgelegte Rate überschreitet, und auch, wenn ein Bruchteil dieser Rate für bekannte DDo S-Vektoren überschritten wird.
Wenn Sie einen Standard-Accelerator konfigurieren, definieren Sie Endpunktgruppen für jede AWS Region, in die Sie den Datenverkehr für Ihre Anwendung weiterleiten. Wenn Shield eine Risikominderung platziert, berechnet es die Kapazität jeder Endpunktgruppe und aktualisiert die Ratenlimits für jedes Shield DDo S-Minderungssystem entsprechend. Die Rate variiert je nach Standort und basiert auf Annahmen von Shield darüber, wie der Verkehr vom Internet zu Ihren AWS Ressourcen geleitet wird. Die Kapazität für eine Endpunktgruppe wird berechnet als die Anzahl der Ressourcen in der Gruppe multipliziert mit der niedrigsten Kapazität für jede Ressource in der Gruppe. In regelmäßigen Abständen berechnet Shield die Kapazität für Ihre Anwendung neu und aktualisiert die Ratenlimits nach Bedarf.
**Anmerkung**
Die Verwendung von Verkehrswahlen zur Änderung des Prozentsatzes des Datenverkehrs, der an eine Endpunktgruppe geleitet wird, ändert nichts daran, wie Shield die Ratenlimits berechnet oder an seine DDo S-Abwehrsysteme verteilt. Wenn Sie Traffic Dials verwenden, konfigurieren Sie Ihre Endpunktgruppen so, dass sie sich in Bezug auf Ressourcentyp und -menge gegenseitig spiegeln. Dadurch wird sichergestellt, dass die von Shield berechnete Kapazität repräsentativ für die Ressourcen ist, die den Datenverkehr für Ihre Anwendung bereitstellen.
Weitere Informationen zu Endpunktgruppen und Verkehrswahlen in Global Accelerator finden Sie unter [Endpunktgruppen in AWS Global Accelerator Standard-Beschleunigern](https://docs.aws.amazon.com/global-accelerator/latest/dg/about-endpoint-groups.html).
# AWS Shield Advanced Schadensbegrenzungslogik für Elastic IPs
Auf dieser Seite wird erklärt, wie die Shield-Ereignisabwehrlogik für Elastic IPs mit AWS Shield Advanced funktioniert. Wenn Sie eine Elastic IP (EIP) mit schützen AWS Shield Advanced, verbessert Shield Advanced die Schutzmaßnahmen, die Shield während eines DDo S-Ereignisses einleitet.
Shield Advanced DDo S-Abwehrsysteme replizieren die Network ACL (NACL) -Konfiguration für das öffentliche Subnetz, dem die EIP zugeordnet ist. Wenn Ihre NACL beispielsweise so konfiguriert ist, dass sie den gesamten UDP-Verkehr blockiert, führt Shield Advanced diese Regel mit den von Shield festgelegten Abhilfemaßnahmen zusammen.
Diese zusätzliche Funktionalität kann Ihnen helfen, Verfügbarkeitsrisiken aufgrund von Datenverkehr zu vermeiden, der für Ihre Anwendung nicht gültig ist. Sie können sie auch verwenden NACLs , um einzelne Quell-IP-Adressen oder CIDR-Bereiche für Quell-IP-Adressen zu blockieren. Dies kann ein nützliches Tool zur Abwehr von DDo S-Angriffen sein, die nicht verteilt werden. Außerdem können Sie damit ganz einfach Ihre eigenen Zulassungslisten verwalten oder IP-Adressen blockieren, die nicht mit Ihrer Anwendung kommunizieren sollen, ohne auf das Eingreifen von AWS Technikern angewiesen zu sein.
# AWS Shield Advanced Schadensbegrenzungslogik für Webanwendungen
AWS Shield Advanced wird verwendet AWS WAF , um Angriffe auf Webanwendungsebene abzuwehren. AWS WAF ist in Shield Advanced ohne zusätzliche Kosten enthalten.
**Standardschutz auf Anwendungsebene**
Wenn Sie eine CloudFront Amazon-Distribution oder einen Application Load Balancer mit Shield Advanced schützen, können Sie Shield Advanced verwenden, um Ihrer geschützten Ressource eine AWS WAF Web-ACL zuzuordnen, sofern Ihnen noch keine zugeordnet ist. Wenn Sie noch keine Web-ACL konfiguriert haben, können Sie mit dem Shield Advanced-Konsolenassistenten eine erstellen und ihr eine ratenbasierte Regel hinzufügen. Eine ratenbasierte Regel begrenzt die Anzahl der Anfragen pro Fünf-Minuten-Zeitfenster für jede IP-Adresse und bietet so grundlegenden Schutz vor einer Flut von Anfragen auf Webanwendungsebene. Sie können die Rate so konfigurieren, dass sie bei 10 beginnt. Weitere Informationen finden Sie unter [Schutz der Anwendungsebene mit AWS WAF Web ACLs und Shield Advanced](ddos-app-layer-web-ACL-and-rbr.md).
Sie können den AWS WAF Dienst auch zur Verwaltung der Web-ACL verwenden. Auf diese Weise können Sie die Web-ACL-Konfiguration erweitern AWS WAF, um beispielsweise bestimmte Webanforderungskomponenten auf Übereinstimmungen oder Muster zu überprüfen, benutzerdefinierte Anfragen- und Antwortbehandlungen hinzuzufügen und Abgleiche mit der Geolokalisierung des Absenders der Anfrage durchzuführen. Weitere Informationen zu AWS WAF Regeln finden Sie unter. [AWS WAF Regeln](waf-rules.md)
**Automatische Schadensbegrenzung auf Anwendungsebene**
Um den Schutz zu verbessern, aktivieren Sie die automatische Abwehr auf Anwendungsebene mit Shield Advanced. Mit dieser Option behält Shield Advanced eine Regel zur AWS WAF Geschwindigkeitsbegrenzung für Anfragen von bekannten DDo S-Quellen bei und bietet benutzerdefinierte Abhilfemaßnahmen für erkannte DDo S-Angriffe.
Wenn Shield Advanced einen Angriff auf eine geschützte Ressource erkennt, versucht es, eine Angriffssignatur zu identifizieren, die den Angriffsverkehr vom normalen Verkehr zu Ihrer Anwendung isoliert. Shield Advanced bewertet die identifizierte Angriffssignatur anhand der historischen Verkehrsmuster für die angegriffene Ressource sowie für jede andere Ressource, die derselben Web-ACL zugeordnet ist.
Wenn Shield Advanced feststellt, dass die Angriffssignatur nur den Datenverkehr isoliert, der am DDo S-Angriff beteiligt ist, implementiert es die Signatur in AWS WAF Regeln innerhalb der zugehörigen Web-ACL. Sie können Shield Advanced anweisen, Abhilfemaßnahmen zu platzieren, die nur den Datenverkehr zählen, mit dem sie übereinstimmen, oder ihn blockieren, und Sie können die Einstellung jederzeit ändern. Wenn Shield Advanced feststellt, dass seine Schadensbegrenzungsregeln nicht mehr benötigt werden, werden sie aus der Web-ACL entfernt. Weitere Informationen zur Abwehr von Ereignissen auf Anwendungsebene finden Sie unter. [Automatisierung der Risikominderung auf Anwendungsebene DDo S mit Shield Advanced](ddos-automatic-app-layer-response.md)
Weitere Informationen zu Schutzmaßnahmen auf Anwendungsebene von Shield Advanced finden Sie unter[Schutz der Anwendungsschicht (Schicht 7) mit AWS Shield Advanced und AWS WAF](ddos-app-layer-protections.md).
# Aufbau grundlegender DDo S-resistenter Architekturen mit Shield Advanced
Auf dieser Seite wird die Resilienz von Distributed Denial of Service (DDoS) erklärt und zwei Beispielarchitekturen vorgestellt.
DDoS-Resilienz ist die Fähigkeit Ihrer Anwendungsarchitektur, DDo S-Angriffen standzuhalten und gleichzeitig legitimen Endbenutzern zu dienen. Eine Anwendung, die sehr widerstandsfähig ist, kann während eines Angriffs verfügbar bleiben, ohne dass sich dies auf Leistungskennzahlen wie Fehler oder Latenz auswirkt. In diesem Abschnitt werden einige gängige Beispielarchitekturen vorgestellt und beschrieben, wie die DDo S-Erkennungs- und Abwehrfunktionen, die von AWS Shield Advanced bereitgestellt werden, verwendet werden können, um ihre DDo S-Resilienz zu erhöhen.
In den Beispielarchitekturen in diesem Abschnitt werden die AWS Services hervorgehoben, die die größten Vorteile der DDo S-Resilienz für Ihre bereitgestellten Anwendungen bieten. Zu den Vorteilen der hervorgehobenen Dienste gehören die folgenden:
+ **Zugriff auf weltweit verteilte Netzwerkkapazitäten** — Die Services Amazon CloudFront und Amazon Route 53 bieten Ihnen Zugriff auf Internet- und DDo S-Abwehrkapazitäten im gesamten AWS globalen Edge-Netzwerk. AWS Global Accelerator Dies ist nützlich, um größere volumetrische Angriffe abzuwehren, die eine Größenordnung von Terabit erreichen können. Sie können Ihre Anwendung in jeder AWS Region ausführen und diese Dienste nutzen, um die Verfügbarkeit zu schützen und die Leistung für Ihre legitimen Benutzer zu optimieren.
+ **Schutz vor DDo Layer-S-Angriffsvektoren für** Webanwendungen — DDo Layer-S-Angriffe auf Webanwendungen lassen sich am besten mit einer Kombination aus Anwendungsskala und einer Web Application Firewall (WAF) abwehren. Shield Advanced verwendet Protokolle zur Inspektion von Webanfragen AWS WAF , um Anomalien zu erkennen, die entweder automatisch oder durch Zusammenarbeit mit dem AWS Shield Response Team (SRT) behoben werden können. Automatische Risikominderung ist durch bereitgestellte AWS WAF ratenbasierte Regeln und auch durch die automatische Abwehr auf Anwendungsebene DDo S von Shield Advanced verfügbar.
Lesen Sie sich nicht nur diese Beispiele durch, sondern überprüfen Sie auch die geltenden Best Practices unter [AWS Best](https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency) Practices for S Resiliency und befolgen Sie diese. DDo
**Topics**
+ [Beispiel für eine Shield Advanced DDo S-Resilienzarchitektur für gängige Webanwendungen](ddos-resiliency-example-web.md)
+ [Beispiel für eine Shield Advanced DDo S-Resilienzarchitektur für TCP- und UDP-Anwendungen](ddos-resiliency-example-tcp-udp.md)
# Beispiel für eine Shield Advanced DDo S-Resilienzarchitektur für gängige Webanwendungen
Diese Seite enthält eine Beispielarchitektur für die Maximierung der Widerstandsfähigkeit gegen DDo S-Angriffe mit Webanwendungen. AWS
Sie können in jeder AWS Region eine Webanwendung erstellen und durch die Erkennungs- und Abwehrfunktionen, die in der Region zur AWS Verfügung stehen, automatischen DDo S-Schutz erhalten.
Dieses Beispiel bezieht sich auf Architekturen, die Benutzer mithilfe von Ressourcen wie Classic Load Balancers, Application Load Balancers, Network Load Balancers, AWS Marketplace-Lösungen oder Ihrer eigenen Proxyschicht zu einer Webanwendung weiterleiten. Sie können die DDo S-Resilienz verbessern, indem Sie Amazon Route 53-Hosting-Zonen, CloudFront Amazon-Distributionen und das AWS WAF Web ACLs zwischen diesen Webanwendungsressourcen und Ihren Benutzern einfügen. Diese Einfügungen können den Ursprung der Anwendung verschleiern, Anfragen näher an Ihren Endbenutzern bearbeiten und eine Flut von Anfragen auf Anwendungsebene erkennen und verhindern. Anwendungen, die Ihren Benutzern statische oder dynamische Inhalte mit CloudFront und Route 53 bereitstellen, werden durch ein integriertes, vollständig integriertes DDo S-Abwehrsystem geschützt, das Angriffe auf Infrastrukturebene in Echtzeit abwehrt.
Mit diesen architektonischen Verbesserungen können Sie dann Ihre von Route 53 gehosteten Zonen und Ihre CloudFront Distributionen mit Shield Advanced schützen. Wenn Sie CloudFront Distributionen schützen, fordert Shield Advanced Sie auf, AWS WAF Webanwendungen zuzuordnen ACLs und ratenbasierte Regeln für sie zu erstellen. Außerdem haben Sie die Möglichkeit, automatische Abwehr auf Anwendungsebene DDo S oder proaktives Engagement zu aktivieren. Proaktives Engagement und automatische Risikominderung auf Anwendungsebene DDo S verwenden Route 53-Zustandsprüfungen, die Sie der Ressource zuordnen. Weitere Informationen zu diesen Optionen finden Sie unter [Ressourcenschutz in AWS Shield Advanced](ddos-resource-protections.md).
Das folgende Referenzdiagramm zeigt diese robuste DDo S-Architektur für eine Webanwendung.
![\[Das Diagramm zeigt ein Rechteck mit dem Titel AWS cloud und links davon eine Benutzergruppe. Innerhalb des Wolkenrechtecks befinden sich zwei weitere Rechtecke nebeneinander. Das linke Rechteck ist betitelt AWS Shield Advanced und das rechte Rechteck hat einen TitelVPC. Das linke AWS Shield Advanced Dreieck enthält drei vertikal gestapelte AWS Symbole. Von oben nach unten lauten die Symbole Amazon Route 53 CloudFront, Amazon und AWS WAF. Das Symbol für CloudFront hat Pfeile, die zum und vom Symbol für führen AWS WAF. Die Benutzergruppe hat einen waagerechten Pfeil, der sich teilt und auf die Symbole für Route 53 und CloudFront zeigt. Rechts neben dem Shield Advanced-Rechteck enthält das VPC-Rechteck zwei nebeneinander liegende Symbole. Von links nach rechts sind diese Symbole Elastic Load Balancing und Amazon Elastic Compute Cloud. Das CloudFront Symbol hat einen waagerechten Pfeil, der zum Elastic Load Balancing Balancing-Symbol führt. Das Elastic Load Balancing Balancing-Symbol hat einen waagerechten Pfeil, der zum Amazon EC2-Symbol führt. Benutzeranfragen werden also an Route 53 und CloudFront gesendet. CloudFront interagiert mit dem Load Balancer AWS WAF und sendet auch Anfragen an diesen weiter, der wiederum Anfragen an Amazon EC2 sendet.\]](http://docs.aws.amazon.com/de_de/waf/latest/developerguide/images/shield-resilient-web-app-arch.png)
Dieser Ansatz bietet Ihrer Webanwendung unter anderem folgende Vorteile:
+ Schutz vor häufig genutzten Angriffen der Infrastrukturschicht (Layer 3 und Layer 4) DDo S ohne Verzögerung bei der Erkennung. Wenn eine Ressource häufig angegriffen wird, führt Shield Advanced außerdem Schutzmaßnahmen für längere Zeiträume durch. Shield Advanced verwendet auch den aus Network ACLs (NACLs) abgeleiteten Anwendungskontext, um unerwünschten Datenverkehr weiter flussaufwärts zu blockieren. Dadurch werden Fehler näher an ihrer Quelle isoliert und die Auswirkungen auf legitime Benutzer minimiert.
+ Schutz vor TCP-SYN-Floods. Die DDo S-Abwehrsysteme, die in Route 53 integriert sind und eine TCP-SYN-Proxyfunktion AWS Global Accelerator bieten, die neue Verbindungsversuche abwehrt und nur legitimen Benutzern dient. CloudFront
+ Schutz vor Angriffen auf DNS-Anwendungsebene, da Route 53 für die Bereitstellung autorisierender DNS-Antworten verantwortlich ist.
+ Schutz vor Fluten von Anfragen auf Webanwendungsebene. Die ratenbasierte Regel, die Sie in Ihrer AWS WAF Web-ACL konfigurieren, blockiert Quellen IPs , wenn sie mehr Anfragen senden, als die Regel zulässt.
+ Automatische Risikominderung auf Anwendungsebene DDo S für Ihre CloudFront Distributionen, wenn Sie diese Option aktivieren. Bei der automatischen DDo S-Abwehr behält Shield Advanced eine ratenbasierte Regel in der zugehörigen AWS WAF Web-ACL der Distribution bei, die das Volumen der Anfragen aus bekannten DDo S-Quellen begrenzt. Wenn Shield Advanced ein Ereignis erkennt, das sich auf den Zustand Ihrer Anwendung auswirkt, erstellt, testet und verwaltet es außerdem automatisch Abhilferegeln in der Web-ACL.
+ Proaktive Zusammenarbeit mit dem Shield Response Team (SRT), wenn Sie diese Option aktivieren. Wenn Shield Advanced ein Ereignis erkennt, das sich auf den Zustand Ihrer Anwendung auswirkt, reagiert das SRT und setzt sich anhand der von Ihnen angegebenen Kontaktinformationen proaktiv mit Ihren Sicherheits- oder Betriebsteams in Verbindung. Das SRT analysiert Muster in Ihrem Datenverkehr und kann Ihre AWS WAF Regeln aktualisieren, um den Angriff zu blockieren.
# Beispiel für eine Shield Advanced DDo S-Resilienzarchitektur für TCP- und UDP-Anwendungen
Dieses Beispiel zeigt eine robuste DDo S-Architektur für TCP- und UDP-Anwendungen in einer AWS Region, die Amazon Elastic Compute Cloud (Amazon EC2) -Instances oder Elastic IP (EIP) -Adressen verwendet.
Sie können diesem allgemeinen Beispiel folgen, um die DDo S-Resilienz für die folgenden Anwendungstypen zu verbessern:
+ TCP- oder UDP-Anwendungen. Zum Beispiel Anwendungen, die für Spiele, IoT und Voice over IP verwendet werden.
+ Webanwendungen, die statische IP-Adressen benötigen oder Protokolle verwenden, die Amazon CloudFront nicht unterstützt. Beispielsweise benötigt Ihre Anwendung möglicherweise IP-Adressen, die Ihre Benutzer zu ihren Firewall-Zulassungslisten hinzufügen können und die nicht von anderen AWS Kunden verwendet werden.
Sie können die DDo S-Resilienz für diese Anwendungstypen verbessern, indem Sie Amazon Route 53 und AWS Global Accelerator einführen. Diese Dienste können Benutzer zu Ihrer Anwendung weiterleiten und sie können Ihrer Anwendung statische IP-Adressen zur Verfügung stellen, die per Anycast über das AWS globale Edge-Netzwerk weitergeleitet werden. Die Standardbeschleuniger von Global Accelerator können die Benutzerlatenz um bis zu 60% verbessern. Wenn Sie über eine Webanwendung verfügen, können Sie Anforderungsfluten auf der Webanwendungsebene erkennen und verhindern, indem Sie die Anwendung auf einem Application Load Balancer ausführen und den Application Load Balancer anschließend mit einer AWS WAF Web-ACL schützen.
Nachdem Sie Ihre Anwendung erstellt haben, schützen Sie Ihre Route 53-Hosting-Zonen, Global Accelerator-Standardbeschleuniger und alle Application Load Balancer mit Shield Advanced. Wenn Sie Ihre Application Load Balancer schützen, können Sie ihnen AWS WAF Web-basierte Regeln zuordnen ACLs und ratenbasierte Regeln für sie erstellen. Sie können den proaktiven Umgang mit dem SRT sowohl für Ihre Global Accelerator-Standardbeschleuniger als auch für Ihre Application Load Balancer konfigurieren, indem Sie neue oder bestehende Route 53-Zustandsprüfungen zuordnen. Weitere Informationen zu den Optionen finden Sie unter. [Ressourcenschutz in AWS Shield Advanced](ddos-resource-protections.md)
Das folgende Referenzdiagramm zeigt ein Beispiel für eine robuste DDo S-Architektur für TCP- und UDP-Anwendungen.
![\[Das Diagramm zeigt Benutzer, die mit Route 53 und mit einer AWS Global Accelerator verbunden sind. Der Accelerator ist mit einem Elastic Load Balancing Balancing-Symbol verbunden, das durch AWS Shield Advanced und geschützt ist AWS WAF. Das Elastic Load Balancing selbst ist mit einer Amazon EC2 EC2-Instance verbunden. Diese Elastic Load Balancing Balancing-Instance und die Amazon EC2 EC2-Instance befinden sich in Region 1. Die AWS Global Accelerator ist auch direkt mit einer anderen Amazon EC2 EC2-Instance verbunden, die sich nicht hinter einer geschützten Elastic Load Balancing Balancing-Instance befindet. Diese zweite Amazon EC2 EC2-Instance befindet sich in Region n.\]](http://docs.aws.amazon.com/de_de/waf/latest/developerguide/images/shield-resilient-tcp-udp-app-arch.png)
Zu den Vorteilen, die dieser Ansatz für Ihre Anwendung bietet, gehören die folgenden:
+ Schutz vor den größten bekannten Angriffen auf die Infrastrukturschicht (Layer 3 und Layer 4) DDo S. Wenn das Volumen eines Angriffs zu einer Überlastung im Vorfeld führt AWS, wird der Fehler näher an seiner Quelle isoliert und hat nur minimale Auswirkungen auf Ihre legitimen Benutzer.
+ Schutz vor Angriffen auf DNS-Anwendungsebene, da Route 53 für die Bereitstellung autorisierender DNS-Antworten verantwortlich ist.
+ Wenn Sie über eine Webanwendung verfügen, bietet dieser Ansatz Schutz vor einer Flut von Anfragen auf der Webanwendungsebene. Die ratenbasierte Regel, die Sie in Ihrer AWS WAF Web-ACL konfigurieren, blockiert Quellen, IPs während diese mehr Anfragen senden, als die Regel zulässt.
+ Proaktive Zusammenarbeit mit dem Shield Response Team (SRT), wenn Sie diese Option für berechtigte Ressourcen aktivieren möchten. Wenn Shield Advanced ein Ereignis erkennt, das sich auf den Zustand Ihrer Anwendung auswirkt, reagiert das SRT und setzt sich anhand der von Ihnen angegebenen Kontaktinformationen proaktiv mit Ihren Sicherheits- oder Betriebsteams in Verbindung.
# Shield Advanced mit anderen kombinieren AWS-Services
Sie können Shield Advanced verwenden, um Ihre Ressourcen in vielen Szenarien zu schützen. In einigen Fällen sollten Sie jedoch andere Dienste verwenden oder andere Dienste mit Shield Advanced kombinieren, um den besten Schutz zu bieten. Im Folgenden finden Sie Beispiele dafür, wie Sie Shield Advanced oder andere AWS Dienste verwenden können, um Ihre Ressourcen zu schützen.
| Ziel | Empfohlene Services | Zugehörige Servicedokumentation |
| --- | --- | --- |
| Schützen Sie eine Webanwendung und RESTful APIs vor einem DDo S-Angriff | Shield Advanced schützt eine CloudFront Amazon-Distribution und einen Application Load Balancer | [Elastic Load Balancing Balancing-Dokumentation](https://docs.aws.amazon.com/elasticloadbalancing/), [ CloudFront Amazon-Dokumentation](https://docs.aws.amazon.com/cloudfront/) |
| Schützt eine TCP-basierte Anwendung vor einem S-Angriff DDo | Shield Advanced schützt einen AWS Global Accelerator Standardbeschleuniger, der an eine Elastic IP-Adresse angeschlossen ist | [AWS Global Accelerator Dokumentation](https://docs.aws.amazon.com/global-accelerator/), [Elastic Load Balancing Balancing-Dokumentation](https://docs.aws.amazon.com/elasticloadbalancing/) |
| Schützt einen UDP-basierten Spieleserver vor einem S-Angriff DDo | Shield Advanced schützt eine EC2 Amazon-Instance, die an eine Elastic IP-Adresse angeschlossen ist | [Amazon Elastic Compute Cloud-Dokumentation](https://docs.aws.amazon.com/ec2/) |
Wenn Sie beispielsweise Shield Advanced verwenden, um eine Elastic IP-Adresse zu schützen, schützt Shield Advanced die damit verbundene Ressource. Während eines Angriffs verteilt Shield Advanced Ihr Netzwerk automatisch ACLs bis zur AWS Netzwerkgrenze. Wenn ACLs sich Ihr Netzwerk an der Netzwerkgrenze befindet, kann Shield Advanced Schutz vor größeren DDo S-Ereignissen bieten. In der Regel ACLs werden Netzwerke in der Nähe Ihrer EC2 Amazon-Instances innerhalb Ihrer Amazon VPC eingesetzt. Die Netzwerk-ACL kann Angriffe nur so groß abwehren, wie Ihre Amazon VPC und Instance handhaben können. Wenn die mit Ihrer EC2 Amazon-Instance verbundene Netzwerkschnittstelle bis zu 10 Gbit/s verarbeiten kann, werden Volumes über 10 Gbit/s langsamer und blockieren möglicherweise den Datenverkehr zu dieser Instance. Während eines Angriffs befördert Shield Advanced Ihre Netzwerk-ACL bis AWS an die Grenze, wodurch mehrere Terabyte an Datenverkehr verarbeitet werden können. Ihre Netzwerk-ACL kann Schutz für Ihre Ressource weit über die typische Kapazität Ihres Netzwerks hinaus bieten. [Weitere Informationen zum Netzwerk finden Sie ACLs unter Netzwerk. ACLs](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_ACLs.html)
# Einrichten AWS Shield Advanced
Dieses Tutorial führt Sie durch die ersten Schritte mit der AWS Shield Advanced Verwendung der Shield Advanced-Konsole.
**Anmerkung**
Shield Advanced erfordert ein Abonnement, AWS Shield Standard aber nicht. Die von Shield Standard bereitgestellten Schutzmaßnahmen stehen allen AWS Kunden kostenlos zur Verfügung.
Shield Advanced bietet fortschrittlichen DDo S-Erkennungs- und Mitigationsschutz für Angriffe auf Netzwerkschicht (Schicht 3), Transportschicht (Schicht 4) und Anwendungsebene (Schicht 7). Weitere Informationen zu Shield Advanced finden Sie unter[AWS Shield Advanced -Übersicht](ddos-advanced-summary.md).
Die AWS technische Community hat ein Beispiel für einen automatisierten Prozess zur Konfiguration von Shield Advanced unter Verwendung der Infrastructure-as-Code-Tools (IaC) AWS CloudFormation und Terraform veröffentlicht. Sie können diese Lösung verwenden AWS Firewall Manager , wenn Ihre Konten Teil einer Organisation in sind AWS Organizations und wenn Sie andere Ressourcentypen außer Amazon Route 53 oder schützen AWS Global Accelerator. Informationen zu dieser Option finden Sie im Code-Repository unter [aws-samples/ aws-shield-advanced-one-click-deployment und im Tutorial unter [One-Click-Bereitstellung](https://youtu.be/LCA3FwMk_QE)](https://github.com/aws-samples/aws-shield-advanced-one-click-deployment) von Shield Advanced.
**Anmerkung**
Es ist wichtig, dass Sie Shield Advanced vor einem Distributed Denial of Service (DDoS) -Ereignis vollständig konfigurieren. Schließen Sie die Konfiguration ab, um sicherzustellen, dass Ihre Anwendung geschützt ist und dass Sie bereit sind, zu reagieren, falls Ihre Anwendung von einem DDo S-Angriff betroffen ist.
Führen Sie die folgenden Schritte nacheinander aus, um mit Shield Advanced zu beginnen.
**Contents**
+ [Abonnieren AWS Shield Advanced](enable-ddos-prem.md)
+ [Hinzufügen und Konfigurieren von Ressourcenschutzmaßnahmen mit Shield Advanced](ddos-choose-resources.md)
+ [Konfiguration von Schutzmaßnahmen auf Anwendungsschicht (Schicht 7) DDo mit AWS WAF](ddos-get-started-web-acl-rbr.md)
+ [Konfiguration der gesundheitsbasierten Erkennung für Ihren Schutz mit Shield Advanced und Route 53](ddos-get-started-health-checks.md)
+ [Konfiguration von Alarmen und Benachrichtigungen mit Shield Advanced und Amazon SNS](ddos-get-started-create-alarms.md)
+ [Überprüfung und Fertigstellung Ihrer Schutzkonfiguration in Shield Advanced](ddos-get-started-review-and-configure.md)
+ [Einrichtung der AWS Shield Response Team (SRT) -Unterstützung für DDo S Event Response](authorize-srt.md)
+ [Ein DDo S-Dashboard in erstellen CloudWatch und CloudWatch Alarme einstellen](deploy-waf-dashboard.md)
# Abonnieren AWS Shield Advanced
Auf dieser Seite wird erklärt, wie Sie Ihre Konten bei Shield Advanced abonnieren, um den Dienst nutzen zu können.
Sie müssen Shield Advanced für jeden abonnieren AWS-Konto , den Sie schützen möchten. Sie müssen Shield Standard nicht abonnieren.
**Abrechnung des Shield Advanced-Abonnements**
Wenn Sie ein AWS Channel-Wiederverkäufer sind, wenden Sie sich an Ihr Account-Team, um Informationen und Beratung zu erhalten. Diese Rechnungsinformationen gelten für Kunden, die keine AWS Channel-Wiederverkäufer sind.
Für alle anderen gelten die folgenden Abonnement- und Abrechnungsrichtlinien:
+ Bei Konten, die Mitglieder einer AWS Organizations Organisation sind, werden die Shield Advanced-Abonnements mit dem Zahlerkonto der Organisation in AWS Rechnung gestellt, unabhängig davon, ob das Zahlerkonto selbst abonniert ist.
+ Wenn Sie mehrere Konten abonnieren, die sich in derselben [Kontenfamilie mit AWS Organizations konsolidierter Abrechnung](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html) befinden, deckt ein Abonnementpreis alle abonnierten Konten in der Familie ab. Die Organisation muss Eigentümer all ihrer Ressourcen sein. AWS-Konten
+ Wenn Sie mehrere Konten für mehrere Organisationen abonnieren, können Sie trotzdem eine Abonnementgebühr für alle Organisationen, Konten und Ressourcen zahlen, vorausgesetzt, Sie besitzen alle Konten. Wenden Sie sich an Ihren Kundenbetreuer oder AWS Support und beantragen Sie eine Gebührenbefreiung der AWS Shield Advanced Abonnementgebühren für alle Organisationen außer einer.
Detaillierte Preisinformationen und Beispiele finden Sie unter [AWS Shield Preisgestaltung](https://aws.amazon.com/shield/pricing/).
**Erwägen Sie die Vereinfachung von Abonnements mit AWS Firewall Manager**
Wenn Ihre Konten Teil einer Organisation sind, empfehlen wir Ihnen, diese Option zu verwenden AWS Firewall Manager , um Ihre Abonnements und Schutzmaßnahmen für die Organisation zu automatisieren. Firewall Manager unterstützt alle geschützten Ressourcentypen mit Ausnahme von Amazon Route 53 und AWS Global Accelerator. Informationen zur Verwendung von Firewall Manager finden Sie unter [AWS Firewall Manager](fms-chapter.md) und[AWS Firewall Manager AWS Shield Advanced Richtlinien einrichten](getting-started-fms-shield.md).
Wenn Sie Firewall Manager nicht verwenden, abonnieren und fügen Sie für jedes Konto mit zu schützenden Ressourcen Schutzmaßnahmen hinzu. Gehen Sie dabei wie folgt vor.
**Um ein Konto zu abonnieren AWS Shield Advanced**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die AWS WAF & Shield-Konsole unter [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. Wählen Sie in der **AWS Shield**Navigationsleiste **Erste Schritte** aus. Wählen **Sie Shield Advanced abonnieren**.
1. Lesen **Sie auf der Seite Shield Advanced abonnieren** die einzelnen Bestimmungen der Vereinbarung und aktivieren Sie dann alle Kontrollkästchen, um anzugeben, dass Sie die Bedingungen akzeptieren. Bei Konten in einer konsolidierten Fakturierungsfamilie müssen Sie den Bedingungen für jedes Konto zustimmen.
**Wichtig**
Wenn Sie ein Abonnement abgeschlossen haben, müssen Sie sich an uns wenden [AWS Support](https://console.aws.amazon.com/support), um das Abonnement zu kündigen.
[Um die automatische Verlängerung für Ihr Abonnement zu deaktivieren, müssen Sie den Shield-API-Vorgang [UpdateSubscription](https://docs.aws.amazon.com/waf/latest/DDOSAPIReference/API_UpdateSubscription.html)oder den CLI-Befehl update-subscription verwenden.](https://docs.aws.amazon.com/cli/latest/reference/shield/update-subscription.html)
Wählen **Sie Shield Advanced abonnieren**. Dadurch abonniert Ihr Konto Shield Advanced und aktiviert den Dienst.
Ihr Konto ist abonniert. Führen Sie die folgenden Schritte aus, um die Ressourcen Ihres Kontos mit Shield Advanced zu schützen.
**Anmerkung**
Shield Advanced schützt Ihre Ressourcen nicht automatisch, nachdem Sie sich angemeldet haben. Sie müssen die Ressourcen angeben, die Shield Advanced schützen soll.
# Hinzufügen und Konfigurieren von Ressourcenschutzmaßnahmen mit Shield Advanced
Diese Seite enthält Anweisungen zum Hinzufügen und Konfigurieren von Schutzmaßnahmen für Ihre Ressourcen.
Shield Advanced schützt nur die Ressourcen, die Sie entweder über Shield Advanced oder in einer Firewall Manager Shield Advanced-Richtlinie angeben. Es schützt nicht automatisch die Ressourcen eines abonnierten Kontos.
**Anmerkung**
Wenn Sie zu Ihrem AWS Firewall Manager Schutz eine Shield Advanced-Richtlinie verwenden, müssen Sie diesen Schritt nicht ausführen. Sie konfigurieren die Richtlinie mit den zu schützenden Ressourcentypen, und Firewall Manager fügt automatisch Schutzmaßnahmen zu Ressourcen hinzu, die in den Geltungsbereich der Richtlinie fallen.
Wenn Sie den Firewall Manager nicht verwenden, gehen Sie für jedes Konto, das über zu schützende Ressourcen verfügt, die folgenden Verfahren durch.
**Um die Ressourcen auszuwählen, die mit Shield Advanced geschützt werden sollen**
1. Wählen Sie auf der Seite **zur Bestätigung des Abonnements des vorherigen Verfahrens oder auf der Seite **Geschützte Ressourcen oder **Übersicht** die Option Zu schützende Ressourcen** hinzufügen** aus.
1. Geben Sie **auf der Seite Ressourcen auswählen, die mit Shield Advanced geschützt** werden sollen, **unter Region und Ressourcentypen angeben** die Regions- und Ressourcentypspezifikationen für die Ressourcen an, die Sie schützen möchten. Sie können Ressourcen in mehreren Regionen schützen, indem Sie **Alle Regionen** auswählen, und Sie können die Auswahl auf globale Ressourcen einschränken, indem Sie **Global** auswählen. Sie können alle Ressourcentypen abwählen, die Sie nicht schützen möchten. Informationen zum Schutz Ihrer Ressourcentypen finden Sie unter. [Liste der Ressourcen, die AWS Shield Advanced schützen](ddos-protections-by-resource-type.md)
1. Wählen Sie **Ressourcen laden** aus. Shield Advanced füllt den Abschnitt **Ressourcen auswählen** mit den AWS Ressourcen, die Ihren Kriterien entsprechen.
1. Im Bereich **Ressourcen auswählen** können Sie die Ressourcenliste filtern, indem Sie eine Zeichenfolge eingeben, nach der in den Ressourcenlisten gesucht werden soll.
Wählen Sie die Ressourcen aus, die Sie schützen möchten.
1. **Wenn Sie den von Ihnen erstellten Shield Advanced-Schutzmaßnahmen Tags hinzufügen möchten, geben Sie diese im Abschnitt Tags an.** Informationen zum Markieren von AWS Ressourcen finden Sie unter [Arbeiten mit dem Tag-Editor](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/tag-editor.html).
1. Wählen Sie **Protect with Shield Advanced**. Dadurch werden die Ressourcen um Shield Advanced-Schutzmaßnahmen erweitert.
Fahren Sie mit den Bildschirmen des Konsolenassistenten fort, um die Konfiguration Ihres Ressourcenschutzes abzuschließen.
**Topics**
+ [Konfiguration von Schutzmaßnahmen auf Anwendungsschicht (Schicht 7) DDo mit AWS WAF](ddos-get-started-web-acl-rbr.md)
+ [Konfiguration der gesundheitsbasierten Erkennung für Ihren Schutz mit Shield Advanced und Route 53](ddos-get-started-health-checks.md)
+ [Konfiguration von Alarmen und Benachrichtigungen mit Shield Advanced und Amazon SNS](ddos-get-started-create-alarms.md)
+ [Überprüfung und Fertigstellung Ihrer Schutzkonfiguration in Shield Advanced](ddos-get-started-review-and-configure.md)
# Konfiguration von Schutzmaßnahmen auf Anwendungsschicht (Schicht 7) DDo mit AWS WAF
Diese Seite enthält Anweisungen zur Konfiguration des Schutzes auf Anwendungsebene mit dem AWS WAF Internet. ACLs
Um eine Ressource auf Anwendungsebene zu schützen, verwendet Shield Advanced eine AWS WAF Web-ACL mit einer ratenbasierten Regel als Ausgangspunkt. AWS WAF ist eine Firewall für Webanwendungen, mit der Sie die HTTP- und HTTPS-Anfragen überwachen können, die an Ihre Ressourcen auf Anwendungsebene weitergeleitet werden, und mit der Sie den Zugriff auf Ihre Inhalte anhand der Eigenschaften der Anfragen steuern können. Eine ratenbasierte Regel begrenzt das Datenverkehrsvolumen auf der Grundlage Ihrer Anforderungsaggregationskriterien und bietet so einen grundlegenden DDo S-Schutz für Ihre Anwendung. Weitere Informationen erhalten Sie unter [Wie AWS WAF funktioniert](how-aws-waf-works.md) und [Verwendung ratenbasierter Regelanweisungen in AWS WAF](waf-rule-statement-type-rate-based.md).
Sie können optional auch die automatische Abwehr von Shield Advanced auf Anwendungsebene DDo S aktivieren, um Shield Advanced-Ratenbegrenzungsanfragen von bekannten DDo S-Quellen zu erhalten und automatisch vorfallspezifische Schutzmaßnahmen für Sie bereitzustellen.
**Wichtig**
Wenn Sie Ihren Shield Advanced-Schutz AWS Firewall Manager mithilfe einer Shield Advanced-Richtlinie verwalten, können Sie den Schutz auf Anwendungsebene hier nicht verwalten. Sie müssen sie in Ihrer Firewall Manager Shield Advanced-Richtlinie verwalten.
**Shield Advanced-Abonnements und AWS WAF Kosten**
Ihr Shield Advanced-Abonnement deckt die Kosten für die Nutzung von AWS WAF Standardfunktionen für Ressourcen ab, die Sie mit Shield Advanced schützen. Die AWS WAF Standardgebühren, die durch Ihre Shield Advanced-Schutzmaßnahmen abgedeckt werden, sind die Kosten pro Schutzpaket (Web-ACL), die Kosten pro Regel und der Grundpreis pro Million Anfragen für die Prüfung von Webanfragen, bis zu 1.500 WCUs und bis zur Standardgröße.
Wenn Sie die automatische Abwehr auf Anwendungsebene DDo S von Shield Advanced aktivieren, wird Ihrem Schutzpaket (Web-ACL) eine Regelgruppe hinzugefügt, die 150 Web-ACL-Kapazitätseinheiten (WCUs) verwendet. Diese werden auf die WCU-Nutzung in Ihrem Protection Pack (Web-ACL) WCUs angerechnet. Weitere Informationen finden Sie unter [Automatisierung der Risikominderung auf Anwendungsebene DDo S mit Shield Advanced](ddos-automatic-app-layer-response.md), [Schutz der Anwendungsebene mit der Shield Advanced-Regelgruppe](ddos-automatic-app-layer-response-rg.md) und [Web-ACL-Kapazitätseinheiten (WCUs) in AWS WAF](aws-waf-capacity-units.md).
Ihr Abonnement AWS WAF für Shield Advanced deckt nicht die Nutzung von Ressourcen ab, die Sie nicht mit Shield Advanced schützen. Es deckt auch keine zusätzlichen, nicht standardmäßigen AWS WAF Kosten für geschützte Ressourcen ab. Beispiele für nicht standardmäßige AWS WAF Kosten sind die Kosten für Bot-Kontrolle, für CAPTCHA Regelaktionen, für Websites, die mehr als 1.500 ACLs Benutzer verwenden WCUs, und für die Überprüfung des Anfragetexts, der über die Standardgröße hinausgeht. Die vollständige Liste finden Sie auf der Seite mit den AWS WAF Preisen. Ihr Abonnement für Shield Advanced beinhaltet den Zugriff auf die Layer 7 DDo Anti-S Amazon Managed Rule-Gruppe. Im Rahmen Ihres Abonnements erhalten Sie in einem Kalendermonat bis zu 50 Milliarden Anfragen an geschützte Shield AWS WAF Advanced-Ressourcen. Anfragen über 50 Milliarden werden gemäß der AWS Shield Advanced Preisseite in Rechnung gestellt.
Vollständige Informationen und Preisbeispiele finden Sie unter [Shield Pricing](https://aws.amazon.com/shield/pricing/) and [AWS WAF Pricing](https://aws.amazon.com/waf/pricing/).
**So konfigurieren Sie DDo Layer-7-S-Schutzmaßnahmen für eine Region**
Shield Advanced bietet Ihnen die Möglichkeit, die Layer 7 DDo S-Abwehr für jede Region zu konfigurieren, in der sich Ihre ausgewählten Ressourcen befinden. Wenn Sie Schutzmaßnahmen in mehreren Regionen hinzufügen, führt Sie der Assistent für jede Region durch das folgende Verfahren.
1. Auf der Seite ** DDoLayer-7-S-Schutzmaßnahmen konfigurieren** werden alle Ressourcen aufgeführt, die noch keiner Web-ACL zugeordnet sind. Wählen Sie für jede dieser Optionen entweder eine vorhandene Web-ACL aus oder erstellen Sie eine neue Web-ACL. Für jede Ressource, der bereits eine Web-ACL zugeordnet ist, können Sie die Web-ACL ändern, ACLs indem Sie zuerst die Verknüpfung mit der aktuellen URL aufheben. AWS WAF Weitere Informationen finden Sie unter [Schutz einer Ressource zuordnen oder deren Verknüpfung aufheben AWS](web-acl-associating-aws-resource.md).
Für Websites ACLs , denen noch keine ratenbasierte Regel zur Verfügung steht, werden Sie vom Konfigurationsassistenten aufgefordert, eine hinzuzufügen. Eine ratenbasierte Regel begrenzt den Datenverkehr von IP-Adressen, wenn diese eine große Anzahl von Anfragen senden. Ratenbasierte Regeln schützen Ihre Anwendung vor einer Flut von Webanfragen und können Warnmeldungen über plötzliche Datenverkehrsspitzen ausgeben, die auf einen möglichen S-Angriff hinweisen könnten. DDo Fügen Sie einer Web-ACL eine ratenbasierte Regel hinzu, indem **Sie auf Ratenbegrenzungsregel hinzufügen klicken und dann ein Ratenlimit und eine Regelaktion** angeben. Sie können zusätzliche Schutzmaßnahmen in der Web-ACL über konfigurieren. AWS WAF
Informationen zur Verwendung von Web ACLs - und ratenbasierten Regeln in Ihren Shield Advanced-Schutzmaßnahmen, einschließlich zusätzlicher Konfigurationsoptionen für ratenbasierte Regeln, finden Sie unter. [Schutz der Anwendungsebene mit AWS WAF Web ACLs und Shield Advanced](ddos-app-layer-web-ACL-and-rbr.md)
1. Wenn Sie möchten, dass Shield Advanced ** DDo DDoS-Angriffe** auf Ihre Ressourcen auf Anwendungsebene automatisch abwehrt, wählen Sie **Aktivieren** und wählen Sie dann die AWS WAF Regelaktion aus, die Shield Advanced in seinen benutzerdefinierten Regeln verwenden soll. Diese Einstellung gilt für das gesamte Internet ACLs für die Ressourcen, die Sie in dieser Assistentensitzung verwalten.
Mit der automatischen Abwehr von Anwendungsschicht DDo S verwaltet Shield Advanced eine ratenbasierte Regel in der AWS WAF Web-ACL der Ressource, die das Volumen der Anfragen aus bekannten DDo S-Quellen begrenzt. Darüber hinaus vergleicht Shield Advanced aktuelle Verkehrsmuster mit historischen Verkehrsbasislinien, um Abweichungen zu erkennen, die auf einen DDo S-Angriff hinweisen könnten. Wenn Shield Advanced einen DDo S-Angriff erkennt, reagiert es darauf, indem es benutzerdefinierte AWS WAF Reaktionsregeln erstellt, auswertet und einsetzt. Sie geben an, ob die benutzerdefinierten Regeln Angriffe in Ihrem Namen zählen oder blockieren.
**Anmerkung**
Die automatische Abwehr auf Anwendungsebene DDo S funktioniert nur mit Schutzpaketen (Web ACLs), die mit der neuesten Version von AWS WAF (v2) erstellt wurden.
Weitere Informationen zur automatischen Abwehr von Anwendungsschicht DDo S mit Shield Advanced, einschließlich Vorbehalte und bewährten Methoden für die Verwendung dieser Funktion, finden Sie unter. [Automatisierung der Risikominderung auf Anwendungsebene DDo S mit Shield Advanced](ddos-automatic-app-layer-response.md)
1. Wählen Sie **Weiter** aus. Der Konsolenassistent wechselt zur Seite zur systembasierten Erkennung.
# Konfiguration der gesundheitsbasierten Erkennung für Ihren Schutz mit Shield Advanced und Route 53
Diese Seite enthält Anweisungen zur Konfiguration von Shield Advanced für die Verwendung von gesundheitsbasierter Erkennung. Dies kann dazu beitragen, die Reaktionsfähigkeit und Genauigkeit bei der Erkennung und Abwehr von Angriffen zu verbessern.
Gut konfigurierte Zustandsprüfungen sind für die genaue Erkennung von Ereignissen unerlässlich. Sie können die zustandsbasierte Erkennung für jeden Ressourcentyp mit Ausnahme von Route 53-Hosting-Zonen konfigurieren.
Um die gesundheitsbasierte Erkennung zu verwenden, definieren Sie eine Zustandsprüfung für Ihre Ressource in Route 53 und verknüpfen Sie die Zustandsprüfung dann mit Ihrem Shield Advanced-Schutz. Es ist wichtig, dass die von Ihnen konfigurierte Zustandsprüfung den Zustand der Ressource genau widerspiegelt. Informationen und Beispiele für die Konfiguration von Integritätsprüfungen zur Verwendung mit Shield Advanced finden Sie unter[Gesundheitsbasierte Erkennung mithilfe von Zustandsprüfungen mit Shield Advanced und Route 53](ddos-advanced-health-checks.md).
Für den proaktiven Engagement-Support des Shield Response Teams (SRT) sind Gesundheitschecks erforderlich. Informationen zu proaktivem Engagement finden Sie unter[Einrichtung eines proaktiven Engagements für das SRT, um Sie direkt zu kontaktieren](ddos-srt-proactive-engagement.md).
**Anmerkung**
Gesundheitschecks müssen als fehlerfrei gemeldet werden, wenn Sie sie mit Ihren Shield Advanced-Schutzmaßnahmen verknüpfen.
**Um die gesundheitsbasierte Erkennung zu konfigurieren**
1. Wählen Sie unter **Associated Health Check (Zugehörige Zustandsprüfung)** die ID der Zustandsprüfung aus, die Sie der Schutzvorkehrung zuordnen möchten.
**Anmerkung**
Wenn Sie die benötigte Zustandsprüfung nicht sehen, rufen Sie die Route 53-Konsole auf und überprüfen Sie die Zustandsprüfung und ihre ID. Weitere Informationen finden Sie unter [Erstellen und Aktualisieren von Zustandsprüfungen](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating.html).
1. Wählen Sie **Weiter** aus. Der Konsolenassistent wechselt zur Seite mit Alarmen und Benachrichtigungen.
# Konfiguration von Alarmen und Benachrichtigungen mit Shield Advanced und Amazon SNS
Diese Seite enthält Anweisungen zur optionalen Konfiguration von Amazon Simple Notification Service-Benachrichtigungen für erkannte CloudWatch Amazon-Alarme und ratenbasierte Regelaktivitäten. Sie können diese verwenden, um Benachrichtigungen zu erhalten, wenn Shield ein Ereignis auf einer geschützten Ressource erkennt oder wenn ein in einer ratenbasierten Regel konfiguriertes Ratenlimit überschritten wird.
Informationen zu Shield CloudWatch Advanced-Metriken finden Sie unter[AWS Shield Advanced Metriken](shield-metrics.md). Informationen zu Amazon SNS finden Sie im [Amazon Simple Notification Service Developer Guide](https://docs.aws.amazon.com/sns/latest/dg/).
**Um Alarme und Benachrichtigungen zu konfigurieren**
1. Wählen Sie die Amazon SNS SNS-Themen aus, für die Sie eine Benachrichtigung wünschen. Sie können ein einzelnes Amazon SNS SNS-Thema für alle geschützten Ressourcen und ratenbasierten Regeln verwenden, oder Sie können verschiedene Themen wählen, die auf Ihre Organisation zugeschnitten sind. Sie können beispielsweise ein SNS-Thema für jedes Team erstellen, das für die Reaktion auf Vorfälle für eine bestimmte Gruppe von Ressourcen verantwortlich ist.
1. Wählen Sie **Weiter** aus. Der Konsolenassistent wechselt zur Seite mit der Überprüfung des Ressourcenschutzes.
# Überprüfung und Fertigstellung Ihrer Schutzkonfiguration in Shield Advanced
**Um Ihre Einstellungen zu überprüfen und abzuschließen**
1. **Überprüfen Sie auf der Seite DDo S-Minderung und Sichtbarkeit überprüfen und konfigurieren** Ihre Einstellungen. Um Änderungen vorzunehmen, wählen Sie in dem Bereich, den Sie ändern möchten, die Option **Bearbeiten** aus. Dadurch kehren Sie zur entsprechenden Seite im Konsolenassistenten zurück. Nehmen Sie Ihre Änderungen vor und klicken Sie dann auf den folgenden Seiten auf **Weiter**, bis Sie zur Seite ** DDoS-Minderung und Sichtbarkeit überprüfen und konfigurieren** zurückkehren.
1. Wählen Sie **Konfiguration beenden** aus. Auf der Seite **Geschützte Ressourcen** werden Ihre neu geschützten Ressourcen aufgeführt.
# Einrichtung der AWS Shield Response Team (SRT) -Unterstützung für DDo S Event Response
Diese Seite enthält Anweisungen zur Einrichtung des Shield Response Team (SRT) -Supports.
Das SRT umfasst Sicherheitsingenieure, die sich auf DDo S Event Response spezialisiert haben. Sie können optional Berechtigungen hinzufügen, die es dem SRT ermöglichen, während eines DDo S-Events Ressourcen in Ihrem Namen zu verwalten. Darüber hinaus können Sie das SRT so konfigurieren, dass es proaktiv mit Ihnen Kontakt aufnimmt, falls die Route 53-Zustandsprüfungen, die mit Ihren geschützten Ressourcen verknüpft sind, während eines erkannten Ereignisses fehlerhaft sind. Diese beiden Erweiterungen Ihres Schutzes ermöglichen eine schnellere Reaktion auf S-Ereignisse. DDo
**Anmerkung**
Um die Dienste des Shield Response Teams (SRT) nutzen zu können, müssen Sie den [Business Support Plan oder den [Enterprise Support](https://aws.amazon.com/premiumsupport/enterprise-support/) Plan](https://aws.amazon.com/premiumsupport/business-support/) abonniert haben.
Das SRT kann AWS WAF Anforderungsdaten und Protokolle bei Ereignissen auf Anwendungsebene überwachen, um anomalen Datenverkehr zu identifizieren. Sie können dabei helfen, benutzerdefinierte AWS WAF Regeln zu erstellen, um schädliche Datenverkehrsquellen einzudämmen. Bei Bedarf kann das SRT architektonische Empfehlungen aussprechen, damit Sie Ihre Ressourcen besser an den Empfehlungen ausrichten können. AWS
Weitere Informationen zum SRT finden Sie unter. [Verwaltete Reaktion auf DDo S-Ereignisse mit Unterstützung des Shield Response Team (SRT)](ddos-srt-support.md)
**Um dem SRT Berechtigungen zu erteilen**
1. Wählen Sie auf der **Übersichtsseite** der AWS Shield Konsole unter ** AWS SRT-Unterstützung konfigurieren die Option SRT-Zugriff** **bearbeiten** aus. Die **Zugriffsseite für das AWS Shield Response Team (SRT) bearbeiten** wird geöffnet.
1. Wählen Sie für die **Einstellung für den SRT-Zugriff** eine der folgenden Optionen aus:
+ **Gewähren Sie dem SRT keinen Zugriff auf mein Konto** — Shield entfernt alle Berechtigungen, die Sie dem SRT zuvor für den Zugriff auf Ihr Konto und Ihre Ressourcen erteilt haben.
+ **Eine neue Rolle für das SRT erstellen, um auf mein Konto zuzugreifen** — Shield erstellt eine Rolle, die dem Service Principal`drt.shield.amazonaws.com`, der das SRT darstellt, vertraut, und fügt ihm die verwaltete Richtlinie hinzu. `AWSShieldDRTAccessPolicy` Die verwaltete Richtlinie ermöglicht es dem SRT, in Ihrem Namen AWS WAF API-Aufrufe zu tätigen AWS Shield Advanced und auf Ihre Protokolle zuzugreifen. AWS WAF Für weitere Informationen über die verwaltete Richtlinie siehe [AWS verwaltete Richtlinie: AWSShield DRTAccess Richtlinie](shd-security-iam-awsmanpol.md#shd-security-iam-awsmanpol-AWSShieldDRTAccessPolicy).
+ **Wählen Sie eine bestehende Rolle für das SRT aus, um auf meine Konten zuzugreifen**. Für diese Option müssen Sie die Konfiguration der Rolle in AWS Identity and Access Management (IAM) wie folgt ändern:
+ Hängen Sie die verwaltete Richtlinie `AWSShieldDRTAccessPolicy` an die Rolle an. Diese verwaltete Richtlinie ermöglicht es dem SRT, in Ihrem Namen AWS WAF API-Aufrufe zu tätigen AWS Shield Advanced und auf Ihre Protokolle zuzugreifen. AWS WAF Für weitere Informationen über die verwaltete Richtlinie siehe [AWS verwaltete Richtlinie: AWSShield DRTAccess Richtlinie](shd-security-iam-awsmanpol.md#shd-security-iam-awsmanpol-AWSShieldDRTAccessPolicy). Informationen zum Anhängen der verwalteten Richtlinie an Ihre Rolle finden Sie unter IAM-Richtlinien [anhängen und trennen](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html).
+ Ändern Sie die Rolle, um dem Service-Prinzipal `drt.shield.amazonaws.com` zu vertrauen. Dies ist der Dienstprinzipal, der die SRT repräsentiert. Weitere Informationen finden Sie unter [IAM-JSON-Richtlinienelemente: Prinzipal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html).
1. Wählen Sie **Speichern**, um Ihre Änderungen zu speichern.
Weitere Informationen darüber, wie Sie dem SRT Zugriff auf Ihre Schutzmaßnahmen und Daten gewähren, finden Sie unter. [Zugriff für das SRT gewähren](ddos-srt-access.md)
**Um den proaktiven Einsatz von SRT zu ermöglichen**
1. Wählen Sie auf der **Übersichtsseite** der AWS Shield Konsole unter **Proaktive Interaktion und Kontakte** im Bereich Kontakte die Option **Bearbeiten** aus.
Geben Sie auf der Seite **Kontakte bearbeiten** die Kontaktinformationen der Personen ein, die das SRT für proaktive Interaktionen kontaktieren soll.
Wenn Sie mehr als einen Kontakt angeben, geben Sie in den **Anmerkungen** an, unter welchen Umständen jeder Kontakt verwendet werden soll. Geben Sie die Namen der primären und sekundären Kontaktpersonen an und geben Sie die Verfügbarkeitszeiten und Zeitzonen für jeden Kontakt an.
Beispiele für Kontaktnotizen:
+ Dies ist eine Hotline, die rund um die Uhr besetzt ist. Bitte arbeiten Sie mit dem antwortenden Analysten zusammen und er wird die entsprechende Person für das Gespräch finden.
+ Bitte kontaktieren Sie mich, wenn die Hotline nicht innerhalb von 5 Minuten antwortet.
1. Wählen Sie **Speichern**.
Die **Übersichtsseite** enthält die aktualisierten Kontaktinformationen.
1. Wählen Sie die **Funktion „Proaktive Interaktion bearbeiten“**, dann „**Aktivieren**“ und anschließend „**Speichern**“, um die proaktive Interaktion zu aktivieren.
Weitere Informationen zu proaktivem Engagement finden Sie unter[Einrichtung eines proaktiven Engagements für das SRT, um Sie direkt zu kontaktieren](ddos-srt-proactive-engagement.md).
# Ein DDo S-Dashboard in erstellen CloudWatch und CloudWatch Alarme einstellen
Diese Seite enthält Anweisungen zum Erstellen eines DDo S-Dashboards in CloudWatch und zum Einstellen von CloudWatch Alarmen.
Sie können potenzielle DDo S-Aktivitäten mithilfe von Amazon überwachen. Amazon CloudWatch sammelt Rohdaten von Shield Advanced und verarbeitet sie zu lesbaren Metriken, die nahezu in Echtzeit verfügbar sind. Mithilfe von Statistiken können Sie CloudWatch sich einen Überblick über die Leistung Ihrer Webanwendung oder Ihres Dienstes verschaffen. Weitere Informationen zur Verwendung CloudWatch finden Sie unter [Was ist CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/WhatIsCloudWatch.html) im * CloudWatch Amazon-Benutzerhandbuch enthalten*.
+ Anweisungen zum Erstellen eines CloudWatch Dashboards finden Sie unter[Überwachung mit Amazon CloudWatch](monitoring-cloudwatch.md).
+ Eine Beschreibung der Shield Advanced-Metriken, die Sie Ihrem Dashboard hinzufügen können, finden Sie unter[AWS Shield Advanced Metriken](shield-metrics.md).
Shield Advanced meldet Ressourcenmetriken CloudWatch häufiger bei DDo S-Ereignissen als wenn keine Ereignisse im Gange sind. Shield Advanced meldet Metriken einmal pro Minute während eines Ereignisses und dann einmal direkt nach dem Ende des Ereignisses. Solange keine Ereignisse im Gange sind, meldet Shield Advanced Metriken einmal täglich zu einer der Ressource zugewiesenen Zeit. Dieser regelmäßige Bericht sorgt dafür, dass die Messwerte aktiv sind und in Ihren benutzerdefinierten CloudWatch Alarmen verwendet werden können.
Damit ist das Tutorial für die ersten Schritte mit Shield Advanced abgeschlossen. Erkunden Sie die Funktionen und Optionen von Shield Advanced weiter, um die Vorteile der von Ihnen ausgewählten Schutzmaßnahmen voll auszuschöpfen. Machen Sie sich zunächst mit Ihren Optionen für die Anzeige und Reaktion auf Ereignisse bei [Einblick in DDo S-Ereignisse mit Shield Advanced](ddos-viewing-events.md) und [Reagieren auf DDo S-Ereignisse in AWS](ddos-responding.md) vertraut.
# Verwaltete Reaktion auf DDo S-Ereignisse mit Unterstützung des Shield Response Team (SRT)
Diese Seite beschreibt die Funktion des Shield Response Teams (SRT).
Das SRT bietet zusätzlichen Support für Shield Advanced-Kunden. Die SRT sind Sicherheitsingenieure, die sich auf DDo S Event Response spezialisiert haben. Als zusätzliche Unterstützungsebene zu Ihrem AWS Support Plan können Sie direkt mit dem SRT zusammenarbeiten und dessen Fachwissen als Teil Ihres Workflows zur Reaktion auf Ereignisse nutzen. Informationen zu den Optionen und Anleitungen zur Konfiguration finden Sie in den folgenden Themen.
**Anmerkung**
Um die Dienste des Shield Response Teams (SRT) nutzen zu können, müssen Sie den [Business Support Plan oder den [Enterprise Support](https://aws.amazon.com/premiumsupport/enterprise-support/) Plan](https://aws.amazon.com/premiumsupport/business-support/) abonniert haben.
Das Shield Response Team (SRT) bietet Dienstleistungen in Regionen an, in denen Shield Advanced verfügbar ist, sowie für Kunden in den GovCloud Regionen AWS GovCloud (USA-Ost) und AWS GovCloud (US-West).
**Aktivitäten zur Unterstützung von SRT**
Das Hauptziel einer Zusammenarbeit mit dem SRT besteht darin, die Verfügbarkeit und Leistung Ihrer Anwendung zu schützen. Je nach Art des DDo S-Ereignisses und der Architektur Ihrer Anwendung kann das SRT eine oder mehrere der folgenden Maßnahmen ergreifen:
+ **AWS WAF Protokollanalyse und Regeln** — Bei Ressourcen, die eine AWS WAF Web-ACL verwenden, kann das SRT Ihre AWS WAF Protokolle analysieren, um Angriffsmerkmale in Ihren Anwendungs-Webanfragen zu identifizieren. Mit Ihrer Zustimmung während des Einsatzes kann das SRT Änderungen an Ihrer Web-ACL vornehmen, um die identifizierten Angriffe zu blockieren.
+ **Erstellen Sie benutzerdefinierte Abwehrmaßnahmen für Ihr Netzwerk** — Das SRT kann für Sie maßgeschneiderte Abhilfemaßnahmen für Angriffe auf Infrastrukturebene erstellen. Das SRT kann mit Ihnen zusammenarbeiten, um den für Ihre Anwendung zu erwartenden Datenverkehr zu verstehen, unerwarteten Datenverkehr zu blockieren und die Geschwindigkeitsbegrenzungen für Pakete pro Sekunde zu optimieren. Weitere Informationen finden Sie unter [Einrichtung benutzerdefinierter Schutzmaßnahmen gegen DDo S-Angriffe mit dem SRT](ddos-srt-custom-mitigations.md).
+ **Netzwerkverkehrstechnik** — Das SRT arbeitet eng mit AWS Netzwerkteams zusammen, um Shield Advanced-Kunden zu schützen. AWS Kann bei Bedarf die Art und Weise ändern, wie Internetverkehr im AWS Netzwerk ankommt, um Ihrer Anwendung mehr Kapazität zur Schadensbegrenzung zuzuweisen.
+ **Empfehlungen zur Architektur** — Das SRT kann feststellen, dass die beste Abwehr eines Angriffs Architekturänderungen erfordert, um sie besser an den AWS bewährten Methoden auszurichten, und diese helfen Ihnen bei der Implementierung dieser Verfahren. Weitere Informationen finden Sie unter [AWS Bewährte Methoden für DDo S-Resiliency](https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency).
Die folgenden Abschnitte enthalten Anweisungen für den Umgang mit dem SRT
**Topics**
+ [Zugriff für das SRT gewähren](ddos-srt-access.md)
+ [Einrichtung eines proaktiven Engagements für das SRT, um Sie direkt zu kontaktieren](ddos-srt-proactive-engagement.md)
+ [Wenden Sie sich an das SRT, um Hilfe bei einem vermuteten DDo S-Ereignis zu erhalten](ddos-srt-contacting.md)
+ [Einrichtung benutzerdefinierter Schutzmaßnahmen gegen DDo S-Angriffe mit dem SRT](ddos-srt-custom-mitigations.md)
# Zugriff für das SRT gewähren
Auf dieser Seite finden Sie Anweisungen, wie Sie der SRT die Erlaubnis erteilen, in Ihrem Namen zu handeln, sodass sie auf Ihre AWS WAF Protokolle zugreifen und Anrufe an die SRT tätigen AWS Shield Advanced und Schutzmaßnahmen AWS WAF APIs verwalten können.
Bei Ereignissen auf Anwendungsebene DDo S kann das SRT AWS WAF Anfragen überwachen, um anomalen Datenverkehr zu identifizieren und dabei zu helfen, benutzerdefinierte AWS WAF Regeln zu erstellen, um schädliche Datenverkehrsquellen zu verhindern.
Darüber hinaus können Sie dem SRT Zugriff auf andere Daten gewähren, die Sie in Amazon S3 S3-Buckets gespeichert haben, z. B. Paketerfassungen oder Protokolle von einem Application Load Balancer CloudFront, Amazon oder aus Quellen von Drittanbietern.
**Anmerkung**
Um die Dienste des Shield Response Teams (SRT) nutzen zu können, müssen Sie den [Business Support Plan oder den [Enterprise Support](https://aws.amazon.com/premiumsupport/enterprise-support/) Plan](https://aws.amazon.com/premiumsupport/business-support/) abonniert haben.
**Um die Berechtigungen für das SRT zu verwalten**
1. Wählen Sie auf der **Übersichtsseite** der AWS Shield Konsole unter ** AWS SRT-Unterstützung konfigurieren die Option SRT-Zugriff** **bearbeiten** aus. Die **Zugriffsseite für das AWS Shield Response Team (SRT) bearbeiten** wird geöffnet.
1. Wählen Sie für die **Einstellung für den SRT-Zugriff** eine der folgenden Optionen aus:
+ **Gewähren Sie dem SRT keinen Zugriff auf mein Konto** — Shield entfernt alle Berechtigungen, die Sie dem SRT zuvor für den Zugriff auf Ihr Konto und Ihre Ressourcen erteilt haben.
+ **Eine neue Rolle für das SRT erstellen, um auf mein Konto zuzugreifen** — Shield erstellt eine Rolle, die dem Service Principal`drt.shield.amazonaws.com`, der das SRT darstellt, vertraut, und fügt ihm die verwaltete Richtlinie hinzu. `AWSShieldDRTAccessPolicy` Die verwaltete Richtlinie ermöglicht es dem SRT, in Ihrem Namen AWS WAF API-Aufrufe zu tätigen AWS Shield Advanced und auf Ihre Protokolle zuzugreifen. AWS WAF Für weitere Informationen über die verwaltete Richtlinie siehe [AWS verwaltete Richtlinie: AWSShield DRTAccess Richtlinie](shd-security-iam-awsmanpol.md#shd-security-iam-awsmanpol-AWSShieldDRTAccessPolicy).
+ **Wählen Sie eine bestehende Rolle für das SRT aus, um auf meine Konten zuzugreifen**. Für diese Option müssen Sie die Konfiguration der Rolle in AWS Identity and Access Management (IAM) wie folgt ändern:
+ Hängen Sie die verwaltete Richtlinie `AWSShieldDRTAccessPolicy` an die Rolle an. Diese verwaltete Richtlinie ermöglicht es dem SRT, in Ihrem Namen AWS WAF API-Aufrufe zu tätigen AWS Shield Advanced und auf Ihre Protokolle zuzugreifen. AWS WAF Für weitere Informationen über die verwaltete Richtlinie siehe [AWS verwaltete Richtlinie: AWSShield DRTAccess Richtlinie](shd-security-iam-awsmanpol.md#shd-security-iam-awsmanpol-AWSShieldDRTAccessPolicy). Informationen zum Anhängen der verwalteten Richtlinie an Ihre Rolle finden Sie unter IAM-Richtlinien [anhängen und trennen](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html).
+ Ändern Sie die Rolle, um dem Service-Prinzipal `drt.shield.amazonaws.com` zu vertrauen. Dies ist der Dienstprinzipal, der die SRT repräsentiert. Weitere Informationen finden Sie unter [IAM-JSON-Richtlinienelemente: Prinzipal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html).
1. Für **(optional): Gewähren Sie SRT-Zugriff auf einen Amazon S3-Bucket**. Wenn Sie Daten teilen müssen, die nicht in Ihren AWS WAF Web-ACL-Protokollen enthalten sind, konfigurieren Sie dies. Zum Beispiel Application Load Balancer Balancer-Zugriffsprotokolle, CloudFront Amazon-Protokolle oder Protokolle aus Quellen von Drittanbietern.
**Anmerkung**
Sie müssen dies nicht für Ihre AWS WAF Web-ACL-Protokolle tun. Das SRT erhält Zugriff auf diese, wenn Sie Zugriff auf Ihr Konto gewähren.
1. Konfigurieren Sie die Amazon S3 S3-Buckets gemäß den folgenden Richtlinien:
+ Die Bucket-Standorte müssen sich in dem befinden AWS-Konto , auf den Sie dem SRT im vorherigen Schritt Zugriff auf das **AWS Shield Response Team (SRT)** gewährt haben.
+ Die Buckets können entweder Klartext- oder SSE-S3-verschlüsselt sein. Weitere Informationen zur Amazon S3 SSE-S3-Verschlüsselung finden Sie unter [Schützen von Daten mithilfe serverseitiger Verschlüsselung mit Amazon S3-Managed Encryption Keys (SSE-S3) im Amazon S3 S3-Benutzerhandbuch](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingServerSideEncryption.html).
Das SRT kann keine Protokolle anzeigen oder verarbeiten, die in Buckets gespeichert sind, die mit Schlüsseln verschlüsselt sind, die in () gespeichert sind. AWS Key Management Service AWS KMS
1. Geben Sie im Abschnitt Shield Advanced **(optional): SRT-Zugriff auf einen Amazon S3-Bucket** für jeden Amazon S3-Bucket, in dem Ihre Daten oder Logs gespeichert sind, den Namen des Buckets ein und wählen Sie **Bucket hinzufügen**. Sie können bis zu 10 Buckets hinzufügen.
Dadurch erhält das SRT die folgenden Berechtigungen für jeden Bucket:`s3:GetBucketLocation`,`s3:GetObject`, und. `s3:ListBucket`
Wenn Sie dem SRT die Erlaubnis geben möchten, auf mehr als 10 Buckets zuzugreifen, können Sie dies tun, indem Sie die zusätzlichen Bucket-Richtlinien bearbeiten und die hier aufgeführten Berechtigungen für das SRT manuell gewähren.
Im Folgenden finden Sie ein Beispiel für eine Richtlinienliste.
```
{
"Sid": "AWSDDoSResponseTeamAccessS3Bucket",
"Effect": "Allow",
"Principal": {
"Service": "drt.shield.amazonaws.com"
},
"Action": [
"s3:GetBucketLocation",
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::bucket-name",
"arn:aws:s3:::bucket-name/*"
]
}
```
1. Wählen Sie **Speichern**, um Ihre Änderungen zu speichern.
[Sie können die SRT auch über die API autorisieren, indem Sie eine IAM-Rolle erstellen, ihr die AWSShield DRTAccess Richtlinienrichtlinie anhängen und die Rolle dann an die Operation Associate übergeben. DRTRole](https://docs.aws.amazon.com/waf/latest/DDOSAPIReference/API_AssociateDRTRole.html)
# Einrichtung eines proaktiven Engagements für das SRT, um Sie direkt zu kontaktieren
Diese Seite enthält Anweisungen zum Einrichten eines proaktiven Engagements mit dem SRT.
Bei proaktivem Engagement kontaktiert Sie das SRT direkt, wenn die Verfügbarkeit oder Leistung Ihrer Anwendung aufgrund eines möglichen Angriffs beeinträchtigt wird. Wir empfehlen dieses Interaktionsmodell, da es die schnellste Reaktion von SRT bietet und es dem SRT ermöglicht, mit der Fehlerbehebung zu beginnen, noch bevor es Kontakt mit Ihnen aufgenommen hat.
Proaktives Engagement ist für Ereignisse auf Netzwerk- und Transportebene auf Elastic IP-Adressen und AWS Global Accelerator Standardbeschleunigern sowie für Webanforderungsfluten auf CloudFront Amazon-Distributionen und Application Load Balancers verfügbar. Proaktives Engagement ist nur für Shield Advanced-Ressourcenschutzmaßnahmen verfügbar, denen eine Amazon Route 53-Zustandsprüfung zugeordnet ist. Informationen zur Verwaltung und Verwendung von Integritätsprüfungen finden Sie unter[Gesundheitsbasierte Erkennung mithilfe von Zustandsprüfungen mit Shield Advanced und Route 53](ddos-advanced-health-checks.md).
Während eines Ereignisses, das von Shield Advanced erkannt wird, verwendet das SRT den Status Ihrer Gesundheitschecks, um festzustellen, ob das Ereignis für ein proaktives Eingreifen in Frage kommt. In diesem Fall wird sich das SRT gemäß den Kontaktangaben, die Sie in Ihrer Konfiguration für proaktives Engagement angegeben haben, mit Ihnen in Verbindung setzen.
Sie können bis zu zehn Kontakte für proaktives Engagement konfigurieren und Sie können Hinweise angeben, die das SRT bei der Kontaktaufnahme mit Ihnen unterstützen. Ihre Ansprechpartner für proaktives Engagement sollten verfügbar sein, um während Veranstaltungen mit dem SRT in Kontakt zu treten. Wenn Sie nicht über ein rund um die Uhr verfügbares Betriebszentrum verfügen, können Sie einen Pager-Kontakt angeben und diese Kontaktpräferenz in Ihren Kontaktnotizen angeben.
Für ein proaktives Engagement müssen Sie Folgendes tun:
+ Sie müssen den [Business Support Plan oder den [Enterprise Support Plan](https://aws.amazon.com/premiumsupport/enterprise-support/)](https://aws.amazon.com/premiumsupport/business-support/) abonniert haben.
+ Sie müssen jeder Ressource, die Sie durch proaktives Engagement schützen möchten, eine Amazon Route 53-Zustandsprüfung zuordnen. Das SRT verwendet den Status Ihrer Zustandsprüfungen, um festzustellen, ob ein Ereignis ein proaktives Eingreifen erfordert. Daher ist es wichtig, dass Ihre Zustandsprüfungen den Status Ihrer geschützten Ressourcen genau widerspiegeln. Weitere Informationen und Anleitungen finden Sie unter[Gesundheitsbasierte Erkennung mithilfe von Zustandsprüfungen mit Shield Advanced und Route 53](ddos-advanced-health-checks.md).
+ Für eine Ressource, der eine AWS WAF Web-ACL zugeordnet ist, müssen Sie die Web-ACL mit AWS WAF (v2) erstellen, der neuesten Version von AWS WAF.
+ Sie müssen mindestens einen Ansprechpartner angeben, den das SRT für proaktive Interaktionen während einer Veranstaltung nutzen kann. Halten Sie Ihre Kontaktinformationen vollständig und aktuell.
**Um ein proaktives Engagement von SRT zu ermöglichen**
1. Wählen Sie auf der **Übersichtsseite** der AWS Shield Konsole unter **Proaktive Interaktion und Kontakte** im Bereich Kontakte die Option **Bearbeiten** aus.
Geben Sie auf der Seite **Kontakte bearbeiten** die Kontaktinformationen der Personen ein, die das SRT für proaktive Interaktionen kontaktieren soll.
Wenn Sie mehr als einen Kontakt angeben, geben Sie in den **Anmerkungen** an, unter welchen Umständen jeder Kontakt verwendet werden soll. Geben Sie die Namen der primären und sekundären Kontaktpersonen an und geben Sie die Verfügbarkeitszeiten und Zeitzonen für jeden Kontakt an.
Beispiele für Kontaktnotizen:
+ Dies ist eine Hotline, die rund um die Uhr besetzt ist. Bitte arbeiten Sie mit dem antwortenden Analysten zusammen und er wird die entsprechende Person für das Gespräch finden.
+ Bitte kontaktieren Sie mich, wenn die Hotline nicht innerhalb von 5 Minuten antwortet.
1. Wählen Sie **Speichern**.
Die **Übersichtsseite** enthält die aktualisierten Kontaktinformationen.
1. Wählen Sie die **Funktion „Proaktive Interaktion bearbeiten“**, dann „**Aktivieren**“ und anschließend „**Speichern**“, um die proaktive Interaktion zu aktivieren.
# Wenden Sie sich an das SRT, um Hilfe bei einem vermuteten DDo S-Ereignis zu erhalten
Sie können das SRT auf eine der folgenden Arten kontaktieren:
**Support-Fall**
Sie können einen Fall unter **AWS Shield**in der **AWS Support Center-Konsole** öffnen.
Anleitungen zur Erstellung eines Support-Falls finden Sie [AWS Support im Center](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html).
Wählen Sie den Schweregrad aus, der Ihrer Situation entspricht, und geben Sie Ihre Kontaktdaten an. Geben Sie in der Beschreibung so viele Details wie möglich an. Geben Sie Informationen zu allen geschützten Ressourcen an, von denen Sie glauben, dass sie betroffen sein könnten, sowie zum aktuellen Stand Ihrer Endbenutzererfahrung. Wenn beispielsweise Ihre Benutzererfahrung beeinträchtigt ist oder Teile Ihrer Anwendung derzeit nicht verfügbar sind, geben Sie diese Informationen an.
+ **Bei vermuteten DDo S-Angriffen** — Wenn die Verfügbarkeit oder Leistung Ihrer Anwendung derzeit durch einen möglichen DDo S-Angriff beeinträchtigt wird, wählen Sie den folgenden Schweregrad und die folgenden Kontaktoptionen aus:
+ Wählen Sie für den Schweregrad den höchsten Schweregrad aus, der für Ihren Supportplan verfügbar ist:
+ Für Business-Support ist das **Produktionssystem ausgefallen: < 1 Stunde**.
+ Für Enterprise-Support ist dies ein **Ausfall des geschäftskritischen Systems: < 15 Minuten**.
+ Wählen Sie als Kontaktoption entweder **Telefon** oder **Chat** und geben Sie Ihre Daten ein. Die Verwendung einer Live-Kontaktmethode bietet die schnellste Antwort.
**Proaktives Engagement**
Bei AWS Shield Advanced proaktivem Einsatz kontaktiert das SRT Sie direkt, wenn der Amazon Route 53-Zustandstest, der mit Ihrer geschützten Ressource verknüpft ist, während eines erkannten Ereignisses fehlerhaft wird. Weitere Informationen zu dieser Option finden Sie unter [Einrichtung eines proaktiven Engagements für das SRT, um Sie direkt zu kontaktieren](ddos-srt-proactive-engagement.md).
# Einrichtung benutzerdefinierter Schutzmaßnahmen gegen DDo S-Angriffe mit dem SRT
Diese Seite enthält Anweisungen für die Arbeit mit dem SRT zur Erstellung benutzerdefinierter Schutzmaßnahmen gegen S-Angriffe. DDo
Für Ihr Elastic IPs (EIPs) und Ihre AWS Global Accelerator Standard-Accelerators können Sie mit dem SRT zusammenarbeiten, um benutzerdefinierte Abwehrmaßnahmen zu konfigurieren. Dies ist nützlich, falls Sie eine bestimmte Logik kennen, die bei der Einführung einer Risikominderung durchgesetzt werden sollte. Beispielsweise möchten Sie möglicherweise nur Datenverkehr aus bestimmten Ländern zulassen, bestimmte Ratenbegrenzungen durchsetzen, optionale Validierungen konfigurieren, Fragmente nicht zulassen oder nur Datenverkehr zulassen, der einem bestimmten Muster in der Paketnutzlast entspricht.
Zu den häufigsten benutzerdefinierten Abhilfemaßnahmen gehören die folgenden:
+ **Musterabgleich** — Wenn Sie einen Dienst betreiben, der mit clientseitigen Anwendungen interagiert, können Sie sich für den Abgleich nach bekannten Mustern entscheiden, die für diese Anwendungen spezifisch sind. Sie können beispielsweise einen Spiel- oder Kommunikationsdienst betreiben, bei dem der Endbenutzer bestimmte Software installieren muss, die Sie vertreiben. Sie können jedem Paket, das von der Anwendung an Ihren Dienst gesendet wird, eine magische Zahl hinzufügen. Sie können bis zu 128 Byte (getrennt oder zusammenhängend) einer nicht fragmentierten Nutzlast und Header eines nicht fragmentierten TCP- oder UDP-Pakets zuordnen. Die Übereinstimmung kann in hexadezimaler Schreibweise als spezifischer Offset vom Anfang der Paketnutzlast oder als dynamischer Offset nach einem bekannten Wert ausgedrückt werden. Die Schadensbegrenzung kann beispielsweise nach dem Byte suchen `0x01` und dann die nächsten vier Byte erwarten`0x12345678`.
+ **DNS-spezifisch** — Wenn Sie Ihren eigenen autoritativen DNS-Service mit Diensten wie Global Accelerator oder Amazon Elastic Compute Cloud (Amazon EC2) betreiben, können Sie eine benutzerdefinierte Schadensbegrenzung anfordern, die Pakete validiert, um sicherzustellen, dass es sich um gültige DNS-Abfragen handelt, und eine Verdachtsbewertung anwenden, bei der Attribute ausgewertet werden, die spezifisch für den DNS-Verkehr sind.
Wenn Sie sich über die Zusammenarbeit mit SRT bei der Erstellung benutzerdefinierter Abhilfemaßnahmen erkundigen möchten, erstellen Sie einen Support-Fall unter. AWS Shield Weitere Informationen zum Erstellen von AWS Support Fällen finden Sie unter [Erste Schritte](https://docs.aws.amazon.com/awssupport/latest/user/getting-started.html) mit. AWS Support
# Ressourcenschutz in AWS Shield Advanced
Sie können AWS Shield Advanced Schutzmaßnahmen für Ihre Ressourcen hinzufügen und konfigurieren. Sie können den Schutz für eine einzelne Ressource verwalten und Ihre geschützten Ressourcen zur besseren Verwaltung von Ereignissen in logischen Sammlungen gruppieren. Sie können Änderungen an Ihren Shield Advanced-Schutzmaßnahmen auch mit AWS Config verfolgen.
**Anmerkung**
Shield Advanced schützt nur Ressourcen, die Sie entweder in Shield Advanced oder durch eine AWS Firewall Manager Shield Advanced-Richtlinie angegeben haben. Ihre Ressourcen werden nicht automatisch geschützt.
Wenn Sie eine AWS Firewall Manager Shield Advanced-Richtlinie verwenden, müssen Sie den Schutz für Ressourcen, die in den Geltungsbereich der Richtlinie fallen, nicht verwalten. Firewall Manager verwaltet automatisch den Schutz für Konten und Ressourcen, die in den Geltungsbereich einer Richtlinie fallen, entsprechend der Richtlinienkonfiguration. Weitere Informationen finden Sie unter [AWS Shield Advanced Richtlinien im Firewall Manager verwenden](shield-policies.md).
**Topics**
+ [Liste der Ressourcen, die AWS Shield Advanced schützen](ddos-protections-by-resource-type.md)
+ [Schutz von EC2 Amazon-Instances und Network Load Balancers mit Shield Advanced](ddos-protections-ec2-nlb.md)
+ [Schutz der Anwendungsschicht (Schicht 7) mit AWS Shield Advanced und AWS WAF](ddos-app-layer-protections.md)
+ [Gesundheitsbasierte Erkennung mithilfe von Zustandsprüfungen mit Shield Advanced und Route 53](ddos-advanced-health-checks.md)
+ [AWS Ressourcen AWS Shield Advanced schützen](configure-new-protection.md)
+ [AWS Shield Advanced Schutzmaßnahmen bearbeiten](manage-protection.md)
+ [Alarme und Benachrichtigungen für Ressourcen erstellen, die durch Shield Advanced geschützt sind](add-alarm-ddos.md)
+ [AWS Shield Advanced Schutz von einer AWS Ressource entfernen](remove-protection.md)
+ [Gruppieren Sie Ihre Schutzmaßnahmen AWS Shield Advanced](ddos-protection-groups.md)
+ [Änderungen am Ressourcenschutz von Tracking Shield Advanced in AWS Config](ddos-add-config.md)
# Liste der Ressourcen, die AWS Shield Advanced schützen
Dieser Abschnitt enthält Informationen zu Shield Advanced-Schutzmaßnahmen für jeden Ressourcentyp.
Shield Advanced schützt AWS Ressourcen in der Netzwerk- und Transportebene (Schichten 3 und 4) und in der Anwendungsschicht (Schicht 7). Sie können einige Ressourcen direkt und andere durch die Verknüpfung mit geschützten Ressourcen schützen. Shield Advanced unterstützt IPv4 und unterstützt nicht IPv6.
**Anmerkung**
Shield Advanced schützt nur Ressourcen, die Sie entweder in Shield Advanced oder durch eine AWS Firewall Manager Shield Advanced-Richtlinie angegeben haben. Ihre Ressourcen werden nicht automatisch geschützt.
Sie können Shield Advanced für erweiterte Überwachung und Schutz mit den folgenden Ressourcentypen verwenden:
+ CloudFront Amazon-Distributionen. Für CloudFront eine kontinuierliche Bereitstellung schützt Shield Advanced jede Staging-Distribution, die einer geschützten Primärdistribution zugeordnet ist.
+ Gehostete Zonen von Amazon Route 53.
+ AWS Global Accelerator Standardbeschleuniger.
+ Amazon EC2 Elastic IP-Adressen. Shield Advanced schützt die Ressourcen, die geschützten Elastic IP-Adressen zugeordnet sind.
+ EC2 Amazon-Instances durch Zuordnung zu Amazon EC2 Elastic-IP-Adressen.
+ Die folgenden Elastic Load Balancing (ELB) -Load Balancer:
+ Load Balancer für Anwendungen.
+ Classic Load Balancer.
+ Network Load Balancers über Verknüpfungen zu Amazon EC2 Elastic-IP-Adressen.
**Anmerkung**
Sie können Shield Advanced nicht verwenden, um andere Ressourcentypen zu schützen. Sie können beispielsweise keine AWS Global Accelerator benutzerdefinierten Routing-Beschleuniger oder Gateway Load Balancer schützen.
**Anmerkung**
NAT-Gateways verarbeiten nur ausgehenden Datenverkehr, während Shield Advanced vor eingehendem S schützt. DDo Verwenden Sie zum Schutz des ausgehenden Datenverkehrs. [AWS Network Firewall](https://docs.aws.amazon.com//network-firewall/latest/developerguide/what-is-aws-network-firewall.html)
Sie können pro AWS-Konto Ressourcentyp bis zu 1.000 Ressourcen überwachen und schützen. In einem einzigen Konto könnten Sie beispielsweise 1.000 Amazon EC2 Elastic IP-Adressen, 1.000 CloudFront Distributionen und 1.000 Application Load Balancer schützen. Sie können eine Erhöhung der Anzahl der Ressourcen, die Sie mit Shield Advanced schützen können, über die Service-Kontingents-Konsole unter beantragen [https://console.aws.amazon.com/servicequotas/](https://console.aws.amazon.com/servicequotas/).
# Schutz von EC2 Amazon-Instances und Network Load Balancers mit Shield Advanced
Auf dieser Seite wird erklärt, wie Sie AWS Shield Advanced Schutzmaßnahmen für EC2 Amazon-Instances und Network Load Balancer verwenden.
Sie können EC2 Amazon-Instances und Network Load Balancers schützen, indem Sie diese Ressourcen zunächst an Elastic IP-Adressen anhängen und dann die Elastic IP-Adressen in Shield Advanced schützen.
Wenn Sie Elastic IP-Adressen schützen, identifiziert und schützt Shield Advanced die Ressourcen, mit denen sie verknüpft sind. Shield Advanced identifiziert automatisch den Ressourcentyp, der an eine Elastic IP-Adresse angehängt ist, und wendet die entsprechenden Erkennungen und Abhilfemaßnahmen für diese Ressource an. Dazu gehört die Konfiguration von Netzwerken ACLs , die für die Elastic IP-Adresse spezifisch sind. Weitere Informationen zur Verwendung von Elastic IP-Adressen mit Ihren AWS Ressourcen finden Sie in den folgenden Anleitungen: [Amazon Elastic Compute Cloud-Dokumentation oder Elastic](https://docs.aws.amazon.com/ec2/) [Load Balancing Balancing-Dokumentation](https://docs.aws.amazon.com/elasticloadbalancing/).
Während eines Angriffs verteilt Shield Advanced Ihr Netzwerk automatisch ACLs bis zur AWS Netzwerkgrenze. Wenn ACLs sich Ihr Netzwerk an der Netzwerkgrenze befindet, kann Shield Advanced Schutz vor größeren DDo S-Ereignissen bieten. In der Regel ACLs werden Netzwerke in der Nähe Ihrer EC2 Amazon-Instances innerhalb Ihrer Amazon VPC eingesetzt. Die Netzwerk-ACL kann Angriffe nur so groß abwehren, wie Ihre Amazon VPC und Instance handhaben können. Wenn die an Ihre EC2 Amazon-Instance angeschlossene Netzwerkschnittstelle beispielsweise bis zu 10 Gbit/s verarbeiten kann, werden Volumes über 10 Gbit/s langsamer und blockieren möglicherweise den Datenverkehr zu dieser Instance. Während eines Angriffs befördert Shield Advanced Ihre Netzwerk-ACL bis AWS an die Grenze, wodurch mehrere Terabyte an Datenverkehr verarbeitet werden können. Ihre Netzwerk-ACL kann Schutz für Ihre Ressource weit über die typische Kapazität Ihres Netzwerks hinaus bieten. [Weitere Informationen zum Netzwerk finden Sie ACLs unter Netzwerk. ACLs](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_ACLs.html)
Bei einigen Skalierungstools AWS Elastic Beanstalk, z. B., können Sie einem Network Load Balancer nicht automatisch eine Elastic IP-Adresse zuordnen. In diesen Fällen müssen Sie die Elastic IP-Adresse manuell anhängen.
# Schutz der Anwendungsschicht (Schicht 7) mit AWS Shield Advanced und AWS WAF
Auf dieser Seite wird erklärt, wie Shield Advanced und Shield AWS WAF zusammenarbeiten, um Ressourcen auf der Anwendungsebene (Schicht 7) zu schützen.
Um Ihre Ressourcen auf Anwendungsebene mit Shield Advanced zu schützen, verknüpfen Sie zunächst eine AWS WAF Web-ACL mit der Ressource und fügen ihr eine oder mehrere ratenbasierte Regeln hinzu. Sie können zusätzlich die automatische Abwehr auf Anwendungsebene DDo S aktivieren, wodurch Shield Advanced als Reaktion auf DDo S-Angriffe automatisch Web-ACL-Regeln in Ihrem Namen erstellt und verwaltet.
Wenn Sie eine Ressource auf Anwendungsebene mit Shield Advanced schützen, analysiert Shield Advanced den Datenverkehr im Laufe der Zeit, um Baselines festzulegen und aufrechtzuerhalten. Shield Advanced verwendet diese Baselines, um Anomalien in den Verkehrsmustern zu erkennen, die auf einen S-Angriff hinweisen könnten. DDo Der Zeitpunkt, an dem Shield Advanced einen Angriff erkennt, hängt vom Verkehr ab, den Shield Advanced vor dem Angriff beobachten konnte, und von der Architektur, die Sie für Ihre Webanwendungen verwenden. Zu den Architekturvariationen, die das Verhalten von Shield Advanced beeinflussen können, gehören der Typ der von Ihnen verwendeten Instanz, Ihre Instanzgröße und ob der Instance-Typ Enhanced Networking unterstützt. Sie können Shield Advanced auch so konfigurieren, dass automatisch Gegenmaßnahmen gegen Angriffe auf Anwendungsebene eingerichtet werden.
**Shield Advanced-Abonnements und AWS WAF Kosten**
Ihr Shield Advanced-Abonnement deckt die Kosten für die Nutzung von AWS WAF Standardfunktionen für Ressourcen ab, die Sie mit Shield Advanced schützen. Die AWS WAF Standardgebühren, die durch Ihre Shield Advanced-Schutzmaßnahmen abgedeckt werden, sind die Kosten pro Schutzpaket (Web-ACL), die Kosten pro Regel und der Grundpreis pro Million Anfragen für die Prüfung von Webanfragen, bis zu 1.500 WCUs und bis zur Standardgröße.
Wenn Sie die automatische Abwehr auf Anwendungsebene DDo S von Shield Advanced aktivieren, wird Ihrem Schutzpaket (Web-ACL) eine Regelgruppe hinzugefügt, die 150 Web-ACL-Kapazitätseinheiten (WCUs) verwendet. Diese werden auf die WCU-Nutzung in Ihrem Protection Pack (Web-ACL) WCUs angerechnet. Weitere Informationen finden Sie unter [Automatisierung der Risikominderung auf Anwendungsebene DDo S mit Shield Advanced](ddos-automatic-app-layer-response.md), [Schutz der Anwendungsebene mit der Shield Advanced-Regelgruppe](ddos-automatic-app-layer-response-rg.md) und [Web-ACL-Kapazitätseinheiten (WCUs) in AWS WAF](aws-waf-capacity-units.md).
Ihr Abonnement AWS WAF für Shield Advanced deckt nicht die Nutzung von Ressourcen ab, die Sie nicht mit Shield Advanced schützen. Es deckt auch keine zusätzlichen, nicht standardmäßigen AWS WAF Kosten für geschützte Ressourcen ab. Beispiele für nicht standardmäßige AWS WAF Kosten sind die Kosten für Bot-Kontrolle, für CAPTCHA Regelaktionen, für Websites, die mehr als 1.500 ACLs Benutzer verwenden WCUs, und für die Überprüfung des Anfragetexts, der über die Standardgröße hinausgeht. Die vollständige Liste finden Sie auf der Seite mit den AWS WAF Preisen. Ihr Abonnement für Shield Advanced beinhaltet den Zugriff auf die Layer 7 DDo Anti-S Amazon Managed Rule-Gruppe. Im Rahmen Ihres Abonnements erhalten Sie in einem Kalendermonat bis zu 50 Milliarden Anfragen an geschützte Shield AWS WAF Advanced-Ressourcen. Anfragen über 50 Milliarden werden gemäß der AWS Shield Advanced Preisseite in Rechnung gestellt.
Vollständige Informationen und Preisbeispiele finden Sie unter [Shield Pricing](https://aws.amazon.com/shield/pricing/) and [AWS WAF Pricing](https://aws.amazon.com/waf/pricing/).
**Topics**
+ [Liste der Faktoren, die die Erkennung und Minderung von Ereignissen auf Anwendungsebene mit Shield Advanced beeinflussen](ddos-app-layer-detection-mitigation.md)
+ [Schutz der Anwendungsebene mit AWS WAF Web ACLs und Shield Advanced](ddos-app-layer-web-ACL-and-rbr.md)
+ [Schutz der Anwendungsebene mit AWS WAF ratenbasierten Regeln und Shield Advanced](ddos-app-layer-rbr.md)
+ [Automatisierung der Risikominderung auf Anwendungsebene DDo S mit Shield Advanced](ddos-automatic-app-layer-response.md)
# Liste der Faktoren, die die Erkennung und Minderung von Ereignissen auf Anwendungsebene mit Shield Advanced beeinflussen
In diesem Abschnitt werden die Faktoren beschrieben, die die Erkennung und Abwehr von Ereignissen auf Anwendungsebene durch Shield Advanced beeinflussen.
**Health checks (Zustandsprüfungen)**
Integritätsprüfungen, die den Gesamtzustand Ihrer Anwendung genau melden, liefern Shield Advanced Informationen über die Verkehrsbedingungen, denen Ihre Anwendung ausgesetzt ist. Shield Advanced benötigt weniger Informationen, die auf einen möglichen Angriff hinweisen, wenn Ihre Anwendung als fehlerhaft gemeldet wird, und es werden mehr Beweise für einen Angriff benötigt, wenn Ihre Anwendung als fehlerfrei gemeldet wird.
Es ist wichtig, dass Sie Ihre Integritätsprüfungen so konfigurieren, dass sie den Zustand der Anwendung korrekt melden. Weitere Informationen und Anleitungen finden Sie unter[Gesundheitsbasierte Erkennung mithilfe von Zustandsprüfungen mit Shield Advanced und Route 53](ddos-advanced-health-checks.md).
**Ausgangswerte für den Verkehr**
Verkehrs-Baselines geben Shield Advanced Informationen über die Eigenschaften des normalen Datenverkehrs für Ihre Anwendung. Shield Advanced verwendet diese Baselines, um zu erkennen, wenn Ihre Anwendung keinen normalen Datenverkehr empfängt, sodass es Sie benachrichtigen und, wie konfiguriert, mit der Entwicklung und dem Testen von Abwehroptionen beginnen kann, um einem potenziellen Angriff entgegenzuwirken. Weitere Informationen darüber, wie Shield Advanced Verkehrsbaselines verwendet, um potenzielle Ereignisse zu erkennen, finden Sie im Abschnitt Übersicht. [Shield Advanced Erkennungslogik für Bedrohungen auf Anwendungsebene (Schicht 7)](ddos-event-detection-application.md)
Shield Advanced erstellt seine Baselines anhand von Informationen, die von der Web-ACL bereitgestellt werden, die der geschützten Ressource zugeordnet ist. Die Web-ACL muss mindestens 24 Stunden und bis zu 30 Tage mit der Ressource verknüpft sein, bevor Shield Advanced die Baselines der Anwendung zuverlässig ermitteln kann. Die benötigte Zeit beginnt, wenn Sie die Web-ACL zuordnen, entweder über Shield Advanced oder über AWS WAF.
Weitere Informationen zur Verwendung einer Web-ACL mit Ihrem Shield Advanced-Schutz auf Anwendungsebene finden Sie unter[Schutz der Anwendungsebene mit AWS WAF Web ACLs und Shield Advanced](ddos-app-layer-web-ACL-and-rbr.md).
**Ratenbasierte Regeln**
Ratenbasierte Regeln können zur Abwehr von Angriffen beitragen. Sie können Angriffe auch verschleiern, indem sie sie abwehren, bevor sie zu einem Problem werden, das groß genug ist, um in normalen Datenverkehrsdaten oder in Statusberichten zum Status von Gesundheitschecks aufzutauchen.
Wir empfehlen, ratenbasierte Regeln in Ihrer Web-ACL zu verwenden, wenn Sie eine Anwendungsressource mit Shield Advanced schützen. Auch wenn ihre Abwehr einen potenziellen Angriff verdecken kann, stellen sie eine wertvolle erste Verteidigungslinie dar und tragen dazu bei, dass Ihre Anwendung Ihren legitimen Kunden weiterhin zur Verfügung steht. Der Traffic, den Ihre tarifbasierten Regeln erkennen, und das Ratenlimit sind in Ihren Kennzahlen sichtbar. AWS WAF
Wenn Sie die automatische Abwehr auf Anwendungsebene DDo S aktivieren, fügt Shield Advanced Ihrer Web-ACL zusätzlich zu Ihren eigenen ratenbasierten Regeln eine Regelgruppe hinzu, die zur Abwehr von Angriffen verwendet wird. In dieser Regelgruppe verfügt Shield Advanced immer über eine ratenbasierte Regel, die das Volumen der Anfragen von IP-Adressen begrenzt, von denen bekannt ist, dass sie Quellen von DDo S-Angriffen sind. Metriken für den Traffic, den die Shield Advanced-Regeln abschwächen, können Sie nicht einsehen.
Weitere Informationen zu ratenbasierten Regeln finden Sie unter. [Verwendung ratenbasierter Regelanweisungen in AWS WAF](waf-rule-statement-type-rate-based.md) Informationen zu der ratenbasierten Regel, die Shield Advanced für die automatische Abwehr von Anwendungsschichten DDo S verwendet, finden Sie unter. [Schutz der Anwendungsebene mit der Shield Advanced-Regelgruppe](ddos-automatic-app-layer-response-rg.md)
Weitere Informationen zu Shield Advanced und AWS WAF Metriken finden Sie unter[Überwachung mit Amazon CloudWatch](monitoring-cloudwatch.md).
# Schutz der Anwendungsebene mit AWS WAF Web ACLs und Shield Advanced
Auf dieser Seite wird erklärt, wie AWS WAF Web ACLs und Shield Advanced zusammenarbeiten, um grundlegende Schutzmaßnahmen auf Anwendungsebene zu erstellen.
Um eine Ressource auf Anwendungsebene mit Shield Advanced zu schützen, ordnen Sie der Ressource zunächst eine AWS WAF Web-ACL zu. AWS WAF ist eine Firewall für Webanwendungen, mit der Sie die HTTP- und HTTPS-Anfragen überwachen können, die an Ihre Ressourcen auf Anwendungsebene weitergeleitet werden, und mit der Sie den Zugriff auf Ihre Inhalte anhand der Eigenschaften der Anfragen steuern können. Sie können eine Web-ACL so konfigurieren, dass Anfragen auf der Grundlage von Faktoren wie dem Ursprung der Anfrage, dem Inhalt von Abfragezeichenfolgen und Cookies sowie der Rate der Anfragen, die von einer einzigen IP-Adresse kommen, überwacht und verwaltet werden. Für Ihren Shield Advanced-Schutz müssen Sie mindestens eine Web-ACL mit einer ratenbasierten Regel verknüpfen, die die Anzahl der Anfragen für jede IP-Adresse begrenzt.
Wenn für die zugehörige Web-ACL keine ratenbasierte Regel definiert ist, fordert Shield Advanced Sie auf, mindestens eine zu definieren. Ratenbasierte Regeln blockieren automatisch den Datenverkehr von der Quelle aus, IPs wenn er die von Ihnen definierten Schwellenwerte überschreitet. Sie schützen Ihre Anwendung vor einer Flut von Webanfragen und können Warnmeldungen über plötzliche Datenverkehrsspitzen ausgeben, die auf einen möglichen S-Angriff hinweisen könnten. DDo
**Anmerkung**
Eine ratenbasierte Regel reagiert sehr schnell auf Datenverkehrsspitzen, die von der Regel überwacht werden. Aus diesem Grund kann eine ratenbasierte Regel nicht nur einen Angriff verhindern, sondern auch die Erkennung eines potenziellen Angriffs durch die Erkennung von Shield Advanced. Bei diesem Kompromiss wird die Prävention der vollständigen Transparenz der Angriffsmuster vorgezogen. Wir empfehlen, eine ratenbasierte Regel als erste Verteidigungslinie gegen Angriffe zu verwenden.
Wenn Ihre Web-ACL eingerichtet ist, wenden Sie bei einem DDo S-Angriff Abhilfemaßnahmen an, indem Sie Regeln in der Web-ACL hinzufügen und verwalten. Sie können dies direkt mit Unterstützung des Shield Response Teams (SRT) oder automatisch durch automatische Abwehr auf Anwendungsebene DDo S tun.
**Wichtig**
Wenn Sie auch die automatische Abwehr auf Anwendungsebene DDo S verwenden, finden Sie die bewährten Methoden für die Verwaltung Ihrer Web-ACL unter. [Bewährte Methoden für die Verwendung der automatischen DDo Application-Layer-S-Abwehr](ddos-automatic-app-layer-response-bp.md)
Informationen AWS WAF zur Verwaltung Ihrer Überwachungs- und Verwaltungsregeln für Webanfragen finden Sie unter[Erstellen eines Schutzpakets (Web-ACL) in AWS WAF](web-acl-creating.md).
# Schutz der Anwendungsebene mit AWS WAF ratenbasierten Regeln und Shield Advanced
Auf dieser Seite wird erklärt, wie AWS WAF ratenbasierte Regeln und Shield Advanced zusammenarbeiten, um grundlegende Schutzmaßnahmen auf Anwendungsebene zu schaffen.
Wenn Sie eine ratenbasierte Regel mit ihrer Standardkonfiguration verwenden, wertet sie AWS WAF regelmäßig den Datenverkehr für das vorherige 5-minütige Zeitfenster aus. AWS WAF blockiert Anfragen von beliebigen IP-Adressen, die den Schwellenwert der Regel überschreiten, bis die Anforderungsrate auf ein akzeptables Niveau gesunken ist. Wenn Sie eine ratenbasierte Regel über Shield Advanced konfigurieren, konfigurieren Sie deren Schwellenwert auf einen Wert, der höher ist als die normale Datenverkehrsrate, die Sie von einer beliebigen Quell-IP in einem beliebigen Zeitfenster von fünf Minuten erwarten.
Möglicherweise möchten Sie mehr als eine ratenbasierte Regel in einer Web-ACL verwenden. Sie könnten beispielsweise eine ratenbasierte Regel für den gesamten Datenverkehr mit einem hohen Schwellenwert sowie eine oder mehrere zusätzliche Regeln verwenden, die so konfiguriert sind, dass sie ausgewählten Teilen Ihrer Webanwendung entsprechen und niedrigere Schwellenwerte haben. Sie könnten beispielsweise die URI `/login.html` einem niedrigeren Schwellenwert zuordnen, um den Missbrauch einer Anmeldeseite zu verhindern.
Sie können eine ratenbasierte Regel so konfigurieren, dass sie ein anderes Bewertungszeitfenster verwendet und Anfragen nach einer Reihe von Anforderungskomponenten wie Header-Werten, Labels und Abfrageargumenten aggregiert. Weitere Informationen finden Sie unter [Verwendung ratenbasierter Regelanweisungen in AWS WAF](waf-rule-statement-type-rate-based.md).
Weitere Informationen und Anleitungen finden Sie im Sicherheits-Blogbeitrag [Die drei wichtigsten AWS WAF ratenbasierten](https://aws.amazon.com/blogs/security/three-most-important-aws-waf-rate-based-rules/) Regeln.
**Erweiterte Konfigurationsoptionen durch AWS WAF**
Die Shield Advanced-Konsole ermöglicht es Ihnen, eine ratenbasierte Regel hinzuzufügen und sie mit den grundlegenden Standardeinstellungen zu konfigurieren. Sie können zusätzliche Konfigurationsoptionen definieren, indem Sie Ihre ratenbasierten Regeln über verwalten. AWS WAF Sie können die Regel beispielsweise so konfigurieren, dass Anfragen auf der Grundlage von Schlüsseln wie einer weitergeleiteten IP-Adresse, einer Abfragezeichenfolge und einer Bezeichnung zusammengefasst werden. Sie können der Regel auch eine Scopedown-Anweisung hinzufügen, um einige Anfragen aus der Bewertung und der Ratenbegrenzung herauszufiltern. Weitere Informationen finden Sie unter [Verwendung ratenbasierter Regelanweisungen in AWS WAF](waf-rule-statement-type-rate-based.md).
# Automatisierung der Risikominderung auf Anwendungsebene DDo S mit Shield Advanced
**Anmerkung**
Ab dem 26. März 2026 AWS WAF wird die DDo Anti-S Managed Rule Group (Anti-DDoS AMR) zur Standardlösung für den Schutz vor HTTP-Request-Flood-Angriffen (siehe den [DDoAnti-S AMR-Launch-Blog](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-the-aws-waf-application-layer-ddos-protection/)). Sie ersetzt die Funktion Layer 7 Auto Mitigation (L7AM). Wenn Sie bereits Shield Advanced-Kunde sind, können Sie die Legacy-Lösung weiterhin mit bestehenden oder neuen AWS Konten verwenden. Wir empfehlen Ihnen jedoch, die DDo Anti-S Managed Rule Group zu übernehmen. Die DDo Anti-S Managed Rule Group erkennt und wehrt Angriffe innerhalb von Sekunden statt Minuten ab. Wenn Sie ein neuer Shield Advanced-Kunde sind und Zugriff auf die ältere Lösung benötigen, wenden Sie sich an den AWS Support.
Auf dieser Seite wird das Thema automatische Risikominderung auf Anwendungsebene DDo S vorgestellt und die damit verbundenen Vorbehalte aufgeführt.
Sie können Shield Advanced so konfigurieren, dass es automatisch reagiert, um Angriffe auf Anwendungsebene (Schicht 7) gegen Ihre geschützten Ressourcen auf Anwendungsebene abzuwehren, indem Webanfragen, die Teil des Angriffs sind, gezählt oder blockiert werden. Diese Option ist eine Ergänzung zum Schutz auf Anwendungsebene, den Sie über Shield Advanced mit einer AWS WAF Web-ACL und Ihrer eigenen ratenbasierten Regel hinzufügen.
Wenn die automatische Risikominderung für eine Ressource aktiviert ist, verwaltet Shield Advanced eine Regelgruppe in der zugehörigen Web-ACL der Ressource, in der es Minderungsregeln im Namen der Ressource verwaltet. Die Regelgruppe enthält eine ratenbasierte Regel, die das Volumen der Anfragen von IP-Adressen verfolgt, von denen bekannt ist, dass sie Quellen von S-Angriffen sind. DDo
Darüber hinaus vergleicht Shield Advanced aktuelle Verkehrsmuster mit historischen Verkehrsbasislinien, um Abweichungen zu erkennen, die auf einen DDo S-Angriff hinweisen könnten. Shield Advanced reagiert auf erkannte DDo S-Angriffe, indem es zusätzliche benutzerdefinierte AWS WAF Regeln in der Regelgruppe erstellt, auswertet und einsetzt.
## Vorbehalte bei der Verwendung der automatischen Abwehr auf Anwendungsebene DDo S
In der folgenden Liste werden die Vorbehalte der automatischen Abwehr der Anwendungsschicht DDo S von Shield Advanced beschrieben und die Schritte beschrieben, die Sie möglicherweise als Reaktion darauf ergreifen sollten.
+ Die automatische Abwehr auf Anwendungsebene DDo S funktioniert nur mit Schutzpaketen (Web ACLs), die mit der neuesten Version von AWS WAF (v2) erstellt wurden.
+ Shield Advanced benötigt Zeit, um eine Basislinie des normalen, historischen Datenverkehrs Ihrer Anwendung zu erstellen, die es nutzt, um den Angriffsverkehr zu erkennen und vom normalen Verkehr zu isolieren, um den Angriffsverkehr einzudämmen. Die Erstellung einer Baseline dauert zwischen 24 Stunden und 30 Tagen ab dem Zeitpunkt, an dem Sie der geschützten Anwendungsressource eine Web-ACL zuordnen. Weitere Informationen zu Verkehrs-Baselines finden Sie unter. [Liste der Faktoren, die die Erkennung und Minderung von Ereignissen auf Anwendungsebene mit Shield Advanced beeinflussen](ddos-app-layer-detection-mitigation.md)
+ Wenn Sie die automatische Abwehr auf Anwendungsebene DDo S aktivieren, wird Ihrem Schutzpaket (Web-ACL) eine Regelgruppe hinzugefügt, die 150 Web-ACL-Kapazitätseinheiten () verwendet. WCUs Diese werden auf die WCU-Nutzung in Ihrem Protection Pack (Web-ACL) WCUs angerechnet. Weitere Informationen finden Sie unter [Schutz der Anwendungsebene mit der Shield Advanced-Regelgruppe](ddos-automatic-app-layer-response-rg.md) und [Web-ACL-Kapazitätseinheiten (WCUs) in AWS WAF](aws-waf-capacity-units.md).
+ Die Shield Advanced-Regelgruppe generiert AWS WAF Metriken, die jedoch nicht angezeigt werden können. Das Gleiche gilt für alle anderen Regelgruppen, die Sie in Ihrem Protection Pack (Web-ACL) verwenden, die Sie aber nicht besitzen, wie z. B. Regelgruppen mit AWS verwalteten Regeln. Weitere Informationen zu AWS WAF Metriken finden Sie unter[AWS WAF Metriken und Dimensionen](waf-metrics.md). Informationen zu dieser Shield Advanced-Schutzoption finden Sie unter[Automatisierung der Risikominderung auf Anwendungsebene DDo S mit Shield Advanced](#ddos-automatic-app-layer-response).
+ Bei Websites ACLs , die mehrere Ressourcen schützen, setzt die automatische Schadensbegrenzung nur benutzerdefinierte Abhilfemaßnahmen ein, die sich nicht negativ auf die geschützten Ressourcen auswirken.
+ Die Zeit zwischen dem Beginn eines DDo S-Angriffs und dem Zeitpunkt, zu dem Shield Advanced benutzerdefinierte automatische Abwehrregeln festlegt, ist von Ereignis zu Ereignis unterschiedlich. Einige DDo S-Angriffe können enden, bevor die benutzerdefinierten Regeln implementiert werden. Andere Angriffe können auftreten, wenn bereits eine Abwehr vorhanden ist und daher von Beginn des Ereignisses an durch diese Regeln abgewehrt werden kann. Darüber hinaus können ratenbasierte Regeln in der Web-ACL- und Shield-Advanced-Regelgruppe den Angriffsverkehr abschwächen, bevor er als mögliches Ereignis erkannt wird.
+ Für Application Load Balancer, die jeglichen Datenverkehr über ein Content Delivery Network (CDN) empfangen, wie Amazon CloudFront, werden die automatischen Abwehrfunktionen von Shield Advanced auf Anwendungsebene für diese Application Load Balancer-Ressourcen reduziert. Shield Advanced verwendet Client-Datenverkehrsattribute, um den Angriffsverkehr zu identifizieren und vom normalen Datenverkehr an Ihre Anwendung zu isolieren, und behält die ursprünglichen Client-Traffic-Attribute CDNs möglicherweise nicht bei oder leitet sie weiter. Wenn Sie dies verwenden CloudFront, empfehlen wir, die automatische Abwehr für die CloudFront Verteilung zu aktivieren.
+ Die automatische Abwehr auf Anwendungsebene DDo S interagiert nicht mit Schutzgruppen. Sie können die automatische Abwehr für Ressourcen aktivieren, die sich in Schutzgruppen befinden, aber Shield Advanced wendet nicht automatisch Angriffsabwehrmaßnahmen an, die auf den Ergebnissen der Schutzgruppe basieren. Shield Advanced wendet automatische Angriffsabwehrmaßnahmen für einzelne Ressourcen an.
**Contents**
+ [Vorbehalte bei der Verwendung der automatischen Abwehr auf Anwendungsebene DDo S](#ddos-automatic-app-layer-response-caveats)
+ [Bewährte Methoden für die Verwendung der automatischen DDo Application-Layer-S-Abwehr](ddos-automatic-app-layer-response-bp.md)
+ [Aktivierung der automatischen Schadensbegrenzung auf Anwendungsebene DDo S](ddos-automatic-app-layer-response-config.md)
+ [Was passiert, wenn Sie die automatische Schadensbegrenzung aktivieren](ddos-automatic-app-layer-response-config.md#ddos-automatic-app-layer-response-enable)
+ [So verwaltet Shield Advanced die automatische Schadensbegrenzung](ddos-automatic-app-layer-response-behavior.md)
+ [So reagiert Shield Advanced mit automatischer Abwehr auf DDo S-Angriffe](ddos-automatic-app-layer-response-behavior.md#ddos-automatic-app-layer-response-ddos-attack)
+ [So verwaltet Shield Advanced die Einstellung für Regelaktionen](ddos-automatic-app-layer-response-behavior.md#ddos-automatic-app-layer-response-rule-action)
+ [So verwaltet Shield Advanced Abhilfemaßnahmen, wenn ein Angriff nachlässt](ddos-automatic-app-layer-response-behavior.md#ddos-automatic-app-layer-response-after-attack)
+ [Was passiert, wenn Sie die automatische Abwehr deaktivieren](ddos-automatic-app-layer-response-behavior.md#ddos-automatic-app-layer-response-disable)
+ [Schutz der Anwendungsebene mit der Shield Advanced-Regelgruppe](ddos-automatic-app-layer-response-rg.md)
+ [Konfiguration zur automatischen Abwehr der Anwendungsschicht DDo S für eine Ressource anzeigen](view-automatic-app-layer-response-configuration.md)
+ [Automatische Abwehr auf Anwendungsebene DDo S aktivieren und deaktivieren](enable-disable-automatic-app-layer-response.md)
+ [Änderung der Aktion, die für die automatische Abwehr von Anwendungsschicht DDo S verwendet wird](change-action-of-automatic-app-layer-response.md)
+ [Verwendung AWS CloudFormation mit automatischer DDo Application-Layer-S-Abwehr](manage-automatic-mitigation-in-cfn.md)
# Bewährte Methoden für die Verwendung der automatischen DDo Application-Layer-S-Abwehr
Halten Sie sich bei der Verwendung der automatischen Schadensbegrenzung an die Anweisungen in diesem Abschnitt.
**Verwaltung allgemeiner Schutzmaßnahmen**
Halten Sie sich bei der Planung und Implementierung Ihrer automatischen Schutzmaßnahmen an diese Richtlinien.
+ Verwalten Sie Ihren gesamten automatischen Schadensbegrenzungsschutz entweder über Shield Advanced oder, falls Sie Ihre Einstellungen AWS Firewall Manager zur automatischen Abwehr von Shield Advanced verwenden, über Firewall Manager. Verwenden Sie Shield Advanced und Firewall Manager nicht gleichzeitig, um diese Schutzmaßnahmen zu verwalten.
+ Verwalten Sie ähnliche Ressourcen mit denselben Web ACLs - und Schutzeinstellungen und verwalten Sie unterschiedliche Ressourcen mit unterschiedlichen Websites. ACLs Wenn Shield Advanced einen DDo S-Angriff auf eine geschützte Ressource abwehrt, definiert es Regeln für die Web-ACL, die der Ressource zugeordnet ist, und testet dann die Regeln anhand des Datenverkehrs aller Ressourcen, die mit der Web-ACL verknüpft sind. Shield Advanced wendet die Regeln nur an, wenn sie sich nicht negativ auf die zugehörigen Ressourcen auswirken. Weitere Informationen finden Sie unter [So verwaltet Shield Advanced die automatische Schadensbegrenzung](ddos-automatic-app-layer-response-behavior.md).
+ Aktivieren Sie für Application Load Balancer, deren gesamter Internetverkehr über eine CloudFront Amazon-Distribution weitergeleitet wird, nur die automatische Schadensbegrenzung für die Verteilung. CloudFront Die CloudFront Distribution wird immer über die größte Anzahl an ursprünglichen Datenverkehrsattributen verfügen, die Shield Advanced zur Abwehr von Angriffen nutzt.
**Optimierung der Erkennung und Abwehr**
Folgen Sie diesen Richtlinien, um den Schutz zu optimieren, den die automatische Schadensbegrenzung für geschützte Ressourcen bietet. Einen Überblick über die Erkennung und Abwehr auf Anwendungsebene finden Sie unter. [Liste der Faktoren, die die Erkennung und Minderung von Ereignissen auf Anwendungsebene mit Shield Advanced beeinflussen](ddos-app-layer-detection-mitigation.md)
+ Konfigurieren Sie Integritätsprüfungen für Ihre geschützten Ressourcen und verwenden Sie sie, um eine gesundheitsbasierte Erkennung in Ihren Shield Advanced-Schutzmaßnahmen zu ermöglichen. Anleitungen finden Sie unter [Gesundheitsbasierte Erkennung mithilfe von Zustandsprüfungen mit Shield Advanced und Route 53](ddos-advanced-health-checks.md).
+ Aktivieren Sie die automatische Schadensbegrenzung im Count Modus, bis Shield Advanced eine Ausgangsbasis für normalen, historischen Datenverkehr festgelegt hat. Shield Advanced benötigt zwischen 24 Stunden und 30 Tagen, um einen Basiswert festzulegen.
Um eine Basislinie für normale Verkehrsmuster zu erstellen, ist Folgendes erforderlich:
+ Die Zuordnung einer Web-ACL zur geschützten Ressource. Sie können sie AWS WAF direkt verwenden, um Ihre Web-ACL zuzuordnen, oder Sie können sie von Shield Advanced zuordnen lassen, wenn Sie den Shield Advanced-Schutz auf Anwendungsebene aktivieren und eine zu verwendende Web-ACL angeben.
+ Normaler Datenfluss zu Ihrer geschützten Anwendung. Wenn bei Ihrer Anwendung kein normaler Datenverkehr stattfindet, z. B. bevor die Anwendung gestartet wird, oder wenn es für längere Zeit zu wenig Produktionsdatenverkehr gibt, können die historischen Daten nicht erfasst werden.
**Verwaltung von Web-ACLS**
Folgen Sie diesen Richtlinien für die Verwaltung des Webs ACLs , das Sie mit automatischer Schadensbegrenzung verwenden.
+ Wenn Sie die Web-ACL, die der geschützten Ressource zugeordnet ist, ersetzen müssen, nehmen Sie die folgenden Änderungen der Reihe nach vor:
1. Deaktivieren Sie in Shield Advanced die automatische Schadensbegrenzung.
1. AWS WAF Trennen Sie in die alte Web-ACL und ordnen Sie die neue Web-ACL zu.
1. Aktivieren Sie in Shield Advanced die automatische Schadensbegrenzung.
Shield Advanced überträgt die automatische Abwehr nicht automatisch von der alten Web-ACL auf die neue.
+ Löschen Sie keine Regelgruppenregel aus Ihrer Website ACLs , deren Name mit `ShieldMitigationRuleGroup` beginnt. Wenn Sie diese Regelgruppe löschen, deaktivieren Sie den Schutz, der durch die automatische Schadensbegrenzung von Shield Advanced für jede Ressource bereitgestellt wird, die mit der Web-ACL verknüpft ist. Darüber hinaus kann es einige Zeit dauern, bis Shield Advanced eine Benachrichtigung über die Änderung erhält und die Einstellungen aktualisiert. Während dieser Zeit werden auf den Seiten der Shield Advanced-Konsole falsche Informationen angezeigt.
Weitere Informationen zur Regelgruppe finden Sie unter[Schutz der Anwendungsebene mit der Shield Advanced-Regelgruppe](ddos-automatic-app-layer-response-rg.md).
+ Ändern Sie nicht den Namen einer Regelgruppenregel, deren Name mit beginnt`ShieldMitigationRuleGroup`. Dies kann die Schutzmaßnahmen beeinträchtigen, die durch die automatische Abwehr von Shield Advanced über die Web-ACL bereitgestellt werden.
+ Verwenden Sie beim Erstellen von Regeln und Regelgruppen keine Namen, die mit beginnen. `ShieldMitigationRuleGroup` Diese Zeichenfolge wird von Shield Advanced verwendet, um Ihre automatischen Gegenmaßnahmen zu verwalten.
+ Weisen Sie bei der Verwaltung Ihrer Web-ACL-Regeln keine Prioritätseinstellung von 10.000.000 zu. Shield Advanced weist diese Prioritätseinstellung seiner Gruppenregel für automatische Schadensbegrenzung zu, wenn es sie hinzufügt.
+ Ordnen Sie der `ShieldMitigationRuleGroup` Regel eine Priorität zu, sodass sie im Verhältnis zu den anderen Regeln in Ihrer Web-ACL ausgeführt wird, wann Sie möchten. Shield Advanced fügt der Web-ACL die Regelgruppenregel mit der Priorität 10.000.000 hinzu, sodass sie nach Ihren anderen Regeln ausgeführt wird. Wenn Sie den AWS WAF Konsolenassistenten zur Verwaltung Ihrer Web-ACL verwenden, passen Sie die Prioritätseinstellungen nach dem Hinzufügen von Regeln zur Web-ACL nach Bedarf an.
+ Wenn Sie AWS CloudFormation Ihr Web verwalten ACLs, müssen Sie die `ShieldMitigationRuleGroup` Regelgruppenregel nicht verwalten. Folgen Sie den Anweisungen unter[Verwendung AWS CloudFormation mit automatischer DDo Application-Layer-S-Abwehr](manage-automatic-mitigation-in-cfn.md).
# Aktivierung der automatischen Schadensbegrenzung auf Anwendungsebene DDo S
Auf dieser Seite wird erklärt, wie Shield Advanced so konfiguriert wird, dass es automatisch auf Angriffe auf Anwendungsebene reagiert.
Sie aktivieren die automatische Abwehr von Shield Advanced als Teil des Schutzes der Anwendungsebene DDo S für Ihre Ressource. Informationen dazu, wie Sie dies über die Konsole tun können, finden Sie unter. [Konfigurieren Sie den Schutz der Anwendungsebene DDo S](manage-protection.md#configure-app-layer-protection)
Für die automatische Schadensbegrenzungsfunktion müssen Sie wie folgt vorgehen:
+ **Ordnen Sie der Ressource eine Web-ACL** zu — Dies ist für jeden Shield Advanced-Schutz auf Anwendungsebene erforderlich. Sie können dieselbe Web-ACL für mehrere Ressourcen verwenden. Wir empfehlen, dies nur für Ressourcen mit ähnlichem Datenverkehr zu tun. Informationen zum InternetACLs, einschließlich der Anforderungen für deren Verwendung mit mehreren Ressourcen, finden Sie unter[Wie AWS WAF funktioniert](how-aws-waf-works.md).
+ **Automatische Abwehr von Shield Advanced auf Anwendungsebene DDo S aktivieren und konfigurieren** — Wenn Sie diese Option aktivieren, geben Sie an, ob Shield Advanced Webanfragen, die als Teil eines DDo S-Angriffs eingestuft werden, automatisch blockieren oder zählen soll. Shield Advanced fügt der zugehörigen Web-ACL eine Regelgruppe hinzu und verwendet sie, um ihre Reaktion auf DDo S-Angriffe auf die Ressource dynamisch zu verwalten. Informationen zu den Aktionsoptionen für Regeln finden Sie unter[Verwenden von Regelaktionen in AWS WAF](waf-rule-action.md).
+ **(Optional, aber empfohlen) Fügen Sie der Web-ACL eine ratenbasierte Regel hinzu** — Standardmäßig bietet die ratenbasierte Regel Ihrer Ressource grundlegenden Schutz vor DDo S-Angriffen, indem sie verhindert, dass eine einzelne IP-Adresse in kurzer Zeit zu viele Anfragen sendet. Informationen zu ratenbasierten Regeln, einschließlich Optionen für die Aggregation benutzerdefinierter Anfragen und Beispiele, finden Sie unter. [Verwendung ratenbasierter Regelanweisungen in AWS WAF](waf-rule-statement-type-rate-based.md)
## Was passiert, wenn Sie die automatische Schadensbegrenzung aktivieren
Shield Advanced macht Folgendes, wenn Sie die automatische Schadensbegrenzung aktivieren:
+ **Fügt bei Bedarf eine Regelgruppe für die Verwendung von Shield Advanced** hinzu — Wenn die AWS WAF Web-ACL, die Sie der Ressource zugeordnet haben, nicht bereits über eine AWS WAF Regelgruppenregel verfügt, die der automatischen Abwehr von Anwendungsebenen DDo S gewidmet ist, fügt Shield Advanced eine hinzu.
Der Name der Regelgruppenregel beginnt mit`ShieldMitigationRuleGroup`. Die Regelgruppe enthält immer eine ratenbasierte Regel mit dem Namen`ShieldKnownOffenderIPRateBasedRule`, die das Volumen der Anfragen von IP-Adressen begrenzt, von denen bekannt ist, dass sie Quellen von DDo S-Angriffen sind. Weitere Informationen zur Shield Advanced-Regelgruppe und der Web-ACL-Regel, die auf sie verweist, finden Sie unter[Schutz der Anwendungsebene mit der Shield Advanced-Regelgruppe](ddos-automatic-app-layer-response-rg.md).
+ **Beginnt, auf DDo S-Angriffe gegen die Ressource zu reagieren** — Shield Advanced reagiert automatisch auf DDo S-Angriffe für die geschützte Ressource. Zusätzlich zu der ratenbasierten Regel, die immer vorhanden ist, verwendet Shield Advanced seine Regelgruppe, um benutzerdefinierte AWS WAF Regeln zur Abwehr von DDo S-Angriffen bereitzustellen. Shield Advanced passt diese Regeln an Ihre Anwendung und die Angriffe an, denen Ihre Anwendung ausgesetzt ist, und testet sie vor der Bereitstellung anhand des historischen Datenverkehrs der Ressource.
Shield Advanced verwendet eine einzige Regelgruppenregel in jeder Web-ACL, die Sie für die automatische Schadensbegrenzung verwenden. Wenn Shield Advanced die Regelgruppe für eine andere geschützte Ressource bereits hinzugefügt hat, fügt es der Web-ACL keine weitere Regelgruppe hinzu.
Die automatische Abwehr von Angriffen auf Anwendungsebene DDo S hängt vom Vorhandensein der Regelgruppe ab. Wenn die Regelgruppe aus irgendeinem Grund aus der AWS WAF Web-ACL entfernt wird, deaktiviert das Entfernen die automatische Abwehr für alle Ressourcen, die der Web-ACL zugeordnet sind.
# So verwaltet Shield Advanced die automatische Schadensbegrenzung
In den Themen in diesem Abschnitt wird beschrieben, wie Shield Advanced Ihre Konfigurationsänderungen für die automatische Abwehr von DDo Anwendungsebenen verarbeitet und wie DDo S-Angriffe behandelt werden, wenn die automatische Abwehr aktiviert ist.
**Topics**
+ [So reagiert Shield Advanced mit automatischer Abwehr auf DDo S-Angriffe](#ddos-automatic-app-layer-response-ddos-attack)
+ [So verwaltet Shield Advanced die Einstellung für Regelaktionen](#ddos-automatic-app-layer-response-rule-action)
+ [So verwaltet Shield Advanced Abhilfemaßnahmen, wenn ein Angriff nachlässt](#ddos-automatic-app-layer-response-after-attack)
+ [Was passiert, wenn Sie die automatische Abwehr deaktivieren](#ddos-automatic-app-layer-response-disable)
## So reagiert Shield Advanced mit automatischer Abwehr auf DDo S-Angriffe
Wenn Sie die automatische Risikominderung für eine geschützte Ressource aktiviert haben, reagiert die ratenbasierte Regel `ShieldKnownOffenderIPRateBasedRule` in der Shield Advanced-Regelgruppe automatisch auf erhöhte Datenverkehrsmengen aus bekannten DDo S-Quellen. Diese Ratenbegrenzung wird schnell angewendet und dient als Schutz an vorderster Front gegen Angriffe.
Wenn Shield Advanced einen Angriff erkennt, geht es wie folgt vor:
1. Versucht, eine Angriffssignatur zu identifizieren, die den Angriffsverkehr vom normalen Datenverkehr zu Ihrer Anwendung isoliert. Ziel ist es, hochwertige DDo S-Abwehrregeln zu erstellen, die, wenn sie platziert werden, nur den Angriffsverkehr betreffen und den normalen Datenverkehr zu Ihrer Anwendung nicht beeinträchtigen.
1. Vergleicht die identifizierte Angriffssignatur anhand der historischen Datenverkehrsmuster für die angegriffene Ressource sowie für alle anderen Ressourcen, die derselben Web-ACL zugeordnet sind. Shield Advanced tut dies, bevor es irgendwelche Regeln als Reaktion auf das Ereignis einsetzt.
Abhängig von den Evaluierungsergebnissen führt Shield Advanced eine der folgenden Aktionen aus:
+ Wenn Shield Advanced feststellt, dass die Angriffssignatur nur den Datenverkehr isoliert, der an dem DDo S-Angriff beteiligt ist, implementiert Shield Advanced die Signatur in AWS WAF Regeln in der Regelgruppe Shield Advanced-Mitigation in der Web-ACL. Shield Advanced gibt diesen Regeln die Aktionseinstellung, die Sie für die automatische Risikominderung der Ressource konfiguriert haben — entweder Count oderBlock.
+ Andernfalls führt Shield Advanced keine Abschwächung durch.
Während eines Angriffs sendet Shield Advanced dieselben Benachrichtigungen und stellt dieselben Ereignisinformationen bereit wie für grundlegende Shield Advanced-Schutzmaßnahmen auf Anwendungsebene. Sie können die Informationen über Ereignisse und DDo S-Angriffe sowie über alle Shield Advanced-Abhilfemaßnahmen für Angriffe in der Shield Advanced-Ereigniskonsole einsehen. Weitere Informationen finden Sie unter [Einblick in DDo S-Ereignisse mit Shield Advanced](ddos-viewing-events.md).
Wenn Sie die automatische Schadensbegrenzung so konfiguriert haben, dass sie die Block Regelaktion verwendet, und Sie aufgrund der von Shield Advanced bereitgestellten Risikominderungsregeln Fehlalarme erhalten, können Sie die Regelaktion in ändern. Count Informationen dazu finden Sie unter. [Änderung der Aktion, die für die automatische Abwehr von Anwendungsschicht DDo S verwendet wird](change-action-of-automatic-app-layer-response.md)
## So verwaltet Shield Advanced die Einstellung für Regelaktionen
Sie können die Regelaktion für Ihre automatischen Abhilfemaßnahmen auf Block oder festlegen. Count
Wenn Sie die Aktionseinstellung der automatischen Schadensbegrenzungsregel für eine geschützte Ressource ändern, aktualisiert Shield Advanced alle Regeleinstellungen für die Ressource. Es aktualisiert alle Regeln, die derzeit für die Ressource in der Shield Advanced-Regelgruppe gelten, und verwendet die neue Aktionseinstellung, wenn es neue Regeln erstellt.
Wenn Sie für Ressourcen, die dieselbe Web-ACL verwenden, unterschiedliche Aktionen angeben, verwendet Shield Advanced die Block Aktionseinstellung für die ratenbasierte Regel der Regelgruppe. `ShieldKnownOffenderIPRateBasedRule` Shield Advanced erstellt und verwaltet andere Regeln in der Regelgruppe im Namen einer bestimmten geschützten Ressource und verwendet die Aktionseinstellung, die Sie für die Ressource angegeben haben. Alle Regeln in der Shield Advanced-Regelgruppe in einer Web-ACL werden auf den Webverkehr aller zugehörigen Ressourcen angewendet.
Es kann einige Sekunden dauern, bis die Änderung der Aktionseinstellung wirksam wird. Während dieser Zeit werden Sie möglicherweise an einigen Stellen, an denen die Regelgruppe verwendet wird, die alte Einstellung und an anderen Stellen die neue Einstellung sehen.
Sie können die Einstellung für die Regelaktion für Ihre automatische Schadensbegrenzungskonfiguration auf der Ereignisseite der Konsole und auf der Konfigurationsseite der Anwendungsebene ändern. Informationen zur Seite „Ereignisse“ finden Sie unter[Reagieren auf DDo S-Ereignisse in AWS](ddos-responding.md). Informationen zur Konfigurationsseite finden Sie unter[Konfigurieren Sie den Schutz der Anwendungsebene DDo S](manage-protection.md#configure-app-layer-protection).
## So verwaltet Shield Advanced Abhilfemaßnahmen, wenn ein Angriff nachlässt
Wenn Shield Advanced feststellt, dass Abwehrregeln, die für einen bestimmten Angriff eingesetzt wurden, nicht mehr benötigt werden, werden sie aus der Shield Advanced-Regelgruppe zur Schadensbegrenzung entfernt.
Das Entfernen von Regeln zur Schadensbegrenzung wird nicht unbedingt mit dem Ende eines Angriffs zusammenfallen. Shield Advanced überwacht Angriffsmuster, die es auf Ihren geschützten Ressourcen erkennt. Es kann sich proaktiv gegen die Wiederholung eines Angriffs mit einer bestimmten Signatur schützen, indem es die Regeln beibehält, die es gegen das erste Auftreten dieses Angriffs angewendet hat. Bei Bedarf verlängert Shield Advanced das Zeitfenster, in dem die Regeln eingehalten werden. Auf diese Weise kann Shield Advanced wiederholte Angriffe mit einer bestimmten Signatur abwehren, bevor sie sich auf Ihre geschützten Ressourcen auswirken.
Shield Advanced entfernt niemals die ratenbasierte Regel`ShieldKnownOffenderIPRateBasedRule`, die das Volumen der Anfragen von IP-Adressen begrenzt, von denen bekannt ist, dass sie Quellen von DDo S-Angriffen sind.
## Was passiert, wenn Sie die automatische Abwehr deaktivieren
Shield Advanced macht Folgendes, wenn Sie die automatische Schadensbegrenzung für eine Ressource deaktivieren:
+ **Reagiert nicht mehr automatisch auf DDo S-Angriffe** — Shield Advanced stellt seine automatischen Reaktionsaktivitäten für die Ressource ein.
+ **Entfernt nicht benötigte Regeln aus der Shield Advanced-Regelgruppe** — Wenn Shield Advanced Regeln in seiner verwalteten Regelgruppe im Namen der geschützten Ressource verwaltet, werden sie entfernt.
+ **Entfernt die Shield Advanced-Regelgruppe, wenn sie nicht mehr verwendet** wird — Wenn die Web-ACL, die Sie der Ressource zugeordnet haben, keiner anderen Ressource zugeordnet ist, für die automatische Schadensbegrenzung aktiviert ist, entfernt Shield Advanced ihre Regelgruppenregel aus der Web-ACL.
# Schutz der Anwendungsebene mit der Shield Advanced-Regelgruppe
Auf dieser Seite wird erklärt, wie die Shield Advanced-Regelgruppe in Ihrer Web-ACL funktioniert.
Shield Advanced verwaltet automatische Minderungsaktivitäten mithilfe von Regeln in einer Regelgruppe, die es besitzt und für Sie verwaltet. Shield Advanced verweist auf die Regelgruppe mit einer Regel in der Web-ACL, die Sie mit Ihrer geschützten Ressource verknüpft haben.
**Die Regelgruppenregel in Ihrer Web-ACL**
Die Shield Advanced-Regelgruppenregel in Ihrer Web-ACL hat die folgenden Eigenschaften:
+ **Name (Name** – `ShieldMitigationRuleGroup``_account-id_web-acl-id_unique-identifier`
+ **Web-ACL-Kapazitätseinheiten (WCU)** — 150. Diese werden WCUs auf die WCU-Nutzung in Ihrer Web-ACL angerechnet.
Shield Advanced erstellt diese Regel in Ihrer Web-ACL mit einer Prioritätseinstellung von 10.000.000, sodass sie nach Ihren anderen Regeln und Regelgruppen in der Web-ACL ausgeführt wird. AWS WAF führt die Regeln in einer Web-ACL ab der Einstellung mit der niedrigsten numerischen Priorität aus. Während der Verwaltung der Web-ACL kann sich diese Prioritätseinstellung ändern.
Die automatische Schadensbegrenzungsfunktion verbraucht keine zusätzlichen AWS WAF Ressourcen in Ihrem Konto, mit Ausnahme der Ressourcen, die von der Regelgruppe in Ihrer Web-ACL WCUs verwendet werden. Beispielsweise wird die Shield Advanced-Regelgruppe nicht zu den Regelgruppen Ihres Kontos gezählt. Informationen zu Kontolimits in AWS WAF finden Sie unter[AWS WAF Kontingente](limits.md).
**Regeln in der Regelgruppe**
Innerhalb der referenzierten Shield Advanced-Regelgruppe unterhält Shield Advanced eine ratenbasierte Regel`ShieldKnownOffenderIPRateBasedRule`, die das Volumen der Anfragen von IP-Adressen begrenzt, von denen bekannt ist, dass sie Quellen von DDo S-Angriffen sind. Diese Regel dient als erste Verteidigungslinie gegen Angriffe, da sie in der Regelgruppe immer präsent ist und sich nicht auf die Analyse von Datenverkehrsmustern stützt, um Angriffe einzudämmen. Die Aktion dieser Regel ist wie bei den anderen Regeln in der Regelgruppe auf die Aktion festgelegt, die Sie für Ihre automatischen Abhilfemaßnahmen auswählen. Weitere Informationen über ratenbasierte Regeln finden Sie unter [Verwendung ratenbasierter Regelanweisungen in AWS WAF](waf-rule-statement-type-rate-based.md).
**Anmerkung**
Die ratenbasierte Regel `ShieldKnownOffenderIPRateBasedRule` funktioniert unabhängig von der Shield Advanced-Ereigniserkennung. Die automatische Abwehr ist zwar aktiviert, diese Regelrate begrenzt jedoch IP-Adressen, von denen bekannt ist, dass sie Quellen von DDo S-Angriffen sind. Bei diesen IP-Adressen kann die Ratenbegrenzung der Regel Angriffe verhindern und auch verhindern, dass Angriffe in den Erkennungsinformationen von Shield Advanced erscheinen. Bei diesem Kompromiss wird die Prävention der vollständigen Transparenz der Angriffsmuster vorgezogen.
Zusätzlich zu der oben beschriebenen permanenten ratenbasierten Regel enthält die Regelgruppe alle Regeln, die Shield Advanced derzeit zur Abwehr DDo von S-Angriffen verwendet. Shield Advanced fügt diese Regeln nach Bedarf hinzu, ändert und entfernt sie. Weitere Informationen finden Sie unter [So verwaltet Shield Advanced die automatische Schadensbegrenzung](ddos-automatic-app-layer-response-behavior.md).
**Kennzahlen**
Die Regelgruppe generiert AWS WAF Metriken, aber da diese Regelgruppe Shield Advanced gehört, können diese Metriken nicht angezeigt werden. Weitere Informationen finden Sie unter [AWS WAF Metriken und Dimensionen](waf-metrics.md).
# Konfiguration zur automatischen Abwehr der Anwendungsschicht DDo S für eine Ressource anzeigen
Auf der Seite Geschützte **Ressourcen und auf den Seiten mit den einzelnen Schutzmaßnahmen** können Sie sich die Konfiguration der automatischen Schadensbegrenzung für Anwendungen auf Layer DDo S für eine Ressource ansehen.
**So zeigen Sie die Konfiguration der automatischen Schadensbegrenzung auf Anwendungsebene DDo S an**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die AWS WAF & Shield-Konsole unter [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. Wählen Sie im AWS Shield Navigationsbereich **Geschützte Ressourcen** aus. In der Liste der geschützten Ressourcen gibt die Spalte **Automatische Abwehr der Anwendungsschicht DDo S** an, ob die automatische Risikominderung aktiviert ist und, sofern aktiviert, welche Aktion Shield Advanced bei seinen Abhilfemaßnahmen verwenden soll.
Sie können auch eine beliebige Ressource auf Anwendungsebene auswählen, um dieselben Informationen auf der Schutzseite für die Ressource anzuzeigen.
# Automatische Abwehr auf Anwendungsebene DDo S aktivieren und deaktivieren
Das folgende Verfahren zeigt, wie Sie die automatische Antwort für eine geschützte Ressource aktivieren oder deaktivieren.
**Um die automatische Abwehr auf Anwendungsebene DDo S für eine einzelne Ressource zu aktivieren oder zu deaktivieren**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die AWS WAF & Shield-Konsole unter [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. Wählen Sie im AWS Shield Navigationsbereich die Option **Geschützte Ressourcen** aus.
1. Wählen Sie auf der Registerkarte **Schutz** die Ressource auf Anwendungsebene aus, für die Sie die automatische Schadensbegrenzung aktivieren möchten. Die Seite mit den Schutzmaßnahmen für die Ressource wird geöffnet.
1. **Wählen Sie auf der Schutzseite der Ressource die Option Bearbeiten aus.**
1. Wählen Sie auf der Seite ** DDoLayer-7-S-Abwehr für globale Ressourcen konfigurieren — *optional*** für **Automatische Schadensbegrenzung auf Anwendungsebene DDo** die Option aus, die Sie für automatische Abwehr verwenden möchten. In der Konsole stehen die folgenden Optionen zur Verfügung:
+ **Aktuelle Einstellungen beibehalten** — Nehmen Sie keine Änderungen an den Einstellungen für die automatische Schadensbegrenzung der geschützten Ressource vor.
+ **Aktivieren** — Aktiviert die automatische Schadensbegrenzung für die geschützte Ressource. Wenn Sie diese Option wählen, wählen Sie in den Web-ACL-Regeln auch die Regelaktion aus, die von den automatischen Risikominderungen verwendet werden soll. Weitere Informationen zu Einstellungen für Regelaktionen finden Sie unter [Verwenden von Regelaktionen in AWS WAF](waf-rule-action.md).
Wenn Ihre geschützte Ressource noch keinen Verlauf des normalen Anwendungsverkehrs hat, aktivieren Sie die automatische Schadensbegrenzung im Count Modus, bis Shield Advanced einen Basiswert festlegen kann. Shield Advanced beginnt mit der Erfassung von Informationen für seine Baseline, wenn Sie Ihrer geschützten Ressource eine Web-ACL zuordnen. Es kann 24 Stunden bis 30 Tage dauern, bis eine gute Ausgangsbasis für normalen Datenverkehr erstellt ist.
+ **Deaktivieren** — Deaktiviert die automatische Schadensbegrenzung für die geschützte Ressource.
1. Gehen Sie die restlichen Seiten durch, bis Sie fertig sind, und speichern Sie die Konfiguration.
Auf der Seite **Schutzmaßnahmen werden** die Einstellungen für die automatische Schadensbegrenzung für die Ressource aktualisiert.
# Änderung der Aktion, die für die automatische Abwehr von Anwendungsschicht DDo S verwendet wird
Sie können die Aktion, die Shield Advanced für seine automatische Antwort auf Anwendungsebene verwendet, an mehreren Stellen in der Konsole ändern:
+ **Konfiguration der automatischen Schadensbegrenzung** — Ändern Sie die Aktion, wenn Sie die automatische Schadensbegrenzung für Ihre Ressource konfigurieren. Das Verfahren finden Sie im vorherigen Abschnitt. [Automatische Abwehr auf Anwendungsebene DDo S aktivieren und deaktivieren](enable-disable-automatic-app-layer-response.md)
+ **Seite mit den Ereignisdetails** — Ändern Sie die Aktion auf der Seite mit den Ereignisdetails, wenn Sie die Ereignisinformationen in der Konsole anzeigen. Weitere Informationen finden Sie unter [AWS Shield Advanced Veranstaltungsdetails anzeigen](ddos-event-details.md).
Wenn Sie über zwei geschützte Ressourcen verfügen, die sich eine Web-ACL teilen, und Sie die Aktion für die eine und Count Block für die andere auf setzen, legt Shield Advanced die Aktion für die ratenbasierte Regel `ShieldKnownOffenderIPRateBasedRule` der Regelgruppe auf fest. Block
# Verwendung AWS CloudFormation mit automatischer DDo Application-Layer-S-Abwehr
Auf dieser Seite wird erklärt, wie Sie CloudFormation Ihre Schutzmaßnahmen und AWS WAF Ihr Internet verwalten können. ACLs
**Automatische Schadensbegrenzung auf Anwendungsebene DDo S aktivieren oder deaktivieren**
Sie können die automatische Risikominderung auf Anwendungsebene DDo S mithilfe der Ressource aktivieren AWS CloudFormation und deaktivieren. `AWS::Shield::Protection` Der Effekt ist derselbe wie bei der Aktivierung oder Deaktivierung der Funktion über die Konsole oder eine andere Schnittstelle. Informationen zu der CloudFormation Ressource finden Sie [AWS::Shield::Protection](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-shield-protection.html)im *AWS CloudFormation Benutzerhandbuch*.
**Verwaltung der Internetnutzung ACLs mit automatischer Schadensbegrenzung**
Shield Advanced verwaltet die automatische Schadensbegrenzung für Ihre geschützte Ressource mithilfe einer Regelgruppenregel in der AWS WAF Web-ACL der geschützten Ressource. Über die AWS WAF Konsole und Sie sehen die Regel APIs, die in Ihren Web-ACL-Regeln aufgeführt ist, mit einem Namen, der mit `ShieldMitigationRuleGroup` beginnt. Diese Regel ist für Ihre automatische Schadensbegrenzung auf Anwendungsebene DDo S vorgesehen und wird von Shield Advanced und AWS WAF für Sie verwaltet. Weitere Informationen erhalten Sie unter [Schutz der Anwendungsebene mit der Shield Advanced-Regelgruppe](ddos-automatic-app-layer-response-rg.md) und [So verwaltet Shield Advanced die automatische Schadensbegrenzung](ddos-automatic-app-layer-response-behavior.md).
Wenn Sie CloudFormation Ihr Web verwalten ACLs, fügen Sie die Shield Advanced-Regelgruppenregel nicht zu Ihrer Web-ACL-Vorlage hinzu. Wenn Sie eine Web-ACL aktualisieren, die mit Ihren automatischen Schutzmaßnahmen verwendet wird, verwaltet AWS WAF automatisch die Regelgruppenregel in der Web-ACL.
Im Vergleich zu anderen Websites, über die Sie die Verwaltung durchführen, werden Sie ACLs die folgenden Unterschiede feststellen: CloudFormation
+ CloudFormation meldet keine Abweichung im Stack-Drift-Status zwischen der tatsächlichen Konfiguration der Web-ACL mit der Shield Advanced-Regelgruppenregel und Ihrer Web-ACL-Vorlage ohne die Regel. Die Shield Advanced-Regel wird nicht in der tatsächlichen Liste für die Ressource in den Drift-Details angezeigt.
Sie können die Shield Advanced-Regelgruppenregel in Web-ACL-Auflistungen sehen AWS WAF, aus denen Sie sie abrufen, z. B. über die AWS WAF Konsole oder AWS WAF APIs.
+ Wenn Sie die Web-ACL-Vorlage in einem Stapel ändern, AWS WAF behält Shield Advanced automatisch die automatische Schadensbegrenzungsregel von Shield Advanced in der aktualisierten Web-ACL bei. Die von Shield Advanced bereitgestellten automatischen Schutzmaßnahmen zur Schadensbegrenzung werden durch Ihr Update der Web-ACL nicht unterbrochen.
Verwalten Sie die Shield Advanced-Regel nicht in Ihrer CloudFormation Web-ACL-Vorlage. Die Web-ACL-Vorlage sollte die Shield Advanced-Regel nicht auflisten. Folgen Sie den bewährten Methoden für die Verwaltung von Web-ACLS unter[Bewährte Methoden für die Verwendung der automatischen DDo Application-Layer-S-Abwehr](ddos-automatic-app-layer-response-bp.md).
# Gesundheitsbasierte Erkennung mithilfe von Zustandsprüfungen mit Shield Advanced und Route 53
Sie können Shield Advanced so konfigurieren, dass es eine gesundheitsbasierte Erkennung verwendet, um die Reaktionsfähigkeit und Genauigkeit bei der Erkennung und Abwehr von Angriffen zu verbessern. Sie können diese Option für jeden Ressourcentyp außer für gehostete Route 53-Zonen verwenden.
Um die zustandsbasierte Erkennung zu konfigurieren, definieren Sie eine Zustandsprüfung für Ihre Ressource in Route 53, stellen sicher, dass sie als fehlerfrei gemeldet wird, und verknüpfen sie dann mit Ihrem Shield Advanced-Schutz. Informationen zu Route 53-Zustandsprüfungen finden Sie unter [So überprüft Amazon Route 53 den Zustand Ihrer Ressourcen](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/welcome-health-checks.html) und [Erstellen, Aktualisieren und Löschen von Zustandsprüfungen](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating-deleting.html) im Amazon Route 53-Entwicklerhandbuch.
**Anmerkung**
Für den proaktiven Engagement-Support des Shield Response Teams (SRT) sind Gesundheitschecks erforderlich. Informationen zu proaktivem Engagement finden Sie unter[Einrichtung eines proaktiven Engagements für das SRT, um Sie direkt zu kontaktieren](ddos-srt-proactive-engagement.md).
Gesundheitschecks messen den Zustand Ihrer Ressourcen auf der Grundlage der von Ihnen definierten Anforderungen. Der Status der Integritätsprüfung liefert wichtige Informationen zu den Erkennungsmechanismen von Shield Advanced, sodass sie besser auf den aktuellen Status Ihrer spezifischen Anwendungen reagieren können.
Sie können die zustandsbasierte Erkennung für jeden Ressourcentyp aktivieren, mit Ausnahme von Route 53-Hosting-Zonen.
+ **Ressourcen auf Netzwerk- und Transportebene (Layer 3/Layer 4)** — Health-based Detection verbessert die Genauigkeit der Erkennung und Abwehr von Ereignissen auf Netzwerk- und Transportebene für Network Load Balancer, Elastic IP-Adressen und Global Accelerator-Standardbeschleuniger. Wenn Sie diese Ressourcentypen mit Shield Advanced schützen, kann Shield Advanced Abwehr für kleinere Angriffe und schnellere Abwehr von Angriffen bieten, selbst wenn der Datenverkehr innerhalb der Kapazität der Anwendung liegt.
Wenn Sie eine zustandsbasierte Erkennung hinzufügen, kann Shield Advanced in Zeiten, in denen die zugehörige Zustandsprüfung fehlerhaft ist, Schutzmaßnahmen noch schneller und bei noch niedrigeren Schwellenwerten vornehmen.
+ **Ressourcen auf Anwendungsebene (Schicht 7)** — Die auf Integrität basierende Erkennung verbessert die Genauigkeit der Erkennung von Fluten von Webanfragen für CloudFront Distributionen und Application Load Balancer. Wenn Sie diese Ressourcentypen mit Shield Advanced schützen, erhalten Sie Warnmeldungen zur Fluterkennung von Webanfragen, wenn es eine statistisch signifikante Abweichung im Verkehrsvolumen gibt, die mit signifikanten Änderungen der Verkehrsmuster kombiniert wird, basierend auf den Anforderungsmerkmalen.
Wenn die zugehörige Route 53-Zustandsprüfung fehlerhaft ist, benötigt Shield Advanced bei zustandsbasierter Erkennung kleinere Abweichungen, um eine Warnung zu erhalten, und Ereignisse werden schneller gemeldet. Umgekehrt, wenn die zugehörige Route 53-Zustandsprüfung fehlerfrei ist, benötigt Shield Advanced größere Abweichungen, um eine Warnung auszulösen.
Sie profitieren am meisten von der Verwendung einer Integritätsprüfung mit Shield Advanced, wenn die Integritätsprüfung nur dann fehlerfrei meldet, wenn Ihre Anwendung innerhalb akzeptabler Parameter läuft, und nur dann fehlerhaft meldet, wenn dies nicht der Fall ist. Verwenden Sie die Anleitungen in diesem Abschnitt, um Ihre Zuordnungen für Gesundheitsprüfungen in Shield Advanced zu verwalten.
**Anmerkung**
Shield Advanced verwaltet Ihre Gesundheitschecks nicht automatisch.
Folgendes ist erforderlich, um einen Gesundheitscheck mit Shield Advanced zu verwenden:
+ Der Gesundheitscheck muss als fehlerfrei gemeldet werden, wenn Sie ihn mit Ihrem Shield Advanced-Schutz verknüpfen.
+ Der Gesundheitscheck muss für den Zustand Ihrer geschützten Ressource relevant sein. Sie sind dafür verantwortlich, Integritätsprüfungen zu definieren und durchzuführen, mit denen der Zustand Ihrer Anwendung auf der Grundlage der spezifischen Anforderungen Ihrer Anwendung genau gemeldet wird.
+ Der Gesundheitscheck muss weiterhin für den Shield Advanced-Schutz verfügbar sein. Löschen Sie keine Zustandsprüfung in Route 53, die Sie für einen Shield Advanced-Schutz verwenden.
**Contents**
+ [Bewährte Methoden für die Verwendung von Gesundheitschecks mit Shield Advanced](health-checks-best-practices.md)
+ [CloudWatch Metriken, die häufig für Zustandsprüfungen mit Shield Advanced verwendet werden](health-checks-metrics.md)
+ [Metriken, die zur Überwachung des Anwendungszustands verwendet werden](health-checks-metrics.md#health-checks-metrics-common)
+ [CloudWatch Amazon-Metriken für jeden Ressourcentyp](health-checks-metrics.md#health-checks-protected-resource-metrics)
+ [Einen Gesundheitscheck mit Ihrer durch Shield Advanced geschützten Ressource verknüpfen](associate-health-check.md)
+ [Trennen einer Zustandsprüfung mit Ihrer durch Shield Advanced geschützten Ressource](disassociate-health-check.md)
+ [Status der Zuordnungen zur Gesundheitsprüfung in Shield Advanced anzeigen](health-check-association-status.md)
+ [Beispiele für Gesundheitschecks für Shield Advanced](health-checks-examples.md)
+ [CloudFront Amazon-Distributionen](health-checks-examples.md#health-checks-example-cloudfront)
+ [Load Balancers](health-checks-examples.md#health-checks-example-load-balancer)
+ [EC2 Elastische IP-Adresse (EIP) von Amazon](health-checks-examples.md#health-checks-example-elastic-ip)
# Bewährte Methoden für die Verwendung von Gesundheitschecks mit Shield Advanced
Folgen Sie den bewährten Methoden in diesem Abschnitt, wenn Sie Gesundheitschecks mit Shield Advanced erstellen und verwenden.
+ Planen Sie Ihre Integritätsprüfungen, indem Sie die Komponenten Ihrer Infrastruktur identifizieren, die Sie überwachen möchten. Ziehen Sie die folgenden Ressourcentypen für Integritätsprüfungen in Betracht:
+ Kritische Ressourcen.
+ Alle Ressourcen, bei denen Sie eine höhere Sensitivität für die Erkennung und Abwehr von Shield Advanced wünschen.
+ Ressourcen, für die Shield Advanced Sie proaktiv kontaktieren soll. Das proaktive Engagement hängt vom Status Ihrer Gesundheitschecks ab.
Zu den Ressourcen, die Sie möglicherweise überwachen möchten, gehören CloudFront Amazon-Distributionen, mit dem Internet verbundene Load Balancer und Amazon EC2-Instances.
+ Definieren Sie Integritätsprüfungen, die den Zustand Ihrer Anwendung genau wiedergeben und so wenige Benachrichtigungen wie möglich enthalten.
+ Schreiben Sie Integritätsprüfungen so, dass sie nur dann fehlerhaft sind, wenn Ihre Anwendung nicht verfügbar ist oder nicht innerhalb akzeptabler Parameter funktioniert. Sie sind dafür verantwortlich, Zustandsprüfungen auf der Grundlage der spezifischen Anforderungen Ihrer Anwendung zu definieren und durchzuführen.
+ Verwenden Sie so wenige Zustandsprüfungen wie möglich und berichten Sie dennoch genau über den Zustand Ihrer Anwendung. Beispielsweise können mehrere Alarme aus mehreren Bereichen Ihrer Anwendung, die alle dasselbe Problem melden, Ihre Reaktionsaktivitäten unnötig belasten, ohne dass ein zusätzlicher Informationswert entsteht.
+ Verwenden Sie berechnete Zustandsprüfungen, um den Zustand von Anwendungen anhand einer Kombination von CloudWatch Amazon-Metriken zu überwachen. Sie können beispielsweise die kombinierte Systemintegrität auf der Grundlage der Latenz Ihrer Anwendungsserver und ihrer Fehlerraten von 5xx berechnen, was darauf hindeutet, dass der Ursprungsserver die Anfrage nicht erfüllt hat.
+ Erstellen und veröffentlichen Sie nach Bedarf Ihre eigenen Anwendungszustandsindikatoren in Form von CloudWatch benutzerdefinierten Messwerten und verwenden Sie diese in einer berechneten Zustandsprüfung.
+ Implementieren und verwalten Sie Ihre Integritätsprüfungen, um die Erkennung zu verbessern und unnötige Wartungsarbeiten zu reduzieren.
+ Bevor Sie einen Gesundheitscheck mit einem Shield Advanced-Schutz verknüpfen, stellen Sie sicher, dass er sich in einem fehlerfreien Zustand befindet. Wenn Sie eine Zustandsprüfung zuordnen, die als fehlerhaft gemeldet wird, kann dies die Erkennungsmechanismen von Shield Advanced für Ihre geschützten Ressourcen verzerren.
+ Halten Sie Ihre Gesundheitschecks für Shield Advanced verfügbar. Löschen Sie keine Zustandsprüfung in Route 53, die Sie für einen Shield Advanced-Schutz verwenden.
+ Verwenden Sie Staging- und Testumgebungen nur, um Ihre Integritätsprüfungen zu testen. Pflegen Sie Integritätsprüfungszuordnungen nur für Umgebungen, die Leistung und Verfügbarkeit auf Produktionsebene erfordern. Behalten Sie in Shield Advanced für Staging- und Testumgebungen keine Integritätsprüfzuordnungen bei.
# CloudWatch Metriken, die häufig für Zustandsprüfungen mit Shield Advanced verwendet werden
In diesem Abschnitt sind die CloudWatch Amazon-Metriken aufgeführt, die häufig bei Integritätsprüfungen verwendet werden, um den Zustand von Anwendungen bei Distributed-Denial-of-Service (DDoS) -Ereignissen zu messen. Vollständige Informationen zu den CloudWatch Metriken für jeden Ressourcentyp finden Sie in der Liste, die der Tabelle folgt.
**Topics**
+ [Metriken, die zur Überwachung des Anwendungszustands verwendet werden](#health-checks-metrics-common)
+ [CloudWatch Amazon-Metriken für jeden Ressourcentyp](#health-checks-protected-resource-metrics)
## Metriken, die zur Überwachung des Anwendungszustands verwendet werden
| Ressource | Metrik | Description |
| --- | --- | --- |
| Route 53 | `HealthCheckStatus` | Der Status des Endpunkts für die Integritätsprüfung. |
| CloudFront | `5xxErrorRate` | Der Prozentsatz aller Anfragen, für die der HTTP-Statuscode 5xx lautet. Dies deutet auf einen Angriff hin, der sich auf die Anwendung auswirkt. |
| Application Load Balancer | `HTTPCode_ELB_5XX_Count` | Die Anzahl der vom Load Balancer generierten HTTP 5xx-Client-Fehlercodes. |
| Application Load Balancer | `RejectedConnectionCount` | Die Anzahl der Verbindungen, die abgelehnt wurden, weil der Load Balancer seine maximale Anzahl von Verbindungen erreicht hat. |
| Application Load Balancer | `TargetConnectionErrorCount` | Die Anzahl der Verbindungen, die zwischen dem Load Balancer und dem Ziel nicht erfolgreich hergestellt wurden. |
| Application Load Balancer | `TargetResponseTime` | Die verstrichene Zeit in Sekunden, nachdem die Anfrage den Load Balancer verlassen hat und eine Antwort vom Ziel erhalten hat. |
| Application Load Balancer | `UnHealthyHostCount` | Die Anzahl der als instabil betrachteten Ziele. |
| Amazon EC2 | `CPUUtilization` | Der Prozentsatz der zugewiesenen EC2 Recheneinheiten, die derzeit verwendet werden. |
## CloudWatch Amazon-Metriken für jeden Ressourcentyp
Weitere Informationen zu den Metriken, die für Ihre geschützten Ressourcen verfügbar sind, finden Sie in den folgenden Abschnitten der Ressourcenhandbücher:
+ Amazon Route 53 — [Überwachung Ihrer Ressourcen mit Amazon Route 53-Zustandsprüfungen und Amazon CloudWatch](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/monitoring-cloudwatch.html) im Amazon Route 53-Entwicklerhandbuch.
+ Amazon CloudFront — [Monitoring CloudFront mit Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/monitoring-using-cloudwatch.html) im Amazon CloudFront Developer Guide.
+ Application Load Balancer — [CloudWatch Metriken für Ihren Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html) im Benutzerhandbuch für Application Load Balancer.
+ Network Load Balancer — [CloudWatch Metriken für Ihren Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-cloudwatch-metrics.html) im Benutzerhandbuch für Network Load Balancer.
+ AWS Global Accelerator — [Verwendung von Amazon CloudWatch mit AWS Global Accelerator](https://docs.aws.amazon.com/global-accelerator/latest/dg/cloudwatch-monitoring.html) im AWS Global Accelerator Developer Guide.
+ Amazon Elastic Compute Cloud — [Listet die verfügbaren CloudWatch Metriken für Ihre Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html) in der https://docs.aws.amazon.com/AWSEC2/ neuesten UserGuide Version auf/ /.
+ Amazon EC2 Auto Scaling — [ CloudWatch Monitoring-Metriken für Ihre Auto Scaling Scaling-Gruppen und -Instances](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html) im Amazon EC2 Auto Scaling Scaling-Benutzerhandbuch.
# Einen Gesundheitscheck mit Ihrer durch Shield Advanced geschützten Ressource verknüpfen
Das folgende Verfahren zeigt, wie Sie eine Amazon Route 53-Zustandsprüfung mit einer geschützten Ressource verknüpfen.
**Anmerkung**
Bevor Sie einen Gesundheitscheck mit einem Shield Advanced-Schutz verknüpfen, stellen Sie sicher, dass er sich in einem fehlerfreien Zustand befindet. Weitere Informationen finden Sie im Amazon Route 53 Developer Guide unter [Überwachen des Status von Zustandsprüfungen und Empfangen von Benachrichtigungen](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-monitor-view-status.html).
**So ordnen Sie einen Gesundheitscheck zu**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die AWS WAF & Shield-Konsole unter [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. Wählen Sie im AWS Shield Navigationsbereich die Option **Geschützte Ressourcen** aus.
1. Wählen Sie auf der Registerkarte **Schutz** die Ressource aus, die Sie einer Integritätsprüfung zuordnen möchten.
1. Wählen Sie **Schutzmaßnahmen konfigurieren** aus.
1. Wählen Sie **Weiter**, bis Sie zur Seite „** DDoS-Erkennung auf Basis von Integritätsprüfungen konfigurieren — *optional***“ gelangen.
1. Wählen Sie unter **Associated Health Check (Zugehörige Zustandsprüfung)** die ID der Zustandsprüfung aus, die Sie der Schutzvorkehrung zuordnen möchten.
**Anmerkung**
Wenn Sie die benötigte Zustandsprüfung nicht sehen, rufen Sie die Route 53-Konsole auf und überprüfen Sie die Zustandsprüfung und ihre ID. Weitere Informationen finden Sie unter [Erstellen und Aktualisieren von Zustandsprüfungen](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating.html).
1. Gehen Sie die restlichen Seiten durch, bis Sie die Konfiguration abgeschlossen haben. Auf der Seite **Schutzmaßnahmen** ist Ihr aktualisierter Health Check-Zusammenhang für die Ressource aufgeführt.
1. Prüfen Sie auf der Seite **Schutzmaßnahmen**, ob Ihr neu zugeordneter Gesundheitscheck als fehlerfrei gemeldet wird.
Sie können einen Gesundheitscheck in Shield Advanced nicht erfolgreich verwenden, solange der Gesundheitscheck als fehlerhaft gemeldet wird. Dies führt dazu, dass Shield Advanced bei sehr niedrigen Schwellenwerten falsch positive Ergebnisse erkennt, was sich auch negativ auf die Fähigkeit des Shield Response Teams (SRT) auswirken kann, die Ressource proaktiv einzusetzen.
Wenn die neu zugeordnete Zustandsprüfung als fehlerhaft gemeldet wird, gehen Sie wie folgt vor:
1. Trennen Sie den Gesundheitscheck von Ihrem Schutz in Shield Advanced.
1. Überprüfen Sie Ihre Health Check-Spezifikationen in Amazon Route 53 erneut und überprüfen Sie die allgemeine Leistung und Verfügbarkeit Ihrer Anwendung.
1. Wenn Ihre Anwendung innerhalb Ihrer Gesundheitsparameter arbeitet und Ihr Gesundheitscheck als fehlerfrei gemeldet wird, versuchen Sie erneut, die Zustandsprüfung in Shield Advanced zu verknüpfen.
Das Verfahren der Health Check Association ist abgeschlossen, wenn Sie Ihre neue Health Check Association eingerichtet haben und sie in Shield Advanced als gesund gemeldet wird.
# Trennen einer Zustandsprüfung mit Ihrer durch Shield Advanced geschützten Ressource
Das folgende Verfahren zeigt, wie Sie eine Amazon Route 53-Zustandsprüfung von einer geschützten Ressource trennen.
**So trennen Sie die Zuordnung einer Zustandsprüfung**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die AWS WAF & Shield-Konsole unter [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. Wählen Sie im AWS Shield Navigationsbereich **Geschützte Ressourcen** aus.
1. Wählen Sie auf der Registerkarte **Schutz** die Ressource aus, die Sie von einer Integritätsprüfung trennen möchten.
1. Wählen Sie Schutzmaßnahmen **konfigurieren** aus.
1. Wählen Sie **Weiter**, bis Sie zur Seite „** DDoS-Erkennung auf Basis von Integritätsprüfungen konfigurieren — *optional***“ gelangen.
1. Wählen Sie unter **Associated Health Check** die leere Option aus, die als **-** aufgeführt ist.
1. Gehen Sie die restlichen Seiten durch, bis Sie die Konfiguration abgeschlossen haben.
Auf der Seite **Schutzmaßnahmen** ist das Feld für die Integritätsprüfung für Ihre Ressource auf **-** gesetzt, was bedeutet, dass es keine Zuordnung zur Integritätsprüfung gibt.
# Status der Zuordnungen zur Gesundheitsprüfung in Shield Advanced anzeigen
Sie können den Status der Zustandsprüfung, die einem Schutz zugeordnet ist, auf der Seite **Geschützte Ressourcen** der AWS WAF & Shield-Konsole und auf der Detailseite jeder Ressource einsehen.
+ **Fehlerfrei** — Der Gesundheitscheck ist verfügbar und wird als fehlerfrei gemeldet.
+ **Ungesund** — Der Gesundheitscheck ist verfügbar und wird als ungesund gemeldet.
+ **Nicht verfügbar** — Der Gesundheitscheck ist für Shield Advanced nicht verfügbar.
**Um eine Zustandsprüfung „**Nicht verfügbar**“ zu beheben**
Erstellen und verwenden Sie einen neuen Gesundheitscheck. Versuchen Sie nicht erneut, einen Gesundheitscheck zuzuordnen, nachdem dieser in Shield Advanced den Status Nicht verfügbar hatte.
Eine ausführliche Anleitung zur Durchführung dieser Schritte finden Sie in den vorherigen Themen.
1. Trennen Sie in Shield Advanced die Zustandsprüfung von der Ressource.
1. Erstellen Sie in Route 53 eine neue Zustandsprüfung für die Ressource und notieren Sie sich deren ID. Weitere Informationen finden Sie unter [Erstellen und Aktualisieren von Zustandsprüfungen](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating.html) im Amazon Route 53-Entwicklerhandbuch.
1. Ordnen Sie in Shield Advanced den neuen Gesundheitscheck der Ressource zu.
# Beispiele für Gesundheitschecks für Shield Advanced
In diesem Abschnitt finden Sie Beispiele für Zustandsprüfungen, die Sie bei einer berechneten Zustandsprüfung verwenden könnten. Bei einer berechneten Zustandsprüfung wird anhand einer Reihe einzelner Zustandsprüfungen ein kombinierter Status ermittelt. Der Status jeder einzelnen Zustandsprüfung basiert auf dem Zustand eines Endpunkts oder auf dem Status einer CloudWatch Amazon-Metrik. Sie kombinieren Gesundheitschecks zu einem berechneten Zustandscheck und konfigurieren dann Ihren berechneten Zustandscheck so, dass der Gesundheitszustand auf der Grundlage des kombinierten Gesundheitsstatus der einzelnen Gesundheitschecks gemeldet wird. Passen Sie die Sensitivität Ihrer berechneten Zustandsprüfungen an Ihre Anforderungen an Anwendungsleistung und Verfügbarkeit an.
Informationen zu berechneten Zustandsprüfungen finden Sie unter [Überwachung anderer Zustandsprüfungen (berechnete Zustandsprüfungen)](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-creating-values.html#health-checks-creating-values-calculated) im Amazon Route 53-Entwicklerhandbuch. Weitere Informationen finden Sie im Blogbeitrag [Route 53 Improvements — Calculated Health Checks and Latency Checks](https://aws.amazon.com/blogs/aws/route-53-improvements-calculated-health-checks-and-latency-checks/).
**Topics**
+ [CloudFront Amazon-Distributionen](#health-checks-example-cloudfront)
+ [Load Balancers](#health-checks-example-load-balancer)
+ [EC2 Elastische IP-Adresse (EIP) von Amazon](#health-checks-example-elastic-ip)
## CloudFront Amazon-Distributionen
In den folgenden Beispielen werden Zustandsprüfungen beschrieben, die zu einer berechneten Zustandsprüfung für eine CloudFront Verteilung kombiniert werden könnten:
+ Überwachen Sie einen Endpunkt, indem Sie einen Domainnamen für einen Pfad auf der Distribution angeben, der dynamische Inhalte bereitstellt. Eine fehlerfreie Antwort würde die HTTP-Antwortcodes 2xx und 3xx beinhalten.
+ Überwachen Sie den Status eines CloudWatch Alarms, der den Zustand des Ursprungs misst. CloudFront Sie können beispielsweise einen CloudWatch Alarm für die Application Load Balancer Balancer-Metrik `TargetResponseTime` verwalten und eine Integritätsprüfung erstellen, die den Status des Alarms widerspiegelt. Die Integritätsprüfung kann fehlerhaft sein, wenn die Antwortzeit zwischen der Anfrage, die den Load Balancer verlässt, und dem Empfang einer Antwort vom Ziel, den im Alarm konfigurierten Schwellenwert überschreitet.
+ Überwachen Sie den Status eines CloudWatch Alarms, der den Prozentsatz der Anfragen misst, für die der HTTP-Statuscode der Antwort 5xx lautet. Wenn die CloudFront 5xx-Fehlerrate der Verteilung höher als der im CloudWatch Alarm definierte Schwellenwert ist, wechselt der Status dieser Zustandsprüfung auf fehlerhaft.
## Load Balancers
In den folgenden Beispielen werden Integritätsprüfungen beschrieben, die in berechneten Integritätsprüfungen für einen Application Load Balancer, Network Load Balancer oder Global Accelerator Standard Accelerator verwendet werden könnten.
+ Überwachen Sie den Status eines CloudWatch Alarms, der die Anzahl der neuen Verbindungen misst, die von Clients zum Load Balancer hergestellt wurden. Sie können den Alarmschwellenwert für die durchschnittliche Anzahl neuer Verbindungen so einstellen, dass er bis zu einem gewissen Grad über Ihrem Tagesdurchschnitt liegt. Die Messwerte für jeden Ressourcentyp lauten wie folgt:
+ Application Load Balancer: `NewConnectionCount`
+ Network Load Balancer: `ActiveFlowCount`
+ Globaler Beschleuniger: `NewFlowCount`
+ Überwachen Sie für Application Load Balancer und Network Load Balancer den Status eines CloudWatch Alarms, der die Anzahl der Load Balancer misst, die als fehlerfrei gelten. Sie können den Alarmschwellenwert entweder für die Availability Zone oder für die Mindestanzahl fehlerfreier Hosts festlegen, die Ihr Load Balancer benötigt. Die verfügbaren Metriken für die Load Balancer-Ressourcen lauten wie folgt:
+ Application Load Balancer: `HealthyHostCount`
+ Network Load Balancer: `HealthyHostCount`
+ Überwachen Sie für Application Load Balancer den Status eines CloudWatch Alarms, der die Anzahl der HTTP 5xx-Antwortcodes misst, die von den Load Balancer-Zielen generiert wurden. Für einen Application Load Balancer können Sie die Metrik verwenden `HTTPCode_Target_5XX_Count` und den Alarmschwellenwert auf der Summe aller 5xx-Fehler für den Load Balancer basieren.
## EC2 Elastische IP-Adresse (EIP) von Amazon
Die folgenden Beispiel-Zustandsprüfungen könnten zu einer berechneten Zustandsprüfung für eine Amazon EC2 Elastic IP-Adresse kombiniert werden:
+ Überwachen Sie einen Endpunkt, indem Sie eine IP-Adresse für die Elastic IP-Adresse angeben. Die Zustandsprüfung bleibt fehlerfrei, solange eine TCP-Verbindung mit der Ressource hinter der IP-Adresse hergestellt werden kann.
+ Überwachen Sie den Status eines CloudWatch Alarms, der den Prozentsatz der zugewiesenen EC2 Amazon-Recheneinheiten misst, die derzeit auf der Instance verwendet werden. Sie können die EC2 Amazon-Metrik verwenden `CPUUtilization` und den Alarmschwellenwert auf einer Ihrer Meinung nach hohen CPU-Auslastung für Ihre Anwendung basieren, z. B. 90%.
# AWS Ressourcen AWS Shield Advanced schützen
Folgen Sie den Anweisungen in diesem Abschnitt, um Shield Advanced-Schutz zu einer oder mehreren Ressourcen hinzuzufügen.
**Um Schutz für eine AWS Ressource hinzuzufügen**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die AWS WAF & Shield-Konsole unter [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. AWS Shield Wählen Sie im Navigationsbereich unter **Geschützte Ressourcen** aus.
1. Wählen Sie **Zu schützende Ressourcen hinzufügen** aus.
1. Geben Sie **auf der Seite Ressourcen auswählen, die mit Shield Advanced geschützt** werden sollen, **unter Region und Ressourcentypen angeben** die Regions- und Ressourcentypspezifikationen für die Ressourcen an, die Sie schützen möchten. Sie können Ressourcen in mehreren Regionen schützen, indem Sie **Alle Regionen** auswählen, und Sie können die Auswahl auf globale Ressourcen einschränken, indem Sie **Global** auswählen. Sie können alle Ressourcentypen abwählen, die Sie nicht schützen möchten. Informationen zum Schutz Ihrer Ressourcentypen finden Sie unter. [Liste der Ressourcen, die AWS Shield Advanced schützen](ddos-protections-by-resource-type.md)
1. Wählen Sie **Ressourcen laden** aus. Shield Advanced füllt den Abschnitt **Ressourcen auswählen** mit den AWS Ressourcen, die Ihren Kriterien entsprechen.
1. Im Bereich **Ressourcen auswählen** können Sie die Ressourcenliste filtern, indem Sie eine Zeichenfolge eingeben, nach der in den Ressourcenlisten gesucht werden soll.
Wählen Sie die Ressourcen aus, die Sie schützen möchten.
1. **Wenn Sie den von Ihnen erstellten Shield Advanced-Schutzmaßnahmen Tags hinzufügen möchten, geben Sie diese im Abschnitt Tags an.** Informationen zum Markieren von AWS Ressourcen finden Sie unter [Arbeiten mit dem Tag-Editor](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/tag-editor.html).
1. Wählen Sie **Protect with Shield Advanced**. Dadurch werden die Ressourcen um Shield Advanced-Schutzmaßnahmen erweitert.
# AWS Shield Advanced Schutzmaßnahmen bearbeiten
Sie können die Einstellungen für Ihre AWS Shield Advanced Schutzmaßnahmen jederzeit ändern. Gehen Sie dazu die Optionen für Ihre ausgewählten Schutzmaßnahmen durch und ändern Sie die Einstellungen, die Sie ändern müssen.
**Um geschützte Ressourcen zu verwalten**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die AWS WAF & Shield-Konsole unter [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. Wählen Sie im AWS Shield Navigationsbereich **Geschützte Ressourcen** aus.
1. Wählen Sie auf der Registerkarte **Schutz** die Ressourcen aus, die Sie schützen möchten.
1. Wählen Sie **Schutzmaßnahmen konfigurieren** und wählen Sie die gewünschte Option für die Ressourcenspezifikation aus.
1. Gehen Sie die einzelnen Ressourcenschutzoptionen durch und nehmen Sie bei Bedarf Änderungen vor.
## Konfigurieren Sie den Schutz der Anwendungsebene DDo S
Zum Schutz vor Angriffen auf Amazon CloudFront - und Application Load Balancer Balancer-Ressourcen können Sie AWS WAF Web ACLs - und ratenbasierte Regeln hinzufügen. Weitere Informationen hierzu finden Sie unter [Schutz der Anwendungsebene mit AWS WAF Web ACLs und Shield Advanced](ddos-app-layer-web-ACL-and-rbr.md).
Sie können auch die automatische Abwehr von Shield Advanced auf Anwendungsebene DDo S aktivieren. Informationen darüber, wie das AWS WAF funktioniert, finden Sie unter[AWS WAF](waf-chapter.md). Informationen zur automatischen Schadensbegrenzungsfunktion finden Sie unter[Automatisierung der Risikominderung auf Anwendungsebene DDo S mit Shield Advanced](ddos-automatic-app-layer-response.md).
**Wichtig**
Wenn Sie Ihre Shield Advanced-Schutzmaßnahmen AWS Firewall Manager mithilfe einer Shield Advanced-Richtlinie verwalten, können Sie die Schutzmaßnahmen auf Anwendungsebene hier nicht verwalten. Für alle anderen Ressourcen empfehlen wir, dass Sie mindestens jeder Ressource eine Web-ACL zuordnen, auch wenn die Web-ACL keine Regeln enthält.
**Anmerkung**
Wenn Sie bei Bedarf die automatische Abwehr auf Anwendungsebene DDo S für eine Ressource aktivieren, fügt der Vorgang Ihrem Konto automatisch eine serviceverknüpfte Rolle hinzu, um Shield Advanced die erforderlichen Berechtigungen zur Verwaltung Ihres Web-ACL-Schutzes zu gewähren. Weitere Informationen finden Sie unter [Verwenden von serviceverknüpften Rollen für Shield Advanced](shd-using-service-linked-roles.md).
**Um Schutzmaßnahmen auf Anwendungsebene S zu konfigurieren DDo**
1. Wenn die Ressource noch nicht mit einer Web-ACL verknüpft ist, können Sie auf der Seite ** DDoLayer-7-S-Schutzmaßnahmen konfigurieren** eine bestehende Web-ACL auswählen oder eine eigene erstellen.
Führen Sie zur Erstellung einer Web-ACL die folgenden Schritte aus:
1. Wählen Sie **Create web ACL** (Web-ACL erstellen) aus.
1. Geben Sie einen Namen ein. Sie können den Namen nach dem Erstellen der Web-ACL nicht mehr ändern.
1. Wählen Sie **Erstellen** aus.
**Anmerkung**
Wenn eine Ressource bereits einer Web-ACL zugeordnet ist, können Sie nicht zu einer anderen Web-ACL wechseln. Wenn Sie die Web-ACL ändern möchten, müssen Sie zuerst das zugehörige Web ACLs aus der Ressource entfernen. Weitere Informationen finden Sie unter [Schutz einer Ressource zuordnen oder deren Verknüpfung aufheben AWS](web-acl-associating-aws-resource.md).
1. Wenn für die Web-ACL keine ratenbasierte Regel definiert ist, können Sie eine hinzufügen, indem Sie **Ratenbegrenzungsregel hinzufügen** wählen und dann die folgenden Schritte ausführen:
1. Geben Sie einen Namen ein.
1. Geben Sie ein Durchsatzlimit ein. Dies ist die maximale Anzahl von Anfragen, die in einem Zeitraum von fünf Minuten von einer einzelnen IP-Adresse aus zulässig sind, bevor die ratenbasierte Regelaktion auf die IP-Adresse angewendet wird. Wenn die Anfragen von der IP-Adresse unter den Grenzwert fallen, wird die Aktion abgebrochen.
1. Stellen Sie die Regelaktion so ein, dass Anfragen von IP-Adressen gezählt oder blockiert werden, solange deren Anzahl der Anfragen das Limit überschreitet. Die Anwendung und Entfernung der Regelaktion kann ein oder zwei Minuten nach der Änderung der IP-Adressanforderungsrate wirksam werden.
1. Wählen Sie **Regel hinzufügen** aus.
1. Wählen Sie für **Automatische Abwehr auf Anwendungsebene DDo S** wie folgt aus, ob Shield Advanced DDo S-Angriffe in Ihrem Namen automatisch abwehren soll:
+ Um die automatische Abwehr zu aktivieren, wählen Sie **Aktivieren** und dann die AWS WAF Regelaktion aus, die Shield Advanced in seinen benutzerdefinierten Regeln verwenden soll. Sie haben die Wahl zwischen Count undBlock. Informationen zu diesen AWS WAF Regelaktionen finden Sie unter[Verwenden von Regelaktionen in AWS WAF](waf-rule-action.md). Informationen darüber, wie Shield Advanced diese Aktionseinstellung verwaltet, finden Sie unter[So verwaltet Shield Advanced die Einstellung für Regelaktionen](ddos-automatic-app-layer-response-behavior.md#ddos-automatic-app-layer-response-rule-action).
+ Um die automatische Schadensbegrenzung zu deaktivieren, wählen Sie **Deaktivieren**.
+ Um die Einstellungen für die automatische Risikominderung für die Ressourcen, die Sie verwalten, unverändert zu lassen, behalten Sie die Standardauswahl **Aktuelle Einstellungen beibehalten** bei.
Informationen zur automatischen Abwehr von Shield Advanced auf Anwendungsebene DDo S finden Sie unter[Automatisierung der Risikominderung auf Anwendungsebene DDo S mit Shield Advanced](ddos-automatic-app-layer-response.md).
1. Wählen Sie **Weiter** aus.
# Alarme und Benachrichtigungen für Ressourcen erstellen, die durch Shield Advanced geschützt sind
Das folgende Verfahren zeigt, wie CloudWatch Alarme für geschützte Ressourcen verwaltet werden.
**Anmerkung**
CloudWatch verursacht zusätzliche Kosten. CloudWatch Die Preise finden Sie unter [ CloudWatch Amazon-Preise](https://aws.amazon.com/cloudwatch/pricing/).
**Um Alarme und Benachrichtigungen zu erstellen**
1. Konfigurieren Sie auf der Schutzseite **Alarme und Benachrichtigungen erstellen — *optional*** die SNS-Themen für die Alarme und Benachrichtigungen, die Sie erhalten möchten. Wählen Sie für Ressourcen, für die keine Benachrichtigungen erforderlich sind, **No topic (Kein Thema)** aus. Sie können ein Amazon SNS SNS-Thema hinzufügen oder ein neues Thema erstellen.
1. Gehen Sie folgendermaßen vor, um ein Amazon SNS SNS-Thema zu erstellen:
1. Wählen Sie in der Dropdownliste die Option **Ein SNS-Thema erstellen** aus.
1. Geben Sie einen Themennamen ein.
1. Geben Sie optional eine E-Mail-Adresse ein, an die die Amazon SNS SNS-Nachrichten gesendet werden, und wählen Sie dann **E-Mail hinzufügen**. Sie können mehr als eine eingeben.
1. Wählen Sie **Erstellen** aus.
1. Wählen Sie **Weiter** aus.
# AWS Shield Advanced Schutz von einer AWS Ressource entfernen
Sie können AWS Shield Advanced den Schutz für jede Ihrer AWS Ressourcen jederzeit aufheben.
**Wichtig**
Durch das Löschen einer AWS Ressource wird die Ressource nicht von entfernt AWS Shield Advanced. Sie müssen auch den Schutz für die Ressource von entfernen AWS Shield Advanced, wie in diesem Verfahren beschrieben.
**Entfernen Sie AWS Shield Advanced den Schutz von einer AWS Ressource**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die AWS WAF & Shield-Konsole unter [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. Wählen Sie im AWS Shield Navigationsbereich die Option **Geschützte Ressourcen** aus.
1. Wählen Sie auf der Registerkarte **Schutz** die Ressourcen aus, deren Schutz Sie entfernen möchten.
1. Wählen Sie Schutzmaßnahmen **löschen** aus.
1. Wenn Sie einen CloudWatch Amazon-Alarm für einen Schutz konfiguriert haben, haben Sie die Möglichkeit, den Alarm zusammen mit dem Schutz zu löschen. Wenn Sie den Alarm zu diesem Zeitpunkt nicht löschen möchten, können Sie ihn stattdessen später über die CloudWatch Konsole löschen.
**Anmerkung**
Wenn Sie bei Schutzmaßnahmen, für die eine Amazon Route 53-Zustandsprüfung konfiguriert ist, den Schutz später erneut hinzufügen, beinhaltet der Schutz immer noch die Zustandsprüfung.
Mit den vorherigen Schritten wird der AWS Shield Advanced Schutz für bestimmte AWS Ressourcen aufgehoben. Sie kündigen Ihr AWS Shield Advanced Abonnement nicht. Dieser Service wird Ihnen weiterhin in Rechnung gestellt. Für Informationen zu Ihrem AWS Shield Advanced Abonnement wenden Sie sich an das [AWS Support Center](https://console.aws.amazon.com/support/home#/).
## Einen CloudWatch Alarm aus Ihrem Shield Advanced-Schutz entfernen
Um einen CloudWatch Alarm aus Ihrem Shield Advanced-Schutz zu entfernen, gehen Sie wie folgt vor:
+ Löschen Sie den Schutz wie in [AWS Shield Advanced Schutz von einer AWS Ressource entfernen](#remove-protection) beschrieben. Achten Sie darauf, das Kontrollkästchen neben **Auch den zugehörigen DDo SDetection Alarm löschen** zu aktivieren.
+ Löschen Sie den Alarm mithilfe der CloudWatch Konsole. Der Name des zu löschenden Alarms beginnt mit **DDoSDetectedAlarmForProtection**.
# Gruppieren Sie Ihre Schutzmaßnahmen AWS Shield Advanced
Verwenden Sie Schutzgruppen, um logische Sammlungen Ihrer geschützten Ressourcen zu erstellen und deren Schutz als Gruppe zu verwalten. Informationen zur Verwaltung von Ressourcenschutzmaßnahmen finden Sie unter. [AWS Shield Advanced Schutzmaßnahmen bearbeiten](manage-protection.md)
**Anmerkung**
Die automatische Schadensbegrenzung auf Anwendungsebene DDo S interagiert nicht mit Schutzgruppen. Sie können die automatische Abwehr für Ressourcen aktivieren, die sich in Schutzgruppen befinden, aber Shield Advanced wendet nicht automatisch Angriffsabwehrmaßnahmen an, die auf den Ergebnissen der Schutzgruppe basieren. Shield Advanced wendet automatische Angriffsabwehrmaßnahmen für einzelne Ressourcen an.
AWS Shield Advanced Schutzgruppen bieten Ihnen eine Self-Service-Möglichkeit, den Umfang der Erkennung und Abwehr individuell anzupassen, indem mehrere geschützte Ressourcen als eine einzige Einheit behandelt werden. Die Gruppierung von Ressourcen kann eine Reihe von Vorteilen bieten.
+ Verbessern Sie die Erkennungsgenauigkeit.
+ Reduzieren Sie Benachrichtigungen über Ereignisse, die nicht bearbeitet werden können.
+ Erhöhen Sie den Umfang der Maßnahmen zur Schadensbegrenzung, sodass auch geschützte Ressourcen einbezogen werden, die bei einem Ereignis ebenfalls beeinträchtigt werden könnten.
+ Beschleunigen Sie die Zeit bis zur Abwehr von Angriffen mit mehreren ähnlichen Zielen.
+ Erleichtern Sie den automatischen Schutz neu erstellter geschützter Ressourcen.
Schutzgruppen können dazu beitragen, Fehlalarme in Situationen wie einem blue/green Swap zu reduzieren, in dem Ressourcen abwechselnd ausgelastet sind, und voll ausgelastet sind. Ein anderes Beispiel ist, wenn Sie Ressourcen häufig erstellen und löschen und dabei ein Lastniveau beibehalten, das von allen Mitgliedern der Gruppe gemeinsam genutzt wird. In solchen Situationen kann die Überwachung einzelner Ressourcen zu Fehlalarmen führen, die Überwachung des Zustands der Ressourcengruppe dagegen nicht.
Sie können Schutzgruppen so konfigurieren, dass sie alle geschützten Ressourcen, alle Ressourcen bestimmter Ressourcentypen oder individuell angegebene Ressourcen umfassen. Neu geschützte Ressourcen, die Ihre Schutzgruppenkriterien erfüllen, werden automatisch in Ihre Schutzgruppe aufgenommen. Eine geschützte Ressource kann mehreren Schutzgruppen angehören.
# Eine Shield Advanced-Schutzgruppe erstellen
**Um eine Schutzgruppe zu erstellen**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die AWS WAF & Shield-Konsole unter [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. Wählen Sie im AWS Shield Navigationsbereich **Geschützte Ressourcen** aus.
1. Wählen Sie die Registerkarte **Schutzgruppen** und dann **Schutzgruppe erstellen** aus.
1. Geben **Sie auf der Seite Schutzgruppe erstellen** einen Namen für Ihre Gruppe ein. Sie verwenden diesen Namen, um die Gruppe in Ihrer Liste der geschützten Ressourcen zu identifizieren. Sie können den Namen einer Schutzgruppe nicht ändern, nachdem Sie sie erstellt haben.
1. Wählen Sie unter **Schutzgruppierungskriterien** die Kriterien aus, anhand derer Shield Advanced die geschützten Ressourcen identifiziert, die in die Gruppe aufgenommen werden sollen. Treffen Sie Ihre zusätzlichen Auswahlen auf der Grundlage der von Ihnen ausgewählten Kriterien.
1. Wählen Sie **unter Aggregation** aus, wie Shield Advanced die Ressourcendaten für die Gruppe kombinieren soll, um Ereignisse zu erkennen, zu mindern und zu melden.
+ **Summe** — Verwendet den gesamten Datenverkehr in der Gruppe. In den meisten Fällen ist dies eine gute Wahl. Beispiele hierfür sind Elastic IP-Adressen für EC2 Amazon-Instances, die manuell oder automatisch skaliert werden.
+ **Mittelwert** — Es wird der Durchschnitt des Datenverkehrs innerhalb der Gruppe verwendet. Dies ist eine gute Wahl für Ressourcen, die den Traffic einheitlich teilen. Beispiele hierfür sind Beschleuniger und Load Balancer.
+ **Max.** — Nutzt den höchsten Traffic von jeder Ressource. Dies ist nützlich für Ressourcen, die den Verkehr nicht gemeinsam nutzen, und für Ressourcen, die den Verkehr auf ungleichmäßige Weise teilen. Beispiele hierfür sind CloudFront Amazon-Distributionen und Herkunftsressourcen für CloudFront Distributionen.
1. Wählen Sie **Speichern**, um Ihre Schutzgruppe zu speichern und zur Seite **Geschützte Ressourcen** zurückzukehren.
Auf der Seite ****Shield-Ereignisse**** können Sie Ereignisse für Ihre Schutzgruppe anzeigen und zusätzliche Informationen zu den geschützten Ressourcen in der Gruppe aufrufen.
# Aktualisierung einer Shield Advanced-Schutzgruppe
**Um eine Schutzgruppe zu aktualisieren**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die AWS WAF & Shield-Konsole unter [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. Wählen Sie im AWS Shield Navigationsbereich die Option **Geschützte Ressourcen** aus.
1. Aktivieren Sie auf der Registerkarte **Schutzgruppen** das Kontrollkästchen neben der Schutzgruppe, die Sie ändern möchten.
1. Wählen Sie auf der Seite der Schutzgruppe die Option **Bearbeiten** aus. Nehmen Sie Ihre Änderungen an den Einstellungen der Schutzgruppe vor.
1. Wählen Sie **Speichern**, um Ihre Änderungen zu speichern.
# Löschen einer Shield Advanced-Schutzgruppe
**Um eine Schutzgruppe zu löschen**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die AWS WAF & Shield-Konsole unter [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. Wählen Sie im AWS Shield Navigationsbereich **Geschützte Ressourcen** aus.
1. Aktivieren Sie auf der Registerkarte **Schutzgruppen** das Kontrollkästchen neben der Schutzgruppe, die Sie entfernen möchten.
1. Wählen Sie auf der Seite der Schutzgruppe die Option **Löschen** aus und bestätigen Sie die Aktion.
# Änderungen am Ressourcenschutz von Tracking Shield Advanced in AWS Config
Auf dieser Seite wird erklärt, wie Sie Änderungen am AWS Shield Advanced Schutz Ihrer Ressourcen mithilfe von aufzeichnen können AWS Config. Anschließend können Sie diese Informationen verwenden, um ein Protokoll der Konfigurationsänderungen für Audit- und Fehlerbehebungszwecke zu pflegen.
Um Schutzänderungen aufzuzeichnen, aktivieren Sie AWS Config die Option für jede Ressource, die Sie verfolgen möchten. Weitere Informationen finden Sie unter [Erste Schritte mit AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/getting-started.html) im *AWS Config -Developerhandbuch*.
Sie müssen die Aktivierung AWS Config für jede Ressource aktivieren AWS-Region , die die verfolgten Ressourcen enthält. Sie können die Option AWS Config manuell aktivieren oder die CloudFormation Vorlage „Aktivieren AWS Config“ unter [CloudFormation StackSets Beispielvorlagen](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-sampletemplates.html) im *CloudFormation Benutzerhandbuch* verwenden.
Wenn Sie die Option aktivieren AWS Config, werden Ihnen die Gebühren entsprechend den Angaben auf der Seite mit den [AWS Config Preisen](https://aws.amazon.com/config/pricing/) in Rechnung gestellt.
**Anmerkung**
Wenn Sie die AWS Config Aktivierung bereits für die erforderlichen Regionen und Ressourcen aktiviert haben, müssen Sie nichts weiter tun. AWS Config Protokolle über Schutzänderungen an Ihren Ressourcen beginnen automatisch mit Daten zu füllen.
Verwenden Sie nach der Aktivierung AWS Config die Region USA Ost (Nord-Virginia) in der AWS Config Konsole, um den Verlauf der Konfigurationsänderungen für AWS Shield Advanced globale Ressourcen einzusehen.
Zeigen Sie den Änderungsverlauf für AWS Shield Advanced regionale Ressourcen über die AWS Config Konsole in den Regionen USA Ost (Nord-Virginia), USA Ost (Ohio), USA West (Oregon), USA West (Nordkalifornien), Europa (Irland), Europa (Frankfurt), Asien-Pazifik (Tokio) und Asien-Pazifik (Sydney) an.
# Einblick in DDo S-Ereignisse mit Shield Advanced
AWS Shield bietet Einblick in die folgenden Kategorien von Veranstaltungen und Veranstaltungsaktivitäten:
+ **Global** — Alle Kunden können auf eine aggregierte Übersicht der weltweiten Bedrohungsaktivitäten der letzten zwei Wochen zugreifen. Sie finden diese Informationen auf den Seiten „**Erste Schritte**“ und „**Globales Bedrohungs-Dashboard**“ der AWS Shield Konsole. Weitere Informationen finden Sie unter [AWS Shield Globale Aktivitäten und Kontoaktivitäten anzeigen](ddos-standard-event-visibility.md).
+ **Konto** — Alle Kunden können auf eine Zusammenfassung der Ereignisse für ihr Konto im Vorjahr zugreifen. Sie finden diese Informationen auf der Seite „**Erste Schritte**“ der AWS Shield Konsole. Weitere Informationen finden Sie unter [AWS Shield Globale Aktivitäten und Kontoaktivitäten anzeigen](ddos-standard-event-visibility.md).
Wenn Sie Shield Advanced abonnieren und Schutzmaßnahmen zu Ihren Ressourcen hinzufügen, erhalten Sie Zugriff auf zusätzliche Informationen über die Ereignisse und DDo S-Angriffe auf die geschützten Ressourcen:
+ **Ereignisse auf geschützten Ressourcen** — Shield Advanced bietet detaillierte Informationen zu jedem Ereignis auf der Seite **Ereignisse** der AWS Shield Konsole. Weitere Informationen finden Sie unter [AWS Shield Advanced Ereignisse anzeigen](ddos-events.md).
+ **Ereigniskennzahlen für geschützte Ressourcen** — Shield Advanced veröffentlicht Erkennungs-, Schadensbegrenzungs- und CloudWatch Amazon-Statistiken zu allen Ressourcen, die es schützt. Sie können diese Metriken verwenden, um CloudWatch Dashboards und Alarme zu konfigurieren. Weitere Informationen finden Sie unter [AWS Shield Advanced Metriken](shield-metrics.md).
+ **Kontoübergreifende Sichtbarkeit von Ereignissen für geschützte Ressourcen** — Wenn Sie Ihre Shield Advanced-Schutzmaßnahmen verwalten, können Sie die Sichtbarkeit von Schutzmaßnahmen für mehrere Konten aktivieren, indem Sie den Firewall Manager in Kombination mit verwenden. AWS Firewall Manager AWS Security Hub CSPM Weitere Informationen finden Sie unter [Shield Advanced-Ereignisse über mehrere anzeigen AWS-Konten mit AWS Firewall Manager und AWS Security Hub CSPM](ddos-viewing-multiple-accounts.md).
Wenn Sie die automatische Abwehr von Anwendungsschicht DDo S für den Schutz auf Anwendungsebene aktivieren, fügt Shield Advanced Ihrem Schutzpaket (Web-ACL) eine Regelgruppe hinzu, die zur Verwaltung automatisierter Schutzmaßnahmen verwendet wird. Diese Regelgruppe generiert AWS WAF Metriken, die jedoch nicht angezeigt werden können. Dies ist dasselbe wie für alle anderen Regelgruppen, die Sie in Ihrem Protection Pack (Web-ACL) verwenden, aber nicht besitzen, wie z. B. Regelgruppen mit AWS verwalteten Regeln. Weitere Informationen zu AWS WAF Metriken finden Sie unter[AWS WAF Metriken und Dimensionen](waf-metrics.md). Informationen zu dieser Shield Advanced-Schutzoption finden Sie unter[Automatisierung der Risikominderung auf Anwendungsebene DDo S mit Shield Advanced](ddos-automatic-app-layer-response.md).
**Topics**
+ [AWS Shield Globale Aktivitäten und Kontoaktivitäten anzeigen](ddos-standard-event-visibility.md)
+ [AWS Shield Advanced Ereignisse anzeigen](ddos-events.md)
+ [Shield Advanced-Ereignisse über mehrere anzeigen AWS-Konten mit AWS Firewall Manager und AWS Security Hub CSPM](ddos-viewing-multiple-accounts.md)
# AWS Shield Globale Aktivitäten und Kontoaktivitäten anzeigen
Diese Seite enthält Anweisungen für den Zugriff auf eine aggregierte Ansicht der globalen Bedrohungsaktivitäten und eine Zusammenfassung der Ereignisse pro Konto auf den Seiten **Erste Schritte** der AWS Shield Konsole und das **Dashboard für globale Bedrohungen**.
Der folgende Screenshot zeigt ein Beispiel für eine Seite mit den **ersten Schritten**.
![\[In der AWS Shield Konsole wird die Seite „Erste Schritte“ mit den Übersichtsfenstern für globale Bedrohungen und Kontoereignisse angezeigt.\]](http://docs.aws.amazon.com/de_de/waf/latest/developerguide/images/shield-console-global-account.png)
**So greifen Sie auf die Konsole zu AWS Shield**
+ Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die AWS WAF & Shield-Konsole unter [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
Sie benötigen kein Abonnement für Shield Advanced, um auf Informationen zu globalen Aktivitäten und Kontoereignissen zuzugreifen.
**Weltweite Aktivitäten**
Diese Informationen sind auf der AWS Shield Konsole über das **globale Bedrohungs-Dashboard** und auf den Seiten **Erste Schritte** verfügbar. Der folgende Screenshot zeigt ein Beispiel für den globalen Aktivitätsbereich.
![\[Ein AWS Shield Konsolenbereich mit dem Titel Von Shield erkannte globale Aktivität zeigt eine Weltkarte, überlagert mit Heatmap-Markierungen für Gebiete, in denen in den letzten zwei Wochen globale Bedrohungen entdeckt wurden.\]](http://docs.aws.amazon.com/de_de/waf/latest/developerguide/images/shield-console-global-activity.png)
Die globale Aktivität beschreibt DDo S-Ereignisse, die bei allen AWS Kunden beobachtet wurden. AWS Aktualisiert einmal pro Stunde die Informationen der letzten zwei Wochen. Im Konsolenbereich können Sie die Ergebnisse sehen, die nach AWS Regionen partitioniert und auf einer Welt-Heatmap angezeigt werden. Neben der Karte zeigt Shield zusammenfassende Informationen wie den größten Paketangriff, die größte Bitrate, den häufigsten Vektor, die Gesamtzahl der Angriffe und die Bedrohungsstufe an. Bei der Bedrohungsstufe handelt es sich um eine Bewertung der aktuellen weltweiten Aktivitäten im Vergleich zu dem, was AWS üblicherweise beobachtet wird. Der Standardwert für die Bedrohungsstufe ist **Normal**. AWS aktualisiert den Wert bei erhöhter DDo S-Aktivität automatisch auf **Hoch**.
Das **globale Bedrohungs-Dashboard** bietet auch Zeitreihen-Metriken und gibt Ihnen die Möglichkeit, zwischen Zeitdauern zu wechseln. Um den Verlauf signifikanter DDo S-Angriffe einzusehen, können Sie das Dashboard so anpassen, dass es vom letzten Tag bis zu den letzten zwei Wochen angezeigt wird. Zeitreihen-Metriken bieten einen Überblick über die höchste Bitrate, Paketrate oder Anforderungsrate für alle Ereignisse, die von AWS Shield Anwendungen erkannt wurden, auf denen AWS während des von Ihnen ausgewählten Zeitfensters ausgeführt wird.
**Kontoaktivität**
Diese Informationen sind auf der AWS Shield Konsolenseite „**Erste Schritte**“ verfügbar.
Der folgende Screenshot zeigt ein Beispiel für einen Bereich mit Kontoaktivitäten.
![\[Ein AWS Shield Konsolenbereich mit dem Titel Von Shield erkannte Kontoaktivität listet eine Zusammenfassung der Ereignisse des vergangenen Jahres auf, mit Informationen wie der Gesamtzahl der Ereignisse und der größten Paket- und Anforderungsrate.\]](http://docs.aws.amazon.com/de_de/waf/latest/developerguide/images/shield-console-account-activity.png)
Die Kontoaktivität beschreibt DDo S-Ereignisse, die Shield für Ihre Ressourcen erkannt hat, die für den Schutz durch Shield Advanced in Frage kommen. Shield erstellt täglich zusammenfassende Kennzahlen für das Jahr, das am Vortag um 00:00 Uhr UTC endet, und zeigt dann die Gesamtzahl der Ereignisse, die größte Bitrate, die größte Paketrate und die größte Anforderungsrate an.
+ Die Metrik zur Gesamtzahl der Ereignisse spiegelt jedes Mal wider, wenn Shield verdächtige Attribute im Datenverkehr entdeckte, der für Ihre Anwendung bestimmt war. Zu den verdächtigen Attributen können Datenverkehr gehören, der ein höheres Volumen als normal aufweist, Datenverkehr, der nicht dem historischen Profil Ihrer Anwendung entspricht, oder Verkehr, der nicht den von Shield für gültigen Anwendungsdatenverkehr definierten Heuristiken entspricht.
+ Statistiken zur größten Bitrate und zur größten Paketrate sind für jede Ressource verfügbar.
+ Die Statistik mit der höchsten Anforderungsrate ist nur für CloudFront Amazon-Distributionen und Application Load Balancer verfügbar, denen eine Web-ACL zugeordnet AWS WAF ist.
**Anmerkung**
Sie können auch über den API-Vorgang auf die Zusammenfassung der Ereignisse auf Kontoebene zugreifen. AWS Shield [DescribeAttackStatistics](https://docs.aws.amazon.com/waf/latest/DDOSAPIReference/API_DescribeAttack.html)
# AWS Shield Advanced Ereignisse anzeigen
Diese Seite enthält Anweisungen für den Zugriff auf Informationen über Ereignisse in Shield Advanced.
Wenn Sie Shield Advanced abonnieren und Ihre Ressourcen schützen, erhalten Sie Zugriff auf zusätzliche Sichtbarkeitsfunktionen für die Ressourcen. Dazu gehören Benachrichtigungen nahezu in Echtzeit über Ereignisse, die von Shield Advanced erkannt werden, sowie zusätzliche Informationen über erkannte Ereignisse und Abhilfemaßnahmen.
**Anmerkung**
Ihre Ereignisinformationen in der Shield Advanced-Konsole basieren auf Shield Advanced-Metriken. Informationen zu Shield Advanced-Metriken finden Sie unter [AWS Shield Advanced Metriken](shield-metrics.md)
AWS Shield bewertet den Datenverkehr zu Ihrer geschützten Ressource anhand mehrerer Dimensionen. Wenn eine Anomalie erkannt wird, erstellt Shield Advanced für jede betroffene Ressource ein separates Ereignis.
Sie können über die Seite **Ereignisse der Shield-Konsole auf Zusammenfassungen und Details zu den Ereignissen** zugreifen. Die Seite „**Ereignisse**“ auf oberster Ebene bietet einen Überblick über aktuelle und vergangene Ereignisse.
Der folgende Screenshot zeigt ein Beispiel für eine **Veranstaltungsseite** mit einem einzelnen laufenden Ereignis. Dieses aktive Ereignis wird auch im linken Navigationsbereich gekennzeichnet.
![\[Im linken Navigationsbereich der AWS Shield Konsole ist die Auswahl Ereignisse rot hervorgehoben, daneben befindet sich eine Zahl 1 in einem roten Kreis. Die Seite „Ereignisse“ ist geöffnet und enthält eine einzelne Zeile in der Ereignisliste. In der Zeile wird eine AWS Ressource vom Typ CloudFront Verteilung aufgeführt. Das Feld Aktueller Status enthält ein dreieckiges rotes Symbol neben den Worten Schadensbegrenzung in Bearbeitung. Das Statusfeld Attack Vectors enthält UDP-Verkehr. Das Feld Startzeit enthält den Wert 16. September 2020, 14:43:00 Uhr SAST. Das Feld Dauer enthält 6 Minuten.\]](http://docs.aws.amazon.com/de_de/waf/latest/developerguide/images/shield-console-event-summary1.png)
Shield Advanced kann je nach Art des Datenverkehrs und den von Ihnen konfigurierten Schutzmaßnahmen auch automatisch Abhilfemaßnahmen gegen Angriffe ergreifen. Diese Abhilfemaßnahmen können Ihre Ressource davor schützen, übermäßigen Datenverkehr oder Datenverkehr zu empfangen, der einer bekannten DDo S-Angriffssignatur entspricht.
Der folgende Screenshot zeigt ein Beispiel für **Ereignisse**, bei denen alle Ereignisse durch Shield Advanced gemildert wurden oder von selbst abgeklungen sind.
![\[Auf einer AWS Shield Konsolenseite mit dem Titel Ereignisse werden Ereignisse, die kürzlich erkannt wurden, und ihr aktueller Status aufgeführt.\]](http://docs.aws.amazon.com/de_de/waf/latest/developerguide/images/shield-console-events.png)
**Schützen Sie Ihre Ressourcen vor einem Ereignis**
Verbessern Sie die Genauigkeit der Ereigniserkennung, indem Sie Ressourcen mit Shield Advanced schützen, während sie den normalen erwarteten Verkehr empfangen, bevor sie einem DDo S-Angriff ausgesetzt sind.
Um Ereignisse für eine geschützte Ressource korrekt melden zu können, muss Shield Advanced zunächst eine Basislinie der erwarteten Datenverkehrsmuster für diese Ressource erstellen.
+ Shield Advanced meldet Ereignisse auf Infrastrukturebene für Ressourcen, nachdem sie mindestens 15 Minuten lang geschützt wurden.
+ Shield Advanced meldet Ereignisse auf Webanwendungsebene für Ressourcen, nachdem sie mindestens 24 Stunden lang geschützt wurden. Die Genauigkeit der Erkennung von Ereignissen auf Anwendungsebene ist am besten, wenn Shield Advanced den erwarteten Verkehr 30 Tage lang beobachtet hat.
**Um auf Ereignisinformationen in der AWS Shield Konsole zuzugreifen**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die AWS WAF & Shield-Konsole unter [https://console.aws.amazon.com/wafv2/](https://console.aws.amazon.com/wafv2/).
1. Wählen Sie im AWS Shield Navigationsbereich **Ereignisse** aus. In der Konsole wird die Seite **Ereignisse** angezeigt.
1. Auf der Seite **Ereignisse** können Sie ein beliebiges Ereignis in der Liste auswählen, um zusätzliche Übersichtsinformationen und Details zu dem Ereignis anzuzeigen.
**Topics**
+ [Liste der Felder in AWS Shield Advanced Ereigniszusammenfassungen](ddos-event-summaries.md)
+ [AWS Shield Advanced Veranstaltungsdetails anzeigen](ddos-event-details.md)
# Liste der Felder in AWS Shield Advanced Ereigniszusammenfassungen
Auf dieser Seite werden die Felder in den Shield Advanced-Ereigniszusammenfassungen aufgeführt und definiert.
Sie können Zusammenfassung und Detailinformationen zu einem Ereignis auf der Konsolenseite des Ereignisses anzeigen. Um die Seite für ein Ereignis zu öffnen, wählen Sie den Namen der AWS Ressource aus der Liste der **Veranstaltungsseiten** aus.
Der folgende Screenshot zeigt ein Beispiel für eine Ereigniszusammenfassung für ein Ereignis auf Netzwerkebene.
![\[Im Übersichtsbereich der Ereignisseite der AWS Shield Konsole werden Informationen zu einem Ereignis aufgeführt. Dazu gehören die betroffene AWS Ressource, Angriffsvektoren, Start- und Endzeiten sowie Abwehr- und Statusinformationen.\]](http://docs.aws.amazon.com/de_de/waf/latest/developerguide/images/shield-console-event-summary2.png)
Die Zusammenfassung der Informationen auf der Ereignisseite umfasst Folgendes.
+ **Aktueller Status** — Werte, die den Status des Ereignisses und die Aktionen angeben, die Shield Advanced für das Ereignis ergriffen hat. Statuswerte gelten für Ereignisse auf Infrastrukturebene (Schicht 3 oder 4) und Anwendungsebene (Schicht 7).
+ **Identifiziert (fortlaufend)** und **Identifiziert (abgeklungen)** — Diese deuten darauf hin, dass Shield Advanced ein Ereignis erkannt, aber bisher keine Maßnahmen ergriffen hat. **Identifiziert (abgeklungen)** bedeutet, dass der verdächtige Verkehr, den Shield erkannt hat, ohne Eingreifen gestoppt wurde.
+ **Schadensbegrenzung im Gange** und **Abhilfe** — Diese Angaben weisen darauf hin, dass Shield Advanced ein Ereignis erkannt und entsprechende Maßnahmen ergriffen hat. **Mitigation** wird auch verwendet, wenn es sich bei der Zielressource um eine von Amazon CloudFront Distribution oder Amazon Route 53 gehostete Zone handelt, die über eigene automatische Inline-Mitigations verfügt.
+ **Angriffsvektoren** — DDo S-Angriffsvektoren wie TCP SYN-Floods und Shield Advanced-Erkennungsheuristiken wie Request Flood. Dies können Anzeichen für einen DDo S-Angriff sein.
+ **Startzeit** — Datum und Uhrzeit, an dem der erste anomale Verkehrsdatenpunkt erkannt wurde.
+ **Dauer oder Endzeit — Gibt die Zeit** an, die zwischen der Startzeit des Ereignisses und dem letzten beobachteten anomalen Datenpunkt verstrichen ist, den Shield Advanced beobachtet hat. Während ein Ereignis andauert, werden diese Werte weiter steigen.
+ **Schutz** — Benennt den Shield Advanced-Schutz, der mit der Ressource verknüpft ist, und stellt einen Link zu seiner Schutzseite bereit. Dieser ist auf der Seite des jeweiligen Ereignisses verfügbar.
+ **Automatische Abwehr der Anwendungsschicht DDo S** — Wird für den Schutz der Anwendungsebene verwendet, um anzugeben, ob die automatische Shield Advanced-Abwehr für die Anwendungsschicht DDo S für die Ressource aktiviert ist. Wenn sie aktiviert ist, bietet sie einen Link, über den Sie auf die Konfiguration zugreifen und sie verwalten können. Dies ist auf der Seite der einzelnen Veranstaltung verfügbar.
+ **Automatische Risikominderung auf Netzwerkebene** — Gibt an, ob für die Ressource eine automatische Abwehr auf Netzwerkebene erfolgt. Wenn eine Ressource über eine Komponente auf Netzwerkschicht verfügt, wird diese aktiviert. Diese Informationen sind auf der Seite der einzelnen Veranstaltung verfügbar.
Für Ressourcen, die häufig angegriffen werden, kann Shield nach dem Abklingen des übermäßigen Datenverkehrs Schutzmaßnahmen ergreifen, um weitere wiederkehrende Ereignisse zu verhindern.
**Anmerkung**
Sie können über den API-Vorgang auch auf Ereigniszusammenfassungen für geschützte Ressourcen zugreifen. AWS Shield [ListAttacks](https://docs.aws.amazon.com/waf/latest/DDOSAPIReference/API_ListAttacks.html)
# AWS Shield Advanced Veranstaltungsdetails anzeigen
Im unteren Bereich der Konsolenseite für das Ereignis finden Sie Einzelheiten zur Erkennung und Abwehr eines Ereignisses sowie zu den wichtigsten Mitwirkenden. Dieser Abschnitt kann eine Mischung aus legitimem und potenziell unerwünschtem Datenverkehr enthalten und kann sowohl Datenverkehr darstellen, der an Ihre geschützte Ressource weitergeleitet wurde, als auch Datenverkehr, der durch Shield-Schutzmaßnahmen blockiert wurde.
+ **Erkennung und Abwehr** — Bietet Informationen über das beobachtete Ereignis und alle getroffenen Gegenmaßnahmen. Informationen zur Abwehr von Ereignissen finden Sie unter. [Reagieren auf DDo S-Ereignisse in AWS](ddos-responding.md)
+ **Wichtigste Mitwirkende** — Kategorisiert den Traffic, der an der Veranstaltung beteiligt ist, und listet die wichtigsten Verkehrsquellen auf, die Shield für jede Kategorie identifiziert hat. Verwenden Sie bei Ereignissen auf Anwendungsebene die Informationen der wichtigsten Mitwirkenden, um sich einen allgemeinen Überblick über die Art eines Ereignisses zu verschaffen. Verwenden Sie jedoch die AWS WAF Protokolle für Ihre Sicherheitsentscheidungen. Weitere Informationen finden Sie in den folgenden Abschnitten.
Ihre Ereignisinformationen in der Shield Advanced-Konsole basieren auf Shield Advanced-Metriken. Informationen zu Shield Advanced-Metriken finden Sie unter [AWS Shield Advanced Metriken](shield-metrics.md)
Risikominderungsmetriken für Amazon CloudFront - oder Amazon Route 53-Ressourcen sind nicht enthalten, da diese Services durch ein Abwehrsystem geschützt sind, das immer aktiviert ist und keine Abhilfemaßnahmen für einzelne Ressourcen erfordert.
Die einzelnen Abschnitte variieren je nachdem, ob sich die Informationen auf ein Ereignis auf der Infrastrukturebene oder auf Anwendungsebene beziehen.
**Topics**
+ [Ereignisdetails der Anwendungsebene (Schicht 7) in Shield Advanced anzeigen](ddos-event-details-application-layer.md)
+ [Ereignisdetails der Infrastrukturebene (Layer 3 oder 4) in Shield Advanced anzeigen](ddos-event-details-infrastructure-layer.md)
# Ereignisdetails der Anwendungsebene (Schicht 7) in Shield Advanced anzeigen
Im unteren Bereich der Konsolenseite für das Ereignis finden Sie Einzelheiten zur Erkennung und Abwehr eines Ereignisses auf Anwendungsebene sowie zu den wichtigsten Mitwirkenden. Dieser Abschnitt kann eine Mischung aus legitimem und potenziell unerwünschtem Datenverkehr enthalten und kann sowohl Datenverkehr darstellen, der an Ihre geschützte Ressource weitergeleitet wurde, als auch Datenverkehr, der durch Shield Advanced-Mitigations blockiert wurde.
Die Schadensbegrenzungsdetails beziehen sich auf alle Regeln in der Web-ACL, die mit der Ressource verknüpft sind, einschließlich Regeln, die speziell als Reaktion auf einen Angriff eingesetzt werden, und ratenbasierte Regeln, die in der Web-ACL definiert sind. Wenn Sie die automatische Abwehr auf Anwendungsebene DDo S für eine Anwendung aktivieren, enthalten die Abhilfemetriken auch Metriken für diese zusätzlichen Regeln. Informationen zu diesen Schutzmaßnahmen auf Anwendungsebene finden Sie unter. [Schutz der Anwendungsschicht (Schicht 7) mit AWS Shield Advanced und AWS WAF](ddos-app-layer-protections.md)
## Erkennung und Schadensbegrenzung
Für ein Ereignis auf Anwendungsebene (Schicht 7) werden auf der Registerkarte **Erkennung und Schadensbegrenzung** Erkennungsmetriken angezeigt, die auf Informationen aus den AWS WAF Protokollen basieren. Die Metriken zur Schadensbegrenzung basieren auf AWS WAF Regeln in der zugehörigen Web-ACL, die so konfiguriert sind, dass unerwünschter Datenverkehr blockiert wird.
Für CloudFront Amazon-Distributionen können Sie Shield Advanced so konfigurieren, dass automatische Abhilfemaßnahmen für Sie angewendet werden. Für alle Ressourcen auf Anwendungsebene können Sie Ihre eigenen Abwehrregeln in Ihrer Web-ACL definieren und das Shield Response Team (SRT) um Hilfe bitten. Weitere Informationen zu diesen Optionen finden Sie unter [Reagieren auf DDo S-Ereignisse in AWS](ddos-responding.md).
Der folgende Screenshot zeigt ein Beispiel für die Erkennungsmetriken für ein Ereignis auf Anwendungsebene, das nach einigen Stunden wieder abgeklungen ist.
![\[Ein Diagramm mit Erkennungsmetriken zeigt die Erkennung von Flut an Anfragen von 11:30 Uhr bis zum Abklingen des Traffics um 16:00 Uhr.\]](http://docs.aws.amazon.com/de_de/waf/latest/developerguide/images/shield-app-detection-metrics.png)
Event-Traffic, der nachlässt, bevor eine Schadensbegrenzungsregel wirksam wird, wird in den Risikometriken nicht berücksichtigt. Dies kann zu einem Unterschied zwischen dem in den Erkennungsdiagrammen angezeigten Webanforderungs-Traffic und den in den Risikominderungsdiagrammen angezeigten Zulassen und Blockierungs-Metriken führen.
## Wichtigste Faktoren
Auf der Registerkarte **Wichtigste Mitwirkende** für Ereignisse auf Anwendungsebene werden die fünf wichtigsten Mitwirkenden angezeigt, die Shield für das Ereignis identifiziert hat, basierend auf den abgerufenen AWS WAF Protokollen. Shield kategorisiert die Informationen der wichtigsten Mitwirkenden nach Dimensionen wie Quell-IP, Quellland und Ziel-URL.
**Anmerkung**
Die genauesten Informationen über den Datenverkehr, der zu einem Ereignis auf Anwendungsebene beiträgt, finden Sie in den AWS WAF Protokollen.
Verwenden Sie die Informationen der wichtigsten Mitwirkenden der Shield-Anwendungsebene nur, um sich einen allgemeinen Überblick über die Art eines Angriffs zu verschaffen, und stützen Sie Ihre Sicherheitsentscheidungen nicht darauf. Bei Ereignissen auf Anwendungsebene sind die AWS WAF Protokolle die beste Informationsquelle, um die Verursacher eines Angriffs zu verstehen und Ihre Abwehrstrategien zu entwickeln.
Die Informationen der wichtigsten Mitwirkenden von Shield spiegeln nicht immer vollständig die Daten in den AWS WAF Protokollen wider. Bei der Aufnahme der Protokolle räumt Shield der Reduzierung der Auswirkungen auf die Systemleistung Vorrang vor dem Abrufen des vollständigen Datensatzes aus den Protokollen ein. Dies kann zu einem Verlust der Granularität der Daten führen, die Shield zur Analyse zur Verfügung stehen. In den meisten Fällen ist der Großteil der Informationen verfügbar, aber es ist möglich, dass die Daten der wichtigsten Mitwirkenden bei jedem Angriff bis zu einem gewissen Grad verzerrt werden.
Der folgende Screenshot zeigt ein Beispiel für eine Registerkarte mit den **wichtigsten Mitwirkenden** für ein Ereignis auf Anwendungsebene.
![\[Auf der Registerkarte mit den meisten Mitwirkenden für ein Ereignis auf Anwendungsebene werden die fünf wichtigsten Mitwirkenden für eine Reihe von Merkmalen von Webanfragen beschrieben. Auf dem Bildschirm werden die fünf wichtigsten Quell-IP-Adressen, die fünf wichtigsten Zieladressen URLs, die fünf wichtigsten Quellländer und die fünf wichtigsten Benutzeragenten angezeigt.\]](http://docs.aws.amazon.com/de_de/waf/latest/developerguide/images/shield-app-event-top-contributors.png)
Die Informationen der Mitwirkenden basieren auf Anfragen sowohl für legitimen als auch für potenziell unerwünschten Datenverkehr. Bei Ereignissen mit größerem Volumen und bei Ereignissen, bei denen die Anforderungsquellen nicht weit verbreitet sind, ist die Wahrscheinlichkeit höher, dass die wichtigsten Mitwirkenden identifiziert werden können. Ein stark verteilter Angriff kann eine beliebige Anzahl von Quellen haben, was es schwierig macht, die Hauptverursacher des Angriffs zu identifizieren. Wenn Shield Advanced keine wesentlichen Mitwirkenden für eine bestimmte Kategorie identifiziert, werden die Daten als nicht verfügbar angezeigt.
# Ereignisdetails der Infrastrukturebene (Layer 3 oder 4) in Shield Advanced anzeigen
Im unteren Bereich der Konsolenseite für das Ereignis finden Sie Einzelheiten zur Erkennung und Abwehr eines Ereignisses auf Infrastrukturebene sowie zu den wichtigsten Mitwirkenden. Dieser Abschnitt kann eine Mischung aus legitimem und potenziell unerwünschtem Datenverkehr enthalten und kann sowohl Datenverkehr darstellen, der an Ihre geschützte Ressource weitergeleitet wurde, als auch Datenverkehr, der durch Shield-Schutzmaßnahmen blockiert wurde.
## Erkennung und Abwehr
Für ein Ereignis auf der Infrastrukturebene (Schicht 3 oder 4) werden auf der Registerkarte **Erkennung und Schadensbegrenzung** Erkennungsmetriken angezeigt, die auf Stichproben von Netzwerkströmen basieren, sowie Risikominderungsmetriken, die auf dem von den Minderungssystemen beobachteten Datenverkehr basieren. Risikominderungsmetriken sind eine genauere Messung des Datenverkehrs, der in Ihre Ressource fließt.
Shield erstellt automatisch eine Abwehr für die geschützten Ressourcentypen Elastic IP (EIP), Classic Load Balancer (CLB), Application Load Balancer (ALB) und Standard Accelerator. AWS Global Accelerator Abhilfemetriken für EIP-Adressen und AWS Global Accelerator Standardbeschleuniger geben die Anzahl der übergebenen und verworfenen Pakete an.
Der folgende Screenshot zeigt ein Beispiel für die Registerkarte **Erkennung und Schadensbegrenzung** für ein Ereignis auf Infrastrukturebene.
![\[Die Erkennungs- und Schadensbegrenzungsdiagramme für ein Netzwerkereignis zeigen einen zunehmenden SYN-Flood- und Packet-Flood-Verkehr in den Erkennungsmetriken, was mit einer Zunahme von Abhilfemaßnahmen einhergeht, die den Verkehr einige Sekunden später verringern, in den Risikomitriken. Nach etwa dreißig Sekunden verstärkter Abhilfemaßnahmen hören die Verkehrsfluten auf.\]](http://docs.aws.amazon.com/de_de/waf/latest/developerguide/images/shield-network-event-detection-mitigation.png)
Event-Traffic, der nachlässt, bevor Shield eine Schadensbegrenzung einleitet, wird in den Risikominderungsmetriken nicht berücksichtigt. Dies kann zu einem Unterschied zwischen dem in den Erkennungsdiagrammen angezeigten Verkehr und den Pass-and-Drop-Metriken in den Risikominderungsdiagrammen führen.
## Wichtigste Faktoren
Auf der Registerkarte mit den **wichtigsten Mitwirkenden** für Ereignisse auf Infrastrukturebene sind Metriken für bis zu 100 Hauptverursacher in verschiedenen Verkehrsdimensionen aufgeführt. Zu den Details gehören Eigenschaften der Netzwerkschicht für jede Dimension, bei der mindestens fünf signifikante Verkehrsquellen identifiziert werden konnten. Beispiele für Verkehrsquellen sind Quell-IP und Quell-ASN.
Der folgende Screenshot zeigt ein Beispiel für eine Registerkarte mit den **wichtigsten Mitwirkenden** für ein Ereignis auf Infrastrukturebene.
![\[Auf der Registerkarte mit den meisten Mitwirkenden für ein Netzwerkereignis werden die Kategorien des Datenverkehrs angezeigt, die am meisten zu dem Ereignis beigetragen haben. Zu den Kategorien gehören in diesem Fall Volumen für Protokoll, Volumen für Protokoll und Zielport, Volumen für Protokoll und Quell-ASN sowie Volumen für TCP-Flags.\]](http://docs.aws.amazon.com/de_de/waf/latest/developerguide/images/shield-network-event-top-contributors.png)
Die Metriken der Mitwirkenden basieren auf Stichproben von Netzwerkströmen sowohl für legitimen als auch für potenziell unerwünschten Datenverkehr. Bei Ereignissen mit größerem Volumen und Ereignissen, bei denen die Datenverkehrsquellen nicht stark verteilt sind, ist die Wahrscheinlichkeit höher, dass die Hauptverursacher identifiziert werden können. Ein stark verteilter Angriff kann eine beliebige Anzahl von Quellen haben, was es schwierig macht, die Hauptverursacher des Angriffs zu identifizieren. Wenn Shield keine wesentlichen Mitwirkenden für eine bestimmte Metrik oder Kategorie identifiziert, werden die Daten als nicht verfügbar angezeigt.
Bei einem Angriff auf die Infrastrukturschicht DDo S können Datenverkehrsquellen gefälscht oder widergespiegelt werden. Eine gefälschte Quelle wird vom Angreifer absichtlich gefälscht. Eine reflektierte Quelle ist die eigentliche Quelle des erkannten Datenverkehrs, aber sie ist nicht bereit, sich an dem Angriff zu beteiligen. Ein Angreifer könnte beispielsweise eine große, verstärkte Flut von Datenverkehr zu einem Ziel erzeugen, indem er den Angriff von Diensten im Internet ableitet, die normalerweise legitim sind. In diesem Fall sind die Quellinformationen möglicherweise gültig, obwohl sie nicht die eigentliche Quelle des Angriffs sind. Diese Faktoren können die Durchführbarkeit von Abhilfemaßnahmen einschränken, die Quellen auf der Grundlage von Paket-Headern blockieren.
# Shield Advanced-Ereignisse über mehrere anzeigen AWS-Konten mit AWS Firewall Manager und AWS Security Hub CSPM
Sie können AWS Shield Advanced geschützte Ressourcen AWS Security Hub CSPM für mehrere Konten verwenden AWS Firewall Manager und verwalten und überwachen.
Mit Firewall Manager können Sie eine Shield Advanced-Sicherheitsrichtlinie erstellen, die die DDo S-Protection-Konformität für all Ihre Konten meldet und durchsetzt. Firewall Manager überwacht Ihre geschützten Ressourcen und fügt auch Schutzmaßnahmen für neue Ressourcen hinzu, die in den Geltungsbereich der Shield Advanced-Richtlinie fallen.
Sie können Firewall Manager integrieren, AWS Security Hub CSPM um ein einziges Dashboard zu erhalten, das DDo S-Ereignisse meldet, die von Shield Advanced und Firewall Manager-Konformitätsergebnissen erkannt wurden, wenn Firewall Manager eine Ressource identifiziert, die nicht Ihren Shield Advanced-Sicherheitsrichtlinien entspricht.
Die folgende Abbildung zeigt eine typische Architektur für die Überwachung geschützter Shield Advanced-Ressourcen mit Firewall Manager und Security Hub CSPM.
![\[Am oberen Rand der Abbildung befindet sich ein Symbol. AWS Organizations Es hat einen nach unten zeigenden Pfeil, der sich so teilt, dass er auf zwei Symbole zeigt, die nebeneinander liegen. Das linke Symbol hat den Titel Production OU und das rechte Symbol hat den TitelSecurity OU. Unter diesen Symbolen befinden sich drei Symbole, die von links nach rechts betitelt sind: AWS Shield Advanced AWS Firewall Manager, und AWS Security Hub CSPM. Das Produktions-OU-Symbol hat einen Pfeil, der nach unten zum Shield Advanced-Symbol zeigt. Das Symbol für die Sicherheits-OU hat einen nach unten zeigenden Pfeil, der sich so teilt, dass er auf die CSPM-Symbole Firewall Manager und Security Hub zeigt. Das Shield Advanced-Symbol hat einen Pfeil, der nach unten auf ein Rechteck mit dem Titel zeigtShield Advanced protected resources. Innerhalb des Rechtecks befinden sich Symbole für Application Load Balancer, CloudFront Distribution und Elastic IP-Adresse. Das Firewall Manager Manager-Symbol hat auch einen Pfeil, der nach unten auf das Shield Advanced protected resources Rechteck zeigt, und es ist beschriftetEnforces compliance of protected resources. Das Shield Advanced-Symbol hat einen horizontalen Pfeil, der auf das beschriftete Firewall Manager Manager-Symbol zeigtDDoS alarm. Das Firewall Manager Manager-Symbol hat einen horizontalen Pfeil, der nach rechts zeigt, auf das Security Hub CSPM-Symbol, das beschriftet ist. DDoS alarm and compliance findings\]](http://docs.aws.amazon.com/de_de/waf/latest/developerguide/images/shield-arch-fms-ash-integration.png)
Wenn Sie Firewall Manager in Security Hub CSPM integrieren, können Sie Sicherheitsergebnisse zusammen mit anderen Warnmeldungen und Compliance-Statusinformationen für die Anwendungen, auf denen Sie laufen, an einem zentralen Ort einsehen. AWS
Der folgende Screenshot zeigt die Informationen, die Sie für ein Shield Advanced-Ereignis in der Security Hub CSPM-Konsole sehen können, wenn Sie über eine solche Integration verfügen.
![\[Der Screenshot zeigt die Seite mit den Ergebnissen der Security Hub CSPM-Konsole mit dem Untertitel Ein Ergebnis ist ein Sicherheitsproblem oder eine fehlgeschlagene Sicherheitsüberprüfung. . Der Abschnitt hat rote Umrandungen, die die folgenden Zeichenfolgen hervorheben: Titel EQUALS Shield Advanced hat einen Angriff auf die überwachte Ressource erkannt und Produktname EQUAL Firewall Manager. Der Bildschirm zeigt eine Reihe von Details über den spezifischen Angriff und seinen Status.\]](http://docs.aws.amazon.com/de_de/waf/latest/developerguide/images/shield-console-security-hub-event.png)
Wie Sie Firewall Manager und Security Hub CSPM mit Shield Advanced integrieren können, um die Ereignis- und Compliance-Überwachung Ihrer geschützten Konten zu zentralisieren, finden Sie im AWS Sicherheitsblog [Zentrale Überwachung für DDo S-Ereignisse einrichten und nicht konforme Ressourcen automatisch korrigieren](https://aws.amazon.com/blogs/security/set-up-centralized-monitoring-for-ddos-events-and-auto-remediate-noncompliant-resources/).
# Reagieren auf DDo S-Ereignisse in AWS
Diese Seite erklärt, wie AWS auf DDo S-Angriffe reagiert wird, und bietet Optionen, wie Sie weiter reagieren können.
AWS wehrt DDo S-Angriffe auf Netzwerk- und Transportebene (Layer 3 und Layer 4) automatisch ab. Wenn Sie Shield Advanced zum Schutz Ihrer EC2 Amazon-Instances verwenden, verteilt Shield Advanced während eines Angriffs automatisch Ihr Amazon VPC-Netzwerk ACLs an der Netzwerkgrenze. AWS Dadurch kann Shield Advanced Schutz vor größeren DDo S-Ereignissen bieten. Weitere Informationen zum Netzwerk ACLs finden Sie unter [Netzwerk ACLs](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_ACLs.html).
Bei Angriffen auf Anwendungsebene (Layer 7) DDo S wird AWS versucht, AWS Shield Advanced Kunden durch CloudWatch Alarme zu erkennen und zu benachrichtigen. Standardmäßig werden Abhilfemaßnahmen nicht automatisch angewendet, um zu verhindern, dass versehentlich gültiger Benutzerverkehr blockiert wird.
Für Ressourcen auf Anwendungsebene (Schicht 7) stehen Ihnen die folgenden Optionen zur Verfügung, um auf einen Angriff zu reagieren.
+ **Stellen Sie Ihre eigenen Abhilfemaßnahmen** bereit — Sie können den Angriff selbst untersuchen und abwehren. Weitere Informationen finden Sie unter [Manuelles Abwehren eines DDo Application-Layer-S-Angriffs](ddos-responding-manual.md).
+ **Support kontaktieren** — Wenn Sie ein Shield Advanced-Kunde sind, können Sie sich an das [AWS Support Center](https://console.aws.amazon.com/support/home#/) wenden, um Hilfe bei Abhilfemaßnahmen zu erhalten. Kritische und dringende Fälle werden direkt an DDo S-Experten weitergeleitet. Weitere Informationen finden Sie unter [Kontaktaufnahme mit dem Support Center während eines DDo Application-Layer-S-Angriffs](ddos-responding-contact-support.md).
Darüber hinaus können Sie vor einem Angriff proaktiv die folgenden Abwehroptionen aktivieren:
+ **Automatische Abhilfemaßnahmen Amazon CloudFront Amazon-Distributionen** — Mit dieser Option definiert und verwaltet Shield Advanced Regeln zur Schadensbegrenzung für Sie in Ihrer Web-ACL. Informationen zur automatischen Schadensbegrenzung auf Anwendungsebene finden Sie unter. [Automatisierung der Risikominderung auf Anwendungsebene DDo S mit Shield Advanced](ddos-automatic-app-layer-response.md)
+ **Proaktives Eingreifen** — Wenn ein umfangreicher Angriff auf Anwendungsebene gegen eine Ihrer Anwendungen AWS Shield Advanced erkannt wird, kann das SRT Sie proaktiv kontaktieren. Das SRT analysiert das DDo S-Ereignis und sorgt für Gegenmaßnahmen. AWS WAF Die SRT kontaktiert Sie und kann mit Ihrer Zustimmung die Regeln anwenden. AWS WAF Weitere Informationen zu dieser Option finden Sie unter [Einrichtung eines proaktiven Engagements für das SRT, um Sie direkt zu kontaktieren](ddos-srt-proactive-engagement.md).
# Kontaktaufnahme mit dem Support Center während eines DDo Application-Layer-S-Angriffs
Diese Seite enthält Anweisungen zur Kontaktaufnahme mit dem Support Center während eines DDo Application-Layer-S-Angriffs.
Wenn Sie ein AWS Shield Advanced Kunde sind, können Sie sich an das [AWS Support Center](https://console.aws.amazon.com/support/home#/) wenden, um Hilfe bei der Abwehr zu erhalten. Kritische und dringende Fälle werden direkt an DDo S-Experten weitergeleitet. Mit AWS Shield Advanced können komplexe Fälle an das AWS Shield Response Team (SRT) weitergeleitet werden, das über umfangreiche Erfahrung im Schutz AWS von Amazon.com und seinen Tochtergesellschaften verfügt. Weitere Informationen zum SRT finden Sie unter. [Verwaltete Reaktion auf DDo S-Ereignisse mit Unterstützung des Shield Response Team (SRT)](ddos-srt-support.md)
Um Support vom Shield Response Team (SRT) zu erhalten, wenden Sie sich an das [AWS Support Center](https://console.aws.amazon.com/support/home#/). Die Reaktionszeit für Ihren Fall hängt vom ausgewählten Schweregrad und den Reaktionszeiten ab, die auf der Seite [AWS Support Pläne](https://aws.amazon.com/premiumsupport/compare-plans/) dokumentiert sind.
Wählen Sie die folgenden Optionen:
+ Falltyp: Technischer Support
+ Service: Distributed Denial of Service (DDoS)
+ Kategorie: Eingehend an AWS
+ Schweregrad: *Wählen Sie eine geeignete Option*
Erklären Sie im Gespräch mit unserem Mitarbeiter, dass Sie ein AWS Shield Advanced Kunde sind, der von einem möglichen DDo S-Angriff betroffen ist. Unser Vertreter leitet Ihren Anruf an die entsprechenden DDo S-Experten weiter. Wenn Sie mit dem [AWS Support Center](https://console.aws.amazon.com/support/home#/) einen Fall über den Servicetyp **Distributed Denial of Service (DDoS)** eröffnen, können Sie per Chat oder Telefon direkt mit einem DDo S-Experten sprechen. DDoDie Support-Techniker von S können Ihnen bei der Identifizierung von Angriffen helfen, Verbesserungen an Ihrer AWS Architektur empfehlen und Sie bei der Nutzung von AWS Services zur Abwehr von DDo S-Angriffen beraten.
Bei Angriffen auf Anwendungsebene kann Ihnen das SRT bei der Analyse verdächtiger Aktivitäten helfen. Wenn Sie die automatische Abwehr für Ihre Ressource aktiviert haben, kann das SRT die Abhilfemaßnahmen überprüfen, die Shield Advanced automatisch gegen den Angriff einleitet. In jedem Fall kann Ihnen das SRT dabei helfen, das Problem zu überprüfen und zu beheben. Die vom SRT empfohlenen Maßnahmen erfordern häufig, dass das SRT AWS WAF Web-Zugriffskontrolllisten (Web ACLs) in Ihrem Konto erstellt oder aktualisiert. Für diese Arbeit benötigt das SRT Ihre Zustimmung.
**Wichtig**
Wir empfehlen, dass Sie im Rahmen der Aktivierung die unter beschriebenen Schritte befolgen AWS Shield Advanced, [Zugriff für das SRT gewähren](ddos-srt-access.md) um dem SRT proaktiv die Berechtigungen zu erteilen, die es benötigt, um Sie bei einem Angriff zu unterstützen. Die frühzeitige Zustimmung verhindert Verzögerungen im Falle eines tatsächlichen Angriffs.
Das SRT hilft Ihnen bei der Triage des DDo S-Angriffs, um Angriffssignaturen und -muster zu identifizieren. Mit Ihrer Zustimmung erstellt und implementiert das SRT AWS WAF Regeln zur Abwehr des Angriffs.
Sie können sich auch vor oder während eines möglichen Angriffs an das SRT wenden, um Abhilfemaßnahmen zu überprüfen und maßgeschneiderte Abhilfemaßnahmen zu entwickeln und einzusetzen. Wenn Sie beispielsweise eine Webanwendung ausführen und nur die Ports 80 und 443 geöffnet haben müssen, können Sie mit dem SRT eine Web-ACL so vorkonfigurieren, dass nur die Ports 80 und 443 „zugelassen“ werden.
Sie autorisieren und kontaktieren das SRT auf Kontoebene. Das heißt, wenn Sie Shield Advanced innerhalb einer Firewall Manager Shield Advanced-Richtlinie verwenden, muss sich der Kontoinhaber, nicht der Firewall Manager Manager-Administrator, an das SRT wenden, um Support zu erhalten. Der Firewall Manager Manager-Administrator kann das SRT nur für Konten kontaktieren, die er besitzt.
# Manuelles Abwehren eines DDo Application-Layer-S-Angriffs
Diese Seite enthält Anweisungen zur manuellen Abwehr eines Layer-S-Angriffs auf Anwendungsebene DDo.
Wenn Sie feststellen, dass die Aktivität auf der Ereignisseite für Ihre Ressource einen DDo S-Angriff darstellt, können Sie in Ihrer Web-ACL eigene AWS WAF Regeln erstellen, um den Angriff abzuwehren. Dies ist die einzige verfügbare Option, wenn Sie kein Shield Advanced-Kunde sind. AWS WAF ist ohne zusätzliche Kosten enthalten. AWS Shield Advanced Informationen zum Erstellen von Regeln in Ihrer Web-ACL finden Sie unter[Schutz konfigurieren in AWS WAF](web-acl.md).
Wenn Sie verwenden AWS Firewall Manager, können Sie Ihre AWS WAF Regeln zu einer Firewall Manager AWS WAF Manager-Richtlinie hinzufügen.
**Um einen potenziellen Application-Layer-S-Angriff manuell DDo abzuwehren**
1. Erstellen Sie in Ihrer Web-ACL Regelanweisungen mit Kriterien, die dem ungewöhnlichen Verhalten entsprechen. Konfigurieren Sie sie zunächst so, dass übereinstimmende Anfragen gezählt werden. Informationen zur Konfiguration Ihrer Web-ACL und Regelanweisungen finden Sie unter [Verwenden von Schutzpaketen (Web ACLs) mit Regeln und Regelgruppen in AWS WAF](web-acl-processing.md) und[Testen und Optimieren Ihrer AWS WAF Schutzmaßnahmen](web-acl-testing.md).
**Anmerkung**
Testen Sie Ihre Regeln immer zuerst, indem Sie zunächst die Regelaktion Count anstelle von verwendenBlock. Wenn Sie sicher sind, dass Ihre neuen Regeln die richtigen Anfragen identifizieren, können Sie sie ändern, um die Anfragen zu blockieren.
1. Überwachen Sie die Anzahl der Anfragen, um festzustellen, ob Sie die entsprechenden Anfragen blockieren möchten. Wenn das Volumen der Anfragen weiterhin ungewöhnlich hoch ist und Sie sicher sind, dass Ihre Regeln die Anfragen erfassen, die das hohe Volumen verursachen, ändern Sie die Regeln in Ihrer Web-ACL, um die Anfragen zu blockieren.
1. Überwachen Sie weiterhin die Seite mit den Ereignissen, um sicherzustellen, dass Ihr Datenverkehr so behandelt wird, wie Sie es möchten.
AWS bietet vorkonfigurierte Vorlagen, damit Sie schnell loslegen können. Die Vorlagen enthalten eine Reihe von AWS WAF Regeln, die Sie anpassen und verwenden können, um gängige webbasierte Angriffe zu blockieren. Weitere Informationen finden Sie unter [AWS WAF Security Automations](https://aws.amazon.com/solutions/aws-waf-security-automations/).
# AWS Shield Advanced Nach einem Angriff eine Gutschrift beantragen
Wenn Sie ein Abonnement haben AWS Shield Advanced und einen DDo S-Angriff erleben, der die Nutzung einer geschützten Shield Advanced-Ressource erhöht, können Sie eine Shield Advanced-Servicegutschrift für Gebühren im Zusammenhang mit der erhöhten Auslastung beantragen, sofern diese nicht durch Shield Advanced gemildert wird.
**Anmerkung**
Sie können alle durch diesen Vorgang erhaltenen Credits nur für die Nutzung von Shield Advanced verwenden. Shield Advanced-Guthaben können nicht mit anderen Diensten verwendet werden.
Guthaben sind nur für die folgenden Arten von Gebühren verfügbar:
+ Shield Advanced ausgehende Datenübertragung
+ Amazon CloudFront HTTP/HTTPS-Anfragen
+ CloudFront ausgehende Datenübertragung
+ Amazon Route 53-Abfragen
+ AWS Global Accelerator Standard-Beschleuniger-Datenübertragung
+ Load Balancer-Kapazitätseinheiten für Application Load Balancer
+ Instanzkosten für geschützte Amazon Elastic Compute Cloud (Amazon EC2) -Instances, die durch eine auto-scaling Skalierungsrichtlinie als Reaktion auf den Angriff erstellt wurden
**Voraussetzungen für die Beantragung einer Gutschrift**
Um Anspruch auf eine Gutschrift zu haben, müssen Sie vor Beginn des Angriffs Folgendes getan haben:
+ Sie müssen den Ressourcen, für die Sie eine Gutschrift beantragen möchten, Shield Advanced-Schutz hinzugefügt haben. Geschützte Ressourcen, die während eines Angriffs hinzugefügt wurden, kommen nicht für den Kostenschutz in Frage.
**Anmerkung**
Die Aktivierung von Shield Advanced auf Ihrem aktiviert AWS-Konto nicht automatisch den Shield Advanced-Schutz für einzelne Ressourcen.
Weitere Informationen zum Schutz von AWS Ressourcen mithilfe von Shield Advanced finden Sie unter[AWS Ressourcen AWS Shield Advanced schützen](configure-new-protection.md).
+ Für anwendbare CloudFront und durch Application Load Balancer geschützte Ressourcen müssen Sie eine AWS WAF Web-ACL zugeordnet und eine ratenbasierte Regel in der Web-ACL im Modus implementiert haben. Block Hinweise zu AWS WAF ratenbasierten Regeln finden Sie unter. [Verwendung ratenbasierter Regelanweisungen in AWS WAF](waf-rule-statement-type-rate-based.md) Informationen darüber, wie Sie das Internet ACLs mit AWS Ressourcen verknüpfen können, finden Sie unter. [Schutz konfigurieren in AWS WAF](web-acl.md)
+ Sie müssen die entsprechenden Best Practices in [AWS Best Practices for DDo S Resiliency](https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency) implementiert haben, um Ihre Anwendung so zu konfigurieren, dass die Kosten bei einem DDo S-Angriff minimiert werden.
**Wie beantrage ich einen Kredit**
Um Anspruch auf eine Gutschrift zu haben, müssen Sie Ihre Kreditanfrage innerhalb von 15 Tagen unmittelbar nach dem Abrechnungsmonat einreichen, in dem der Angriff stattgefunden hat.
Um eine Gutschrift zu beantragen, reichen Sie einen Rechnungsfall über das [AWS Support Center](https://console.aws.amazon.com/support/home#/) ein. Fügen Sie Ihrer Anfrage Folgendes bei:
+ Die Worte „DDoS Concession“ in der Betreffzeile
+ Datum und Uhrzeit der einzelnen Ereignisse oder Verfügbarkeitsunterbrechungen, für die Sie eine Gutschrift beantragen
+ Die AWS Dienste und spezifischen Ressourcen, die betroffen waren
Nachdem Sie eine Anfrage eingereicht haben, überprüft das AWS Shield Response Team (SRT), ob ein DDo S-Angriff stattgefunden hat und, falls ja, ob geschützte Ressourcen skaliert wurden, um den DDo S-Angriff abzuwehren. Es stellt AWS fest, dass geschützte Ressourcen so skaliert wurden, dass sie den DDo S-Angriff abwehren, und AWS stellt eine Gutschrift für den Teil des Datenverkehrs aus, der AWS feststellt, dass er durch den DDo S-Angriff verursacht wurde. Gutschriften sind für 12 Monate gültig.
# Sicherheit bei der Nutzung des AWS Shield Dienstes
In diesem Abschnitt wird erklärt, wie das Modell der gemeinsamen Verantwortung gilt für AWS Shield.
Cloud-Sicherheit AWS hat höchste Priorität. Als AWS Kunde profitieren Sie von einer Rechenzentrums- und Netzwerkarchitektur, die darauf ausgelegt sind, die Anforderungen der sicherheitssensibelsten Unternehmen zu erfüllen.
**Anmerkung**
Dieser Abschnitt enthält AWS Standardsicherheitsrichtlinien für Ihre Nutzung des AWS Shield Dienstes und seiner AWS Ressourcen, wie z. B. den erweiterten Schutz von Shield.
Informationen zum Schutz Ihrer AWS Ressourcen mit Shield und Shield Advanced finden Sie im Rest des AWS Shield Handbuchs.
Sicherheit ist eine gemeinsame Verantwortung von Ihnen AWS und Ihnen. Das [Modell der geteilten Verantwortung](https://aws.amazon.com/compliance/shared-responsibility-model/) beschreibt dies als Sicherheit *der* Cloud und Sicherheit *in* der Cloud:
+ **Sicherheit der Cloud** — AWS ist verantwortlich für den Schutz der Infrastruktur, auf der AWS Dienste in der ausgeführt AWS Cloud werden. AWS bietet Ihnen auch Dienste, die Sie sicher nutzen können. Die Wirksamkeit unserer Sicherheitsfunktionen wird regelmäßig von externen Prüfern im Rahmen des [AWS -Compliance-Programms getestet und überprüft](https://aws.amazon.com/compliance/programs/). Weitere Informationen zu den Compliance-Programmen, die für Shield gelten, finden Sie unter [AWS Services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/).
+ **Sicherheit in der Cloud** — Ihre Verantwortung richtet sich nach dem AWS Dienst, den Sie nutzen. In Ihre Verantwortung fallen außerdem weitere Faktoren, wie z. B. die Vertraulichkeit der Daten, die Anforderungen Ihrer Organisation sowie geltende Gesetze und Vorschriften.
Diese Dokumentation hilft Ihnen zu verstehen, wie Sie das Modell der gemeinsamen Verantwortung bei der Verwendung von Shield anwenden können. In den folgenden Themen erfahren Sie, wie Sie Shield konfigurieren, um Ihre Sicherheits- und Compliance-Ziele zu erreichen. Sie lernen auch, wie Sie andere AWS Dienste nutzen können, die Ihnen helfen, Ihre Shield-Ressourcen zu überwachen und zu sichern.
**Topics**
+ [Schützen Sie Ihre Daten in Shield](shd-data-protection.md)
+ [Verwenden von IAM mit AWS Shield](shd-security-iam.md)
+ [Protokollierung und Überwachung in Shield](shd-incident-response.md)
+ [Überprüfung der Konformität in Shield](shd-security-compliance.md)
+ [Aufbau von Resilienz in Shield](shd-disaster-recovery-resiliency.md)
+ [Infrastruktursicherheit in AWS Shield](shd-infrastructure-security.md)
# Schützen Sie Ihre Daten in Shield
In diesem Abschnitt wird erklärt, wie das Modell der AWS gemeinsamen Verantwortung für den Datenschutz in Shield gilt.
Das [Modell der AWS gemeinsamen Verantwortung](https://aws.amazon.com/compliance/shared-responsibility-model/) und geteilter Verantwortung gilt für den Datenschutz in AWS Shield. Wie in diesem Modell beschrieben, AWS ist verantwortlich für den Schutz der globalen Infrastruktur, auf der alle Systeme laufen AWS Cloud. Sie sind dafür verantwortlich, die Kontrolle über Ihre in dieser Infrastruktur gehosteten Inhalte zu behalten. Sie sind auch für die Sicherheitskonfiguration und die Verwaltungsaufgaben für die von Ihnen verwendeten AWS-Services verantwortlich. Weitere Informationen zum Datenschutz finden Sie unter [Häufig gestellte Fragen zum Datenschutz](https://aws.amazon.com/compliance/data-privacy-faq/). Informationen zum Datenschutz in Europa finden Sie im Blog-Beitrag [AWS -Modell der geteilten Verantwortung und in der DSGVO](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) im *AWS -Sicherheitsblog*.
Aus Datenschutzgründen empfehlen wir, dass Sie AWS-Konto Anmeldeinformationen schützen und einzelne Benutzer mit AWS IAM Identity Center oder AWS Identity and Access Management (IAM) einrichten. So erhält jeder Benutzer nur die Berechtigungen, die zum Durchführen seiner Aufgaben erforderlich sind. Außerdem empfehlen wir, die Daten mit folgenden Methoden schützen:
+ Verwenden Sie für jedes Konto die Multi-Faktor-Authentifizierung (MFA).
+ Wird verwendet SSL/TLS , um mit AWS Ressourcen zu kommunizieren. Wir benötigen TLS 1.2 und empfehlen TLS 1.3.
+ Richten Sie die API und die Protokollierung von Benutzeraktivitäten mit ein AWS CloudTrail. Informationen zur Verwendung von CloudTrail Pfaden zur Erfassung von AWS Aktivitäten finden Sie unter [Arbeiten mit CloudTrail Pfaden](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) im *AWS CloudTrail Benutzerhandbuch*.
+ Verwenden Sie AWS Verschlüsselungslösungen zusammen mit allen darin enthaltenen Standardsicherheitskontrollen AWS-Services.
+ Verwenden Sie erweiterte verwaltete Sicherheitsservices wie Amazon Macie, die dabei helfen, in Amazon S3 gespeicherte persönliche Daten zu erkennen und zu schützen.
+ Wenn Sie für den Zugriff AWS über eine Befehlszeilenschnittstelle oder eine API FIPS 140-3-validierte kryptografische Module benötigen, verwenden Sie einen FIPS-Endpunkt. Weitere Informationen über verfügbare FIPS-Endpunkte finden Sie unter [Federal Information Processing Standard (FIPS) 140-3](https://aws.amazon.com/compliance/fips/).
Wir empfehlen dringend, in Freitextfeldern, z. B. im Feld **Name**, keine vertraulichen oder sensiblen Informationen wie die E-Mail-Adressen Ihrer Kunden einzugeben. Dies gilt auch, wenn Sie mit Shield oder anderen AWS-Services über die Konsole AWS CLI, API oder arbeiten AWS SDKs. Alle Daten, die Sie in Tags oder Freitextfelder eingeben, die für Namen verwendet werden, können für Abrechnungs- oder Diagnoseprotokolle verwendet werden. Wenn Sie eine URL für einen externen Server bereitstellen, empfehlen wir dringend, keine Anmeldeinformationen zur Validierung Ihrer Anforderung an den betreffenden Server in die URL einzuschließen.
Shield-Einheiten — wie Schutzeinrichtungen — werden im Ruhezustand verschlüsselt, außer in bestimmten Regionen, in denen Verschlüsselung nicht verfügbar ist, darunter China (Peking) und China (Ningxia). Eindeutige Verschlüsselungsschlüssel werden für jede Region verwendet.
# Verwenden von IAM mit AWS Shield
In diesem Abschnitt wird erklärt, wie Sie IAM mit verwenden. AWS Shield
AWS Identity and Access Management (IAM) hilft einem Administrator AWS-Service , den Zugriff auf Ressourcen sicher zu AWS kontrollieren. IAM-Administratoren kontrollieren, wer *authentifiziert* (angemeldet) und *autorisiert* werden kann (über Berechtigungen verfügt), um Shield-Ressourcen zu verwenden. IAM ist ein Programm AWS-Service , das Sie ohne zusätzliche Kosten nutzen können.
**Topics**
+ [Zielgruppe](#security_iam_audience)
+ [Authentifizierung mit Identitäten](#security_iam_authentication)
+ [Verwalten des Zugriffs mit Richtlinien](#security_iam_access-manage)
+ [Wie AWS Shield funktioniert mit IAM](shd-security_iam_service-with-iam.md)
+ [Beispiele für identitätsbasierte Richtlinien für AWS Shield](shd-security_iam_id-based-policy-examples.md)
+ [AWS verwaltete Richtlinien für AWS Shield](shd-security-iam-awsmanpol.md)
+ [Problembehandlung bei AWS Shield Identität und Zugriff](shd-security_iam_troubleshoot.md)
+ [Verwenden von serviceverknüpften Rollen für Shield Advanced](shd-using-service-linked-roles.md)
## Zielgruppe
Wie Sie AWS Identity and Access Management (IAM) verwenden, hängt von der Arbeit ab, die Sie in Shield ausführen.
**Dienstbenutzer** — Wenn Sie den Shield-Dienst für Ihre Arbeit verwenden, stellt Ihnen Ihr Administrator die Anmeldeinformationen und Berechtigungen zur Verfügung, die Sie benötigen. Da Sie für Ihre Arbeit mehr Shield-Funktionen verwenden, benötigen Sie möglicherweise zusätzliche Berechtigungen. Wenn Sie die Funktionsweise der Zugriffskontrolle nachvollziehen, wissen Sie bereits, welche Berechtigungen Sie von Ihrem Administrator anfordern müssen. Wenn Sie in Shield nicht auf eine Funktion zugreifen können, finden Sie weitere Informationen unter[Problembehandlung bei AWS Shield Identität und Zugriff](shd-security_iam_troubleshoot.md).
**Serviceadministrator** — Wenn Sie in Ihrem Unternehmen für die Shield-Ressourcen verantwortlich sind, haben Sie wahrscheinlich vollen Zugriff auf Shield. Es ist Ihre Aufgabe, zu bestimmen, auf welche Shield-Funktionen und Ressourcen Ihre Servicebenutzer zugreifen sollen. Anschließend müssen Sie Anforderungen an Ihren IAM-Administrator senden, um die Berechtigungen der Servicebenutzer zu ändern. Lesen Sie die Informationen auf dieser Seite, um die Grundkonzepte von IAM nachzuvollziehen. Weitere Informationen darüber, wie Ihr Unternehmen IAM mit Shield verwenden kann, finden Sie unter[Wie AWS Shield funktioniert mit IAM](shd-security_iam_service-with-iam.md).
**IAM-Administrator** — Wenn Sie ein IAM-Administrator sind, möchten Sie vielleicht mehr darüber erfahren, wie Sie Richtlinien schreiben können, um den Zugriff auf Shield zu verwalten. Beispiele für identitätsbasierte Shield-Richtlinien, die Sie in IAM verwenden können, finden Sie unter. [Beispiele für identitätsbasierte Richtlinien für AWS Shield](shd-security_iam_id-based-policy-examples.md)
## Authentifizierung mit Identitäten
Authentifizierung ist die Art und Weise, wie Sie sich AWS mit Ihren Identitätsdaten anmelden. Sie müssen sich als IAM-Benutzer authentifizieren oder eine IAM-Rolle annehmen. Root-Benutzer des AWS-Kontos
Sie können sich als föderierte Identität anmelden, indem Sie Anmeldeinformationen aus einer Identitätsquelle wie AWS IAM Identity Center (IAM Identity Center), Single Sign-On-Authentifizierung oder Anmeldeinformationen verwenden. Google/Facebook Weitere Informationen zum Anmelden finden Sie unter [So melden Sie sich bei Ihrem AWS-Konto an](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) im *Benutzerhandbuch für AWS-Anmeldung *.
AWS Bietet für den programmatischen Zugriff ein SDK und eine CLI zum kryptografischen Signieren von Anfragen. Weitere Informationen finden Sie unter [AWS Signature Version 4 for API requests](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) im *IAM-Benutzerhandbuch*.
### AWS-Konto Root-Benutzer
Wenn Sie einen erstellen AWS-Konto, beginnen Sie mit einer Anmeldeidentität, dem sogenannten AWS-Konto *Root-Benutzer*, der vollständigen Zugriff auf alle AWS-Services Ressourcen hat. Wir raten ausdrücklich davon ab, den Root-Benutzer für Alltagsaufgaben zu verwenden. Eine Liste der Aufgaben, für die Sie sich als Root-Benutzer anmelden müssen, finden Sie unter [Tasks that require root user credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) im *IAM-Benutzerhandbuch*.
### Verbundidentität
Es hat sich bewährt, dass menschliche Benutzer für den Zugriff AWS-Services mithilfe temporärer Anmeldeinformationen einen Verbund mit einem Identitätsanbieter verwenden müssen.
Eine *föderierte Identität* ist ein Benutzer aus Ihrem Unternehmensverzeichnis, Ihrem Directory Service Web-Identitätsanbieter oder der AWS-Services mithilfe von Anmeldeinformationen aus einer Identitätsquelle zugreift. Verbundene Identitäten übernehmen Rollen, die temporäre Anmeldeinformationen bereitstellen.
Für die zentrale Zugriffsverwaltung empfehlen wir AWS IAM Identity Center. Weitere Informationen finden Sie unter [Was ist IAM Identity Center?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) im *AWS IAM Identity Center -Benutzerhandbuch*.
### IAM-Benutzer und -Gruppen
Ein *[IAM-Benutzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)* ist eine Identität mit bestimmten Berechtigungen für eine einzelne Person oder Anwendung. Wir empfehlen die Verwendung temporärer Anmeldeinformationen anstelle von IAM-Benutzern mit langfristigen Anmeldeinformationen. Weitere Informationen finden Sie im *IAM-Benutzerhandbuch* unter [Erfordern, dass menschliche Benutzer den Verbund mit einem Identitätsanbieter verwenden müssen, um AWS mithilfe temporärer Anmeldeinformationen darauf zugreifen zu](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) können.
Eine [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) spezifiziert eine Sammlung von IAM-Benutzern und erleichtert die Verwaltung von Berechtigungen für große Gruppen von Benutzern. Weitere Informationen finden Sie unter [Anwendungsfälle für IAM-Benutzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) im *IAM-Benutzerhandbuch*.
### IAM-Rollen
Eine *[IAM-Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* ist eine Identität mit spezifischen Berechtigungen, die temporäre Anmeldeinformationen bereitstellt. Sie können eine Rolle übernehmen, indem Sie [von einer Benutzer- zu einer IAM-Rolle (Konsole) wechseln](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) oder indem Sie eine AWS Oder-API-Operation AWS CLI aufrufen. Weitere Informationen finden Sie unter [Methoden, um eine Rolle zu übernehmen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html) im *IAM-Benutzerhandbuch*.
IAM-Rollen sind nützlich für den Verbundbenutzer-Zugriff, temporäre IAM-Benutzerberechtigungen, kontoübergreifenden Zugriff, serviceübergreifenden Zugriff und Anwendungen, die auf Amazon EC2 laufen. Weitere Informationen finden Sie unter [Kontoübergreifender Ressourcenzugriff in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) im *IAM-Benutzerhandbuch*.
## Verwalten des Zugriffs mit Richtlinien
Sie kontrollieren den Zugriff, AWS indem Sie Richtlinien erstellen und diese an AWS Identitäten oder Ressourcen anhängen. Eine Richtlinie definiert Berechtigungen, wenn sie mit einer Identität oder Ressource verknüpft sind. AWS bewertet diese Richtlinien, wenn ein Principal eine Anfrage stellt. Die meisten Richtlinien werden AWS als JSON-Dokumente gespeichert. Weitere Informationen zu JSON-Richtliniendokumenten finden Sie unter [Übersicht über JSON-Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) im *IAM-Benutzerhandbuch*.
Mit Hilfe von Richtlinien legen Administratoren fest, wer Zugriff auf was hat, indem sie definieren, welches **Prinzipal** welche **Aktionen** auf welchen **Ressourcen**und unter welchen **Bedingungen**durchführen darf.
Standardmäßig haben Benutzer, Gruppen und Rollen keine Berechtigungen. Ein IAM-Administrator erstellt IAM-Richtlinien und fügt sie zu Rollen hinzu, die die Benutzer dann übernehmen können. IAM-Richtlinien definieren Berechtigungen unabhängig von der Methode, die zur Ausführung der Operation verwendet wird.
### Identitätsbasierte Richtlinien
Identitätsbasierte Richtlinien sind JSON-Berechtigungsrichtliniendokumente, die Sie einer Identität (Benutzer, Gruppe oder Rolle) anfügen können. Diese Richtlinien steuern, welche Aktionen Identitäten für welche Ressourcen und unter welchen Bedingungen ausführen können. Informationen zum Erstellen identitätsbasierter Richtlinien finden Sie unter [Definieren benutzerdefinierter IAM-Berechtigungen mit vom Kunden verwalteten Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) im *IAM-Benutzerhandbuch*.
Identitätsbasierte Richtlinien können *Inline-Richtlinien* (direkt in eine einzelne Identität eingebettet) oder *verwaltete Richtlinien* (eigenständige Richtlinien, die mit mehreren Identitäten verbunden sind) sein. Informationen dazu, wie Sie zwischen verwalteten und Inline-Richtlinien wählen, finden Sie unter [Choose between managed policies and inline policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html) im *IAM-Benutzerhandbuch*.
### Ressourcenbasierte Richtlinien
Ressourcenbasierte Richtlinien sind JSON-Richtliniendokumente, die Sie an eine Ressource anfügen. Beispiele hierfür sind *Vertrauensrichtlinien für IAM-Rollen* und Amazon S3*-Bucket-Richtlinien*. In Services, die ressourcenbasierte Richtlinien unterstützen, können Service-Administratoren sie verwenden, um den Zugriff auf eine bestimmte Ressource zu steuern. Sie müssen in einer ressourcenbasierten Richtlinie [einen Prinzipal angeben](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html).
Ressourcenbasierte Richtlinien sind Richtlinien innerhalb dieses Diensts. Sie können AWS verwaltete Richtlinien von IAM nicht in einer ressourcenbasierten Richtlinie verwenden.
### Zugriffskontrolllisten () ACLs
Zugriffskontrolllisten (ACLs) steuern, welche Principals (Kontomitglieder, Benutzer oder Rollen) über Zugriffsberechtigungen für eine Ressource verfügen. ACLs ähneln ressourcenbasierten Richtlinien, verwenden jedoch nicht das JSON-Richtliniendokumentformat.
Amazon S3 und Amazon VPC sind Beispiele für Dienste, die Unterstützung ACLs bieten. AWS WAF Weitere Informationen finden Sie unter [Übersicht über ACLs die Zugriffskontrollliste (ACL)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html) im *Amazon Simple Storage Service Developer Guide*.
### Weitere Richtlinientypen
AWS unterstützt zusätzliche Richtlinientypen, mit denen die maximalen Berechtigungen festgelegt werden können, die durch gängigere Richtlinientypen gewährt werden:
+ **Berechtigungsgrenzen** – Eine Berechtigungsgrenze legt die maximalen Berechtigungen fest, die eine identitätsbasierte Richtlinie einer IAM-Entität erteilen kann. Weitere Informationen finden Sie unter [Berechtigungsgrenzen für IAM-Entitäten](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) im *-IAM-Benutzerhandbuch*.
+ **Richtlinien zur Dienstkontrolle (SCPs)** — Geben Sie die maximalen Berechtigungen für eine Organisation oder Organisationseinheit in an AWS Organizations. Weitere Informationen finden Sie unter [Service-Kontrollrichtlinien](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) im *AWS Organizations -Benutzerhandbuch*.
+ **Richtlinien zur Ressourcenkontrolle (RCPs)** — Legen Sie die maximal verfügbaren Berechtigungen für Ressourcen in Ihren Konten fest. Weitere Informationen finden Sie im *AWS Organizations Benutzerhandbuch* unter [Richtlinien zur Ressourcenkontrolle (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html).
+ **Sitzungsrichtlinien** – Sitzungsrichtlinien sind erweiterte Richtlinien, die als Parameter übergeben werden, wenn Sie eine temporäre Sitzung für eine Rolle oder einen Verbundbenutzer erstellen. Weitere Informationen finden Sie unter [Sitzungsrichtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) im *IAM-Benutzerhandbuch*.
### Mehrere Richtlinientypen
Wenn für eine Anfrage mehrere Arten von Richtlinien gelten, sind die sich daraus ergebenden Berechtigungen schwieriger zu verstehen. Informationen darüber, wie AWS bestimmt wird, ob eine Anfrage zulässig ist, wenn mehrere Richtlinientypen betroffen sind, finden Sie unter [Bewertungslogik für Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) im *IAM-Benutzerhandbuch*.
# Wie AWS Shield funktioniert mit IAM
In diesem Abschnitt wird erklärt, wie Sie die Funktionen von IAM mit verwenden. AWS Shield
Bevor Sie IAM verwenden, um den Zugriff auf Shield zu verwalten, sollten Sie sich darüber informieren, welche IAM-Funktionen für Shield verfügbar sind.
**IAM-Funktionen, die Sie mit verwenden können AWS Shield**
| IAM-Feature | Shield-Unterstützung |
| --- | --- |
| [Identitätsbasierte Richtlinien](#shd-security_iam_service-with-iam-id-based-policies) | Ja |
| [Ressourcenbasierte Richtlinien](#shd-security_iam_service-with-iam-resource-based-policies) | Nein |
| [Richtlinienaktionen](#shd-security_iam_service-with-iam-id-based-policies-actions) | Ja |
| [Richtlinienressourcen](#shd-security_iam_service-with-iam-id-based-policies-resources) | Ja |
| [Richtlinienbedingungsschlüssel (servicespezifisch)](#shd-security_iam_service-with-iam-id-based-policies-conditionkeys) | Ja |
| [ACLs](#shd-security_iam_service-with-iam-acls) | Nein |
| [ABAC (Tags in Richtlinien)](#shd-security_iam_service-with-iam-tags) | Teilweise |
| [Temporäre Anmeldeinformationen](#shd-security_iam_service-with-iam-roles-tempcreds) | Ja |
| [Forward Access Sessions (FAS)](#shd-security_iam_service-with-iam-principal-permissions) | Ja |
| [Servicerollen](#shd-security_iam_service-with-iam-roles-service) | Ja |
| [Service-verknüpfte Rollen](#shd-security_iam_service-with-iam-roles-service-linked) | Ja |
Einen allgemeinen Überblick darüber, wie Shield und andere AWS Dienste mit den meisten IAM-Funktionen funktionieren, finden Sie im [IAM-Benutzerhandbuch unter AWS Dienste, die mit *IAM* funktionieren](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html).
## Identitätsbasierte Richtlinien für Shield
Dieser Abschnitt enthält Beispiele für identitätsbasierte Richtlinien für. AWS Shield
**Unterstützt Richtlinien auf Identitätsbasis:** Ja
Identitätsbasierte Richtlinien sind JSON-Berechtigungsrichtliniendokumente, die Sie einer Identität anfügen können, wie z. B. IAM-Benutzern, -Benutzergruppen oder -Rollen. Diese Richtlinien steuern, welche Aktionen die Benutzer und Rollen für welche Ressourcen und unter welchen Bedingungen ausführen können. Informationen zum Erstellen identitätsbasierter Richtlinien finden Sie unter [Definieren benutzerdefinierter IAM-Berechtigungen mit vom Kunden verwalteten Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) im *IAM-Benutzerhandbuch*.
Mit identitätsbasierten IAM-Richtlinien können Sie angeben, welche Aktionen und Ressourcen zugelassen oder abgelehnt werden. Darüber hinaus können Sie die Bedingungen festlegen, unter denen Aktionen zugelassen oder abgelehnt werden. Informationen zu sämtlichen Elementen, die Sie in einer JSON-Richtlinie verwenden, finden Sie in der [IAM-Referenz für JSON-Richtlinienelemente](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) im *IAM-Benutzerhandbuch*.
Beispiele für identitätsbasierte Shield-Richtlinien finden Sie unter. [Beispiele für identitätsbasierte Richtlinien für AWS Shield](shd-security_iam_id-based-policy-examples.md)
## Ressourcenbasierte Richtlinien innerhalb von Shield
**Unterstützt ressourcenbasierte Richtlinien:** Nein
Ressourcenbasierte Richtlinien sind JSON-Richtliniendokumente, die Sie an eine Ressource anfügen. Beispiele für ressourcenbasierte Richtlinien sind IAM-*Rollen-Vertrauensrichtlinien* und Amazon-S3-*Bucket-Richtlinien*. In Services, die ressourcenbasierte Richtlinien unterstützen, können Service-Administratoren sie verwenden, um den Zugriff auf eine bestimmte Ressource zu steuern. Für die Ressource, an welche die Richtlinie angehängt ist, legt die Richtlinie fest, welche Aktionen ein bestimmter Prinzipal unter welchen Bedingungen für diese Ressource ausführen kann. Sie müssen in einer ressourcenbasierten Richtlinie [einen Prinzipal angeben](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html). Zu den Prinzipalen können Konten, Benutzer, Rollen, Verbundbenutzer oder gehören. AWS-Services
Um kontoübergreifenden Zugriff zu ermöglichen, können Sie ein gesamtes Konto oder IAM-Entitäten in einem anderen Konto als Prinzipal in einer ressourcenbasierten Richtlinie angeben. Weitere Informationen finden Sie unter [Kontoübergreifender Ressourcenzugriff in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) im *IAM-Benutzerhandbuch*.
## Politische Maßnahmen für Shield
**Unterstützt Richtlinienaktionen:** Ja
Administratoren können mithilfe von AWS JSON-Richtlinien angeben, wer auf was Zugriff hat. Das heißt, welcher **Prinzipal** **Aktionen** für welche **Ressourcen** und unter welchen **Bedingungen** ausführen kann.
Das Element `Action` einer JSON-Richtlinie beschreibt die Aktionen, mit denen Sie den Zugriff in einer Richtlinie zulassen oder verweigern können. Nehmen Sie Aktionen in eine Richtlinie auf, um Berechtigungen zur Ausführung des zugehörigen Vorgangs zu erteilen.
Eine Liste der Shield-Aktionen finden Sie unter [Aktionen definiert von AWS Shield](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsshield.html#awsshield-actions-as-permissions) in der *Service Authorization Reference*.
Richtlinienaktionen in Shield verwenden vor der Aktion das folgende Präfix:
```
shield
```
Um mehrere Aktionen in einer einzigen Anweisung anzugeben, trennen Sie sie mit Kommata:
```
"Action": [
"shield:action1",
"shield:action2"
]
```
Sie können auch Platzhalter verwenden, um mehrere Aktionen anzugeben. Um beispielsweise alle Aktionen in Shield anzugeben, die mit beginnen`List`, schließen Sie die folgende Aktion ein:
```
"Action": "shield:List*"
```
Beispiele für identitätsbasierte Shield-Richtlinien finden Sie unter. [Beispiele für identitätsbasierte Richtlinien für AWS Shield](shd-security_iam_id-based-policy-examples.md)
## Politische Ressourcen für Shield
**Unterstützt Richtlinienressourcen:** Ja
Administratoren können mithilfe von AWS JSON-Richtlinien angeben, wer auf was Zugriff hat. Das heißt, welcher **Prinzipal** **Aktionen** für welche **Ressourcen** und unter welchen **Bedingungen** ausführen kann.
Das JSON-Richtlinienelement `Resource` gibt die Objekte an, auf welche die Aktion angewendet wird. Als Best Practice geben Sie eine Ressource mit dem zugehörigen [Amazon-Ressourcennamen (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html) an. Verwenden Sie für Aktionen, die keine Berechtigungen auf Ressourcenebene unterstützen, einen Platzhalter (\$1), um anzugeben, dass die Anweisung für alle Ressourcen gilt.
```
"Resource": "*"
```
Eine Liste der Shield-Ressourcentypen und ihrer ARNs Typen finden Sie unter [Resources defined by AWS Shield](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsshield.html#awsshield-resources-for-iam-policies) in der *Service Authorization Reference*. Informationen zu den Aktionen, mit denen Sie den ARN einzelner Ressourcen angeben können, finden Sie unter [Von AWS Shield definierte Aktionen](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsshield.html#awsshield-actions-as-permissions). Um den Zugriff auf eine Teilmenge der Shield-Ressourcen zu erlauben oder zu verweigern, nehmen Sie den ARN der Ressource in das `resource` Element Ihrer Richtlinie auf.
*Bei AWS Shield den Ressourcen handelt es sich um *Schutzmaßnahmen und Angriffe*.* Diesen Ressourcen sind eindeutige Amazon-Ressourcennamen (ARNs) zugeordnet, wie in der folgenden Tabelle dargestellt.
****
| Name in der AWS Shield Konsole | Name im AWS Shield SDK/CLI | ARN-Format |
| --- | --- | --- |
| Ereignis oder Angriff | AttackDetail | `arn:aws:shield::account:attack/ID` |
| Schutz | Protection | `arn:aws:shield::account:protection/ID` |
Um den Zugriff auf eine Teilmenge der Shield-Ressourcen zu erlauben oder zu verweigern, nehmen Sie den ARN der Ressource in das `resource` Element Ihrer Richtlinie auf. Die ARNs for Shield haben das folgende Format:
```
arn:partition:shield::account:resource/ID
```
Ersetzen Sie die *ID* Variablen *account**resource*, und durch gültige Werte. Gültige Werte können beispielsweise folgende sein:
+ *account*: Die ID Ihres AWS-Konto. Sie müssen einen Wert angeben.
+ *resource*: Der Typ der Shield-Ressource, entweder `attack` oder`protection`.
+ *ID*: Die ID der Shield-Ressource oder ein Platzhalter (`*`), um alle Ressourcen des angegebenen Typs anzugeben, die mit der angegebenen AWS-Konto Ressource verknüpft sind.
Der folgende ARN gibt zum Beispiel alle Schutzmaßnahmen für das Konto `111122223333` an:
```
arn:aws:shield::111122223333:protection/*
```
Die Ressourcen ARNs von Shield haben das folgende Format:
```
arn:partition:shield:region:account-id:scope/resource-type/resource-name/resource-id
```
Allgemeine Informationen zu ARN-Spezifikationen finden Sie unter [Amazon Resource Names (ARNs)](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) in der Allgemeine Amazon Web Services-Referenz.
Im Folgenden sind die Anforderungen aufgeführt, die für die ARNs einzelnen `wafv2` Ressourcen spezifisch sind:
+ *region*: Für Shield-Ressourcen, die Sie zum Schutz von CloudFront Amazon-Distributionen verwenden, setzen Sie diesen Wert auf`us-east-1`. Andernfalls setzen Sie dies auf die Region, die Sie mit Ihren geschützten regionalen Ressourcen verwenden.
+ *scope*: Legen Sie den Geltungsbereich auf `global` für die Verwendung mit einer CloudFront Amazon-Distribution oder `regional` für die Verwendung mit einer der regionalen Ressourcen fest, die dies AWS WAF unterstützen. Bei den regionalen Ressourcen handelt es sich um eine Amazon API Gateway Gateway-REST-API, einen Application Load Balancer, eine AWS AppSync GraphQL-API, einen Amazon Cognito Cognito-Benutzerpool, einen AWS App Runner Service und eine AWS Verified Access-Instance.
+ *resource-type*: Geben Sie einen der folgenden Werte an: `attack` für Ereignisse oder Angriffe, `protection` für Schutzmaßnahmen.
+ *resource-name*: Geben Sie den Namen an, den Sie der Shield-Ressource gegeben haben, oder geben Sie einen Platzhalter (`*`) an, um alle Ressourcen anzugeben, die die anderen Spezifikationen im ARN erfüllen. Sie müssen entweder den Ressourcennamen und die Ressourcen-ID oder für beide einen Platzhalter angeben.
+ *resource-id*: Geben Sie die ID der Shield-Ressource an, oder geben Sie einen Platzhalter (`*`) an, um alle Ressourcen anzugeben, die die anderen Spezifikationen im ARN erfüllen. Sie müssen entweder den Ressourcennamen und die Ressourcen-ID oder einen Platzhalter für beide angeben.
Der folgende ARN gibt beispielsweise alle Websites ACLs mit regionalem Geltungsbereich für das Konto `111122223333` in Region an`us-west-1`:
```
arn:aws:wafv2:us-west-1:111122223333:regional/webacl/*/*
```
Der folgende ARN gibt die Regelgruppe `MyIPManagementRuleGroup` mit dem globalen Geltungsbereich für das Konto `111122223333` in Region an`us-east-1`:
```
arn:aws:wafv2:us-east-1:111122223333:global/rulegroup/MyIPManagementRuleGroup/1111aaaa-bbbb-cccc-dddd-example-id
```
Beispiele für identitätsbasierte Shield-Richtlinien finden Sie unter. [Beispiele für identitätsbasierte Richtlinien für AWS Shield](shd-security_iam_id-based-policy-examples.md)
## Schlüssel zu den Policy-Bedingungen für Shield
**Unterstützt servicespezifische Richtlinienbedingungsschlüssel:** Ja
Administratoren können mithilfe von AWS JSON-Richtlinien angeben, wer auf was Zugriff hat. Das heißt, welcher **Prinzipal** **Aktionen** für welche **Ressourcen** und unter welchen **Bedingungen** ausführen kann.
Das Element `Condition` gibt an, wann Anweisungen auf der Grundlage definierter Kriterien ausgeführt werden. Sie können bedingte Ausdrücke erstellen, die [Bedingungsoperatoren](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html) verwenden, z. B. ist gleich oder kleiner als, damit die Bedingung in der Richtlinie mit Werten in der Anforderung übereinstimmt. Eine Übersicht aller AWS globalen Bedingungsschlüssel finden Sie unter [Kontextschlüssel für AWS globale Bedingungen](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) im *IAM-Benutzerhandbuch*.
Eine Liste der Shield-Bedingungsschlüssel finden Sie unter [Bedingungsschlüssel für AWS Shield](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsshield.html#awsshield-policy-keys) in der *Service Authorization Reference*. Informationen zu den Aktionen und Ressourcen, mit denen Sie einen Bedingungsschlüssel verwenden können, finden Sie unter [Aktionen definiert von AWS Shield](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsshield.html#awsshield-actions-as-permissions).
Beispiele für identitätsbasierte Shield-Richtlinien finden Sie unter. [Beispiele für identitätsbasierte Richtlinien für AWS Shield](shd-security_iam_id-based-policy-examples.md)
## ACLs in Shield
**Unterstützt ACLs:** Nein
Zugriffskontrolllisten (ACLs) steuern, welche Principals (Kontomitglieder, Benutzer oder Rollen) über Zugriffsberechtigungen für eine Ressource verfügen. ACLs ähneln ressourcenbasierten Richtlinien, verwenden jedoch nicht das JSON-Richtliniendokumentformat.
## ABAC mit Shield
**Unterstützt ABAC (Tags in Richtlinien):** Teilweise
Die attributbasierte Zugriffskontrolle (ABAC) ist eine Autorisierungsstrategie, bei der Berechtigungen basierend auf Attributen, auch als Tags bezeichnet, definiert werden. Sie können Tags an IAM-Entitäten und AWS -Ressourcen anhängen und dann ABAC-Richtlinien entwerfen, die Operationen zulassen, wenn das Tag des Prinzipals mit dem Tag auf der Ressource übereinstimmt.
Um den Zugriff auf der Grundlage von Tags zu steuern, geben Sie im Bedingungselement einer[ Richtlinie Tag-Informationen ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)an, indem Sie die Schlüssel `aws:ResourceTag/key-name`, `aws:RequestTag/key-name`, oder Bedingung `aws:TagKeys` verwenden.
Wenn ein Service alle drei Bedingungsschlüssel für jeden Ressourcentyp unterstützt, lautet der Wert für den Service **Ja**. Wenn ein Service alle drei Bedingungsschlüssel für nur einige Ressourcentypen unterstützt, lautet der Wert **Teilweise**.
*Weitere Informationen zu ABAC finden Sie unter [Definieren von Berechtigungen mit ABAC-Autorisierung](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) im IAM-Benutzerhandbuch*. Um ein Tutorial mit Schritten zur Einstellung von ABAC anzuzeigen, siehe [Attributbasierte Zugriffskontrolle (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) verwenden im *IAM-Benutzerhandbuch*.
## Temporäre Anmeldeinformationen mit Shield verwenden
**Unterstützt temporäre Anmeldeinformationen:** Ja
Temporäre Anmeldeinformationen ermöglichen kurzfristigen Zugriff auf AWS Ressourcen und werden automatisch erstellt, wenn Sie einen Verbund verwenden oder die Rollen wechseln. AWS empfiehlt, temporäre Anmeldeinformationen dynamisch zu generieren, anstatt langfristige Zugriffsschlüssel zu verwenden. Weitere Informationen finden Sie unter [Temporäre Anmeldeinformationen in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) und [AWS-Services , die mit IAM funktionieren](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) im *IAM-Benutzerhandbuch*.
## Zugriffssitzungen für Shield weiterleiten
**Unterstützt Forward Access Sessions (FAS):** Ja
Forward-Access-Sitzungen (FAS) verwenden die Berechtigungen des Prinzipals, der einen aufruft AWS-Service, kombiniert mit der Anforderung, Anfragen AWS-Service an nachgelagerte Dienste zu stellen. Einzelheiten zu den Richtlinien für FAS-Anforderungen finden Sie unter [Zugriffssitzungen weiterleiten](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html).
## Servicerollen für Shield
**Unterstützt Servicerollen:** Ja
Eine Servicerolle ist eine [IAM-Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html), die ein Service annimmt, um Aktionen in Ihrem Namen auszuführen. Ein IAM-Administrator kann eine Servicerolle innerhalb von IAM erstellen, ändern und löschen. Weitere Informationen finden Sie unter [Erstellen einer Rolle zum Delegieren von Berechtigungen an einen AWS-Service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) im *IAM-Benutzerhandbuch*.
**Warnung**
Durch das Ändern der Berechtigungen für eine Servicerolle kann die Shield-Funktionalität beeinträchtigt werden. Bearbeiten Sie Servicerollen nur, wenn Shield Sie dazu anleitet.
## Servicebezogene Rollen für Shield
**Unterstützt serviceverknüpfte Rollen:** Ja
Eine dienstbezogene Rolle ist eine Art von Servicerolle, die mit einer verknüpft ist. AWS-Service Der Service kann die Rolle übernehmen, um eine Aktion in Ihrem Namen auszuführen. Dienstbezogene Rollen werden in Ihrem Dienst angezeigt AWS-Konto und gehören dem Dienst. Ein IAM-Administrator kann die Berechtigungen für Service-verknüpfte Rollen anzeigen, aber nicht bearbeiten.
Einzelheiten zum Erstellen oder Verwalten von dienstbezogenen Shield-Rollen finden Sie unter[Verwenden von serviceverknüpften Rollen für Shield Advanced](shd-using-service-linked-roles.md).
# Beispiele für identitätsbasierte Richtlinien für AWS Shield
Standardmäßig sind Benutzer und Rollen nicht berechtigt, Shield-Ressourcen zu erstellen oder zu ändern. Ein IAM-Administrator muss IAM-Richtlinien erstellen, die Benutzern die Berechtigung erteilen, Aktionen für die Ressourcen auszuführen, die sie benötigen.
Informationen dazu, wie Sie unter Verwendung dieser beispielhaften JSON-Richtliniendokumente eine identitätsbasierte IAM-Richtlinie erstellen, finden Sie unter [Erstellen von IAM-Richtlinien (Konsole)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) im *IAM-Benutzerhandbuch*.
Einzelheiten zu den von Shield definierten Aktionen und Ressourcentypen, einschließlich des Formats ARNs für die einzelnen Ressourcentypen, finden Sie unter [Aktionen, Ressourcen und Bedingungsschlüssel für AWS Shield](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsshield.html) in der *Service Authorization Reference*.
**Topics**
+ [Best Practices für Richtlinien](#shd-security_iam_service-with-iam-policy-best-practices)
+ [Verwenden der Shield-Konsole](#shd-security_iam_id-based-policy-examples-console)
+ [Gewähren der Berechtigung zur Anzeige der eigenen Berechtigungen für Benutzer](#shd-security_iam_id-based-policy-examples-view-own-permissions)
+ [Gewähren Sie Lesezugriff auf Ihre Shield Advanced-Schutzmaßnahmen](#shd-example0)
+ [Gewähren Sie nur Lesezugriff auf Shield,, und CloudFront CloudWatch](#shd-example1)
+ [Vollzugriff auf Shield gewähren CloudFront, und CloudWatch](#shd-example2)
## Best Practices für Richtlinien
Identitätsbasierte Richtlinien legen fest, ob jemand Shield-Ressourcen in Ihrem Konto erstellen, darauf zugreifen oder sie löschen kann. Dies kann zusätzliche Kosten für Ihr verursachen AWS-Konto. Wenn Sie identitätsbasierte Richtlinien erstellen oder bearbeiten, befolgen Sie diese Richtlinien und Empfehlungen:
+ **Erste Schritte mit AWS verwalteten Richtlinien und Umstellung auf Berechtigungen mit den geringsten Rechten** — Verwenden Sie die *AWS verwalteten Richtlinien*, die Berechtigungen für viele gängige Anwendungsfälle gewähren, um damit zu beginnen, Ihren Benutzern und Workloads Berechtigungen zu gewähren. Sie sind in Ihrem verfügbar. AWS-Konto Wir empfehlen Ihnen, die Berechtigungen weiter zu reduzieren, indem Sie vom AWS Kunden verwaltete Richtlinien definieren, die speziell auf Ihre Anwendungsfälle zugeschnitten sind. Weitere Informationen finden Sie unter [Von AWS verwaltete Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) oder [Von AWS verwaltete Richtlinien für Auftragsfunktionen](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) im *IAM-Benutzerhandbuch*.
+ **Anwendung von Berechtigungen mit den geringsten Rechten** – Wenn Sie mit IAM-Richtlinien Berechtigungen festlegen, gewähren Sie nur die Berechtigungen, die für die Durchführung einer Aufgabe erforderlich sind. Sie tun dies, indem Sie die Aktionen definieren, die für bestimmte Ressourcen unter bestimmten Bedingungen durchgeführt werden können, auch bekannt als *die geringsten Berechtigungen*. Weitere Informationen zur Verwendung von IAM zum Anwenden von Berechtigungen finden Sie unter [ Richtlinien und Berechtigungen in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) im *IAM-Benutzerhandbuch*.
+ **Verwenden von Bedingungen in IAM-Richtlinien zur weiteren Einschränkung des Zugriffs** – Sie können Ihren Richtlinien eine Bedingung hinzufügen, um den Zugriff auf Aktionen und Ressourcen zu beschränken. Sie können beispielsweise eine Richtlinienbedingung schreiben, um festzulegen, dass alle Anforderungen mithilfe von SSL gesendet werden müssen. Sie können auch Bedingungen verwenden, um Zugriff auf Serviceaktionen zu gewähren, wenn diese für einen bestimmten Zweck verwendet werden AWS-Service, z. CloudFormation B. Weitere Informationen finden Sie unter [IAM-JSON-Richtlinienelemente: Bedingung](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) im *IAM-Benutzerhandbuch*.
+ **Verwenden von IAM Access Analyzer zur Validierung Ihrer IAM-Richtlinien, um sichere und funktionale Berechtigungen zu gewährleisten** – IAM Access Analyzer validiert neue und vorhandene Richtlinien, damit die Richtlinien der IAM-Richtliniensprache (JSON) und den bewährten IAM-Methoden entsprechen. IAM Access Analyzer stellt mehr als 100 Richtlinienprüfungen und umsetzbare Empfehlungen zur Verfügung, damit Sie sichere und funktionale Richtlinien erstellen können. Weitere Informationen finden Sie unter [Richtlinienvalidierung mit IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) im *IAM-Benutzerhandbuch*.
+ **Multi-Faktor-Authentifizierung (MFA) erforderlich** — Wenn Sie ein Szenario haben, das IAM-Benutzer oder einen Root-Benutzer in Ihrem System erfordert AWS-Konto, aktivieren Sie MFA für zusätzliche Sicherheit. Um MFA beim Aufrufen von API-Vorgängen anzufordern, fügen Sie Ihren Richtlinien MFA-Bedingungen hinzu. Weitere Informationen finden Sie unter [Sicherer API-Zugriff mit MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) im *IAM-Benutzerhandbuch*.
Weitere Informationen zu bewährten Methoden in IAM finden Sie unter [Best Practices für die Sicherheit in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) im *IAM-Benutzerhandbuch*.
## Verwenden der Shield-Konsole
Um auf die AWS Shield Konsole zugreifen zu können, benötigen Sie ein Mindestmaß an Berechtigungen. Diese Berechtigungen müssen es Ihnen ermöglichen, Details zu den Shield-Ressourcen in Ihrem aufzulisten und anzuzeigen AWS-Konto. Wenn Sie eine identitätsbasierte Richtlinie erstellen, die strenger ist als die mindestens erforderlichen Berechtigungen, funktioniert die Konsole nicht wie vorgesehen für Entitäten (Benutzer oder Rollen) mit dieser Richtlinie.
Sie müssen Benutzern, die nur die API AWS CLI oder die AWS API aufrufen, keine Mindestberechtigungen für die Konsole gewähren. Stattdessen sollten Sie nur Zugriff auf die Aktionen zulassen, die der API-Operation entsprechen, die die Benutzer ausführen möchten.
Benutzer, die auf die AWS Konsole zugreifen und sie verwenden können, können auch auf die AWS Shield Konsole zugreifen. Es sind keine zusätzlichen Berechtigungen erforderlich.
### Nur für die Konsole APIs
In der Konsole können Sie auf die folgenden Informationen zu Distributed Denial of Service (DDoS) -Angriffen zugreifen. Geben Sie die folgenden API-Berechtigungen in einer IAM-Richtlinie an, um bestimmte Aktionen zuzulassen oder abzulehnen.
| Action | Description |
| --- | --- |
| DescribeAttackContributors | Erteilt die Erlaubnis, detaillierte Informationen über die Verursacher eines bestimmten DDo S-Angriffs abzurufen. |
| ListMitigations | Erteilt die Berechtigung zum Abrufen einer Liste von Abhilfemaßnahmen, die bei DDo S-Angriffen angewendet wurden. |
| GetGlobalThreatData | Erteilt die Genehmigung zum Abrufen globaler Bedrohungsdaten und Trends aus den Bedrohungsüberwachungssystemen von AWS Shield. |
Dieses Beispiel zeigt, wie Sie eine Richtlinie erstellen könnten, die es Ihnen ermöglicht, Informationen zu DDo S-Angriffen in der Konsole zu sehen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"shield:DescribeAttackContributors"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"shield:ListMitigations"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"shield:GetGlobalThreatData"
],
"Resource": "*"
}
]
}
```
------
## Gewähren der Berechtigung zur Anzeige der eigenen Berechtigungen für Benutzer
In diesem Beispiel wird gezeigt, wie Sie eine Richtlinie erstellen, die IAM-Benutzern die Berechtigung zum Anzeigen der eingebundenen Richtlinien und verwalteten Richtlinien gewährt, die ihrer Benutzeridentität angefügt sind. Diese Richtlinie umfasst Berechtigungen zum Ausführen dieser Aktion auf der Konsole oder programmgesteuert mithilfe der AWS CLI AWS OR-API.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
## Gewähren Sie Lesezugriff auf Ihre Shield Advanced-Schutzmaßnahmen
AWS Shield ermöglicht den kontoübergreifenden Zugriff auf Ressourcen, ermöglicht Ihnen jedoch nicht, kontenübergreifende Schutzmaßnahmen für Ressourcen einzurichten. Sie können Schutz für Ressourcen nur aus dem Konto erstellen, das der Besitzer dieser Ressourcen ist.
Es folgt ein Beispiel für eine Richtlinie, die Berechtigungen für die `shield:ListProtections`-Aktionen für alle Ressourcen erteilt. Shield unterstützt für einige API-Aktionen nicht die Identifizierung bestimmter Ressourcen mithilfe der Ressource ARNs (auch als Berechtigungen auf Ressourcenebene bezeichnet). Daher geben Sie ein Platzhalterzeichen (\$1) an. Dies ermöglicht nur den Zugriff auf die Ressourcen, die Sie durch die Aktion abrufen können. `ListProtections`
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ListProtections",
"Effect": "Allow",
"Action": [
"shield:ListProtections"
],
"Resource": "*"
}
]
}
```
------
## Gewähren Sie nur Lesezugriff auf Shield,, und CloudFront CloudWatch
Die folgende Richtlinie gewährt Benutzern nur Lesezugriff auf Shield und zugehörige Ressourcen, einschließlich CloudFront Amazon-Ressourcen und CloudWatch Amazon-Metriken. Es ist nützlich für Benutzer, die die Erlaubnis benötigen, die Einstellungen in Shield Protections and Attacks einzusehen und Metriken zu überwachen. CloudWatch Diese Benutzer können keine Shield-Ressourcen erstellen, aktualisieren oder löschen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ProtectedResourcesReadAccess",
"Effect": "Allow",
"Action": [
"cloudfront:List*",
"route53:List*",
"cloudfront:Describe*",
"elasticloadbalancing:Describe*",
"cloudwatch:Describe*",
"cloudwatch:Get*",
"cloudwatch:List*",
"cloudfront:GetDistribution*",
"globalaccelerator:ListAccelerators",
"globalaccelerator:DescribeAccelerator"
],
"Resource": [
"arn:aws:elasticloadbalancing:*:*:*",
"arn:aws:cloudfront::*:*",
"arn:aws:route53:::hostedzone/*",
"arn:aws:cloudwatch:*:*:*:*",
"arn:aws:globalaccelerator::*:*"
]
},
{
"Sid": "ShieldReadOnly",
"Effect": "Allow",
"Action": [
"shield:List*",
"shield:Describe*",
"shield:Get*"
],
"Resource": "*"
}
]
}
```
------
## Vollzugriff auf Shield gewähren CloudFront, und CloudWatch
Mit der folgenden Richtlinie können Benutzer alle Shield-Operationen und alle Operationen auf CloudFront Webverteilungen ausführen sowie Metriken und eine Stichprobe von Anfragen in CloudWatch überwachen. Es ist nützlich für Benutzer, die Shield-Administratoren sind.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ProtectedResourcesReadAccess",
"Effect": "Allow",
"Action": [
"cloudfront:List*",
"route53:List*",
"cloudfront:Describe*",
"elasticloadbalancing:Describe*",
"cloudwatch:Describe*",
"cloudwatch:Get*",
"cloudwatch:List*",
"cloudfront:GetDistribution*",
"globalaccelerator:ListAccelerators",
"globalaccelerator:DescribeAccelerator"
],
"Resource": [
"arn:aws:elasticloadbalancing:*:*:*",
"arn:aws:cloudfront::*:*",
"arn:aws:route53:::hostedzone/*",
"arn:aws:cloudwatch:*:*:*:*",
"arn:aws:globalaccelerator::*:*"
]
},
{
"Sid": "ShieldFullAccess",
"Effect": "Allow",
"Action": [
"shield:*"
],
"Resource": "*"
}
]
}
```
------
Es wird dringend empfohlen, dass Sie die Multi-Factor Authentication (MFA, Multifaktor-Authentifizierung) für Benutzer mit Administrator-Berechtigungen konfigurieren. Weitere Informationen finden Sie unter [Using Multi-Factor Authentication (MFA) -Geräte mit AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/Using_ManagingMFA.html) im *IAM-Benutzerhandbuch*.
# AWS verwaltete Richtlinien für AWS Shield
Eine AWS verwaltete Richtlinie ist eine eigenständige Richtlinie, die von erstellt und verwaltet wird AWS. AWS Verwaltete Richtlinien sind so konzipiert, dass sie Berechtigungen für viele gängige Anwendungsfälle bereitstellen, sodass Sie damit beginnen können, Benutzern, Gruppen und Rollen Berechtigungen zuzuweisen.
Beachten Sie, dass AWS verwaltete Richtlinien für Ihre speziellen Anwendungsfälle möglicherweise keine Berechtigungen mit den geringsten Rechten gewähren, da sie allen AWS Kunden zur Verfügung stehen. Wir empfehlen Ihnen, die Berechtigungen weiter zu reduzieren, indem Sie [vom Kunden verwaltete Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) definieren, die speziell auf Ihre Anwendungsfälle zugeschnitten sind.
Sie können die in AWS verwalteten Richtlinien definierten Berechtigungen nicht ändern. Wenn die in einer AWS verwalteten Richtlinie definierten Berechtigungen AWS aktualisiert werden, wirkt sich das Update auf alle Prinzidentitäten (Benutzer, Gruppen und Rollen) aus, denen die Richtlinie zugeordnet ist. AWS aktualisiert eine AWS verwaltete Richtlinie höchstwahrscheinlich, wenn eine neue Richtlinie eingeführt AWS-Service wird oder neue API-Operationen für bestehende Dienste verfügbar werden.
Weitere Informationen finden Sie unter [Von AWS verwaltete Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) im *IAM-Benutzerhandbuch*.
## AWS verwaltete Richtlinie: AWSShield DRTAccess Richtlinie
In diesem Abschnitt wird erklärt, wie AWS verwaltete Richtlinien für Shield verwendet werden.
AWS Shield verwendet diese verwaltete Richtlinie, wenn Sie dem Shield Response Team (SRT) die Erlaubnis erteilen, in Ihrem Namen zu handeln. Diese Richtlinie gewährt dem SRT eingeschränkten Zugriff auf Ihr AWS Konto, um bei der Abwehr von DDo S-Angriffen bei schwerwiegenden Ereignissen zu helfen. Diese Richtlinie ermöglicht es der SRT, Ihre AWS WAF Regeln und Shield Advanced-Schutzmaßnahmen zu verwalten und auf Ihre AWS WAF Protokolle zuzugreifen.
Informationen darüber, wie Sie der SRT die Erlaubnis erteilen, in Ihrem Namen tätig zu werden, finden Sie unter. [Zugriff für das SRT gewähren](ddos-srt-access.md)
Einzelheiten zu dieser Richtlinie finden Sie unter [AWSShieldDRTAccessRichtlinie](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/service-role/AWSShieldDRTAccessPolicy) in der IAM-Konsole.
## AWS verwaltete Richtlinie: AWSShield ServiceRolePolicy
Shield Advanced verwendet diese verwaltete Richtlinie, wenn Sie die automatische Abwehr auf Anwendungsebene DDo S aktivieren, um die Berechtigungen festzulegen, die für die Verwaltung der Ressourcen für Ihr Konto erforderlich sind. Diese Richtlinie ermöglicht Shield Advanced, AWS WAF Regeln und Regelgruppen im Internet zu erstellen und anzuwenden ACLs, die Sie Ihren geschützten Ressourcen zugeordnet haben, um automatisch auf DDo S-Angriffe zu reagieren.
Sie können keine Verbindungen AWSShield ServiceRolePolicy zu Ihren IAM-Entitäten herstellen. Shield fügt diese Richtlinie der dienstbezogenen Rolle hinzu`AWSServiceRoleForAWSShield`, damit Shield Aktionen in Ihrem Namen durchführen kann.
Shield Advanced ermöglicht die Verwendung dieser Richtlinie, wenn Sie die automatische Abwehr auf Anwendungsebene DDo S aktivieren. Weitere Informationen zur Verwendung dieser Richtlinie finden Sie unter[Automatisierung der Risikominderung auf Anwendungsebene DDo S mit Shield Advanced](ddos-automatic-app-layer-response.md).
Informationen zur dienstbezogenen Rolle AWSService RoleForAWSShield , die diese Richtlinie verwendet, finden Sie unter [Verwenden von serviceverknüpften Rollen für Shield Advanced](shd-using-service-linked-roles.md)
Einzelheiten zu dieser Richtlinie finden Sie unter [AWSShieldServiceRolePolicy](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/aws-service-role/AWSShieldServiceRolePolicy)In der IAM-Konsole.
## Shield-Updates für AWS verwaltete Richtlinien
Sehen Sie sich Details zu Aktualisierungen der AWS verwalteten Richtlinien für Shield an, seit dieser Dienst begonnen hat, diese Änderungen zu verfolgen. Um automatische Benachrichtigungen über Änderungen an dieser Seite zu erhalten, abonnieren Sie den RSS-Feed auf der Shield-Dokumentenverlaufsseite unter[Dokumentverlauf](doc-history.md).
| Richtlinie | Beschreibung der Änderung | Date |
| --- | --- | --- |
| `AWSShieldServiceRolePolicy` Diese Richtlinie ermöglicht Shield den Zugriff auf und die Verwaltung von AWS Ressourcen, um automatisch in Ihrem Namen auf DDo Application-Layer-S-Angriffe zu reagieren. Details in der IAM-Konsole: [AWSShieldServiceRolePolicy](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/aws-service-role/AWSShieldServiceRolePolicy) Die serviceverknüpfte Rolle `AWSServiceRoleForAWSShield` verwendet diese Richtlinie. Weitere Informationen finden Sie unter [Verwenden von serviceverknüpften Rollen für Shield Advanced](shd-using-service-linked-roles.md). | Diese Richtlinie wurde hinzugefügt, um Shield Advanced die Berechtigungen zu gewähren, die für die automatische Schadensbegrenzungsfunktion auf Anwendungsebene DDo S erforderlich sind. Informationen zu dieser Funktion finden Sie unter[Automatisierung der Risikominderung auf Anwendungsebene DDo S mit Shield Advanced](ddos-automatic-app-layer-response.md). | 1. Dezember 2021 |
| Shield hat begonnen, Änderungen zu verfolgen | Shield begann, Änderungen für seine AWS verwalteten Richtlinien zu verfolgen. | 3. März 2021 |
# Problembehandlung bei AWS Shield Identität und Zugriff
Verwenden Sie die folgenden Informationen, um häufig auftretende Probleme zu diagnostizieren und zu beheben, die bei der Arbeit mit Shield und IAM auftreten können.
**Topics**
+ [Ich bin nicht berechtigt, eine Aktion in Shield durchzuführen](#shd-security_iam_troubleshoot-no-permissions)
+ [Ich bin nicht berechtigt, iam auszuführen: PassRole](#shd-security_iam_troubleshoot-passrole)
+ [Ich möchte Personen außerhalb von mir den Zugriff AWS-Konto auf meine Shield-Ressourcen ermöglichen](#shd-security_iam_troubleshoot-cross-account-access)
## Ich bin nicht berechtigt, eine Aktion in Shield durchzuführen
Wenn Sie eine Fehlermeldung erhalten, dass Sie nicht zur Durchführung einer Aktion berechtigt sind, müssen Ihre Richtlinien aktualisiert werden, damit Sie die Aktion durchführen können.
Der folgende Beispielfehler tritt auf, wenn der IAM-Benutzer `mateojackson` versucht, über die Konsole Details zu einer fiktiven `my-example-widget`-Ressource anzuzeigen, jedoch nicht über `shield:GetWidget`-Berechtigungen verfügt.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: shield:GetWidget on resource: my-example-widget
```
In diesem Fall muss die Richtlinie für den Benutzer `mateojackson` aktualisiert werden, damit er mit der `shield:GetWidget`-Aktion auf die `my-example-widget`-Ressource zugreifen kann.
Wenn Sie Hilfe benötigen, wenden Sie sich an Ihren AWS Administrator. Ihr Administrator hat Ihnen Ihre Anmeldeinformationen zur Verfügung gestellt.
## Ich bin nicht berechtigt, iam auszuführen: PassRole
Wenn Sie eine Fehlermeldung erhalten, dass Sie nicht berechtigt sind, die `iam:PassRole` Aktion durchzuführen, müssen Ihre Richtlinien aktualisiert werden, damit Sie eine Rolle an Shield übergeben können.
Einige AWS-Services ermöglichen es Ihnen, eine bestehende Rolle an diesen Dienst zu übergeben, anstatt eine neue Servicerolle oder eine dienstverknüpfte Rolle zu erstellen. Hierzu benötigen Sie Berechtigungen für die Übergabe der Rolle an den Dienst.
Der folgende Beispielfehler tritt auf, wenn ein IAM-Benutzer mit dem Namen `marymajor` versucht, die Konsole zu verwenden, um eine Aktion in Shield auszuführen. Die Aktion erfordert jedoch, dass der Service über Berechtigungen verfügt, die durch eine Servicerolle gewährt werden. Mary besitzt keine Berechtigungen für die Übergabe der Rolle an den Dienst.
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
In diesem Fall müssen die Richtlinien von Mary aktualisiert werden, um die Aktion `iam:PassRole` ausführen zu können.
Wenn Sie Hilfe benötigen, wenden Sie sich an Ihren AWS Administrator. Ihr Administrator hat Ihnen Ihre Anmeldeinformationen zur Verfügung gestellt.
## Ich möchte Personen außerhalb von mir den Zugriff AWS-Konto auf meine Shield-Ressourcen ermöglichen
Sie können eine Rolle erstellen, mit der Benutzer in anderen Konten oder Personen außerhalb Ihrer Organisation auf Ihre Ressourcen zugreifen können. Sie können festlegen, wem die Übernahme der Rolle anvertraut wird. Für Dienste, die ressourcenbasierte Richtlinien oder Zugriffskontrolllisten (ACLs) unterstützen, können Sie diese Richtlinien verwenden, um Personen Zugriff auf Ihre Ressourcen zu gewähren.
Weitere Informationen dazu finden Sie hier:
+ Informationen darüber, ob Shield diese Funktionen unterstützt, finden Sie unter[Wie AWS Shield funktioniert mit IAM](shd-security_iam_service-with-iam.md).
+ *Informationen dazu, wie Sie Zugriff auf Ihre Ressourcen gewähren können, AWS-Konten die Ihnen gehören, finden Sie im IAM-Benutzerhandbuch unter [Gewähren des Zugriffs für einen IAM-Benutzer in einem anderen AWS-Konto , den Sie besitzen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html).*
+ Informationen dazu, wie Sie Dritten Zugriff auf Ihre Ressourcen gewähren können AWS-Konten, finden Sie [AWS-Konten im *IAM-Benutzerhandbuch* unter Gewähren des Zugriffs für Dritte](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html).
+ Informationen dazu, wie Sie über einen Identitätsverbund Zugriff gewähren, finden Sie unter [Gewähren von Zugriff für extern authentifizierte Benutzer (Identitätsverbund)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) im *IAM-Benutzerhandbuch*.
+ Informationen zum Unterschied zwischen der Verwendung von Rollen und ressourcenbasierten Richtlinien für den kontoübergreifenden Zugriff finden Sie unter [So unterscheiden sich IAM-Rollen von ressourcenbasierten Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html) im *IAM-Benutzerhandbuch*.
# Verwenden von serviceverknüpften Rollen für Shield Advanced
In diesem Abschnitt wird erklärt, wie Sie dienstbezogene Rollen verwenden, um Shield Advanced Zugriff auf Ressourcen in Ihrem AWS Konto zu gewähren.
AWS Shield Advanced verwendet AWS Identity and Access Management (IAM) [dienstgebundene](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) Rollen. Eine serviceverknüpfte Rolle ist eine einzigartige Art von IAM-Rolle, die direkt mit Shield Advanced verknüpft ist. Dienstbezogene Rollen sind von Shield Advanced vordefiniert und beinhalten alle Berechtigungen, die der Dienst benötigt, um andere AWS Dienste in Ihrem Namen aufzurufen.
Eine dienstbezogene Rolle erleichtert die Einrichtung von Shield Advanced, da Sie die erforderlichen Berechtigungen nicht manuell hinzufügen müssen. Shield Advanced definiert die Berechtigungen seiner dienstbezogenen Rollen, und sofern nicht anders definiert, kann nur Shield Advanced seine Rollen übernehmen. Die definierten Berechtigungen umfassen die Vertrauens- und Berechtigungsrichtlinie. Diese Berechtigungsrichtlinie kann keinen anderen IAM-Entitäten zugewiesen werden.
Sie können eine serviceverknüpfte Rolle erst löschen, nachdem ihre verwandten Ressourcen gelöscht wurden. Dies schützt Ihre Shield Advanced-Ressourcen, da Sie nicht versehentlich die Zugriffsberechtigung für die Ressourcen entfernen können.
Informationen zu anderen Services, die serviceverknüpften Rollen unterstützen, finden Sie unter [AWS -Services, die mit IAM funktionieren](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html). Suchen Sie nach den Services, für die **Ja** in der Spalte **Serviceverknüpfte Rolle** angegeben ist. Wählen Sie über einen Link **Ja** aus, um die Dokumentation zu einer serviceverknüpften Rolle für diesen Service anzuzeigen.
## Dienstbezogene Rollenberechtigungen für Shield Advanced
Shield Advanced verwendet die mit dem Dienst verknüpfte Rolle namens **AWSServiceRoleForAWSShield**. Diese Rolle ermöglicht Shield Advanced den Zugriff auf und die Verwaltung von AWS Ressourcen, um in Ihrem Namen automatisch auf DDo Application-Layer-S-Angriffe zu reagieren. Weitere Informationen zu dieser Funktion finden Sie unter[Automatisierung der Risikominderung auf Anwendungsebene DDo S mit Shield Advanced](ddos-automatic-app-layer-response.md).
Die AWSService RoleFor AWSShield dienstverknüpfte Rolle vertraut darauf, dass die folgenden Dienste die Rolle übernehmen:
+ `shield.amazonaws.com`
Die genannte Rollenberechtigungsrichtlinie AWSShield ServiceRolePolicy ermöglicht Shield Advanced, die folgenden Aktionen für alle AWS Ressourcen durchzuführen:
+ `wafv2:GetWebACL`
+ `wafv2:UpdateWebACL`
+ `wafv2:GetWebACLForResource`
+ `wafv2:ListResourcesForWebACL`
+ `cloudfront:ListDistributions`
+ `cloudfront:GetDistribution`
Wenn Aktionen für alle AWS Ressourcen zulässig sind, wird dies in der Richtlinie als angegeben`"Resource": "*"`. Dies bedeutet lediglich, dass die dienstbezogene Rolle jede angegebene Aktion für alle AWS Ressourcen ausführen kann*, die von der Aktion unterstützt* werden. Die Aktion `wafv2:GetWebACL` wird beispielsweise nur für `wafv2` Web-ACL-Ressourcen unterstützt.
Shield Advanced führt nur API-Aufrufe auf Ressourcenebene für geschützte Ressourcen durch, für die Sie die Schutzfunktion auf Anwendungsebene aktiviert haben, und für Websites ACLs , die mit diesen geschützten Ressourcen verknüpft sind.
Sie müssen Berechtigungen konfigurieren, damit eine juristische Stelle von IAM (z. B. Benutzer, Gruppe oder Rolle) eine serviceverknüpfte Rolle erstellen, bearbeiten oder löschen kann. Weitere Informationen finden Sie unter [serviceverknüpfte Rollenberechtigungen](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) im *IAM-Benutzerhandbuch*.
## Eine serviceverknüpfte Rolle für Shield Advanced erstellen
Sie müssen eine serviceverknüpfte Rolle nicht manuell erstellen. Wenn Sie die automatische Abwehr auf Anwendungsebene DDo S für eine Ressource in der AWS-Managementkonsole, der oder der AWS API aktivieren AWS CLI, erstellt Shield Advanced die serviceverknüpfte Rolle für Sie.
Wenn Sie diese serviceverknüpfte Rolle löschen und sie dann erneut erstellen müssen, können Sie dasselbe Verfahren anwenden, um die Rolle in Ihrem Konto neu anzulegen. Wenn Sie die automatische Abwehr auf Anwendungsebene DDo S für eine Ressource aktivieren, erstellt Shield Advanced die serviceverknüpfte Rolle erneut für Sie.
## Bearbeiten einer serviceverknüpften Rolle für Shield Advanced
Shield Advanced erlaubt Ihnen nicht, die AWSService RoleFor AWSShield serviceverknüpfte Rolle zu bearbeiten. Da möglicherweise verschiedene Entitäten auf die Rolle verweisen, kann der Rollenname nach dem Erstellen einer serviceverknüpften Rolle nicht mehr geändert werden. Sie können jedoch die Beschreibung der Rolle mit IAM bearbeiten. Weitere Informationen finden Sie unter [Bearbeiten einer serviceverknüpften Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) im *IAM-Benutzerhandbuch*.
## Löschen einer serviceverknüpften Rolle für Shield Advanced
Wenn Sie ein Feature oder einen Dienst, die bzw. der eine serviceverknüpften Rolle erfordert, nicht mehr benötigen, sollten Sie diese Rolle löschen. Auf diese Weise haben Sie keine ungenutzte juristische Stelle, die nicht aktiv überwacht oder verwaltet wird. Sie müssen jedoch die Ressourcen für Ihre serviceverknüpften Rolle zunächst bereinigen, bevor Sie sie manuell löschen können.
**Anmerkung**
Wenn Shield Advanced die Rolle verwendet, wenn Sie versuchen, die Ressourcen zu löschen, schlägt das Löschen möglicherweise fehl. Wenn dies passiert, warten Sie einige Minuten und versuchen Sie es erneut.
**Um die Shield Advanced-Ressourcen zu löschen, die von AWSService RoleFor AWSShield**
Deaktivieren Sie für all Ihre Ressourcen, für die Schutzmaßnahmen auf Anwendungsebene DDo S konfiguriert sind, die automatische Abwehr von Anwendungsschicht DDo S. Anleitungen zur Konsole finden Sie unter [Konfigurieren Sie den Schutz der Anwendungsebene DDo S](manage-protection.md#configure-app-layer-protection).
**So löschen Sie die serviceverknüpfte Rolle mit IAM**
Verwenden Sie die IAM-Konsole, die oder die AWS API AWS CLI, um die serviceverknüpfte Rolle zu löschen. AWSService RoleFor AWSShield Weitere Informationen finden Sie unter [Löschen einer serviceverknüpften Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) im *IAM-Leitfaden*.
## Unterstützte Regionen für Service-verknüpfte Shield Advanced-Rollen
Shield Advanced unterstützt die Verwendung von dienstbezogenen Rollen in allen Regionen, in denen der Service verfügbar ist. Weitere Informationen finden Sie unter [Shield Advanced-Endpunkte und Kontingente](https://docs.aws.amazon.com/general/latest/gr/shield.html).
# Protokollierung und Überwachung in Shield
In diesem Abschnitt wird erläutert, wie Sie AWS Tools zur Überwachung und Reaktion auf Ereignisse in verwenden AWS Shield.
Die Überwachung ist ein wichtiger Bestandteil der Aufrechterhaltung der Zuverlässigkeit, Verfügbarkeit und Leistung von Shield und Ihren AWS Lösungen. Sie sollten Überwachungsdaten aus allen Teilen Ihrer AWS Lösung sammeln, damit Sie einen etwaigen Ausfall an mehreren Stellen leichter debuggen können. AWS bietet verschiedene Tools zur Überwachung Ihrer Shield-Ressourcen und zur Reaktion auf potenzielle Ereignisse:
** CloudWatch Amazon-Alarme**
Mithilfe von CloudWatch Alarmen beobachten Sie eine einzelne Metrik über einen von Ihnen angegebenen Zeitraum. Wenn die Metrik einen bestimmten Schwellenwert überschreitet, CloudWatch sendet eine Benachrichtigung an ein Amazon SNS SNS-Thema oder eine AWS Auto Scaling Richtlinie. Weitere Informationen finden Sie unter [Überwachung mit Amazon CloudWatch](monitoring-cloudwatch.md).
**AWS CloudTrail Logs**
CloudTrail bietet eine Aufzeichnung der Aktionen, die von einem Benutzer, einer Rolle oder einem AWS Dienst in Shield ausgeführt wurden. Anhand der von gesammelten Informationen können Sie die Anfrage CloudTrail, die an Shield gestellt wurde, die IP-Adresse, von der aus die Anfrage gestellt wurde, wer die Anfrage gestellt hat, wann sie gestellt wurde, und weitere Details ermitteln. Weitere Informationen finden Sie unter [Protokollierung von AWS CloudTrail-API-Aufrufen mit](logging-using-cloudtrail.md).
# Überprüfung der Konformität in Shield
In diesem Abschnitt wird Ihre Verantwortung für die Einhaltung der Vorschriften bei der Verwendung von erläutert AWS Shield.
Informationen darüber, ob AWS-Service ein [AWS-Services in den Geltungsbereich bestimmter Compliance-Programme fällt, finden Sie unter Umfang nach Compliance-Programm AWS-Services unter](https://aws.amazon.com/compliance/services-in-scope/) . Wählen Sie dort das Compliance-Programm aus, an dem Sie interessiert sind. Allgemeine Informationen finden Sie unter [AWS Compliance-Programme AWS](https://aws.amazon.com/compliance/programs/) .
Sie können Prüfberichte von Drittanbietern unter herunterladen AWS Artifact. Weitere Informationen finden Sie unter [Berichte herunterladen unter ](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html).
Ihre Verantwortung für die Einhaltung der Vorschriften bei der Nutzung AWS-Services hängt von der Vertraulichkeit Ihrer Daten, den Compliance-Zielen Ihres Unternehmens und den geltenden Gesetzen und Vorschriften ab. Weitere Informationen zu Ihrer Verantwortung für die Einhaltung der Vorschriften bei der Nutzung AWS-Services finden Sie in der [AWS Sicherheitsdokumentation](https://docs.aws.amazon.com/security/).
# Aufbau von Resilienz in Shield
In diesem Abschnitt wird erklärt, wie die AWS Architektur Datenredundanz für unterstützt. AWS Shield
Die AWS globale Infrastruktur basiert auf AWS-Regionen Availability Zones. AWS-Regionen bieten mehrere physisch getrennte und isolierte Availability Zones, die über Netzwerke mit niedriger Latenz, hohem Durchsatz und hoher Redundanz miteinander verbunden sind. Mithilfe von Availability Zones können Sie Anwendungen und Datenbanken erstellen und ausführen, die automatisch Failover zwischen Availability Zones ausführen, ohne dass es zu Unterbrechungen kommt. Availability Zones sind besser hoch verfügbar, fehlertoleranter und skalierbarer als herkömmliche Infrastrukturen mit einem oder mehreren Rechenzentren.
Weitere Informationen zu Availability Zones AWS-Regionen und Availability Zones finden Sie unter [AWS Globale](https://aws.amazon.com/about-aws/global-infrastructure/) Infrastruktur.
# Infrastruktursicherheit in AWS Shield
In diesem Abschnitt wird erklärt, wie der AWS Shield Dienstverkehr isoliert wird.
Als verwalteter Dienst AWS Shield ist er durch AWS globale Netzwerksicherheit geschützt. Informationen zu AWS Sicherheitsdiensten und zum AWS Schutz der Infrastruktur finden Sie unter [AWS Cloud-Sicherheit](https://aws.amazon.com/security/). Informationen zum Entwerfen Ihrer AWS Umgebung unter Verwendung der bewährten Methoden für die Infrastruktursicherheit finden Sie unter [Infrastructure Protection](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) in *Security Pillar AWS Well‐Architected Framework*.
Sie verwenden AWS veröffentlichte API-Aufrufe, um über das Netzwerk auf Shield zuzugreifen. Kunden müssen Folgendes unterstützen:
+ Transport Layer Security (TLS). Wir benötigen TLS 1.2 und empfehlen TLS 1.3.
+ Verschlüsselungs-Suiten mit Perfect Forward Secrecy (PFS) wie DHE (Ephemeral Diffie-Hellman) oder ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). Die meisten modernen Systeme wie Java 7 und höher unterstützen diese Modi.
# AWS Shield Advanced Kontingente
AWS Shield Advanced hat Standardkontingente für die Anzahl der Entitäten pro Region. Sie können [eine Erhöhung dieser Kontingente beantragen](https://console.aws.amazon.com/servicequotas/home/services/shield/quotas).
| Ressource | Standardkontingent |
| --- | --- |
| Maximale Anzahl geschützter Ressourcen für jeden Ressourcentyp, der Schutz AWS Shield Advanced bietet, pro Konto. | 1.000 |
| Maximale Anzahl von Schutzgruppen pro Konto. | 100 |
| Maximale Anzahl einzelner geschützter Ressourcen, die Sie speziell in eine Schutzgruppe aufnehmen können. In der API bezieht sich dies auf `Members` die, die Sie bei der Einstellung der Schutzgruppe `Pattern` angeben`ARBITRARY`. In der Konsole gilt dies für die Ressourcen, die Sie für die Schutzgruppe Wählen Sie **aus geschützten Ressourcen auswählen auswählen**. | 1.000 |