Identità e accessi: perché l’IAM è il vero perimetro

Quando il lavoro esce dagli uffici, le applicazioni vivono nel cloud e i dispositivi appartengono a chiunque, la vecchia idea di perimetro — un dentro fidato e un fuori ostile — perde senso. Ciò che resta a fare da confine è l’identità: chi è, cosa può fare e in quali condizioni. L’IAM non è un componente della sicurezza tra gli altri; è il punto in cui la maggior parte degli attacchi passa o si ferma.

Gli attaccanti lo hanno capito da tempo. Sempre più intrusioni non “bucano” nulla: usano credenziali valide, ottenute con phishing, riuso di password o furto di token. In un mondo così, la robustezza dell’identità è la robustezza della difesa.

MFA, ma quella giusta

L’autenticazione a più fattori resta il singolo controllo con il miglior rapporto tra costo e riduzione del rischio. Ma non tutti i fattori sono uguali: i codici via SMS e le semplici notifiche push si possono aggirare con SIM swap, phishing in tempo reale o affaticamento da approvazioni. Dove è possibile, l’obiettivo sono metodi resistenti al phishing — chiavi hardware o passkey basate su standard come FIDO2 — legati al dominio del servizio, così una pagina falsa non può riutilizzare l’autenticazione.

Altrettanto importante è la copertura: l’MFA vale finché non ci sono scorciatoie. Un vecchio protocollo che non lo supporta, un’eccezione “provvisoria”, un percorso di recupero debole bastano ad annullarlo.

Privilegi: quanti ne servono davvero

La maggior parte delle utenze ha più permessi di quanti ne usino davvero. Il divario tra privilegio concesso e privilegio necessario è esattamente ciò che un attaccante sfrutta dopo il primo accesso. Ridurre quel divario — minimo privilegio applicato con costanza — limita quanto lontano può arrivare una credenziale compromessa.

Per gli accessi amministrativi il salto di qualità è il privilegio just-in-time: niente diritti elevati permanenti, ma elevazione richiesta e concessa per l’attività, con approvazione e registrazione, e poi ritirata. Meno privilegi permanenti esistono, meno bersagli di valore restano in giro.

Il ciclo di vita: dall’ingresso all’uscita

Gli accessi vanno gestiti come un ciclo, non concessi e dimenticati. All’ingresso, diritti coerenti con il ruolo. Al cambio di ruolo, la revoca di ciò che non serve più — è qui che nasce l’accumulo di permessi, quando si aggiunge senza mai togliere. All’uscita, la disattivazione tempestiva di ogni accesso, umano e non.

Il punto più fragile è quasi sempre l’offboarding: account di ex collaboratori o fornitori che restano attivi per mesi sono una porta aperta senza custode. Un ciclo di vita governato, con revisioni periodiche degli accessi (chi ha cosa, e serve ancora?), tiene i permessi allineati alla realtà anziché alla storia.

Gli account di servizio, l’angolo dimenticato

Le identità non umane — account di servizio, chiavi API, identità di applicazioni e automazioni — oggi spesso superano di gran lunga quelle umane, e ricevono molta meno attenzione. Non fanno MFA, hanno spesso privilegi ampi, credenziali statiche che nessuno ruota e nessun momento di “uscita” che ne provochi la disattivazione.

Vanno trattate con la stessa disciplina: un proprietario chiaro, il minimo privilegio, credenziali a vita breve o rotazione regolare, e un inventario che dica cosa esiste e perché. Un account di servizio sovra-privilegiato e dimenticato è tra i percorsi più silenziosi verso un danno esteso.

Centralizzare per controllare

Ogni applicazione con il proprio archivio di credenziali è una superficie da difendere e un punto cieco in più. Consolidare l’autenticazione su un unico provider di identità, con single sign-on e federazione, non è solo comodità per chi usa i sistemi: è controllo. Un solo posto dove imporre l’MFA, applicare le policy, disattivare un accesso e vedere cosa succede vale più di dieci configurazioni sparse che invecchiano ognuna a modo suo.

La centralizzazione riduce anche le password: meno credenziali separate significano meno cose da rubare, riusare o dimenticare attive. Il rovescio è che quel provider diventa un bersaglio di primo piano — motivo in più per proteggerlo con i controlli più forti che ha.

Rilevare gli attacchi all’identità

Se gli attacchi passano dalle credenziali, la difesa deve saper leggere i segnali dell’identità: accessi da luoghi o dispositivi anomali, viaggi impossibili, raffiche di tentativi falliti, approvazioni MFA ripetute che sanno di affaticamento indotto, la creazione improvvisa di nuove credenziali o regole. Non serve rilevare tutto; servono i pochi segnali che precedono quasi sempre un abuso.

Questi eventi vanno registrati, conservati e — dove possibile — collegati a una risposta: bloccare, richiedere una nuova verifica, avvisare. Un IAM senza rilevamento è una serratura di cui non sa mai se qualcuno ha provato la chiave.

In sintesi

Se l’identità è il perimetro, l’IAM è il muro portante. MFA resistente al phishing e senza scorciatoie, privilegi ridotti al necessario ed elevati solo quando serve, un ciclo di vita che revoca con la stessa cura con cui concede, account di servizio governati come le persone, e un rilevamento che legge i segnali dell’abuso: qui si vince o si perde gran parte della sicurezza moderna.