Spreek het overdrachtsvenster en de eigenaren af
Bevestig wie bevoegd is om overdrachten goed te keuren en toegang in te trekken. Benoem de eigenaar van het klantaccount, de vertrekkende contractor, de vervangende operator en de persoon die kan helpen als toegang uitvalt. Spreek een afsluitmoment af, toegestane wijzigingen tijdens de overlap en het bewijs dat nodig is vóór voltooiing.
Zorg voor een actuele projectinventaris, de overeengekomen werkScope en toegang tot het beveiligde inloggegevenssysteem van de klant. Stel vast hoe accountherstel werkt voordat de vertrekkende operator wordt verwijderd. Als de overdracht volgt op vermoedelijke compromittering, moet de eigenaar van de incidentrespons het moment van insluiting bepalen; de normale overlapvolgorde kan ongeschikt zijn.
Inventariseer eigenaarschap apart van login-toegang
Vermeld per dienst de accounteigenaar, huidige operators, automatiseringsidentiteiten, hersteleigenaar en vereiste overdrachtsactie. Een beheerderslogin bepaalt niet wie de facturatie of het herstel beheert. Registreer alleen referenties naar inloggegevens of fingerprints van openbare sleutels; zet nooit wachtwoorden, tokens, privésleutels of herstelcodes in dit register.
Scroll horizontaal voor alle tabelkolommen.
| Projectasset | Eigenaarschapvraag | Bewijs van voltooiing |
|---|---|---|
| Domein en DNS | Wie beheert de registrar, verlenging en het herstelcontact? | Eigenaar bevestigt toegang en actuele registraties. |
| Hosting en server | Wie beheert het account, de console en geprivilegieerde gebruikers? | Vervanger verifieert zelfstandig de noodzakelijke toegang. |
| Repository en deployment | Wie is eigenaar van de repository, automatisering en deployment-inloggegevens? | Goedgekeurde release uitgerold naar een geïsoleerd doel. |
| Applicatie en integraties | Wie beheert het CMS, e-mail, API's en geplande taken? | Rol- en integratiecontroles geregistreerd. |
| Back-ups en herstel | Wie beheert de back-upopslag en eventueel benodigd decryptiemateriaal? | Vervanger voltooit een geïsoleerde hersteloefening. |
Draag eigenaarschap en operationele kennis over
Gebruik het ondersteunde overdrachts- of uitnodigingsmechanisme van de dienst en laat de ontvangende eigenaar het beheer vanuit hun eigen account verifiëren. Vermijd het overnemen van de persoonlijke identiteit van de contractor als gedeelde login. Geef projectreferenties opnieuw uit via het goedgekeurde beveiligde systeem waar voorheen een persoonlijk account ze leverde.
Bij GitHub-repositories blijven bij een overdracht de bijbehorende secrets, deploy keys en webhooks behouden, en bestaande collaborators kunnen blijven bestaan. Beoordeel deze expliciet na de overdracht. De overdrachtsbevestiging stelt een eigendomswijziging vast, niet de voltooiing van het verwijderen van toegang.
Lever de release-referentie, runtime-versies, configuratielocaties, geplande taken, externe afhankelijkheden, back-upbereik en herstelprocedure. Voeg bekende storingen en de volgende onderhoudstaak toe. Leg uit waar inloggegevens veilig worden opgehaald zonder hun waarden naar documentatie te kopiëren.
Laat de vervanger het werk uitvoeren
Vraag de vervanger de schriftelijke procedure te volgen zonder de sessie van de contractor te lenen. Zij moeten de goedgekeurde bron verkrijgen, uitrollen naar een geïsoleerd testdoel, nuttige logs vinden en de toegestane beheertaak van de applicatie demonstreren. Registreer elke ontbrekende stap, werk de instructies bij en herhaal de betrokken controle.
Laat hen een overeengekomen back-up herstellen naar een afzonderlijke testbestemming met uitgaande integraties uitgeschakeld of omgeleid. Controleer representatieve records, uploads en applicatiegedrag. Registreer de back-up-ID, het doel, de verstreken tijd en onopgeloste hiaten. Overschrijf productie niet om herstel te demonstreren, en interpreteer een geslaagde back-uptaak niet als een voltooide hersteltest.
Verwijder de toegang van de vertrekkende partij via alle routes
Nadat vervangende toegang en herstel zijn geverifieerd, verwijdert u de contractor uit relevante teams, repositories, hostingaccounts en applicatierollen. Controleer actieve sessies en trek projectspecifieke tokens, integraties en inloggegevens in die zij zouden kunnen behouden. Waar een inloggegeven wordt gedeeld, geeft u de vervanging uit, werkt u afhankelijke services bij en test u ze voordat de oude waarde wordt uitgefaseerd. Herhaal de taak van de vervanger na intrekking om verborgen afhankelijkheid van een oud inloggegeven op te sporen.
GitHub deploy keys blijven actief wanneer hun maker uit een repository wordt verwijderd. Inspecteer ze afzonderlijk, inclusief schrijfrechten en de machine die elke sleutel gebruikt. Voor geautoriseerde OAuth-apps moet de accounteigenaar de app-lijst controleren en verouderde autorisaties intrekken met behulp van GitHub's bedieningselementen.
Voor SSH-toegang identificeert u de daadwerkelijke configuratie voor public-key-autorisatie. OpenSSH documenteert dat AuthorizedKeysFile de bestanden selecteert die voor public-key-authenticatie worden gebruikt; ga er niet van uit dat elke server één standaardbestand gebruikt. Houd een geverifieerd herstelpad aan en test de nieuwe verbinding van de vervanger en de vereiste privileges voordat u de onderhoudssessie sluit.
Voorbeeld: de repository is verplaatst, maar de deployment niet
In dit fictieve scenario verandert Cedar Workshop van websitecontractor. De repository bereikt de organisatie van de klant, maar de deployment job gebruikt nog steeds een inloggegeven dat eigendom is van de vertrekkende contractor. De vervanger kan code bewerken maar kan de goedgekeurde build niet publiceren. De overdracht blijft onvolledig.
De eigenaar regelt een projectgebonden deployment-inloggegeven met de rechten die voor die taak nodig zijn. De vervanger verifieert deployment en herstel op het testdoel. Het team faseert daarna het oude inloggegeven uit, beoordeelt resterende deploy keys en voert de toegestane controles opnieuw uit. Het afsluitingsverslag verwijst naar deze resultaten zonder inloggegevens te bevatten.
Sluit af met bewijs en gepland eigenaarschap
Leg de eigenaar vast die de overdracht heeft geaccepteerd, elke verwijzing naar ingetrokken toegang, het tijdstip van voltooiing, de testresultaten van de vervanging en openstaande uitzonderingen. Bevestig wie actie onderneemt bij de volgende geplande jobstoring, domeinverlenging en onderhoudstaak. Spreek af hoe tijdelijke testdata en projectkopieën in het bezit van de contractor worden behandeld onder de bestaande overeenkomst.
Toegangsverwijdering kan niet bewijzen dat historische kopieën nooit zijn behouden. Een hersteloefening bewijst het geteste scenario, niet elke faalmodus. Houd die grenzen zichtbaar en neem onopgelost werk op in het operationele verantwoordelijkheidsregister met een genoemde eigenaar en einddatum.
Bronnen en review
Technische referenties zijn gecontroleerd op september 12, 2026. Voorbeelden zijn planningsoefeningen; de gedocumenteerde software-referenties bevestigen geen PrivateHostLab-servicecapaciteiten.