Puoi ridurre la tua superficie di attacco cloud eseguendo un audit di ogni autorizzazione persistente sulle tue piattaforme cloud e di identità, eliminando gli accessi non
Gli account con privilegi sono inviti permanenti per gli aggressori, con credenziali da rubare e autorizzazioni di cui abusare. Quando i diritti amministrativi sono costantemente attivi, che vengano utilizzati o meno, gli account con privilegi ampliano notevolmente la superficie di attacco. Il modello Zero Standing Privilege (ZSP) riduce questo rischio garantendo che nessun utente disponga di un accesso elevato permanente. I privilegi vengono invece richiesti per un’attività specifica, concessi per un periodo di tempo limitato, approvati tramite un flusso di lavoro definito e revocati automaticamente quando l’intervallo approvato scade. Il modello ZSP riflette un cambiamento più ampio nella sicurezza moderna, sostituendo l’accesso permanente con l’accesso temporaneo per ridurre ciò che un utente malintenzionato può sfruttare. Keeper aiuta ad applicare il modello ZSP concedendo l’accesso Just-in-Time (JIT) e revocandolo automaticamente alla scadenza della finestra temporale approvata, facendo passare gli utenti da zero privilegi esattamente all’accesso di cui hanno bisogno, per poi riportarli automaticamente a zero.
Continua a leggere per scoprire l’importanza del modello ZSP, come funziona in Keeper e dove Keeper lo applica nei vari ambienti.
Perché i privilegi permanenti sono un rischio per la sicurezza
Un account con privilegi che rimane attivo indefinitamente offre agli aggressori un bersaglio duraturo: le credenziali non scadono, l’accesso è costantemente disponibile e non c’è un momento prestabilito in cui tali diritti vengono revocati. Se gli aggressori rubano o compromettono uno di questi account, ereditano i privilegi permanenti nella loro interezza.
Il problema più grande è il raggio di esplosione, poiché un account compromesso con accesso permanente raramente si ferma al sistema a cui era destinato. Gli aggressori utilizzano i privilegi permanenti per spostarsi lateralmente all’interno degli ambienti, raggiungendo altri server, database e risorse cloud lungo il loro percorso. Quella che all’inizio può sembrare una singola credenziale compromessa può trasformarsi rapidamente in un punto d’appoggio su tutta l’infrastruttura, se l’utente dispone di un accesso permanente. Quando i privilegi sono permanenti, l’accesso non è legato a una richiesta, a un’attività o a un periodo di tempo specifici, e non rimane quindi alcuna traccia chiara del motivo per cui una persona abbia potuto accedere a un sistema in un determinato momento. Questa ambiguità rende molto più difficile indagare sugli incidenti di sicurezza legati ai privilegi permanenti e dimostrare la conformità.
Come funziona il modello zero standing privilege in Keeper
Keeper aiuta ad applicare il modello ZSP tramite Keeper Privileged Cloud, che estende il framework di accesso JIT di KeeperPAM ai tuoi provider di identità e alle applicazioni federate. Invece di assegnare diritti di amministratore permanenti, Keeper Privileged Cloud concede l’accesso con privilegi elevati solo quando viene richiesto, solo per un intervallo di tempo approvato e solo in base ai controlli del flusso di lavoro che definisci. Per impostazione predefinita, gli utenti non dispongono di alcun privilegio ed eseguono l’elevazione attraverso un processo controllato e verificabile, per poi tornare a zero quando l’attività è completata. Di seguito viene illustrato come funziona in pratica ZSP per Keeper.
Configura le politiche di accesso
In una voce PAM Cloud, gli amministratori definiscono le regole di accesso utilizzando le impostazioni JIT e Workflow. Ciò comprende se una richiesta necessita di approvazione, chi può approvarla, per quanto tempo rimane valido l’accesso una volta concesso e a quale ruolo viene elevato l’utente. Queste impostazioni aiutano a determinare esattamente il modo in cui l’accesso con privilegi viene richiesto, approvato e limitato nel tempo, garantendo che non avvenga alcuna elevazione oltre i limiti che imposti.

Condividi le voci con gli utenti autorizzati
Una volta definita una policy, la voce PAM Cloud viene condivisa con gli utenti che dovrebbero poter richiedere l’accesso. Poiché l’elevazione avviene tramite il tuo provider d’identità, ogni utente deve avere un account sia nel tuo provider d’identità sia nel tenant di Keeper. Grazie alla condivisione della voce, tali utenti possono richiedere un accesso con privilegi più elevati quando un’attività lo richiede, senza disporre nel frattempo di alcun privilegio permanente.
Esamina e approva le richieste
Quando un utente ha bisogno dell’accesso, può richiederlo direttamente dalla propria Cassaforte Keeper o dalla CLI di Keeper Commander. Gli approvatori designati ricevono notifiche in tempo reale da strumenti come Slack, Teams, Jira e ServiceNow e possono approvare o negare una richiesta da qualsiasi client Keeper, in modo che le richieste non rimangano in sospeso in attesa che qualcuno raggiunga la propria postazione. A seconda della policy, gli approvatori possono anche richiedere una giustificazione e un numero di ticket prima di concedere l’accesso, collegando ogni elevazione a un motivo documentato.

