# Zugangsdaten hinter einem Aktions-Gateway mit Nachweis rotieren

Das Ersetzen eines ablaufenden API-Tokens oder einer SSH-Identität sollte langweilig sein. Gefährlich wird es, wenn jeder Agent, jedes Shell-Profil, jedes Repository-Geheimnis und jedes lokale Tool eine eigene Kopie besitzt. In diesem Setup rotieren Sie nicht eine Zugangsdaten. Sie suchen nach einer unbekannten Zahl von Kopien, hoffen, alle gefunden zu haben, und unterbrechen Arbeit an Stellen, an denen niemand getestet hat.

Ein Aktions-Gateway verändert die Aufgabe. Das Gateway besitzt die Zugangsdaten, führt die externe Anfrage aus und gibt das Ergebnis an den Agent zurück. Die Rotation hat damit einen einzigen Ort, an dem Geheimnisse gespeichert werden, eine kontrollierte Umschaltung und Nachweise, die eine Agent-Session von der verwendeten Identität trennen. Diese Trennung ist bei einem Vorfall besonders wichtig, weil sonst leicht «Dieser Prozess hat die Anfrage gesendet» mit «Dieser Prozess besaß das Token» verwechselt wird.

Ich habe Teams erlebt, die eine Rotation für abgeschlossen erklärten, sobald ein neuer Wert in einem Secret-Manager auftauchte. Danach blieb ein alter Deployment-Schlüssel in der `authorized_keys`-Datei eines Kontos, oder eine vergessene lokale Umgebungsvariable hielt ein abgelaufenes API-Token am Leben. Eine Rotation ist erst abgeschlossen, wenn der Ersatz den vorgesehenen Aktionspfad erfolgreich durchlaufen hat und sich die alte Identität nicht mehr authentifizieren kann.

## Rotation ist eine Identitätsänderung, kein String-Austausch

Bei einer Zugangsdatenrotation wird eine authentifizierende Identität durch eine andere ersetzt. Außerdem muss nachgewiesen werden, dass der Zugriff wie vorgesehen umgezogen ist. Einen neuen Token in ein Feld einzufügen, ist nur ein einzelner Schritt dieser Änderung.

Halten Sie in Ihren Notizen und Werkzeugen vier Dinge auseinander:

- Die externe Identität: ein API-Token, ein Client-Geheimnis, ein SSH-Schlüsselpaar oder die von einem Anbieter akzeptierte Zugangsdaten eines Dienstkontos.
- Der Zugangsdaten-Eintrag: der verschlüsselte Datensatz, in dem die Identität und Informationen zu ihrer Verwendung gespeichert sind.
- Das Autorisierungsziel: das API-Konto, Repository, Maschinenkonto, der Host oder Netzwerkendpunkt, der die Zugangsdaten akzeptiert.
- Die Agent-Session: der konkrete Prozess, der eine Aktion angefordert hat.

Menschen vermischen regelmäßig den ersten und den vierten Punkt. Das führt zu fehlerhaften Vorfallsberichten. Eine Agent-Session kann einen Endpunkt über ein Gateway aufgerufen haben, ohne das Bearer-Token lesen zu müssen. Umgekehrt kann ein geleaktes Token von einem Prozess verwendet werden, der in Ihrem Agent-Journal nie auftaucht. Das sind unterschiedliche Untersuchungen mit unterschiedlichen Maßnahmen zur Eindämmung.

Dasselbe gilt für den Ablauf. Ein Anbieter kann ein Token zu einem bestimmten Zeitpunkt ablaufen lassen, während der Gateway-Eintrag als gespeicherte Information vollkommen intakt bleibt. Der Eintrag läuft nicht von selbst ab. Sie müssen die externe Identität vor der Ablehnung durch den Anbieter ersetzen, die neue Identität prüfen und die alte außer Betrieb nehmen.

Die NIST Special Publication 800-57, Teil 1, behandelt Kryptoperioden als mehr als bloße Kalendereinträge. Die Ausführungen verbinden eine Kryptoperiode mit Offenlegung, Nutzung und Kompromittierungsrisiko. Das ist auch für API- und SSH-Zugangsdaten der richtige Ansatz. Ein Token mit weitreichendem Schreibzugriff, häufiger Verwendung oder unklarer Zuständigkeit verdient eine kürzere geplante Lebensdauer als eine eng begrenzte Identität für eine einzelne Nur-Lese-Aufgabe. Machen Sie daraus kein Ritual, bei dem jeden Freitag Zeichenfolgen geändert werden, während der Berechtigungsumfang übermäßig groß bleibt.

