Das Sammeln und Speichern von Protokolldaten von virtuellen Maschinen und anderen Quellen in der AWS-Cloud-Umgebung der Deutschen Telekom ist nicht nur „Best Practice“, sondern auch eine strenge Sicherheitsanforderung. Sobald wir die Daten an Ort und Stelle haben, müssen wir eine weitere Anforderung erfüllen: Wie können wir sicher und rechtskonform auf die Daten zugreifen?
Als Protokollierungs- und Überwachungsteam von Deutsche Telekom ist Cloud Security für die sichere Erfassung und Speicherung der Logfiles von EC2-Instanzen wie Syslog-Protokollen und Windows-Systemprotokollen in der gesamten Cloud-Umgebung verantwortlich.
Logfiles unterliegen strengen Vorschriften. Der Zugriff auf eine solche Datei ist generell verboten.
Ist ein Lesezugriff erforderlich, zum Beispiel im Falle eines Audits oder einer Untersuchung, muss dieser über das Protokollierungs- und Überwachungsteam angefragt werden. Dieses leitet anschließend den sogenannten „Break Glass“-Prozess ein und ermöglicht so den Zugriff auf die in Buckets gespeicherten Logfiles.
Das Verfahren, das formal als „Break Glass“-Prozess bezeichnet wird, beinhaltet im Allgemeinen einen privilegierten Zugriff auf Daten. Um die Berechtigungen zu umgehen, muss ein definierter Prozess gestartet werden, nachfolgende Aktionen unterliegen verschiedenen Warn- und Kontrollmechanismen. Zudem müssen relevante Interessengruppen, zum Beispiel der Betriebsrat, jedes Mal, wenn dieser Prozess ausgelöst wird, per E-Mail benachrichtigt werden. Solche Daten unterliegen strengen Vorschriften. Der Zugriff darauf ist generell verboten.
Der Amazon Simple Storage Service (S3)-Bucket, der die vertraulichen Logdateien enthält, wurde gemäß Best Practices und Anforderungen erstellt, d. h. Versionierung, Verschlüsselung, WORM-Objektsperre (Write Once Read Many) im Kompatibilitätsmodus usw. beachtet.
Zudem wurde ihm eine Amazon S3-Bucket Richtlinie beigefügt, die angibt, wer Objekte unter welchen Bedingungen hochladen darf. Die Berechtigung dazu war auf die Prinzipien der DTIT AWS-Organisation beschränkt. Der Lesezugriff auf die Objekte wurde durch die Richtlinie in keiner Weise eingeschränkt.
Technisch gesehen konnte so jeder, der über ausreichende Berechtigungen für das AWS-Protokollierungskonto verfügte, Daten abrufen, ohne dass andere davon Kenntnis erhielten.
-data.png)
Übergeordnetes Architekturdiagramm der vorgeschlagenen Bucket Lösung:
Verbesserung der Sicherheit des S3 Buckets:
Die S3 Richtlinie wurde um eine Regel erweitert, die jede „getObject“-Aktion ablehnt, sofern diese nicht von einer bestimmten Rolle des Identity and Access Managements (IAM) angefordert wird. In Verbindung mit einer Service Control Policy (SCP) verhindert dies, dass Personen im Protokollierungskonto Daten abrufen können, selbst wenn sie über Administratorrechte verfügen.
Benutzeroberflächen-Schicht:
Zwei Servicekatalog-Elemente wurden im sogenannten Verwaltungskonto bereitgestellt. Diese führen den „Break Glass“-Prozess zum Öffnen oder Schließen des Datenzugriffs aus. Die Servicekatalog-Elemente werden von einer benutzerdefinierten Lambda-Ressource unterstützt. Diese ändert die oben genannte S3-Bucket Richtlinie mithilfe einer Vertrauensstellung im Protokollierungskonto. Dadurch können Nutzer die Datenzugriffsanforderungen einschließlich einer historischen Übersicht unkompliziert auszuführen.
Reaktive Schicht:
Die hinterlegte CloudWatch-Ereignisregel wird durch die Aufrufe PutBucketPolicy und PutBucketACL ausgelöst. Anschließend erfolgt eine Überprüfung der Bucket Richtlinie im API-Aufruf sowie eine Analyse der "statement ID" (SID) der ersten Anweisung. Schließlich sendet die Regel eine Benachrichtigung an ein SNS-Thema. Sie wird über einen Eingangstransformator geleitet, der eine E-Mail mit Informationen zu der auf den Bucket angewendeten S3 Richtlinie erstellt. Alle relevanten internen und externen Interessengruppen, wie der Betriebsrat und der Datenschutz- und Sicherheitsmanager, haben das SNS-Thema abonniert und werden so über jede Berechtigungsänderung im Bucket informiert.
Infrastrukturschicht:
Alle Ressourcen für die Protokollierungs- und Verwaltungskonten werden per „Infrastructure as Code“ als CloudFormation-Stapel bereitgestellt. Sie folgen, sowohl bei Berechtigungen als auch bei Vertrauensrichtlinien im Fall von IAM-Rollen, dem Least-Privilege-Prinzip.
Präventivschicht:
Ein benutzerdefinierter SCP wurde erstellt und an das Protokollierungskonto angehängt, um Manipulationen an den bereitgestellten Ressourcen und damit ein Durchbrechen des „Break Glass“ zu verhindern.
Überwachungsschicht:
Während der Implementierung wurde von dem Projekt zugewiesenen Datenschutz- und Sicherheitsmanagern eine zusätzliche Anforderung gestellt: Eine Steuerung zur Überwachung der Änderungen an der S3-Bucket-Richtlinie. Diese überprüft, dass nur eine der beiden vordefinierten „OpenAccess“- oder „ClosedAccess“-Richtlinien an den S3-Bucket angehängt ist. Stimmt die Richtlinie im PutBucketPolicy-API-Aufruf nicht mit den vordefinierten Richtlinien überein, wird die Standardrichtlinie „ClosedAccess“ verwendet. Dieser Vorgang läuft aktuell noch und gehört nicht zum Auftragsumfang von T-Systems.
Die Lösung ist vom zugewiesenen Datenschutz- und Sicherheitsmanager genehmigt und somit sicher. Sie ist benutzerfreundlich, weil auch nicht-technische Nutzer den „Break Glass“-Prozess verwenden können. Sie setzt auf nativen AWS-Diensten auf und ist damit problemlos erweiterbar und skalierbar. Da sie per „Infrastructure as Code“ mit Parametern erstellt wurde, lassen sich darüber zudem auch neue Buckets abdecken oder zusätzliche AWS-Konten einbinden.
