Beim Austausch eines Entwickler-Macs müssen Zugangsdaten für Agenten erneuert werden

Einen Entwickler-Mac zu ersetzen ist eine Änderung von Zugriffsrechten, keine Dateiübertragung. Deine Editor-Einstellungen, Repositories, Shell-Historie und lokalen Build-Caches können mit gewöhnlichen Migrationswerkzeugen umziehen. Zugangsdaten, mit denen ein KI-Agent Produktions-APIs aufrufen oder SSH-Sitzungen öffnen kann, brauchen einen eigenen Plan.

Der häufigste Fehler ist, den alten Mac wie einen Koffer zu behandeln. Jemand richtet den neuen Rechner ein, startet den Migrationsassistenten, sieht den vertrauten Schreibtisch und nimmt an, der Umzug sei abgeschlossen. Tatsächlich können dabei jahrelange Berechtigungen, zwischengespeicherte Tokens, vergessene SSH-Identitäten und Werkzeuge für Agenten eine Vertrauensgrenze überschritten haben, ohne dass jemand geprüft hat, was erhalten geblieben ist.

Daten getrennt von Berechtigungen verschieben

Dateien sind Kopien. Berechtigung bedeutet, weiterhin etwas außerhalb des Macs tun zu können. Ein API-Token kann noch eine Bereitstellung auslösen, nachdem der alte Laptop dein Haus verlassen hat. Ein öffentlicher SSH-Schlüssel kann auf einem Server weiter akzeptiert werden, lange nachdem sein privater Teil kopiert, gesichert oder gelöscht wurde. Eine Cloud-Sitzung kann sich selbst erneuern, bis der Aussteller sie widerruft.

Diese Unterscheidung verändert den Plan für den Austausch. Quellcode, Notizen und nicht geheime Konfigurationen kannst du früh kopieren, weil du sie später vergleichen kannst. Berechtigungen solltest du zurückstellen, bis du entschieden hast, ob der neue Mac dieselbe Zugangsdaten, eine Ersatz-Zugangsdaten oder überhaupt keine Berechtigung braucht.

Werkzeuge für Agenten machen den Unterschied noch deutlicher. Ein normaler Entwickler gibt vielleicht einen Befehl ein, wenn ein abgelaufenes Token Aufmerksamkeit verlangt. Ein autonomer Coding-Agent kann schnell und wiederholt Aufrufe durchführen, während du gerade nicht hinsiehst. Der Agent braucht kein Klartextgeheimnis, um ein Risiko zu schaffen. Es reicht ein Weg zu einer Aktion, die die Berechtigung des alten Geräts weiterhin akzeptiert.

Eine vernünftige Migration führt zwei Listen:

• Ein Datenverzeichnis erfasst Repositories, Dokumente, Konfigurationsdateien, lokale Datenbanken, Backup-Orte und Lizenzmaterial.
• Ein Berechtigungsverzeichnis erfasst jedes entfernte System, das eine Aktion akzeptiert, weil etwas auf dem alten Mac gespeichert, für ihn ausgestellt oder von ihm genehmigt wurde.

Führe diese Listen nicht zusammen. Ein Repository kann zweimal wiederhergestellt werden, ohne Probleme zu verursachen. Ein zweimal kopiertes Bearer-Token schafft zwei Orte, die geschützt werden müssen. Deshalb ist der übliche Rat, erst zu migrieren und später aufzuräumen, bei Zugangsdaten falsch.

Apple beschreibt Migration Assistant als Werkzeug zum Übertragen von Dokumenten, Apps, Benutzerkonten und Einstellungen. Die Informationen auf dem alten Mac werden dabei nicht gelöscht. Apple beschreibt die normale Migration damit korrekt. Genau deshalb ist sie kein Verfahren zum Stilllegen von Zugangsdaten. Der alte Rechner bleibt eine aktive Kopie, bis du ihm seine Berechtigungen bewusst entziehst.

Eine neue Einrichtung ist die Standardwahl

Eine neue Einrichtung ist meist sicherer, weil du dadurch festlegen musst, was der Ersatz-Mac tun darf. Du meldest dich erneut an, erstellst, sofern der Dienst das unterstützt, ein neues Token oder eine neue SSH-Identität, gibst dem neuen Gerät die kleinstmögliche erforderliche Rolle und entfernst den Zugriff des Vorgängers, sobald der Wechsel funktioniert.

