# Schutz von Netzwerken
Benutzer, sowohl Ihre Mitarbeiter als auch Ihre Kunden, können sich überall befinden. Sie müssen sich von traditionellen Modellen verabschieden, bei denen Sie allem und jedem vertrauen, das Zugang zu Ihrem Netzwerk hat. Wenn Sie dem Prinzip folgen, Sicherheit auf allen Ebenen anzuwenden, setzen Sie einen [Zero-Trust](https://aws.amazon.com/blogs/security/zero-trust-architectures-an-aws-perspective/)-Ansatz um. Zero-Trust-Sicherheit ist ein Modell, bei dem Anwendungskomponenten oder Microservices als voneinander getrennt betrachtet werden und keine Komponente oder kein Microservice anderen vertraut.
Die sorgfältige Verwaltung Ihres Netzwerkdesigns bildet die Grundlage, um Ressourcen innerhalb Ihrer Workload zu isolieren und einzugrenzen. Da viele Ressourcen in Ihrer Workload in einer VPC ausgeführt werden und die Sicherheitseigenschaften übernehmen, ist es wichtig, dass das Design automatisierte Inspektions- und Schutzmechanismen unterstützt wird. Für Workloads, welche außerhalb einer VPC mit Edge-Services oder Serverless ausgeführt werden, bestehen vereinfachte bewährte Methoden. Spezifische Anleitungen zur Serverless-Sicherheit finden Sie unter [AWS Well-Architected Serverless Application Lens](https://docs.aws.amazon.com/wellarchitected/latest/serverless-applications-lens/welcome.html).
**Topics**
+ [SEC05-BP01 Erstellen von Netzwerkebenen](sec_network_protection_create_layers.md)
+ [SEC05-BP02 Kontrollieren des Datenverkehrsflusses innerhalb Ihrer Netzwerkebenen](sec_network_protection_layered.md)
+ [SEC05-BP03 Implementieren Sie einen inspektionsbasierten Schutz](sec_network_protection_inspection.md)
+ [SEC05-BP04 Automatisieren Sie den Netzwerkschutz](sec_network_auto_protect.md)
# SEC05-BP01 Erstellen von Netzwerkebenen
Segmentieren Sie Ihre Netzwerktopologie in verschiedene Ebenen, die auf logischen Gruppierungen Ihrer Workload-Komponenten entsprechend ihrer Datensensibilität und Zugriffsanforderungen basieren. Unterscheiden Sie zwischen Komponenten, auf die vom Internet aus zugegriffen werden muss, wie z. B. öffentliche Web-Endpunkte, und solchen, die nur intern erreichbar sein müssen, wie z. B. Datenbanken.
**Gewünschtes Ergebnis:** Die Ebenen Ihres Netzwerks sind Teil eines ganzheitlichen, tiefgreifenden Sicherheitsansatzes, der die Identitätsauthentifizierungs- und Autorisierungsstrategie Ihrer Workloads ergänzt. Je nach Sensibilität der Daten und den Zugriffsanforderungen werden Ebenen mit entsprechenden Verkehrsfluss- und Kontrollmechanismen eingerichtet.
**Typische Anti-Muster:**
+ Sie erstellen alle Ressourcen in einem einzigen VPC oder Subnetz.
+ Sie erstellen Ihre Netzwerkebenen ohne Rücksicht auf die Anforderungen an die Datensensibilität, das Verhalten der Komponenten oder die Funktionalität.
+ Sie verwenden VPCs und Subnetze als Standards für alle Aspekte der Netzwerkebenen und berücksichtigen nicht, wie verwaltete AWS-Services Ihre Topologie beeinflussen.
**Vorteile der Nutzung dieser bewährten Methode:** Die Einrichtung von Netzwerkebenen ist der erste Schritt, um unnötige Pfade durch das Netzwerk einzuschränken, insbesondere solche, die zu kritischen Systemen und Daten führen. Dadurch wird es für Unbefugte schwieriger, sich Zugriff auf Ihr Netzwerk zu verschaffen und zu weiteren Ressourcen darin zu navigieren. Diskrete Netzwerkebenen reduzieren den Umfang der Analyse für Inspektionssysteme, z. B. für die Erkennung von Eindringlingen oder die Verhinderung von Malware, vorteilhaft. Dadurch wird das Potenzial für Fehlalarme und unnötigen Verarbeitungsaufwand reduziert.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
Beim Entwurf einer Workload-Architektur ist es üblich, die Komponenten je nach ihrer Verantwortlichkeit in verschiedene Ebenen aufzuteilen. Eine Webanwendung kann zum Beispiel eine Präsentationsebene, eine Anwendungsebene und eine Datenebene haben. Bei der Gestaltung Ihrer Netzwerktopologie können Sie einen ähnlichen Ansatz wählen. Die zugrunde liegenden Netzwerkkontrollen können dazu beitragen, die Anforderungen Ihres Workloads an den Datenzugriff durchzusetzen. In einer dreistufigen Webanwendungsarchitektur können Sie zum Beispiel Ihre statischen Präsentationsebenendateien in [Amazon S3](https://aws.amazon.com/s3/) speichern und sie von einem Content Delivery Network (CDN) wie [Amazon CloudFront](https://aws.amazon.com/cloudfront/) aus bereitstellen. Die Anwendungsebene kann öffentliche Endpunkte haben, die ein [Application Load Balancer (ALB)](https://aws.amazon.com/elasticloadbalancing/application-load-balancer/) in einem [Amazon VPC](https://aws.amazon.com/vpc/)-öffentlichen Subnetz (ähnlich einer demilitarisierten Zone oder DMZ) bedient, während die Backend-Services in privaten Subnetzen bereitgestellt werden. Die Datenebene, die Ressourcen wie Datenbanken und gemeinsam genutzte Dateisysteme hostet, kann sich in anderen privaten Subnetzen befinden als die Ressourcen Ihrer Anwendungsebene. An jeder dieser Ebenengrenzen (CDN, öffentliches Subnetz, privates Subnetz) können Sie Kontrollen bereitstellen, die es nur autorisiertem Datenverkehr erlauben, diese Grenzen zu überqueren.
Ähnlich wie bei der Modellierung von Netzwerkebenen auf der Grundlage des funktionalen Zwecks der Komponenten Ihres Workloads sollten Sie auch die Sensibilität der verarbeiteten Daten berücksichtigen. Wenn Sie das Beispiel der Webanwendung verwenden, kann es sein, dass alle Ihre Workload-Services innerhalb der Anwendungsebene angesiedelt sind, während verschiedene Services Daten mit unterschiedlichen Sensibilitätsstufen verarbeiten. In diesem Fall kann die Aufteilung der Anwendungsebene durch mehrere private Subnetze, verschiedene VPCs in demselben AWS-Konto oder sogar verschiedene VPCs in verschiedenen AWS-Konten für jede Stufe der Datensensibilität je nach Ihren Kontrollanforderungen angemessen sein.
Eine weitere Überlegung für Netzwerkebenen ist die Verhaltenskonsistenz der Komponenten Ihres Workloads. Um das Beispiel fortzusetzen: In der Anwendungsebene haben Sie möglicherweise Services, die Eingaben von Endbenutzern oder externen Systemintegrationen akzeptieren, die von Natur aus risikoreicher sind als die Eingaben für andere Services. Beispiele sind das Hochladen von Dateien, das Ausführen von Skripten, das Scannen von E-Mails und so weiter. Die Unterbringung dieser Services in einer eigenen Netzwerkebene hilft dabei, eine stärkere Isolationsgrenze um sie herum zu schaffen, und kann verhindern, dass ihr einzigartiges Verhalten falsche positive Alarme in Inspektionssystemen erzeugt.
Berücksichtigen Sie bei Ihrer Planung, wie die Nutzung von AWS verwalteten Services Ihre Netzwerktopologie beeinflusst. Erfahren Sie, wie Services wie [Amazon VPC Lattice](https://aws.amazon.com/vpc/lattice/) die Interoperabilität Ihrer Workload-Komponenten über Netzwerkebenen hinweg erleichtern können. Wenn Sie [AWS Lambda](https://aws.amazon.com/lambda/) verwenden, sollten Sie die Bereitstellung in Ihren VPC-Subnetzen vornehmen, es sei denn, es gibt besondere Gründe, die dagegen sprechen. Bestimmen Sie, wo VPC-Endpunkte und [AWS PrivateLink](https://aws.amazon.com/privatelink/) die Einhaltung von Sicherheitsrichtlinien, die den Zugriff auf Internet-Gateways beschränken, vereinfachen können.
### Implementierungsschritte
1. Überprüfen Sie Ihre Workload-Architektur. Gruppieren Sie Komponenten und Services logisch nach den Funktionen, die sie erfüllen, nach der Sensibilität der verarbeiteten Daten und nach ihrem Verhalten.
1. Für Komponenten, die auf Anfragen aus dem Internet reagieren, sollten Sie Load Balancer oder andere Proxys verwenden, um öffentliche Endpunkte bereitzustellen. Erkunden Sie die Verlagerung der Sicherheitskontrollen durch den Einsatz von verwalteten Services wie CloudFront, [Amazon API Gateway](https://aws.amazon.com/api-gateway/), Elastic Load Balancing und [AWS Amplify](https://aws.amazon.com/amplify/) zum Hosten öffentlicher Endpunkte.
1. Für Komponenten, die in Datenverarbeitungsumgebungen ausgeführt werden, wie Amazon EC2-Instances, [AWS Fargate](https://aws.amazon.com/fargate/)-Container oder Lambda-Funktionen, stellen Sie diese in privaten Subnetzen bereit, und zwar basierend auf Ihren Gruppen aus dem ersten Schritt.
1. Für vollständig verwaltete AWS-Services, wie [Amazon DynamoDB](https://aws.amazon.com/dynamodb/), [Amazon Kinesis](https://aws.amazon.com/kinesis/) oder [Amazon SQS](https://aws.amazon.com/sqs/), sollten Sie VPC-Endpunkte als Standard für den Zugriff über private IP-Adressen verwenden.
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [REL02 Planen der Netzwerktopologie](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-your-network-topology.html)
+ [PERF04-BP01 Verstehen der Auswirkungen des Netzwerks auf die Leistung](https://docs.aws.amazon.com/wellarchitected/latest/framework/perf_networking_understand_how_networking_impacts_performance.html)
**Zugehörige Videos:**
+ [AWS re:Invent 2.023 - AWS networking foundations](https://www.youtube.com/watch?v=8nNurTFy-h4)
**Zugehörige Beispiele:**
+ [VPC-Beispiele](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-examples-intro.html)
+ [Greifen Sie privat auf Container-Anwendungen auf Amazon ECS zu, indem Sie AWS Fargate, AWS PrivateLink und einen Network Load Balancer verwenden](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.html)
+ [Serve static content in an Amazon S3 bucket through a VPC by using Amazon CloudFront](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/serve-static-content-in-an-amazon-s3-bucket-through-a-vpc-by-using-amazon-cloudfront.html)
# SEC05-BP02 Kontrollieren des Datenverkehrsflusses innerhalb Ihrer Netzwerkebenen
Verwenden Sie innerhalb der einzelnen Ebenen Ihres Netzwerks eine weitere Segmentierung, um den Datenverkehr auf die für die einzelnen Workloads erforderlichen Flüsse zu beschränken. Konzentrieren Sie sich zunächst auf die Kontrolle des Datenverkehrs zwischen dem Internet oder anderen externen Systemen eines Workloads und Ihrer Umgebung (*Nord-Süd-Verkehr*). Betrachten Sie anschließend die Ströme zwischen verschiedenen Komponenten und Systemen (*Ost-West-Verkehr*).
**Gewünschtes Ergebnis:** Sie lassen nur die Netzwerkflüsse zu, die für die Kommunikation der Komponenten Ihrer Workloads untereinander, mit ihren Clients und mit allen anderen Services, von denen sie abhängig sind, erforderlich sind. Ihr Design berücksichtigt Überlegungen wie öffentlichen im Vergleich zu privatem Ingress und Egress, Datenklassifizierung, regionale Vorschriften und Protokollanforderungen. Wo immer es möglich ist, bevorzugen Sie Punkt-zu-Punkt-Flüsse gegenüber Netzwerk-Peering im Rahmen des *Prinzips der geringsten Berechtigung*.
**Typische Anti-Muster:**
+ Sie verfolgen bei der Netzwerksicherheit einen Perimeter-basierten Ansatz und kontrollieren den Datenverkehr nur an den Grenzen Ihrer Netzwerkebenen.
+ Sie gehen davon aus, dass der gesamte Verkehr innerhalb einer Netzwerkebene authentifiziert und autorisiert ist.
+ Sie kontrollieren entweder den eingehenden oder den ausgehenden Datenverkehr, aber nicht beide.
+ Sie verlassen sich bei der Authentifizierung und Autorisierung des Datenverkehrs ausschließlich auf Ihre Workload-Komponenten und Netzwerkkontrollen.
**Vorteile der Nutzung dieser bewährten Methode:** Diese Vorgehensweise trägt dazu bei, das Risiko unbefugter Bewegungen innerhalb Ihres Netzwerks zu verringern, und fügt Ihren Workloads eine zusätzliche Autorisierungsebene hinzu. Durch die Kontrolle des Datenverkehrs können Sie den Umfang der Auswirkungen eines Sicherheitsvorfalls begrenzen und die Erkennung und Reaktion beschleunigen.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird:** Hoch
## Implementierungsleitfaden
Netzwerkebenen helfen zwar bei der Abgrenzung von Komponenten Ihres Workloads, die eine ähnliche Funktion, eine ähnliche Datensensibilität und ein ähnliches Verhalten aufweisen. Sie können jedoch eine wesentlich feinere Ebene der Datenverkehrskontrolle schaffen, indem Sie Techniken zur weiteren Segmentierung von Komponenten innerhalb dieser Ebenen einsetzen, die dem Prinzip der geringsten Berechtigung folgen. Innerhalb von AWS werden Netzwerkebenen in erster Linie über Subnetze entsprechend den IP-Adressbereichen innerhalb eines Amazon VPC definiert. Ebenen können auch über verschiedene VPCs definiert werden, z. B. für die Gruppierung von Microservice-Umgebungen nach Business Domain. Wenn Sie mehrere VPCs verwenden, vermitteln Sie das Routing mit einem [AWS Transit Gateway](https://aws.amazon.com/transit-gateway/). Dies ermöglicht zwar die Kontrolle des Datenverkehrs auf Layer-4-Ebene (IP-Adressen- und Portbereiche) mithilfe von Sicherheitsgruppen und Routing-Tabellen, aber Sie können mit zusätzlichen Services, wie [AWS PrivateLink](https://aws.amazon.com/privatelink/), [Amazon Route 53-Resolver-DNS-Firewall](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall.html), [AWS Network Firewall](https://aws.amazon.com/network-firewall/) und [AWS WAF](https://aws.amazon.com/waf/) weitere Kontrolle erlangen.
Verstehen und inventarisieren Sie den Datenfluss und die Kommunikationsanforderungen Ihrer Workloads in Bezug auf verbindungsauslösende Parteien, Ports, Protokolle und Netzwerkebenen. Prüfen Sie die verfügbaren Protokolle für den Verbindungsaufbau und die Datenübertragung, um diejenigen auszuwählen, die Ihre Schutzanforderungen erfüllen (z. B. HTTPS statt HTTP). Erfassen Sie diese Anforderungen sowohl an den Grenzen Ihrer Netzwerke als auch innerhalb jeder Ebene. Sobald diese Anforderungen identifiziert sind, prüfen Sie die Möglichkeiten, um nur den erforderlichen Datenverkehr an jedem Verbindungspunkt zuzulassen. Ein guter Ausgangspunkt ist die Verwendung von *Sicherheitsgruppen* innerhalb Ihrer VPC, da sie an Ressourcen angehängt werden können, die eine Elastic-Network-Schnittstelle (ENI) verwenden, wie Amazon EC2-Instances, Amazon ECS-Aufgaben, Amazon EKS-Pods oder Amazon RDS-Datenbanken. Im Gegensatz zu einer Layer-4-Firewall kann eine Sicherheitsgruppe eine Regel haben, die den Datenverkehr einer anderen Sicherheitsgruppe anhand ihrer Kennung zulässt, wodurch Aktualisierungen minimiert werden, wenn sich die Ressourcen innerhalb der Gruppe im Laufe der Zeit ändern. Sie können den Datenverkehr auch mithilfe von Sicherheitsgruppen nach eingehenden und ausgehenden Regeln filtern.
Wenn sich der Datenverkehr zwischen VPCs bewegt, ist es üblich, VPC-Peering für einfaches Routing oder AWS Transit Gateway für komplexes Routing zu verwenden. Mit diesen Ansätzen erleichtern Sie den Datenverkehrsfluss zwischen dem Bereich der IP-Adressen des Quell- und des Zielnetzwerks. Wenn Ihr Workload jedoch nur Datenverkehrsflüsse zwischen bestimmten Komponenten in verschiedenen VPCs erfordert, sollten Sie eine Punkt-zu-Punkt-Verbindung mit [AWS PrivateLink](https://aws.amazon.com/privatelink/) verwenden. Bestimmen Sie dazu, welcher Service als Produzent und welcher als Verbraucher fungieren soll. Stellen Sie einen kompatiblen Load Balancer für den Produzenten bereit, schalten Sie PrivateLink entsprechend ein und akzeptieren Sie dann eine Verbindungsanfrage des Verbrauchers. Dem Produzenten-Service wird dann eine private IP-Adresse aus der VPC des Verbrauchers zugewiesen, die der Verbraucher für nachfolgende Anfragen verwenden kann. Dieser Ansatz reduziert die Notwendigkeit, die Netzwerke zu peeren. Beziehen Sie die Kosten für die Datenverarbeitung und den Load Balancer in die Bewertung von PrivateLink mit ein.
Sicherheitsgruppen und PrivateLink tragen zwar dazu bei, den Fluss zwischen den Komponenten Ihrer Workloads zu kontrollieren. Eine weitere wichtige Überlegung ist jedoch, wie Sie kontrollieren können, auf welche DNS-Domains Ihre Ressourcen zugreifen dürfen (falls überhaupt). Abhängig von der DHCP-Konfiguration Ihrer VPCs können Sie zwei verschiedene AWS-Services für diesen Zweck in Betracht ziehen. Die meisten Kunden verwenden den standardmäßigen Route 53-Resolver DNS-Service (auch Amazon-DNS-Server oder AmazonProvidedDNS genannt), der für VPCs unter der \$12-Adresse ihres CIDR-Bereichs verfügbar ist. Mit diesem Ansatz können Sie DNS-Firewall-Regeln erstellen und diese mit Ihrer VPC verknüpfen, die festlegen, welche Aktionen für die von Ihnen bereitgestellten Domain-Listen durchgeführt werden sollen.
Wenn Sie nicht den Route 53-Resolver verwenden, oder wenn Sie den Resolver mit tieferen Prüf- und Flusskontrollfunktionen als der Domain-Filterung ergänzen wollen, sollten Sie die Bereitstellung eines AWS Network Firewall erwägen. Dieser Service prüft einzelne Pakete anhand von zustandslosen oder zustandsbehafteten Regeln, um zu entscheiden, ob der Datenverkehr verweigert oder zugelassen werden soll. Einen ähnlichen Ansatz können Sie für die Filterung des eingehenden Internetdatenverkehrs zu Ihren öffentlichen Endpunkten mit AWS WAF verfolgen. Weitere Hinweise zu diesen Services finden Sie unter [SEC05-BP03 Implementieren eines prüfungsbasierten Schutzes](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_network_protection_inspection.html).
### Implementierungsschritte
1. Identifizieren Sie die erforderlichen Datenflüsse zwischen den Komponenten Ihrer Workloads.
1. Wenden Sie mehrere Kontrollen mit einem Ansatz der Tiefenverteidigung sowohl für den eingehenden als auch für den ausgehenden Datenverkehr an, einschließlich der Verwendung von Sicherheitsgruppen und Routing-Tabellen.
1. Verwenden Sie Firewalls, um eine feinkörnige Kontrolle über den Netzwerkverkehr in, aus und zwischen Ihren VPCs zu definieren, wie z. B. die Route 53 Resolver DNS Firewall, AWS Network Firewall und AWS WAF. Erwägen Sie den Einsatz von [AWS Firewall Manager](https://aws.amazon.com/firewall-manager/) für die zentrale Konfiguration und Verwaltung Ihrer Firewall-Regeln in Ihrer Organisation.
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [REL03-BP01 Segmentierung Ihres Workloads](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_service_architecture_monolith_soa_microservice.html)
+ [SEC09-BP02 Erzwingen einer Verschlüsselung bei der Übertragung](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_data_transit_encrypt.html)
**Zugehörige Dokumente:**
+ [Security best practices for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-best-practices.html)
+ [AWS Network Optimization Tips](https://aws.amazon.com/blogs/networking-and-content-delivery/aws-network-optimization-tips/)
+ [Guidance for Network Security on AWS](https://aws.amazon.com/solutions/guidance/network-security-on-aws/)
+ [Secure your VPC's outbound network traffic in the AWS Cloud](https://docs.aws.amazon.com/prescriptive-guidance/latest/secure-outbound-network-traffic/welcome.html)
**Zugehörige Tools:**
+ [AWS Firewall Manager](https://aws.amazon.com/firewall-manager/)
**Zugehörige Videos:**
+ [AWS Transit Gateway reference architectures for many VPCs](https://youtu.be/9Nikqn_02Oc)
+ [Application Acceleration and Protection with Amazon CloudFront, AWS WAF, and AWS Shield](https://youtu.be/0xlwLEccRe0)
+ [AWS re:Inforce 2023: Firewalls and where to put them](https://www.youtube.com/watch?v=lTJxWAiQrHM)
# SEC05-BP03 Implementieren Sie einen inspektionsbasierten Schutz
Richten Sie Kontrollpunkte für den Datenverkehr zwischen Ihren Netzwerkebenen ein, um sicherzustellen, dass die Daten während der Übertragung den erwarteten Kategorien und Mustern entsprechen. Analysieren Sie Datenverkehrsströme, Metadaten und Muster, um Ereignisse effektiver zu identifizieren, zu erkennen und darauf zu reagieren.
**Gewünschtes Ergebnis:** Der Datenverkehr, der zwischen Ihren Netzwerkebenen verläuft, wird geprüft und autorisiert. Entscheidungen über das Zulassen oder Verweigern von Zugriffen beruhen auf expliziten Regeln, Informationen über Bedrohungen und Abweichungen vom Grundverhalten. Der Schutz wird strenger, je näher der Datenverkehr an sensible Daten heranrückt.
**Typische Anti-Muster:**
+ Ausschließlich auf Firewall-Regeln vertrauen, die auf Ports und Protokollen basieren, und Vorteile intelligenter Systeme außer Acht lassen
+ Firewall-Regeln auf der Grundlage bestimmter aktueller Bedrohungsmuster erstellen, die sich ändern können
+ Überprüfung des Datenverkehrs auf den Übergang von privaten zu öffentlichen Subnetzen oder von öffentlichen Subnetzen zum Internet beschränken
+ Keine Basisansicht Ihres Netzwerkdatenverkehrs haben, die Sie auf Verhaltensanomalien hin überprüfen können
**Vorteile der Nutzung dieser bewährten Methode:** Prüfungssysteme ermöglichen es Ihnen, intelligente Regeln zu erstellen, z. B. den Datenverkehr nur dann zuzulassen oder zu verweigern, wenn bestimmte Bedingungen in den Datenverkehrsdaten vorliegen. Profitieren Sie von verwalteten Regelsätzen von AWS und Partnern, die auf den neuesten Bedrohungsinformationen basieren, da sich die Bedrohungslandschaft im Laufe der Zeit ändert. Dadurch verringert sich der Aufwand für die Pflege von Regeln und die Suche nach Indikatoren für eine Gefährdung, wodurch das Potenzial für Fehlalarme reduziert wird.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird: **Mittel
## Implementierungsleitfaden
[Verschaffen Sie sich mithilfe anderer [Firewalls](https://aws.amazon.com/marketplace/search/results?searchTerms=firewalls) und [Intrusion Prevention-Systeme](https://aws.amazon.com/marketplace/search/results?searchTerms=Intrusion+Prevention+Systems) (IPS) AWS Network Firewall, die Sie hinter einem Gateway Load Balancer () einsetzen können, eine genaue Kontrolle über Ihren AWS Marketplace statusbehafteten und statusfreien Netzwerkverkehr. GWLB](https://aws.amazon.com/elasticloadbalancing/gateway-load-balancer/)AWS Network Firewall unterstützt [Suricata-kompatible](https://docs.aws.amazon.com/network-firewall/latest/developerguide/stateful-rule-groups-ips.html) Open-Source-Spezifikationen, um Ihre Workloads zu schützen. IPS
AWS Network Firewall Sowohl die Lösungen als auch die von Anbietern, die A verwenden, GWLB unterstützen unterschiedliche Bereitstellungsmodelle für Inline-Inspektionen. Sie können beispielsweise Inspektionen auf VPC Einzelbasis durchführen, sie in Form einer zentralen Inspektion durchführen oder sie in einem Hybridmodell einsetzenVPC, bei dem der Ost-West-Verkehr durch eine Inspektion fließt VPC und der Interneteingang einzeln geprüft wird. VPC Eine weitere Überlegung ist, ob die Lösung das Entpacken von Transport Layer Security (TLS) unterstützt, wodurch eine Deep Packet Inspection für Datenflüsse, die in beide Richtungen initiiert werden, ermöglicht wird. Weitere Informationen und ausführliche Details zu diesen Konfigurationen finden Sie im Leitfaden für [AWS Network Firewall Best Practices](https://aws.github.io/aws-security-services-best-practices/guides/network-firewall/).
[Wenn Sie Lösungen verwenden, die out-of-band Inspektionen durchführen, z. B. die PCAP-Analyse von Paketdaten von Netzwerkschnittstellen, die im Promiscuous-Modus arbeiten, können Sie die Verkehrsspiegelung konfigurieren. VPC](https://docs.aws.amazon.com/vpc/latest/mirroring/what-is-traffic-mirroring.html) Gespiegelter Datenverkehr wird auf die verfügbare Bandbreite Ihrer Schnittstellen angerechnet und unterliegt denselben Datenübertragungsgebühren wie nicht gespiegelter Datenverkehr. Sie können sehen, ob virtuelle Versionen dieser Appliances auf dem verfügbar sind [AWS Marketplace](https://aws.amazon.com/marketplace/solutions/infrastructure-software/cloud-networking), was möglicherweise die Inline-Bereitstellung hinter einem unterstützt. GWLB
Schützen Sie Ihre Anwendung bei Komponenten, die über HTTP basierte Protokolle abgewickelt werden, mit einer Webanwendungs-Firewall (WAF) vor häufigen Bedrohungen. [AWS WAF](https://aws.amazon.com/waf)ist eine Firewall für Webanwendungen, mit der Sie Anfragen, die Ihren konfigurierbaren Regeln entsprechen, überwachen und blockieren HTTP können, bevor sie an Amazon API Gateway CloudFront, Amazon AWS AppSync oder einen Application Load Balancer gesendet werden. Ziehen Sie Deep Packet Inspection in Betracht, wenn Sie den Einsatz Ihrer Webanwendungs-Firewall evaluieren, da Sie bei einigen Anwendungen den Vorgang TLS vor der Datenverkehrsinspektion beenden müssen. Zu Beginn können Sie AWS WAF es [Von AWS verwaltete Regeln](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started.html#getting-started-wizard-add-rule-group)in Kombination mit Ihren eigenen Integrationen verwenden oder bestehende [Partnerintegrationen](https://aws.amazon.com/waf/partners/) verwenden.
Mit können Sie AWS WAF, AWS Shield Advanced AWS Network Firewall, und VPC Amazon-Sicherheitsgruppen in Ihrer gesamten AWS Organisation zentral verwalten [AWS Firewall Manager](https://aws.amazon.com/firewall-manager/).
## Implementierungsschritte
1. Stellen Sie fest, ob Sie die Inspektionsregeln breit fassen könnenVPC, z. B. durch eine Inspektion, oder ob Sie einen detaillierteren VPC Ansatz benötigen.
1. Für Inline-Prüfungslösungen:
1. Falls Sie diese verwenden AWS Network Firewall, erstellen Sie Regeln, Firewall-Richtlinien und die Firewall selbst. Sobald diese konfiguriert sind, können Sie den [Datenverkehr an den Endpunkt der Firewall leiten](https://aws.amazon.com/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall/), um die Prüfung zu aktivieren.
1. Wenn Sie eine Appliance eines Drittanbieters mit einem Gateway Load Balancer (GWLB) verwenden, stellen Sie Ihre Appliance in einer oder mehreren Availability Zones bereit und konfigurieren Sie sie. Erstellen Sie dann Ihren GWLB Endpunktdienst und konfigurieren Sie das Routing für Ihren Datenverkehr.
1. Für out-of-band Inspektionslösungen:
1. Aktivieren Sie VPC Traffic Mirroring auf Schnittstellen, an denen eingehender und ausgehender Datenverkehr gespiegelt werden soll. Sie können EventBridge Amazon-Regeln verwenden, um eine AWS Lambda Funktion aufzurufen, mit der die Verkehrsspiegelung auf Schnittstellen aktiviert wird, wenn neue Ressourcen erstellt werden. Richten Sie die Sitzungen zur Datenverkehrsspiegelung auf den Network Load Balancer vor Ihrer Appliance, der den Datenverkehr verarbeitet.
1. Für Lösungen für eingehenden Internetdatenverkehr:
1. Um zu konfigurieren AWS WAF, konfigurieren Sie zunächst eine Web-Zugriffskontrollliste (WebACL). Das Web ACL ist eine Sammlung von Regeln mit einer seriell verarbeiteten Standardaktion (ALLOWoderDENY), die definiert, wie Sie mit dem Datenverkehr WAF umgehen. Sie können Ihre eigenen Regeln und Gruppen erstellen oder AWS verwaltete Regelgruppen in Ihrem Web ACL verwenden.
1. Sobald Ihr Web konfiguriert ACL ist, verknüpfen Sie das Web ACL mit einer AWS Ressource (wie einem Application Load Balancer, einem API Gateway oder einer CloudFront Distribution) RESTAPI, um mit dem Schutz des Webverkehrs zu beginnen.
## Ressourcen
**Zugehörige Dokumente:**
+ [What is Traffic Mirroring?](https://docs.aws.amazon.com/vpc/latest/mirroring/what-is-traffic-mirroring.html)
+ [Implementing inline traffic inspection using third-party security appliances](https://docs.aws.amazon.com/prescriptive-guidance/latest/inline-traffic-inspection-third-party-appliances/welcome.html)
+ [AWS Network Firewall Beispielarchitekturen mit Routing](https://docs.aws.amazon.com/network-firewall/latest/developerguide/architectures.html)
+ [Zentralisierte Inspektionsarchitektur mit AWS Gateway Load Balancer und AWS Transit Gateway](https://aws.amazon.com/blogs/networking-and-content-delivery/centralized-inspection-architecture-with-aws-gateway-load-balancer-and-aws-transit-gateway/)
**Zugehörige Beispiele:**
+ [Best practices for deploying Gateway Load Balancer](https://aws.amazon.com/blogs/networking-and-content-delivery/best-practices-for-deploying-gateway-load-balancer/)
+ [TLSInspektionskonfiguration für verschlüsselten Ausgangsverkehr und AWS Network Firewall](https://aws.amazon.com/blogs/security/tls-inspection-configuration-for-encrypted-egress-traffic-and-aws-network-firewall/)
**Zugehörige Tools:**
+ [AWS Marketplace IDS/IPS](https://aws.amazon.com/marketplace/search/results?prevFilters=%257B%2522id%2522%3A%25220ed48363-5064-4d47-b41b-a53f7c937314%2522%257D&searchTerms=ids%2Fips)
# SEC05-BP04 Automatisieren Sie den Netzwerkschutz
Automatisieren Sie die Implementierung Ihrer Netzwerkschutzmaßnahmen mithilfe von DevOps Methoden wie *Infrastructure as Code* (IaC) und CI/CD-Pipelines. Diese Praktiken können Ihnen helfen, Änderungen an Ihrem Netzwerkschutz über ein Versionskontrollsystem zu verfolgen, den Zeitaufwand für die Bereitstellung von Änderungen zu reduzieren und zu erkennen, wenn Ihr Netzwerkschutz von der gewünschten Konfiguration abweicht.
**Gewünschtes Ergebnis:** Sie definieren Netzwerkschutzmaßnahmen mit Vorlagen und übertragen diese in ein Versionskontrollsystem. Automatisierte Pipelines werden initiiert, wenn neue Änderungen vorgenommen werden, die ihre Prüfung und Bereitstellung orchestrieren. Richtlinienprüfungen und andere statische Tests dienen der Validierung von Änderungen vor der Bereitstellung. Sie stellen die Änderungen in einer Staging-Umgebung bereit, um zu überprüfen, ob die Kontrollen wie erwartet funktionieren. Die Bereitstellung in Ihrer Produktionsumgebung erfolgt ebenfalls automatisch, sobald die Kontrollen genehmigt sind.
**Typische Anti-Muster:**
+ Darauf vertrauen, dass die einzelnen Workload-Teams ihren kompletten Netzwerkstack, Schutzmaßnahmen und Automatisierungen selbst definieren Keine zentrale Veröffentlichung von Standardaspekten des Netzwerkstapels und der Schutzmechanismen für Workload-Teams zur Nutzung
+ Auf ein zentrales Netzwerkteam vertrauen, das alle Aspekte des Netzwerks, der Schutzmaßnahmen und der Automatisierungen definiert Verzicht auf die Delegation von Workload-spezifischen Aspekten des Netzwerkstacks und der Schutzmaßnahmen an das Team des Workloads
+ Beibehalten eines ausgewogenen Verhältnisses zwischen Zentralisierung und Delegation zwischen einem Netzwerkteam und Workload-Teams, aber keine Anwendung konsistenter Test- und Bereitstellungsstandards über Ihre IaC-Vorlagen und CI/CD-Pipelines hinweg Unterlassen der Erfassung erforderlicher Konfigurationen in Tools, die Ihre Vorlagen auf Einhaltung überprüfen
**Vorteile der Nutzung dieser bewährten Methode:** Durch die Verwendung von Vorlagen zur Definition Ihres Netzwerkschutzes können Sie Änderungen im Laufe der Zeit mit einem Versionskontrollsystem verfolgen und vergleichen. Der Einsatz von Automatisierung zum Testen und Bereitstellen von Änderungen schafft Standardisierung und Vorhersehbarkeit, erhöht die Chancen auf eine erfolgreiche Bereitstellung und reduziert die sich wiederholenden manuellen Konfigurationen.
**Risikostufe, wenn diese bewährte Methode nicht eingeführt wird: **Mittel
## Implementierungsleitfaden
Eine Reihe von Netzwerkschutzmaßnahmen, die in [SEC05-BP02 Steuern Sie den Datenfluss innerhalb Ihrer Netzwerkschichten und SEC 05-BP03](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_network_protection_layered.html) [Implementieren Sie inspektionsbasierten Schutz](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_network_protection_inspection.html) beschrieben sind, verfügen über verwaltete Regelsysteme, die automatisch auf der Grundlage der neuesten Bedrohungsinformationen aktualisiert werden können. [Beispiele für den Schutz Ihrer Web-Endgeräte sind [AWS WAF verwaltete](https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups.html) Regeln und automatische Abwehr auf Anwendungsebene.AWS Shield Advanced DDoS](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-automatic-app-layer-response.html) Verwenden Sie [von AWS Network Firewall verwaltete Regelgruppen](https://docs.aws.amazon.com/network-firewall/latest/developerguide/nwfw-managed-rule-groups.html), um auch bei Domain-Listen mit geringer Reputation und Bedrohungssignaturen auf dem Laufenden zu bleiben.
Neben verwalteten Regeln empfehlen wir Ihnen, DevOps Methoden zur Automatisierung der Bereitstellung Ihrer Netzwerkressourcen, Schutzmaßnahmen und der von Ihnen festgelegten Regeln zu verwenden. Sie können diese Definitionen in [AWS CloudFormation](https://aws.amazon.com/cloudformation/) oder einem anderen *Infrastructure as Code* (IaC)-Tool Ihrer Wahl erfassen, sie an ein Versionskontrollsystem übergeben und sie über CI/CD-Pipelines bereitstellen. Nutzen Sie diesen Ansatz, um die traditionellen Vorteile der DevOps Verwaltung Ihrer Netzwerkkontrollen zu nutzen, z. B. vorhersehbarere Versionen, automatisierte Tests mit Tools wie [AWS CloudFormation Guard](https://docs.aws.amazon.com/cfn-guard/latest/ug/what-is-guard.html)und die Erkennung von Abweichungen zwischen Ihrer bereitgestellten Umgebung und der gewünschten Konfiguration.
Basierend auf den Entscheidungen, die Sie im Rahmen von [SEC05-BP01 Create Network Layers getroffen haben, verfolgen Sie möglicherweise einen zentralen Managementansatz für die Erstellung von Netzwerkschichten](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_network_protection_create_layers.html)VPCs, die für Eingangs-, Ausgangs- und Inspektionsabläufe vorgesehen sind. [Wie in der [AWS Sicherheitsreferenzarchitektur (AWS SRA)](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture) beschrieben, können Sie diese VPCs in einem speziellen Netzwerkinfrastrukturkonto definieren.](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/network.html) Sie können ähnliche Techniken verwenden, um zentral die von Ihren Workloads in anderen Konten VPCs verwendeten Sicherheitsgruppen, AWS Network Firewall Bereitstellungen, Route 53-Resolver-Regeln und DNS Firewall-Konfigurationen sowie andere Netzwerkressourcen zu definieren. Sie können diese Ressourcen mit Ihren anderen Konten mit [AWS Resource Access Manager](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html) teilen. Mit diesem Ansatz können Sie das automatisierte Testen und die Bereitstellung Ihrer Netzwerkkontrollen für das Netzwerkkonto vereinfachen, da Sie nur ein Ziel verwalten müssen. Sie können dies in einem hybriden Modell tun, bei dem Sie bestimmte Kontrollen zentral bereitstellen und gemeinsam nutzen und andere Kontrollen an die einzelnen Workload-Teams und ihre jeweiligen Konten delegieren.
## Implementierungsschritte
1. Legen Sie fest, welche Aspekte des Netzwerks und des Schutzes zentral definiert werden und welche Ihre Workload-Teams verwalten können.
1. Erstellen Sie Umgebungen zum Testen und Bereitstellen von Änderungen an Ihrem Netzwerk und dessen Schutzmaßnahmen. Verwenden Sie zum Beispiel ein Netzwerk-Testkonto und ein Netzwerk-Produktionskonto.
1. Legen Sie fest, wie Sie Ihre Vorlagen in einem Versionskontrollsystem speichern und pflegen wollen. Speichern Sie zentrale Vorlagen in einem Repository, das sich von den Workload-Repositories unterscheidet, während Workload-Vorlagen in Repositories gespeichert werden können, die speziell für diesen Workload gelten.
1. Erstellen Sie CI/CD-Pipelines zum Testen und Bereitstellen von Vorlagen. Definieren Sie Tests, um zu prüfen, ob Fehlkonfigurationen vorliegen und ob die Vorlagen den Standards Ihres Unternehmens entsprechen.
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [SEC01-BP06 Automatisieren Sie die Implementierung von Standard-Sicherheitskontrollen](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_automate_security_controls)
**Zugehörige Dokumente:**
+ [AWS Security Reference Architecture - Network account](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/network.html)
**Zugehörige Beispiele:**
+ [AWS Deployment Pipeline Reference Architecture](https://pipelines.devops.aws.dev/)
+ [NetDevSecOpszur Modernisierung von Netzwerkinstallationen AWS](https://aws.amazon.com/blogs/networking-and-content-delivery/netdevsecops-to-modernize-aws-networking-deployments/)
+ [Integration von AWS CloudFormation Sicherheitstests und Berichten AWS Security Hub CSPMAWS CodeBuild](https://aws.amazon.com/blogs/security/integrating-aws-cloudformation-security-tests-with-aws-security-hub-and-aws-codebuild-reports/)
**Zugehörige Tools:**
+ [AWS CloudFormation](https://aws.amazon.com/cloudformation/)
+ [AWS CloudFormation Guard](https://docs.aws.amazon.com/cfn-guard/latest/ug/what-is-guard.html)
+ [cfn\$1nag](https://github.com/stelligent/cfn_nag)