# Agent-Tresore nach der Migration brauchen einen Kaltstart

Eine Mac-Übertragung ist keine harmlose Verlagerung, wenn autonome Agents APIs und SSH-Hosts erreichen können. Sie erzeugt einen neuen Rechner, eine neue Hardwaresicherheitsgrenze, neue laufende Prozesse und einen neuen Moment, in dem jemand entscheiden muss, welche Berechtigungen weiterhin gerechtfertigt sind. Wenn Agents wieder auf externe Systeme zugreifen können, weil der Schreibtisch vertraut aussieht, hat die Migration den einzigen wichtigen Teil übersprungen.

Der Migrationsassistent kann Dokumente, Apps, Benutzerkonten und Einstellungen von einem anderen Mac, PC oder Backup übertragen. Das ist hilfreich, um schnell wieder arbeitsfähig zu sein. Es bedeutet nicht, dass jede Sicherheits­eigenschaft des Quellrechners erhalten bleiben soll. Apple dokumentiert ausdrücklich, dass Secure-Enclave-Schlüssel und Schlüsselbundobjekte mit der Markierung `ThisDeviceOnly` nicht auf ein anderes Gerät migriert werden.

Die sichere Betriebsregel ist einfach: Übertrage, was dir bei der Untersuchung und beim Wiederaufbau hilft, und verlange dann einen neuen Nachweis, bevor ein Agent eine Zugangsdaten verwenden oder eine entfernte Sitzung öffnen darf. Ein Tresor, der sich nach einer Übertragung nicht öffnen lässt, tut möglicherweise genau das, wofür du ihn eingerichtet hast.

## Ein übertragener Mac ist ein neuer Endpunkt

Ein neuer Mac kann denselben Benutzernamen, denselben Pfad zum Home-Verzeichnis, dieselben Apps und denselben Projekt-Checkout haben. Keine dieser Tatsachen macht ihn zum selben Sicherheitsendpunkt. Prozessor, Secure Enclave, biometrische Registrierung, Kontext der Festplattenverschlüsselung, installierter Systemzustand, Netzwerkanbindung und lokale Prozesshistorie haben sich geändert.

Teams ziehen oft den falschen Vergleich. Sie fragen, ob auf dem Zielrechner dieselben Dateien liegen. Sie sollten fragen, ob der Zielrechner den Besitz derselben Berechtigung nachweisen kann, ohne eine Berechtigung zu kopieren, die lokal bleiben sollte. Bei einem Tresor mit gerätegebundener Absicherung sind das gegensätzliche Ziele.

Apples Sicherheitsdokumentation zieht die Grenze klar. Ein privater Secure-Enclave-Schlüssel wird innerhalb der Enclave erzeugt, kann keinen bereits vorhandenen privaten Schlüssel importieren und kann nur von der Enclave verwendet werden, die ihn erstellt hat. Apple sagt außerdem, dass ein Schlüsselbundobjekt mit `kSecAttrAccessibleWhenUnlockedThisDeviceOnly` nicht auf ein neues Gerät migriert wird.

Bei einem überstürzten Laptop-Austausch kann dieses Verhalten lästig wirken. Es verhindert, dass ein kopierter Anwendungskontainer, ein Backup oder eine Migrationsübertragung zu einem portablen Bearer-Token für den externen Zugriff wird. Umgehe den Fehler nicht, indem du Geheimnisse in eine Notizdatei, eine Umgebungsvariable, die Shell-History oder einen allgemeinen Passwortmanager-Eintrag exportierst. Damit würdest du eine bewusst gesetzte Hardwaregrenze durch eine Datei ersetzen, die sich viel weiter verbreiten kann als der alte Laptop.

Lege die Erwartungen für die Umstellung fest, bevor du den Migrationsassistenten öffnest:

- Der alte Mac bleibt die maßgebliche Quelle für den bestehenden Zugriff, bis der Zielrechner die Tests bestanden hat.
- Auf dem neuen Mac bleibt die Agent-Ausführung blockiert oder von Produktionszugangsdaten getrennt.
- Eine übertragene Datei ist ein Prüfhinweis, keine Erlaubnis zu handeln.
- Für jede Freigabe und jede Zugangsdatenbindung muss ein erwartetes Ergebnis festgelegt sein.