Dieser Ansatz wirkt langsamer, weil er Altlasten sichtbar macht, die eine Kontomigration verborgen hätte. Vielleicht findest du ein altes Bereitstellungs-Token, dessen Besitzer das Team verlassen hat, ein persönliches Zugriffstoken mit einem viel größeren Umfang als nötig oder einen SSH-Schlüssel, der auf mehrere Rechner kopiert wurde, weil niemand eine Veröffentlichung unterbrechen wollte. Solche Funde sind wertvoll. Der Austausch ist einer der seltenen Zeitpunkte, an denen du diese Probleme beheben kannst, ohne eine funktionierende Umgebung zu stören.

Wähle eine neue Einrichtung, wenn eine dieser Bedingungen zutrifft:

• Der alte Mac wurde für mehrere Rollen verwendet, etwa für private Arbeit, Administration und Produktionssupport.
• Du kannst nicht alle Zugangsdaten oder entfernten Konten benennen, die der alte Mac nutzen kann.
• Der alte Rechner wurde repariert, gemeinsam genutzt, war zeitweise verloren oder befand sich anderweitig außerhalb deiner Kontrolle.
• Ein Aussteller von Zugangsdaten kann ein gerätespezifisches Token, Zertifikat, App-Passwort oder einen SSH-Schlüssel erstellen.
• Du wechselst zwischen Arbeitgebern, Teams, verwalteten Geräteprofilen oder Apple-Accounts.

Eine neue Einrichtung macht auch den Rückweg sauberer. Wenn der neue Mac am ersten Arbeitstag ausfällt, kann der alte Rechner vorübergehend online bleiben, während du den Zugriff korrigierst. Diese Überschneidung hat einen Preis. Setze deshalb eine kurze Frist und dokumentiere sie. Die Überschneidung soll beweisen, dass der neue Rechner funktioniert, nicht die Entscheidung über den Widerruf vermeiden.

Das falsche Gegenargument lautet, dass durch die Erneuerung aller Zugangsdaten mehr Zugangsdaten verwaltet werden müssen. Eine kurze Zeit mit zwei benannten und erfassten Zugangsdaten ist beherrschbar. Eine unbefristete Phase, in der niemand weiß, ob ein Eintrag im Passwortmanager, ein lokaler Schlüsselbund, ein Backup oder ein Tresor für Agenten noch die alte Berechtigung enthält, ist es nicht.

Eine verschlüsselte Migration hat eine eng begrenzte Aufgabe

Eine verschlüsselte Migration kann gerechtfertigt sein, wenn eine erneute Einrichtung ein nicht vertretbares Betriebsrisiko schaffen würde, der Aussteller der Zugangsdaten keinen sauberen Austausch unterstützt oder ein Tresorprodukt einen dokumentierten Export- und Importprozess für genau diesen Wechsel anbietet. Sie ist nicht gerechtfertigt, nur weil das erneute Eingeben von Zugangsdaten lästig ist.

Verwechsle eine vom Betriebssystem verschlüsselte Festplatte nicht mit einem portablen, verschlüsselten Paket für Zugangsdaten. Die vollständige Festplattenverschlüsselung schützt ein Gerät innerhalb seines normalen Schutzmodells. Ein Migrationsexport wird zu einem neuen Objekt. Du musst wissen, ob er selbst verschlüsselt ist, ob sein Entschlüsselungsmaterial getrennt liegt, wie lange die Datei existiert und ob eine Wiederherstellung auf einem zweiten Rechner unbemerkt möglich ist.

Prüfe vor dem Export eines verschlüsselten Tresors Folgendes:

1. Benenne das Exportformat und die App-Version, die es lesen kann.
2. Bestimme die Verschlüsselungsgrenze des Exports selbst, nicht nur die des Datenträgers, auf dem er liegt.
3. Lege fest, wo der Export während des Wechsels liegt, und setze eine Frist für seine Löschung.
4. Prüfe, wie der neue Tresor den erfolgreichen Import nachweist, ohne Geheimniswerte offenzulegen.
5. Entscheide, welche Zugangsdaten nach dem Import stillgelegt oder erneuert werden.

