Amazon ANS-C01: Netzwerksicherheit und Compliance — Lernleitfaden

By Laurynas Brazys · 3 August 2026 · #amazon #ans-c01 #certification #exam-prep #study-guide

Teil des AWS Advanced Networking Specialty ANS-C01 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Grundkonzept

Netzwerksicherheit in AWS ist mehrschichtig aufgebaut: Perimeter-Kontrollen, Kontrollen auf VPC-Ebene, Kontrollen auf Host- und Anwendungsebene sowie Überwachung/Inspektion. An der VPC-Grenze verwenden Sie Sicherheitsgruppen (zustandsbehaftete, host-zentrierte virtuelle Firewalls, die auf ENIs angewendet werden) und Netzwerk-ACLs (zustandslose Filterung auf Subnetz-Ebene, die nach Regelnummer ausgewertet wird), um grobe Zugriffskontrollen durchzusetzen. Sicherheitsgruppen verfolgen den Verbindungszustand, sodass ein etablierter Antwort-Flow automatisch zugelassen wird. Das macht sie ideal, um von Clients initiierte Verbindungen zu Pods oder Instanzen zu ermöglichen. NACLs erfordern explizite Zulassungsregeln in beide Richtungen oder komplementäre Regeln für den Rückverkehr; sie werden in aufsteigender Reihenfolge der Regelnummern ausgewertet und eignen sich daher für eine allgemeine Härtung auf Subnetz-Ebene, wie z. B. die Eliminierung ganzer CIDR-Bereiche oder die Anwendung temporärer Notfallmechanismen für Sperrlisten.

Inspektion und zentralisierte Richtliniendurchsetzung werden durch verwaltete und selbstverwaltete Dienste bereitgestellt. AWS Network Firewall kann zustandsbehaftete, Suricata-ähnliche Schutzmaßnahmen, Filterung nach Domain-Listen und Signaturen im Stil der Intrusion Prevention am VPC-Perimeter mit expliziten Firewall-Richtlinien und Regelgruppen implementieren. Web Application Firewall (AWS WAF) ist anwendungsorientiert für den Schutz der HTTP(S)-Schicht und integriert sich mit Application Load Balancer, Amazon CloudFront und API Gateway, um OWASP-Schutzmaßnahmen, ratenbasierte Regeln und benutzerdefinierte Header-Prüfungen durchzusetzen. DDoS-Schutz wird durch AWS Shield bereitgestellt (Standard ist automatisch und kostenlos; Shield Advanced bietet Traffic Engineering, Kostenschutz und Integration mit WAF zur Mitigation auf Anwendungsebene). Erkennungsdienste wie Amazon GuardDuty analysieren VPC Flow Logs, DNS-Protokolle und CloudTrail, um Aufklärungsaktivitäten (Reconnaissance), Port-Scans und das Verhalten kompromittierter Instanzen aufzudecken.

Sichtbarkeit und Paketerfassung vervollständigen das Modell. VPC Flow Logs zeichnen Flow-Metadaten pro ENI auf und können an CloudWatch Logs, Amazon S3 oder Kinesis Data Firehose zur Analyse mit Athena übermittelt werden. Für eine vollständige Paketerfassung oder tiefere Inspektion ermöglicht Traffic Mirroring die Spiegelung des ENI-Traffics an eine IDS/Paketerfassungs-Appliance (ein EC2-Sensor mit einer gespiegelten ENI oder ein Ziel eines Network Load Balancers), wo Tools wie Suricata oder Zeek ausgeführt werden. Zusammen ermöglichen diese Kontrollen eine Defense-in-Depth-Strategie, bei der Prävention, Erkennung und Forensik vorhanden sind.

Wichtige Dienste und Konfiguration

Mehrere AWS-Dienste sind für die Netzwerksicherheit von zentraler Bedeutung, und jeder hat spezifische Konfigurationsmuster und APIs, die man kennen sollte:

Security Groups
Network ACLs (NACLs)
AWS Network Firewall
AWS WAF
AWS Shield (Standard und Advanced)
Amazon GuardDuty
VPC Flow Logs
Traffic Mirroring

