# Reaktion auf einen verlorenen Entwickler-Mac: Zugriff sicher widerrufen

Ein fehlender Entwickler-Mac ist zuerst ein Vorfall mit Zugangsdaten und erst danach ein Hardwareproblem. Der Laptop kann unberührt zurückkommen. Er kann aber auch entsperrt, offline oder in fremden Händen sein, während seine Browser-Sitzungen, SSH-Schlüssel, Cloud-CLI-Caches, lokalen Repositories und Agentenprozesse weiterhin Berechtigungen besitzen.

Die schlechteste Reaktion ist, auf Gewissheit zu warten. Die bekommt man nur selten. Beginne mit reversibler Eindämmung, sichere Beweise, bevor hektische Änderungen den Zusammenhang verwischen, und rotiere anschließend die Zugangsdaten, mit denen ein Eindringling seinen Zugriff ausweiten könnte. Eine ruhige Reihenfolge ist besser als hastige Passwortänderungen in jedem Dienst.

## Behandle das Verschwinden bis zur Eindämmung als aktiven Zugriff

Gehe davon aus, dass der fehlende Mac authentifizierte Anfragen senden kann, bis du die wichtigen Zugriffswege gestoppt hast. Diese Annahme beschuldigt niemanden und sagt keinen Angriff voraus. Sie verhindert den typischen Fehler, ein Ticket zur Gerätesuche wie einen reinen Hardwarevorgang zu behandeln, statt wie ein Ereignis für die Zugriffskontrolle.

Notiere sofort vier Zeitpunkte: wann der Mac zuletzt physisch gesehen wurde, wann er zuletzt nachweislich gesperrt war, wann sein Benutzer zuletzt mit sensiblen Systemen gearbeitet hat und wann der Verlust gemeldet wurde. Diese Zeitpunkte legen den Prüfzeitraum fest. Lass die Erinnerung nicht stundenlang ungenau werden, während alle Besprechungsräume durchsucht werden.

Halte fest, was zum letzten sicheren Zeitpunkt geöffnet war. Nützlich sind konkrete Angaben: ein Terminal mit Verbindung zu einem Produktionssystem, ein Agentenlauf, der Bereitstellungscode bearbeitete, ein Browser-Tab in einer Cloud-Konsole, eine lokale Portweiterleitung, ein Repository mit Zugangsdaten in der Historie oder ein für eine Migration entsperrter Passwortmanager. «Am Backend gearbeitet» hilft der zuständigen Person kaum weiter.

Ordne die Situation ein, bevor du Aufgaben verteilst:

- Das Gerät war gesperrt und ging in einem kontrollierten Büro verloren.
- Das Gerät war entsperrt oder der Sperrstatus ist unbekannt.
- Das Gerät verschwand im öffentlichen Nahverkehr, in einem Hotel oder an einem anderen unkontrollierten Ort.
- Das Gerät hatte aktiven Produktionszugriff oder einen autonomen Agentenprozess.
- Das Gerät gehörte einem Administrator, Release Engineer oder Besitzer eines Organisationskontos.

Ein gesperrtes Gerät mit Festplattenverschlüsselung und einem hardwaregeschützten Secret-Speicher ist eine bessere Ausgangslage als ein entsperrtes Gerät. Das ist trotzdem kein Grund, auf den Widerruf zu verzichten. Der Geräteschutz erschwert das Auslesen des Speichers. Er kann keine Aktionen rückgängig machen, die bei entsperrtem Gerät ausgeführt wurden, entfernte Sitzungen ungültig machen oder zeigen, ob jemand den Rechner vor der Sperrung benutzt hat.

Bestimme eine Person für Entscheidungen und eine weitere für die Zeitleiste. In einem kleinen Team kann das dieselbe Person sein. Die Dokumentation sollte Konto, Zugangsdatenklasse, Maßnahme, Zeitpunkt, ausführende Person und Fundstelle des Beweises enthalten. Eine Tabelle reicht in der ersten Stunde aus. Ein Chatverlauf mit Reaktions-Emojis ist kein Vorfallsprotokoll.

Verwende die letzte Netzwerkadresse des fehlenden Macs nicht als Beweis für seine Sicherheit. Der Netzwerkstandort kann veraltet, weitergeleitet oder gemeinsam genutzt sein. Kontaktiere eine mutmaßliche Finderin oder einen mutmaßlichen Finder nicht über Konten, die auf dem Gerät geöffnet sein könnten. Nutze einen separaten Kanal.

