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.
# Reduzierung der Angriffsfläche
Ein weiterer wichtiger Aspekt bei der Entwicklung einer AWS Lösung ist die Begrenzung der Möglichkeiten, die ein Angreifer hat, Ihre Anwendung ins Visier zu nehmen. Dieses Konzept wird als *Reduzierung der Angriffsfläche* bezeichnet. Ressourcen, die nicht dem Internet ausgesetzt sind, sind schwieriger anzugreifen, wodurch die Möglichkeiten, die Angreifer haben, die Verfügbarkeit Ihrer Anwendung ins Visier zu nehmen, eingeschränkt sind.
Wenn Sie beispielsweise nicht erwarten, dass Benutzer direkt mit bestimmten Ressourcen interagieren, stellen Sie sicher, dass diese Ressourcen nicht über das Internet zugänglich sind. Ebenso sollten Sie keinen Datenverkehr von Benutzern oder externen Anwendungen über Ports oder Protokolle akzeptieren, die für die Kommunikation nicht erforderlich sind.
Im folgenden Abschnitt finden Sie AWS bewährte Methoden, mit denen Sie Ihre Angriffsfläche reduzieren und die Internetgefährdung Ihrer Anwendung einschränken können.
# Verschleierung von AWS Ressourcen (BP1,,) BP4 BP5
In der Regel können Benutzer eine Anwendung schnell und einfach verwenden, ohne dass die AWS Ressourcen vollständig im Internet verfügbar sein müssen.
# Sicherheitsgruppen und Netzwerk ACLs (BP5)
Mit Amazon Virtual Private Cloud (AmazonVPC) können Sie einen logisch isolierten Bereich bereitstellen, in AWS Cloud dem Sie AWS Ressourcen in einem von Ihnen definierten virtuellen Netzwerk starten können.
Sicherheitsgruppen und Netzwerke ACLs sind sich insofern ähnlich, als sie es Ihnen ermöglichen, den Zugriff auf AWS Ressourcen innerhalb Ihres VPC Netzwerks zu kontrollieren. Sicherheitsgruppen ermöglichen es Ihnen jedoch, eingehenden und ausgehenden Datenverkehr auf Instanzebene zu kontrollieren, während Netzwerke ähnliche Funktionen auf VPC Subnetzebene ACLs bieten. Für die Nutzung von Sicherheitsgruppen oder Netzwerken fallen keine zusätzlichen Gebühren an. ACLs
Sie können wählen, ob Sie beim Starten einer Instance Sicherheitsgruppen angeben oder die Instance zu einem späteren Zeitpunkt einer Sicherheitsgruppe zuordnen möchten. *Jeglicher Internetverkehr zu einer Sicherheitsgruppe wird implizit verweigert, es sei denn, Sie erstellen eine Zulassungsregel, die den Datenverkehr zulässt.*
Wenn Sie beispielsweise EC2 Amazon-Instances hinter einem Elastic Load Balancer haben, sollten die Instances selbst nicht öffentlich zugänglich sein müssen und sollten IPs nur privat sein. Stattdessen könnten Sie dem Elastic Load Balancer Zugriff auf die erforderlichen Ziel-Listener-Ports gewähren, indem Sie eine Sicherheitsgruppenregel verwenden, die den Zugriff auf 0.0.0.0/0 erlaubt (um Probleme mit der Verbindungsverfolgung zu vermeiden — siehe Hinweis unten) in Verbindung mit einer Network Access Control List (NACL) im Zielgruppen-Subnetz, sodass nur die Elastic Load Balancing Balancing-IP-Bereiche mit den Instances kommunizieren können. Dadurch wird sichergestellt, dass der Internetverkehr nicht direkt mit Ihren EC2 Amazon-Instances kommunizieren kann, was es für einen Angreifer schwieriger macht, etwas über Ihre Anwendung zu erfahren und sie zu beeinflussen.
Wenn Sie ein Netzwerk erstellenACLs, können Sie sowohl Regeln zum Zulassen als auch zum Ablehnen angeben. Dies ist nützlich, wenn Sie bestimmte Arten von Datenverkehr für Ihre Anwendung explizit verweigern möchten. Sie können beispielsweise IP-Adressen (als CIDR Bereiche), Protokolle und Zielports definieren, denen der Zugriff auf das gesamte Subnetz verweigert wird. Wenn Ihre Anwendung nur für den TCP Datenverkehr verwendet wird, können Sie eine Regel erstellen, um den gesamten UDP Datenverkehr zu verweigern oder umgekehrt. Diese Option ist nützlich, wenn Sie auf DDoS Angriffe reagieren, da Sie damit Ihre eigenen Regeln zur Abwehr des Angriffs erstellen können, wenn Sie die Quelle IPs oder eine andere Signatur kennen.
Wenn Sie ein Abonnement haben AWS Shield Advanced, können Sie Elastic IP-Adressen als geschützte Ressourcen registrieren. DDoSAngriffe auf Elastic IP-Adressen, die als geschützte Ressourcen registriert wurden, werden schneller erkannt, was zu einer schnelleren Abwehr führen kann. Wenn ein Angriff erkannt wird, lesen die DDoS Abwehrsysteme das NetzwerkACL, das der gewünschten Elastic IP-Adresse entspricht, und erzwingt es an der AWS Netzwerkgrenze und nicht auf Subnetzebene. Dadurch wird Ihr Risiko, dass eine Reihe von Angriffen auf die Infrastrukturebene Auswirkungen haben, erheblich reduziert. DDoS
Weitere Informationen zur Konfiguration von Sicherheitsgruppen und Netzwerken ACLs zur Optimierung der DDoS Ausfallsicherheit finden Sie unter [How to Help Prepare for DDoS Attacks by Reducing Your Attack Surface](https://aws.amazon.com/blogs/security/how-to-help-prepare-for-ddos-attacks-by-reducing-your-attack-surface/).
Weitere Informationen zur Verwendung von Shield Advanced mit Elastic IP-Adressen als geschützte Ressourcen finden Sie in den Schritten [zum Abonnieren AWS Shield Advanced](https://docs.aws.amazon.com/waf/latest/developerguide/enable-ddos-prem.html).
# Schützen Sie Ihre Herkunft (BP1,BP5)
Wenn Sie Amazon CloudFront mit einer Herkunft verwenden, die innerhalb Ihres liegtVPC, sollten Sie sicherstellen, dass nur Ihr CloudFront Vertrieb Anfragen an Ihren Ursprung weiterleiten kann. Mit Edge-to-Origin-Anforderungsheadern können Sie den Wert vorhandener Anforderungsheader hinzufügen oder deren Wert überschreiben, wenn Anfragen an Ihren Absender weitergeleitet werden CloudFront . Du kannst die *benutzerdefinierten Origin-Header* verwenden, zum Beispiel den `X-Shared-Secret` Header, um zu überprüfen, ob die Anfragen an deinen Absender gesendet wurden. CloudFront
Weitere Informationen zum Schutz Ihres Ursprungs mit benutzerdefinierten *Origin-Headern finden Sie unter Benutzerdefinierte Header* zu [ursprünglichen Anfragen [hinzufügen](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/add-origin-custom-headers.html) und Zugriff auf Application](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/add-origin-custom-headers.html) [Load Balancers einschränken](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/restrict-access-to-load-balancer.html).
Eine Anleitung zur Implementierung einer Musterlösung zur automatischen Rotation des Werts von *Origin Custom Headers* für die Ursprungszugriffsbeschränkung finden Sie unter [How to enhance Amazon CloudFront Origin Security with AWS WAF and Secrets Manager](https://aws.amazon.com/blogs/security/how-to-enhance-amazon-cloudfront-origin-security-with-aws-waf-and-aws-secrets-manager/).
Alternativ können Sie eine [AWS Lambda](https://aws.amazon.com/lambda/)Funktion verwenden, um Ihre Sicherheitsgruppenregeln automatisch so zu aktualisieren, dass nur CloudFront Datenverkehr zugelassen wird. Auf diese Weise wird die Sicherheit Ihres Ursprungs verbessert, indem sichergestellt wird, dass böswillige Benutzer den Zugriff auf Ihre Webanwendung nicht umgehen CloudFront können. AWS WAF
Weitere Informationen darüber, wie Sie Ihren Ursprung schützen können, indem Sie Ihre Sicherheitsgruppen und den `X-Shared-Secret` Header [automatisch aktualisieren, finden Sie unter So aktualisieren Sie Ihre Sicherheitsgruppen für Amazon CloudFront und mithilfe AWS WAFAWS Lambda von](https://aws.amazon.com/blogs/security/how-to-automatically-update-your-security-groups-for-amazon-cloudfront-and-aws-waf-by-using-aws-lambda/)
Die Lösung erfordert jedoch zusätzliche Konfiguration und die Kosten für die Ausführung von Lambda-Funktionen. Um dies zu vereinfachen, haben wir jetzt eine von [AWS-verwaltete Präfixliste](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/LocationsOfEdgeServers.html#managed-prefix-list) eingeführt, mit der Sie den eingehenden HTTP HTTPS /-Traffic CloudFront auf Ihre Ursprünge beschränken können, und zwar nur von den IP-Adressen, an die der Absender gerichtet CloudFront ist. AWS-verwaltete Präfixlisten werden von erstellt und verwaltet AWS und können ohne zusätzliche Kosten verwendet werden. Sie können CloudFront in Ihren (Amazon-VPC) Sicherheitsgruppenregeln, Subnetz-Routing-Tabellen, allgemeinen Sicherheitsgruppenregeln für und allen anderen AWS Ressourcen, die eine [verwaltete Präfixliste verwenden können AWS Firewall Manager, auf die Liste der verwalteten Präfixe](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-aws-managed-prefix-lists.html) verweisen.
Weitere Informationen zur Verwendung der AWS-managed prefix list für Amazon CloudFront finden Sie unter [Beschränken Sie den Zugriff auf Ihre Ursprünge mithilfe der AWS-managed prefix list für](https://aws.amazon.com/blogs/networking-and-content-delivery/limit-access-to-your-origins-using-the-aws-managed-prefix-list-for-amazon-cloudfront/) Amazon. CloudFront
**Anmerkung**
Wie bereits in anderen Abschnitten dieses Dokuments beschrieben, kann der Einsatz von Sicherheitsgruppen zum Schutz Ihrer Herkunft die [Verbindungsverfolgung von Sicherheitsgruppen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html) als potenzieller Engpass bei einer Flut von Anfragen mit sich bringen. Sofern Sie nicht in der Lage sind, bösartige Anfragen CloudFront mithilfe einer Caching-Richtlinie zu filtern, die das Zwischenspeichern ermöglicht, ist es möglicherweise besser, sich auf die zuvor erläuterten *benutzerdefinierten Origin-Header* zu verlassen, um zu überprüfen, ob die Anfragen an Ihren Ursprung gesendet wurden, anstatt Sicherheitsgruppen zu verwenden. CloudFront Die Verwendung eines benutzerdefinierten Anforderungsheaders mit einer Application Load Balancer-Listener-Regel verhindert Drosselungen aufgrund von Tracking-Limits, die sich auf den Aufbau neuer Verbindungen zu einem Load Balancer auswirken können, sodass Application Load Balancer im Falle eines Angriffs auf die Zunahme des Datenverkehrs skalieren kann. DDoS
# APIEndgeräte schützen () BP4
Wenn Sie eine API der Öffentlichkeit zugänglich machen müssen, besteht die Gefahr, dass das API Frontend Ziel eines DDoS Angriffs wird. Um das Risiko zu verringern, können Sie [Amazon API Gateway als Zugang](https://aws.amazon.com/api-gateway/) zu Anwendungen verwenden EC2 AWS Lambda, die auf Amazon oder anderswo ausgeführt werden. Durch die Verwendung von Amazon API Gateway benötigen Sie keine eigenen Server für das API Frontend und können andere Komponenten Ihrer Anwendung verschleiern. Indem Sie es schwieriger machen, die Komponenten Ihrer Anwendung zu erkennen, können Sie verhindern, dass diese AWS Ressourcen Ziel eines Angriffs werden. DDoS
Wenn Sie Amazon API Gateway verwenden, können Sie zwischen zwei Arten von API Endpunkten wählen. Die erste ist die Standardoption: Edge-optimierte API Endgeräte, auf die über eine Amazon-Distribution zugegriffen wird. CloudFront Die Verteilung wird jedoch von API Gateway erstellt und verwaltet, sodass Sie keine Kontrolle darüber haben. Die zweite Option besteht darin, einen regionalen API Endpunkt zu verwenden, auf den von demselben AWS-Region Endpunkt aus zugegriffen REST API wird, auf dem Ihr bereitgestellt wurde. AWS empfiehlt, den zweiten Endpunkttyp zu verwenden und ihn mit Ihrer eigenen CloudFront Amazon-Distribution zu verknüpfen. Auf diese Weise haben Sie die Kontrolle über den CloudFront Amazon-Vertrieb und können ihn AWS WAF für den Schutz auf Anwendungsebene verwenden. Dieser Modus bietet Ihnen Zugriff auf skalierte DDoS Minderungskapazitäten im gesamten AWS globalen Edge-Netzwerk.
Wenn Sie Amazon CloudFront und AWS WAF Amazon API Gateway verwenden, konfigurieren Sie die folgenden Optionen:
+ Konfigurieren Sie das Cache-Verhalten für Ihre Distributionen so, dass alle Header an den regionalen API Gateway-Endpunkt weitergeleitet werden. Auf diese Weise CloudFront wird der Inhalt als dynamisch behandelt und das Zwischenspeichern des Inhalts übersprungen.
+ Schützen Sie Ihr API Gateway vor direktem Zugriff, indem Sie die Distribution so konfigurieren, dass sie den benutzerdefinierten Origin-Header enthält x-api-key, indem Sie den [APISchlüsselwert](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-setup-api-key-with-console.html) in API Gateway festlegen.
+ Schützen Sie das Backend vor übermäßigem Datenverkehr, indem Sie Standard- oder Burst-Rate-Limits für jede Methode in Ihrem REST APIs konfigurieren.
Weitere Informationen zur Erstellung APIs mit Amazon API Gateway finden Sie unter [Erste Schritte](https://aws.amazon.com/api-gateway/getting-started/) mit [Amazon API Gateway](https://aws.amazon.com/api-gateway/getting-started/).