Accesso Just-in-Time Spiegato: Come Eliminare i Privilegi Permanenti nella Tua Azienda

La maggior parte degli incidenti di sicurezza aziendale che coinvolgono l'accesso privilegiato condividono una causa comune: l'account compromesso aveva accesso che non necessitava, a sistemi che non toccava da settimane, con credenziali valide da mesi. L'attaccante non ha elevato i privilegi — i privilegi erano già lì, in piedi, in attesa. Questo è il problema dei privilegi permanenti, ed è lo spazio specifico che l'accesso just-in-time è progettato per colmare.

Cos'è l'Accesso Just-in-Time — e Come Differisce dal PAM Tradizionale

PAM tradizionale opera su un modello vault-and-checkout. Le credenziali privilegiate sono archiviate in un vault. Quando un sysadmin necessita l'accesso, preleva le credenziali, si connette al sistema target e restituisce le credenziali al termine. Questo è meglio dei fogli di calcolo condivisi e dei post-it, ma ha comunque un problema strutturale fondamentale: l'account privilegiato stesso esiste permanentemente nel sistema target. L'account Administrator nel server Windows, l'account root nell'host Linux, l'account sa nel database — questi account sono sempre presenti, sempre abilitati, sempre un bersaglio.

L'accesso just-in-time (JIT) adotta un approccio diverso: eliminare completamente l'account permanente, o quantomeno assicurare che l'account sia disabilitato e le credenziali siano ruotate immediatamente prima e dopo ogni utilizzo. L'accesso viene fornito su richiesta per un utente specifico, un target specifico e una finestra temporale specifica. Quando la finestra scade, l'accesso viene automaticamente revocato — non restituito, ma rimosso.

Il principio di zero standing privileges (ZSP) estende questo ulteriormente: nessun account privilegiato dovrebbe avere accesso persistente a nessun sistema di produzione. Ogni sessione privilegiata è una concessione temporanea con un inizio definito, una fine definita e una traccia di audit completa. Quando nessuna sessione è attiva, nessun accesso privilegiato esiste.

La differenza pratica tra PAM tradizionale e JIT/ZSP:

• PAM tradizionale: Il gruppo Domain Admins ha 15 membri. Le credenziali sono nel vault. I membri prelevano le credenziali quando necessario. Gli account esistono 24/7 su ogni server domain-joined.
• PAM JIT: Nessuna appartenenza permanente a Domain Admins. Quando un sysadmin necessita accesso elevato, invia una richiesta limitata a un server specifico e una durata specifica. Il sistema fornisce l'accesso, crea la sessione, la registra e la revoca al termine della finestra temporale.

La superficie di attacco nel modello tradizionale è ogni momento che l'account esiste, contro ogni sistema che può raggiungere. La superficie di attacco nel modello JIT è la durata della sessione approvata, contro il target specifico approvato.

Prima di JIT vs Dopo JIT — Uno Scenario Concreto

Prima di JIT: Un sysadmin senior in un'azienda di 500 persone è nel team da quattro anni. È un membro permanente del gruppo Domain Admins e ha accesso RDP admin permanente a circa 200 server — sviluppo, staging e produzione. Utilizza attivamente questo accesso per forse 20 server su base regolare. Gli altri 180 sono infrastruttura che ha configurato durante le migrazioni e non ha toccato da allora. Le sue credenziali sono nell'SSO aziendale, il suo account non è mai stato revisionato per ridurre la portata, e il suo accesso non è cambiato da quando si è unito.

Quando il suo laptop viene colpito da phishing in un attacco mirato, l'attaccante ha accesso immediato, persistente e incontrastato a tutti i 200 server. Il raggio di esplosione è l'intera infrastruttura.

Dopo JIT: Lo stesso sysadmin non ha accesso privilegiato permanente. Quando necessita eseguire manutenzione su un server di produzione specifico, invia una richiesta: "Ho bisogno di accesso RDP admin a prod-db-03 per 4 ore per applicare la patch trimestrale." La richiesta è revisionata dal suo responsabile e da un membro del team di sicurezza tramite un flusso di approvazione Slack. Una volta approvata, il sistema fornisce una credenziale limitata nel tempo limitata a quel server specifico. La sessione è automaticamente registrata dall'inizio alla fine. Al termine delle 4 ore, l'accesso viene revocato e la credenziale viene ruotata.

Quando il suo laptop viene colpito da phishing, l'attaccante ha accesso a qualunque sessione attiva esista in quel momento. Se nessuna sessione è attualmente approvata e attiva, l'attaccante non ha accesso privilegiato a nessun sistema di produzione. Il raggio di esplosione è limitato da ciò che è stato approvato e attivo al momento del compromesso — non l'intera impronta infrastrutturale della carriera del sysadmin.

