Secrets im Serverbetrieb: Passwörter, API-Keys und Zertifikate kontrolliert verwalten

In fast jeder gewachsenen Infrastruktur gibt es eine Stelle, an der niemand gern nachsieht: die Zugangsdaten. Datenbankpasswörter stehen in Konfigurationsdateien, API-Keys liegen in einem alten Repository, das Admin-Kennwort für die Firewall steht in einem Wiki-Artikel von vor drei Jahren. Solange alles läuft, fällt das nicht auf. Problematisch wird es, wenn ein Mitarbeiter das Unternehmen verlässt, ein Repository versehentlich öffentlich wird oder ein Dienstleister Zugriff auf mehr bekommt, als er braucht.

Secrets-Management ist deshalb kein Sicherheitsluxus, sondern Teil eines geordneten Betriebs. Dieser Beitrag beschreibt, welche Arten von Secrets es gibt, welche Anforderungen daraus folgen und wie ein pragmatischer Einstieg aussieht.

Was überhaupt ein Secret ist

Der Begriff wird oft auf Passwörter verengt. Tatsächlich fällt deutlich mehr darunter: Datenbankzugangsdaten, API-Tokens von Zahlungsdienstleistern oder Mailanbietern, private Schlüssel von TLS-Zertifikaten, SSH-Hostschlüssel, Signaturschlüssel für Pakete oder Container-Images, Verschlüsselungsschlüssel für Backups, Zugangsdaten für Monitoring-Agenten.

Diese Werte haben eine gemeinsame Eigenschaft: Wer sie besitzt, hat Zugriff, unabhängig davon, wer er ist. Deshalb ist die entscheidende Frage nicht nur, wie sicher ein Secret gespeichert wird, sondern wie viele Kopien davon existieren und wer sie anfassen kann.

Menschen und Maschinen brauchen Unterschiedliches

Ein häufiger Denkfehler besteht darin, alle Secrets in einem Werkzeug unterzubringen. Ein Administrator, der sich morgens an einer Weboberfläche anmeldet, hat andere Anforderungen als ein Deployment-Prozess, der um drei Uhr nachts ein Datenbankpasswort braucht.

Für Menschen eignet sich ein Passwortmanager mit Teamfreigaben, Zwei-Faktor-Authentifizierung und nachvollziehbaren Zugriffsrechten. Für Maschinen braucht es einen Mechanismus, der ohne Interaktion funktioniert: Umgebungsvariablen aus einer geschützten Quelle, Dateien mit engen Dateirechten oder ein Secret Store mit API-Zugriff. Beide Welten sollten sauber getrennt sein, auch wenn sie organisatorisch zusammengehören.

Die typischen Fundorte für verstreute Zugangsdaten

Bevor man ein Werkzeug auswählt, lohnt sich eine Bestandsaufnahme. Erfahrungsgemäß finden sich Secrets an diesen Stellen:

• Konfigurationsdateien im Git-Repository, teils in der Historie, auch wenn sie längst entfernt wurden
• CI-Variablen, die über Jahre angelegt und nie aufgeräumt wurden
• Shell-Historien und Cronjob-Definitionen auf einzelnen Servern
• Wikis, Tickets und Chatverläufe
• Lokale Notizen auf Arbeitsgeräten einzelner Mitarbeiter
• Fertig konfigurierte Images oder Snapshots, die ein Passwort mitbringen

Diese Liste ist keine Anklage, sondern der normale Zustand einer Infrastruktur, die über Jahre gewachsen ist. Der erste Schritt zu einem belastbaren Secrets-Management ist nicht ein neues Werkzeug, sondern die Antwort auf die Frage, welche Zugangsdaten es gibt und wo sie überall liegen.

Anforderungen an eine tragfähige Lösung

Aus dem Betrieb ergeben sich vier Anforderungen, die unabhängig vom gewählten Produkt gelten.

Verschlüsselte Ablage: Secrets dürfen nicht im Klartext auf Datenträgern liegen, auch nicht in Backups. Das betrifft auch Datenbank-Dumps von Anwendungen, die Tokens speichern.

Zugriff nach Rolle: Nicht jeder braucht alles. Ein Entwickler benötigt Zugangsdaten für die Testumgebung, nicht für die Produktion. Ein Monitoring-Dienst braucht einen lesenden Datenbankzugang, nicht den Administratoraccount.

Nachvollziehbarkeit: Es muss erkennbar sein, wer wann welches Secret abgerufen oder geändert hat. Ohne dieses Protokoll ist nach einem Vorfall nicht feststellbar, welcher Umfang betroffen ist.

