Conveniți asupra ferestrei de predare și a responsabililor
Confirmați cine este autorizat să aprobe transferurile și să revoce accesul. Numiți proprietarul contului clientului, contractorul care pleacă, operatorul înlocuitor și persoana care poate ajuta dacă accesul se întrerupe. Conveniți un termen limită, modificările permise în timpul suprapunerii și dovezile necesare înainte de finalizare.
Aveți un inventar actual al proiectului, sfera de lucru convenită și acces la sistemul securizat de credențiale al clientului. Stabiliți cum funcționează recuperarea contului înainte de a elimina operatorul care pleacă. Dacă predarea urmează unei suspiciuni de compromitere, responsabilul de răspuns la incidente ar trebui să determine momentul izolării; secvența normală de suprapunere poate fi inadecvată.
Inventariați separat proprietatea de accesul prin autentificare
Enumerați pentru fiecare serviciu proprietarul contului, operatorii curenți, identitățile de automatizare, responsabilul de recuperare și acțiunea de transfer necesară. O autentificare de administrator nu stabilește cine controlează facturarea sau recuperarea. Înregistrați doar referințe de credențiale sau amprente de chei publice; nu puneți niciodată parole, tokenuri, chei private sau coduri de recuperare în acest registru.
Derulați orizontal pentru toate coloanele tabelului.
| Activ de proiect | Întrebare privind proprietatea | Dovadă de finalizare |
|---|---|---|
| Domeniu și DNS | Cine controlează registrarul, reînnoirea și contactul de recuperare? | Proprietarul confirmă accesul și înregistrările curente. |
| Găzduire și server | Cine controlează contul, consola și utilizatorii privilegiați? | Înlocuitorul verifică independent accesul necesar. |
| Depozit și implementare | Cine deține depozitul, automatizarea și credențialele de implementare? | Versiune aprobată implementată pe o țintă izolată. |
| Aplicație și integrări | Cine administrează CMS-ul, e-mailul, API-urile și sarcinile programate? | Verificări de rol și integrări înregistrate. |
| Backup și recuperare | Cine controlează stocarea backup-ului și orice material de decriptare necesar? | Înlocuitorul finalizează un exercițiu de recuperare izolat. |
Transferați proprietatea și cunoștințele operaționale
Folosiți mecanismul de transfer sau invitație acceptat de serviciu, apoi rugați proprietarul primitor să verifice controlul din propriul cont. Evitați adoptarea identității personale a contractorului ca autentificare partajată. Reemiteți credențialele proiectului prin sistemul securizat aprobat acolo unde anterior le furniza un cont personal.
Pentru depozitele GitHub, un transfer păstrează secretele asociate, cheile de implementare și webhook-urile, iar colaboratorii existenți pot rămâne. Verificați-le explicit după transfer. Confirmarea transferului stabilește o schimbare de proprietate, nu finalizarea eliminării accesului.
Furnizați referința versiunii, versiunile de runtime, locațiile de configurare, sarcinile programate, dependențele externe, sfera backup-ului și procedura de recuperare. Adăugați defecțiunile cunoscute și următoarea sarcină de mentenanță. Explicați unde sunt obținute credențialele în siguranță fără a copia valorile lor în documentație.
Lăsați înlocuitorul să efectueze lucrarea
Rugați înlocuitorul să urmeze procedura scrisă fără a împrumuta sesiunea contractorului. Ar trebui să obțină sursa aprobată, să implementeze pe o țintă de test izolată, să localizeze jurnalele utile și să demonstreze sarcina de administrare a aplicației permisă. Înregistrați fiecare pas lipsă, apoi actualizați instrucțiunile și repetați verificarea afectată.
Rugați-i să restaureze un backup convenit într-o destinație de test separată, cu integrările de ieșire dezactivate sau redirecționate. Verificați înregistrările reprezentative, încărcările și comportamentul aplicației. Înregistrați identificatorul backup-ului, ținta, timpul scurs și lacunele nerezolvate. Nu suprascrieți producția pentru a demonstra recuperarea și nu interpretați un job de backup reușit ca un test de restaurare finalizat.
Eliminați accesul persoanei care pleacă pe toate căile
După ce accesul de înlocuire și recuperarea sunt verificate, eliminați contractorul din echipele, depozitele, conturile de găzduire și rolurile aplicațiilor relevante. Examinați sesiunile active și revocați tokenurile de proiect, integrările și acreditările pe care le-ar putea păstra. Acolo unde o acreditare este partajată, emiteți înlocuitorul acesteia, actualizați serviciile dependente și testați-le înainte de a retrage vechea valoare. Repetați sarcina înlocuitorului după revocare pentru a detecta dependența ascunsă de o acreditare veche.
Cheile de implementare GitHub rămân active atunci când creatorul lor este eliminat dintr-un depozit. Inspectați-le separat, inclusiv permisiunile de scriere și mașina care utilizează fiecare cheie. Pentru aplicațiile OAuth autorizate, proprietarul contului ar trebui să revizuiască lista de aplicații și să revoce autorizațiile obsolete folosind controalele GitHub.
Pentru accesul SSH, identificați configurația reală de autorizare a cheilor publice. OpenSSH documentează că AuthorizedKeysFile selectează fișierele utilizate pentru autentificarea cu chei publice; nu presupuneți că fiecare server folosește un singur fișier implicit. Păstrați o cale de recuperare verificată și testați conexiunea nouă a înlocuitorului și privilegiile necesare înainte de a închide sesiunea de mentenanță.
Exemplu: depozitul a fost mutat, dar implementarea nu
În acest scenariu fictiv, Cedar Workshop își schimbă contractorul pentru site. Depozitul ajunge în organizația clientului, dar jobul de implementare folosește încă o acreditare deținută de contractorul care pleacă. Înlocuitorul poate edita codul, dar nu poate publica build-ul aprobat. Predarea rămâne incompletă.
Proprietarul aranjează o acreditare de implementare controlată de proiect, cu permisiunile necesare pentru acel job. Înlocuitorul verifică implementarea și recuperarea pe ținta de test. Apoi echipa retrage vechea acreditare, revizuiește cheile de implementare rămase și rulează din nou verificările permise. Înregistrarea de închidere face referire la aceste rezultate fără a conține valori de acreditare.
Încheiați cu dovezi și responsabilitate programată
Înregistrați proprietarul care a acceptat predarea, fiecare referință de acces revocată, timpul de finalizare, rezultatele testelor de înlocuire și excepțiile în suspensie. Confirmați cine va acționa la următoarea defecțiune a jobului programat, reînnoirea domeniului și sarcina de mentenanță. Conveniți cum sunt gestionate datele de test temporare și copiile de proiect deținute de contractor conform acordului existent.
Eliminarea accesului nu poate dovedi că copiile istorice nu au fost niciodată păstrate. Un exercițiu de recuperare dovedește scenariul testat, nu fiecare mod de eșec. Păstrați aceste limite vizibile și transferați lucrările nerezolvate în registrul de responsabilitate operațională, cu un proprietar numit și o dată scadentă.
Surse și recenzii
Referințele tehnice au fost verificate în septembrie 12, 2026. Exemplele sunt exerciții de planificare; documentația software menționată nu stabilește capabilitățile de serviciu PrivateHostLab.