PAM 
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
Pubblicato il Settembre 01, 2026
Uno degli elementi più sfruttabili delle moderne superfici di attacco sono i privilegi permanenti: i diritti di accesso persistenti che permangono negli account molto tempo dopo che non sono più necessari. Con i privilegi permanenti, le credenziali statiche sono più facili da rubare e gli account con autorizzazioni eccessive offrono agli aggressori possibilità di accesso molto più ampie del dovuto. Il modello Zero Standing Privilege (ZSP), che prevede l’assenza di privilegi permanenti, risolve questi problemi concedendo l’accesso solo quando necessario e revocandolo non appena l’attività è completata, senza lasciare alcun accesso residuo. Tuttavia, attuare il modello ZSP non è così semplice come potrebbe sembrare, poiché eliminare gli accessi permanenti incide su quasi tutti i sistemi, le identità e i flussi di lavoro dell’organizzazione. Le sfide più comuni nell’attuazione del modello ZSP includono i sistemi legacy che non supportano l’accesso temporaneo, la protezione delle identità delle macchine, la resistenza organizzativa e la dimostrazione della conformità ai revisori.
Continua a leggere per scoprire le sfide più comuni legate all’assenza di privilegi permanenti, come affrontarle e in che modo Keeper® può aiutarti.
Le 6 sfide più comuni legate all’assenza di privilegi permanenti
Sebbene l’assenza di privilegi permanenti sia auspicabile per ogni organizzazione, non è sempre facile conseguirla. Ecco alcune delle sfide ZSP più comuni e come affrontare ciascuna di esse.
1. Sistemi legacy
Le infrastrutture e le applicazioni meno recenti sono state progettate per funzionare con credenziali persistenti per avere un accesso sempre disponibile. Questo è l’opposto di ciò che richiede il modello ZSP: spesso questi sistemi non supportano nativamente la concessione dell’accesso su richiesta e la sua revoca poco dopo, risultando tra i contesti in cui è più difficile applicare il modello. La soluzione è migrare per fasi anziché tutto in una volta, partendo prima dai sistemi a più alto rischio e inserendo un proxy di Gestione degli accessi privilegiati (PAM) davanti al sistema legacy. Il proxy controlla gli accessi, consentendo al sistema legacy di continuare a funzionare secondo le proprie modalità, mentre lo strumento PAM gestisce l’accesso temporaneo e registra tutte le attività.
2. Identità non umane (NHI)
I privilegi permanenti non sono solo un problema umano; si applicano anche alle identità non umane (NHI). Gli account di servizio e le automazioni spesso utilizzano credenziali a lunga durata, configurate una sola volta e poi dimenticate perché nessun essere umano le utilizza effettivamente, quindi nessuno le ruota né le revoca. Poiché queste identità dispongono spesso di accessi privilegiati e, negli ambienti cloud-native, superano numericamente gli utenti umani con un rapporto di circa 144:1, costituiscono una parte crescente e spesso trascurata delle superfici di attacco. Le organizzazioni devono gestire le NHI con lo stesso rigore adottato per le identità umane: devono sostituire le credenziali di lunga durata con credenziali di breve durata, emesse durante l’esecuzione e con scadenza automatica, così da non lasciare accessi permanenti che possano essere sottratti.
3. AI agentica
Oltre alle identità delle macchine, gli agenti AI introducono un ulteriore ostacolo nell’applicazione del modello ZSP. Sono effimeri, progettati per svolgere un’attività utilizzando le risorse a cui devono accedere durante l’esecuzione. Se le organizzazioni tentano di predisporre l’accesso in anticipo, finiscono per concedere autorizzazioni eccessive per ogni evenienza, e tale accesso si accumula ed esce dal perimetro stabilito. È necessario concedere agli agenti AI l’accesso solo durante l’esecuzione, limitare rigorosamente le autorizzazioni di ciascun token alla specifica attività o allo strumento utilizzato dall’agente e far scadere l’accesso non appena l’attività è completata.
4. Complessità di RBAC
Il controllo degli accessi basato sui ruoli (RBAC) costituisce una base naturale per il modello ZSP, ma definire su larga scala ruoli precisi per le singole attività è difficile. I ruoli cambiano man mano che le persone assumono nuove responsabilità, i permessi si accumulano nel tempo e, alla fine, i ruoli attentamente progettati non riflettono più l’accesso privilegiato di cui la tua organizzazione ha bisogno. La soluzione consiste nel mantenere i ruoli allineati alle esigenze effettive attraverso verifiche periodiche degli accessi e il rilevamento automatico delle autorizzazioni, per individuare gli accessi inutilizzati e orientarsi verso il controllo degli accessi basato sugli attributi (ABAC).
5. Resistenza e ostacoli alla produttività
Le persone tendono a considerare l’accesso permanente come qualcosa di loro proprietà, ed è per questo che chiedere loro di rinunciarvi genera resistenza e il timore che i flussi di lavoro di richiesta e approvazione rallentino i ritmi serrati dei vari team. Se non affrontata, questa opposizione blocca le implementazioni prima che prendano slancio. La soluzione si concentra sulla comunicazione, spiegando perché il cambiamento è importante e utilizzando esempi reali di violazioni causate da accessi permanenti per rendere il rischio tangibile anziché astratto.
6. Lacune nella verificabilità
È molto difficile dimostrare che il modello ZSP stia effettivamente funzionando senza avere visibilità in tempo reale su chi ha avuto accesso a cosa, quando e perché. Se le organizzazioni non riescono a dimostrare che l’accesso viene concesso e revocato correttamente, non possono soddisfare gli auditor né, francamente, fidarsi del modello stesso. Per affrontare questo problema, le organizzazioni devono disporre di raccolta centralizzata dei log, monitoraggio e registrazione delle sessioni e verifiche continue degli accessi che producano documentazione da consegnare direttamente ai revisori. La visibilità dimostrabile è ciò che trasforma lo ZSP da una policy su carta in qualcosa che puoi effettivamente verificare.
Come affrontare le sfide legate all’assenza di privilegi permanenti
Sebbene molte sfide legate allo ZSP siano reali, sono risolvibili con le soluzioni giuste. Ecco i passaggi per applicare il modello ZSP nella tua organizzazione:
- Individua e inventaria i privilegi permanenti e le NHI: inizia elencando tutti gli account con accesso permanente, includendo sia quelli degli utenti umani sia le identità delle macchine, come gli account di servizio e gli agenti AI.
- Stabilisci le priorità in base al livello di rischio: classifica gli elementi in base all’entità dei danni che una compromissione potrebbe causare, dando la precedenza a quelli a più alto rischio, come gli account amministrativi con privilegi, gli agenti AI e tutto ciò che riguarda i sistemi critici.
- Avvia un progetto pilota su un caso d’uso circoscritto e di alto valore: testa il modello su un’area importante ma gestibile prima di distribuirlo ovunque. In questo modo puoi dimostrare che funziona e risolvere i problemi in un ambiente controllato, evitando che un errore iniziale incida sull’intera organizzazione.
- Automatizza il processo di richiesta, approvazione e revoca: una volta confermato che il modello funziona, automatizza le operazioni manuali per mantenere il modello ZSP operativo su larga scala ed evitare che le revoche dimenticate reintroducano privilegi permanenti.
- Esegui audit continui e dimostra la conformità: continua a verificare che l’accesso venga concesso e revocato come previsto, conservando documentazione che ne dimostri il corretto funzionamento nel tempo ai revisori.
Supera le sfide legate all’assenza di privilegi permanenti con Keeper
Affrontare le attività nell’ordine giusto e automatizzare la gestione degli accessi rende il modello ZSP gestibile, anziché apparentemente proibitivo. Keeper Privileged Cloud applica il modello ZSP concedendo l’accesso con privilegi elevati solo quando è necessario e la relativa richiesta è stata approvata, per poi revocarlo automaticamente al termine dell’intervallo autorizzato. Keeper funziona con i tuoi provider di identità esistenti, tra cui AWS, Microsoft Entra ID, Google Cloud, Okta e Active Directory. Conserva inoltre un audit trail completo di chi ha richiesto l’accesso, chi lo ha approvato e quando è scaduto. La combinazione di elevazione automatica dei privilegi e piena visibilità affronta alcune delle sfide più complesse del modello ZSP, senza introdurre un ulteriore sistema non integrato da gestire.
Richiedi una demo di KeeperPAM per eliminare i privilegi permanenti nella tua organizzazione.
Domande frequenti
Perché è così difficile implementare il modello ZSP?
Il modello ZSP è difficile da implementare perché interessa quasi tutti i sistemi, le identità e i flussi di lavoro dell’organizzazione. I sistemi legacy prevedono per impostazione predefinita credenziali sempre attive, le NHI e gli agenti AI sono facili da trascurare, i ruoli cambiano nel tempo e i team spesso sono restii a rinunciare all’accesso permanente. Il modello è complesso se applicato in modo coerente su larga scala, motivo per cui un’implementazione graduale supportata dall’automazione funziona meglio rispetto al tentativo di cambiare tutto in un’unica soluzione.
È possibile applicare il modello ZSP ai sistemi legacy?
Il modello ZSP può essere applicato ai sistemi legacy, anche se questi non sempre sono in grado di attuarlo autonomamente. Le applicazioni più datate sono progettate per funzionare con credenziali persistenti, quindi non possono concedere nativamente l’accesso su richiesta e revocarlo immediatamente dopo. La soluzione alternativa consiste nel collocare un proxy PAM davanti al sistema per gestire l’accesso temporaneo, controllare chi vi accede e registrare ogni sessione. In questo modo, puoi applicare controlli secondo il modello ZSP anche a un sistema che non li supporta nativamente.
Cosa succede all’accesso di emergenza dopo aver rimosso i privilegi permanenti?
Rimuovere i privilegi permanenti non elimina la necessità di un accesso di emergenza; cambia solo il modo in cui lo gestisci. Invece di lasciare più account amministrativi sempre attivi distribuiti tra i sistemi, le organizzazioni concentrano l’accesso di emergenza in un account dedicato, indipendente dai servizi normalmente necessari per accedere. In questo modo, gli amministratori autorizzati possono comunque effettuare l’accesso in caso di interruzione del servizio o di configurazione errata. Un account di emergenza è un’eccezione deliberata e rigorosamente controllata al modello ZSP, non un modo per eluderlo. È quindi custodito nella cassaforte, protetto con MFA e una password complessa: il suo utilizzo genera avvisi e tutte le attività vengono registrate. In questo modo, l’accesso di emergenza rimane disponibile, mentre il privilegio permanente che comporta è limitato a un unico account attentamente monitorato.
