Anmeldedaten-Lebenszyklus und Ausführung brauchen getrennte Besitzer

Ein Secret-Manager sollte entscheiden, welche Anmeldedaten existieren, wann sie ablaufen und wie sie ungültig werden. Ein Desktop-Gateway sollte entscheiden, ob dieser Prozess diese Aktion jetzt ausführen darf, die Aktion ohne Übergabe der Anmeldedaten an den Prozess ausführen und das Ergebnis protokollieren. Beide Aufgaben zusammenzulegen wirkt einfacher, bis die erste Rotation, der erste Widerruf oder ein Vorfall die Frage aufwirft, welche Komponente tatsächlich zuständig war.

Die Grenze richtet sich nach dem Besitz im Moment der Verwendung, nicht nach dem Speicherort. HashiCorp Vault oder ein auf 1Password gestützter Ablauf kann für den Lebenszyklus zuständig bleiben, während ein Gateway die Ausführung steuert. Dafür muss die Übergabe Status und Identität des Lebenszyklus bewahren, ohne das Gateway in einen unkontrollierten Cache zu verwandeln. Wenn das Gateway einen Wert kopiert, dessen Lease vergisst und ihn weiterverwendet, enthält das Diagramm zwei Kästen, aber das System zwei Secret-Manager.

Dieses Modell rechtfertigt den zusätzlichen Verbindungsaufwand, wenn autonome Agenten produktive APIs oder SSH-Ziele erreichen können. Diese Agenten brauchen eng begrenzte Aktionen und menschliche Kontrolle. Sie brauchen keinen weiteren Weg, Anmeldedaten zu lesen.

Die Grenze liegt vor der authentifizierten Aktion

Das Lebenszyklussystem besitzt Erstellung, Rotation, Ablauf und Widerruf der Anmeldedaten; das Ausführungsgateway besitzt die Freigabe jeder authentifizierten Aktion. Dieser Satz ist der Architekturtest. Für jedes Feld, jeden Cache, jeden erneuten Versuch und jeden Protokolleintrag muss eine Seite verantwortlich sein.

Lebenszyklusverantwortung umfasst mehr als die Speicherung einer verschlüsselten Zeichenfolge. Bei einem dynamischen Datenbankkonto gehören dazu die Rolle, die das Konto erstellt, die Lease-ID, die TTL, Regeln für die Verlängerung und die Operation zum Löschen oder Deaktivieren des Kontos. Bei einem statischen API-Token gehören der ausstellende Dienst, die aktuelle Generation, der Aktivierungszeitpunkt, ein mögliches Überschneidungsfenster und der Nachweis dazu, dass die alte Generation nicht mehr funktioniert. Ein Passwortmanager kann den maßgeblichen Datensatz speichern, doch die entfernte API entscheidet weiterhin, ob sie das Token akzeptiert.

Die Ausführungsverantwortung beginnt, nachdem ein Aufrufer eine Wirkung wie GET /billing/invoices, POST /deployments oder einen SSH-Befehl auf einem benannten Host verlangt. Das Gateway authentifiziert den Aufrufer, prüft die lokale Freigabe, löst die autorisierten Anmeldedaten auf, fügt sie in das ausgehende Protokoll ein und gibt nur das Ergebnis zurück. Es sollte dem Agenten keine allgemeine Aktion read secret anbieten. Damit würde Ausführung wieder zur Secret-Verteilung.

Eine klare Schnittstelle benennt deshalb eine Aktion und eine Referenz auf Anmeldedaten, nicht deren Wert. Sie benennt außerdem die erwartete Generation, damit eine verzögerte Anfrage nicht unbemerkt eine Rotationsgrenze überschreitet. Ein brauchbarer Anfrageumschlag sieht so aus:

{
  "action_id": "01J...",
  "credential_ref": "vault:database/creds/agent-readonly",
  "expected_generation": "lease:database/creds/agent-readonly/2f6a...",
  "purpose": "read migration status",
  "target": "db-admin.internal",
  "caller": {
    "session_id": "sess_7f2...",
    "process_authority": "signed:TEAMID.example.agent"
  }
}