Das ist eine kontrollierte Neuregistrierung, auch wenn sich der Großteil der App-Daten erfolgreich kopieren lässt. Die Bezeichnung als Übertragung ändert nichts an der Sicherheitsarbeit.

## Vier Zustandsarten scheitern auf unterschiedliche Weise

Anwendungsdaten, Freigaben, Audit-Datensätze und Zugangsdatenbindungen liegen oft nebeneinander. Sie dürfen trotzdem nicht als ein und dasselbe behandelt werden. Jeder Zustand beantwortet eine andere Frage, und eine Migration kann für jeden ein anderes Ergebnis liefern.

**Anwendungsdaten** sind der gewöhnliche lokale Zustand: Einstellungen, Endpunktdefinitionen, Bezeichnungen, nicht geheime Metadaten und möglicherweise verschlüsselte Tresorblobs. Sie können vollständig übertragen werden. Ihre Anwesenheit sagt nur, dass der Kopiervorgang sie gefunden hat.

**Freigaben** sind zeitlich begrenzte Entscheidungen über einen bestimmten Agent-Prozess. Sie beantworten die Frage: «Darf dieser Prozess während dieses Laufs handeln?» Eine Freigabe, die nach der Übertragung in einer lokalen Datenbank sichtbar bleibt, darf keinen Prozess auf einem neuen Mac autorisieren. Der Prozess hat eine neue Elternkette, einen neuen Speicherort der ausführbaren Datei, eine neue Umgebung und möglicherweise einen veränderten Signaturstatus.

**Audit-Datensätze** sind Nachweise darüber, was geschehen ist. Sie können und sollten erhalten bleiben, wenn die Übertragung die relevanten verschlüsselten Dateien bewahrt. Ihre Reihenfolge und Integritätseigenschaften müssen erhalten bleiben, nicht nur ihre Lesbarkeit in einer Journalansicht.

**Zugangsdatenbindungen** beantworten die Frage, ob die Hardware des Zielrechners die kryptografische Absicherung eines Geheimnisses verwenden kann. Der verschlüsselte Blob kann kopiert werden, während die lokale Möglichkeit zum Entschlüsseln nicht übertragen wird. Das ist der Punkt, der selbst sorgfältige Entwickler überrascht: Verfügbarkeit von Chiffretext ist nicht dasselbe wie Verfügbarkeit von Zugangsdaten.

Schreibe diese vier Zustände vor der Übertragung in ein Migrationsarbeitsblatt. Halte kein vages Ergebnis wie «Tresor migriert» fest. Notiere für jeden Zustand ein eigenes Ergebnis:

| Zustand | So sieht Erfolg aus | So sieht ein Fehler aus | Entscheidung für die Umstellung |
| --- | --- | --- | --- |
| App-Daten | Erwartete Einstellungen und nicht geheime Metadaten sind vorhanden | Konfiguration fehlt oder wurde unerwartet verändert | Einstellungen vor dem Zugriffstest wiederherstellen oder neu aufbauen |
| Freigaben | Der neue Agent-Prozess fragt erneut nach | Er kann wegen eines alten Datensatzes handeln | Vor jedem externen Aufruf stoppen und untersuchen |
| Audit-Datensätze | Historische Einträge sind vorhanden und die Integritätsprüfung gelingt | Einträge fehlen, sind umgeordnet oder bestehen die Prüfung nicht | Beide Kopien aufbewahren und die Quelle nicht löschen |
| Zugangsdatenbindungen | Der Zielrechner verlangt seine eigene lokale Entsperrung und verhält sich danach wie vorgesehen | Geheimnisse werden ohne die vorgesehene lokale Sperre stillschweigend nutzbar | Das Ergebnis als Sicherheitsmangel behandeln, bis es erklärt ist |

Der schwierige Fall ist ein Teilerfolg. Die App startet, Einstellungen erscheinen, die alte Audit-Historie ist vorhanden und der Tresor lässt sich nicht entsperren. Das ist keine fehlgeschlagene Migration. Es ist eine Migration, die Nachweise und Konfiguration bewahrt, aber die Übertragung gerätegebundener Berechtigungen verweigert. Akzeptiere dieses Ergebnis und registriere die Zugangsdaten neu.

