Amazon SCS-C02: Netzwerk- und VPC-Sicherheit — Lernleitfaden

By Laurynas Brazys · 24 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

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

VPC-Endpunkte und Endpunkt-Richtlinien

VPC-Endpunkte halten den Datenverkehr zu AWS-Services im AWS-Netzwerk und umgehen dabei das öffentliche Internet, NAT-Gateways und Internet-Gateways. Es gibt zwei strukturell unterschiedliche Arten, und deren Verwechslung ist einer der häufigsten Designfehler.

Gateway-Endpunkte gibt es nur für Amazon S3 und DynamoDB. Sie sind Einträge in Routing-Tabellen – Sie verknüpfen den Endpunkt mit Routing-Tabellen, und der für die Präfixliste des Dienstes bestimmte Datenverkehr (z. B. pl-63a5400a für S3 in us-east-1) wird unbemerkt über den Endpunkt umgeleitet. Sie kosten nichts und können nicht von außerhalb der VPC, an die sie angebunden sind, erreicht werden.

Interface-Endpunkte (basierend auf AWS PrivateLink) sind ENIs mit privaten IP-Adressen, die in Ihren Subnetzen platziert werden. Sie sind für jeden Dienst erforderlich, der nicht S3 oder DynamoDB ist – Secrets Manager, KMS, STS, SSM, CloudWatch Logs, ECR API/DKR und Hunderte andere. Wenn eine EC2-Instanz in einem privaten Subnetz ohne NAT-Gateway GetSecretValue von Secrets Manager abrufen muss, hilft ein Gateway-Endpunkt nicht; Sie müssen einen com.amazonaws.<region>.secretsmanager Interface-Endpunkt erstellen und privates DNS aktivieren, damit der Standard-Hostname des Dienstes zur privaten IP des Endpunkts aufgelöst wird.

Endpunkt-Richtlinien schränken ein, was über den Endpunkt getan werden kann, unabhängig von den IAM-Richtlinien des Aufrufers. Die beiden wichtigsten Condition Keys zur Verhinderung von Datenexfiltration sind aws:PrincipalOrgID (die Identität, die den Aufruf tätigt, muss zu Ihrer Organisation gehören) und aws:ResourceOrgID (der S3-Bucket, KMS-Schlüssel usw., auf den zugegriffen wird, muss zu Ihrer Organisation gehören). Die Anwendung beider schließt den klassischen Exfiltrationspfad, bei dem eine kompromittierte Instanz mit legitimen S3-Berechtigungen in einen von einem Angreifer kontrollierten Bucket außerhalb Ihrer Organisation schreibt – die Anmeldeinformationen funktionieren zwar weiterhin gegen S3, aber der Endpunkt weigert sich, die Anfrage weiterzuleiten.

{
  "Statement": [{
    "Effect": "Allow",
    "Principal": "*",
    "Action": "s3:*",
    "Resource": "*",
    "Condition": {
      "StringEquals": {
        "aws:PrincipalOrgID": "o-abc123",
        "aws:ResourceOrgID":  "o-abc123"
      }
    }
  }]
}

Die Standard-Endpunkt-Richtlinie ist vollständig permissiv ("Action":"*" auf "Resource":"*"), weshalb ein Subnetz nur mit einem Gateway-Endpunkt und Least-Privilege-IAM immer noch für Exfiltration missbraucht werden kann, es sei denn, Sie verschärfen die Endpunkt-Richtlinie selbst.

Hybride Konnektivität: VPN und Direct Connect

Site-to-Site VPN baut zwei IPsec-Tunnel zwischen einem Virtual Private Gateway (oder Transit Gateway) und einem Customer Gateway-Gerät auf. Es ist schnell bereitzustellen, standardmäßig verschlüsselt und durchquert das öffentliche Internet – daher hängen Durchsatz und Latenz von Ihrem ISP-Pfad ab.

AWS Direct Connect stellt eine dedizierte physische Leitung über einen Direct Connect-Standort bereit. Es bietet vorhersagbar niedrige Latenz und hohe, konsistente Bandbreite (1/10/100 Gbit/s), was für „geschwätzigen“ On-Premises-Datenbankverkehr wichtig ist. Direct Connect ist von sich aus nicht auf Layer 3 verschlüsselt; die Frames laufen über private Glasfaser. Für Workloads, die sowohl niedrige Latenz als auch IPsec erfordern, ist die Standardlösung Direct Connect plus ein Site-to-Site VPN, das über ein öffentliches VIF läuft (oder ein Transit Gateway mit MACsec auf neueren DX-Ports). Ein reines VPN ist auch das empfohlene verschlüsselte Backup für eine primäre Direct Connect-Verbindung und bietet Ausfallsicherheit, falls die Leitung ausfällt.