Das Gateway darf den zugrunde liegenden Wert erhalten, denn eine Komponente muss Bytes in einen Authorization-Header oder einen SSH-Handshake einsetzen. Die Bedingung lautet, dass es den Wert innerhalb des vertrauenswürdigen Ausführungspfads erhält, ihn von Argumenten, Umgebungsvariablen, Dateien, Werkzeugergebnissen und Fehlermeldungen fernhält, die der Agent sehen kann, und ihn anschließend nach einer dokumentierten Cache-Regel verwirft. Secret-frei für den Agenten bedeutet nicht, dass keine Komponente jemals Klartext verarbeitet.

Die Lebenszyklusinstanz erstellt und entfernt Anmeldedaten

Verwenden Sie Vault als Besitzer des Lebenszyklus, wenn dessen Secrets Engine die Anmeldedaten im Zielsystem erstellen und widerrufen kann. Verwenden Sie einen auf 1Password gestützten Ablauf nur dann als Besitzer statischer Anmeldedaten, wenn er auch den ausstellenden Dienst aktualisiert, die neue Generation erfasst und die alte entfernt. Nur den neuesten Wert zu speichern ist Bestandsverwaltung, keine Rotation.

Die HashiCorp-Dokumentation zu Vault-Leases formuliert den Vertrag ungewöhnlich deutlich. Jedes dynamische Secret erhält ein Lease mit einer Dauer und einem Kennzeichen für die Verlängerbarkeit. Vault verspricht die Gültigkeit während dieser Dauer, doch nach dem Ablauf darf der Verbraucher nicht mehr davon ausgehen, dass die Anmeldedaten funktionieren. Der Widerruf eines Lease macht das Secret ungültig und verhindert eine Verlängerung. Bei unterstützten Engines führt Vault auch die Bereinigung im Zielsystem aus, beispielsweise das Löschen erzeugter Cloud-Anmeldedaten oder eines Datenbankbenutzers.

Dieses Verhalten macht Vault zum naheliegenden Besitzer unterstützter dynamischer Anmeldedaten. Das Gateway sollte ein Lease anfordern oder empfangen, die zurückgegebene TTL beachten und die Nutzung vor dessen Ende einstellen. Es darf nie eine längere lokale Lebensdauer erfinden. HashiCorp weist außerdem darauf hin, dass ein bei der Verlängerung angeforderter Zuwachs nur eine Empfehlung ist und Clients die Antwort prüfen müssen. Ein Gateway, das eine weitere Stunde anfordert und davon ausgeht, sie erhalten zu haben, hat die Lebenszyklusverantwortung bereits verletzt.

Die KV-Engine von Vault verhält sich anders. Laut Vault-Dokumentation stellt KV keine Leases aus, selbst wenn eine Antwort eine Lease-Dauer enthält. Ein API-Token wird durch die Speicherung in KV nicht dynamisch, und das Löschen einer alten KV-Version widerruft das Token nicht zwingend beim Aussteller. Der Rotationsablauf muss den Anbieter aufrufen, den Ersatz prüfen, den maßgeblichen Datensatz aktualisieren und das alte Token deaktivieren.

Dieselbe Einschränkung gilt für 1Password. Die CLI-Dokumentation beschreibt Secret-Referenzen und Befehle wie op run, op read und op inject. Diese Mechanismen rufen ein gespeichertes Secret zur Laufzeit ab. Für sich allein rotieren sie keinen allgemeinen API-Schlüssel eines Drittanbieters bei dessen Aussteller. Ein Team kann den maßgeblichen Datensatz weiterhin in 1Password führen, doch die umgebende Automatisierung muss die Aktualisierung im entfernten System und die Entfernung des alten Werts übernehmen.

Weisen Sie die Lebenszyklusverantwortung nicht nach Anbieterkategorie zu. Entscheidend sind nachweisliche Kontrolle über den Aussteller und eine beobachtbare Änderung der Generation.