Eine saubere Beschreibung der Rotation sollte so klingen: «Die Session des Build-Agents verwendete für diese Anfrage den Zugangsdaten-Eintrag deploy-api-prod. Dieser Eintrag wurde von der Anbieter-Token-ID mit der Endung 4K2 auf die Anbieter-Token-ID mit der Endung P9M geändert. Das alte Token wurde widerrufen, nachdem der neue Eintrag die erwartete Aktion abgeschlossen hatte.» Das Token selbst gehört nicht hinein.

## Legen Sie das Geheimnis an einem Ort ab, bevor der Ablauf die Entscheidung erzwingt

Eine kontrollierte Rotation ist nicht möglich, solange Zugangsdaten in Agent-Prompts, Repository-Dateien, Shell-Variablen und kopierten Konfigurationen liegen. Die Konsolidierung kommt zuerst, auch wenn das Ablaufdatum näher rückt.

Beginnen Sie mit einem Inventar, das der Nutzung folgt und nicht nur dem Speicherort. Fragen Sie jedes Team, welche externen Aufrufe und SSH-Ziele ein Agent erreichen kann. Halten Sie für jede Antwort Anbieter- oder Host-Konto, Zugangsdaten-Typ, Besitzer, vorgesehene Aktion, Berechtigungsumfang, Ablaufverhalten und die Frage fest, ob die Zugangsdaten an anderer Stelle auftauchen. Beim letzten Feld beginnt die unangenehme Arbeit.

Ein Repository-Scan findet offensichtliche Fehler, kann aber das Fehlen von Kopien nicht beweisen. Suchen Sie nach Namen von Umgebungsvariablen, Konfigurationsschlüsseln, Deployment-Vorlagen, kopierten Pfaden zu privaten Schlüsseln und Dokumentationen, die dazu auffordern, ein Token in eine Agent-Konfiguration einzufügen. Prüfen Sie auch die Tool-Definitionen des Agents. Wenn ein Tool `token`, `api_key`, `authorization` oder rohe Inhalte privater Schlüssel als Argument akzeptiert, kann der Agent weiterhin Geheimnisse mit sich führen, selbst wenn ein anderes System eine Kopie aufbewahrt.

Für HTTP ist die gewünschte Struktur einfach: Der Agent liefert eine Aktion und gewöhnliche Request-Daten, während das Gateway die gespeicherten Zugangsdaten auswählt und das Autorisierungsmaterial erst beim Senden der Anfrage einfügt. Ein Tool-Aufruf des Agents könnte konzeptionell so aussehen:

```json
{
  "credential": "deploy-api-prod",
  "method": "POST",
  "url": "https://api.example.internal/releases",
  "headers": {"Content-Type": "application/json"},
  "body": {"revision": "a81c2f"}
}
```

Ein Bearer-Token darf auch nicht unter einem freundlichen Feldnamen darin auftauchen. Einen Authorization-Header im Tool-Ergebnis zurückzugeben, wäre derselbe Fehler in umgekehrter Richtung. Redigieren Sie ihn an der Aktionsgrenze und nicht erst später in einem Chat-Protokoll.

Bei SSH sollte der Agent eine Verbindung über einen benannten Zugangsdaten-Eintrag und ein Ziel anfordern. Er sollte weder einen privaten Schlüsselblock noch eine temporäre private Schlüsseldatei oder eine Anweisung erhalten, in `~/.ssh` zu suchen. Ein privater Schlüssel im Arbeitsverzeichnis eines Agents überlebt in Caches, im Editorverlauf, in Archiven und manchmal in einem Commit. Ich habe genug solcher Dateien bereinigt, um «temporär» als Wort ohne Sicherheitsbedeutung zu betrachten.

Sallyport speichert API- und SSH-Schlüssel in einem verschlüsselten Tresor innerhalb der macOS-App und führt HTTP- und SSH-Aktionen aus, ohne das Geheimnis an den Agent weiterzugeben. Dadurch haben Sie einen einzigen Eintrag, den Sie ändern müssen. Trotzdem müssen ältere Kopien gefunden und entfernt werden, die vor dieser Umstellung entstanden sind.

