Szenarien für sichere Architekturen

Szenario: Auf einer EC2-Instance läuft eine Webanwendung, die Objekte aus einem bestimmten S3-Bucket lesen muss. Das Sicherheitsteam verlangt, dass keine langfristigen Anmeldeinformationen auf der Instance gespeichert werden und der Zugriff nach dem Prinzip der geringsten Berechtigung erfolgt. Lösung: Erstellen Sie eine IAM role mit einer Richtlinie, die ausschließlich s3:GetObject für die ARN des bestimmten Buckets erlaubt. Verknüpfen Sie die Rolle als instance profile mit der EC2-Instance. Die Anwendung verwendet den Instance Metadata Service (IMDS), um automatisch temporäre Anmeldeinformationen abzurufen – gespeicherte Schlüssel sind nicht erforderlich.

Szenario: Ein Unternehmen speichert personenbezogene Daten von Kunden in einer RDS-PostgreSQL-Datenbank. Das Compliance-Team verlangt eine Verschlüsselung ruhender Daten und die Möglichkeit, die Verwendung des Schlüssels zu prüfen. Lösung: Aktivieren Sie die RDS encryption using AWS KMS mit einem Customer Managed Key (CMK). Mit dem CMK kann das Sicherheitsteam die Schlüsselrotation steuern, die Schlüsselverwendung in CloudTrail einsehen und den Zugriff bei Bedarf widerrufen. Hinweis: Die Verschlüsselung muss beim Erstellen der RDS-Instance aktiviert werden – eine bestehende unverschlüsselte RDS-Instance kann nicht nachträglich direkt verschlüsselt werden. Erstellen Sie zum Verschlüsseln einer vorhandenen Datenbank einen Snapshot, kopieren Sie ihn mit aktivierter Verschlüsselung und stellen Sie die Datenbank aus dem verschlüsselten Snapshot wieder her.

Szenario: Ein Entwickler hat versehentlich einen S3-Bucket öffentlich gemacht und dadurch Kundendaten offengelegt. Das Sicherheitsteam möchte sicherstellen, dass kein S3-Bucket im Konto jemals öffentlich gemacht werden kann, selbst wenn ein Entwickler dies versucht. Lösung: Aktivieren Sie S3 Block Public Access auf Kontoebene. Diese Einstellung setzt jede Bucket-Richtlinie und ACL außer Kraft, die öffentlichen Zugriff gewährt, unabhängig davon, was einzelne Teams konfigurieren. Kombinieren Sie dies mit einer AWS Config rule (s3-bucket-public-read-prohibited), um fortlaufend nicht konforme Buckets zu erkennen und entsprechende Warnungen auszulösen.

Szenario: Ein Unternehmen möchte sicherstellen, dass seine RDS-Datenbank nur von seinen Anwendungsservern und nicht aus dem Internet erreichbar ist. Lösung: Platzieren Sie RDS in einem private subnet ohne Route zu einem Internet-Gateway. Erstellen Sie eine security group for RDS, die eingehenden Datenverkehr auf Port 5432 (PostgreSQL) ausschließlich von der Security Group der Anwendungsserver zulässt – nicht von einem beliebigen IP-Adressbereich. So kann ein Angreifer selbst bei einer Kompromittierung eines Anwendungsservers nicht von außerhalb der VPC auf die Datenbank zugreifen; außerdem wird die laterale Bewegung durch die Regeln der Security Groups eingeschränkt.

Szenario: Der Anwendungscode enthält derzeit fest in Konfigurationsdateien hinterlegte Datenbankanmeldeinformationen. Das Sicherheitsaudit stuft dies als kritisches Risiko ein. Lösung: Speichern Sie die Anmeldeinformationen in AWS Secrets Manager und konfigurieren Sie eine automatic rotation (Secrets Manager verfügt über integrierte Lambda-Rotationsfunktionen für RDS). Aktualisieren Sie die Anwendung so, dass sie die Anmeldeinformationen zur Laufzeit über das SDK aus Secrets Manager abruft. Die Anwendung erhält automatisch aktuelle Anmeldeinformationen, ohne dass bei jeder Rotation ein Deployment erforderlich ist. Aktivieren Sie die RDS-Vorlage für die Secret-Rotation, um eine vollständig verwaltete Rotation der Anmeldeinformationen ohne Ausfallzeit zu ermöglichen.

Szenario: Ein Unternehmen möchte erkennen, ob die Anmeldeinformationen eines AWS-Kontos kompromittiert und von unerwarteten Orten aus verwendet werden. Lösung: Aktivieren Sie Amazon GuardDuty in allen Regionen. GuardDuty analysiert CloudTrail-Ereignisse, VPC Flow Logs und DNS-Logs mithilfe von Machine Learning, um Anomalien zu erkennen: API-Aufrufe aus ungewöhnlichen geografischen Regionen, Muster für Bitcoin-Mining auf EC2, Kommunikation mit Tor-Exit-Nodes oder Muster für den Abfluss von Anmeldeinformationen. GuardDuty erzeugt Findings, die EventBridge rules auslösen können, um das Sicherheitsteam automatisch über SNS zu benachrichtigen oder ein Support-Ticket zu erstellen.