Wenn eine Antwort unklar bleibt, richte die Zugangsdaten neu ein. Sicherheitsmigrationen scheitern in den unklaren Bereichen, nicht im erfolgreichen Assistentenablauf.

Ein weiterer unangenehmer Punkt: Ein verschlüsselter Export kann sich als getarntes Backup erweisen. Ein Team importiert ihn vielleicht auf dem neuen Mac, erklärt den Wechsel für abgeschlossen und lässt das Archiv dann in Time Machine, einem gemeinsam genutzten Dateidienst oder auf einem externen Laufwerk liegen. Dieser Export ist weiterhin ein Container für Zugangsdaten. Für ihn muss dieselbe Aufbewahrungsentscheidung gelten wie für den alten Mac.

Verschlüsselte Migration und neue Einrichtung schließen sich nicht aus. In der Praxis kann man sie kombinieren. Übertrage Zugangsdaten für Dienste mit geringem Einfluss bei Bedarf über einen dokumentierten verschlüsselten Weg. Stelle Produktionstokens, privilegierte SSH-Schlüssel, Signaturmaterial und alles, was Kundendaten erreichen kann, neu aus. Ordne nach den möglichen Folgen, nicht danach, wie leicht sich ein Geheimnis kopieren lässt.

Vor dem Anfassen des neuen Macs ein Berechtigungsverzeichnis erstellen

Erstelle das Inventar auf dem alten Mac, solange er noch funktioniert. Verlasse dich nach der Übertragung nicht auf dein Gedächtnis, denn migrierte Einstellungen können den neuen Rechner vollständig aussehen lassen, obwohl wichtige Zugriffe fehlen. Das Verzeichnis sollte Verweise auf Geheimnisse enthalten, nicht deren Werte.

Eine einfache Datei genügt. Bewahre sie an einem privaten Arbeitsort auf, der nicht Teil eines öffentlichen Repositories wird.

Service: production deployment API
Purpose: release automation
Credential form: bearer token
Old-device location: agent vault record deploy-prod
Issuer: deployment service administrator
Replacement method: create new device token
Cutover test: read release status only
Old-access action: revoke old token
Owner: platform team
Status: pending

Service: build host
Purpose: remote build troubleshooting
Credential form: SSH identity
Old-device location: agent vault record build-ssh
Issuer: build host authorized_keys
Replacement method: create a new SSH key pair
Cutover test: ssh hostname
Old-access action: remove old public key
Owner: build infrastructure
Status: pending

Das Feld, das viele auslassen, ist die Maßnahme für den alten Zugriff. Ohne dieses Feld wird das Inventar zu einer Einkaufsliste für den neuen Mac. Es muss zugleich ein Plan zum Entfernen der Berechtigungen vom alten Rechner sein.

Erfasse Zugangsdaten an Orten, die Entwickler regelmäßig vergessen:

• Tresore für Agenten und Konfigurationsdateien von Agenten.
• SSH-Konfiguration, Zustand des SSH-Agenten, hardwaregeschützte Identitäten und Listen autorisierter Schlüssel auf entfernten Systemen.
• Browser-Sitzungen für Cloud-Konsolen und Identitätsanbieter.
• Paketregistries, Werkzeuge für Code-Hosting, Bereitstellungssysteme und Administrationskonten für CI.
• Lokale Umgebungsdateien, Shell-Startdateien, Passwortmanager, Backup-Archive und verschlüsselte Wechseldatenträger.

Trage keine echten Bearer-Tokens, privaten Schlüssel, Wiederherstellungscodes oder Passwörter in das Verzeichnis ein. Es ist nützlich, weil es genug Informationen für den Austausch und Widerruf von Zugriffen enthält, ohne selbst zu einem weiteren hochwertigen Geheimnisspeicher zu werden.

Notiere für jeden Eintrag den am wenigsten zerstörerischen Test. Eine Zugangsdaten für Bereitstellungen sollte zunächst nur den Status lesen, nicht eine Veröffentlichung erstellen. Eine SSH-Identität sollte zunächst einen eingeschränkten Befehl oder einen Host ohne Produktionsberechtigungen verwenden. Wenn der einzig mögliche Test die Produktion verändern kann, hat der Dienst ein Zugriffsproblem, das vor dem nächsten Hardwarewechsel behoben werden sollte.