Eine sichere Übergabe enthält Referenz und Lease

Das Gateway benötigt eine auflösbare Referenz, eine Gültigkeitsgrenze und einen Widerrufspfad. Nur eine Referenz löst die Benennung, verliert aber die Zeit. Nur ein Ablaufzeitpunkt verliert die Instanz, die tatsächlich widerrufen kann. Nur ein Secret-Wert verliert beides.

Bei dynamischen Vault-Secrets ist die Lease-ID der natürliche Bezeichner der Generation. Die Antwort von vault read database/creds/my-role enthält lease_id, lease_duration, lease_renewable, username und password. Das Gateway muss die Bytes der Anmeldedaten und diese Metadaten in einem Objekt binden. Es darf das Passwort nicht in einem Cache und das Lease in einem anderen speichern, in dem beide auseinanderlaufen können.

Erstellen Sie für einen statischen 1Password-Datensatz eine unveränderliche Generationsmarke im Rotationsablauf. Das kann eine von der gewählten Integration bereitgestellte Elementversions-ID oder eine neben der Referenz gespeicherte Rotationsereignis-ID sein. Verwenden Sie keinen veränderlichen Elementnamen wie prod-api-key als Generation. Der Name sagt dem Gateway, wo es auflösen soll, beweist aber nicht, welchen Wert es erhalten hat.

Der Übergabevertrag sollte diese Eigenschaften enthalten:

• credential_ref identifiziert die Quelle ohne geheimes Material.
• generation ändert sich bei jeder Änderung der nutzbaren Anmeldedaten.
• not_after gibt dem Gateway einen festen lokalen Stoppzeitpunkt, sofern einer existiert.
• revocation_ref zeigt Reaktionswerkzeugen, welches Objekt widerrufen oder entfernt werden muss.
• issued_for bindet die Anmeldedaten an vorgesehene Rolle, Ziel und Umgebung.

Eine Antwort des Gateways sollte die nicht geheimen Teile wiederholen, damit Aufrufer und Audit-System eine Wirkung zuordnen können, ohne die Anmeldedaten zu kennen:

{
  "action_id": "01J...",
  "status": 200,
  "credential_ref": "vault:database/creds/agent-readonly",
  "generation": "lease:database/creds/agent-readonly/2f6a...",
  "executed_at": "2026-07-27T14:03:12Z",
  "result_digest": "sha256:9b0..."
}

Dieser Vertrag legt auch eine unbequeme Tatsache offen: Ein Desktop-Gateway braucht eine eigene Maschinenidentität, um Daten aus dem Lebenszyklussystem abzurufen. Auch diese initialen Anmeldedaten haben einen Lebenszyklus. Ein Vault-Token sollte eine enge Richtlinie und eine eigene TTL oder Verlängerungslogik haben. Ein 1Password-Servicekonto-Token sollte nur die erforderlichen Tresore erreichen. Das initiale Token in einer lokalen Einstellungsdatei zu verstecken verschiebt das ursprüngliche Problem nur eine Ebene nach unten.

Ablauf muss Caches und erneute Versuche überstimmen

Der Ablauf bleibt bei der Übergabe nur erhalten, wenn jeder Ausführungspfad die aktuelle Zeit mit der von der Lebenszyklusinstanz gelieferten Grenze vergleicht. Das Gateway sollte eine neue Aktion ablehnen, wenn die verbleibende Zeit nicht für Auflösung, Freigabe, Verbindungsaufbau, Ausführung und eine kleine Uhrentoleranz reicht.

Angenommen, Vault stellt Datenbank-Anmeldedaten für zehn Minuten aus. Ein Agent startet in Minute neun einen Export, der Benutzer liest vierzig Sekunden lang die Freigabekarte und das Gateway versucht es nach einem Netzwerk-Timeout zweimal erneut. Ein Cache, der die TTL nur beim Abruf geprüft hat, kann den letzten Versuch nach Ablauf beginnen. Das Ziel gibt einen Authentifizierungsfehler zurück, doch der Audit-Datensatz kann ihn fälschlich als Netzwerkproblem oder Ablehnung durch den Benutzer einordnen.