Concedi e revoca automaticamente l’accesso
Una volta approvata una richiesta, Keeper Gateway esegue l’elevazione sul provider di identità o sulla risorsa di destinazione, assegnando all’utente l’appartenenza al gruppo, il ruolo o l’autorizzazione configurati, in modo che possa ottenere l’accesso consentito dalla policy. Alla scadenza della durata approvata, Keeper Gateway revoca automaticamente tale accesso, rimuovendo l’appartenenza o l’assegnazione temporanea e riportando l’utente a ZSP. Inoltre, registra ogni elevazione che ha richiesto l’accesso, chi lo ha approvato e quando è iniziata e terminata, in modo che i team di sicurezza e conformità abbiano un resoconto chiaro, per ogni richiesta, di come l’accesso con privilegi è stato concesso e utilizzato.
Dove Keeper garantisce l’assenza di privilegi permanenti
Keeper non limita ZSP a un singolo sistema o tipo di account. Lo stesso framework JIT si applica ovunque sia presente un accesso privilegiato nel tuo ambiente, dai provider di identità con cui i tuoi utenti si autenticano alle risorse cloud, ai database e alle macchine dietro di essi.
Su tutti i tuoi provider d’identità
Keeper Privileged Cloud estende l’accesso JIT ai provider di identità esistenti, tra cui AWS IAM, Microsoft Entra ID, Google Cloud tramite Google Identity, Okta e Active Directory. Keeper concede e revoca i privilegi direttamente all’interno della tua infrastruttura esistente, quindi l’elevazione avviene dove i tuoi account sono già presenti, senza alcuna interruzione delle modalità di autenticazione degli utenti. Il provider di identità rimane la tua fonte di verità, mentre Keeper controlla semplicemente quando un utente viene inserito in un gruppo con privilegi e quando ne viene rimosso.
Tale portata non riguarda solo le piattaforme stesse, ma include anche le applicazioni che federano l’accesso e l’autorizzazione tramite questi provider di identità. Anche le applicazioni federate possono utilizzare Keeper per il controllo degli accessi, consentendo agli utenti di applicare lo stesso modello JIT alle app a valle a cui i team accedono quotidianamente.
Su cloud, database e macchine
Poiché ZSP non è solo un problema della console cloud, KeeperPAM applica lo stesso framework di elevazione dei privilegi anche al di fuori dei tuoi provider di identità. Utilizzando le voci PAM Cloud, PAM Database e PAM Machine, puoi estendere l’accesso a tempo limitato a risorse cloud, database e singole macchine, applicando lo stesso ciclo di vita all’infrastruttura alla base del tuo livello di identità.
Oltre all’elevazione, il Keeper Gateway ruota anche le credenziali privilegiate in modo che non rimangano bersagli statici e, per database e macchine, può effettuare il provisioning di account temporanei, inserendo le credenziali lato server affinché l’utente non debba mai gestirle. Tutto risiede all’interno dell’architettura zero-knowledge di Keeper, il che significa che le credenziali e i segreti rimangono crittografati end-to-end e non vengono mai esposti a Keeper o a chiunque altro. Insieme, la rotazione automatica e lo zero-knowledge garantiscono che persino le credenziali che abilitano l’accesso privilegiato non persistano come materiali che un aggressore potrebbe rubare e sfruttare.
Riduci al minimo la tua superficie di attacco con Keeper
L’assenza di privilegi permanenti funziona solo se viene applicata in modo coerente, ed è qui che Keeper Privileged Cloud eccelle. Con Keeper, i team addetti alla sicurezza dispongono di un modo verificabile per concedere l’accesso privilegiato su richiesta e revocarlo automaticamente, utilizzando i provider di identità e l’infrastruttura già in uso. Gli amministratori ottengono un controllo dimostrabile su chi può accedere a cosa e quando; gli utenti ottengono l’accesso di cui hanno bisogno senza attendere il provisioning manuale o mantenere diritti di cui non hanno bisogno.
Richiedi una demo di KeeperPAM per vedere l’accesso JIT e la revoca automatica nel tuo ambiente.
Domande frequenti
In che modo il modello ZSP si differenzia dal principio del privilegio minimo?
Il principio del privilegio minimo limita gli utenti ai soli permessi richiesti dal loro ruolo, ma tali permessi sono generalmente permanenti, quindi restano attivi sia che vengano utilizzati sia che non lo siano. Il modello Zero Standing Privilege fa un ulteriore passo avanti: non esiste un livello di accesso predefinito; i privilegi vengono concessi solo se richiesti e approvati, per poi essere revocati al termine dell’attività. In parole semplici, il principio del privilegio minimo limita la quantità di accessi a disposizione di un utente, mentre il modello ZSP ne riduce la durata, idealmente azzerandola fino a quando non diventa necessario. Leggi il nostro blog per saperne di più sul confronto tra Zero Standing Privilege e principio del privilegio minimo.
Quali provider di identità supporta Keeper?
Keeper Privileged Cloud applica l’accesso JIT su AWS IAM, Microsoft Entra ID, Google Cloud tramite Google Identity, Okta e Active Directory. Le applicazioni che consentono l’accesso e l’autorizzazione in modo federato tramite queste piattaforme possono utilizzare Keeper anche per il controllo degli accessi, in modo che lo stesso modello JIT si estenda alle altre app collegate ai tuoi provider di identità.
Come accedono gli utenti alle risorse dopo l'approvazione?
Una volta approvata una richiesta di accesso, gli utenti possono accedere alla risorsa tramite Remote Browser Isolation di Keeper per eseguire una sessione sicura basata su browser o continuare a utilizzare i propri flussi di lavoro esistenti, come il portale di accesso AWS o la CLI di AWS. In entrambi i casi, l’accesso dura solo per il tempo autorizzato e viene revocato automaticamente dopo la finestra temporale approvata.