Ein neuer Tresor muss mehr als eine erfolgreiche Anmeldung nachweisen

Ein neuer Tresor ist bereit, wenn du die erwarteten Einträge zuordnen kannst, ihn mit den Kontrollen des neuen Geräts entsperrst, darüber eine begrenzte Aktion ausführst und eine unabhängige Aufzeichnung dieser Aktion prüfen kannst. Ein vertrautes Label in einer App reicht nicht. Ein kopiertes Label kann auf einen abgelaufenen Eintrag, das falsche Konto oder eine Zugangsdaten verweisen, die nie vorhanden war.

Für einen Tresor, der Zugangsdaten für Agenten enthält, verwende eine festgelegte Testreihenfolge:

1. Sperre den Tresor und versuche die harmlose Aktion. Bei gesperrtem Tresor muss die Anfrage abgelehnt werden.
2. Entsperre ihn über die normale lokale Kontrolle und wiederhole dieselbe harmlose Aktion.
3. Starte einen neuen Agentenprozess und prüfe, ob das Autorisierungsverhalten zu deiner vorgesehenen Sitzungseinstellung passt.
4. Prüfe den einzelnen Aktivitätseintrag für den Aufruf und den Sitzungseintrag für den Agentenlauf.
5. Verifiziere die Audit-Spur, bevor du Quellenmaterial vom alten Mac entfernst.

Sallyport bewahrt seine Geheimnisse in einem verschlüsselten lokalen Tresor auf und führt HTTP- und SSH-Aktionen aus, ohne dem Agenten Zugangsdaten im Klartext zu übergeben. Das Tresor-Gate verweigert Aktionen im gesperrten Zustand. Dadurch ist der erste Test aussagekräftig und nicht nur kosmetisch.

Verwende den Audit-Befehl als Teil des Abnahmenachweises:

sp audit verify

Führe ihn nach dem Testaufruf auf dem neuen Mac aus und notiere Datum, ausführende Person, Testziel und Ergebnis im Migrationsticket oder Änderungsprotokoll. Es geht nicht um zusätzliche Bürokratie. Es geht darum, den Nachweis zu erhalten, dass der neue Rechner eine gültige Spur erzeugt hat, bevor du das Quellgerät zerstörst. Ein hashverketteter Audit-Eintrag kann Veränderungen am Protokoll erkennen, aber nicht feststellen, dass du vergessen hast, eine Zugangsdaten einzurichten. Dafür ist das Berechtigungsverzeichnis zuständig.

Halte den Test klein. Wenn eine Zugangsdaten keine schreibgeschützte Anfrage sicher ausführen kann, erstelle für die Migration einen eigenen Testendpunkt oder ein eingeschränktes Konto. Oft wird eine echte Änderung in der Produktion als Beweis verwendet, weil sie eindeutig ist. Sie ist auf die denkbar schlechteste Weise eindeutig: Trifft sie das falsche Konto, wird aus dem Migrationstest ein Vorfall.

Migration Assistant ist nützlich, aber kein Tresorprotokoll

Migration Assistant kann Stunden sparen, wenn du Apps, Benutzerkonten, Dateien und Einstellungen vom alten Mac brauchst. Er kann auch eine vollständige Benutzerumgebung aus einem Time-Machine-Backup übertragen. Apple dokumentiert beide Möglichkeiten. Diese Breite hilft bei der Wiederherstellung eines Arbeitsplatzes, liefert dir aber keinen genauen Nachweis darüber, welche Dateien, Sitzungen, Caches und App-Einträge mit Zugangsdaten übernommen wurden.

Verwende ihn für das Datenverzeichnis. Behandle jeden Berechtigungseintrag als nicht vorhanden, bis du ihn unter den vorgesehenen Kontrollen des neuen Rechners geprüft hast. Diese Haltung verhindert zwei schlechte Ergebnisse: dass du einer zufälligen Übertragung sensibler Zustände vertraust und dass du Zeit mit der Suche nach einer Zugangsdaten verschwendest, die absichtlich nicht übertragen werden sollte.