## Geben Sie jeder Zugangsdaten einen Besitzer und einen Zweck

Eine Zugangsdaten kann mehrere berechtigte Nutzer haben, braucht aber trotzdem einen verantwortlichen Besitzer und einen festgelegten Zweck. Gemeinsame Zuständigkeit ist meist ein höflicher Ausdruck dafür, dass niemand Ablauf, Berechtigungsumfang oder Stilllegung prüft.

Benennen Sie Einträge so, dass ein Betreiber die Autorisierungsgrenze erkennen kann, ohne Geheimnismaterial zu sehen. `billing-write-prod` sagt mehr als `token-final-2`. `github-deploy-repo-a` sagt mehr als `automation-key`. Nehmen Sie die Umgebung auf, wenn sie das Ziel beeinflusst, und vermeiden Sie den Namen einer Person, wenn die Zugangsdaten zu einer Servicefunktion gehören. Menschen gehen, der Zweck eines Dienstes sollte erkennbar bleiben.

Legen Sie keine unabhängigen Ziele hinter ein gemeinsames Token, nur um die Zahl der Einträge zu verringern. Dieser Abkürzung ist beliebt, weil eine einzige Erneuerung einfach erscheint. Sie verursacht drei Probleme:

1. Sie können nicht erkennen, welches Ziel die Rotation ausgelöst hat.
2. Eine Ausweitung des Umfangs für eine Nutzung vergrößert den Zugriff für alle anderen Nutzungen.
3. Der Widerruf der Identität während eines Vorfalls unterbricht unabhängige Arbeit.

Ein Eintrag kann eine eng zusammengehörige Gruppe von Aktionen gegen ein Anbieter-Konto abdecken, wenn Umfang und Besitzer tatsächlich identisch sind. Treffen Sie diese Entscheidung ausdrücklich und nicht als Standard. Wenn der Build-Publisher und der Support-Export unterschiedliche Berechtigungen benötigen, brauchen sie unterschiedliche Identitäten, auch wenn beide dieselbe API aufrufen.

Für SSH gilt dieselbe Disziplin. Ein SSH-Schlüssel für ein Deployment-Konto auf einer Hostgruppe sollte nicht zugleich für den Zugriff auf Produktionsdatenbanken dienen, nur weil beide SSH verwenden. Setzen Sie Beschränkungen möglichst serverseitig: ein eigenes Konto, einen eingeschränkten Befehl, eine Quellenbeschränkung, sofern Ihr Netzwerk dies unterstützt, und einen eindeutigen Kommentar am autorisierten Schlüssel. Ein Kommentar erzwingt keinen Zugriff, macht aber einen übrig gebliebenen alten Schlüssel sichtbar, wenn jemand unter Zeitdruck `authorized_keys` prüft.

Das Handbuch zu OpenSSHs `authorized_keys` dokumentiert Optionen wie `command=`, `restrict` und `from=`. Diese Optionen sind nur dann hilfreich, wenn Sie den genauen Befehlspfad testen, den die Automatisierung benötigt. Ich habe erlebt, wie ein gut gemeinter `restrict`-Eintrag eine Portweiterleitung unterbrach, von der ein Deployment-Job stillschweigend abhing. Das findet man besser bei einer geplanten Rotation als um Mitternacht. Fügen Sie nicht blind jede verfügbare Einschränkung hinzu. Verwenden Sie die Einschränkungen, die zur benannten Aktion passen.

## Verwenden Sie ein Überschneidungsfenster mit festem Endzeitpunkt

Lassen Sie alte und neue Zugangsdaten nur so lange gemeinsam aktiv, wie es zur Validierung des Ersatzes und zur Wiederherstellung nach einer fehlgeschlagenen Umschaltung nötig ist. Die Überschneidung ist ein Sicherheitsmechanismus und kein dauerhafter Betriebsmodus.

Einige Anbieter erlauben mehrere API-Tokens oder mehrere aktive Client-Zugangsdaten. Erstellen Sie zuerst den Ersatz, notieren Sie eine sicher aufzubewahrende Kennung und laden Sie ihn in den Gateway-Eintrag. Führen Sie anschließend eine harmlose Aktion über denselben Weg aus, den der Agent im normalen Betrieb verwendet. Ein Lese-Endpunkt, das Erstellen eines Entwurfs in einem Testprojekt oder eine Anfrage zur Ermittlung der aufrufenden Identität kann ausreichen, sofern die Aktion den erforderlichen Umfang und das richtige Zielkonto prüft.