Setzen Sie die nutzbare Frist einmal anhand maßgeblicher Metadaten:

usable_until = min(authority_not_after, fetched_at + local_cache_cap)
latest_start = usable_until - approval_budget - connect_budget - clock_margin

Diese Budgets sind Betriebsentscheidungen und verlängern die Lebensdauer der Anmeldedaten nicht. Liegt now nach latest_start, rufen Sie eine neue Generation ab und zeigen Sie eine neue Freigabe, falls sich die genehmigte Aktion wesentlich ändern würde. Verlängern Sie ein Vault-Lease nie nur, um eine Anfrage zu retten, die in einer lokalen Warteschlange gewartet hat. Die Verlängerung ist eine Lebenszyklusentscheidung und kann das Risikofenster vergrößern.

Für erneute Versuche gilt dieselbe Disziplin. Ein Versuch darf Anmeldedaten nur wiederverwenden, wenn die Generation weiterhin übereinstimmt, die nutzbare Frist noch läuft und die entfernte Operation sicher wiederholt werden kann. HTTP-Idempotenz und Gültigkeit der Anmeldedaten sind getrennte Prüfungen. Ein gültiges Token macht einen doppelten POST nicht harmlos.

Verwenden Sie bei statischen Anmeldedaten ohne vom Aussteller vorgegebenen Ablauf eine lokale Cache-Obergrenze, um die Lebensdauer alter Kopien zu beschränken. Nennen Sie sie Cache-Richtlinie, nicht Ablauf. Der Lebenszyklusablauf benötigt nach der Rotation weiterhin eine Generationsmeldung oder eine erzwungene erneute Auflösung. Andernfalls kann das Gateway während einer Überschneidung ein noch gültiges altes Token weiterverwenden und den Entfernungstest erfolgreich aussehen lassen, bis der Anbieter das Token tatsächlich deaktiviert.

Widerruf ist ein durchgängiges Ereignis

Widerruf funktioniert nur, wenn die Lebenszyklusinstanz die Anmeldedaten beim Aussteller deaktiviert und das Gateway jede zukünftige Verwendung der zwischengespeicherten Generation beendet. Nur eine Seite zu bereinigen reicht nicht aus.

Vault stellt Administratoren einen konkreten Mechanismus bereit. vault lease revoke macht ein Lease ungültig, und ein Widerruf nach Präfix kann Leases unter einem Pfad ungültig machen. Die HashiCorp-Befehlsdokumentation unterscheidet außerdem normalen Widerruf von erzwungener Entfernung. Eine erzwungene Entfernung kann dazu führen, dass Vault ein Lease vergisst, obwohl die Secrets Engine den Widerruf nicht ausführen konnte. Vault und Ziel stimmen dann nicht mehr überein. Behandeln Sie diese Warnung als Vorfall, nicht als Erfolgsmeldung.

Ein Desktop-Gateway sollte ein Widerrufssignal empfangen, wenn das Lebenszyklussystem eines senden kann. Zusätzlich braucht es eine Abwehr, die den aktuellen Status abfragt. Vor einer sensiblen Verwendung kann es die Generation erneut prüfen oder wieder auflösen. Bei kurzen Vault-Leases können eine strenge TTL und ein kurzer Cache ausreichen. Bei einem statischen API-Token sollte der Rotationskoordinator den Gateway-Cache beim Wechsel ungültig machen und das entfernte Token anschließend direkt an einem harmlosen Endpunkt prüfen.

