Ein Unternehmen führt langwierige Analysen von Daten durch, die in Amazon S3 gespeichert sind. Die Aufträge werden auf Amazon EC2-Instances in einem privaten Subnetz ohne Internetzugang mithilfe einer Auto Scaling-Gruppe ausgeführt. Die EC2-Instances und S3-Buckets befinden sich im selben AWS-Konto und verwenden einen S3-Gateway-VPC-Endpunkt mit der Standardrichtlinie. Die Profilrolle jeder Instance erlaubt s3:GetObject und s3:PutObject explizit nur für die erforderlichen S3-Buckets. Das Unternehmen stellt fest, dass eine oder mehrere Instances kompromittiert sind und Daten in einen S3-Bucket außerhalb der AWS Organizations-Organisation des Unternehmens exfiltrieren. Ein Sicherheitsingenieur muss die Exfiltration stoppen, während die Verarbeitungsaufträge betriebsbereit bleiben. Welche Lösung erfüllt diese Anforderungen?

Die Aktualisierung der S3-Gateway-Endpunktrichtlinie mit den Bedingungsschlüsseln aws:ResourceOrgID und aws:PrincipalOrgID stellt sicher, dass S3-Aktionen nur für Ressourcen und von Prinzipalen innerhalb der AWS Organizations-Organisation des Unternehmens zugelassen werden. Da die EC2-Instanzen einen Gateway-VPC-Endpunkt verwenden, müssen alle S3-Anfragen diesen Endpunkt passieren. Diese Richtlinie verhindert somit die Datenexfiltration zu S3-Buckets außerhalb der Organisation, während die internen Verarbeitungsaufträge weiterhin funktionieren. Die Aktualisierung der Instance-Profilrolle ist unzureichend, da die kompromittierte Instanz möglicherweise temporäre Anmeldeinformationen generieren kann, die nicht an die ursprüngliche Rolle gebunden sind. Das Blockieren von Port 443 würde den gesamten S3-Zugriff unterbrechen. Eine Service Control Policy (SCP) wäre eine effektive Lösung, aber sie wird auf Organisationsebene angewendet und würde nicht die spezifische Anforderung erfüllen, die Exfiltration zu stoppen, während die Verarbeitungsaufträge betriebsbereit bleiben, da sie den Zugriff auf S3-Buckets in anderen Konten der Organisation blockieren könnte, die für legitime Zwecke verwendet werden.