## Sichere das Gerät, ohne die Untersuchung zu zerstören

Fernsperre und Fernlöschung sind sinnvolle Maßnahmen, aber nur ein Teil der Eindämmung. Löse sie über deinen Geräteverwaltungsdienst oder den Gerätesuchdienst des Betriebssystems aus, sobald die bekannten Fakten das rechtfertigen. Halte den Zeitpunkt der Anfrage und jede Zustellbestätigung fest.

Ein Fernbefehl wartet, bis das Gerät den Dienst erreicht. Ist der Mac offline, bleibt der Befehl möglicherweise ausstehend. Wenn jemand ihn offline halten kann, wird er vielleicht lange nicht ausgeführt. Deshalb darf der Widerruf von Zugangsdaten nicht auf eine Bestätigung der Löschung warten.

Bitte die Geräteverwaltung, verfügbare Verwaltungsdaten zu sichern, bevor sich Aufbewahrungsfristen ändern oder Daten durch eine spätere Löschung verschwinden. Nützlich sind unter anderem Serien- oder Inventarnummer, zugewiesener Benutzer, letzter Kontaktzeitpunkt, Betriebssystemversion, zuletzt gemeldete IP-Adresse, FileVault-Escrow-Status, sofern eure Organisation ihn erfasst, sowie der Status von Fernsperre oder Fernlöschung. Sammle, was deine Werkzeuge liefern. Erfinde aus fehlenden Feldern keine lückenlose Geschichte.

Wurde der fehlende Mac mit einem persönlichen Apple Account verwendet, sollte die Besitzerin oder der Besitzer die Gerätesuche unter Begleitung der Vorfallsleitung übernehmen. Bitte nicht um persönliche Zugangsdaten. Die Organisation braucht die Bestätigung, dass eine Sperr- oder Löschanfrage gestellt wurde, nicht den Zugriff auf private Daten.

Sichere den lokalen Arbeitskontext aus anderen Systemen. Deaktiviere das VPN des Geräts oder dessen Zero-Trust-Gerätestatus, sofern dein Anbieter eine gerätespezifische Sperre erlaubt. Widerrufe sein Zertifikat, falls vorhanden. Entferne das Gerät aus Gruppen der Geräteverwaltung, die Netzwerkzugriff gewähren. Deaktiviere Remote-Desktop- und Synchronisierungsrechte, die diesem Endpunkt zugeordnet sind.

Jetzt sollten auch unbeaufsichtigte Arbeiten gestoppt werden, die an das Gerät gebunden sind. Ein lokaler geplanter Job kann auf einem ausgeschalteten Laptop nicht weiterlaufen. Ein Remote-Agent, eine Cloud-Entwicklungsumgebung, ein CI-Runner oder eine Browserautomatisierung, die von dort gestartet wurde, kann jedoch unabhängig weiterarbeiten. Ermittle den Ausführungsort, bevor du annimmst, dass der fehlende Mac die Kontrolle darüber hat.

Vermeide die verbreitete, aber schwache Empfehlung, «einfach das Hauptpasswort des Benutzers zu ändern». Sie wirkt attraktiv, weil sie schnell sichtbar ist. Das kann helfen, besonders wenn jemand das Passwort beobachtet haben könnte. Häufig bleiben aber persönliche Zugriffstokens, OAuth-Freigaben, SSH-Schlüssel, Browser-Sitzungen, CLI-Refresh-Tokens und dienstspezifische Zugangsdaten aktiv. Ein Passwort-Reset ist eine Aufgabe in einem umfassenderen Eindämmungsplan.

## Aktive Agentenberechtigungen stoppen, bevor der nächste Aufruf erfolgt

Ein Coding-Agent mit Zugriff auf externe Aktionen verdient dieselbe Dringlichkeit wie ein interaktives Terminal. Er kann weiterhin eine API aufrufen oder SSH öffnen, wenn sein Prozess läuft, seine Sitzung autorisiert bleibt und das Gerät das Netzwerk erreicht. Stoppe die Berechtigung des Agenten am Gateway und bei jedem entfernten Dienst, der seine Zugangsdaten akzeptiert hat.

