Rawpixel.com - stock.adobe.com
DevOps-Tools und -Zugangsdaten zuverlässig absichern
DevOps erweitern die Angriffsfläche für Cyberattacken bei Unternehmen deutlich. Mit wenigen grundlegenden Kontrollmaßnahmen lassen sich die Sicherheitsrisiken minimieren.
Egal, aus welcher Branche, Unternehmen nutzen verstärkt DevOps-Modelle, um die Digitale Transformation voranzutreiben und die Business-Performance zu verbessern. Die Sicherheit darf dabei allerdings nicht auf der Strecke bleiben. Schon mit vier grundlegenden Kontrollmaßnahmen können Unternehmen DevOps-immanente Sicherheitsrisiken deutlich minimieren.
Nach wie vor vernachlässigen Unternehmen bei DevOps-Implementierungen die Sicherheit – ein fataler Fehler, denn gerade durch DevOps erweitert sich die Angriffsfläche für Cyberattacken erheblich, allein schon, weil mehr privilegierte Accounts und Zugangsdaten generiert und über vernetzte Systeme hinweg geteilt werden. Zu solchen – bisher vielfach nur unzureichend berücksichtigten und gesicherten – Zugangsdaten gehören etwa Service-Accounts, Encryption-, API- und SSH-Keys, Secrets von Containern oder eingebettete Passwörter in Programm-Code, der häufig auch in zentralen oder gar öffentlich zugänglichen Repositories liegt. In der Hand eines externen Angreifers oder auch böswilligen Insiders stellen diese privilegierten vertraulichen Zugangsdaten eine erhebliche Gefahr dar, da sie eine vollständige Kontrolle über die gesamte IT-Infrastruktur eines Unternehmens ermöglichen können.
Gemeinsam mit Entwicklungs- und Produktionsumgebungen müssen deshalb auch die DevOps-Tools selbst und ihre Zugangsdaten gesichert werden. Elementare Sicherheitsmaßnahmen betreffen die Bereiche Tool-Auswahl und -Konfiguration, Kontrolle des Zugriffs, Least Privilege sowie Code Repositories.
Tool-Auswahl und -Konfiguration
Zunächst muss ein Unternehmen die verwendeten DevOps-Tools, einschließlich der Open-Source-Tools, ermitteln und in einer detaillierten Evaluierung mögliche Sicherheitsmängel identifizieren; dabei ist insbesondere zu überprüfen, ob alle Tools den Sicherheitsstandards des Unternehmens entsprechen.
Bei dieser Bewertung und auch bei der Tool-Auswahl und der Festlegung von Unternehmensstandards für Konfiguration und Nutzung muss das Security-Team involviert sein. Es hat zu gewährleisten, dass alle DevOps-Tools sicher konfiguriert sind, keine unsicheren Standardkonfigurationen verwenden und immer auf dem neuesten Stand gehalten werden.
Kontrolle des Zugriffs
Ein Unternehmen muss sicherstellen, dass die Anmeldeinformationen für die Cloud-Management-Konsole und den Zugriff auf die DevOps-Tools in einem verschlüsselten Datenspeicher (Vault) abgelegt werden und dass ihre Verwendung protokolliert und überwacht wird. Für den Zugriff auf die Tools sollte eine Multifaktor-Authentifizierung verpflichtend sein.
Auf jeden Fall muss ein Unternehmen den Zugang zu hochriskanten Befehlen innerhalb der DevOps-Tools beschränken. Zum Beispiel führen Docker-Anwender einen Container oft mit dem Flag -privileged aus, dass ihm einen direkten Zugriff auf Host-Komponenten bietet. Der Betrieb eines Containers mit diesem Flag sollte aber im Allgemeinen unterbunden werden. Falls es doch nötig ist, muss der Benutzerzugriff stark reglementiert und überwacht werden; auch die Protokollierung aller Aktivitäten mit dem Flag -privileged ist dann zu empfehlen.
Nicht zuletzt sollten alle unnötigen Konten mit Zugriff auf DevOps-Tools entfernt werden, etwa Konten von Entwicklern, die eine neue Funktion haben, gegenwärtig keinen Zugriff auf Tools benötigen oder das Unternehmen bereits verlassen haben. Für vorhandene Konten ist eine Rezertifizierung durchzuführen.
Least Privilege
Die Zugriffsrechte von Benutzern auf DevOps-Tools müssen im Rahmen eines Least-Privilege-Konzepts auf das für die jeweilige Rolle erforderliche Minimum beschränkt werden. Zudem sollte für bestimmte Tätigkeiten eine doppelte Autorisierung zwingend vorgeschrieben sein. So könnte beispielsweise festgelegt werden, dass eine Änderung an einer Puppet-Manifest-Datei von einer zweiten Person überprüft und freigegeben werden muss, bevor sie live geht.
„Eine Best-Practice-Strategie für Security erfordert immer die ganzheitliche Adressierung von Sicherheitsherausforderungen und potenziellen Sicherheitslücken – und auch der DevOps-Bereich darf hier keine Ausnahme bilden“
Michael Kleist, Cyberark
Darüber hinaus sollte es im Hinblick auf die Verwendung von Continuous Integration (CI) und Continuous Delivery (CD) Tools eine strikte Separation of Duties geben. Vor allem Tools für die Build-Automatisierung wie Jenkins sind oft „überprivilegiert“. So ist es üblich, einen Jenkins-Master für alle Aufgaben einzurichten, das heißt für Building, Testing und Packaging aller Applikationen.
Stattdessen sollte aber eine Separation of Duties durch Implementierung mehrerer Jenkins-Nodes realisiert werden, die jeweils einer bestimmten Funktion – zum Beispiel Build oder Test – für jede Anwendung zugeordnet sind. Wenn jeder Knoten eine eindeutige Identität und eine begrenzte Anzahl von Berechtigungen hat, werden auch die Gefahren durch eine potenzielle Kompromittierung deutlich reduziert.
Code Repositories
Unerlässlich ist die Konzeption risikobasierter Richtlinien für Entwickler rund um die Verwendung von Code Repositories, denn neben Zugangsdaten kann ein Code auch Details über das interne Netzwerk des Unternehmens enthalten, die für Cyberangreifer nützlich sein könnten. Falls es ohne Beeinträchtigung des Workflows möglich ist, sollte ein On-Premises- und kein Cloud-basiertes Code Repository genutzt werden. Auf jeden Fall ist aber die Nutzung eines automatisierten Scanning-Verfahrens empfehlenswert, um sicherzustellen, dass Codes keine Secrets enthalten.
Eine Best-Practice-Strategie für Security erfordert immer die ganzheitliche Adressierung von Sicherheitsherausforderungen und potenziellen Sicherheitslücken – und auch der DevOps-Bereich darf hier keine Ausnahme bilden. Ohne eine zuverlässige Sicherung der administrativen Konsolen für DevOps-Tools und Cloud-Dienste sowie der Zugangsdaten, die in Skripten für die Automatisierung der CI- und CD-Pipeline und der DevOps-Tools genutzt werden, ist ein Unternehmen für jeden potenziellen Angreifer eine relativ leichte Beute.
Über den Autor:
Michael Kleist ist Regional Director DACH bei CyberArk.