Accesso JIT e Conformità — Come ZSP Si Mappa a NIS2, SOC 2 e ISO 27001

L'accesso JIT e gli zero standing privileges non sono solo una buona pratica di sicurezza — sono sempre più requisiti espliciti nei framework di conformità che le aziende dell'Europa centrale e dell'Europa devono soddisfare.

NIS2 Articolo 21 — Least Privilege: NIS2 richiede che le entità essenziali implementino il controllo di accesso basato su principi di least privilege. "Least privilege" nel contesto NIS2 significa che l'accesso dovrebbe essere concesso solo nella misura necessaria per eseguire un'attività specifica. L'accesso admin permanente a 200 server fallisce questo test per definizione — il sysadmin che utilizza regolarmente 20 di quei server ha accesso permanente a 180 che non necessita. L'accesso JIT applica il least privilege strutturalmente: l'accesso è sempre limitato al sistema specifico e alla finestra temporale della necessità effettiva.

SOC 2 CC6.3 — Revoca di Accesso: I Criteri dei Servizi Fiduciari SOC 2 richiedono che l'accesso sia rimosso prontamente quando non è più richiesto. CC6.3 copre specificamente la revoca di accesso per dipendenti terminati, cambi di ruolo e conclusioni di progetti. L'accesso JIT soddisfa CC6.3 automaticamente: l'accesso scade al termine della finestra temporale approvata senza alcun passaggio di revoca manuale. La domanda dell'auditor — "come assicurate che l'accesso sia rimosso quando non è più necessario?" — ha una risposta deterministica: "Scade automaticamente; qui c'è il registro di audit di ogni scadenza di sessione."

ISO 27001 Annex A.9.2 — Provisioning di Accesso: ISO 27001 A.9.2.2 richiede un processo formale di provisioning di accesso, e A.9.2.3 richiede che i diritti di accesso privilegiato siano allocati su base need-to-use. "Need-to-use" è il linguaggio ISO 27001 per least privilege, e si mappa direttamente a JIT: l'accesso dovrebbe esistere quando è necessario e non esistere quando non è necessario. A.9.2.5 richiede una revisione periodica dei diritti di accesso dell'utente — con l'accesso JIT, la revisione è continua piuttosto che periodica, perché l'accesso viene concesso di nuovo da zero per ogni sessione.

L'argomento di conformità per JIT è diretto: i privilegi permanenti sono strutturalmente non conformi al principio di least privilege che NIS2, SOC 2 CC6.3 e ISO 27001 A.9.2 richiedono tutti. JIT è il modello di implementazione che rende il least privilege operazionalmente praticabile su larga scala.

Come VaultPAM Implementa l'Accesso JIT

VaultPAM implementa l'accesso JIT attraverso quattro meccanismi integrati:

Flussi di approvazione: Quando un utente richiede accesso privilegiato a un sistema target, VaultPAM instrada la richiesta all'approvatore appropriato — responsabile, team di sicurezza, o entrambi, a seconda del livello di accesso e della sensibilità del sistema. Le approvazioni possono essere completate tramite l'interfaccia web di VaultPAM o canali di notifica integrati. La richiesta include il sistema target, la durata richiesta e la giustificazione, fornendo all'approvatore il contesto per prendere una decisione informata.

Sessioni limitate nel tempo: Ogni concessione di accesso approvato include un'ora di scadenza fissa. La finestra della sessione è impostata al momento dell'approvazione — 1 ora, 4 ore, 8 ore, o una durata personalizzata fino al massimo della policy. Quando la finestra della sessione scade, VaultPAM revoca automaticamente l'accesso. Non c'è alcun passaggio manuale, nessun email di promemoria, nessuna dipendenza dall'utente che si disconnette. L'accesso semplicemente cessa di esistere.

Auto-scadenza e rotazione di credenziali: Per le sessioni RDP e SSH, VaultPAM fornisce una credenziale specifica della sessione all'inizio della finestra approvata e la ruota alla scadenza. La credenziale che esisteva per la sessione approvata non funziona più dopo la scadenza. Un attaccante che cattura la credenziale durante la sessione non può riutilizzarla dopo la chiusura della finestra.

Traccia di audit: Ogni richiesta JIT — invio, approvazione o rifiuto, inizio della sessione, durata della sessione, registrazione della sessione e scadenza — è registrata nel registro di audit immutabile di VaultPAM. La traccia di audit include l'identità dell'approvatore, il timestamp dell'approvazione, il testo della giustificazione e una registrazione completa dell'attività della sessione. Questo è il pacchetto di prove che soddisfa le richieste di audit NIS2, il campionamento dell'auditor SOC 2 e le revisioni spot-check ISO 27001.

Vedi l'accesso JIT di VaultPAM in azione — elimina i privilegi permanenti nel tuo ambiente