• Nur Direct Connect: niedrige Latenz, privat, aber auf der IP-Ebene unverschlüsselt.
• Nur VPN: verschlüsselt, schnell bereitzustellen, aber Latenz und Jitter des Internet-Pfades.
• Direct Connect + VPN: niedrige Latenz und IPsec-Verschlüsselung; auch das Standard-HA-Muster.

Sicherheitsgruppen, NACLs, DHCP und Quell-/Ziel-Überprüfung

Sicherheitsgruppen sind zustandsbehaftet (stateful): Wenn Sie eine eingehende Anfrage erlauben, wird die Antwort automatisch ausgehend erlaubt. Sie unterstützen nur „Erlauben“-Regeln (allow rules) und werden pro ENI ausgewertet.

Netzwerk-ACLs sind zustandslos (stateless) und operieren an der Subnetzgrenze. Jeder Flow erfordert zwei Regeln – eine für die ursprüngliche Richtung und eine für den Rückverkehr im Bereich der ephemeren Ports (Linux typischerweise 32768–60999, Windows 49152–65535 und NLBs/ELBs verwenden 1024–65535). Eine NACL, die eingehenden TCP-Port 443 erlaubt, aber ausgehenden TCP-Port 1024–65535 vergisst, wird unbemerkt TLS unterbrechen. ICMP ist nicht TCP/UDP: „Echo-Reply“-Antwortpakete müssen explizit erlaubt werden, und Path MTU Discovery basiert auf ICMP Typ 3 Code 4, was leicht versehentlich verworfen werden kann. NACL-Regeln werden ebenfalls in numerischer Reihenfolge ausgewertet, wobei die erste passende Regel gewinnt (first-match wins), mit einem impliziten „Deny“ am Ende.

DHCP-Optionssätze steuern, was eine VPC den Instanzen beim Start übergibt: domain-name-servers, domain-name, NTP-Server, NetBIOS. Das Ersetzen des standardmäßigen AmazonProvidedDNS durch einen benutzerdefinierten On-Premises-Resolver kann legitim sein, hat aber echte Sicherheitskonsequenzen. Dienste wie GuardDuty leiten DNS-basierte Befunde (z. B. die Erkennungen „Kryptowährung“ und „C&C-Domäne“) aus Abfragen ab, die den Route 53 Resolver durchlaufen. Sobald Sie Instanzen auf einen DNS-Server eines Drittanbieters verweisen, sieht GuardDuty die Abfragen nicht mehr und diese Befundtypen verschwinden – eine einfache Möglichkeit, die Erkennung versehentlich zu blenden.

Die Quell-/Ziel-Überprüfung (Source/Destination Checking) ist ein ENI-Attribut, das jedes Paket verwirft, dessen Quell- oder Ziel-IP nicht mit dem ENI übereinstimmt. Diese Standardeinstellung ist für gewöhnliche Instanzen korrekt, unterbricht aber jede Appliance, deren Aufgabe es ist, Datenverkehr weiterzuleiten – NAT-Instanzen, virtuelle Firewalls (Palo Alto, Fortinet, Check Point), Transit-Router, VPN-Konzentratoren. Für diese ENIs deaktivieren Sie die Überprüfung:

aws ec2 modify-instance-attribute \
  --instance-id i-0abc123 \
  --no-source-dest-check

VPC-Peering, über RAM geteilte VPCs und NAT-Design

VPC-Peering ist eine nicht-transitive Layer-3-Verbindung zwischen zwei VPCs (eins zu eins). Wenn VPC A mit B und B mit C verbunden ist, kann A nicht auf C zugreifen – Sie müssen A und C direkt peeren oder ein Transit Gateway verwenden. Die Routing-Tabellen auf beiden Seiten müssen Routen zum Peer-CIDR enthalten, und Sicherheitsgruppen können nur innerhalb einer Region auf die IDs von Peer-Sicherheitsgruppen verweisen.