Ermittle zuerst jeden Lauf, der vom fehlenden Mac stammen könnte. Sichere Prozesskennung, Start- und Endzeit der Sitzung, zugewiesene Zugangsdaten, Zielsysteme und letzte abgeschlossene Aktion. Verwendet dein Agenten-Host eine Sitzungsliste, widerrufe die betroffenen Sitzungen, statt auf ihren Ablauf zu warten. Kannst du die Läufe des fehlenden Geräts nicht unterscheiden, widerrufe alle Sitzungen dieses Benutzers und erstelle später neue.

Sallyports Sitzungsjournal kann einen Agentenlauf sofort widerrufen, während das Aktivitätsjournal die einzelnen Aufrufe der Anwendung festhält. Nutze beide Aufzeichnungen bei einem Geräteverlust: Die eine zeigt, welchen Lauf du beenden musst, die andere, was dieser Lauf zuvor versucht hat.

Verwechsle einen Agentennamen nicht mit einer vertrauenswürdigen Identität. «Claude Code» in einer Prozessbezeichnung oder einem Terminaltitel beweist weder, welche ausführbare Datei lief, noch wer sie signiert hat oder ob ein Angreifer einen kopierten Prozess gestartet hat. Ein ordentlicher Freigabenachweis sollte die Code-Signaturinstanz des aufrufenden Prozesses nennen. Halte diese Identität zusammen mit der Sitzung fest und vergleiche sie mit der bekannten Entwicklungsumgebung.

Ein Gateway kann künftige Aufrufe blockieren, aber eine Anfrage, die bereits eine API erreicht hat, nicht zurückholen. Hat ein Agent ein Bereitstellungstoken erstellt, einen Benutzer hinzugefügt, eine Repository-Einstellung geändert oder Daten hochgeladen, untersuche den betreffenden Dienst direkt. Das Agentenjournal liefert einen Hinweis. Der Zieldienst entscheidet, ob die Aktion erfolgreich war.

Bei Agenten, die über einen MCP-Server verbunden sind, widerrufe oder deaktiviere den Verbindungspfad für die Identität des betroffenen Arbeitsplatzes. Prüfe anschließend die Agentenkonfiguration in Quellcode-Repositories, Shell-Profilen, Projektverzeichnissen und verwalteten Konfigurationen. Spiele diese Konfiguration erst auf einen Ersatz-Mac zurück, wenn alte Tokens entfernt, Befehlshooks geprüft und Verweise auf persönliche oder Produktionskonten untersucht wurden.

Die Genehmigung für jeden einzelnen Aufruf ist hier besonders hilfreich. Sie erzwingt im Moment der Verwendung eine menschliche Entscheidung und kann den Schaden begrenzen, nachdem jemand den Arbeitsplatz verlassen hat. Sie ersetzt aber nicht den Widerruf nach dem Verlust eines Laptops. Eine bereits erteilte Genehmigung kann für den laufenden Prozess gültig bleiben. Ein zuvor verwendetes externes Token kann kopiert worden sein oder eine eigene Gültigkeitsdauer besitzen.

## Zugangsdaten in der Reihenfolge rotieren, in der ein Angreifer sie missbrauchen würde

Die Rotation von Zugangsdaten ist eine geordnete Aufgabe, bei der Wege zur Rechteausweitung entfernt werden. Rotiere zuerst Zugangsdaten, mit denen sich weiterer Zugriff schaffen lässt, und danach solche, die nur einen risikoarmen Entwicklungsdienst lesen. In umgekehrter Reihenfolge kannst du eine Stunde lang unbedeutende Tokens zurücksetzen, während ein Cloud-Administratortoken weiter funktioniert.

Beginne mit Identität und Kontrollzugriff: Sitzungen des Identitätsanbieters, Organisationsbesitzerkonten, Cloud-Administratorrollen, Zugriff auf Secret-Manager, Administration der Quellcodeorganisation, Konten für Bereitstellungskontrolle und Administration der Geräteverwaltung. Wenn eine Person all diese Rechte besitzt, ist das nach der Eindämmung ein Architekturproblem. Zuerst muss der aktuelle Vorfall gelöst werden.

Danach rotierst du Zugang, mit dem Code verschoben oder Workloads ausgeführt werden können: CI-Zugangsdaten, Veröffentlichungstokens für Paket-Registries, Signaturschlüssel, Bereitstellungsschlüssel, Cloud-Workload-Tokens, Container-Registry-Tokens und SSH-Schlüssel für Bastion-Hosts oder Produktionssysteme. Zum Schluss folgen Ticketsysteme, Dokumentationswerkzeuge, API-Tokens mit geringeren Rechten und einzelne Dienstpasswörter.