Verlassen Sie sich nicht auf einen allgemeinen Endpunkt «Token gültig», wenn der Agent normalerweise Releases veröffentlicht oder Tickets ändert. Ein Token kann gültig sein, aber der Schreibumfang kann fehlen, das Token kann auf ein Sandbox-Konto zeigen oder scheitern, weil das Gateway den falschen Header-Typ einfügt. Testen Sie Methode, URL-Familie, Konto und Payload-Struktur der tatsächlichen Aktion mit einem harmlosen Objekt.

Legen Sie den Widerrufszeitpunkt der alten Zugangsdaten fest, bevor Sie testen. Wenn Sie diesen Zeitpunkt nicht benennen können, haben Sie kein Überschneidungsfenster geschaffen, sondern eine weitere dauerhafte Zugangsdaten.

Eine praktische Reihenfolge sieht so aus:

1. Erstellen Sie die neue Anbieter-Zugangsdaten mit dem erforderlichen Umfang und einer bekannten Ablaufregel.
2. Aktualisieren Sie den einen Gateway-Eintrag und behalten Sie die bisherige Zugangsdaten nur für die erklärte Überschneidung.
3. Führen Sie eine enge Aktion über eine autorisierte Agent-Session oder eine von einem Betreiber kontrollierte Testsession aus.
4. Prüfen Sie das Ergebnis beim Anbieter und sehen Sie im Aktionsjournal nach, ob Session und Ziel wie erwartet aufgeführt sind.
5. Widerrufen oder entfernen Sie die alte Anbieter-Zugangsdaten und wiederholen Sie anschließend die enge Aktion.

Der abschließende Test nach dem Widerruf ist keine Formsache. Er findet den peinlichen Fall, in dem Ihr Test unbemerkt das alte Token verwendet hat, weil eine Umgebungsvariable, eine Proxy-Konfiguration oder ein anderer Zugangsdaten-Eintrag Vorrang hatte. Das passiert häufiger, als viele zugeben.

Wenn ein Anbieter nur eine aktive API-Zugangsdaten erlaubt, gibt es keine echte Überschneidung. Planen Sie ein Änderungsfenster, erfassen Sie vor dem Wechsel eine Ausgangsaktion, ersetzen Sie das Geheimnis im Gateway, führen Sie sofort den engen Test aus und halten Sie einen Kontoinhaber bereit, der bei einer Ablehnung durch den Anbieter einen Ersatz ausstellen kann. Lösen Sie das fehlende Überschneidungsfenster nicht, indem Sie das neue Token vorab in die Agent-Konfiguration legen.

## Validieren Sie den tatsächlich verwendeten Agent-Pfad

Ein Rotationstest muss Gateway, Zugangsdaten-Auswahl, Anfragekonstruktion, externe Autorisierung und Ergebnisverarbeitung durchlaufen. Wenn Sie jede Komponente einzeln testen, bleiben genau dort Lücken, in denen Fehler bei Zugangsdaten verborgen sind.

Machen Sie die HTTP-Testanfrage so spezifisch, dass Sie sie in den Anbieter-Logs erkennen können. Verwenden Sie, wenn möglich, ein Idempotenz-Token oder erstellen Sie ein klar gekennzeichnetes, wegwerfbares Objekt. Prüfen Sie, ob der Anbieter das vorgesehene Konto oder die richtige Identität meldet. Bestätigen Sie anschließend, dass das Aktionsjournal einen passenden Aufruf mit Ziel, Ergebnis und Session-Referenz enthält, ohne Zugangsdaten auszugeben.

Ein allgemeiner Shell-Test hilft, das Verhalten des Anbieters zu isolieren, beweist aber weniger, als viele denken:

```sh
curl -sS -D /tmp/headers.txt \
  -H "Authorization: Bearer $NEW_TOKEN" \
  https://api.example.internal/v1/whoami
```

