Cloud-Ressourcen mit vielen Berechtigungen werden häufig zum Ziel für Angreifer, die in kompromittierten Umgebungen mehr Privilegien und Zugriffe erlangen können. Die Angreifer verwenden verschiedene Privilegienausweitungen und andere Techniken, um weitere Angriffe ausführen zu können. Das Least-Privilege-Prinzip (Principle of Least Privilege, PoLP) sollte regelmäßig auf Ihre Ressourcen angewandt und geprüft werden. Dies ist von entscheidender Bedeutung, um Sicherheitsvorfälle und Verstöße im Zusammenhang mit zu weit gefassten Berechtigungen oder Zugriffsrechten zu verhindern.
PLP Generator Aufbau
Angesichts der Cyberbedrohung und der wachsenden Zahl von Anwendungen und Umgebungen in Unternehmen ist klar, dass die Definition von Least-Privilege-Berechtigungen automatisiert werden muss. Doch wie lässt sich dieses Prinzip der geringsten Privilegien effektiv implementieren?
Generierung der Richtlinien mit dem PLP-Generator
Hier bei T-Systems haben wir eine Lösung namens PLP-Generator entwickelt, eine Python-Anwendung, die Richtlinien nach dem PoLP oder Least-Privilege-Prinzip generiert. Sie verwendet AWS und eine GitLab-API für die Ende-zu-Ende-Verwaltung von IAM-Richtlinien (Identity and Access Management), d. h. ihre Generierung und regelmäßige Aktualisierungen. Die resultierenden Richtlinien werden dann an IAM-Rollen angehängt, die von Entwicklungsteams in der IT-Abteilung zum Bereitstellen ihres Codes verwendet werden. Die Anwendung wird regelmäßig ausgeführt, durchläuft die Rollen und führt den Richtliniengenerierungs- und Verfeinerungsprozess aus.
Der PLP-Generator lässt sich am besten bei Projekten von mittlerer Größe einsetzen. Solche Projekte sollten ein Identitäts- und Sicherheitsteam umfassen, das für die Verwaltung der von den CI/CD-Pipelines verwendeten IAM-Rollen und die Definition ihrer Berechtigungen verantwortlich ist.
Im Folgenden sehen Sie, wie wir den Prozess mit gängigen DevOps-Tools wie GitLab und Terraform und sicherheitsbezogenen AWS-Services wie AWS Organizations, CloudTrail und dem AWS IAM Access Analyzer implementieren konnten.
Das Projekt besteht aus mehreren Anwendungen mit jeweils zahlreichen SDLC-Phasen (Software Development Lifecycle). Ein separates AWS-Konto repräsentiert jeden SDLC gemäß den Best Practices von AWS für die Organisation von Workloads. Einige Workloads teilen sich jedoch ein AWS-Konto für dieselbe SDLC-Phase.
Die Softwareingenieure, die die Anwendungen entwickeln, verwenden GitLab zum Hosten ihres Codes und ihrer CI/CD-Pipelines (Continuous Integration/Continuous Deployment). Diese stellen dann die resultierenden Artefakte auf AWS bereit.
Ein separater Unterordner (eine Terraform-Konfiguration) in einem Git-Repository repräsentiert jede Anwendung. Der Unterordner definiert Bereitstellungs-IAM-Rollen für jede SDLC-Anwendungsphase. Die Terraform-Ausgaben für eine bestimmte Anwendung umfassen Umgebungen, die zum Generieren der Richtlinien bestimmt sind.
Diese Struktur ermöglicht den Ausschluss von Sandbox-Umgebungen, die oft als Spielplatz für Entwickler dienen; Berechtigungen, die dort verwendet werden, würden in einer höheren Umgebung mit anderen Usern keinen Sinn ergeben. Umgekehrt ist es nicht erforderlich, dass alle Umgebungen die durch den Prozess generierte Richtlinie verwenden. Manche können mehr Freiheiten zulassen.
Kernkomponente der Automatisierung ist der IAM Access Analyzer Service von AWS. Damit er ordnungsgemäß funktioniert, muss CloudTrail auf dem Zielkonto aktiviert sein. CloudTrail ist ein AWS-Service, der von AWS IAM-Entitäten durchgeführte Aktionen aufzeichnet und sie an einem sicheren Ort speichert. Gemäß bewährten Sicherheitsverfahren wird der resultierende S3-Bucket mit CloudTrail-Daten in einem separaten Archivkonto bereitgestellt, das nur für diesen Zweck bestimmt ist, und mit einem KMS-Schlüssel verschlüsselt.
Die Access Analyzer Service-Rollen werden in jedem AWS-Konto in der Organisation bereitgestellt. Sie haben gerade genug Berechtigungen, um auf die CloudTrail-Daten zuzugreifen und die Least-Privilege-Richtlinien zu generieren.
Die in jedem Konto bereitgestellten IAM Management-Rollen erstellen die eigentlichen Bereitstellungsrollen und können ihre Zugriffsrechte beziehungsweise Berechtigungen anpassen. Zunächst wird jede Bereitstellungsrolle mit umfassenderen Berechtigungen initialisiert, die dann basierend auf ihrer vorherigen Aktivität mit der hier beschriebenen Lösung reduziert werden.
Die CI/CD-Pipelines der Entwickler verwenden die Bereitstellungsrollen, um die tatsächlichen Workloads für die AWS-Zielkonten bereitzustellen.
Erstellen einer Zusammenführungsanfrage mit unserem PLP-Generator
Für jede Anwendung und Umgebung im Geltungsbereich ruft die Anwendung die AWS IAM Access Analyzer-API im entsprechenden AWS-Konto auf, um die neuesten IAM-Berechtigungen für die angegebene IAM-Bereitstellungsrolle basierend auf ihrer Aktivität in den letzten sieben Tagen anzufordern.
Die zurückgeschickten Daten bestehen aus zwei Teilen. Ein Teil sind die sogenannten „Last accessed“-Daten, die ohne weitere Details nur angeben, welche AWS-Dienste verwendet wurden.
Der andere Teil der zurückgeschickten Antwort ist detaillierter und enthält umfangreiche Informationen auf Aktionsebene für jeden Dienst. Diese Funktion ist nicht für alle Dienste verfügbar, aber die Liste der unterstützten Dienste enthält einige der am häufigsten verwendeten.
Nach dem Parsen und Verarbeiten der Daten für die IAM-Rollen im Repository und dem Zusammenführen der Daten mit den vorhandenen generierten Richtlinien (falls vorhanden), erstellt der PLP-Generator einen Merge Request. Dies sind die neuen Berechtigungen, die seit der letzten Generation hinzugefügt wurden und werden einem Mitglied des Sicherheitsteams zugewiesen.
Der Merge Request wird als „Entwurf“ gekennzeichnet, wodurch die automatische Zusammenführung verhindert wird. Stattdessen muss ein Mitglied des Sicherheitsteams die neu hinzugefügten Berechtigungen einmal manuell überprüfen und entweder zusammenführen oder verwerfen.
Wenn ein Merge Request genehmigt wird, löst er die CI/CD-Pipeline aus und führt den Befehl „Terraform plan“ für die vorhandene Infrastruktur aus. Er zeigt die Unterschiede erneut an und wartet auf eine weitere Zustimmung durch den menschlichen User, bevor er den Befehl „Terraform apply“ ausführt.
Abgesehen von den manuellen Überprüfungen und Genehmigungen ist die Lösung vollständig automatisiert und nach der Einrichtung wartungsfrei.
Die Lösung umfasst zwei Sicherheitsvorkehrungen, um zu verhindern, dass den Bereitstellungsrollen mehr Berechtigungen als nötig zugewiesen werden – den Merge Request, der überprüft und zusammengeführt werden muss, und den Schritt „Terraform apply“, der die Berechtigungen auf AWS ändert und manuell genehmigt werden muss.
Die Sicherheitsingenieure können:
Vor allem aber ermöglicht unsere Lösung regelmäßige Überprüfungen durch Sicherheitsingenieure, was für die IT-Security wichtig ist. Sie bietet gerade genug Berechtigungen für die CI/CD-Pipelines der Entwickler, damit alles funktioniert und die Abläufe nicht mit „Zugriff verweigert“-Fehlern gestört werden. Sie gewährleistet auch die Einhaltung hoher Sicherheitsstandards in höheren Umgebungen. Durch die automatische Anwendung des Principle of Least Privilege (PoLP) wird in der IT-Umgebung ein angemessener Sicherheitsstatus beibehalten. Zusammen mit anderen Maßnahmen trägt dieser Ansatz dazu bei, Sicherheitsvorfälle zu verhindern und die IT-Infrastruktur zu schützen.
