Un coleg pleacă. Îi poți opri accesul fără să blochezi firma?
Cum separi drepturile personale de munca firmei: o matrice pe operațiuni și o probă cu un cont retras și un înlocuitor.
Când un coleg pleacă, ai două lucruri de verificat în aplicația firmei: el nu mai poate folosi drepturile retrase, iar persoana care îi preia munca poate continua operațiunea cu propriul cont. Un mesaj „utilizator dezactivat” răspunde doar parțial. Întrebarea este ce se întâmplă cu cererea care aștepta aprobarea lui.
Colegul pleacă, cererea rămâne
Să luăm un exemplu fictiv. Într-o platformă internă, Ana pregătește o cerere de achiziție, iar Mihai o aprobă. Mihai pleacă din firmă. Cererea există în continuare, dar cine o poate aproba acum?
Dacă răspunsul este „intrăm cu contul lui”, predarea muncii încă depinde de identitatea persoanei plecate. Dacă răspunsul este „îi dăm Anei rol de administrator”, ai acordat drepturi mai largi decât cele necesare pentru cererea respectivă. În exemplul nostru, înlocuitorul este Radu. El are nevoie de dreptul de a aproba cererile din aria lui, cu propriul cont, fără să primească acces la tot sistemul.
OWASP distinge autentificarea, care verifică identitatea, de autorizare, care verifică dacă acea identitate poate face acțiunea cerută[1]. Faptul că Radu se poate autentifica nu spune încă dacă poate aproba cererea. Nici numele rolului nu descrie singur toate limitele lui.
Scrie drepturile pe operațiunea reală
Înainte să alegi denumiri precum „manager” sau „operator”, descrie ce trebuie să poată face omul. În aceeași cerere, a vedea, a modifica și a aproba sunt drepturi distincte. Contează și resursa: toate cererile firmei sau numai cele ale departamentului său?
Pentru cererea departamentului, matricea arată astfel:
| Operațiune / resursă | Ana — pregătește | Radu — preia aprobarea |
|---|---|---|
| Vede cererea departamentului | Da | Da |
| Modifică cererea înainte de aprobare | Da | Nu în acest exemplu |
| Aprobă cererea departamentului | Nu | Da |
| Vede cereri din alte departamente | Nu | Nu |
| Administrează conturi | Nu | Nu |
În acest exemplu, preluarea aprobării nu cere acces la toate cererile și nici dreptul de a administra conturi. Principiul privilegiilor minime cere doar drepturile necesare muncii, inclusiv delimitarea resurselor accesibile[1]. Decidentul stabilește ce operațiune trebuie permisă; echipa tehnică transpune limita în aplicație și o verifică.
Dacă înlocuitorul nu este încă desemnat, scrie acest lucru în fișă. „Se ocupă cineva” nu identifică un cont și nu permite o probă. Decizia de business rămasă deschisă este cine preia aprobarea, nu cum se numește butonul de dezactivare.
Separă accesul persoanei de dependențele firmei
Aplicația trimite și un raport periodic. Dacă raportul folosește o credențială legată de contul lui Mihai, retragerea accesului poate afecta și raportul. Asta cere o verificare distinctă: cine deține integrarea, ce identitate folosește și cum se schimbă legitim acea dependență?
Nu rezolvi această întrebare păstrând parola fostului coleg. Și nici ștergând la întâmplare conturi sau chei. Cere furnizorului să distingă accesul personal, responsabilitatea asupra cererilor deschise și identitățile folosite de automatizări. Orice schimbare se pregătește și se verifică în mediul potrivit, cu responsabilul sistemului.
Fișa pentru o singură operațiune poate avea patru răspunsuri simple:
- Cine vede resursa și care este limita accesului?
- Cine o modifică și cine o aprobă?
- Cine preia fiecare drept când persoana pleacă sau schimbă rolul?
- Există o automatizare ori un cont comun care depinde de identitatea ei?
Un cont comun merită discutat separat. Dacă mai multe persoane folosesc aceeași identitate, blocarea contului afectează acel acces comun; nu demonstrează că ai retras doar drepturile unei persoane. Articolul tratează aplicația custom și dependențele ei, nu toate conturile IT ale firmei.
Cere o probă cu două conturi de test
Reia cererea într-un mediu de test, cu date fictive. Folosește un cont pentru persoana care pleacă și unul pentru înlocuitor. Înregistrează mai întâi ce drepturi are fiecare. Apoi echipa tehnică aplică retragerea prevăzută și arată rezultatele pe aceeași resursă:
- Contul retras nu mai poate citi sau aproba cererea pentru care i-au fost retrase drepturile.
- Înlocuitorul poate continua operațiunea permisă, folosind propriul cont.
- Înlocuitorul este refuzat pentru o resursă sau acțiune care rămâne în afara drepturilor sale.
- Se verifică și o sesiune de test deja deschisă înainte de retragere, nu doar o autentificare nouă.
Ultimul punct contează pentru întrebarea „mai poate intra?”. OWASP cere verificarea permisiunilor la fiecare cerere și teste pentru logica de autorizare[1]. Ascunderea unui buton nu este demonstrația refuzului unei operațiuni: echipa tehnică trebuie să verifice și răspunsul aplicației la cererea respectivă, în testul autorizat.
Stabilește cu furnizorul când trebuie să devină efectivă retragerea și cum se verifică sesiunile sau tokenii folosiți de aplicație. Nu presupune că toate sunt invalidate instantaneu de aceeași setare. Dacă un rezultat nu corespunde, consemnează exact resursa, acțiunea și contul de test; acestea fac problema reproductibilă.
Ce merită cerut înainte de livrare
SurCod construiește produse software și sisteme pentru afaceri[2]. Pentru un sistem custom, întrebarea despre plecarea unui coleg merită pusă când definești operațiunile și drepturile, nu doar când cauți un cont în lista de utilizatori. Perspectiva este concretă: retragerea accesului și continuarea muncii se judecă pe aceeași operațiune, prin rezultate separate.
Alege acum o operațiune din aplicația ta. Scrie cine vede, cine modifică, cine aprobă și cine îi înlocuiește. Cu această fișă, cere echipei care construiește sau operează sistemul să îți arate proba pe conturi de test. Vei putea distinge o predare funcțională de o simplă schimbare în lista de utilizatori. Proba acoperă operațiunea testată; nu certifică securitatea întregii aplicații.