Die erwartete Ausgabe enthält oft den Status `200` in `/tmp/headers.txt` und einen Body, der das Dienstkonto identifiziert. Das zeigt, dass der Anbieter das Token akzeptiert. Es beweist nicht, dass Ihr Aktions-Gateway denselben Header einfügt, den richtigen Eintrag auswählt oder verhindert, dass der Agent `$NEW_TOKEN` sieht. Verwenden Sie diesen Test nur unter der Kontrolle eines Betreibers und entfernen Sie die Variable anschließend aus der Shell. Fügen Sie niemals ein echtes Token in ein Ticket oder eine gespeicherte Terminalaufzeichnung ein.

Testen Sie bei SSH denselben Hostnamen, Benutzer und dieselbe Befehlsform, die die Automatisierung benötigt. Die folgende Prüfung des öffentlichen Schlüssels hilft bei der Diagnose der Serverautorisierung, ohne private Informationen in der Ausgabe preiszugeben:

```sh
ssh -o BatchMode=yes -o IdentitiesOnly=yes \
  deploy@host.example.internal 'id && test -w /srv/releases && echo write-ok'
```

`BatchMode=yes` lässt einen Authentifizierungsfehler sofort fehlschlagen, statt auf ein interaktives Passwort zu warten. `IdentitiesOnly=yes` verhindert, dass ein SSH-Client jeden anderen in einem Agent geladenen Schlüssel ausprobiert. Nehmen Sie eine erfolgreiche Anmeldung mit `ssh deploy@host` nicht als Beweis, dass die Deployment-Aktion funktioniert. Das entfernte Konto kann eine Shell akzeptieren, aber den vom Job verwendeten Befehl, das Verzeichnis oder die Einschränkung durch einen erzwungenen Befehl ablehnen.

Das OpenSSH-Handbuch zu `ssh` erklärt, dass `IdentitiesOnly` die vom Client angebotenen Identitäten begrenzt. Diese Option findet ein häufiges falsch positives Ergebnis auf Entwicklerrechnern: Der lokale Agent ist mit einem persönlichen Schlüssel erfolgreich, während der neue Automatisierungsschlüssel in der Produktion scheitern würde. In einem Gateway-Aufbau führen Sie die entsprechende Prüfung über den SSH-Pfad des Gateways aus, wo der ausgewählte gespeicherte Schlüssel eindeutig ist.

Testen Sie auch Fehler und nicht nur Erfolg. Versuchen Sie bewusst eine Anfrage mit einer nicht autorisierten Methode oder einen SSH-Befehl außerhalb der vorgesehenen Berechtigung. Sie wollen eine klare Ablehnung beim entfernten System und einen korrekten Journaleintrag. Wenn eine angeblich eng begrenzte Zugangsdaten eine unabhängige Aktion erfolgreich ausführt, stoppen Sie die Rotation und reduzieren Sie den Umfang, bevor Sie die alte Identität außer Betrieb nehmen.

## Bei SSH scheitert die Rotation auf dem Server, wenn alte öffentliche Schlüssel bleiben

Das Ersetzen eines privaten SSH-Schlüssels im Tresor widerruft den alten Schlüssel nicht. Der Server akzeptiert die alte Identität weiterhin, bis ihr öffentlicher Schlüssel aus jeder vertrauenswürdigen Autorisierungsquelle entfernt wurde.

SSH erschwert das Inventar, weil öffentliche Schlüssel an mehreren Stellen auftauchen können: in `~/.ssh/authorized_keys`, einem Identitätsdienst, einer Cloud-Instanz-Metadateneinstellung, einer Vorlage für Konfigurationsverwaltung oder einer Deploy-Key-Schnittstelle des Anbieters. Finden Sie zuerst die maßgebliche Quelle. Wenn die Konfigurationsverwaltung `authorized_keys` neu schreibt, kann eine manuelle Notfall-Löschung beim nächsten Lauf wieder rückgängig gemacht werden.

Erzeugen Sie mit den freigegebenen Werkzeugen eine Ersatzidentität und speichern Sie ihren privaten Teil nur an der Gateway-Grenze. Installieren Sie den neuen öffentlichen Teil neben dem alten. Geben Sie jedem Eintrag einen Kommentar mit Zweck und Rotationsdatum und testen Sie ihn über den vorgesehenen Weg. Sobald er funktioniert, entfernen Sie den alten öffentlichen Eintrag aus der Quelle der Wahrheit und bestätigen Sie, dass der Server ihn ablehnt.