## Agent-Zugriff vor dem Kopieren einfrieren

Beginne nicht mit dem Migrationsassistenten. Stelle zuerst sicher, dass kein Agent eine Anfrage senden kann, solange unklar ist, welcher Mac die Berechtigung besitzt.

Stoppe zunächst aktive Agent-Läufe auf dem Quell-Mac. Wenn der Agent von einem Terminal-Multiplexer, einer Editor-Erweiterung, einer Hintergrundaufgabe oder einem lokalen Launcher ähnlich einer CI-Aufgabe verwaltet wird, stoppe jeden Einstiegspunkt. Schließe die Terminalsitzungen, die sie gestartet haben. Ein geschlossenes Fenster beweist nicht, dass ein Kindprozess beendet wurde.

Halte anschließend den Zustand des Quellrechners außerhalb der App fest. Notiere Datum und Uhrzeit, die Seriennummer oder interne Anlagenkennung des Quell-Macs, das Benutzerkonto, die aktiven Agent-Prozesse und die Namen der entfernten Systeme, die die Agents erreichen konnten. Schreibe keine Geheimnisse in diesen Datensatz. Du brauchst eine Zeitleiste, die spätere Nachweise erklärt, keinen zweiten Tresor.

Trenne den Zielrechner bis zum ersten kontrollierten Test von den wichtigen Netzwerken. Das kann bedeuten, in der anfänglichen Einrichtung ein Produktions-VPN-Profil nicht zu übernehmen, eine Firewall-Regel zu verweigern oder den neuen Mac einfach vom Netzwerk getrennt zu lassen, bis die lokalen Prüfungen abgeschlossen sind. Ein Laptop, der keine externe API erreichen kann, kann nicht versehentlich zeigen, dass eine alte Autorisierung akzeptiert wurde.

Lege außerdem fest, wer neue Freigaben annehmen darf. Das ist wichtiger, als Teams oft zugeben. Eine Migration findet häufig statt, während jemand anderes den neuen Rechner einrichtet, Backups wiederherstellt oder einen beschädigten Laptop repariert. Wer auf eine Freigabekarte klickt, sollte wissen, welche Agent-Binärdatei freigegeben wird und warum sie diese Fähigkeit benötigt.

Verwende einen kurzen Übergabedatensatz wie diesen:

```text
Migration ID: MA-2026-07-22-A
Source endpoint: old Mac asset ID
Destination endpoint: new Mac asset ID
External access state: disabled
Source agent runs: stopped
Source sessions revoked: pending destination verification
First permitted test: disposable read-only API action
Decision owner: named operator
```

Das angezeigte Datum ist ein Beispielformat, keine magische Kennung. Entscheidend ist, dass du später das Ende des Quell-Audit-Logs, die erste Freigabe auf dem Zielrechner und die erste erfolgreiche Aktion mit einem gemeinsamen Umstellungsdatensatz verbinden kannst.

## App-Dateien können umziehen, ohne Vertrauen mitzunehmen

Untersuche den Anwendungszustand in zwei Durchgängen: zuerst auf Vollständigkeit, dann auf Berechtigungen. Vermische beides nicht. Die Vollständigkeit zeigt dir, was wiederhergestellt werden muss. Die Berechtigungen zeigen dir, was abgelehnt oder neu aufgebaut werden muss.

Starte die Anwendung nach der Übertragung, während der Zielrechner weiterhin keine Produktionsdienste erreichen kann. Prüfe, ob die sichtbare Konfiguration sinnvoll ist: Endpunktnamen, Bezeichnungen, nicht geheime Routing-Details und die erwartete lokale Journalansicht. Vergleiche sie mit dem Quell-Mac, solange dieser noch vorhanden ist. Fehlt ein Endpunkt, baue ihn bewusst neu auf. Erscheint ein Endpunkt, den niemand kennt, entferne ihn und finde heraus, woher er stammt.