Ein typischer Fehler sieht so aus: Ein Entwickler migriert sein Konto, öffnet ein Agentenprojekt und sieht, dass der Agent erfolgreich einen HTTP-Aufruf ausführt. Er nimmt an, der neue Tresor funktioniere. Tatsächlich wurde der Aufruf über eine aus dem Browser stammende Cloud-Sitzung oder ein Token ausgeführt, das noch in einer kopierten Konfigurationsdatei lag. Eine Woche später läuft die Sitzung ab. Der Entwickler fügt hastig eine Ersatz-Zugangsdaten hinzu, lässt die kopierte Zugangsdaten liegen und hat nun auf dem alten Mac, in einem Backup und im neuen Tresor Wege zu demselben Dienst.

Die Lösung besteht nicht darin, Migration Assistant zu verbieten. Der Nachweis muss getrennt werden. Schließe vor dem Agententest nicht benötigte Browser-Sitzungen, verwende für den Test keine kopierten Umgebungsdateien und nutze einen Tresoreintrag, den du bewusst neu eingerichtet oder bewusst importiert hast. Prüfe anschließend den Aktivitätseintrag. Du musst wissen, welcher Weg die Aktion ausgeführt hat.

Apple weist außerdem darauf hin, dass Migration Assistant die Informationen auf dem alten Mac nicht löscht. Richte den Wechsel nach dieser Tatsache aus. Ein Bildschirm mit der Meldung, dass die Migration abgeschlossen ist, bedeutet, dass die Kopie fertig ist. Er bedeutet nicht, dass das frühere Gerät sicher an jemand anderen übergeben werden kann.

Den alten Mac vor dem Löschen widerrufen

Der Widerruf hat mehrere Ebenen. Wer sie als eine einzige Aktion behandelt, gewinnt ein falsches Gefühl von Sicherheit. Das Beenden eines Agentenlaufs stoppt einen Prozess. Das Entfernen eines Geräts aus einem Identitätsanbieter beendet möglicherweise einige Sitzungen. Der Widerruf eines Bearer-Tokens verhindert künftige API-Nutzung. Das Entfernen eines öffentlichen SSH-Schlüssels verhindert die Remote-Anmeldung über diese Identität. Eine Passwortänderung kann abhängig vom Dienst einige Sitzungen ungültig machen, während andere bestehen bleiben.

Notiere die konkrete Widerrufsmaßnahme für jeden Eintrag, bevor du beginnst. Eine Notiz wie „altes Gerät deaktivieren“ reicht nicht. Entfernte Systeme haben keine gemeinsame, allgemeingültige Definition von Gerätezugriff.

Eine praktische Reihenfolge ist:

1. Widerrufe aktive Agentensitzungen und stoppe lokale Agentenprozesse auf dem alten Mac.
2. Erneuere oder widerrufe übergeordnete API-Tokens, App-Passwörter, Cloud-Sitzungen und Zugangsdaten für Dienstkonten, die vom alten Gerät aus noch gültig sind.
3. Entferne alte öffentliche SSH-Schlüssel von jedem Server, Bastion-Host und Code-Hosting-Konto, das sie akzeptiert.
4. Entferne Gerätevertrauen oder Browser-Sitzungen aus Identitätssystemen, sofern der Dienst diese Kontrolle anbietet.
5. Führe das Verzeichnis erneut durch und vermerke bei jedem Eintrag den Nachweis des Widerrufs.

Sallyports Sitzungsprotokoll kann einen Agentenlauf sofort widerrufen, während das Aktivitätsprotokoll einzelne Aufrufe zur Prüfung bereitstellt. Nutze es für die Ebene der laufenden Prozesse und erledige anschließend die Arbeit an den übergeordneten Zugangsdaten. Eine widerrufene lokale Sitzung widerruft kein Token, das ein externer Dienst weiterhin akzeptieren würde.

Lösche den alten Rechner nicht zuerst, denn er kann den einzigen Hinweis auf ein selten genutztes Dienstkonto, eine Hardware-Token-Verknüpfung oder einen Host-Alias enthalten, den du entfernen musst. Lass ihn ausgeschaltet und unter deiner physischen Kontrolle, während du den neuen Mac prüfst. Wenn er während des Tests online bleiben muss, führe darauf keine Agenten aus, füge keine Zugangsdaten hinzu und setze eine eindeutige Frist für den Wechsel.

