Implicazioni dell'AuthN/AuthZ Gap

È ormai risaputo che nel cloud "l'identità è il nuovo perimetro". È una bella formula, facile da inserire in una presentazione o in un articolo, ma trasformarla in indicazioni operative è un po' più complesso. Oggi desidero concentrarmi su un solo aspetto dell'IAM in cloud, che chiamo "AuthN/AuthZ Gap". Si tratta in realtà di un problema che si presenta ogni volta che si utilizza la federazione, ma nel cloud la posta in gioco è più alta, poiché il management plane del cloud è sempre esposto su internet.

Innanzitutto, una breve introduzione su AuthN e AuthZ:

• AuthN sta per autenticazione. L'atto di dimostrare di essere una determinata entità. Per noi comuni mortali si tratta in genere di nome utente, password ed eventualmente MFA.
• AuthZ sta per autorizzazione. L'atto di verificare se un'azione è consentita. Per il cloud IaaS questo corrisponde quasi sempre a una chiamata API, anche quando si utilizza la console/il portale web.

Autenticazione e autorizzazione sono attività diverse, con flussi diversi. Quando accediamo a un sito web ci autentichiamo e in genere questo crea una sessione. Non dobbiamo reinserire le credenziali a ogni clic: il browser si limita a inviare un token valido per un determinato periodo di tempo. Le autorizzazioni, invece, vengono in genere verificate ogni volta che proviamo a compiere un'azione, per accertare che disponiamo dei permessi corretti.

A ben vedere, una volta ottenuto quel token di sessione, esso non viene più verificato a meno che qualcosa nel codice non imponga un nuovo controllo. L'autenticazione è valida per l'intera sessione e quindi è possibile compiere qualsiasi azione rientri nell'ambito delle proprie autorizzazioni. A seconda della piattaforma/del sistema, quelle credenziali temporanee continueranno a funzionare anche se vengono revocate o se l'account viene eliminato del tutto. Questo è l'AuthN/AuthZ Gap.

Dedico molto tempo a questo argomento quando insegno Cloud Incident Response, perché ho constatato che persino i responder di sicurezza esperti non ne comprendono sempre le implicazioni. Si immagini il caso di credenziali cloud rubate: si revocano o si eliminano le credenziali, ma l'attaccante ha una sessione attiva aperta e può potenzialmente continuare a eseguire azioni autorizzate. Il che è… un problema.

Come si risolve

A seconda di come si utilizzano tali credenziali, l'opzione più semplice è di norma modificare l'autorizzazione. È sufficiente applicare una policy di deny all'entità (o rimuovere le azioni consentite), poiché viene valutata a ogni chiamata API effettuata dall'attaccante. Pur essendo l'opzione più semplice, non è sempre la migliore, perché può interrompere attività in esecuzione (le credenziali rubate non sono sempre legate soltanto a utenti). Altre opzioni, a seconda del supporto offerto dal proprio cloud provider, includono:

• Aggiungere condizioni per limitare l'IP di origine delle chiamate API.
• Negare tutte le sessioni create prima di una determinata data/ora.

È più probabile imbattersi in questo problema quando ci si federa verso un cloud provider che all'interno del provider stesso. Ho appena eseguito un test in AWS e ho perso l'accesso sulle sessioni aperte piuttosto rapidamente dopo aver eliminato un utente IAM. Tuttavia, lo stesso non vale necessariamente quando la federazione proviene da un identity provider esterno e, persino all'interno di AWS, alcuni servizi non verificano nuovamente le credenziali durante le sessioni attive (ad esempio, la mia sessione di Session Manager è rimasta attiva per circa 15 minuti e oltre dopo l'eliminazione del ruolo che consentiva l'accesso).

Non si tratta di una grande vulnerabilità sconosciuta, ma di un aspetto da tenere presente nello sviluppo dei propri controlli di sicurezza cloud e dei playbook di incident response. Tipi diversi di credenziali hanno durate diverse, sia tra i vari cloud provider sia all'interno dello stesso provider. Anche il proprio identity provider costituisce un fattore, così come il punto in cui si tenta di revocare le credenziali. Ad esempio, se si ha un utente in Active Directory che viene poi federato in AWS, e tale utente assume un ruolo in AWS e ottiene le credenziali di sessione per quel ruolo, è necessario revocare o limitare le credenziali del ruolo assunto anche se si limita l'utente in AD. AWS non avrà alcun modo di sapere che la sessione dell'utente proveniente da AD non è più valida fino al termine della sessione, quando procederà a rivalidare l'autenticazione.

Internamente siamo passati a utilizzare il nostro strumento Authorization Control, che supporta la creazione di sessioni con restrizioni tramite ChatOps senza introdurre attriti che potrebbero rallentare i nostri sviluppatori. Non è ancora disponibile in general release, ma se desidera provarlo durante l'early access può semplicemente scrivermi direttamente all'indirizzo rich.mogull@firemon.com.