Geteilte VPCs über AWS Resource Access Manager (RAM) ermöglichen es einem zentralen Netzwerkkonto, eine VPC zu besitzen und einzelne Subnetze mit Teilnehmerkonten zu teilen. Die Teilnehmer starten Ressourcen in den geteilten Subnetzen, können aber weder die VPC noch Routing-Tabellen oder Endpunkte ändern – der Eigentümer behält die Kontrolle über die Konnektivitätsrichtlinien. Dies ist oft kostengünstiger und einfacher als das Peering vieler VPCs.

Für ausgehenden Internetverkehr aus privaten Subnetzen stellen Sie ein NAT-Gateway pro Availability Zone bereit und leiten jedes private Subnetz zum NAT in seiner eigenen AZ. Ein einzelnes NAT-Gateway stellt eine AZ-übergreifende Abhängigkeit und einen Engpass für Skalierbarkeit und Verfügbarkeit dar. Wenn Ihr Workload einen Drittanbieter aufruft, der Ihre ausgehenden Verbindungen auf eine IP-Allow-Liste setzt (z. B. ein Zahlungsabwickler), registrieren Sie die Elastic IP des NAT-Gateways. Da Instanzen hinter einer Auto Scaling-Gruppe alle über diese feste EIP ausgehen, ändert sich die Quell-IP nicht, wenn die Gruppe skaliert. Die Platzierung der EC2-Instanzen und der RDS-Datenbank in privaten Subnetzen und die Terminierung von nur HTTP/HTTPS auf dem ALB vervollständigt dieses Muster.

Route 53 Resolver: Weiterleitung und Abfrageprotokollierung

Der Route 53 Resolver (die .2-Adresse in jeder VPC) ist der Dreh- und Angelpunkt für hybrides DNS. Ausgehende Resolver-Endpunkte (Outbound) leiten bestimmte Domainnamen von AWS über Regeln zur bedingten Weiterleitung (Conditional Forwarding Rules) an lokale DNS-Server weiter – zum Beispiel, damit corp.example.internal gegen Ihr Active Directory aufgelöst wird. Eingehende Resolver-Endpunkte (Inbound) tun das Gegenteil: Sie stellen lokalen Hosts eine private IP in Ihrer VPC zur Verfügung, die sie abfragen können, um *.eu-west-1.compute.internal und Private Hosted Zones aufzulösen.

Das Resolver-Abfrageprotokollierung (Query Logging) schreibt jede DNS-Anfrage, die von der VPC aus gestellt wird, in CloudWatch Logs, S3 oder Kinesis Firehose. Es ist die maßgebliche Aufzeichnung zur Untersuchung von vermuteter Datenexfiltration oder Missbrauch und ergänzt – ersetzt aber nicht – GuardDuty. Denken Sie daran: Wenn ein DHCP-Optionssatz Instanzen zu einem Nicht-Amazon-Resolver umleitet, werden sowohl die Abfrageprotokollierung als auch die DNS-Erkenntnisse von GuardDuty unbrauchbar (go dark), da die Anfragen den Route 53 Resolver nie erreichen.

Praktisches Problem: Anwendungsfall-Szenario

Szenario: Meridian Financial betreibt eine AWS-Umgebung mit mehreren Konten und einem Hub-and-Spoke-Netzwerk: Eine über RAM geteilte Shared-Services-VPC hostet zentrale NAT Gateways, Route 53 Resolver-Endpunkte und Transit Gateway-Attachments, während mehrere Anwendungs-VPCs mit dem Transit Gateway gepeert oder verbunden sind. Lokale Rechenzentren sind über Direct Connect mit VPN-Failover angebunden, und die Teams verlassen sich für die hybride DNS-Auflösung auf zentralisierte DHCP-Optionssätze und geteilte Resolver-Endpunkte.

Herausforderung: Ein kürzlicher Vorfall zeigte, dass auf sensible S3-Objekte über das öffentliche Internet zugegriffen wurde, weil die Spokes den Traffic über das geteilte NAT anstatt über VPC-Endpunkte leiteten. Zudem wurden DNS-Anfragen für interne Zonen an öffentliche Resolver weitergegeben (geleakt), und eine EC2-Instanz, die als Ad-hoc-Router (Source/Dest-Check deaktiviert) verwendet wurde, ermöglichte laterale Bewegungen (Lateral Movement).