Sie können den Fingerabdruck eines öffentlichen Schlüssels prüfen, ohne einen privaten Schlüssel offenzulegen:

```sh
ssh-keygen -lf deploy-release-ed25519.pub
# 256 SHA256:exampleFingerprint deploy-release-2025 (ED25519)
```

Wichtiger als der Beispiel-Fingerprint ist die Struktur der Ausgabe: Bitlänge, Fingerprint, Kommentar und Schlüsseltyp. Tragen Sie den tatsächlichen Fingerprint in den Änderungsnachweis ein. Fügen Sie die umgebenden Autorisierungsoptionen des öffentlichen Schlüssels nicht in einen vagen Screenshot ein. Übernehmen Sie die genaue serverseitige Regel in Ihre geprüfte Konfiguration, damit ein anderer Betreiber ersehen kann, ob sie einen erzwungenen Befehl oder eine Quellenbeschränkung enthält.

Führen Sie anschließend einen Negativtest mit dem alten Schlüssel durch, bevor Sie die letzte kontrollierte Kopie zerstören. Der Server sollte ihn nach der Entfernung ablehnen. Wenn dieser Test nicht möglich ist, weil Sie den alten privaten Schlüssel nicht mehr besitzen, prüfen Sie stattdessen die maßgebliche Quelle der autorisierten Schlüssel und die Audit-Aufzeichnungen des Anbieters. Halten Sie diese Einschränkung im Nachweis fest. Einen nicht durchgeführten Widerrufstest vorzutäuschen, ist schlechter, als eine unvollständige Prüfung zu dokumentieren.

Rotieren Sie einen SSH-Schlüssel nicht, indem Sie eine Datei am selben Pfad überschreiben und einen unbekannten Client neu starten. Lang laufende Prozesse können Verbindungen offen halten, SSH-Agents können eine alte Identität anbieten und ein Hilfsprogramm kann einen Dateideskriptor zwischenspeichern. Ein zustandsloser Aktionshelfer reduziert diese Unklarheit, weil jede Verbindung mit einer bekannten Auswahl beginnt. Entscheidend ist das beobachtbare Verhalten, nicht eine bevorzugte Programmiersprache.

## Autorisierung und Rotation getrennt behandeln

Die Genehmigung, einen Agent eine Aktion ausführen zu lassen, unterscheidet sich von der Genehmigung, bei jedem Aufruf eine bestimmte Zugangsdaten zu verwenden. Wer beides gleich behandelt, erzeugt entweder Genehmigungsmüdigkeit oder lässt sensible Identitäten zu weit offen.

Eine Session-Kontrolle beantwortet: «Darf dieser neu gestartete Agent-Prozess während dieses Laufs Aktionen ausführen?» Sie hilft, einen neuen Prozess abzufangen, bevor er externen Zugriff erhält. Eine Kontrolle pro Aufruf beantwortet: «Darf diese konkrete Zugangsdaten jetzt verwendet werden?» Das passt zu einer Zahlung, einem Produktions-Release oder einer Zugangsdaten, deren Umfang jede einzelne Nutzung prüfenswert macht.

Fordern Sie nicht für jeden harmlosen Statusabruf eine menschliche Genehmigung an, nur weil der Rotationsprozess alle nervös gemacht hat. Menschen bestätigen wiederholte identische Aufforderungen, ohne sie zu lesen. Verwenden Sie häufige Genehmigungen für Identitäten, deren einzelne Aktion eine Entscheidung erfordert, und eine klar begrenzte Session-Genehmigung für den Rest. Rotation sollte Betreiber nicht dazu bringen, Warnungen einfach wegzuklicken.

Sallyports Entscheidungskette hält die Tresorgrenze absolut. Danach wird standardmäßig ein neuer Agent-Prozess für seine Session autorisiert. Für die Verwendung einer ausgewählten Zugangsdaten kann zusätzlich eine Genehmigung pro Aufruf verlangt werden. Während der Rotation kann ein Betreiber so die Testsession erlauben und gleichzeitig für jede Verwendung der neuen Produktionszugangsdaten eine ausdrückliche Bestätigung verlangen, bis die Umschaltung abgeschlossen ist.