Austauschbarkeit: Jedes Secret muss sich ersetzen lassen, ohne dass dafür ein größerer Umbau nötig ist. Wenn das Ändern eines Datenbankpassworts eine mehrstündige Aktion mit ungewissem Ausgang ist, wird es im Ernstfall nicht gemacht.

Secrets aus Repositories heraushalten

Der häufigste Einzelfehler ist das Einchecken von Zugangsdaten in die Versionsverwaltung. Dagegen helfen drei Maßnahmen, die sich schnell umsetzen lassen.

Erstens eine klare Konvention: Konfigurationsdateien enthalten Platzhalter, die tatsächlichen Werte kommen zur Laufzeit aus der Umgebung. Beispieldateien wie config.example.yml gehören ins Repository, die ausgefüllte Variante nicht.

Zweitens automatische Prüfungen in der Pipeline, die typische Muster wie private Schlüssel oder Tokenformate erkennen und den Build abbrechen. Das verhindert nicht jeden Fall, aber die offensichtlichen.

Drittens ein realistischer Umgang mit Altlasten: Ein Secret, das einmal in der Historie stand, gilt als kompromittiert. Es nachträglich aus der Historie zu entfernen, ist aufwendig und oft unvollständig. Schneller und sicherer ist es, den Wert zu ersetzen.

Rotation planen, bevor sie nötig wird

Rotation bedeutet, ein Secret durch ein neues zu ersetzen und das alte ungültig zu machen. Viele Teams scheuen davor zurück, weil unklar ist, welche Systeme den Wert noch verwenden. Genau das ist der Grund, warum Rotation früh geübt werden sollte.

Hilfreich ist eine einfache Liste pro Secret: Wo wird es verwendet, welcher Dienst muss nach einer Änderung neu gestartet werden, wer ist verantwortlich. Diese Dokumentation ist wichtiger als ein kurzes Rotationsintervall. Ein Passwort, das jährlich getauscht wird und dessen Austausch reibungslos funktioniert, ist in der Praxis besser als ein monatliches Intervall, das nie eingehalten wird.

Für Dienste, die es unterstützen, sind kurzlebige Zugangsdaten die bessere Lösung. Tokens mit begrenzter Gültigkeit, die bei Bedarf neu ausgestellt werden, machen die Rotation zum Normalfall statt zur Ausnahme.

Anlassbezogene Rotation

Unabhängig von festen Intervallen gibt es Ereignisse, die einen sofortigen Austausch erfordern: das Ausscheiden eines Mitarbeiters mit Produktionszugriff, das Ende einer Dienstleisterbeziehung, der Verdacht auf einen Vorfall, ein versehentlich veröffentlichtes Repository. Diese Fälle sollten in der Offboarding-Checkliste stehen, nicht im Gedächtnis einzelner Personen.

Der Notfallzugang

Ein zentral verwalteter Secret Store schafft eine neue Abhängigkeit. Wenn er ausfällt oder niemand mehr hineinkommt, steht der Betrieb still. Deshalb gehört zu jeder Lösung ein geregelter Notfallzugang.

Üblich ist ein versiegelter Zugang, der physisch oder in einem getrennten System hinterlegt ist, dessen Verwendung protokolliert wird und der nach jeder Nutzung erneuert wird. Wichtig ist, dass mindestens zwei Personen ihn verwenden können und dass seine Funktion regelmäßig überprüft wird. Ein Notfallzugang, der seit Jahren nicht getestet wurde, ist eine Annahme, keine Absicherung.

Ein pragmatischer Einstieg

Der Aufbau muss nicht mit einer großen Plattform beginnen. Eine mögliche Reihenfolge:

1. Bestandsaufnahme aller bekannten Zugangsdaten mit Verwendungszweck und Verantwortlichem
2. Trennung in Secrets für Menschen und Secrets für Systeme
3. Einführung eines Passwortmanagers mit Teamstruktur für die erste Gruppe
4. Verlagerung der zweiten Gruppe aus Repositories in eine geschützte Quelle, aus der Deployments lesen
5. Austausch aller Werte, die jemals in Repositories, Tickets oder Chats standen
6. Festlegung von Verantwortlichkeiten und Rotationsanlässen

Jeder dieser Schritte bringt für sich genommen eine Verbesserung. Entscheidend ist, dass die Ergebnisse dokumentiert werden und nicht wieder im Alltag versickern.

Fazit

Secrets-Management ist weniger eine Frage des Produkts als eine Frage der Ordnung. Wer weiß, welche Zugangsdaten existieren, wer sie nutzen darf und wie sie sich austauschen lassen, kann auf Vorfälle und Personalwechsel ruhig reagieren. Wer es nicht weiß, muss im Ernstfall raten - und das ist der teuerste Teil jedes Sicherheitsvorfalls.