Übergabefenster und Verantwortliche vereinbaren
Bestätigen Sie, wer zur Genehmigung von Übertragungen und zum Widerruf von Zugriffen autorisiert ist. Benennen Sie den Kontoinhaber des Kunden, den ausscheidenden Auftragnehmer, den Nachfolgeoperator und die Person, die helfen kann, wenn der Zugriff abbricht. Vereinbaren Sie einen Stichtag, zulässige Änderungen während der Überlappung und die vor Abschluss erforderlichen Nachweise.
Halten Sie ein aktuelles Projektinventar, den vereinbarten Arbeitsumfang und Zugang zum sicheren Credential-System des Kunden bereit. Legen Sie fest, wie die Kontowiederherstellung funktioniert, bevor der ausscheidende Operator entfernt wird. Wenn die Übergabe auf einen vermuteten Kompromiss folgt, sollte der Incident-Response-Verantwortliche den Zeitpunkt der Eindämmung bestimmen; die normale Überlappungssequenz kann unangemessen sein.
Eigentum getrennt vom Login-Zugriff erfassen
Listen Sie für jeden Dienst den Kontoinhaber, die aktuellen Operatoren, Automatisierungsidentitäten, den Wiederherstellungsverantwortlichen und die erforderliche Übertragungsaktion auf. Ein Administrator-Login klärt nicht, wer die Abrechnung oder Wiederherstellung kontrolliert. Zeichnen Sie nur Credential-Referenzen oder Public-Key-Fingerabdrücke auf; niemals Passwörter, Tokens, private Schlüssel oder Wiederherstellungscodes in dieses Register aufnehmen.
Horizontal scrollen für alle Tabellenspalten.
| Projekt-Asset | Eigentumsfrage | Abschlussnachweis |
|---|---|---|
| Domain und DNS | Wer kontrolliert den Registrar, die Verlängerung und den Wiederherstellungskontakt? | Eigentümer bestätigt Zugriff und aktuelle Datensätze. |
| Hosting und Server | Wer kontrolliert das Konto, die Konsole und privilegierte Benutzer? | Nachfolger verifiziert notwendigen Zugriff unabhängig. |
| Repository und Bereitstellung | Wem gehören das Repository, die Automatisierung und die Deploy-Credentials? | Genehmigtes Release auf ein isoliertes Ziel bereitgestellt. |
| Anwendung und Integrationen | Wer administriert das CMS, E-Mail, APIs und geplante Jobs? | Rollen- und Integrationsprüfungen aufgezeichnet. |
| Backups und Wiederherstellung | Wer kontrolliert den Backup-Speicher und etwaiges erforderliches Entschlüsselungsmaterial? | Nachfolger führt eine isolierte Wiederherstellungsübung durch. |
Eigentum und operatives Wissen übertragen
Verwenden Sie den unterstützten Übertragungs- oder Einladungsmechanismus des Dienstes und lassen Sie den empfangenden Eigentümer die Kontrolle von seinem eigenen Konto aus überprüfen. Vermeiden Sie, die persönliche Identität des Auftragnehmers als gemeinsames Login zu übernehmen. Geben Sie Projekt-Credentials über das genehmigte sichere System neu aus, wo zuvor ein persönliches Konto sie bereitgestellt hat.
Bei GitHub-Repositories behält eine Übertragung zugehörige Secrets, Deploy-Keys und Webhooks bei, und vorhandene Mitwirkende können bestehen bleiben. Überprüfen Sie diese nach der Übertragung ausdrücklich. Der Übertragungsbeleg belegt einen Eigentumswechsel, nicht den Abschluss der Zugriffsentfernung.
Stellen Sie die Release-Referenz, Laufzeitversionen, Konfigurationsorte, geplanten Jobs, externen Abhängigkeiten, den Backup-Umfang und das Wiederherstellungsverfahren bereit. Fügen Sie bekannte Fehler und die nächste Wartungsaufgabe hinzu. Erklären Sie, wo Credentials sicher abgerufen werden, ohne ihre Werte in die Dokumentation zu kopieren.
Den Nachfolger die Arbeit ausführen lassen
Bitten Sie den Nachfolger, das schriftliche Verfahren zu befolgen, ohne die Sitzung des Auftragnehmers zu verwenden. Er sollte die genehmigte Quelle beziehen, auf ein isoliertes Testziel bereitstellen, nützliche Logs finden und die zulässige Anwendungsadministrationsaufgabe demonstrieren. Zeichnen Sie jeden fehlenden Schritt auf, aktualisieren Sie dann die Anweisungen und wiederholen Sie die betroffene Prüfung.
Lassen Sie ihn ein vereinbartes Backup an einem separaten Testziel wiederherstellen, wobei ausgehende Integrationen deaktiviert oder umgeleitet sind. Prüfen Sie repräsentative Datensätze, Uploads und Anwendungsverhalten. Zeichnen Sie die Backup-Kennung, das Ziel, die verstrichene Zeit und ungelöste Lücken auf. Überschreiben Sie nicht die Produktion, um die Wiederherstellung zu demonstrieren, und interpretieren Sie einen erfolgreichen Backup-Job nicht als abgeschlossenen Wiederherstellungstest.
Ausscheidenden Zugriff über alle Wege entfernen
Nachdem der Ersatz-Zugang und die Wiederherstellung überprüft wurden, entfernen Sie den Auftragnehmer aus den relevanten Teams, Repositories, Hosting-Konten und Anwendungsrollen. Überprüfen Sie aktive Sitzungen und widerrufen Sie Projekt-Token, Integrationen und Anmeldeinformationen, die er zurückbehalten könnte. Wenn eine Anmeldeinformation gemeinsam genutzt wird, stellen Sie ihren Ersatz aus, aktualisieren Sie abhängige Dienste und testen Sie sie, bevor Sie den alten Wert außer Betrieb nehmen. Wiederholen Sie die Aufgabe des Ersatzes nach dem Widerruf, um versteckte Abhängigkeiten von einer alten Anmeldeinformation zu erkennen.
GitHub-Deploy-Schlüssel bleiben aktiv, wenn ihr Ersteller aus einem Repository entfernt wird. Überprüfen Sie sie separat, einschließlich Schreibberechtigungen und der Maschine, die jeden Schlüssel verwendet. Für autorisierte OAuth-Apps sollte der Kontoinhaber die App-Liste überprüfen und veraltete Autorisierungen mithilfe der GitHub-Steuerelemente widerrufen.
Für SSH-Zugriff identifizieren Sie die tatsächliche Konfiguration der Public-Key-Autorisierung. OpenSSH dokumentiert, dass AuthorizedKeysFile die Dateien auswählt, die für die Public-Key-Authentifizierung verwendet werden; gehen Sie nicht davon aus, dass jeder Server eine Standarddatei verwendet. Halten Sie einen verifizierten Wiederherstellungspfad bereit und testen Sie die neue Verbindung des Ersatzes und die erforderlichen Berechtigungen, bevor Sie die Wartungssitzung beenden.
Beispiel: Das Repository wurde verschoben, aber die Bereitstellung nicht
In diesem fiktiven Szenario wechselt Cedar Workshop seinen Website-Auftragnehmer. Das Repository erreicht die Organisation des Kunden, aber der Deployment-Job verwendet noch immer eine Anmeldeinformation, die dem ausscheidenden Auftragnehmer gehört. Der Ersatz kann Code bearbeiten, aber den genehmigten Build nicht veröffentlichen. Die Übergabe bleibt unvollständig.
Der Eigentümer arrangiert eine projektgesteuerte Deployment-Anmeldeinformation mit den für diesen Job erforderlichen Berechtigungen. Der Ersatz überprüft Deployment und Wiederherstellung auf dem Testziel. Das Team nimmt dann die alte Anmeldeinformation außer Betrieb, überprüft verbleibende Deploy-Schlüssel und führt die zulässigen Prüfungen erneut durch. Der Abschlussbericht verweist auf diese Ergebnisse, ohne Anmeldeinformationswerte zu enthalten.
Mit Nachweisen und geplantem Eigentum abschließen
Erfassen Sie den Eigentümer, der die Übergabe akzeptiert hat, jede widerrufene Zugriffsreferenz, den Abschlusszeitpunkt, die Testergebnisse des Ersatzes und offene Ausnahmen. Bestätigen Sie, wer beim nächsten geplanten Job-Fehler, der Domain-Verlängerung und der Wartungsaufgabe handeln wird. Vereinbaren Sie, wie temporäre Testdaten und projektbezogene Kopien im Besitz des Auftragnehmers im Rahmen der bestehenden Vereinbarung behandelt werden.
Das Entfernen des Zugriffs kann nicht beweisen, dass historische Kopien nie zurückbehalten wurden. Eine Wiederherstellungsübung beweist das getestete Szenario, nicht jeden Fehlermodus. Halten Sie diese Grenzen sichtbar und übertragen Sie ungelöste Arbeiten mit einem benannten Verantwortlichen und einem Fälligkeitsdatum in das Betriebsverantwortungsprotokoll.
Quellen & Prüfung
Technische Referenzen wurden am 12. September 2026 geprüft. Beispiele sind Planungsübungen; referenzierte Softwaredokumentation belegt keine PrivateHostLab Servicefähigkeiten.