Bereits laufende Aktionen brauchen eine ausdrückliche Regel. Ein Widerruf kann Aktionen zuverlässig blockieren, die noch nicht begonnen haben. Er kann eine von einer entfernten API bereits akzeptierte Anfrage, eine bestätigte Datenbanktransaktion oder einen an die Shell übergebenen SSH-Befehl unter Umständen nicht rückgängig machen. Das Gateway sollte den Status authorized, dispatched, acknowledged oder unknown vermerken, statt zu behaupten, der Widerruf habe die Wirkung gelöscht.

Testen Sie den vollständigen Pfad und bewahren Sie die alte Generation in einem kontrollierten Testwerkzeug auf:

1. Führen Sie über das Gateway einen harmlosen Lesevorgang aus und erfassen Sie die Generation.
2. Widerrufen Sie das Lease oder rotieren und deaktivieren Sie die statischen Anmeldedaten beim Aussteller.
3. Versuchen Sie dieselbe Aktion über ein Gateway mit warmem Cache.
4. Versuchen Sie eine direkte Verwendung der entfernten Anmeldedaten aus dem Testwerkzeug.
5. Bestätigen Sie beide Fehler und ordnen Sie sie den Lebenszyklus- und Ausführungsdatensätzen zu.

Wenn Schritt drei gelingt, hat das Gateway den Widerruf ignoriert. Wenn Schritt vier gelingt, hat der Lebenszyklusablauf nicht beim Aussteller widerrufen. Wenn beide fehlschlagen, die Datensätze aber nicht dieselbe Generation identifizieren, kann das Reaktionsteam weiterhin nicht beweisen, was geschehen ist.

Zuordnung braucht Aussteller- und Aufruferidentität

Lebenszyklusprotokolle beantworten, wer Anmeldedaten erstellt, verlängert, rotiert oder widerrufen hat. Gateway-Protokolle beantworten, welcher lokale Prozess welche Aktion angefordert hat, wer sie freigegeben hat, welches Ziel sie empfing und welches Ergebnis zurückkam. Keines ersetzt das andere.

Dynamische Anmeldedaten verbessern die Zuordnung beim Aussteller, wenn jedes Lease eine eigene entfernte Identität erzeugt. Die HashiCorp-Dokumentation zur Datenbank-Secrets-Engine weist darauf hin, dass eindeutige erzeugte Benutzernamen den Datenbankzugriff einer bestimmten Dienstinstanz zuordnen lassen. Das ist nützlich, doch der Datenbankbenutzer bezeichnet weiterhin die gemietete Identität des Gateways, nicht unbedingt den Agentenprozess, der die Abfrage angefordert hat.

Das Gateway braucht deshalb eine beständige Sitzungsidentität und eine vertrauenswürdige Prozessidentität. Eine PID allein ist schwach, weil Betriebssysteme PIDs wiederverwenden und Prozesse Kinder starten können. Erfassen Sie die auf der Plattform verfügbare Identität der ausführbaren Datei, gegebenenfalls ihre Signaturinstanz, den Elternprozess, Beginn und Ende der Sitzung sowie eine nicht erratbare Sitzungs-ID. Binden Sie jeden Aktionsdatensatz an diese Sitzung.

Das Verknüpfungsfeld ist die Generation der Anmeldedaten. Schreiben Sie die Vault-Lease-ID oder die statische Rotationsereignis-ID sowohl in den Lebenszyklusdatensatz als auch in den Aktionsdatensatz des Gateways. Erfassen Sie außerdem die entfernte Anfrage-ID, wenn die API eine zurückgibt. Bei einem Vorfall müssen Prüfer dieser Kette folgen können:

agent session -> gateway action -> credential generation -> issuer event -> remote request

Schreiben Sie keine Secret-Werte, Authorization-Header, privaten Schlüssel oder aufgelösten Umgebungsblöcke in diese Protokolle. Nachträgliches Schwärzen ist unzuverlässig, weil Ausnahmen, Debug-Dumps und Trace-Exporter die Daten vorher kopieren können. Bauen Sie strukturierte Datensätze aus einer Positivliste sicherer Felder auf.