Szenario: Eine Webanwendung hinter einem ALB erhält SQL-Injection-Angriffe. Die Anwendung kann nicht sofort geändert werden. Lösung: Verknüpfen Sie AWS WAF mit dem ALB. Setzen Sie die Regelgruppe AWS Managed Rules for Common Threats (Core Rule Set + SQL Database rule group) ein, die eine vorgefertigte Erkennung von SQL-Injection enthält. WAF prüft HTTP-Anfragen, bevor sie den ALB erreichen, und blockiert Anfragen, die Angriffsmustern entsprechen – Änderungen am Anwendungscode sind nicht erforderlich. Aktivieren Sie außerdem die WAF-Protokollierung zu Kinesis Firehose für Sicherheitsanalysen.

Szenario: Ein zentrales Sicherheitskonto benötigt schreibgeschützten Zugriff auf alle Workload-Konten in einer AWS Organisation, um Sicherheitsprüfungen durchzuführen. Lösung: Erstellen Sie in jedem Workload-Konto eine IAM role mit einer Vertrauensrichtlinie, die dem Sicherheitskonto (anhand der Konto-ID) erlaubt, die Rolle zu übernehmen. Verknüpfen Sie eine schreibgeschützte Richtlinie (z. B. die von AWS verwaltete Richtlinie SecurityAudit). Das Sicherheitsteam im zentralen Konto verwendet STS AssumeRole, um vorübergehend die Rolle in jedem Workload-Konto zu übernehmen. Dies folgt dem Prinzip der geringsten Berechtigung – in den Workload-Konten werden keine dauerhaften IAM-Benutzer angelegt.

Szenario: Ein Unternehmen verwendet AWS Organizations und möchte verhindern, dass ein Konto in einer Nicht-Produktions-OU teure GPU-Instances startet. Lösung: Erstellen Sie eine Service Control Policy (SCP), die ec2:RunInstances für GPU-Instance-Familien (p3, p4, g4, g5) verweigert, und verknüpfen Sie sie mit der Nicht-Produktions-OU. SCPs gelten auch für Root-Benutzer und IAM-Benutzer mit Administratorberechtigungen in den Mitgliedskonten – sie dienen als Leitplanken, die keine Identität im Konto außer Kraft setzen kann. Dadurch werden versehentlich oder böswillig verursachte hohe Ausgaben in Entwicklungs- und Testkonten verhindert.

Szenario: Ein Finanzdienstleistungsunternehmen muss Prüfern nachweisen, dass alle AWS-API-Aufrufe protokolliert, manipulationssicher gespeichert und 7 Jahre lang aufbewahrt werden. Lösung: Erstellen Sie einen multi-region AWS CloudTrail trail, der Protokolle in einen dedizierten S3-Bucket in einem Protokollierungskonto übermittelt. Aktivieren Sie die Log File Integrity Validation (kryptografische Digest-Dateien, die Manipulationen an Protokollen erkennen). Legen Sie für den Protokollierungs-Bucket eine S3-Object Lock-Richtlinie im Compliance-Modus mit einer Aufbewahrungsfrist von 7 Jahren fest. So wird sichergestellt, dass die Protokolle während der erforderlichen Aufbewahrungsfrist weder gelöscht noch geändert werden können – auch nicht vom Root-Benutzer.

Szenario: EC2-Instances in einer privaten VPC müssen auf S3 zugreifen, ohne dass der Datenverkehr das öffentliche Internet durchläuft. Derzeit wird ein NAT Gateway verwendet, dessen Datenverarbeitungsgebühren hohe Kosten verursachen. Lösung: Erstellen Sie einen S3 Gateway VPC Endpoint. Fügen Sie der Routingtabelle des privaten Subnetzes einen Routeneintrag hinzu, der die S3-Präfixliste auf den Endpunkt verweist. Der Datenverkehr zu S3 bleibt nun vollständig im AWS-Netzwerk-Backbone – weder ein NAT Gateway noch ein Internet-Gateway ist erforderlich. S3 Gateway Endpoints sind kostenlos (anders als Interface Endpoints, die pro Stunde und Availability Zone berechnet werden). Dies verbessert außerdem die Sicherheit, da der Zugriff auf S3 nicht mehr über den Pfad des öffentlichen Internets erfolgt.

Testen Sie Ihr Verständnis der Konzepte aus dieser Lektion für AWS Solutions Architect (SAA-C03).

In dieser Lektion haben Sie Szenarien zu folgenden Themen bearbeitet: IAM-Rollen und Instance-Profile für den EC2-Zugriff ohne Anmeldeinformationen, Secrets Manager für die automatische Rotation von Datenbank-Anmeldeinformationen, AWS WAF zum Blockieren von Injection-Angriffen ohne Codeänderungen sowie CloudTrail mit S3 Object Lock für manipulationssichere Compliance-Protokolle. Als Nächstes behandeln wir Szenarien für ausfallsichere und hochverfügbare Architekturen.