Die Tresorgrenze hat eine eigene Aufgabe. Ein gesperrter Tresor muss Aktionen ablehnen, unabhängig davon, was eine Agent-Session zuvor durfte. So erhält ein Betreiber bei einem vermuteten Leck oder unerwartetem Verhalten einen harten Stopp. Dadurch wird die Anbieter-Zugangsdaten nicht widerrufen. Sperren Sie den Zugriff und widerrufen oder deaktivieren Sie trotzdem die externe Identität, wenn jemand sie außerhalb des Gateways kopiert haben könnte.

Halten Sie kurz fest, wer einen Ausnahme-Test in der Produktion genehmigt hat und warum. Machen Sie aus Genehmigungsnotizen kein Tagebuch. Session-Identität, Zeitpunkt, Zugangsdaten-Eintrag, Ziel und Änderungsreferenz reichen aus, um die Genehmigung mit dem Rotationsereignis zu verbinden.

## Audit-Nachweise müssen zwei verschiedene Fragen beantworten

Ein nützlicher Rotationsnachweis kann sowohl «Was hat der Agent getan?» als auch «Können wir dem Nachweis vertrauen?» beantworten. Ein einfaches Anwendungslog beantwortet nach bearbeiteten Dateien, gelöschten Zeilen oder vermischten Routineaufrufen und Vorfällen oft keine der beiden Fragen zuverlässig.

Für die erste Frage braucht es operative Felder: Session-Identität, Signaturinstanz oder Prozessidentität, sofern vorhanden, Zeitpunkt, Aktionstyp, Ziel, Name des Zugangsdaten-Eintrags, Ergebnis und eine Referenz auf die Anbieteranfrage, sofern es eine gibt. Das Journal darf keine Bearer-Tokens, Passwörter, privaten Schlüssel oder vollständigen Header mit Geheimnissen speichern. Logs mit Zugangsdaten machen jeden Leser des Logs zu einem weiteren Besitzer dieser Zugangsdaten.

Die zweite Frage betrifft die Integrität. Die Bezeichnung «append-only» reicht nicht, wenn ein Administrator das Log vom Vortag umschreiben kann. Eine Hash-Kette macht jeden Eintrag vom vorherigen abhängig. Bei der Prüfung kann so erkannt werden, ob Einträge entfernt oder verändert wurden. Sie beweist nicht, dass eine Aktion nie stattgefunden hat, und macht falsche Eingaben nicht wahr. Sie erschwert jedoch, stille Änderungen als ursprünglichen Nachweis auszugeben.

Hier zahlen sich getrennte Session- und Aktivitätsjournale aus. Ein Session-Journal beantwortet, welcher Agent-Prozess Autorität erhalten hat und ob jemand diesen Lauf widerrufen hat. Ein Aktivitätsjournal beantwortet, welche einzelnen HTTP- oder SSH-Aktionen währenddessen stattfanden. Wenn ein API-Token um 14:00 Uhr rotiert wird, können Sie die Aufrufe vor und nach der Umschaltung prüfen, ohne jede Session-Genehmigung als Beweis für jede Anfrage zu behandeln.

Sallyport erstellt beide Ansichten aus einem verschlüsselten, schreibgeschützten Audit-Log und kann die Kette mit `sp audit verify` offline prüfen, ohne den Tresorschlüssel zu benötigen. Führen Sie die Prüfung vor und nach einer sensiblen Rotation aus und bewahren Sie das Ergebnis mit dem Änderungsnachweis auf. Eine erfolgreiche Prüfung besagt, dass die aufgezeichnete Kette intern konsistent ist. Sie ersetzt nicht die Prüfung der tatsächlichen Ziele und Ergebnisse.

Halten Sie bei einer risikoreichen Rotation diese Nachweise in einem kompakten Eintrag fest:

- Warum die Zugangsdaten geändert wurde und wem das Autorisierungsziel gehört.
- Sichere Kennungen der alten und neuen Anbieter-Zugangsdaten sowie das geplante Ende der Überschneidung.
- Die enge Validierungsaktion und ihr Ergebnis beim Anbieter.
- Die an der Validierung beteiligten Agent-Session- und Aktivitätsreferenzen.
- Ein Nachweis oder eine dokumentierte Einschränkung beim Widerruf der alten Identität.

