Identity governance ibrida: come tenere sincronizzate le directory senza aprire varchi alla sicurezza

Nel momento in cui un'azienda decide di estendere la propria infrastruttura verso il cloud — parzialmente o integralmente — una delle prime sfide operative che si presenta non riguarda la rete, né lo storage, né i costi di compute. Riguarda le identità. Chi è autorizzato ad accedere a cosa, in quale ambiente, con quali privilegi e per quanto tempo: queste domande, apparentemente banali in un contesto puramente on-premise, diventano straordinariamente complesse quando i confini tra datacenter fisico e piattaforma cloud si fanno permeabili.

La sincronizzazione delle directory — Active Directory, LDAP, Azure AD, Okta, Google Workspace — è il terreno su cui si gioca buona parte della sicurezza delle identità nelle organizzazioni italiane che operano in modalità ibrida. Eppure, è anche uno degli ambiti in cui si commettono errori sistematici, spesso non visibili fino a quando non si verifica un incidente.

Il problema della sincronizzazione ritardata

Uno degli scenari più sottovalutati è quello della desincronizzazione temporanea tra directory. Immaginate un dipendente che lascia l'azienda: il suo account viene disabilitato nel sistema HR e nell'Active Directory locale, ma se la propagazione verso il provider cloud non avviene in tempo reale — o peggio, è schedulata ogni quattro ore — esiste una finestra in cui quell'utente conserva accesso attivo a servizi cloud critici.

Questa finestra può sembrare trascurabile, ma in termini di sicurezza rappresenta un'esposizione concreta. Le credenziali di un ex dipendente con accesso residuo a piattaforme SaaS aziendali, bucket di storage o ambienti di sviluppo cloud sono un rischio che nessun responsabile IT dovrebbe accettare come normale.

La soluzione non è semplicemente accorciare il ciclo di sincronizzazione, anche se questo aiuta. È ripensare l'architettura del provisioning e deprovisioning in modo che le modifiche critiche — disabilitazione account, revoca privilegi elevati, cambio di ruolo — vengano propagate in modo prioritario e verificato.

SSO mal configurato: l'illusione della semplicità

Il Single Sign-On è spesso presentato come la risposta definitiva alla complessità della gestione delle credenziali. Un'unica identità, un unico punto di autenticazione, accesso fluido a tutti i servizi. In teoria, è corretto. In pratica, un SSO mal configurato può diventare un vettore di attacco di prima categoria.

Tra i problemi più frequenti che si riscontrano nelle implementazioni aziendali italiane, spiccano alcuni pattern ricorrenti:

• Token con scadenza eccessivamente lunga: sessioni che rimangono valide per ore o giorni senza richiedere riautenticazione, esponendo l'organizzazione in caso di dispositivo compromesso.
• Mancata validazione del contesto: il sistema SSO concede accesso senza verificare la postura del dispositivo, la rete di provenienza o la geolocalizzazione della richiesta.
• Bypass dell'MFA su applicazioni legacy: applicazioni integrate tramite protocolli datati (SAML 1.1, autenticazione base) che vengono escluse dal flusso di autenticazione a più fattori.
• Federazione senza revisione periodica: trust stabiliti tra identity provider che non vengono mai rivalutati, anche quando le relazioni con fornitori o partner cambiano.

Ogni uno di questi punti rappresenta un potenziale varco. La semplicità percepita dall'utente finale non deve tradursi in superficialità architetturale sul versante tecnico.

Identity governance: oltre la semplice gestione degli accessi

La governance delle identità è un concetto più ampio rispetto alla sola gestione degli accessi (IAM). Non si tratta solo di sapere chi ha accesso a cosa, ma di capire perché quell'accesso esiste, se è ancora necessario e se è proporzionato al ruolo attuale dell'utente.

In ambienti ibridi, questa visione complessiva richiede strumenti capaci di aggregare informazioni provenienti da fonti eterogenee: la directory on-premise, i log del provider cloud, i sistemi HR, le piattaforme di ticketing. Senza questa aggregazione, i team IT si trovano a operare con visibilità parziale, incapaci di rilevare anomalie come utenti con privilegi accumulati nel tempo (il cosiddetto privilege creep) o account di servizio con permissioni mai riviste dalla loro creazione.

Un approccio maturo all'identity governance prevede:

1. Revisioni periodiche degli accessi (access review), preferibilmente automatizzate e coinvolgendo i responsabili di business come certificatori.
2. Modello di accesso a privilegio minimo (least privilege), applicato sistematicamente sia agli utenti umani che agli account di servizio.
3. Separazione dei compiti (segregation of duties), per evitare che un singolo utente accumuli permissioni incompatibili tra loro.
4. Audit trail centralizzato, con log immutabili che traccino ogni evento di accesso, modifica dei privilegi e operazione sensibile.

La sfida dell'esperienza utente

Uno degli argomenti più spesso sollevati quando si discute di rafforzare i controlli sulle identità è l'impatto sull'esperienza degli utenti finali. È una preoccupazione legittima: sistemi di autenticazione troppo invasivi generano resistenza, spingono i dipendenti verso workaround non autorizzati e riducono la produttività.

La risposta non è scegliere tra sicurezza e usabilità, ma progettare flussi di autenticazione adattivi. Un sistema di autenticazione contestuale è in grado di calibrare il livello di verifica richiesto in base al rischio associato alla specifica richiesta di accesso: un utente che si autentica dalla propria postazione aziendale, sulla rete interna, durante l'orario lavorativo, riceverà un'esperienza fluida. Lo stesso utente che tenta di accedere alle 2 di notte da un indirizzo IP estero vedrà attivati controlli aggiuntivi.

Questo approccio — spesso definito risk-based authentication — consente di mantenere un livello di sicurezza elevato senza penalizzare sistematicamente gli utenti che operano in condizioni normali.

Verso un modello unificato per ambienti ibridi

La direzione verso cui si stanno muovendo le organizzazioni più strutturate è quella di un piano di controllo delle identità unificato, capace di gestire in modo coerente utenti, dispositivi e applicazioni indipendentemente da dove risiedono — datacenter locale, cloud pubblico, SaaS di terze parti.

In questo scenario, il provider di identità (IdP) diventa un componente critico dell'infrastruttura, da trattare con la stessa attenzione riservata ai sistemi di rete o di storage. La sua disponibilità, la sua sicurezza e la sua capacità di integrarsi con l'ecosistema applicativo aziendale sono fattori che determinano la resilienza complessiva dell'organizzazione.

Per le aziende italiane che si trovano in una fase di transizione ibrida, il consiglio operativo è di non trattare la sincronizzazione delle directory come un problema tecnico di secondo piano da risolvere una volta sola. È un processo continuativo che richiede monitoraggio, revisione e adattamento costante.

La sicurezza delle identità non è uno stato che si raggiunge: è una pratica che si mantiene.