Empfohlener Ansatz:

1. Stellen Sie Gateway-VPC-Endpunkte für S3 und DynamoDB sowie Interface-Endpunkte (AWS PrivateLink) für Secrets Manager und KMS in der Shared-Services-VPC bereit. Fügen Sie explizite Endpunkt-Richtlinien (Endpoint Policies) an, die den Zugriff auf benannte Buckets und Service Principals beschränken.
2. Überarbeiten Sie das NAT-Design, sodass Anwendungs-Subnetze VPC-Endpunkte für AWS-APIs und S3 verwenden. Behalten Sie NAT Gateways nur für echten ausgehenden Internetverkehr bei, abgesichert durch strikte Egress-Sicherheitsgruppen und Flow Logs nach CloudWatch/S3.
3. Aktivieren Sie die Source/Dest-Prüfungen auf allen EC2-Instanzen wieder, außer auf dokumentierten Routing-Appliances. Verlagern Sie das Routing auf Transit Gateway-Attachments oder verwaltete NAT-Instanzen und setzen Sie das Prinzip der geringsten Rechte (Least Privilege) für Routing-Tabellen durch.
4. Verschärfen Sie die Sicherheitsgruppen und Subnetz-NACLs zu einer „Deny-by-Default“-Haltung und wenden Sie zentralisierte IAM+SG-Baselines über AWS Organizations SCPs und AWS Config-Regeln an.
5. Härten Sie das hybride DNS, indem Sie eingehende/ausgehende Endpunkte des Route 53 Resolvers bereitstellen, Regeln für bedingte Weiterleitung und DNS Firewall konfigurieren, die Resolver-Abfrageprotokollierung in CloudWatch Logs aktivieren und DHCP-Optionssätze verwenden, um die Nutzung interner Resolver für alle über RAM geteilten VPCs zu erzwingen.

Begründung: Dieser Ansatz eliminiert unnötigen ausgehenden Internetverkehr durch die Verwendung von VPC-Endpunkten mit Endpunkt-Richtlinien, zentralisiert und kontrolliert das Routing über Transit Gateway/Direct Connect, stellt Schutzmechanismen auf Instanzebene wieder her und verhindert das Durchsickern von DNS-Anfragen (DNS Leakage) durch Resolver-Endpunkte und Protokollierung. Dies steht im Einklang mit den Best Practices von AWS für Netzwerke und gestaffelte Sicherheitskonzepte (Defense-in-Depth).

VPC-Endpunkte und Endpunktrichtlinien

VPC-Endpunkte ermöglichen es Workloads innerhalb einer VPC, auf AWS-Service-APIs zuzugreifen, ohne das öffentliche Internet oder ein NAT-Gateway zu durchlaufen. Es gibt zwei Architekturvarianten, und die Wahl der falschen ist eine häufige Ursache für fehlgeleiteten Datenverkehr.

• Gateway-Endpunkte: Werden nur für Amazon S3 und DynamoDB verwendet. Sie werden als Ziel in einer Routing-Tabelle implementiert (Präfixliste pl-xxxxxxxx, die auf vpce-xxxxxxxx verweist). Es wird kein ENI erstellt, es sind keine DNS-Änderungen erforderlich und es fallen keine stündlichen Kosten an.

• Interface-Endpunkte (PrivateLink): Werden für KMS, SQS, SNS, Secrets Manager, STS, die EC2-API und die meisten anderen Services verwendet. Sie stellen ENIs mit privaten IPs in ausgewählten Subnetzen bereit und werden stündlich plus pro GB abgerechnet.

Für einen kontoübergreifenden Batch-Job, bei dem EC2-Instanzen in Konto B aus einem S3-Bucket in Konto A lesen, der mit einem KMS-Schlüssel in Konto A verschlüsselt ist, ist das korrekte Design ein Gateway-Endpunkt für S3 plus ein Interface-Endpunkt für KMS. Der Gateway-Endpunkt hält s3:GetObject, s3:PutObject, s3:PutObjectAcl und s3:ListBucket vom Internet fern; der Interface-Endpunkt tut dasselbe für kms:Decrypt, kms:Encrypt und kms:GenerateDataKey. Da der KMS-Schlüssel-ARN den Standard-Hostnamen kms.<region>.amazonaws.com verwendet, muss für den Interface-Endpunkt privates DNS aktiviert sein, damit der unveränderte Hostname des SDKs zur ENI des Endpunkts anstatt zum öffentlichen KMS-Dienst aufgelöst wird. Ohne privates DNS (oder ohne dass sowohl DNS-Hostnamen als auch DNS-Auflösung auf VPC-Ebene aktiviert sind) würde der Client immer noch den öffentlichen Endpunkt ansteuern – daher erfordert die Anforderung „keine Code-Änderungen“ implizit privates DNS.