Nutze für jede Zugangsdatenart dieses Arbeitsblatt. Es verhindert den häufigen Fehler, ein Geheimnis zu rotieren und dabei Systeme zu übersehen, die ihm weiterhin vertrauen.

| Feld | Was festzuhalten ist |
| --- | --- |
| Zugangsdaten | Genaue Kennung von Token, Schlüssel, Zertifikat, Sitzung oder OAuth-Freigabe |
| Besitzer | Verantwortliche Person oder verantwortliches Dienstkonto |
| Berechtigung | Systeme und Aktionen, die damit erlaubt sind |
| Speicherort | Bekannte Speicher, CI-Variablen, Gerätedateien, Anwendungseinstellungen |
| Maßnahme | Widerrufen, rotieren, Konto deaktivieren, öffentlichen Schlüssel entfernen oder neu ausstellen |
| Validierung | Test, der beweist, dass die alte Berechtigung scheitert und legitime Arbeit weiterhin möglich ist |

Überschreibe ein Geheimnis nicht einfach und hoffe auf das Beste. Widerrufe das alte Objekt, wenn der Anbieter eine getrennte Widerrufsfunktion bietet. Erstelle den Ersatz mit dem engsten Geltungsbereich, der den gewünschten Ablauf noch ermöglicht. Aktualisiere die autorisierten Verbraucher. Prüfe danach, dass die alten Zugangsdaten scheitern. Halte Kennung und Zeitpunkt fest, niemals den Geheimniswert.

Bei einem Bearer-Token kann die Prüfung aus einem harmlosen authentifizierten Endpunkt bestehen, der das alte Token ablehnen und das neue akzeptieren sollte. Entferne bei SSH den alten öffentlichen Schlüssel aus jedem autorisierten Pfad. Teste anschließend eine Verbindung mit diesem Schlüssel und erwarte eine Ablehnung. Widerrufe bei einer OAuth-Freigabe die Freigabe beim Identitätsanbieter und prüfe aktive Sitzungen oder die Tokenliste der Anwendung.

Ein Test über die Kommandozeile macht das Verhalten sichtbar. Ersetze den Endpunkt durch einen sicheren, der die authentifizierte Identität zurückgibt, und führe den Test nur auf einem sauberen Gerät aus:

```
curl -i -H "Authorization: Bearer $OLD_TOKEN" https://api.example.internal/whoami
```

Nach dem Widerruf sollte eine Authentifizierungsfehlermeldung erscheinen, etwa `HTTP/1.1 401 Unauthorized` oder die dokumentierte Antwort des Anbieters für ein ungültiges Token. Eine `200`-Antwort bedeutet, dass das alte Token noch funktioniert. «Wir haben es im Secret-Manager geändert» ist kein Beweis, da der entfernte Dienst das alte Geheimnis weiterhin akzeptieren kann.

SSH verdient besondere Aufmerksamkeit. Entwickler erinnern sich oft an `~/.ssh/id_ed25519` und vergessen Deploy Keys, hardwaregeschützte Schlüssel, SSH-Zertifikate, weitergeleitete Agenten, bei Quellcodeanbietern registrierte Schlüssel, in CI gespeicherte Schlüssel und öffentliche Schlüssel auf Bastion-Hosts. Suche auf der Seite der Zugriffskontrolle, nicht nur auf der verlorenen Festplatte. Jeder Ort, der den öffentlichen Schlüssel akzeptiert, muss ihn künftig ablehnen.

## Aktivitäten vor und nach dem Verlustzeitraum prüfen

Die Audit-Prüfung sollte beantworten, ob Zugriff stattgefunden hat, welche Berechtigung verwendet wurde, was sich geändert hat und ob die Änderung einen neuen Rückweg geschaffen hat. Wer Logs nur nach offensichtlichen zerstörerischen Befehlen durchsucht, übersieht die vorbereitenden Schritte eines Angreifers.