Prüfe danach jeden Zustand, der automatische Aktionen auslösen könnte. Dazu gehören automatisch gestartete Agent-Integrationen, Shell-Profil-Einträge, die einen Connector starten, Editor-Aufgaben, Launch-Agents, gespeicherte Befehlvorlagen und Anwendungseinstellungen, die frühere Sitzungen erneut öffnen. Eine Migration kann Komforteinstellungen erhalten, die für einen Texteditor harmlos, für einen Agent mit Zugriff auf Produktions-APIs jedoch gefährlich sind.

Apple sagt, dass der Migrationsassistent Apps, Accounts, Dokumente und Einstellungen überträgt. Genau deshalb ist diese Prüfung nötig, statt anzunehmen, dass nur persönliche Dateien verschoben wurden.

Betrachte das Vorhandensein eines Verzeichnisses nicht als bestandenes Kriterium. Ein Sicherheitsdesign kann absichtlich eine verschlüsselte Tresordatei übertragen, aber das Material zum Entschlüsseln zurücklassen. Ein scheinbar leerer Tresor kann ebenfalls korrekt sein, wenn die App den lokalen Sicherheitszustand nicht kopiert. Die einzige nützliche Frage lautet, ob das Ergebnis dem erwarteten Design entspricht.

Bei Sallyport ist der Tresor innerhalb der App verschlüsselt und die Tresorsperre absolut. Auf Macs mit dem unterstützten Hardwarepfad verwendet die Sperre Secure Enclave und Touch ID. Gesperrt bedeutet, dass jede Aktion verweigert wird. Ein kopierter Tresorinhalt ist daher kein Beleg dafür, dass der Zielrechner die Berechtigung des Quell-Macs verwenden kann.

Dokumentiere jedes beobachtete Ergebnis mit präzisen Formulierungen. Schreibe «Verschlüsselter Zustand vorhanden, lokale Sperre des Zielrechners bleibt geschlossen» statt «Migration fehlgeschlagen». Schreibe «Agent-Launcher vor dem ersten Lauf deaktiviert» statt «wahrscheinlich gestoppt». Diese Details verhindern, dass ein späterer Operator einen unvollständigen Test als erfolgreiche Umstellung behandelt.

## Alte Freigaben dürfen keinen neuen Prozess autorisieren

Sitzungsfreigabe und Zugriff auf Zugangsdaten sind getrennte Kontrollen. Ein neuer Mac muss beide in der richtigen Reihenfolge bestehen. Die Tresorsperre entscheidet, ob überhaupt eine Aktion möglich ist. Die Sitzungsautorisierung entscheidet, ob dieser konkrete Agent-Lauf Aufrufe ausführen darf. Eine Regel pro Aufruf entscheidet, ob eine bestimmte Zugangsdaten bei jeder Nutzung eine weitere menschliche Entscheidung verlangt.

Diese Trennung verschwimmt leicht, weil der Benutzer nur sieht, dass eine einzelne Aktion gelingt oder scheitert. Akzeptiere diese Unklarheit während der Migration nicht. Teste sie gezielt.

Starte einen neuen Agent-Prozess erst, wenn sich der Tresor des Zielrechners im vorgesehenen gesperrten oder entsperrten Zustand befindet. Bitte ihn um eine harmlose Aktion mit einer Zugangsdaten, die keine Produktionssysteme verändern kann. Das erwartete Sitzungsergebnis ist eine neue Freigabeanfrage. Prüfe die Prozessidentität und die in der Freigabeoberfläche angezeigte Signaturautorität. Genehmige nur den Lauf, den du tatsächlich gestartet hast.

Wenn ein Agent-Prozess auf dem Zielrechner ohne neues Autorisierungsereignis eine Aktion ausführt, stoppe ihn. Freue dich nicht darüber, dass die Übertragung Zeit gespart hat. Finde den Pfad, der die Berechtigung erteilt hat. Es kann sich um einen weiterlaufenden Prozess, eine wiederhergestellte Sitzungsdatenbank, eine Integration außerhalb des erwarteten Shims oder ein Freigabemodell handeln, das die Prozesslebensdauer nicht eng genug bindet.