Sobald du den Widerruf bestätigt hast, ändert sich die Rolle des alten Macs. Er ist keine Ausweicharbeitsstation mehr. Er bleibt kurzzeitig als Beweismittel erhalten, falls ein Dienst unerwarteten Zugriff meldet, und wird danach zum Gerät, das gelöscht werden kann.

Die Entsorgung ist eine eigene Sicherheitskontrolle

Das Löschen des Macs ersetzt den Widerruf nicht, und der Widerruf ersetzt das Löschen nicht. Du brauchst beides. Ein entfernter Widerruf begrenzt, was eine kopierte Zugangsdaten tun kann. Das Löschen entfernt lokale Daten, lokalen Anwendungszustand, heruntergeladenen Quellcode, Browserverlauf und Tresormaterial, das auf dem Gerät zurückbleiben kann.

Verwende bei einem Mac mit Apple silicon oder bei einem Intel-Mac mit T2 Security Chip und unterstützter macOS-Version die Systemeinstellungen, „Allgemein“, „Übertragen oder Zurücksetzen“ und anschließend „Alle Inhalte und Einstellungen löschen“. Apple zufolge entfernt der Löschassistent Benutzerkonten, Benutzerdaten, installierte Apps, Anmeldungen bei Apple-Diensten, „Wo ist?“ und die Aktivierungssperre. Er löscht außerdem Volumes und nicht nur das aktuelle Benutzerkonto.

Falls die Option nicht verfügbar ist, improvisiere nicht mit dem Löschen einzelner Dateien oder einer schnellen Formatierung. Apple verweist bei älterer, nicht unterstützter Hardware auf das passende Löschverfahren über die Wiederherstellung und das Festplattendienstprogramm. Die Methode unterscheidet sich, weil sich unterstützte Hardware und Sicherheitsmodell unterscheiden.

Wenn das Löschen abgeschlossen ist, halte beim Bildschirm für die Ersteinrichtung an, falls du den Mac verkaufen, in Zahlung geben, verschenken oder recyceln möchtest. Apple rät ausdrücklich, in diesem Fall die Einrichtung nicht fortzusetzen. Wenn du sie abschließt, erstellst du nur ein weiteres lokales Konto auf einem Computer, der deine Kontrolle verlassen soll.

Wenn der alte Mac fehlt oder du vermutest, dass er verändert wurde, stelle sein Benutzerkonto nicht auf dem neuen Rechner wieder her. Apple warnt davor, beim Zurücksetzen wegen eines vermuteten Eingriffs ein Backup wiederherzustellen, da dadurch auch die unerwünschte Software zurückkommen kann. Priorisiere in diesem Fall den entfernten Widerruf von Zugangsdaten und eine saubere Einrichtung des Ersatz-Macs.

Das Verfahren so langweilig machen, dass es sich wiederholen lässt

Das beste Verfahren für den Austausch eines Geräts hängt nicht davon ab, dass sich jemand heldenhaft daran erinnert, wo alle Geheimnisse liegen. Es erzeugt jedes Mal dieselben Nachweise: ein Datenverzeichnis, ein Berechtigungsverzeichnis, begrenzte Tests auf dem neuen Mac, Belege für den Widerruf auf dem alten Gerät und eine Bestätigung des Löschens.

Verlange nicht von jedem Entwickler, Spezialist für die forensische Suche nach Zugangsdaten zu werden. Verlange von Diensten nach Möglichkeit gerätespezifische Zugangsdaten. Fordere Namen und Verantwortliche für privilegierten Zugriff. Stelle Ingenieuren einen schreibgeschützten Testweg bereit. Mache den Widerruf in jedem Dienst eindeutig. Diese Gewohnheiten reduzieren den Aufwand beim Austausch eines Macs und machen auch jeden anderen Vorfall leichter einzudämmen.

Ein Ersatz-Mac sollte an seinem ersten Tag nur die Berechtigungen erhalten, die sich begründen lassen. Wenn das unbequem wirkt, lass das alte Gerät für eine weitere Prüfung ausgeschaltet. Diese Verzögerung kostet weniger, als Monate später festzustellen, dass ein ausgemusterter Laptop noch immer einen Weg in die Produktion hatte.