Amazon-S3-Sicherheit und Compliance auf AWS verstehen
10. Mai 2019
0 Min. LesezeitAnmerkung der Redaktion
Dieser Blogbeitrag erschien ursprünglich auf fugue.co. Fugue wurde 2022 Teil von Snyk und ist ein wichtiger Bestandteil von Snyk IaC.
Wenn Ihr Unternehmen Amazon Web Services (AWS) für Cloud-Computing nutzt, kommt wahrscheinlich auch Amazon S3, der Amazon Simple Storage Service, häufig zum Einsatz. Der Objektspeicherdienst gehörte zu den ersten Cloud-Diensten von AWS (bereits 2006!), und seine einfache Bedienung, Zuverlässigkeit und Skalierbarkeit haben ihn äußerst beliebt gemacht.
Eine fehlerhafte Konfiguration Ihrer S3-Ressourcen kann jedoch zu schwerwiegenden Sicherheits- und Compliance-Vorfällen führen. Öffentlichkeitswirksame Datenschutzverletzungen infolge falsch konfigurierter S3-Ressourcen sorgen immer wieder für Schlagzeilen – und weitere werden folgen. Schon eine falsch konfigurierte Zugriffsrichtlinie oder Verschlüsselungseinstellung für einen S3-„Bucket“ kann dazu führen, dass sensible Daten in die Hände von Angreifern gelangen.
Unabhängig davon, wie die Schlagzeile lautet: In jedem dieser Fälle war der Cloud-Kunde verantwortlich, nicht AWS. AWS erfüllt seinen Teil des Modells der geteilten Verantwortung für Cloud-Sicherheit vorbildlich. Das Unternehmen kann Sie jedoch nicht davon abhalten, sich mit Ihrer S3-Konfiguration selbst zu schaden und Ihr Unternehmen in die Schlagzeilen zu bringen.
Compliance bestimmt wahrscheinlich Ihre Amazon-S3-Nutzung
Wenn Ihr Unternehmen einem Compliance-Regelwerk wie HIPAA, PCI, SOC 2, DSGVO oder NIST 800-53 unterliegt, sollten Sie wissen, dass sie alle Kontrollen für die Nutzung und Konfiguration von S3 (und vielen anderen AWS-Diensten, die Ihr Unternehmen wahrscheinlich nutzt) enthalten. Falls keines dieser Regelwerke für Ihr Unternehmen oder Ihre Workloads gilt, sollten Sie den AWS CIS Benchmark in Betracht ziehen, um die sichere Nutzung von AWS zu unterstützen.
Kontrollieren Sie den Zugriff auf Ihre Amazon-S3-Buckets
Viele Datenschutzverletzungen im Zusammenhang mit S3 sind auf falsch konfigurierte Zugriffsrichtlinien zurückzuführen. Wenn ein neuer S3-Bucket erstellt wird, ist die standardmäßige Zugriffsrichtlinie auf „privat“ gesetzt. Diese Einstellung kann sich im Laufe der Zeit jedoch ändern – und tut es häufig auch. Cloud-Umgebungen verändern sich, wenn Entwickler Anwendungen und Infrastruktur aktualisieren und neue Dienste hinzufügen. Dabei können Zugriffsrichtlinien unbeabsichtigt gelockert oder deaktiviert werden.
Überprüfen Sie Ihre S3-Ressourcen und deren Zugriffsrichtlinien, um sicherzustellen, dass sie sicher konfiguriert sind. Verfolgen Sie Änderungen an diesen Konfigurationen mit CloudTrail. Für S3-Buckets mit sensiblen Daten empfiehlt sich ein Produkt wie Fugue, das Abweichungen von Ihrer festgelegten, sicheren Konfigurationsbaseline ohne zusätzlichen Code oder Skripte erkennt und beheben kann.
Der AWS CIS Benchmark ist ein gutes Beispiel für ein Compliance-Framework, das die S3-Konfiguration und -Nutzung regelt. CIS 2.6 verlangt, dass die Bucket-Zugriffsprotokollierung aktiviert ist. CIS 3.8 schreibt vor, für alle Änderungen an Bucket-Richtlinien einen Protokollmetrikenfilter und einen Alarm zu aktivieren. Stellen Sie außerdem sicher, dass Ihre S3-Buckets mit sensiblen Daten nicht öffentlich zugänglich sind. Erstellen Sie stattdessen eine AWS-IAM-Richtlinie, die nur autorisierten Benutzern den Zugriff auf den Bucket erlaubt.
Schützen Sie Ihre Amazon-S3-Daten durch Verschlüsselung
Sichere Zugriffsrichtlinien für Ihre Amazon-S3-Ressourcen sind unverzichtbar. Sie müssen aber auch sicherstellen, dass die Verschlüsselung stets aktiviert ist, damit niemand mit unbefugtem Zugriff die Daten lesen kann. Überprüfen Sie erneut Ihre S3-Ressourcen, um sicherzustellen, dass die Verschlüsselung aktiviert ist, und nutzen Sie Protokolle, um Änderungen an diesen Ressourcen nachzuverfolgen – auch Fälle, in denen die Verschlüsselung deaktiviert wird.
Auch hier dürfte Ihr Compliance-Framework relevant sein. Zwei Beispiele: NIST 800-53 SC-13: Cryptographic Protection verlangt von Unternehmen, bei Bedarf Verschlüsselung einzusetzen. SOC 2 CC 6.1 verlangt, dass die Verschlüsselung weitere Maßnahmen zum Schutz gespeicherter Daten ergänzt.
Sie sind für AWS-Sicherheit und Compliance verantwortlich!
Auch wenn jedes Unternehmen anders ist, liegt die Verantwortung für den Schutz kritischer Daten auf AWS in der Regel bei einem Cloud-Security-Engineer, DevOps-Engineer, Compliance-Analysten oder Cloud-Architekten. Manchmal teilen sich einige oder alle diese Rollen die Verantwortung für die Cloud-Sicherheit. Das erfordert eine effektive Zusammenarbeit, die oft als „DevSecOps“ bezeichnet wird.
Unabhängig von Ihrer Rolle oder Position: Wenn Sie für die Sicherheit und Compliance Ihrer AWS-Umgebung verantwortlich sind, gehört es zu Ihren wichtigsten Aufgaben, sicherzustellen, dass kritische S3-Ressourcen korrekt konfiguriert sind und während ihrer gesamten Lebensdauer korrekt konfiguriert bleiben.
Aufgabe Nr. 1: Sicherstellen, dass Ihre S3-Konfigurationen den Richtlinien entsprechen
Falls noch nicht geschehen, müssen Sie sicherstellen, dass die Konfiguration Ihrer vorhandenen S3-Ressourcen in Ihrer AWS-Umgebung den geltenden Compliance- und Sicherheitsrichtlinien entspricht. Dazu gehört in der Regel eine Prüfung der Konfiguration Ihrer S3-Ressourcen – manuell über die AWS Console oder mithilfe eines Audit-Tools.
Sie sollten alle Ihre AWS-Umgebungen regelmäßig und häufig überprüfen. Kritische Ressourcen sollten Sie kontinuierlich mit einem Tool prüfen, das Ressourcen scannt, ihre Konfiguration anhand von Richtlinien validiert und Verstöße sowie Ihre allgemeine Sicherheitslage meldet. Achten Sie darauf, Abweichungen von der ursprünglichen S3-Konfiguration zu erkennen, damit Sie feststellen können, ob die Änderung gegen Richtlinien verstößt.
Arbeiten Sie außerdem eng mit Ihren Anwendungs- und DevOps-Teams zusammen, um sicherzustellen, dass ihre Maßnahmen (z. B. das Bereitstellen neuer oder Aktualisieren bestehender Umgebungen) den einschlägigen Richtlinien entsprechen. Da dies meist ein zeitaufwendiger und fehleranfälliger manueller Prozess ist, sollte Ihr Team Möglichkeiten suchen, Sicherheitsprüfungen nach links zu verlagern und Richtlinienprüfungen früher in den Softwareentwicklungszyklus (SDLC) einzubauen. So lassen sich Korrekturen einfacher, schneller und kostengünstiger vornehmen.
Aufgabe Nr. 2: Fehlkonfigurationen von Amazon S3 erkennen und beheben
Sie haben also bestätigt, dass Ihre AWS-S3-Ressourcen den Richtlinien entsprechen und sicher konfiguriert sind. Großartig! Jetzt kommt der schwierige Teil: sicherzustellen, dass das auch so bleibt.
Konfigurationsabweichungen bei Cloud-Infrastrukturressourcen sind weit verbreitet und bergen oft Risiken. S3-Bucket-Konfigurationen lassen sich über die AWS Console und eine Application Programming Interface (API) ändern, die mit verschiedenen zusätzlichen Automatisierungstools genutzt werden kann. Wahrscheinlich werden Sie feststellen, dass sich S3-Konfigurationen (wie auch die vieler anderer AWS-Dienste) häufig ändern. Dadurch können sie gegen Compliance-Vorgaben verstoßen und Sicherheitslücken entstehen.
Sie benötigen ein Tool, das Ihre AWS-Umgebung scannt und Sie bei Verstößen gegen S3-Konfigurationsrichtlinien alarmiert. Sie sollten Warnungen für S3-Buckets ignorieren können, die absichtlich öffentlich zugänglich sind (z. B. für statische Websites), während Fehlkonfigurationen bei Buckets erkannt werden, die privat und verschlüsselt sein sollten. Warnmeldungen sollten genügend Informationen zur Fehlkonfiguration enthalten, um die manuelle Behebung zu erleichtern.
Bei kritischen S3-Buckets mit sensiblen Daten müssen Sie manuelle Prozesse hinter sich lassen und Fehlkonfigurationen automatisch beheben, sobald sie auftreten. Mit manuellen Verfahren lässt sich die mittlere Zeit bis zur Behebung (MTTR) kritischer Fehlkonfigurationen nicht auf ein sicheres Maß reduzieren, denn auch die Bedrohungen, die Schwachstellen in der Cloud-Infrastruktur wie falsch konfigurierte S3-Buckets ausnutzen, sind automatisiert. Mit der Zeit werden Sie feststellen, dass automatische Behebungen viel Zeit sparen und sich auch für weitere Cloud-Ressourcen einsetzen lassen.
AWS-Fehlkonfigurationen automatisch beheben
Eine effiziente und umfassende Methode zur automatischen Behebung von AWS-Fehlkonfigurationen besteht darin, mithilfe von Baselines eine selbstheilende AWS-Infrastruktur für Ihre kritischen Ressourcen aufzubauen. Bei diesem Ansatz legen Sie eine bekannte, korrekte Infrastrukturbaseline fest, die den Richtlinien entspricht. Sobald sie eingerichtet ist, erkennen und überprüfen Sie alle Abweichungen von der Baseline. Bei kritischen Ressourcen sollten Sie Abweichungen automatisch auf die festgelegte Baseline zurücksetzen. Baselines machen es überflüssig, mögliche Fehler vorherzusagen und Sperrlisten zu erstellen. Außerdem ermöglichen sie, Sicherheit und Compliance nach links zu verlagern.
Fugue ermöglicht eine selbstheilende Cloud-Infrastruktur. In unserem Webinar erfahren Sie mehr.
Aufgabe Nr. 3: AWS-S3-Fehlkonfigurationen melden
Zusätzlich zu regelmäßigen Compliance- und Sicherheitsprüfberichten verlangen die meisten Unternehmen einen Bericht zu jeder Fehlkonfiguration einer kritischen Ressource wie Amazon S3. Diese Berichte müssen üblicherweise folgende Informationen enthalten:
Welche Ressource war betroffen (und in welcher Umgebung)?
Welche Konfiguration wurde geändert?
Wann ist die Fehlkonfiguration aufgetreten?
Wer war für die Fehlkonfiguration verantwortlich?
Welche Richtlinie wurde gegebenenfalls durch die Fehlkonfiguration verletzt?
Wann wurde die Fehlkonfiguration erkannt?
Wann wurde die Fehlkonfiguration behoben (und die Behebung überprüft)?
Wer hat die Fehlkonfiguration behoben (oder wie wurde sie behoben)?
Welche Maßnahmen werden ergriffen, damit sich solche Fehlkonfigurationen nicht wiederholen?
Für einen solchen Bericht müssen Sie viele Protokolldaten zusammentragen – auch hier kann Automatisierung helfen. Die letzte Anforderung lässt sich nur mit automatischer Behebung erfüllen: Sie verhindert, dass solche Fehlkonfigurationen erneut auftreten.
Messen Sie die mittlere Zeit bis zur Behebung (MTTR) von Fehlkonfigurationen bei kritischen Cloud-Ressourcen, um die Widerstandsfähigkeit Ihrer Cloud-Sicherheitsmaßnahmen zu verfolgen. Angesichts der automatisierten Bedrohungen, die solche Fehlkonfigurationen ausnutzen wollen, ist eine MTTR von vielen Stunden oder Tagen mit einem inakzeptablen Risiko verbunden.
Noch etwas …
Wenn Sie Cloud-Umgebungen in großem Maßstab betreiben und Ihnen die Sicherheit und Compliance Ihrer Cloud-Infrastruktur wichtig sind, kann Fugue Sie unterstützen. Mit Fugue können Sie:
Überprüfen Sie die Compliance Ihrer Cloud-Umgebungen anhand verschiedener Richtlinien-Frameworks wie HIPAA, PCI, SOC 2, NIST 800-53, ISO 27001 und DSGVO.
vollständige Transparenz über Ihre Cloud-Umgebungen erhalten – mit Konfigurationsbaselines für die Cloud-Infrastruktur und der Erkennung von Abweichungen.
Fehlkonfigurationen der Cloud-Infrastruktur verhindern und sich mit einer selbstheilenden Infrastruktur vor Sicherheitsvorfällen und Compliance-Verstößen schützen.
Sicherheit und Compliance Ihrer Cloud-Infrastruktur nach links verlagern – mit CI/CD-Integration, damit Ihre Entwickler schnell und sicher arbeiten können.
kontinuierliche Einblicke in die Compliance und entsprechende Berichte erhalten – für Ihre gesamte Cloud-Infrastruktur im Unternehmen.
IaC-Sicherheit für Entwickler
Snyk schützt Ihre Infrastructure as Code vom SDLC bis zur Laufzeit in der Cloud mit einer einheitlichen Policy-as-Code-Engine, damit jedes Team sicher entwickeln, bereitstellen und betreiben kann.