Die Zuordnung scheitert auch, wenn alle Aktionen ein langlebiges Servicekonto teilen und kein Gateway-Datensatz erhalten bleibt. Rotation verkürzt die Lebensdauer dieses Kontos, identifiziert aber nicht den Aufrufer. Umgekehrt können perfekte Prozessprotokolle nicht beweisen, welche Generation das Ziel erreichte, wenn das Gateway Lease oder Version auslässt. Bewahren Sie beide Dimensionen.

Umgebungsinjektion überschreitet die Grenze

Ein Ablauf, der ein Secret in die Umgebung eines Agenten einfügt, gibt dem Agenten den Besitz. Das Desktop-Gateway kontrolliert dann nicht mehr jede Verwendung. Diese Unterscheidung ist bei CLI-Mustern von 1Password besonders wichtig, weil bequemer Abruf wie Ausführungskontrolle wirken kann.

Die 1Password-Dokumentation erklärt, dass op run einen Unterprozess startet und ihm Secrets als Umgebungsvariablen bereitstellt. Das kann sinnvoll sein, um Klartext aus einer eingecheckten .env-Datei herauszuhalten. Der Kindprozess kann die Variable jedoch lesen, ausgeben, an einen anderen Prozess weitergeben oder für eine nicht freigegebene Anfrage verwenden. op inject löst Referenzen in einen Konfigurationsstrom auf, und op read gibt dem Aufrufer einen aufgelösten Wert zurück. Keiner dieser Pfade entspricht einem Gateway, das das Secret vom Agenten fernhält.

Bei von Menschen bedienten Skripten, die das breite Verhalten eines nativen SDK benötigen, kann Umgebungsinjektion vertretbar sein. Bei einem autonomen Agenten, dessen Netzwerk- und SSH-Aktionen bei jeder Verwendung kontrolliert werden müssen, zerstört sie die beabsichtigte Grenze. Geben Sie die eingeschränkte Abrufidentität dem Gateway und stellen Sie dem Agenten aktionsförmige Werkzeuge bereit.

Die initialen Anmeldedaten verdienen weiterhin Beachtung. 1Password empfiehlt Servicekonten für minimale Berechtigungen und erlaubt die Beschränkung auf bestimmte Tresore. Das verkleinert den Abrufbereich des Gateways. Es beschränkt nicht, was das Gateway nach dem Abruf tun kann. Daher bleiben dessen Aktionsfläche, Freigaben und Prüfung ausgehender Ziele nötig.

Vermeiden Sie einen beliebten Umweg: das Secret in einem Wrapper auflösen, das Gateway mit den Anmeldedaten als Parameter aufrufen und versprechen, das Gateway werde sie schwärzen. Der Agent oder Wrapper hatte den Wert bereits, Shell-Verlauf und Prozessinspektion können ihn offenlegen, und das Gateway kann nicht beweisen, dass keine zweite Verwendung stattfand. Übergeben Sie die Referenz über die Grenze und lösen Sie sie in der ausführenden Komponente auf.

Freigabe ist von Rotation unabhängig

Frisch rotierte Anmeldedaten können weiterhin eine schädliche Aktion autorisieren, und eine sorgfältig freigegebene Aktion kann veraltete Anmeldedaten verwenden. Rotation und Freigabe reduzieren verschiedene Risiken, deshalb darf keine unbemerkt die andere ersetzen.

Die Lebenszyklusinstanz beantwortet: „Ist diese Generation gültig?“ Das Gateway beantwortet: „Darf dieser Aufrufer diese Wirkung jetzt auslösen?“ Der entfernte Dienst beantwortet: „Hat diese authentifizierte Identität die Berechtigung?“ Halten Sie alle drei Antworten sichtbar. Eine grüne Freigabekarte sollte ohne Prüfung durch das Gateway keine Aktualität der Anmeldedaten andeuten. Ein aktuelles Lease darf eine für einen zerstörerischen Aufruf vorgeschriebene menschliche Freigabe nicht umgehen.