Lege den Prüfzeitraum vom letzten bekannten sicheren Zeitpunkt bis zu dem Moment fest, an dem alle Zugangsdaten mit hohen Rechten widerrufen wurden. Erweitere ihn rückwirkend, wenn das Gerät schon vor dem Verlust unerklärliche Aktivitäten zeigte. Erweitere ihn nach vorn, solange alte Sitzungen oder Zugangsdaten aktiv bleiben. Verwende im Vorfallsprotokoll eine einheitliche Zeitzone.

Prüfe zuerst Ereignisse beim Identitätsanbieter. Suche nach erfolgreichen und fehlgeschlagenen Anmeldungen, neuen MFA-Methoden, Änderungen an Wiederherstellungsoptionen, OAuth-Einwilligungen, neuen Anwendungsfreigaben, erstellten Sitzungen, ungewöhnlichen Geräteregistrierungen und Änderungen an Administratorrollen. Eine fehlgeschlagene Anmeldung ist nicht harmlos, wenn sie zwischen erfolgreichen Erneuerungen oder einer neuen Sitzung aus demselben Kontext auftaucht.

Untersuche danach Cloud- und Infrastruktur-Audit-Trails auf Aktionen, die dauerhaften Zugriff schaffen: neue Zugriffsschlüssel, Dienstprinzipale, API-Tokens, Rollenzuweisungen, Richtlinienänderungen, Firewall-Änderungen, erstellte Compute-Instanzen, gelesene Geheimnisse, Snapshot-Exporte und Änderungen an der Audit-Log-Konfiguration. Auch ein Token mit reinen Leserechten kann genug Konfiguration offenlegen, um ein mächtigeres Geheimnis zu finden.

Auch die Quellcodeverwaltung verdient dieselbe Sorgfalt. Prüfe Ergänzungen von Deploy Keys, Ereignisse zu persönlichen Zugriffstokens, Änderungen an SSH-Schlüsseln, Branch-Schutz, Webhooks, Repository-Übertragungen, installierte Anwendungen, Veröffentlichungen von Releases und Paketen sowie Änderungen an Workflow-Dateien. Ein geänderter CI-Workflow kann einem späteren Lauf mehr Zugriff geben, als der gestohlene Mac je hatte.

Prüfe bei SSH-Zielen Authentifizierungslogs, aufgezeichnete Befehle, Shell-Historien nur als ergänzende Beweise, Protokolle privilegierter Befehle und neue Einträge in `authorized_keys`. Eine erfolgreiche Anmeldung mit einem Schlüssel nach dem gemeldeten Verlustzeitpunkt braucht eine Erklärung, selbst wenn die Quelladresse vertraut aussieht. Der Ausgang eines Unternehmens-VPNs kann viele Personen unter derselben Adresse erscheinen lassen.

Sallyport bewahrt hinter seinen Journalen ein schreibblindes, verschlüsseltes und hashverkettetes Audit-Log. Sichere das verfügbare Audit-Material auf einem sauberen Mac und führe die Offline-Integritätsprüfung aus, bevor du die Einträge als Beweise behandelst:

```
sp audit verify
```

Eine erfolgreiche Prüfung sollte melden, dass die Kette validiert wurde. Bei einem Fehler musst du die betroffenen Dateien sichern, den Fehler dokumentieren und untersuchen, warum die Prüfung fehlgeschlagen ist. Der Befehl prüft die Kette über dem Chiffretext und benötigt den Tresorschlüssel nicht. Er bestätigt, dass die aufgezeichnete Reihenfolge nicht verändert wurde, nicht dass jede entfernte Aktion erfolgreich war.

Erstelle eine kurze Ereignistabelle, statt Rohlogs in einen Chat zu kopieren. Führe Zeitstempel, Akteur oder Zugangsdatenkennung, Quelle, Aktion, Ziel, Ergebnis, Beweisreferenz und Einordnung auf. Markiere Ereignisse als erwartet, verdächtig, nachweislich schädlich oder ungeklärt. Die Spalte «ungeklärt» ist wichtig. Teams schließen Vorfälle oft, weil sie eine harmlose Erklärung gefunden haben, während mehrere Kontoänderungen noch ungeprüft sind.

## Nach dauerhaften Zugängen suchen, nicht nur nach Diebstahl

Wer einen Entwicklerrechner nutzen kann, sucht möglicherweise einen unauffälligen Rückweg statt einer sofortigen Änderung in der Produktion. Suche nach neuen Zugangsdaten, veränderter Automatisierung und Kontrolländerungen, die einen Passwort-Reset überstehen.