Sicherheitsgruppen werden pro ENI über die EC2-API oder die Konsole konfiguriert; um eine Ingress-Regel hinzuzufügen, verwenden Sie „aws ec2 authorize-security-group-ingress –group-id sg-123 –protocol tcp –port 443 –cidr 0.0.0.0/0“. Denken Sie daran, CIDRs mit den geringsten Rechten (Least Privilege) zu verwenden und separate SGs für Load Balancer und Backend-Pods anzuhängen, um zu weitreichende Regeln zu vermeiden. Erstellen Sie NACLs über „aws ec2 create-network-acl“ und fügen Sie nummerierte Einträge mit „aws ec2 create-network-acl-entry“ hinzu, wobei Regelnummer, Regelaktion, Protokoll, Portbereich und das Egress-Flag angegeben werden.

AWS Network Firewall verwendet Regelgruppen und Firewall-Richtlinien, die an eine Firewall-Ressource gebunden sind, welche in einem VPC-Subnetz erstellt wird. Verwenden Sie „aws network-firewall create-rule-group“, um zustandslose oder zustandsbehaftete Regeln zu definieren, „aws network-firewall create-firewall-policy“, um sie zusammenzusetzen, und „aws network-firewall create-firewall“, um sie bereitzustellen. Wählen Sie zustandsbehaftete Regelgruppen für protokollbewusste Inspektion und Suricata-kompatible Signaturregeln; verwenden Sie zustandslose Regeln für sehr hohen Durchsatz und eine Erstfilterung.

AWS WAF hängt eine Web ACL an einen ALB an und kann Übereinstimmungen mit IP-Sets, String-Übereinstimmungen in Headern oder ratenbasierte Regeln durchsetzen. Verwenden Sie „aws wafv2 create-web-acl“ und geben Sie Regeln an, die Header prüfen (z. B. das Blockieren von Anfragen, die keinen benutzerdefinierten Header enthalten, den Sie an Ihrem vertrauenswürdigen Front-End einfügen). AWS Shield Advanced wird pro Konto aktiviert und bietet Zugang zum DDoS Response Team sowie zusätzlichen Schutz für Ressourcen, die bei Shield Advanced registriert sind.

Aktivieren Sie GuardDuty über „aws guardduty create-detector“ und integrieren Sie die Ergebnisse (Findings) zur Automatisierung mit CloudWatch Events oder EventBridge. Für die Telemetrie erstellen Sie VPC Flow Logs über „aws ec2 create-flow-logs –resource-type VPC –resource-id vpc-123 –traffic-type ALL –log-destination-type cloud-watch-logs –log-group-name /aws/vpc/flowlogs“. Für die Paketerfassung verwenden Sie „aws ec2 create-traffic-mirror-target“, „aws ec2 create-traffic-mirror-filter“ und „aws ec2 create-traffic-mirror-session“, um gespiegelten Datenverkehr an eine Appliance-ENI oder einen NLB zu leiten.

Designmuster und Kompromisse

Ende-zu-Ende-Verschlüsselung mit Mutual TLS, bei der der Load Balancer TLS nicht terminieren darf, erfordert ein Layer-4-Pass-Through-Muster. Verwenden Sie einen Network Load Balancer (NLB) vor den Backend-Pods, damit die TLS-Sitzung direkt mit den Service-Endpunkten ausgehandelt wird. In Kubernetes auf EKS stellen Sie einen Service vom Typ LoadBalancer bereit, der von einem NLB unterstützt wird, und registrieren Sie Pods als Ziele nach IP-Adresse. Der AWS Load Balancer Controller oder ältere Service-Annotationen stellen sicher, dass der Zieltyp IP und das Protokoll der Zielgruppe TCP ist. Bei hoher Gleichzeitigkeit, die für gRPC und viele langlebige HTTP/2-Verbindungen charakteristisch ist, behält der NLB die Quell-IPs bei und verursacht einen geringeren Overhead pro Verbindung als L7-Proxys. Wenn eine TLS-Terminierung am ALB erforderlich ist (z. B. für URL-basiertes Routing), müssen Sie TLS am ALB mit einem ACM-Zertifikat terminieren und dann an die Backends weiterleiten. Die Client-IP kann beibehalten werden, indem Sie sich auf X-Forwarded-For (ALB) verlassen oder einen Proxy Protocol v2-fähigen NLB für Backends verwenden, die die ursprüngliche Quell-IP auf L4 benötigen.