Die Wiederverwendung einer Freigabe braucht einen definierten Umfang. Wenn das Gateway eine Agentensitzung freigibt, binden Sie die Freigabe an die Prozesssitzung und beenden Sie sie, wenn der Prozess endet oder der Benutzer sie widerruft. Wenn Anmeldedaten bei jedem Aufruf eine Freigabe verlangen, muss die Rotation diese Anforderung für die neue Generation erhalten. Ein neuer Wert darf sensible Anmeldedaten nicht auf eine schwächere Voreinstellung zurücksetzen.

Der Freigabetext sollte Aktion, Ziel und Aufrufer beschreiben, nicht das Secret. „Signiertem Prozess X erlauben, POST /deployments in Produktion auszuführen“ liefert eine Entscheidungsgrundlage. „Verwendung von API-Schlüssel prod-3 erlauben“ zwingt Menschen, die Absicht aus Bestandsnamen abzuleiten, und gewöhnt sie an undurchsichtige Aufforderungen.

Sallyport setzt diese Ausführungsseite für HTTP-API- und SSH-Aktionen unter macOS um: Agenten verbinden sich über seinen MCP-Shim, Anmeldedaten bleiben im verschlüsselten prozessinternen Tresor und die Anwendung führt die Aktion aus. Seine festen Kontrollen trennen den gesperrten Tresor, die Freigabe der Prozesssitzung und eine optionale Freigabe bei jeder Verwendung. Wenn ein anderes System Anmeldedaten erstellt oder rotiert, bleibt eine externe Lebenszyklusinstanz erforderlich.

Doppelte Rotation schafft zwei scheinbare Besitzer

Lassen Sie Lebenszyklussystem und Gateway nicht dieselben Anmeldedaten unabhängig rotieren. Manche Teams nennen das Tiefenverteidigung, doch zwei Schreiber erzeugen mehrdeutige Generationen, unzuverlässige Rücknahmen und Rennen beim Widerruf.

Nehmen wir einen statischen Anbieter, der zwei aktive API-Schlüssel erlaubt. Der 1Password-Ablauf erstellt Schlüssel B, prüft ihn und aktualisiert das maßgebliche Element, während Schlüssel A für eine kurze Umstellungszeit aktiv bleibt. Gleichzeitig erstellt der lokale Planer des Gateways Schlüssel C, weil seine Kopie von A ein festgelegtes Alter erreicht hat. Einige Prozesse lösen B auf, der warme Cache enthält weiterhin A und das Gateway beginnt C zu verwenden. Die Deaktivierung von A beweist fast nichts, weil niemand weiß, ob B oder C bestehen bleiben soll.

Ein Koordinator muss die Rotationszustandsmaschine besitzen. Bei einem dynamischen Vault-Secret stellt Vault diese Koordination bereits über Rollen und Leases bereit; das Gateway verbraucht Leases und rotiert das entfernte Konto nicht. Bei einem über 1Password verwalteten statischen Datensatz kann der Rotationsauftrag Anbieter und gespeichertes Element koordinieren; das Gateway beobachtet Generationsänderungen und macht seinen Cache ungültig. Lokale Verschlüsselung durch das Gateway schützt eine gespeicherte Kopie, doch eine erneute Verschlüsselung des Speichers ist keine Rotation beim Aussteller.

Eine brauchbare statische Rotation hat ausdrückliche Zustände statt nur eines Kennzeichens rotated:

prepared -> activated -> distributed -> old_disabled -> verified
                |             |
                +-> rollback <-+

prepared bedeutet, dass der Aussteller eine Kandidatengeneration erstellt hat. activated bedeutet, dass eine harmlose authentifizierte Anfrage damit erfolgreich war. distributed bedeutet, dass die maßgebliche Referenz auf den Kandidaten auflöst und Gateways die neue Generation bestätigen. old_disabled bedeutet, dass der Aussteller die vorherige Generation ablehnt. verified bedeutet, dass ein Gateway mit warmem Cache und ein direktes Testwerkzeug mit dem alten Wert scheitern. Eine Rücknahme darf nur möglich bleiben, solange die vorherige Generation absichtlich aktiv ist.

