Monopam-Vault: Discovery, Vaulting und Rotation
Was hat sich geändert
Jede Inhaltsänderung wird versioniert. Wählen Sie eine Version, um sie mit der vorherigen zu vergleichen.
Version 9 → 10
AktualisierungNeues Modul zum Vault-Betrieb in der Produktion: Vault-Schlüssel und Neuverschlüsselung, Wiederherstellung nach gescheiterten Rotationen, Secret Syncs und geteilte Einträge, Token-Kodierung, Maschinenidentitäten und Leases dynamischer Geheimnisse. Das Modul enthält jetzt Diagramme und am Ende eine Liste, was zuerst zu prüfen ist.
3 Lektionen aktualisiertDauer
Inhaltliche Aktualisierung. Eingeschriebene Lernende wurden benachrichtigt.
Dauer von 24 auf 26 Minuten geändert.
Jedes Geheimnis in der Mandantendatenbank ist mit einem Schlüssel verschlüsselt, den jeder Monopam-Prozess beim Start aus seiner Umgebung liest. Ist kein Schlüssel gesetzt, nutzt Monopam einen eingebauten Schlüssel. Dieser wird mit dem Produkt ausgeliefert, schützt also vor beiläufigem Lesen, aber nicht vor jemandem, der sowohl einen Datenbank-Dump als auch die Software besitzt. Eine Produktivinstallation setzt ihren eigenen Schlüssel.
| Variable | Zweck |
| --- | --- |
| `MONOPAM_VAULT_KEY` | Der aktive Schlüssel. Neue Schreibvorgänge nutzen ihn |
| `MONOPAM_VAULT_KEY_VERSION` | Die Versionsnummer des aktiven Schlüssels. Eine höhere Zahl bedeutet einen neueren Schlüssel |
| `MONOPAM_VAULT_KEYS` | Die älteren Schlüssel, damit unter ihnen geschriebene Zeilen lesbar bleiben |
Zusammen bilden sie den **Schlüsselring**. Ein Super-Admin kann den Stand über den Schlüsselstatus der Vault-Wartung prüfen, der die aktive Version meldet und ob die Installation extern verschlüsselt ist.
### Drei Regeln, die die meisten Störungen erklären
**1. Jeder Prozess, und nur beim Start.** Webserver und jedes Gateway entschlüsseln Geheimnisse, also brauchen alle denselben Schlüsselring. Die Umgebung wird einmal beim Start gelesen, eine Änderung bewirkt daher nichts, bis der Prozess neu startet. Das klassische Symptom: Der Schlüssel wurde nur auf dem Webserver gesetzt. Ein Passwort im Browser anzuzeigen funktioniert, weil der Webserver entschlüsseln kann, SSH und RDP aber scheitern, weil das Gateway es nicht kann. Setzen Sie den Schlüssel auf jedem Host, starten Sie jeden neu und planen Sie dafür ein Wartungsfenster.
**2. Der Job folgt dem Schlüssel, nie umgekehrt.** Sobald der Schlüssel überall sitzt, startet ein Super-Admin den Neuverschlüsselungsjob, der vorhandene Zeilen unter dem aktiven Schlüssel neu schreibt. Den Job ohne externen Schlüssel zu starten bringt keinen Sicherheitsgewinn: Die Zeilen werden schlicht unter dem eingebauten Schlüssel neu geschrieben, und eine Warnung wird protokolliert.
**3. Alte Schlüssel bleiben, bis der Job null Fehler meldet.** Das Job-Ergebnis listet je Tabelle, wie viele Werte geprüft, aktualisiert und fehlgeschlagen sind. Ein fehlgeschlagener Wert ist eine Zeile, die der Job nicht entschlüsseln konnte, meist weil die Schlüsselversion, mit der sie geschrieben wurde, im Ring fehlt. Der Job lässt solche Zeilen unberührt. Entfernen Sie jetzt alte Schlüssel, werden diese Zeilen dauerhaft unlesbar. Ergänzen Sie den fehlenden Schlüssel in `MONOPAM_VAULT_KEYS`, starten Sie neu, lassen Sie den Job erneut laufen und entfernen Sie alte Schlüssel erst nach einem Lauf mit `FailedValues` gleich null in allen Tabellen.
::diagram pam-vault-key-change
### Es gibt keine Wiederherstellung
Ein verlorener Schlüssel lässt sich nicht wiederherstellen, und jede damit verschlüsselte Zeile bleibt unlesbar. Legen Sie den Schlüssel vor Beginn der Änderung außerhalb von Monopam ab, etwa in einem Passwortmanager mit eingeschränktem Zugriff, und behandeln Sie ihn wie Ihre sensibelste Anmeldeinformation.
> Tipp: Lesen Sie den Schlüsselstatus der Vault-Wartung vor und nach der Änderung. Vorher zeigt er, ob die Installation überhaupt extern verschlüsselt ist. Nachher muss die aktive Version die von Ihnen gesetzte sein.
Eine Rotation ändert das Passwort am Ziel und führt danach die Automationen aus, die abhängige Systeme aktualisieren, etwa einen Dienst oder einen Anwendungspool, der das Konto nutzt. Die Einstellung `If Automation Fails` der Rotationsrichtlinie entscheidet, was geschieht, wenn eine dieser Automationen scheitert.
| Wahl | Was Monopam tut | Passt, wenn |
| --- | --- | --- |
| `Revert to the previous password` (Standard) | Ändert das Ziel zurück, Vault und Ziel stimmen im alten Passwort überein | Das abhängige System weiterlaufen muss und das Ziel eine zweite Änderung verträgt |
| `Keep the new password` | Lässt Vault und Ziel auf dem neuen Passwort und markiert den Eintrag zur Nacharbeit | Eine zweite Änderung kurz danach das Konto sperren würde |
Bedenken Sie, was ein Revert wirklich ist: eine zweite Passwortänderung am Ziel wenige Sekunden nach der ersten. Auf einem System, das Konten nach schnellen Änderungen sperrt, ist gerade diese zweite Änderung gefährlich. Dort behalten Sie das neue Passwort und reparieren das abhängige System von Hand.
### Wenn auch der Revert scheitert
Das Audit-Ereignis `Password Rotation Revert Error: Manual Intervention Required` bedeutet, dass die Automation scheiterte und der Rückweg ebenfalls. Vault und Ziel können nun verschiedene Passwörter halten, und Monopam kann nicht wissen, welches das Ziel akzeptiert.
Klicken Sie nicht drauflos. Stellen Sie zuerst fest, welches Passwort das Ziel jetzt akzeptiert. Handeln Sie dann danach: `Reconcile`, wenn der Vault den richtigen Wert hält und das Ziel angeglichen werden muss, ein Revert aus der Password History mit anschließendem `Reconcile`, wenn der vorherige Wert gilt, oder ein manuelles Zurücksetzen auf dem Host. Wer Passwörter in falscher Reihenfolge gegen ein System mit Sperrschwelle probiert, sperrt das Konto und macht aus einem Rotationsproblem einen Ausfall.
::diagram pam-rotation-outcomes
### Wohin ein rotiertes Geheimnis reist
**Secret Syncs.** Ein Vault-Eintrag kann in einen externen Speicher wie AWS Secrets Manager synchronisiert werden. Der Sync wird nur eingereiht, wenn ein Passwort endgültig ist: nach dem Speichern oder nach einer erfolgreichen, nicht zurückgenommenen Rotation. Eine gescheiterte und zurückgenommene Rotation überträgt nichts, der externe Speicher sieht also nie ein Passwort, das zehn Sekunden lebte.
**Geteilte Einträge zwischen Mandanten.** Ein Dienstleister kann einen Eintrag seines Hauptmandanten in einem Kundenmandanten nutzbar machen, ohne das Geheimnis zu kopieren. Der Modus bestimmt, was die Mitarbeiter des Kunden tun können.
| Modus | Der Kundenmandant kann |
| --- | --- |
| `Sessions only` (Standard) | Sitzungen mit dem Konto öffnen. Das Geheimnis wird nicht angezeigt, nicht von der Vault-API geliefert und nicht in Skript-Tokens eingesetzt |
| `Sessions and reveal` | Zusätzlich den Wert lesen |
Das Geheimnis lebt nur im Hauptmandanten. Rotation, Verlauf und Abgleich finden dort statt, und jede Nutzung im Kundenmandanten liest den aktuellen Wert in diesem Moment, ein rotiertes Passwort ist also überall sofort aktuell.
**Tokens in Startern und Skripten.** Ein Token wie `{{Vault.appadmin.Password}}` setzt den Rohwert ein. Roh ist falsch, sobald der Zielort eine eigene Syntax hat. In einer URL zerstört ein Passwort mit `&` oder `#` die Adresse. Hängen Sie einen Kodierungsmodifikator an: `{{Vault.appadmin.Password:url}}` kodiert den Wert prozentual, `:sh` und `:ps` machen ihn in einer einfach quotierten Shell- oder PowerShell-Zeichenkette sicher, und `:base64` kodiert ihn für einen Transport, der Base64 dekodiert. Modifikatoren lassen sich nicht verketten, und ein falsch geschriebener Modifikator wird ohne Fehler ignoriert und liefert den Rohwert. Testen Sie daher mit einem Passwort voller Sonderzeichen.
> Tipp: Lesen Sie nach einer gescheiterten Rotation das Audit, bevor Sie das Konto anfassen. War der Revert erfolgreich, stimmen Vault und Ziel im alten Passwort überein, und nur das abhängige System braucht Reparatur. Nur `Password Rotation Revert Error: Manual Intervention Required` bedeutet, dass beide abweichen können.
Menschen lassen sich Geheimnisse im Browser anzeigen. Pipelines, Pods und Operatoren lesen sie aus dem Secrets Store über eine **Maschinenidentität** (`Secrets` > `Identities`). Die Identität meldet sich an, erhält ein kurzlebiges Token und liest, was ihre **Grants** auf Projekt, Umgebung und Ordner erlauben.
### Die Anmeldemethode wählen
| Methode | Die Maschine weist sich aus mit | Wählen, wenn | Preis |
| --- | --- | --- | --- |
| Universal Auth | Client-ID und Client-Secret | Der Aufrufer überall laufen kann, auch ein CI-Server, dessen Token-Aussteller nur intern erreichbar ist | Ein Geheimnis, das gespeichert und von Hand rotiert werden muss |
| OIDC | Einem signierten Token seiner Plattform, geprüft gegen die öffentlichen Schlüssel des Ausstellers und den gebundenen Claim | Der Aussteller der Plattform öffentlich erreichbar ist, wie bei gehosteten Pipeline-Diensten | Nichts wird gespeichert. Funktioniert nicht, wenn Monopam die öffentlichen Dokumente des Ausstellers nicht erreicht |
| Kubernetes | Einem Service-Account-Token des Clusters | Der Workload in einem Cluster läuft | Monopam muss den Cluster erreichen |
Beispiel: Ein Team will bei einem gehosteten Pipeline-Dienst kein langlebiges Token im Repository. Eine OIDC-Identität, deren gebundener Claim zur Herkunft des Workflows passt, gibt der Pipeline ein kurzlebiges Token und lässt nichts zurück, das durchsickern könnte. Ihr selbst betriebener Build-Server stellt ebenfalls Tokens aus, sein Aussteller ist aber nur im Netz sichtbar, Monopam kann sie also nicht prüfen. Dieser Server erhält Universal Auth, mit `Allowed IP ranges` auf das Build-Netz gesetzt, damit ein durchgesickertes Secret anderswo nutzlos ist.
### Verhalten, das man vor einem Vorfall kennen sollte
- **Tokens überleben Änderungen an der Identität.** Das Deaktivieren einer Identität oder `Rotate Secret` stoppt neue Anmeldungen sofort. Bereits ausgestellte Tokens funktionieren, bis ihre `Token TTL (minutes)` endet. Eine kurze TTL ist Ihre eigentliche Eindämmungszeit.
- **`Rotate Secret` kennt kein Zurück.** Das alte Secret stirbt sofort. Jeder Aufrufer, der es noch hat, scheitert mit `Invalid client credentials.`, bis er das neue erhält. Verteilen Sie nach Möglichkeit zuerst, und rotieren Sie eine geteilte Identität nie beiläufig.
- **`Allowed IP ranges` wird nur bei der Anmeldung geprüft**, nicht bei jedem Lesezugriff. Hinter einem Load Balancer ist die Aufruferadresse die erste IPv4-Adresse in `X-Forwarded-For`. Setzt der Balancer den Header nicht, sieht jeder Aufrufer wie der Balancer aus, und eine eingeschränkte Identität wird abgelehnt. Korrigieren Sie den Header. Nehmen Sie nicht die Adresse des Balancers in den Bereich auf, das ließe jeden dahinter durch.
- **Fehlgeschlagene Anmeldungen pausieren eine Adresse.** Ab dem zehnten Fehlschlag innerhalb von fünf Minuten erhält die Adresse für den Rest des Fensters `Too many failed logins`. Dreißig Pipelines hinter einer NAT-Adresse teilen dieses Schicksal, ein Job in einer Schleife mit altem Secret stoppt also alle.
- **Ablehnungen tragen ihren Code im Body.** Eine Autorisierungsablehnung der Maschinen-API antwortet mit HTTP 400 und `"code":403` im Inhalt. Clients müssen den Body lesen.
- **`Restricted (never visible)` ist eine Anzeigeeinstellung.** Sie verbirgt einen Wert in der Weboberfläche. Eine Maschine mit Grant erhält ihn dennoch, über die Maschinen-API wie über die Vault-kompatible API. Nur Grants begrenzen, was eine Maschine lesen kann.
### Dynamische Geheimnisse
Ein dynamisches Geheimnis (`Secrets` > `Dynamic`) erzeugt auf Anforderung eine kurzlebige Anmeldeinformation, etwa einen Datenbank-Login, und gibt sie als **Lease** aus. Endet der Lease, widerruft Monopam die Anmeldeinformation am Ziel.
| Situation | Was geschieht | Was Sie tun |
| --- | --- | --- |
| Eine Anwendung verlängert ihren Datenbank-Lease immer wieder | Jede Verlängerung verlängert den Lease, aber nie über Erstellungszeit plus `Max TTL (minutes)` hinaus | Lassen Sie die Anwendung vor dieser Grenze einen neuen Lease anfordern und neu verbinden |
| Das Ziel war beim Ablauf des Lease nicht erreichbar | Der Lease zeigt `Revoke Failed`. Monopam versucht es nicht erneut | Entfernen Sie den erzeugten Login am Ziel von Hand. Er kann noch existieren |
| Ein Lease für ein Kubernetes-Token wird verlängert | Die Verlängerung wird abgelehnt | Fordern Sie vor Ablauf des Tokens einen neuen Lease an |
::diagram pam-machine-lease
`Revoke Failed` ist der Zustand, auf den Sie achten müssen. Es ist der eine Fall, in dem eine von Monopam erzeugte Anmeldeinformation unbemerkt weiterleben kann.
### Was zuerst zu prüfen ist
| Symptom | Zuerst prüfen |
| --- | --- |
| Jeder Aufrufer einer Identität scheitert mit `Invalid client credentials.` | Ob jemand `Rotate Secret` genutzt hat. Das alte Geheimnis starb sofort |
| Viele Pipelines erhalten gleichzeitig `Too many failed logins` | Ein Job, der hinter der gemeinsamen NAT-Adresse mit altem Geheimnis in der Schleife läuft |
| Eine eingeschränkte Identität wird hinter einem Load Balancer abgelehnt | Ob der Balancer `X-Forwarded-For` setzt |
| Ein Client meldet HTTP 400, wo eine Ablehnung erwartet wurde | Der Body: `"code":403` ist die Autorisierungsablehnung |
| Eine deaktivierte Identität liest weiterhin Geheimnisse | Ihre ausgestellten Tokens leben, bis `Token TTL (minutes)` endet |