Endpunktrichtlinien sind eine zweite, unabhängige Autorisierungsebene. Es existiert eine standardmäßig freizügige Richtlinie, aber eine Härtung für einen bestimmten Bucket und Schlüssel sieht wie folgt aus:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": "*",
    "Action": ["s3:GetObject","s3:PutObject","s3:PutObjectAcl","s3:ListBucket"],
    "Resource": ["arn:aws:s3:::acct-a-bucket","arn:aws:s3:::acct-a-bucket/*"]
  }]
}

Das bloße Erstellen des Endpunkts reicht nicht aus. Zwei Fehlerszenarien treten immer wieder auf: (1) Der Endpunkt existiert, aber die Routing-Tabelle des privaten Subnetzes hat keinen Eintrag für die S3-Präfixliste, sodass der Verkehr weiterhin über das NAT-Gateway ausgeleitet wird; (2) die Endpunktrichtlinie lässt eine Aktion wie s3:PutObjectAcl aus oder zielt auf den falschen Bucket-ARN, wodurch Aufrufe, die IAM ansonsten erlauben würde, stillschweigend blockiert werden. Sowohl die Bucket-Richtlinie als auch die Endpunktrichtlinie müssen die Anfrage zulassen – sie werden als Schnittmenge und nicht als Vereinigungsmenge behandelt.

Sicherheitsgruppen, NACLs und schnelle Eindämmung

Sicherheitsgruppen und Netzwerk-ACLs (NACLs) lösen überlappende Probleme auf unterschiedlichen Ebenen, und die Prüfung erzwingt oft eine Wahl zwischen ihnen für die Incident Response.

• Sicherheitsgruppen: Zustandsbehaftet (Stateful), Auswertung auf ENI-Ebene. Rückverkehr wird automatisch zugelassen. Es existieren nur „Allow“-Regeln. Ideal für Richtlinien auf Host-Ebene („Web-Tier kann App-Tier auf Port 8080 erreichen“).

• Netzwerk-ACLs: Zustandslos (Stateless), Auswertung an der Subnetzgrenze. Es existieren sowohl „Allow“- als auch „Deny“-Regeln, die in der Reihenfolge der Regelnummern verarbeitet werden. Ideal für grobe, subnetzweite Sperren – insbesondere für das Blocklisting eines IP-Bereichs oder das Sperren eines bestimmten Ports für jede Instanz in einem Subnetz.

Wenn ein Malware-Ausbruch Sie zwingt, ausgehenden Verkehr auf TCP/2905 zu einer Reihe von Command-and-Control-IPs über viele Instanzen hinweg zu blockieren, ist eine NACL-„Deny“-Regel das richtige Instrument. Sicherheitsgruppen können kein „Deny“ ausdrücken und würden erfordern, jede SG, die von jeder betroffenen ENI referenziert wird, aufzuzählen und zu ändern. Eine einzige NACL-„Deny“-Regel auf Subnetz-Ebene mit einer niedrigen Regelnummer (z. B. 90) deckt alle Instanzen in diesem Subnetz sofort ab, während nicht zusammenhängender Verkehr, der durch spätere „Allow“-Regeln ausgewertet wird, erhalten bleibt.

Da NACLs zustandslos sind, denken Sie daran, dass für beide Richtungen Regeln erforderlich sind. Das Blockieren des ausgehenden Verkehrs auf Port 2905 erfordert keine Regel für eingehenden Verkehr, aber wenn Sie auch eingehende Antworten ablehnen möchten, müssen Sie einen Eintrag für eingehenden Verkehr hinzufügen – und es müssen „Allow“-Einträge für ephemere Ports (1024–65535) für eingehenden Verkehr existieren, um legitimen Rückverkehr durchzulassen.

NAT-Gateways, Routing und AZ-Unabhängigkeit