Das Gateway sollte Zustandsänderungen mit Referenzen und Generations-IDs erhalten, niemals beide Secret-Werte. Ein Ungültigkeitsereignis könnte credential_ref, old_generation, new_generation und effective_at benennen. Beim Empfang verwirft das Gateway den alten Cache-Eintrag, bricht daran gebundene Aktionen in der Warteschlange ab und löst beim Beginn der nächsten freigegebenen Aktion erneut auf. Wenn das Ereignis nie eintrifft, müssen Cache-Obergrenze und Generationsprüfung trotzdem zum maßgeblichen Wert führen.

Eine Rücknahme verlangt dieselbe Sorgfalt. Ein 1Password-Element wieder auf Schlüssel A zu richten funktioniert nicht, nachdem der Anbieter A deaktiviert hat. Einen neuen Wert unter dem alten Anzeigenamen auszustellen stellt auch die alte Generation nicht wieder her. Der Koordinator sollte nur erstellen oder reaktivieren, was der Anbieter unterstützt, eine neue Generations-ID vergeben und die normalen Phasen für Verteilung und Prüfung erneut ausführen.

Halten Sie den Verantwortungsdatensatz so klein, dass er während eines Vorfalls gelesen werden kann. Nennen Sie für jede Referenz einen Rotationskoordinator, einen Aussteller, eine Gateway-Cache-Richtlinie, einen Widerrufsbefehl und eine Person oder einen Dienst, die eine Notfallentfernung beginnen dürfen. Wenn zwei Zeilen behaupten, die nächste Generation erstellen zu können, halten Sie an. Das ist keine Redundanz, sondern ein Rennen mit geheimem Material.

Prüfen Sie die Verbindung statt einzelner Kästen

Ein bestandener Vault-Test und ein bestandener Gateway-Test beweisen nicht, dass ihre Übergabe funktioniert. Prüfen Sie an der Grenze alte Caches, überlappende Generationen, verzögerte Freigaben, gescheiterte Widerrufe, Prozessneustarts und fehlende Verknüpfungsfelder.

Verwenden Sie eine entbehrliche Zielidentität und führen Sie vor der Produktion diese Abnahmematrix aus:

Führen Sie die Matrix auf denselben Pfaden aus, die Agenten später verwenden. Ein Mock, der auf Befehl 401 liefert, zeigt nicht, ob ein echtes Datenbank-Plug-in einen Benutzer entfernt hat, ob ein Anbieter überlappende Schlüssel erlaubt oder ob eine SSH-Verbindung nach dem Widerruf der Anmeldedaten aktiv bleibt.

Definieren Sie ausdrückliche Erfolgskriterien. Nach not_after beginnt keine Aktion. Eine widerrufene oder entfernte Generation scheitert auch über einen warmen Cache. Jeder Ausführungsdatensatz lässt sich ohne geheimes Material genau einer Lebenszyklusgeneration zuordnen. Ein gescheiterter Widerruf beim Aussteller verhindert die Behauptung einer erfolgreichen Entfernung. Ein Freigabedatensatz identifiziert eine Prozesssitzung und läuft nach der eingestellten Kontrolle ab.

Die Grenze erfüllt ihren Zweck, wenn Fehler auf ihren Bereich beschränkt bleiben. Vault oder der 1Password-Rotationsablauf kann Anmeldedaten ersetzen, ohne dem Agenten Secret-Werte zu zeigen. Das Gateway kann Freigabeverhalten ändern, ohne zum Aussteller zu werden. Das Reaktionsteam kann eine Generation widerrufen, eine Sitzung stoppen und sehen, welche entfernten Wirkungen bereits eingetreten sein könnten. Wenn Ihr Verbindungstest diese drei Operationen nicht unabhängig beweist, korrigieren Sie den Vertrag, bevor Sie ein weiteres Secret-System hinzufügen.