AWS Germany – Amazon Web Services in Deutschland
Verhinderung unbeabsichtigter Verschlüsselung von Amazon S3-Objekten
von Steve de Vera and Jennifer Paz übersetzt durch David Surey
Bei Amazon Web Services (AWS) hat die Sicherheit der Daten unserer Kunden oberste Priorität und das wird auch immer so bleiben. Kürzlich haben das AWS Customer Incident Response Team (CIRT) und unsere automatisierten Sicherheitsüberwachungssysteme einen Anstieg ungewöhnlicher Verschlüsselungsaktivitäten im Zusammenhang mit Amazon Simple Storage Service (Amazon S3)-Buckets festgestellt.
Es ist wichtig zu beachten, dass diese Aktionen keine Sicherheitslücke innerhalb eines AWS-Dienstes ausnutzen, sondern gültige Anmeldeinformationen erfordern, die ein nicht autorisierter Benutzer auf unbeabsichtigte Weise verwendet. Obwohl diese Aktionen im Kundenbereich des Modells der geteilten Verantwortung stattfinden, empfiehlt AWS Schritte, die Kunden anwenden können, um solche Aktivitäten zu verhindern oder deren Auswirkungen zu reduzieren.
In Zusammenarbeit mit Kunden haben unsere Sicherheitsteams einen Anstieg von Datenverschlüsselungsereignissen in S3 festgestellt, bei denen eine Verschlüsselungsmethode namens serverseitige Verschlüsselung mit kundenseitig bereitgestellten Schlüsseln (SSE-C) verwendet wurde. Wir haben ein wichtiges Muster erkannt: Eine große Anzahl von S3 CopyObject-Operationen mit SSE-C hat begonnen, Objekte zu überschreiben. Dies führt dazu, dass Kundendaten mit einem neuen Verschlüsselungsschlüssel neu verschlüsselt werden. Diese Funktion wird zwar von vielen Kunden genutzt, birgt aber die beschriebenen Risiken. Unsere Analyse ergab, dass dies von böswilligen Akteuren durchgeführt wurde, die gültige Kunden-Anmeldeinformationen erhalten hatten und diese verwendeten, um Objekte neu zu verschlüsseln.
Mit Active Defense-Tools [EN] haben wir automatische Gegenmaßnahmen implementiert, die in vielen Fällen dazu beitragen, diese Art von unbefugten Aktivitäten zu verhindern. Diese Gegenmaßnahmen haben bereits einen hohen Prozentsatz der Versuche erfolgreich verhindert, ohne dass Kunden Schritte zum Selbstschutz unternehmen mussten. Da die Bedrohungsakteure gültige Anmeldeinformationen verwendeten, ist es für AWS schwierig, zuverlässig zwischen gültiger und böswilliger Nutzung zu unterscheiden. Daher empfehlen wir Kunden, bewährte Verfahren anzuwenden, um das Risiko zu mindern.
Um sich vor der unbefugten Verwendung von SSE-C zu schützen, empfehlen wir Kunden diese vier Sicherheits-Best Practices zu implementieren:
- Blockieren Sie die Verwendung von SSE-C, es sei denn, dies ist für eine Anwendung erforderlich
- Implementieren Sie Datenwiederherstellungsverfahren
- Überwachen Sie AWS-Ressourcen auf unerwartete Zugriffsmuster
- Implementieren Sie kurzfristige Anmeldeinformationen
I. Blockieren Sie die Verwendung der SSE-C-Verschlüsselung
Sie können die Verwendung von SSE-C blockieren, wenn Ihre Anwendungen diese Verschlüsselungsmethode nicht nutzen. Dies ist auf zwei Wegen möglich: Entweder über eine Ressourcenrichtlinie für einen S3-Bucket oder über eine Ressourcenkontrollrichtlinie (RCP), die auf eine Organisation in AWS Organizations angewendet wird.
Ressourcenrichtlinien für S3-Buckets werden üblicherweise als Bucket-Richtlinien bezeichnet und ermöglichen es Kunden, Berechtigungen für einzelne Buckets in S3 festzulegen. Eine Bucket-Richtlinie kann mithilfe der S3 PutBucketPolicy-API-Operation, der AWS-Befehlszeilenschnittstelle (CLI) oder über die AWS Management Console angewendet werden. Erfahren Sie mehr darüber, wie Bucket-Richtlinien funktionieren, in der S3-Dokumentation. Das folgende Beispiel zeigt eine Bucket-Richtlinie, die SSE-C-Anfragen für einen Bucket namens your-bucket-name> blockiert.
RCPs ermöglichen es Kunden, die maximal verfügbaren Berechtigungen festzulegen, die für Ressourcen in einer gesamten Organisation in AWS Organizations gelten. Eine RCP kann mithilfe der AWS Organizations UpdatePolicy-API-Operation, der AWS-Befehlszeilenschnittstelle (CLI) oder über die AWS Management Console angewendet werden. Erfahren Sie mehr darüber, wie RCPs funktionieren, in der AWS Organizations-Dokumentation. Das folgende Beispiel zeigt eine RCP, die SSE-C-Anfragen für Buckets in der Organisation blockiert.
II. Implementieren Sie Datenwiederherstellungsverfahren
Ohne Datenschutzmechanismen können die Wiederherstellungszeiten für Daten länger sein. Als Best Practice für den Datenschutz empfehlen wir, dass Sie sich davor schützen, dass Daten überschrieben werden, und dass Sie eine zweite Kopie kritischer Daten aufbewahren.
Aktivieren Sie die S3-Versionierung, um mehrere Versionen eines Objekts in einem Bucket aufzubewahren, damit Sie Objekte wiederherstellen können, die versehentlich gelöscht oder überschrieben wurden. Es ist wichtig zu beachten, dass die Versionierung die Speicherkosten erhöhen kann, insbesondere bei Anwendungen, die Objekte in einem Bucket häufig überschreiben. Erwägen Sie in diesem Fall die Implementierung von S3-Lebenszyklus-Richtlinien, um ältere Versionen zu verwalten und die Speicherkosten zu kontrollieren.
Kopieren oder sichern Sie außerdem kritische Daten in einem anderen Bucket und gegebenenfalls in einem anderen AWS-Konto oder einer anderen AWS-Region. Um Objekte automatisch zwischen Buckets zu kopieren können Sie die S3-Replikation verwenden. Diese Buckets können sich im selben oder in verschiedenen AWS-Konten sowie in derselben oder in verschiedenen AWS-Regionen befinden. Die S3-Replikation bietet auch eine SLA für Kunden mit strengeren Anforderungen an RPO (Recovery Point Objective) und RTO (Recovery Time Objective). Alternativ können Sie AWS Backup für S3 verwenden, einen verwalteten Dienst, der die regelmäßige Sicherung von S3-Buckets automatisiert.
III. Überwachen Sie AWS-Ressourcen auf unerwartete Zugriffsmuster
Ohne Überwachung können unbefugte Aktionen auf S3-Buckets unbemerkt bleiben. Wir empfehlen die Verwendung von Tools wie AWS CloudTrail oder S3-Server-Zugriffsprotokollierung, um den Zugriff auf Ihre Daten zu überwachen.
AWS CloudTrail ermöglicht es Ihnen, Ereignisse über AWS-Dienste (einschließlich Amazon S3) zu protokollieren. Diese Protokolle können in einem einzigen Konto zusammengeführt werden, damit Ihre Sicherheitsteams darauf zugreifen und sie überwachen können. Sie können auch CloudWatch-Alarme basierend auf spezifischen S3-Metriken oder Protokollen erstellen, um auf ungewöhnliche Aktivitäten aufmerksam zu werden. Alarme können Ihnen dabei helfen, anomales Verhalten schnell zu erkennen. Sie können auch eine Automatisierung einrichten, die Amazon EventBridge und AWS Lambda verwendet, um automatisch Korrekturmaßnahmen zu ergreifen. Sie finden hier eine Beispielimplementierung für ein Setup, das alle Buckets einer Organisation scannt und S3 Block Public Access anwendet. Dieser Blog-Beitrag zeigt Ihnen, wie Sie Verschlüsselungsmethoden für Objekt-Uploads in Echtzeit überprüfen können.
IV. Implementieren Sie kurzfristige Anmeldeinformationen
Während die oben genannte Technik die SSE-C-Verschlüsselung nutzt, liegt die eigentliche Ursache hierfür und für einen großen Teil der Sicherheitsvorfälle in der Kompromittierung von langfristigen Zugriffsschlüsseln.
Der effektivste Ansatz zur Minderung des Risikos kompromittierter Anmeldeinformationen besteht darin, von vornherein keine langfristigen Anmeldeinformationen zu erstellen. Anmeldeinformationen, die nicht existieren, können nicht offengelegt oder gestohlen werden, und AWS bietet eine umfangreiche Reihe von Funktionen, die die Notwendigkeit beseitigen, jemals Anmeldeinformationen im Quellcode oder in Konfigurationsdateien zu speichern.
IAM-Rollen ermöglichen es Anwendungen, mithilfe kurzfristiger Anmeldeinformationen sicher signierte API-Anfragen von Amazon Elastic Compute Cloud (Amazon EC2)-Instanzen, Amazon Elastic Container Service (Amazon ECS)– oder Amazon Elastic Kubernetes Service (Amazon EKS)-Containern oder Lambda-Funktionen zu stellen. Sogar Systeme außerhalb der AWS Cloud können authentifizierte Aufrufe ohne langfristige AWS-Anmeldeinformationen tätigen, indem sie die Funktion IAM Roles Anywhere verwenden.
AWS IAM Identity Center ermöglicht zusätzlich Entwicklerarbeitsplätzen den Zugriff über kurzfristige Anmeldeinformationen. Diese sind durch ihre längerfristigen Benutzeridentitäten abgesichert und werden zusätzlich durch Multi-Faktor-Authentifizierung (MFA) geschützt.
Diese Technologien basieren auf dem AWS Security Token Service (AWS STS). Der Service stellt temporäre Sicherheitsanmeldeinformationen aus, die den Zugriff auf AWS-Ressourcen steuern. Dadurch müssen keine langfristigen AWS-Sicherheitsanmeldeinformationen in Anwendungen verteilt oder eingebettet werden – weder im Code noch in Konfigurationsdateien.
Zusammenfassung
Die wichtigste Maßnahme zum Schutz Ihrer AWS-Umgebung vor gängigen Angriffen ist die Eliminierung oder Minimierung langfristiger Zugangsdaten (Zugriffsschlüssel/geheimer Schlüssel). Als nächsten Schritt sollten Sie die Berechtigungen für alle Prinzipale auf das notwendige Minimum reduzieren (sogenannte „Least-Privilege“-Analyse). Darüber hinaus haben wir für das in diesem Blog diskutierte spezielle Angriffsmuster die häufigsten Indikatoren hervorgehoben, auf die Sie achten sollten.
Ihre Sicherheitsteams arbeiten kontinuierlich am Schutz Ihrer Umgebung. Gleichzeitig setzen sich verschiedene AWS-Teams gemeinsam für den Schutz Ihrer wertvollen Daten ein. Zu diesen Teams gehören das AWS Customer Incident Response Team (CIRT), Amazon Threat Intelligence und Service-Teams wie das Amazon S3-Team. Sie alle arbeiten eng zusammen, teilen Erkenntnisse und entwickeln innovative Lösungen.
Dieser Beitrag informiert Sie über eine aktuelle Bedrohung für Kundendaten. Wir haben dabei vier Best Practices für die Sicherheit vorgestellt. Diese Praktiken helfen Ihnen, sich vor böswilligen Akteuren zu schützen, die SSE-C nutzen, um Daten mit verlorenen oder gestohlenen AWS-Anmeldeinformationen zu verschlüsseln.
Während sich die Taktiken der Bedrohungsakteure weiterentwickeln, bleibt unser Einsatz für die Sicherheit der Kunden unerschütterlich. Gemeinsam bauen wir eine sicherere Cloud-Umgebung auf, die es Ihnen ermöglicht, mit Zuversicht zu innovieren.
Wenn Sie jemals unautorisierte Aktivitäten vermuten, zögern Sie nicht und wenden sich sofort an den AWS-Support.
Über die Autor:innen
![]() |
Steve de Vera ist Manager im AWS Customer Incident Response Team (CIRT) mit Schwerpunkt auf Bedrohungsforschung und Bedrohungsinformationen. Er ist leidenschaftlicher Anhänger des American-Style-BBQ und zertifizierter Wettbewerbs-BBQ-Juror. Er hat einen Hund namens Brisket. |
![]() |
Jennifer Paz ist Security-Ingenieurin mit über einem Jahrzehnt Erfahrung und arbeitet derzeit im AWS Customer Incident Response Team (CIRT). Jennifer hilft Kunden gerne dabei, Sicherheitsherausforderungen zu bewältigen und komplexe Lösungen zu implementieren, um ihre Sicherheitslage zu verbessern. Wenn sie nicht arbeitet, ist Jennifer eine begeisterte Spaziergängerin, Joggerin, Pickleball-Enthusiastin, Reisende und Feinschmeckerin, immer auf der Suche nach neuen kulinarischen Abenteuern. |