Quando la MFA non basta

La regola numero uno della sicurezza cloud è: "utilizzerai sempre la MFA". Perché? Perché quando si passa al cloud computing pubblico, in sostanza si prendono tutte le interfacce amministrative, le si consolida in un unico portale o in un'unica API e poi… le si mette su Internet protette da nome utente, password e (forse) MFA. Anche quando si utilizza una federazione.

Ma si scopre che nemmeno la MFA è sempre sufficiente, come dimostrano diverse violazioni di grande portata, tra cui quella avvenuta in Uber.

Questa è una delle differenze più importanti da comprendere tra il cloud e l'infrastruttura tradizionale, ed è il motivo per cui si continua a sentire l'espressione "l'identità è il nuovo perimetro". Prima del cloud gestivamo il nostro datacenter dall'interno di reti private (o attraverso punti di accesso controllati come VPN e jump box). Con il cloud tutto questo è su Internet per impostazione predefinita ed è difficile metterlo in sicurezza, soprattutto ora che supportiamo sempre più spesso dipendenti e amministratori da remoto.

La MFA è un modo efficace per proteggere l'autenticazione di utenti e amministratori. Abbiamo moltissime opzioni, che vanno da quelle un po' più sicure (MFA basata sulla messaggistica) a quelle davvero molto sicure (chiavi hardware). Ma il problema, anche con la MFA, è che gli utenti dispongono di un accesso persistente con privilegi persistenti. Se si assegna un ruolo a un utente, questi può utilizzare tali autorizzazioni in qualsiasi momento dopo l'autenticazione. Gli aggressori lo sanno e hanno sviluppato una serie di tecniche per ottenere un accesso autenticato. Essi:

• abusano delle credenziali statiche, soprattutto se non viene utilizzata la MFA.
• superano alcune forme di MFA. Ad esempio, ricorrono al SIM swap per intercettare i messaggi di testo diretti ai telefoni.
• manipolano gli amministratori con tecniche di social engineering per far disattivare la MFA o reimpostarla su un dispositivo sotto il loro controllo.
• manipolano gli utenti con tecniche di social engineering per carpire un codice MFA.
• sottraggono le credenziali di sessione dal sistema di un utente dopo che questi si è già autenticato, per poi utilizzarle da un sistema sotto il controllo dell'aggressore.

Una volta ottenuto l'accesso, l'aggressore inizia a esplorare i privilegi e prima o poi li utilizza per attività malevole.

Il privilegio minimo è una menzogna

Il problema di fondo è che assegniamo le autorizzazioni non in base a ciò che una persona deve fare in un dato momento, ma a ciò che potrebbe dover fare in futuro. Gli utenti, e soprattutto gli amministratori, dispongono dell'insieme massimo di autorizzazioni per tutte le azioni possibili. Ogni standard di sicurezza al mondo afferma che l'IAM dovrebbe basarsi sul default deny e sul privilegio minimo, ma è una sorta di menzogna, dato che l'insieme dei "privilegi minimi" è definito dall'insieme massimo dei privilegi di cui l'utente avrà bisogno prima o poi, non in ogni momento.

Anche quando consentiamo agli utenti di cambiare ruolo e di utilizzare autorizzazioni diverse per sessioni diverse, questi hanno comunque quasi sempre accesso a tali ruoli quando lo desiderano. In realtà il privilegio minimo dovrebbe essere vincolato al tempo, non solo all'utente. Storicamente gestiamo le autorizzazioni assegnando ruoli, e i ruoli hanno autorizzazioni entro un determinato ambito. "Sei amministratore su questi 5 account e utente normale sugli altri 98". Spesso assegniamo addirittura più ruoli a un utente, che combinano le autorizzazioni oppure permettono di passare da un ruolo all'altro a seconda delle attività svolte.

Si immagini quanto sarebbe più difficile per un aggressore se eliminassimo i privilegi persistenti. Invece di autenticarsi e disporre dell'accesso a tutte le proprie autorizzazioni, l'utente avrebbe accesso con un insieme molto ridotto di autorizzazioni e dovrebbe richiedere un'escalation per qualsiasi operazione potenzialmente dannosa.

Aumentare la sicurezza con le autorizzazioni dinamiche

Non sto proponendo di eliminare la MFA o altre misure di sicurezza a livello di autenticazione. Restano di importanza vitale, ma a volte non bastano. Ciò vale in particolare per la sicurezza cloud, a causa del maggiore grado di esposizione intrinseca a Internet. Ma il cloud presenta anche dei vantaggi, tra cui la federazione basata su sessione e le autorizzazioni granulari (fino alle singole chiamate API).

Invece di fornire agli utenti un accesso persistente a tutte le autorizzazioni di cui potrebbero avere bisogno, forniamo loro un accesso più limitato e saranno poi loro a richiedere l'accesso a privilegi elevati. Non è un concetto nuovo: è quello che i prodotti di privileged user management utilizzano da anni. Ma tali prodotti si sono spesso basati su tecniche macchinose, come le sessioni via proxy e la rotazione di password temporanee. Il cloud è intrinsecamente più flessibile, poiché i modelli IAM nativi sono per loro natura basati su sessione e i privilegi sono definiti in documenti di policy (tipicamente scritti in JSON).

È così che funzionano strumenti come il nostro FireMon Authorization Control. Oppure si dia un'occhiata a Netflix ConsoleMe per un esempio open source. Gli utenti richiedono l'accesso quando ne hanno bisogno e le piattaforme utilizzano quindi le policy per determinare cosa è necessario ai fini dell'approvazione. Quando tali condizioni sono soddisfatte, ad esempio l'autorizzazione di un responsabile o di un collega, l'utente viene autorizzato a utilizzare un ruolo per una sessione. Le piattaforme possono anche inserire condizioni come "consenti questa sessione solo dall'indirizzo IP che l'ha richiesta". Queste richieste sono in genere out-of-band e utilizzano canali laterali come ChatOps per le approvazioni, rendendo il processo volutamente rumoroso, soprattutto per gli accessi sensibili agli ambienti di produzione.

La sicurezza a livello di autorizzazione semplifica in realtà la vita a tutti, dagli sviluppatori e utenti agli amministratori della sicurezza. Non è necessario conoscere in anticipo l'insieme completo delle autorizzazioni potenziali. Sono invece gli utenti a chiedere ciò di cui hanno bisogno nel momento in cui ne hanno bisogno. Le policy determinano il percorso con meno attriti per fornire tale accesso senza compromettere la sicurezza. Strumenti come ChatOps fanno sì che uno sviluppatore possa richiedere l'accesso a un nuovo account e ottenere una risposta in pochi secondi, invece di dover inviare una richiesta a un sistema di ticketing che potrebbe richiedere giorni o settimane.

Aggiungendo sicurezza all'autorizzazione riduciamo l'impatto delle credenziali rubate e delle autenticazioni violate, riducendo al contempo attriti e oneri operativi.