Ein NAT-Gateway ist eine zonale Ressource. Das kanonische Muster ist ein NAT-Gateway pro Availability Zone, wobei die Routing-Tabelle jedes privaten Subnetzes mit 0.0.0.0/0 auf das NAT-Gateway in derselben AZ verweist:

PrivateRouteTable-AZ-a:  0.0.0.0/0 -> nat-aaaa (in subnet public-az-a)
PrivateRouteTable-AZ-b:  0.0.0.0/0 -> nat-bbbb (in subnet public-az-b)
PrivateRouteTable-AZ-c:  0.0.0.0/0 -> nat-cccc (in subnet public-az-c)

Ein einziges, über AZs geteiltes NAT-Gateway erscheint günstiger, bringt aber zwei Probleme mit sich: Kosten für zonenübergreifenden Datentransfer bei jedem Paket und eine harte Verfügbarkeitsabhängigkeit – wenn diese AZ ausfällt, verliert jedes private Subnetz den Internetzugang. Das zonale NAT-Muster vermeidet auch Eigenheiten durch asymmetrisches Routing, wenn es mit einer Transit-Gateway-Inspektion kombiniert wird (siehe unten).

VPC-Flow-Logs zur Untersuchung

Flow-Logs erfassen 5-Tupel-Metadaten (Quell-/Ziel-IP, Port, Protokoll, Aktion ACCEPT/REJECT, Bytes, Pakete) auf VPC-, Subnetz- oder ENI-Ebene. Um Instanzen aufzuspüren, die Signale an C2-Hosts auf TCP/2905 senden, aktivieren Sie Flow-Logs für die VPC, setzen den Verkehrstyp auf REJECT (da die NACL den Verkehr nun verwirft) und fragen Sie die Daten in CloudWatch Logs Insights oder Athena ab:

SELECT srcaddr, dstaddr, dstport, action, COUNT(*) AS hits
FROM vpc_flow_logs
WHERE dstport = 2905 AND action = 'REJECT'
GROUP BY srcaddr, dstaddr, dstport, action
ORDER BY hits DESC;

Die Spalte srcaddr deckt die IPs der infizierten Instanzen mit minimalem Aufwand auf – keine Paketmitschnitte, keine Host-Agenten. Die Auswahl von „ALL“ für den Verkehr funktioniert, erzeugt aber mehr Daten und Kosten; die alleinige Auswahl von „ACCEPT“ würde die verworfenen Versuche komplett übersehen, was aber genau das ist, was Sie sehen müssen.

PrivateLink, Transit Gateway und Network Firewall

PrivateLink erweitert das Interface-Endpoint-Modell auf Ihre eigenen Services: Eine Provider-VPC stellt einen NLB hinter einem VPC Endpoint Service bereit, und Konsumenten erstellen Interface Endpoints, um darauf zuzugreifen, ohne VPC-Peering oder Routen-Sharing. Die Verbindung ist unidirektional und verbirgt den CIDR des Providers vollständig.

Transit Gateway (TGW) ist der zentrale Knotenpunkt (Hub) für Many-to-Many-Konnektivität zwischen VPCs und On-Premises-Umgebungen. Ein gängiges Muster ist eine zentralisierte Inspection-VPC, in der AWS Network Firewall oder Appliances von Drittanbietern ausgeführt werden, wobei TGW-Routentabellen den Spoke-to-Spoke-Verkehr durch die Inspection-VPC leiten. Dieses Design funktioniert unter dem Standardverhalten des TGW nicht, da das TGW die Flows über Attachment-ENIs in verschiedenen AZs hasht und der Rückgabepfad in eine andere AZ als der Weiterleitungspfad gelangen kann. Stateful Firewalls verwerfen die Pakete mitten im Flow, für die sie nie das SYN-Paket gesehen haben.

Zwei Korrekturen sind gemeinsam erforderlich. Erstens, aktivieren Sie den Appliance Mode für das TGW-Attachment der Inspection-VPC; dies bindet jeden bidirektionalen Flow an dieselbe AZ-ENI, sodass der Hin- und Rückweg denselben Firewall-Endpunkt durchlaufen. Zweitens, konfigurieren Sie die TGW-Routentabellen so, dass Spoke-Attachments den Verkehr an das Attachment der Inspection-VPC senden und eine separate Post-Inspection-Routentabelle auf der Inspection-VPC den Verkehr an den richtigen Spoke zurückleitet. Das Auslassen eines dieser Schritte – entweder nur der Appliance Mode ohne die Routentabellen oder nur die Routentabellen ohne den Appliance Mode – führt weiterhin zu asymmetrischen Paketverlusten.