Damit kann ein späterer Ermittler eine normale geplante Änderung von einer unerklärten neuen Zugangsdaten unterscheiden. Außerdem wird sichtbar, wenn eine Prüfung des Widerrufs fehlt, bevor Monate vergehen.

## Behandeln Sie ein vermutetes Leck zuerst als Eindämmungsfall

Wenn Sie vermuten, dass ein Agent ein Geheimnis gesehen oder exportiert hat, stoppen Sie den Zugriff zuerst. Ein neues Token zu erstellen, ohne das offengelegte Token zu deaktivieren, lässt den alten Weg für jeden offen, der es kopiert hat.

Sperren Sie das Aktions-Gateway für eine sofortige lokale Eindämmung, widerrufen Sie aktive Agent-Sessions, die nicht weiterarbeiten sollen, und deaktivieren oder widerrufen Sie die Anbieter-Zugangsdaten. Bewahren Sie die relevanten Session- und Aktivitätsnachweise auf, bevor Aufräumjobs den Kontext löschen. Stellen Sie anschließend eine neue Identität aus, deren Umfang auf die notwendige Arbeit begrenzt ist.

Warten Sie nicht auf den perfekten Beweis, dass der Wert geleakt wurde. Ein Token in einem Agent-Transkript, Shell-Verlauf, Repository-Commit, Build-Log oder kopierten Chat reicht aus, um es als offengelegt zu behandeln. Entfernen Sie bei einem privaten SSH-Schlüssel den passenden öffentlichen Schlüssel aus jeder vertrauenswürdigen Quelle und suchen Sie nach Kopien des privaten Materials an den Stellen, an denen die Automatisierung Artefakte schreibt. Einen privaten Schlüssel zu rotieren, während sein alter öffentlicher Schlüssel autorisiert bleibt, ist keine Eindämmung.

Wenn der Dienst wieder läuft, ermitteln Sie, wie das Geheimnis die Grenze überschritten hat. Die Ursachen sind meist erschreckend gewöhnlich: Ein Tool-Parameter akzeptierte rohe Zugangsdaten, ein Debug-Log gab Request-Header aus, ein Entwickler kopierte eine lokale Umgebungsdatei in einen Agent-Arbeitsbereich oder ein Fallback-Client umging das Gateway. Beheben Sie diesen Weg, bevor Sie den Vorfall für abgeschlossen erklären. Andernfalls beginnt das Ersatzgeheimnis lediglich seinen eigenen Countdown bis zum nächsten Leck.

## Machen Sie Ablaufarbeit zu einem geplanten Betriebstest

Eine Kalendererinnerung sollte einen wiederholbaren Test, eine Prüfung der Zuständigkeit und eine Widerrufsentscheidung auslösen. Sie sollte nicht zu einer panischen Bitte führen, ein neues Token in die Konfigurationsdatei zu kopieren, die zuletzt funktioniert hat.

Prüfen Sie jeden Zugangsdaten-Eintrag vor dem Ablaufdatum beim Anbieter. Bestätigen Sie, dass der benannte Besitzer weiterhin für das externe Konto verantwortlich ist, der dokumentierte Zweck noch besteht, der Berechtigungsumfang zur Aktion passt und die ausgewählten Agent-Sessions weiterhin Zugriff benötigen. Wenn eine dieser Antworten nein lautet, nehmen Sie die Identität außer Betrieb, statt sie zu rotieren.

Üben Sie bei weiterhin erforderlichen Identitäten die enge Validierungsaktion früh genug, um Änderungen am Anbieter-Konto, neue SSH-Einschränkungen oder veränderte API-Berechtigungen zu entdecken. Bewahren Sie den Übungsnachweis getrennt von der tatsächlichen Rotation auf, damit niemand einen alten erfolgreichen Test mit einem Nachweis verwechselt, dass der heutige Ersatz funktioniert.

Der unangenehme Test findet die meisten Fehler: Wiederholen Sie nach dem Widerruf der alten Zugangsdaten genau die Aktion, von der der Agent abhängt, und prüfen Sie, ob das Journal sie der vorgesehenen Session und dem richtigen Eintrag zuordnet. Wenn dieser Test scheitert, haben Sie einen begrenzten Fehler mit Besitzer, Nachweisen und bekanntem Rückweg. Das ist deutlich besser, als ein abgelaufenes Geheimnis mitten in einem autonomen Deployment zu entdecken.