Modernes Secrets-Management

Daniel Bornkessel

Am 17. Juni 2014 wurde die Firma Code Spaces [1] Opfer einer Hacker-Attacke. Dem Unternehmen, das selbst mit Sicherheit und Stabilität warb, fehlte nach 12 Stunden jegliche Existenzgrundlage: Hacker hatten Zugriff auf die zentrale AWS-Console und löschten alle Daten und Backups der Kunden. Eine Wiederherstellung war mit vertretbarem Aufwand nicht möglich. Code Spaces musste den Betrieb einstellen. Die Ursache: Fehlendes Secrets Management.

Einleitung

Haben Sie aktuell geheime Anmeldedaten für eine Produktionsumgebung auf Ihrem Computer gespeichert? Dies können Konfigurationsdateien mit Datenbankpasswörtern, eine AWS-Credentials-Datei oder ein unverschlüsselter SSH-Schlüssel sein. Entwickler oder Administratoren, die häufig mit Produktivsystemen interagieren, werden diese Frage sehr wahrscheinlich mit einem „Ja” beantworten oder in einer Umgebung mit sehr strengen Regularien und Prozessen arbeiten.

Secrets-Management

Secrets-Management beschreibt Strategien, wie mit Secrets, also Geheimnissen, umgegangen werden soll. Mit Geheimnissen sind nicht Kreditkartennummern gemeint, die verschlüsselt abgespeichert werden müssen, sondern Passwörter, Schlüssel oder Zertifikate, die beispielsweise zum Verschlüsseln von Daten genutzt werden.

Secrets-Management ist Teil der IT-Sicherheitsstrategie und beschäftigt sich, im Gegensatz zu Konzepten wie Firewalls, VPNs usw., mit Bedrohungen, die von innerhalb des Unternehmens kommen. Dies können zum Beispiel frustrierte Mitarbeiter sein, die der Firma böswillig Schaden zufügen, oder Flüchtigkeitsfehler im Umgang mit Secrets. Laut Rashmi Jha, Program Manager bei Microsoft, sind 80 Prozent der Datenlecks auf vermeidbare Fehler von Personen zurückzuführen, die verantwortlich für das Managen von Geheimnissen sind [2].

Traditionell werden Secrets von einer möglichst kleinen Personengruppe, in der Regel Administratoren, verwaltet und für Applikationen auf Servern bereitgestellt. Diese Strategie funktioniert mit klassisch ausgelieferten Monolithen gut. Werden diese allerdings durch viele, kontinuierlich ausgerollte Microservices ersetzt, skaliert diese Art des Secrets-Managements nicht mehr. Dies hat unter anderem folgende Gründe:

• Mit der Anzahl von Services steigt die Anzahl der Geheimnisse. Statt einer Datenbank für den Monolithen werden beispielsweise mehrere Datenbanken für die jeweiligen Microservices benötigt.
• Neue, agile Arbeitsformen streben ein DevOps-Modell an, bei dem Entwickler klassische Administratoren-Aufgaben automatisieren.

Die optimale Implementierung einer modernen Microservice-Architektur soll Entwicklern einen möglichst hohen Freiheitsgrad bieten und gleichzeitig mindestens so sicher sein wie bisher.

Unternehmen, die nicht in Secrets-Management investieren, müssen zumeist einen der folgenden Kompromisse eingehen:

• Beschneidung der Flexibilität: Einige Rechte (Datenbanken anlegen, API-Keys für externe Services bereitstellen usw.) sind weiterhin einem sehr kleinen Personenkreis vorbehalten. Das System wird systematisch so beschnitten, dass Entwickler keinen Zugriff auf Produktionsgeheimnisse bekommen können. Die Folge sind geringe Flexibilität für die Entwickler, langsame Prozesse und weiterhin die Abhängigkeit von einer kleinen Personengruppe.
• Verringern der Sicherheit: Die Personengruppe, die Zugriff auf Produktions-Secrets hat, wird vergrößert, und man hofft, dass schon alles gut geht.

