In Amazon S3 laden Sie Objekte (Dateien) hoch, wählen eine Storage-Klasse, vergeben Zugriffsrechte, konfigurieren automatisches Löschen und vieles mehr. Abgerechnet wird stundenweise, und Sie können jedes Objekt jederzeit löschen, um keine weiteren Speicherkosten zu verursachen.
Eine Funktion, die AWS eingeführt hat, ist Object Lock – ein Mechanismus, der verhindert, dass Objekte gelöscht oder überschrieben werden. Er soll Daten, die langfristig aufbewahrt werden müssen – sei es aus Compliance- oder Archivierungsgründen –, vor versehentlichem oder böswilligem Löschen schützen.
Beim Anlegen eines Buckets wählen Sie einen Object Lock Retention Mode, der vorgibt, wie AWS das Löschen von Objekten einschränkt:
- Governance Mode – Objekte sind schreibgeschützt, doch Nutzer mit speziellen Berechtigungen können den Lock übergehen oder aufheben.
- Compliance Mode – Objekte sind während der festgelegten Aufbewahrungsfrist vollständig unveränderlich. Niemand – nicht einmal der Root-Account-User oder der AWS Support – kann sie in diesem Zeitraum löschen.
In beiden Varianten lässt sich eine Aufbewahrungsfrist zwischen 1 Tag und 100 Jahren festlegen, die für jedes Objekt einzeln ab dem Upload nach S3 läuft.
Sobald Object Lock für einen Bucket aktiv ist, legen Sie beim Upload den Lock-Modus und die Aufbewahrungsfrist je Objekt fest. Geben Sie diese Werte beim Upload nicht an, greifen die Standardeinstellungen.
Ändern Sie die Standardeinstellungen später, wirkt sich das ausschließlich auf neue Objekte aus – bestehende Objekte behalten die Lock-Konfiguration, mit der sie hochgeladen wurden.
Schauen wir uns den Compliance Mode genauer an:
Ist er aktiv, kann nach dem Upload weder eine IAM Role noch ein Nutzer – nicht einmal der Root-User – die Objekte vor Ablauf der Aufbewahrungsfrist löschen. Auch der AWS Support kann Ihnen dabei nicht weiterhelfen.
Sie erhalten folgende Fehlermeldung:
"Access Denied because object protected by object lock."
Warum sollten Sie ihn blockieren?
Um den Schaden bei einem kompromittierten AWS-Account zu begrenzen.
Lassen Sie es mich erläutern: Sobald Angreifer Zugriff auf einen AWS-Account haben, folgen sie meist einem von drei Mustern:
- Ransom & Destruction: Backups verschlüsseln, Lösegeld fordern und Ressourcen löschen, um Chaos zu stiften.
- Krypto-Mining: Teure GPU-Compute-Instanzen in allen verfügbaren Regionen starten, um Kryptowährungen zu schürfen.
- Finanzieller Aderlass: Kostenintensive Ressourcen wie Metal-Instances und riesige EBS-Volumes bereitstellen oder Redshift Reserved Nodes kaufen, um die Rechnung in die Höhe zu treiben.
Ein besonders perfider Trick: Angreifer legen einen S3-Bucket mit Object Lock im Compliance Mode und langer Aufbewahrungsfrist an und laden über Zombie-EC2-Instances riesige Dateien hoch – oder sogar Inhalte, deren Besitz illegal ist.
Bei einem späteren Cost Review oder einer Anomalie-Erkennung entdecken Sie womöglich einen Bucket mit riesigen Mengen nicht löschbarer Daten, der Tausende bis Zehntausende Dollar pro Monat kostet – ohne jede Möglichkeit, ihn zu entfernen.
Wie löschen Sie also einen Bucket mit Objekten, die durch den Compliance Mode geschützt sind?
Gar nicht.
Der einzige Weg: den gesamten AWS-Account samt aller Ressourcen schließen – ein erheblicher Aufwand, gerade bei Produktivumgebungen.
Sie müssen Ihre gesamten Workloads in einen neuen AWS-Account migrieren – ein Prozess, der Wochen oder gar Monate dauern kann, vergleichbar mit einer kompletten Umgebungsmigration.
Wie blockieren Sie ihn?
Mit Resource Control Policies (RCP) – einer Funktion in AWS Organizations, mit der Sie Richtlinien über alle Accounts Ihrer Organisation hinweg (mit Ausnahme des Management-Accounts) für Ressourcen wie S3-Buckets durchsetzen.
Sie können eine Resource Policy erstellen, die jeden Versuch, Object Lock zu aktivieren, unterbindet (leider lässt sich das nicht auf den Compliance Mode beschränken). Versucht jemand, Object Lock zu aktivieren, erhält er einen Access-Denied-Fehler.
Profi-Tipp: Sie können auch nur bestimmten Nutzern (z. B. dem Security-Team) erlauben, die Einschränkung zu umgehen, während alle anderen blockiert bleiben. So behalten Sie die Kontrolle, ohne den Account unnötigen Risiken auszusetzen.
Hier ein Beispiel für eine RCP, die den Compliance Mode für bestehende und neue Buckets vollständig blockiert:
Ich habe die Policy angewendet, einen neuen Bucket angelegt – beim Versuch, den Compliance Mode zu aktivieren, erhielt ich folgende Fehlermeldung:
Fazit:
Wenn Sie langfristige finanzielle Schäden durch Fehlkonfigurationen oder unautorisierten Zugriff konsequent eindämmen wollen, empfehle ich dringend, diese Policy anzuwenden.
Übrigens ist der Compliance Mode nicht auf S3 beschränkt – es gibt ihn auch bei:
- EBS Snapshots – Backups von EC2-Volumes (Disks)
- AWS Backup Vault – dem AWS-Backup-Service
Je nach Risikoprofil sollten Sie auch dort eine Sperre in Betracht ziehen.
Weitere hilfreiche Ressourcen finden Sie unter doit.com/services – der nächste Schritt zu Ihrem Erfolg wartet bereits!