Sallyports Sitzungsautorisierung ist standardmäßig aktiviert. Der erste Aufruf eines neuen Agent-Prozesses wird als Freigabekarte angezeigt, die mit der Signaturautorität des Prozesses beginnt. Eine Freigabe gilt nur für diesen Lauf, bis der Prozess beendet wird. Ein neu gestarteter Prozess auf dem Zielrechner ist daher der richtige Ort für eine neue Entscheidung.

Teste Zugangsdaten mit Freigabe pro Aufruf separat. Markiere eine harmlose Testzugangsdaten so, dass jede Nutzung eine Freigabe verlangt. Führe zwei Aufrufe aus demselben freigegebenen Agent-Lauf aus. Für jede Nutzung dieser Zugangsdaten sollte eine Entscheidung erscheinen. Die Sitzungsentscheidung sollte nicht erneut erscheinen, nur weil derselbe Prozess weiterläuft. So erkennst du, ob du die Sitzungsebene oder die Ebene pro Aufruf getestet hast, statt aus einem einzelnen Popup zu raten.

Eine sinnvolle Testtabelle ist klein:

| Test | Erwartete Beobachtung | Abbruchbedingung |
| --- | --- | --- |
| Erster Aufruf eines neuen Agent-Laufs | Eine neue Sitzungsfreigabe erscheint | Der Aufruf läuft mit einer alten Freigabe weiter |
| Zweiter Aufruf im selben Lauf | Keine zweite Sitzungsfreigabe | Ohne Grund erscheint eine zweite Sitzungsanfrage |
| Erste Nutzung einer Zugangsdaten mit Freigabe pro Nutzung | Eine zugangsdatenbezogene Entscheidung erscheint | Die Zugangsdaten wird still verwendet |
| Zweite Nutzung dieser Zugangsdaten | Eine weitere zugangsdatenbezogene Entscheidung erscheint | Die erste Entscheidung gilt weiter |
| Beenden und Neustarten des Agents | Erneut erscheint eine neue Sitzungsfreigabe | Der vorherige Lauf besitzt weiterhin die Berechtigung |

Teste das nicht mit einem Produktions-Deployment, denn du testest nicht nur ein Popup. Du testest, ob der neue Endpunkt die Prozesslebensdauer und die Zugangsrichtlinie korrekt erkennt.

## Die Audit-Historie braucht eine Prüfung, keine Sichtkontrolle

Eine Journalansicht mit Einträgen von gestern ist hilfreich, beweist aber nicht, dass der übertragene Datensatz vollständig geblieben ist. Eine Migration kann eine Datei auslassen, einen älteren Snapshot kopieren, eine Aktualisierung unterbrechen oder dich eine zwischengespeicherte Indexansicht betrachten lassen. Audit-Nachweise brauchen einen Integritätstest.

Bewahre den Quell-Mac auf, bevor du die erste Aktion auf dem Zielrechner ausführst. Halte den letzten Zeitstempel der Quelle fest und notiere, wie viele Sitzungen und Aufrufe du rund um die Umstellung erwartest. Vergleiche dann die historische Ansicht des Zielrechners. Suche nach Kontinuität, nicht nach identischer Darstellung oder Anzeigereihenfolge.

Sallyport erzeugt seine Sitzungs- und Aktivitätsjournale aus einem schreibgeschützten, verschlüsselten und hashverketteten Audit-Log. Der Prüfer kann die Kette offline über dem Chiffretext prüfen, ohne einen Tresorschlüssel zu benötigen. Damit erhält die Migration einen konkreten Prüfpunkt, statt einen Operator eine Liste alter Aktionen überfliegen zu lassen.

Führe die Prüfung nach Möglichkeit vor der Übertragung auf dem Quellrechner aus und wiederhole sie auf dem Zielrechner, bevor irgendeine Agent-Aktion erlaubt wird. Speichere Standardausgabe und Exit-Code, ohne ein bestimmtes Nachrichtenformat vorauszusetzen:

```sh
sp audit verify > audit-verify.txt 2>&1
status=$?
printf 'sp audit verify exit=%s\n' "$status"
```

