Într-o companie care funcționează de câțiva ani, întrebarea „câte conturi active aparțin unor persoane care nu mai lucrează aici?” nu are, de regulă, un răspuns. Nu pentru că nimeni nu s-ar fi ocupat de plecări, ci pentru că un răspuns ar presupune o listă completă a sistemelor în care se pot crea conturi, iar lista aceasta nu există actualizată nicăieri.
Problema nu se rezolvă cu mai multă atenție. Se rezolvă schimbând locul în care este ținută evidența: din memoria oamenilor, într-un sistem care produce evenimente.
De ce plecările se rezolvă doar parțial
Un proces de plecare tipic pornește de la o notificare informală și se execută pe baza a ceea ce își amintește administratorul de sistem despre persoana respectivă. Funcționează pentru sistemele vizibile: contul de e-mail, calculatorul, accesul la partajările de fișiere. Se oprește exact acolo unde încep sistemele adăugate în timp de alte departamente, fără ca IT-ul să fie implicat la instalare.
Al doilea motiv este momentul declanșării. Departamentul de resurse umane înregistrează încetarea contractului conform propriului calendar, iar IT-ul află uneori după ultima zi lucrată. În ziua plecării, prioritatea reală a managerului este predarea lucrărilor, nu revocarea accesului.
Al treilea motiv este că o revocare parțială arată identic cu una completă. Nimeni nu raportează un acces rămas deschis, pentru că nimeni nu îl folosește vizibil. Se semnalează doar accesul care lipsește.
În producție și în logistică apare un factor suplimentar: o parte importantă din personal nu are dispozitiv de companie și nu are cont individual de e-mail. Accesul acestor oameni trece prin stații partajate din hală, terminale de scanare, aplicații de pontaj, cartele de acces în clădire, conturi în portalurile transportatorilor și, uneori, conturi în sistemele partenerilor. Niciunul dintre acestea nu apare în directorul de identitate, deci niciunul nu se închide când se dezactivează un cont în director.
Schimbarea de rol, cazul care se tratează și mai rar
Plecarea are măcar un moment declanșator clar. Schimbarea rolului nu are. Cineva trece de la depozit la aprovizionare, primește drepturile noi în prima săptămână, iar drepturile vechi rămân, pentru că retragerea lor nu este cerută de nimeni și nu deranjează pe nimeni.
Efectul se acumulează liniar cu vechimea. După câteva schimbări interne, o persoană deține reuniunea tuturor rolurilor pe care le-a ocupat, iar în multe organizații cel mai larg acces nu îl are un administrator, ci un angajat cu vechime mare care a trecut prin trei departamente. Aceleași drepturi se moștenesc mai departe atunci când un cont nou este creat „la fel ca al colegului”, practică frecventă tocmai pentru că este rapidă.
La acestea se adaugă accesele acordate temporar pentru un proiect, pentru o inventariere sau pentru un audit, care nu au niciodată o dată de expirare atașată. Un acces temporar fără termen este un acces permanent cu o justificare temporară.
O sursă autoritativă pentru identitate
Ciclul de intrare, modificare și plecare devine fiabil doar când este declanșat de sistemul care știe primul: evidența de personal. Angajarea, schimbarea de poziție și încetarea contractului sunt deja înregistrate acolo, cu date de intrare în vigoare. Ce lipsește de obicei este transmiterea lor către infrastructura de identitate.
Trei condiții fac diferența între o integrare care funcționează și una care produce erori zilnice.
Prima este un identificator stabil, propriu persoanei, folosit în toate sistemele. Numele nu este identificator: se scrie diferit cu și fără diacritice, se schimbă, se repetă.
A doua este calitatea datelor din evidența de personal. Dacă poziția este completată în text liber, corespondența dintre rol și drepturi nu poate fi automatizată. Un catalog de roluri, chiar sumar, cu accesul de bază pentru fiecare, este condiția minimă.
A treia este tratarea separată a încetărilor imediate. Un concediu disciplinar sau o plecare conflictuală cer revocare în minute, nu la următoarea sincronizare. Este nevoie de un canal manual, cunoscut și testat, care execută revocarea la cerere și lasă urmă.
Ce se automatizează și ce rămâne manual
Aplicațiile care suportă SCIM se aprovizionează și se dezactivează automat din director. Cele integrate prin SAML sau OpenID Connect se închid implicit la dezactivarea contului central, pentru că nu mai există o cale de autentificare independentă. Aceste două categorii ar trebui să acopere majoritatea aplicațiilor folosite zilnic, iar extinderea lor este cea mai eficientă investiție din tot proiectul.
Restul rămâne o listă lungă și eterogenă: conturi locale în ERP, WMS sau în aplicația de producție, aplicații SaaS achiziționate direct de un departament pe cardul firmei, chei SSH lăsate pe servere, jetoane de acces în API-uri, conturi de serviciu, profiluri VPN cu certificat propriu, cartele de acces fizic, conturi de utilizator în platforme de telematică, precum și accesele acordate de parteneri în propriile lor sisteme, unde revocarea nu vă aparține și trebuie cerută.
Obiectivul realist nu este automatizarea completă a acestei liste. Este reducerea ei la un inventar scurt, cu un responsabil numit pentru fiecare intrare, ținut într-un loc care se actualizează atunci când se adaugă un sistem nou. Practic, aceasta înseamnă ca achiziția oricărei aplicații să treacă printr-un pas în care se stabilește cum se creează și cum se închide un cont în ea.
Conturile de serviciu și credențialele partajate
Aceasta este categoria cea mai dificilă, pentru că revocarea afectează pe altcineva decât persoana care pleacă. O parolă folosită de o echipă întreagă nu se schimbă la plecarea unui membru, pentru că schimbarea oprește lucrul celorlalți. Rezultatul este că fiecare persoană care a trecut prin echipă păstrează, în practică, acces.
Plecarea unei persoane care cunoștea o credențială partajată este, tehnic, un incident de securitate minor care cere rotație. Dacă rotația este atât de costisitoare încât nu se face niciodată, problema nu este disciplina, ci arhitectura.
Direcția de lucru are trei componente. Identitate individuală chiar și pe echipamente partajate, prin cartelă și PIN sau prin sesiuni scurte legate de o persoană, ceea ce elimină cea mai mare parte a credențialelor comune din operațiuni. Un inventar al conturilor de serviciu, în care fiecare are un proprietar, un scop declarat și un mecanism de rotație, iar cele fără proprietar identificabil se dezactivează controlat și se observă ce se oprește. Și eliminarea autentificării interactive pentru conturile tehnice, prin identități gestionate de platformă acolo unde sunt disponibile, astfel încât să nu mai existe o parolă pe care cineva să o poată cunoaște.
Dezactivarea contului nu închide accesul existent
Dezactivarea împiedică o autentificare nouă. Nu invalidează, singură, ceea ce a fost deja emis.
Sesiunile deschise în browser rămân valabile până la expirare. Jetoanele de reîmprospătare pot prelungi accesul zile întregi. Aplicațiile terțe cărora persoana le-a acordat consimțământ păstrează propriile jetoane. Parolele de aplicație, cheile de API și jetoanele personale continuă să funcționeze. Un profil VPN care se autentifică pe bază de certificat funcționează până la revocarea certificatului, indiferent de starea contului. Iar dispozitivul înregistrat în sistemul de administrare a echipamentelor rămâne înrolat până când este șters explicit.
Un proces de plecare complet include, ca pași distincți, închiderea sesiunilor active, revocarea jetoanelor de reîmprospătare și a consimțămintelor acordate aplicațiilor, revocarea certificatelor, ștergerea înregistrării dispozitivelor și rotația secretelor la care persoana avea acces în seiful de parole.
Revizuirea accesului, dincolo de semnătura formală
Revizuirea periodică a drepturilor se transformă ușor în formalitate. Un fișier cu sute de rânduri și denumiri de grupuri lipsite de sens pentru un manager se aprobă în bloc, iar rezultatul este o dovadă de audit fără efect operațional.
Ce o face utilă: împărțirea pe sisteme cu semnificație de business, în loc de un tabel unic; afișarea ultimei autentificări lângă fiecare drept, pentru că un acces nefolosit de șase luni este ușor de retras; formularea în termeni de ce permite dreptul, nu de numele grupului tehnic; și tratarea neconfirmării ca retragere, nu ca păstrare. O comparație periodică între directorul de identitate și evidența de personal completează exercițiul, pentru că scoate la iveală conturile fără persoană.
Accesul privilegiat este un capitol separat
Drepturile administrative nu se administrează prin aceleași mecanisme. Modelul funcțional este seiful, cu eliberare la cerere pentru o durată limitată, motiv înregistrat, rotație automată după folosire și jurnalizarea sesiunii.
Plecarea unui administrator este un eveniment diferit de plecarea unui utilizator, pentru că nu se rezolvă prin dezactivarea contului său. Cere rotația a tot ce a putut citi: parole de administrator local, chei ale conturilor de serviciu, credențiale de acces la echipamentele de rețea, chei API în furnizorii de cloud. Aceeași categorie include accesul permanent al furnizorilor, de exemplu al integratorului care a instalat linia de producție și a rămas cu o conexiune de întreținere deschisă de ani de zile.
Colaboratori și personal prin firme de muncă temporară
Despre plecarea unui colaborator extern nimeni nu anunță IT-ul, pentru că relația se încheie între două firme, nu printr-un proces intern de personal. Aceeași situație apare la personalul furnizat prin agenții, unde rotația este mare și evidența aparține agenției.
Singura măsură care rezistă este expirarea implicită. Contul se creează cu o dată de încetare egală cu termenul din contract, se prelungește doar la cererea explicită a unui responsabil intern desemnat și se închide automat dacă nu se cere nimic. Este mai puțin elegant decât o notificare corectă și funcționează fără să depindă de ea.
Ce se cere la audit
Un auditor nu evaluează intenția procesului, ci dovezile. În practică se cer aceleași lucruri: lista plecărilor dintr-o perioadă, alături de momentul dezactivării fiecărui cont, astfel încât întârzierea să fie măsurabilă; procesul scris de intrare, modificare și plecare; înregistrările revizuirilor de acces, cu numele celui care a confirmat și data; jurnalele sesiunilor privilegiate; și inventarul conturilor de serviciu cu proprietarii lor.
Pentru companiile aflate sub incidența NIS2, controlul accesului și gestionarea conturilor privilegiate sunt cerințe explicite între măsurile de administrare a riscurilor, iar ISO 27001 verifică aceleași elemente prin controalele de gestiune a identității. Ambele cer să demonstrați că măsura funcționează, nu că există.
Ordinea practică a lucrărilor
Inventarul sistemelor, cu un responsabil pentru fiecare, este primul pas, pentru că fără el restul nu are perimetru. Urmează o reconciliere între director și evidența de personal, care identifică situația actuală; conturile fără persoană se dezactivează, nu se șterg, și se păstrează o perioadă, pentru că unele se dovedesc a fi conturi de serviciu deghizate.
Apoi se stabilește un singur declanșator, din evidența de personal, și se extinde SSO și aprovizionarea automată la aplicațiile cele mai folosite, ceea ce scurtează lista manuală. Procedura de plecare se rescrie cu pașii de revocare a sesiunilor și a jetoanelor incluși explicit. La final se aduc în ordine conturile de serviciu, se introduce seiful pentru accesul privilegiat și se pornește ciclul de revizuire.
Consolidarea directorului, procesele de intrare și plecare și accesul privilegiat fac parte din serviciul de identitate și management al accesului, iar cartelele, terminalele și accesul fizic care trebuie închise în același timp țin de controlul accesului.