Just-in-Time Access Explained: How to Eliminate Standing Privileges in Your Enterprise
Majoritatea incidentelor de securitate din întreprinderi care implică acces privilegiat au o cauză comună: contul compromis avea acces pe care nu-l avea nevoie, la sisteme pe care nu le-a atins de săptămâni, cu credențiale care au fost valide pentru luni. Atacatorul nu a escalat privilegiile — privilegiile erau deja acolo, în picioare, așteptând. Aceasta este problema privilegiilor în picioare, și aceasta este lacuna specifică pe care accesul just-in-time este proiectat să o închidă.
Ce Este Just-in-Time Access — și Cum Diferă de PAM-ul Tradițional
PAM tradițional operează pe un model de depozit și retragere. Credențialele privilegiate sunt stocate într-un Vault. Când un sysadmin are nevoie de acces, retrage credențialele, se conectează la sistemul țintă și returnează credențialele când termină. Aceasta este mai bună decât foile de calcul partajate și notițele lipicioase, dar are în continuare o problemă structurală fundamentală: contul privilegiat în sine există permanent pe sistemul țintă. Contul Administrator pe serverul Windows, contul root pe gazda Linux, contul sa pe baza de date — aceste conturi sunt întotdeauna prezente, întotdeauna activate, întotdeauna o țintă.
Just-in-time (JIT) access adopă o abordare diferită: elimina contul în picioare în întregime, sau cel puțin asigură că contul este dezactivat și credențialele sunt rotite imediat înainte și după fiecare utilizare. Accesul este provizionat la cerere pentru un utilizator specific, o țintă specifică și o fereastră de timp specifică. Când fereastra expiră, accesul este revocart automat — nu este returnat, ci elimitat.
Principiul zero standing privileges (ZSP) extinde acest lucru mai departe: niciun cont privilegiat nu ar trebui să aibă acces persistent la niciun sistem de producție. Fiecare sesiune privilegiată este o autorizare temporară cu un start definit, o încheiere definită și o pista de audit completă. Când nicio sesiune nu este activă, niciun acces privilegiat nu există.
Diferența practică dintre PAM tradițional și JIT/ZSP:
- PAM tradițional: Grupul
Domain Adminsare 15 membri. Credențialele sunt în Vault. Membrii retrag credențialele când au nevoie. Conturile există 24/7 pe fiecare server conectat la domeniu. - JIT PAM: Nicio belonged în picioare la
Domain Admins. Când un sysadmin are nevoie de acces ridicat, trimite o cerere limitată la un server specific și o durată specifică. Sistemul provizionează accesul, creează sesiunea, o înregistrează și o revocă la sfârșitul ferestrei de timp.
Suprafața de atac în modelul tradițional este fiecare moment în care contul există, față de fiecare sistem pe care îl poate atinge. Suprafața de atac în modelul JIT este durata sesiunii aprobate, față de ținta specifică aprobată.
Înainte de JIT vs După JIT — Un Scenariu Concret
Înainte de JIT: Un sysadmin senior la o companie cu 500 de persoane a fost în echipă timp de patru ani. Sunt membru permanent al grupului Domain Admins și au acces RDP admin în picioare la aproximativ 200 de servere — dezvoltare, testare și producție. Folosesc acest acces activ pentru poate 20 de servere în mod regulat. Celelalte 180 sunt infrastructură pe care au configurat-o în timpul migrațiilor și nu au atins-o de atunci. Credențialele lor sunt în SSO-ul corporativ, contul lor nu a fost niciodată revizuit pentru reducerea scopului, iar accesul lor nu s-a schimbat de când s-au alăturat.
Când laptopul lor este folosit în atac de phishing țintit, atacatorul are acces imediat, persistent și necontestat la toate 200 de servere. Raza de explozie este întreaga infrastructură.
După JIT: Același sysadmin nu are acces privilegiat în picioare. Când trebuie să efectueze întreținere pe un server de producție specific, trimite o cerere: „Am nevoie de acces RDP admin la prod-db-03 pentru 4 ore pentru a aplica patch-ul trimestrial." Cererea este revizuită de managerul lor și de un membru al echipei de securitate printr-un flux de aprobare Slack. Odată aprobată, sistemul provizionează o credențială limitată în timp la acel server specific. Sesiunea este înregistrată automat de la început la sfărșit. La sfârșitul a 4 ore, accesul este revocat și credențiala este rotită.
Când laptopul lor este folosit în atac de phishing, atacatorul are acces la orice sesiuni active care există în acel moment. Dacă nicio sesiune nu este aprobată și activă în prezent, atacatorul nu are acces privilegiat la niciun sistem de producție. Raza de explozie este delimitată de ceea ce a fost aprobat și activ în momentul compromiterii — nu întreaga amprentă infrastructurii de acces al sysadmin-ului din cariera lor.
JIT Access și Conformitate — Cum Se Mapează ZSP la NIS2, SOC 2 și ISO 27001
JIT access și zero standing privileges nu sunt doar bună practică de securitate — acestea sunt din ce în ce mai explicit cerințe în cadrele de conformitate pe care întreprinderile din CEE și Europa trebuie să le satisfacă.
NIS2 Articolul 21 — Least Privilege: NIS2 cere ca entitățile esențiale să implementeze controlul accesului pe baza principiilor de least privilege. „Least privilege" în contextul NIS2 înseamnă că accesul ar trebui acordat doar în limita necesară pentru a efectua o sarcină specifică. Accesul admin în picioare la 200 de servere eșuează această testare prin definiție — sysadmin-ul care folosește 20 din acele servere în mod regulat are acces în picioare la 180 pe care nu le are nevoie. JIT access impune least privilege din punct de vedere structural: accesul este întotdeauna limitat la sistemul specific și fereastra de timp a nevoii reale.
SOC 2 CC6.3 — Access Revocation: Criteriile de Servicii de Încredere SOC 2 cerin că accesul este eliminat prompt atunci când nu mai este necesar. CC6.3 acoperă în mod specific revocarea accesului pentru angajații demiși, schimbările de rol și încheierile de proiecte. JIT access satisface CC6.3 automat: accesul expiră la sfârșitul ferestrei aprobate fără niciun pas manual de revocare. Întrebarea auditorului — „cum asigurați că accesul este eliminat când nu mai este necesar?" — are un răspuns determinist: „Expiră automat; iată jurnalul de audit al fiecărei expirări de sesiune."
ISO 27001 Annex A.9.2 — Access Provisioning: ISO 27001 A.9.2.2 cere un proces formal de provizionare a accesului, și A.9.2.3 cere ca drepturi de acces privilegiate să fie alocate pe bază de necesitate. „Necesitate de utilizare" este limbajul ISO 27001 pentru least privilege, și se mapează direct la JIT: accesul ar trebui să existe când este necesar și să nu existe când nu este necesar. A.9.2.5 cere revizuirea periodică a drepturilor de acces al utilizatorului — cu JIT access, revizuirea este continuă mai degrabă decât periodică, deoarece accesul este re-acordat din zero pentru fiecare sesiune.
Argumentul conformității pentru JIT este direct: privilegiile în picioare sunt structural non-conforme cu principiul least privilege pe care NIS2, SOC 2 CC6.3 și ISO 27001 A.9.2 le cerin. JIT este modelul de implementare care face least privilege operațional viabil la scară.
Cum VaultPAM Implementează JIT Access
VaultPAM implementează JIT access prin patru mecanisme integrate:
Approval workflows: Când un utilizator solicită acces privilegiat la un sistem țintă, VaultPAM direcționează cererea la aprobatorul potrivit — manager, echipă de securitate, sau ambii, în funcție de nivelul accesului și sensibilitatea sistemului. Aprobările pot fi completate prin interfața web VaultPAM sau prin canale de notificare integrate. Cererea include sistemul țintă, durata solicitată și justificarea, oferind aprobatorul contextul pentru a lua o decizie informată.
Time-bounded sessions: Fiecare acord de acces aprobat include o durată de expirare hard. Fereastra sesiunii este setată la momentul aprobării — 1 oră, 4 ore, 8 ore, sau o durată personalizată până la maximul politicii. Când fereastra sesiunii expiră, VaultPAM revocă accesul automat. Nu există niciun pas manual, niciun email de reamintire, nicio dependență de utilizatorul care se deconectează. Accesul pur și simplu încetează să existe.
Auto-expiry și credential rotation: Pentru sesiunile RDP și SSH, VaultPAM provizionează o credențială specifică sesiunii la începutul ferestrei aprobate și o rotește la expirare. Credențiala care a existat pentru sesiunea aprobată nu mai funcționează după expirare. Un atacator care captează credențiala în mijlocul sesiunii nu o poate reutiliza după încheierea ferestrei.
Audit trail: Fiecare cerere JIT — submisie, aprobare sau respingere, start sesiune, durată sesiune, înregistrare sesiune și expirare — este înregistrată în jurnalul de audit imuabil al VaultPAM. Pista de audit include identitatea aprobatorului, marca de timp a aprobării, textul justificării și o înregistrare completă a activității sesiunii. Aceasta este pachetul de dovezi care satisface cererile de audit NIS2, eșantionarea auditorului SOC 2 și revizuirile spot-check ISO 27001.
Vezi VaultPAM JIT access în acțiune — elimina privilegiile în picioare în mediul tău