Prüfe in jeder Kontrollebene kürzlich erstellte Zugriffe: neue Benutzer, API-Tokens, OAuth-Anwendungen, öffentliche SSH-Schlüssel, Deploy Keys, Dienstkonten, persönliche Zugriffstokens, Wiederherstellungsoptionen, Geräteanmeldungen und delegierte Administrationsrollen. Vergleiche sie mit einer vorhandenen Ausgangsbasis. Gibt es keine, sollte der Dienstverantwortliche jeden neuen Eintrag manuell bestätigen, statt die Liste als normal einzustufen.

Suche in Codeänderungen nach geänderten CI-Definitionen, Build-Skripten, Einstellungen zur Paketveröffentlichung, Abhängigkeits-URLs, Webhook-Endpunkten und Geheimnisreferenzen. Ein schädlicher Workflow versteckt sich oft in einem kleinen Pull Request oder einer Konfigurationsänderung, die wie routinemäßige Wartung aussieht. Prüfe zusammengeführte Änderungen und offene Branches, die im Prüfzeitraum erstellt wurden.

Untersuche außerdem Datenbewegungen. Prüfe Artefaktdownloads, Repository-Klone, sofern dein Anbieter sie protokolliert, Exporte aus Kundensystemen, Auflistungs- und Abrufereignisse in Objektspeichern sowie neu freigegebene Dokumente. Die Sichtbarkeit ist möglicherweise nicht vollständig, insbesondere bei einem lokalen Klon, der vor dem Vorfall erstellt wurde. Halte diese Einschränkung offen im Protokoll fest, statt anzunehmen, dass kein Export stattgefunden hat.

Reagiere nicht auf jede Anomalie über. Eine Bereitstellung zu ungewöhnlicher Uhrzeit kann ein genehmigtes Ticket haben. Prüfe sie mit der Person oder dem Automatisierungskonto, das sie ausgelöst hat, über einen Kommunikationskanal, der nichts mit dem fehlenden Laptop zu tun hat. Sende keine Bestätigungsanfrage an ein Konto, dessen Sitzung möglicherweise offengelegt wurde, und akzeptiere dessen Antwort nicht als Beweis.

Wenn du dauerhaften Zugriff findest, weite die Untersuchung aus. Ein neuer SSH-Schlüssel auf einem Bastion-Host bedeutet, dass jeder darüber erreichbare Host geprüft werden muss. Bei einer neuen Quellcodeanwendung müssen ihre Repository-Berechtigungen und die Workflows geprüft werden, die ihr Token verwenden. Bei einer neuen Cloud-Rolle müssen Rollenzuweisungen und Aktivitäten untersucht werden. Entferne den dauerhaften Zugriff zuerst, sichere die Beweise und rotiere anschließend alle Zugangsdaten, die er auslesen konnte.

## Zugriff von einem sauberen Endpunkt aus wiederherstellen, nicht aus einem Backup-Image

Ein Ersatz-Mac sollte neue Berechtigungen bewusst erhalten. Beim Zurückspielen eines vollständigen Backups können neben dem Quellcode auch alte Tokens, SSH-Schlüssel, Browser-Cookies, Agentenkonfiguration, Shell-Hooks und unbekannte Dateien zurückkehren. Diese Bequemlichkeit ist während einer aktiven Untersuchung teuer.

Nimm den neuen Mac in die normale Geräteverwaltung auf, installiere Betriebssystemupdates, aktiviere Festplattenverschlüsselung und Bildschirmsperre und installiere freigegebene Entwicklungswerkzeuge aus vertrauenswürdigen Quellen. Stelle Quellcode erst aus entfernten Repositories wieder her, nachdem du den Kontozugriff geprüft hast. Erzeuge lokale Einstellungen nach Möglichkeit aus versionierter, geprüfter Konfiguration neu.

Verwende während der Reaktion ein separates Konto oder Browserprofil für administrative Aufgaben. Halte den täglichen Entwicklungszugriff enger begrenzt. Diese Trennung reduziert den Schaden, wenn eine Entwicklungsumgebung irgendwann eine nicht vertrauenswürdige Erweiterung, ein Paketskript oder eine Agentenanweisung ausführt.