Speichere `audit-verify.txt` mit dem Migrationsdatensatz, nicht in einem Chat-Thread, der später verschwindet. Ein Exit-Code von null ist nur dann hilfreich, wenn du zusätzlich festhältst, welcher Endpunkt ihn wann erzeugt hat. Meldet der Prüfer einen Fehler oder liefert er einen Wert ungleich null, stoppe den Migrationspfad. Bewahre die Quelle unverändert auf, kopiere die Diagnoseausgabe und untersuche die Übertragung, statt ein neues Journal zu beginnen, das die Unterbrechung verdeckt.

Behalte außerdem eine weitere Unterscheidung im Blick: Die übertragene Audit-Historie belegt, was der alte Endpunkt aufgezeichnet hat. Die Aktivitäten des Zielrechners belegen, was der neue Endpunkt nach der Umstellung tut. Vermische beides gedanklich nicht. Der erste Aufruf auf dem Zielrechner sollte leicht auffindbar, mit der neuen Sitzungsautorisierung verknüpft und eindeutig später als der letzte Aufruf der Quelle sein.

## Zugangsdaten neu registrieren, statt sie zu extrahieren

Die verbreitete Abkürzung besteht darin, ein API-Token oder einen privaten SSH-Schlüssel vom alten Mac zu exportieren, auf dem neuen einzufügen und zu versprechen, ihn später zu löschen. Sie ist beliebt, weil sie schnell funktioniert. Sie ist falsch, wenn das alte Design die Zugangsdaten absichtlich vom Agent fernhielt und die lokale Nutzung an einen geschützten Tresor band.

Bei einer Neuregistrierung lautet die Frage nicht mehr «Wie kopiere ich dieses Geheimnis?», sondern «Wer soll diesem Endpunkt eine neue Berechtigung erteilen?» Das ist die bessere Frage. Möglicherweise musst du ein neues API-Token erstellen, einen neuen öffentlichen SSH-Schlüssel registrieren oder eine neue Zugangsdaten vom Systemverantwortlichen erhalten. Gleichzeitig entsteht ein klarer Widerrufspunkt für den alten Mac.

Erstelle für HTTP-Zugriff, sofern der entfernte Dienst dies erlaubt, eine kurzlebige, schreibgeschützte Testzugangsdaten. Gib ihr Zugriff auf genau eine harmlose Ressource. Lass den neu freigegebenen Agent diese Ressource anfordern. Prüfe das zurückgegebene Ergebnis und den lokalen Audit-Eintrag. Widerrufe die Testzugangsdaten anschließend oder lasse sie nach dem normalen Verfahren des Dienstes ablaufen.

Verwende für SSH ein eigenes Testkonto oder einen eingeschränkten Testhost. Der erste Befehl sollte nur Informationen anzeigen, etwa die Identität des entfernten Kontos und das aktuelle Arbeitsverzeichnis. Mache den ersten Erfolgsnachweis nicht zu einem Repository-Push, einer Paketveröffentlichung, einem Datenbankbefehl oder einem Deployment-Trigger. Solche Aktionen erschweren die Fehlersuche, weil sie genau das System verändern, das du schützen willst.

Eine Zugangsdaten mit Freigabe pro Aufruf ist in dieser Phase besonders hilfreich. Sie zwingt einen Menschen, genau zu beobachten, wann die externe Nutzung beginnt. Nachdem der Zielrechner die Tests für Autorisierung, Audit und harmlose Aktionen bestanden hat, registriere die Produktionszugangsdaten über den normalen Verantwortungsweg neu. Widerrufe die alte Zugangsdaten oder entferne die Autorisierung des alten Endpunkts, sobald das entfernte System diese Unterscheidung unterstützt.

Verwechsle eine SSH-Schlüsseldatei nicht mit einer SSH-Identität, die auf den neuen Mac gehört. Ein kopierter privater Schlüssel kann sich authentifizieren. Das beweist aber nur, dass ein Server dasselbe kryptografische Material akzeptiert hat. Es sagt nichts darüber aus, ob die Übertragung dein lokales Sicherheitsmodell bewahrt hat. Neuer Endpunkt, neue Identitätsregistrierung, neuer Audit-Trail.

## Die erste echte Aktion sollte absichtlich langweilig sein