Für skalierbare Multi-Account- und Multi-VPC-Architekturen, in denen zentrale Dienste erforderlich sind, ist PrivateLink (AWS VPC Endpoint Services) die sicherste und skalierbarste Wahl. Stellen Sie zentrale Dienste aus der Shared-Services-VPC als AWS PrivateLink Endpoint Service bereit. Jedes Konsumenten-Konto erstellt einen Interface VPC Endpoint zu diesem Dienst. Der Service-Eigentümer kann die Annahme des Endpunkts erfordern und auf den Endpoint-ENIs auf Sicherheitsgruppen basierende Kontrollen anwenden. Dieses Modell hält den Datenverkehr im AWS-Netzwerk, vermeidet die Skalierungsgrenzen von Peering und bietet granulare Sicherheit pro Konsument. Transit Gateway mit Segmentierung und Network Firewall kann für den Transit auf Netzwerkebene und die zentrale Inspektion verwendet werden, ist aber besser geeignet, wenn eine vollständig geroutete Konnektivität mit komplexen Routing-Richtlinien erforderlich ist anstatt einer Isolation pro Dienst.

Bei der Diagnose der Bandbreitennutzung über mehrere VIFs auf Direct Connect sollten Sie zuerst Metadaten priorisieren: Aktivieren und fragen Sie VPC Flow Logs ab, die in S3 oder CloudWatch aggregiert sind, und analysieren Sie sie mit Athena, um IP-Flows mit hohem Volumen bestimmten VPCs und Subnetzen zuzuordnen. Ergänzen Sie die Flow Logs mit CloudWatch-Metriken für die virtuellen Schnittstellen von Direct Connect. Wenn Sie eine Inspektion auf Payload-Ebene oder heterogene Protokolle benötigen, setzen Sie Traffic Mirroring ein, um Pakete an ein EC2-basiertes IDS zu erfassen. Traffic Mirroring ist ressourcenintensiv und verursacht Kosten; verwenden Sie es nur für Sitzungen/Zeitfenster, in denen Flow Logs und GuardDuty-Ergebnisse nicht ausreichen.

Häufige Fallstricke und Entscheidungskriterien

Ein häufiger Fehler ist es, sich für eine breite Perimeter-Durchsetzung allein auf Security Groups zu verlassen und nicht auf NACLs oder Network Firewall zurückzugreifen, wo eine Inspektion auf Subnetz-Ebene oder eine zustandsbehaftete (stateful) Überprüfung erforderlich ist. Security Groups sind pro ENI konfiguriert und einfach zu verwalten, aber sie skalieren nicht gut als zentrale Steuerungsebene für viele VPCs in verschiedenen Konten; verwenden Sie AWS Firewall Manager, um WAF- und Network Firewall-Regeln kontoübergreifend zu zentralisieren. Ein weiterer Fallstrick ist die Beendigung von TLS am Load Balancer, ohne die Erhaltung der Client-IP zu berücksichtigen; ein ALB fügt X-Forwarded-For-Header ein, aber das Anwendungs-Logging muss diesen Header explizit auslesen und es muss eine Vertrauensstellung etabliert werden (z. B. sollte nur der ALB diesen senden). Um strikt sicherzustellen, dass nur Global Accelerator einen ALB erreichen kann, vermeiden Sie es, sich ausschließlich auf DNS zu verlassen; schränken Sie stattdessen die ALB-Listener über Security Groups auf die veröffentlichten IP-Bereiche des Accelerators ein (automatisieren Sie Updates mit der ip-ranges.json oder verwalteten Präfixlisten) oder verwenden Sie, wo möglich, einen rein internen ALB und schalten Sie ihm den Accelerator-Endpunkt vor.