Stelle SSH-Zugangsdaten für das neue Gerät neu aus. Bevorzuge ein von der Organisation verwaltetes SSH-Zertifikat oder einen eigenen Schlüssel pro Gerät, sofern eure Infrastruktur das unterstützt. Ein gemeinsamer privater Schlüssel, der von Laptop zu Laptop kopiert wird, macht jeden Geräteverlust zu einer umfassenden Migration. Namenskonventionen für öffentliche Schlüssel, die Gerät und Besitzer erkennen lassen, beschleunigen den späteren Widerruf.

Erstelle frische API-Tokens nur, wenn ein Werkzeug sie wirklich benötigt. Gib einem Build-System eigene Zugangsdaten, statt ein Entwicklertoken in CI zu kopieren. Setze ein Ablaufdatum, sofern der Dienst das unterstützt. Dokumentiere, wem das Token gehört und wo es verwendet wird. Ein Geheimnis, das niemand zuordnen kann, wird später selbst zum Vorfallsproblem.

Stelle den Agentenzugriff zuletzt wieder her. Prüfe, welche ausführbare Datei eine Verbindung herstellt, welche Code-Signaturinstanz sie vorweist, welche Kanäle sie verwenden darf und welche Zugangsdaten sie anfordern kann. Beginne nach Möglichkeit mit Lese- oder Entwicklungszugang. Beobachte die ersten Aktionen, statt wegen Zeitdrucks eine weitreichende Genehmigung zu erteilen.

Lege keine Zugangsdaten in Agenten-Prompts, Konfigurationstexten, Issue-Kommentaren oder Shell-Befehlen ab, die in der Historie landen. Ein Aktions-Gateway sollte das Geheimnis verwahren und es erst bei der Ausführung der Anfrage einfügen. Diese Grenze hält Klartext-Zugangsdaten vom Agenten fern, entschuldigt aber keine nachlässige Freigabe der Aktionen selbst.

## Den Vorfall erst schließen, wenn alte Wege nachweislich scheitern

Du kannst einen Vorfall wegen eines fehlenden Macs schließen, wenn der verlorene Endpunkt keinen nutzbaren Weg mehr zu relevanten Berechtigungen hat, der Prüfzeitraum untersucht wurde und die Ersatzeinrichtung die alte Gefährdung nicht wiederherstellt. Den physischen Mac zu finden reicht nicht. Bei unklarer Verwahrung kann auch ein wiedergefundener Rechner eine erneute Aufnahme in die Verwaltung oder eine Löschung benötigen.

Prüfe jede Zeile des Arbeitsblatts zu den Zugangsdaten. Für jede Zugangsdatenart mit hohen Rechten muss ein Ergebnis der Widerrufs- oder Rotationsmaßnahme dokumentiert sein. Jede aktive Agentensitzung, die an das Gerät gebunden war, braucht ein Beendigungsergebnis. Jedes verdächtige Ereignis braucht eine Erklärung, eine Behebung oder eine dokumentierte Entscheidung, das verbleibende Risiko zu akzeptieren.

Führe aus einer kontrollierten Umgebung Negativtests für die entfernten Zugriffswege durch. Bestätige, dass der VPN-Zugriff die alte Geräteidentität ablehnt. Bestätige, dass widerrufene SSH-Schlüssel scheitern. Bestätige, dass alte API-Tokens scheitern. Prüfe, dass frühere Organisationssitzungen keine Administrationsseiten mehr erreichen, sofern der Anbieter eine Sitzungsprüfung ermöglicht. So findest du Fälle, in denen alte Zugangsdaten in einer zweiten Region, auf einem vergessenen Bastion-Host oder in einem separaten Identitätsmandanten gültig geblieben sind.

Schreibe eine kurze Nachbemerkung zum Vorfall, solange die Details frisch sind. Nimm Zeitleiste, Auswirkungen, betroffene Zugangsdaten, geprüfte Beweise, ergriffene Maßnahmen, offene Unsicherheiten und geplante Änderungen auf. Verzichte auf Schuldzuweisungen. Wenn die Reaktion davon abhing, dass eine Person sich an den Speicherort eines Tokens erinnert, braucht der Prozess Inventar und Verantwortlichkeiten, keine Standpauke.

Der praktische Test ist einfach: Welche Aktionen könnte der eingeschaltete fehlende Mac morgen noch ausführen? Arbeite weiter, bis die ehrliche Antwort lautet: keine, die von Bedeutung sind. Dieser Maßstab ist strenger als ein Beleg für die Fernlöschung. Genau das schützt deine Systeme.