Die erste produktionsnahe Aktion sollte zeigen, ob die gesamte Kette funktioniert, ohne Aufräumarbeit zu erzeugen. Wähle eine schreibgeschützte Operation, die auf ein unkritisches Testobjekt beschränkt und sowohl in entfernten Logs als auch im lokalen Aktivitätsjournal leicht zu finden ist.

Geeignet sind etwa das Lesen der Metadaten eines Test-API-Objekts, das Auflisten eines eigens dafür eingerichteten leeren SSH-Verzeichnisses oder die Abfrage der aktuell authentifizierten Identität eines Dienstes. Ungeeignet sind das Erstellen von Cloud-Ressourcen, das Rotieren gemeinsam genutzter Zugangsdaten, das Veröffentlichen von Artefakten, das Ändern von Repository-Einstellungen und Befehle, die Shell-Erweiterungen auf echte Pfade anwenden.

Führe die Aktion einmal aus. Bestätige in der Reihenfolge ihres Auftretens:

1. Der Tresor des Zielrechners befand sich vor der Anfrage im vorgesehenen Zustand.
2. Der neue Agent-Prozess erhielt eine neue Sitzungsautorisierung.
3. Eine Zugangsdaten mit Freigabe pro Aufruf verlangte eine Freigabe, sofern dies eingestellt war.
4. Das entfernte System zeichnete die erwartete harmlose Aktion auf.
5. Der Aktivitätsdatensatz des Zielrechners stimmt mit der freigegebenen Aktion überein.

Fehlt eine Beobachtung, wiederhole die Aktion erst, wenn du den Grund verstanden hast. Das wiederholte Ausführen eines undurchsichtigen Tests erzeugt meist einen Stapel fast identischer Datensätze, aber keine Erklärung. Ein sauberer Erfolg sagt mehr als fünf hektische Wiederholungen.

Nachdem diese Aktion bestanden ist, aktiviere den externen Zugriff für jeweils eine Zugangsdaten. Aktiviere nicht an einem Nachmittag jeden gespeicherten Endpunkt, nur weil der Zielrechner endlich nutzbar ist. Ein Produktions-Token, eine SSH-Identität für die Infrastruktur und ein persönliches Service-Token bergen unterschiedliche Risiken und brauchen möglicherweise unterschiedliche Freigebende. Aktiviere sie in einer Reihenfolge, die zunächst die geringste Berechtigung verleiht.

## Den alten Mac behalten, bis die Nachweise vollständig sind

Lösche den Quell-Mac nicht und gib ihn nicht zurück, sobald der Zielrechner erfolgreich startet. Halte ihn mit deaktivierten Agents bereit, bis der Übertragungsdatensatz vollständig ist und du die Nachweise auf beiden Seiten erklären kannst.

Der Abschlussdatensatz sollte den zuletzt geprüften Audit-Zustand der Quelle, den ersten geprüften Audit-Zustand des Zielrechners, die Ergebnisse der neuen Freigabetests, die neu registrierten und widerrufenen Zugangsdaten sowie die Person enthalten, die den Produktionszugriff autorisiert hat. Das ist keine Bürokratie um ihrer selbst willen. So kannst du später beantworten, ob eine Aktion vom alten Rechner, vom neuen Rechner oder aus einer ungeplanten Überschneidung kam.

Widerrufe anschließend aktive Sitzungen der Quelle. Entferne die Quelle aus vorhandenen Listen erlaubter Fernzugriffe. Widerrufe quellenspezifische Tokens und SSH-Registrierungen, sobald der Ersatz funktioniert. Prüfe schließlich, dass der alte Endpunkt nicht allein dadurch wieder Zugriff erhält, dass er erneut online geht.

Der wichtigste Test ist nicht, ob der Migrationsassistent genug übertragen hat. Entscheidend ist, ob sich der Zielrechner die externe Berechtigung erneut verdienen musste. Wenn die Antwort ja lautet, beginnt der neue Mac mit einer begründbaren Grenze. Wenn die Antwort nein lautet, lasse die Agents getrennt, bis du genau erklären kannst, was die Übertragung passiert hat und warum.