Zugangsdaten und Secrets sicher verwalten

Zahlen aus zwei jährlichen Erhebungen, beide öffentlich einsehbar.

Wer das Repository lesen darf, liest das Produktivpasswort mit. Nicht nur das feste Team, sondern auch der externe Dienstleister von vor drei Monaten und jeder, der sich einmal eine lokale Kopie gezogen hat. Diese Kopien verschwinden nicht, wenn der Zugang entzogen wird.

Ein Backup der Konfiguration ist ein Backup der Zugangsdaten. Ein Auszug, den jemand zur Fehlersuche in die Testumgebung einspielt, trägt sie mit hinüber.

Und beim Personalwechsel weiß niemand, welche Zugänge zu drehen sind. Eine Liste fehlt, weil die Liste die Systeme selbst sind.

Umgebungsvariablen sind keine Lösung, sondern eine Verlagerung: Der Wert steht dann im Deployment-Manifest und im Prozessabbild, unverschlüsselt und an Orten, an denen weniger Leute hinsehen.

Links, wo der Wert heute meistens liegt. Rechts, was sich ändert, wenn ihn ein eigener Dienst hält.

In der Modellierung wird das Feld nicht als Text angelegt, sondern als verschlüsseltes Feld. Damit ist die Sache für das Projekt erledigt: Beim Speichern legt der Rahmen den Wert in SOLUTIONS.vault ab und schreibt in die Datenbank den Platzhalter. Keine Verschlüsselungsroutine, die jemand selbst schreibt, vergisst oder falsch aufruft. Das ist der Grund, warum wir konfigurieren statt programmieren.

Beim Lesen passiert bewusst nichts automatisch. Eine Liste mit zweihundert Schnittstellenkonfigurationen liefert zweihundert Platzhalter und keinen Klartextwert, auch wenn der Aufrufer alle zweihundert Datensätze sehen darf. Der Klartext kommt über einen eigenen Aufruf für ein einzelnes Feld, und der prüft dieselbe Berechtigung wie das Öffnen des Datensatzes.

Wir unterscheiden zwei Arten von Einträgen. Anmeldepasswörter von Personen werden unumkehrbar abgelegt und lassen sich prüfen, aber nie wieder lesen. Technische Zugangsdaten müssen rücklesbar sein, weil die Anwendung sie vorzeigt. Hinterlegt wird nicht nur eine Zeichenkette, sondern auch ein Zugangsdatensatz oder Zertifikatsdaten.

Ein Zugang wird nur dann regelmäßig gedreht, wenn das billig ist. Muss dafür eine Datei in vier Umgebungen angefasst und freigegeben werden, steht die Rotation in der Richtlinie und findet trotzdem nicht statt. Liegt der Wert in SOLUTIONS.vault, ist sie das Ändern eines Eintrags.

Eine Anwendung, die eine Datenbankverbindung dauerhaft offen hält, übernimmt den neuen Wert erst beim nächsten Verbindungsaufbau. Sofort wirksam ist die Änderung nur dort, wo ohnehin je Vorgang verbunden wird; sonst bleibt ein geplanter Neustart Teil der Rotation.

Die Trennung nach Umgebung fällt mit ab: Entwicklung, Test und Produktion haben getrennte Schlüsselräume; eine Anwendung entschlüsselt ausschließlich ihre eigenen Einträge. Wer eine Kopie der Testdatenbank hat, hält nichts in der Hand, was auf Produktion passt.

Der Dienst ist ein Behältnis; er ersetzt keine Entscheidung. Wenn niemand festlegt, welcher Zugang existieren darf, wer ihn anfordern darf und wann er gedreht wird, verschiebt SOLUTIONS.vault das Chaos nur an einen sichereren Ort. Dann bleibt weiterhin unklar, wofür der Eintrag „Schnittstelle alt, nicht löschen“ gut ist. Diese Arbeit ist organisatorisch und lässt sich nicht mitbestellen.

Die zweite Grenze fehlt im Gespräch am häufigsten: Hier geht es um technische Zugänge zwischen Systemen, nicht um die Passwörter Ihrer Mitarbeiter. Ein Passwortmanagement für Menschen ist ein anderes Produkt und bleibt daneben nötig.

Und wer Daten an der Anwendung vorbei direkt in die Datenbank schreibt, umgeht die Verschlüsselung: Der Wert steht dann im Klartext dort, wo der Platzhalter stehen sollte, und es fällt niemandem auf. Importe müssen deshalb durch die Anwendung laufen, mehr dazu unter Datenmigration und Schnittstellen. Gegen jemanden mit weitreichenden Rechten hilft ohnehin keine Verschlüsselung, sondern nur das Rechtesystem in SOLUTIONS.user.

• Datenmigration und Schnittstellen: jede Verbindung nach außen braucht Zugangsdaten
• Rollen und Rechte: wer den Datensatz sehen darf, darf ihn entschlüsseln
• Betrieb auf Kubernetes und On-Premise

Häufige Fragen

Wo werden die Zugangsdaten gespeichert?

In einem eigenen, verschlüsselten Dienst. In der Datenbank der Fachanwendung steht nur ein Platzhalter, ein Backup dieser Anwendung enthält den Zugang also nicht. Der Dienst hat keine Adresse im Internet und läuft dort, wo die Anwendung läuft.

Kann ich ein hinterlegtes Passwort später wieder im Klartext sehen?

Das hängt vom Eintrag ab. Anmeldepasswörter von Personen werden unumkehrbar abgelegt: prüfbar, aber nie wieder lesbar. Technische Zugangsdaten sind rücklesbar verschlüsselt. Entschlüsselt wird einzeln und nur für einen Aufruf, der den Datensatz ohnehin lesen darf.

Was passiert bei einem Personalwechsel?

SOLUTIONS.vault liefert das Inventar: welche technischen Zugänge existieren und woran sie hängen. Das Drehen ist danach das Ändern eines Eintrags statt einer Suche durch Dateien und Skripte. Welche Zugänge zu drehen sind, entscheiden Sie.

Ersetzt das unseren Passwortmanager für Mitarbeiter?

Nein. Hier geht es um technische Zugänge zwischen Systemen: was eine Fachanwendung braucht, um mit Datenbank, ERP oder einer Fremdschnittstelle zu sprechen. Ein Passwortmanagement für Mitarbeiter ist ein anderes Produkt und bleibt daneben nötig.

Wird protokolliert, wer auf einen Eintrag zugreift?

An jedem Eintrag steht, wer ihn angelegt und wer ihn zuletzt geändert hat, jeweils mit Zeitpunkt. Eine vollständige Historie jeder einzelnen Änderung führt der Dienst nicht, und ein Zugriffsprotokoll ist es erst recht nicht. Wer wann einen Wert entschlüsselt hat, steht im Protokollstrom des Dienstes; für einen Prüfer ist das eine Log-Auswertung.

Muss dafür etwas programmiert werden?

Für die Anwendung nicht. Am Feld im Modell hinterlegen Sie, dass der Wert verschlüsselt gehalten wird. Aufwand entsteht anderswo: Jeder Ort, an dem heute ein Klartextwert steht, muss gefunden, überführt und gedreht werden. Das ist der größere Posten.