Network Firewall selbst verwendet Suricata-kompatible Regeln und ist auf symmetrisches Routing angewiesen, um den Flow-Status aufrechtzuerhalten. Die Kombination mit Flow Logs sowohl in der Inspection-VPC als auch in den Spoke-VPCs liefert die forensische Spur, die erforderlich ist, um nachzuweisen, welcher Spoke eine Sitzung initiiert hat und ob die Firewall sie zugelassen oder verworfen hat.

Praktisches Problem: Anwendungsfallszenario

Szenario: Meridian Financial betreibt eine Multi-Account-AWS-Umgebung mit Produktions-VPCs über drei Availability Zones in us-east-1, die über ein AWS Transit Gateway mit einer zentralen Security-VPC verbunden sind. Sie verwenden NAT Gateways in jeder AZ für den Egress-Verkehr, S3 Gateway Endpoints und Interface Endpoints (PrivateLink) für Partner-SaaS sowie eine zentralisierte AWS Network Firewall neben Security Groups und NACLs; VPC Flow Logs werden zur Überwachung an CloudWatch gestreamt.

Herausforderung: Eine EC2-Produktionsinstanz steht im Verdacht, Lateral-Movement- und Datenexfiltrationsversuche zu einer externen IP und zu S3 unternommen zu haben. Meridian benötigt eine schnelle Eindämmung über alle AZs hinweg, ohne andere geschäftskritische VPCs zu stören.

Empfohlener Ansatz:

1. Die kompromittierte Instanz sofort unter Quarantäne stellen, indem ihre Security Groups durch eine restriktive „Quarantäne“-SG ersetzt werden, die jeglichen ausgehenden/eingehenden Verkehr verweigert, und die Instanz für die automatisierte Behebung über Systems Manager taggen; gleichzeitig auf Subnetz-Ebene Network ACL-Regeln anwenden, um den Egress-Verkehr zu verdächtigen externen IP-Bereichen zu blockieren.
2. Die VPC am Transit Gateway isolieren, indem das TGW-Routentabellen-Attachment für die betroffene VPC entfernt oder zu einer Quarantäne-TGW-Routentabelle (Blackhole oder keine Route zu anderen Attachments) geändert wird, um Lateral Movement zu anderen VPCs zu stoppen.
3. Den verbleibenden Egress-Verkehr der VPC durch die zentralisierte AWS Network Firewall umleiten, indem TGW-/Routentabellen-Einträge aktualisiert werden, um die Inspektion zu erzwingen und bekannte bösartige Ziele zu blockieren, wobei die AZ-Unabhängigkeit durch die Beibehaltung von NAT Gateways pro AZ für einen resilienten, inspizierten Egress-Verkehr erhalten bleibt.
4. Die Data-Plane-Kontrollen verschärfen, indem restriktive VPC Endpoint-Richtlinien auf S3/DynamoDB Gateway Endpoints angewendet werden, um Put/Get von nicht genehmigten Principals zu verweigern und sicherzustellen, dass interne APIs Interface Endpoints (PrivateLink) verwenden, um Pfade über das Internet zu vermeiden.
5. VPC Flow Logs mit CloudWatch Logs Insights und AWS CloudTrail für die Forensik verwenden, dann die Instanz sanieren (Re-Image, Schlüssel rotieren) und erst nach Validierung wieder einführen; Regeln über AWS Firewall Manager/AWS Config durchsetzen.

Begründung: Diese Abfolge bietet eine schnelle Eindämmung nach dem Least-Privilege-Prinzip sowohl auf Host- als auch auf Netzwerkebene, zentralisiert die Inspektion mit Network Firewall und Transit Gateway-Routing, um den „Blast Radius“ zu minimieren, bewahrt die AZ-Resilienz durch NAT pro AZ und nutzt VPC Flow Logs für eine nachvollziehbare Untersuchung – im Einklang mit den Defense-in-Depth-Best-Practices von AWS.

← Datenschutz und S3 · Alle Domänen · Edge- und Anwendungssicherheit →

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

Amazon durchsuchen →