Da modernes, automatisiertes Secrets-Management noch ein relativ neues Themengebiet ist, entscheiden sich zur Zeit viele Unternehmen für einen dieser beiden Kompromisse. Große Unternehmen, die eine Prozesskultur und Ticket-Systeme haben, beschneiden häufiger die Flexibilität, kleinere Firmen erweitern eher die Rechte der Entwickler.

Gutes Secrets-Management

Die Strategien eines guten Secrets-Managements sind weder neu noch unbekannt, dennoch werden diese bisher kaum oder nur manuell umgesetzt. Gutes Secrets-Management deckt unter anderem folgende Best Practices ab:

• Das Secrets-Management ist in einem zentralen Service automatisiert.
• Jede App und jeder Entwickler bekommt nur Zugriff auf die Geheimnisse, die sie wirklich benötigen.
• Alle Secrets werden ausschließlich verschlüsselt abgespeichert.
• Geheimnisse haben eine zeitlich begrenzte Gültigkeit.
• Jede Interaktion mit dem Secrets-Management wird aufgezeichnet und kann im Nachhinein überprüft werden.

Aktuelle Lösungen für Secrets-Management

Wer nach Lösungen für Secrets-Management sucht, wird sehr wahrscheinlich auf HashiCorps Vault stoßen, die zur Zeit umfassendste und ausgereifteste Lösung. Alternativen sind entweder an ein Framework oder eine Umgebung gebunden (AWS Secrets Manager, CloudFoundry CredHub) und/oder verfügen über einen deutlich geringeren Funktionsumfang (Keywhiz). Alle erwähnten Lösungen haben interessante Konzepte implementiert, von denen hier einige näher betrachtet werden. Tabelle 1 fasst die Informationen zusammen.

Generelle Funktionsweise

Vault, AWS Secrets Manager, CredHub und Keywhiz speichern Secrets zentral ab und stellen eine REST-Schnittstelle zur Interaktion zur Verfügung. Aus Entwickler- und Applikationssicht erfüllen Secrets-Management-Systeme die Aufgabe, Secrets bereitzustellen, sofern eine Berechtigung zum Lesen vorhanden ist (s. Abb. 1).

Authentifizierung von Nutzern

Bei der Authentifizierung bestehen für Nutzer und Applikationen verschiedene Anforderungen. Für Nutzer ist es vorteilhaft, wenn eine schon existierende Nutzerverwaltung wie LDAP, Active Directory oder IAM genutzt werden kann. Dies macht das Aufbauen einer neuen Nutzerverwaltung für den Secrets-Manager überflüssig. Vault und der AWS Secrets Manager bieten hier eine Vielzahl von Möglichkeiten an. CredHub nutzt die integrierte CloudFoundry-Nutzerverwaltung und Keywhiz kann zusammen mit LDAP genutzt werden. Berechtigungen, welche Secrets gesetzt, gelesen oder gelöscht werden können, sind jeweils davon abhängig, welcher User sich authentifiziert oder zu welcher Gruppe der User gehört.

Alle Systeme, mit Ausnahme des AWS Secrets Managers, bieten außerdem die Möglichkeit, eine eigene Nutzerdatenbank anzulegen. Bei Vault und Keywhiz erhält der Nutzer nach der Autorisierung einen Token, der bei nachfolgenden Anfragen mitgeschickt werden muss (s. Abb. 2). Bei den anderen Lösungen werden die Requests entweder signiert (AWS), oder Tokens beziehungsweise Zertifikate werden bei jedem Request zur Authentifizierung und Autorisierung mitgeschickt.

Authentifizierung von Applikationen

Für Applikationen ist das Ziel, möglichst keine Geheimnisse in einem Versionsverwaltungssystem speichern zu müssen. Idealerweise wird eine App ausgerollt und bekommt auf „magische Art“ alle nötigen Secrets wie Datenbank-Passwörter, API-Keys oder Zertifikate. Müssten Applikationen Anmeldedaten für das Secrets-Management-System mitbringen, wäre ein Satz von Secrets durch einen anderen getauscht worden. Dies würde in etwa dem Prinzip eines Passwortmanagers entsprechen. Das Grundproblem der Übergabe von Passwörtern an Applikationen wäre hierdurch aber nicht gelöst.

Eine mögliche Lösung ist, nötige Anmeldedaten für den Secrets-Manager in der Laufzeitumgebung bereitzustellen. Bei AWS ist dies zum Beispiel über Instance-Profile [3] möglich: Die Rechte, mit dem Secrets-Manager zu sprechen, sind davon abhängig, welche Rolle die EC2-Instanz besitzt, auf der die Applikation läuft.

Vault bietet mehrere Möglichkeiten zur Authentifizierung von Applikationen. Bei Kubernetes können sich Applikationen beispielsweise mit dem Token des Kubernetes-Service-Accounts gegen Vault authentifizieren. Dieser Token ist in jedem Kubernetes-Container unter einem definierten Pfad verfüg- und auslesbar und ermöglicht eine Authentifizierung gegen die Kubernetes-Programmierschnittstelle (s. Abb. 3). Ähnliche Lösungen sind bei Vault auch für andere Umgebungen verfügbar (AWS, Google Cloud und mehr).

Wer den Secrets-Manager CredHub von CloudFoundry nutzen will, muss die Kommunikation mit CredHub nicht selbst implementieren. Stattdessen liest das Deployment-Tool BOSH alle referenzierten Secrets von CredHub und injiziert diese über Environment-Variablen in die Laufzeitumgebung.

Bei Keywhiz muss die Authentifizierung auch über das Deployment-Tool stattfinden. Statt Environment-Variablen wird via FuseFS ein Verzeichnis mit Dateien gemounted, welche die jeweiligen Secrets gespeichert haben.

Automatisches Rotieren von Secrets

Der AWS Secrets Manager, und zukünftig auch CredHub [4], unterstützen das automatische Rotieren von Geheimnissen. Hierzu müssen Backends wie zum Beispiel MySQL-Datenbanken explizit unterstützt werden. AWS bietet dies bereits für seine RDS-Datenbanken an. Für andere Systeme können Lambda-Funktionen erstellt werden, welche das Rotieren implementieren. Beim automatischen Rotieren ersetzt das Secrets-Management-System aktuelle Geheimnisse externer Systeme automatisch durch neue, sichere Passwörter. Das Austauschen von Passwörtern ist somit nur noch eine Funktion, die ausgelöst werden muss. Niemand kommt in Kontakt mit den neuen Passwörtern, da diese nicht mehr manuell gesetzt werden müssen. Da Geheimnisse nicht im Quellcode gespeichert werden, ist eine Anpassung der Applikationen nach einer Rotation nicht nötig.

Dynamische Secrets

Vault verzichtet auf das automatische Rotieren von Passwörtern und geht mit sogenannten dynamischen Secrets noch einen Schritt weiter. Im Gegensatz zu normalen, statischen Geheimnissen werden dynamische Secrets zur Anfragezeit erstellt und haben eine begrenzte Lebensdauer. Wenn eine Applikation einen Nutzernamen und das zugehörige Passwort für eine Datenbank anfragt, so wird ein neuer Datenbanknutzer mit entsprechenden Rechten und einem zufälligen Passwort erstellt und zurückgeliefert. Werden von dieser Applikation mehrere Instanzen ausgerollt, so bekommt jede Instanz ein individuelles Username-Passwort-Paar. Der erstellte

Nutzer wird automatisch nach einer konfigurierten Zeit (time to live) wieder gelöscht.

Sollen dynamische Secrets für ein System genutzt werden, muss Vault mit entsprechenden Rechten ausgestattet werden. Bei MySQL wären dies beispielsweise Credentials eines Nutzers, welcher andere Nutzer anlegen und löschen darf.

Vault unterstützt dynamische Secrets unter anderem für Datenbanken, AWS, SSH und PKI (private key infrastructure). Bei der PKI können via API einfach TLS-Client-Zertifikate angefragt werden. Dies kann genutzt werden, um kurzlebige Client-Zertifikate zur Authentifizierung zu erstellen. Da der Aufwand gering ist, können auch diese Zertifikate eine kurze Lebensdauer haben – das Ausstellen eines neuen Zertifikats ist nur eine HTTP-Anfrage.

Dynamische Secrets lösen eins der größten Sicherheitsprobleme zuverlässig: langlebige Passwörter oder Tokens.

Literatur und Links