Entscheiden Sie zwischen PrivateLink und Transit Gateway, indem Sie die Service-Granularität gegen vollständiges Full-Mesh-Routing abwägen. PrivateLink bietet eine zugriffskontrollierte Verbindung pro Service mit Filterung auf Ebene der Security Groups und skaliert, ohne die Routing-Tabellen zu überlasten; Transit Gateway ist notwendig, wenn Sie routenbasierte Konnektivität zwischen vielen VPCs und On-Premises-Netzwerken benötigen und wenn Sie eine zentrale Paketinspektion mit AWS Network Firewall erfordern. Für hohen Durchsatz bevorzugen Sie zustandslose (stateless) Network Firewall-Regeln am Perimeter, kombiniert mit gezielten zustandsbehafteten (stateful) Regelgruppen für kritische Datenflüsse; die zustandslose Verarbeitung skaliert gut, verliert aber das Protokollbewusstsein.

Praktisches Problem: Anwendungsfallszenario

Genanntes Unternehmen: Meridian Payments – Herausforderung: eine gRPC-basierte Zahlungs-API auf EKS zu ermöglichen, die durchgehendes Mutual TLS erfordert (keine TLS-Terminierung im Pfad), Tausende von gleichzeitigen, langlebigen Verbindungen unterstützt, Autoscaling von Pods ermöglicht und die Identifizierung der ursprünglichen Client-IPs für Protokollierung und Betrugserkennung sicherstellt.

Ansatz: Bereitstellen eines Amazon Network Load Balancer vor dem EKS Service, der für den Zieltyp IP konfiguriert ist, sodass die Pod-ENIs direkt bei den NLB-Zielgruppen registriert werden. Verwenden Sie den AWS Load Balancer Controller, um einen NLB-gestützten Service mit Annotationen zu erstellen, um sicherzustellen, dass das Protokoll der Zielgruppe TCP auf Port 443 ist und Health Checks ebenfalls TCP verwenden. Beenden Sie mTLS an den Backend-Pods; konfigurieren Sie Istio oder eine Sidecar-TLS-Bibliothek, wenn Sie eine standardisierte Zertifikatsrotation benötigen, und verwenden Sie Kubernetes Secrets, die von AWS Certificate Manager Private Certificate Authority oder AWS Secrets Manager befüllt werden. Erhalten Sie die Client-IPs, da der NLB die Quell-IP beibehält; stellen Sie sicher, dass die networkPolicy- und Security-Group-Regeln der Backend-Pods die Quellbereiche vom NLB/den Clients zulassen. Verwenden Sie HPA und den Cluster Autoscaler, um die Pods zu skalieren; stellen Sie sicher, dass die deregistration_delay der Zielgruppe so eingestellt ist, dass ein ordnungsgemäßes Connection Draining möglich ist.
Ansatz für Beobachtbarkeit und Forensik: Aktivieren Sie VPC Flow Logs für die EKS-VPC nach CloudWatch Logs und aggregieren Sie diese zur Aufbewahrung über Kinesis Firehose in S3, um mit Athena-Abfragen Datenflüsse mit hoher Bandbreite zu analysieren. Aktivieren Sie GuardDuty zur Anomalieerkennung bei VPC-Flows und DNS. Wenn während vermuteter Betrugsfälle eine tiefere Paketinspektion erforderlich ist, erstellen Sie Traffic-Mirror-Sitzungen auf den problematischen ENIs zu einem EC2-Sensor, auf dem Suricata läuft; verwalten Sie die Mirror-Filter so, dass nur relevanter Datenverkehr erfasst wird, um die Kosten zu begrenzen.

Begründung seitens AWS: Der NLB bietet L4-Pass-Through, sodass TLS und mTLS durchgehend ausgehandelt werden und das Backend die wahre Client-IP sieht. Dies erfüllt die Anforderung, dass der Datenverkehr nicht von zwischengeschalteten Proxys entschlüsselt wird und die Protokollierungs-/Betrugsanalyse die ursprüngliche Quelle sieht. Die Registrierung von Pods nach IP und die Verwendung des AWS Load Balancer Controller integriert sich mit dem EKS-Autoscaling. VPC Flow Logs, GuardDuty und Traffic Mirroring bieten eine abgestufte Sichtbarkeit von Metadaten bis zur vollständigen Paketerfassung für eine skalierbare, kosteneffiziente Compliance und Reaktion auf Vorfälle.

← Load Balancing und Traffic-Management · Alle Domänen · Content Delivery und Edge-Networking →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →