Secrets Management
Passwörter und Schlüssel zentral verwahren
Die Idee und ihr Nutzen
Der Schadendienst einer Versicherung, also das Programm für die Bearbeitung von Schäden, muss sich mit einem Passwort bei seiner Datenbank anmelden. Steht dieses Passwort im Programmcode, kann es jeder lesen und kopieren, der Zugang zum Code hat. Deshalb liegt das Passwort in einem Tresor, einem eigenen Programm, das geheime Werte verschlüsselt aufbewahrt und nur an berechtigte Programme herausgibt. Der Schadendienst weist sich beim Tresor aus, erhält das Passwort und meldet sich damit bei der Datenbank an. Muss das Passwort ausgetauscht werden, ändert sich nur der Wert im Tresor und in der Datenbank, nicht der Programmcode. Dieses Vorgehen heißt Secrets Management, auf Deutsch Verwaltung von Geheimnissen.
Wie funktioniert es?
Das Betriebsteam betreibt den Schadendienst. Zuerst legt das Betriebsteam das Datenbankpasswort im Tresor ab. Dabei legt das Betriebsteam in einer Zugriffsregel fest, welches Programm welches Geheimnis lesen darf. Die Zugriffsregel lautet: Nur der Schadendienst darf das Datenbankpasswort lesen. Beim Start weist der Schadendienst dem Tresor seine Identität nach. Dafür nutzt der Schadendienst einen Nachweis der Betriebsumgebung, ein digitales Dokument, das bestätigt, dass dieses Programm der Schadendienst ist. Die Plattform, auf der der Schadendienst läuft, also die Software, die Programme auf den Servern startet, stellt ihm diesen Nachweis beim Start automatisch aus. Einen Schlüssel im Programmcode braucht der Schadendienst dafür nicht. Mit einem solchen Schlüssel könnte jeder, der den Code hat, das Datenbankpasswort aus dem Tresor abrufen. Der Tresor gibt das Passwort nur an den Schadendienst heraus, und der Schadendienst hält es nur in seinem Arbeitsspeicher. Mit dem abgerufenen Passwort meldet sich der Schadendienst bei der Datenbank an, und die Datenbank nimmt die Anmeldung an.
Ein halbes Jahr später tauscht das Betriebsteam das Passwort planmäßig aus. Die Versicherung schreibt vor, Datenbankpasswörter alle sechs Monate zu wechseln; ein unbemerkt bekannt gewordenes Passwort ist so höchstens ein halbes Jahr lang nutzbar. Zuerst richtet das Betriebsteam in der Datenbank ein neues Passwort ein. Der Schadendienst läuft in mehreren Instanzen, also gleichzeitig laufenden Exemplaren desselben Programms. Alle Instanzen rufen dasselbe Datenbankpasswort aus dem Tresor ab. Das alte Passwort bleibt deshalb vorerst gültig, bis alle Instanzen umgestellt sind. Sobald die Datenbank das neue Passwort kennt, hinterlegt das Betriebsteam das neue Passwort im Tresor. Durch diese Reihenfolge fehlt dem Schadendienst nie ein gültiges Passwort. Beim nächsten geplanten Neustart liest jede Instanz den neuen Wert und meldet sich damit neu an. Das Betriebsteam beobachtet, ob sich alle Instanzen erfolgreich anmelden, und entfernt erst dann das alte Passwort aus der Datenbank.
Der Tresor bewahrt die Geheimnisse verschlüsselt auf, prüft bei jedem Abruf die Zugriffsregel und gibt die Werte aus. Er kann außerdem festhalten, wer wann welches Geheimnis abgerufen hat. Die Datenbank prüft wie bisher bei jeder Anmeldung das Passwort; woher das Passwort stammt, spielt für die Datenbank keine Rolle. Geheime Werte sind nicht nur Passwörter. Dazu gehören auch Schlüssel für die Verschlüsselung, Zugangsschlüssel für fremde Schnittstellen und Zertifikate, also digitale Echtheitsnachweise. Den regelmäßigen Austausch solcher Werte nennt man im Fachjargon Rotation.
Ist der Tresor beim Start des Schadendienstes nicht erreichbar, erhält der Schadendienst kein Passwort und kann sich nicht bei der Datenbank anmelden. Instanzen, die schon laufen und angemeldet sind, arbeiten dagegen weiter, bis sie neu starten oder ihre Verbindung zur Datenbank verlieren. Einen neuen Wert kann der Schadendienst auch ohne Neustart abrufen, indem er regelmäßig beim Tresor nach Änderungen fragt. Manche Tresore können statt eines dauerhaft gemeinsam genutzten Passworts für jede Instanz einen eigenen, zeitlich begrenzten Datenbankzugang erzeugen, der nach Ablauf von selbst ungültig wird. Der Tresor schützt das Passwort nur, solange es bei ihm liegt. Der Schadendienst darf das Passwort nach dem Abruf nicht in Protokolldateien, Fehlermeldungen oder ungeschützte Dateien schreiben. Welche Tabellen der Schadendienst nach der Anmeldung lesen und ändern darf, legt weiterhin die Datenbank fest, nicht der Tresor.
Secrets Management: das Datenbankpasswort liegt im Tresor, nicht im Code
Wann ist es sinnvoll und wann nicht?
Secrets Management lohnt sich
- Ein Programm braucht geheime Werte, die kein Unbefugter kennen darf. Ohne Tresor stehen solche Werte im Programmcode oder in einer Einstellungsdatei, die mit dem Code gespeichert wird. Das Passwort steht dann in jeder Kopie des Codes, auf den Rechnern aller Entwickler, in Datensicherungen und in der Versionsverwaltung, die alle früheren Stände des Codes dauerhaft aufbewahrt. Oft weiß niemand genau, wo überall das Passwort steht und wer es schon gesehen hat.
- Geheime Werte sollen ausgetauscht werden können, ohne dass der Programmcode geändert, neu gebaut und neu ausgeliefert werden muss. Wird das Passwort bekannt, muss es geändert werden. Ein Anlass ist zum Beispiel der gestohlene Laptop eines Entwicklers. Ohne Tresor passt das Entwicklungsteam des Schadendienstes dafür jede Datei an, in der das Passwort steht, baut den Code neu und liefert ihn neu aus.
- Das Betriebsteam muss nachweisen können, welches Programm wann auf welches Geheimnis zugegriffen hat. Steht das Passwort in einer Datei, hält niemand fest, wer die Datei gelesen hat. Der Tresor kann jeden Abruf mit dem abrufenden Programm und dem Zeitpunkt festhalten.
Secrets Management ist nicht das Richtige
- Eine Einstellung ist nicht geheim. Beispiele sind die Adresse eines Dienstes oder die Zahl gleichzeitiger Verbindungen zur Datenbank. Lägen solche Einstellungen im Tresor, bräuchte jeder, der eine solche Einstellung ändern will, Zugang zum Tresor. Dann legt das Betriebsteam solche Einstellungen in einem Configuration Server ab, einem Programm, das nicht geheime Einstellungen für alle Programme gemeinsam verwaltet. Zugang zum Tresor brauchen dann nur die Personen, die Geheimnisse verwalten.
- Ein Wert hat keinen Schutzbedarf. Ein Beispiel ist das Passwort einer Testdatenbank auf dem Rechner eines Entwicklers, die nur erfundene Daten enthält. Wird dieses Passwort bekannt, entsteht kein Schaden, und ein Tresor hätte nichts zu schützen. Der Entwickler trägt das Passwort deshalb in eine Einstellungsdatei auf seinem Rechner ein. Er muss keinen Tresor einrichten und keine Zugriffsregeln pflegen.
- Nur wenige Dienste brauchen Geheimnisse, nur wenige Personen verwalten diese Dienste, und die Plattform, auf der die Dienste laufen, verwahrt geheime Werte selbst. Ein eigener Tresor würde dann dieselbe Aufgabe noch einmal erledigen. Das Betriebsteam hinterlegt die Werte deshalb in der Plattform. Die Plattform übergibt jedem dieser Dienste einen solchen Wert beim Start als geschützte Umgebungsvariable. Eine Umgebungsvariable ist ein benannter Wert, den das Programm beim Start vorfindet. Einrichtung, Ausfallschutz und Pflege eines eigenen Tresors entfallen. Allerdings kann auf vielen Plattformen jeder, der einen Dienst verwalten darf, auch die geheimen Werte dieses Dienstes lesen; bei wenigen Verwaltern bleibt dieser Kreis klein. Die Plattform tauscht die Werte auch nicht planmäßig aus, deshalb tauscht das Betriebsteam sie alle sechs Monate selbst in der Plattform aus.
- Die Datenbank kann einen Nachweis der Plattform selbst prüfen. Dann richtet das Betriebsteam die Datenbank so ein, dass sich der Schadendienst mit diesem Nachweis ganz ohne Passwort anmeldet. Für die Anmeldung bei der Datenbank braucht der Schadendienst dann keinen Tresor. Es gibt kein Datenbankpasswort, das gestohlen werden könnte oder alle sechs Monate ausgetauscht werden müsste.
Nachteile und typische Fehler
Der Tresor wird selbst zu einem kritischen Baustein, denn alle Dienste, die geheime Werte brauchen, hängen beim Start vom Tresor ab. Der Tresor braucht deshalb einen Ausfallschutz und strenge Regeln, wer ihn verwalten darf. Sein Betrieb macht laufend Arbeit: Zugriffsregeln müssen für jedes Programm gepflegt, Nachweise der Betriebsumgebung eingerichtet und Datensicherungen des Tresors geschützt aufbewahrt werden. Jeder Austausch eines Passworts braucht eine abgestimmte Reihenfolge zwischen Tresor, Datenbank und den Neustarts des Schadendienstes.
Typische Fehler und woran man sie erkennt:
- Verschobenes Geheimnis: Der Schlüssel, mit dem sich der Schadendienst beim Tresor ausweist, steht selbst wieder im Programmcode. Wer den Code hat, kann damit alle Geheimnisse des Schadendienstes abrufen. Erkennbar ist das an Zugangsschlüsseln für den Tresor in der Versionsverwaltung.
- Preisgabe nach dem Abruf: Der Schadendienst schreibt zur Fehlersuche alle Einstellungen in eine Protokolldatei, darunter das abgerufene Passwort. Jeder, der die Protokolldatei lesen darf, kann sich dann mit diesem Passwort bei der Datenbank anmelden. Erkennbar ist das an Passwörtern im Klartext in Protokollen oder Fehlermeldungen.
- Tresor nicht erreichbar: Der Tresor fällt aus, und neu startende Instanzen des Schadendienstes erhalten kein Passwort und können sich nicht bei der Datenbank anmelden. Erkennbar ist das an Startfehlern aller Dienste, die gleichzeitig mit einer Störung des Tresors auftreten.
- Übernommener Tresor: Ein Angreifer übernimmt den Tresor und hat Zugang zu allen Geheimnissen auf einmal. Erkennbar ist das an Abrufen von Geheimnissen im Protokoll des Tresors, die das abrufende Programm sonst nie liest.
- Altes Passwort zu früh entfernt: Das Betriebsteam entfernt das alte Passwort aus der Datenbank, bevor alle Instanzen neu gestartet sind. Eine Instanz, die noch mit dem alten Passwort arbeitet, verliert später ihre Verbindung zur Datenbank. Diese Instanz meldet sich mit dem alten Passwort neu an, und die Datenbank weist die Anmeldung ab. Erkennbar ist das an Anmeldefehlern einzelner Instanzen des Schadendienstes nach dem Entfernen des alten Passworts.
- Zu weite Zugriffsregel: Die Zugriffsregel erlaubt allen Diensten, das Datenbankpasswort zu lesen. Dringt ein Angreifer in irgendeinen dieser Dienste ein, ruft er über diesen Dienst das Datenbankpasswort aus dem Tresor ab und meldet sich damit bei der Datenbank des Schadendienstes an. Erkennbar ist das an Abrufen des Passworts durch Programme, die die Datenbank des Schadendienstes gar nicht nutzen.
Weiterführend
Verwandte Ansätze
- Least Privilege: gibt jedem Programm nur die Rechte, die es braucht. Die Zugriffsregel im Tresor setzt diesen Grundsatz für Geheimnisse um, indem nur der Schadendienst das Datenbankpasswort lesen darf.
- Encryption at Rest and in Transit: verschlüsselt gespeicherte und übertragene Daten. Die dafür nötigen Schlüssel liegen häufig selbst in einem Tresor.
- Twelve Factor App: verlangt, dass Einstellungen und Zugangsdaten nicht im Programmcode stehen, sondern dem Programm von der Betriebsumgebung übergeben werden.
- Audit Logging: hält nachvollziehbar fest, wer wann auf welches Geheimnis zugegriffen oder es geändert hat.
Quellen
- OWASP: Secrets Management Cheat Sheet: Empfehlungen zur gemeinsamen Verwaltung von Geheimnissen mit feinen Zugriffsregeln, regelmäßigem Austausch, zeitlich begrenzten Zugängen, Protokollierung der Abrufe und dem Verbot, Geheimnisse in Protokolle zu schreiben.
- HashiCorp: Vault Database secrets engine: Projektdokumentation zu Datenbankzugängen, die ein Tresor auf Anfrage erzeugt und nach Ablauf ihrer Gültigkeitsdauer wieder ungültig macht.