External ID e il confused deputy

Quando consente a una terza parte di assumere un ruolo nel Suo account, può verificarsi un rischio di sicurezza noto come problema del confused deputy. L'external ID è il controllo semplice ma fondamentale che lo impedisce. Questo modello ricorre nell'esame ogni volta che un fornitore SaaS necessita di accedere al Suo account AWS.

Un confused deputy è un'entità attendibile (il deputy) che viene indotta a utilizzare la propria autorità per conto di un aggressore. In AWS, un servizio di terze parti ha l'autorizzazione ad assumere ruoli in molti account dei clienti; se nulla collega la richiesta al rapporto legittimo con il cliente, un aggressore potrebbe indurlo ad assumere il Suo ruolo.

Immagini un servizio SaaS di monitoraggio che assume un ruolo in ogni account cliente. Il servizio SaaS utilizza un'unica identità AWS per tutti. Se un aggressore che è anche un cliente indovina l'ARN del Suo ruolo, potrebbe convincere il servizio SaaS ad assumere il Suo ruolo, poiché il servizio SaaS è il principal attendibile. Il solo ID dell'account non basta a impedirlo.

L'external ID è un valore univoco e segreto che il fornitore assegna al rapporto con Lei. Lo inserisce nella policy di attendibilità del ruolo come condizione e il fornitore deve fornire esattamente lo stesso valore quando chiama AssumeRole. Poiché l'aggressore non conosce il Suo external ID, non può indurre il fornitore ad assumere il Suo ruolo.

Questa policy di attendibilità richiede l'external ID corrispondente. AssumeRole ha esito positivo solo quando il fornitore passa il valore identico, impedendo l'attacco del confused deputy.

È fondamentale che sia il fornitore a generare e controllare l'external ID, non il cliente. In questo modo si impedisce ai clienti di accordarsi per riutilizzare lo stesso valore. Le linee guida AWS sono esplicite: in qualità di terza parte, deve assegnare a ogni cliente un external ID univoco e richiederlo a ogni assunzione.

L'external ID non deve essere segreto come una password; può comparire nelle istruzioni di configurazione. Il suo valore per la sicurezza deriva dal fatto di essere univoco per cliente e controllato dal fornitore, così un aggressore non può indurre il deputy a utilizzare il valore del cliente sbagliato. Lo consideri un token anti-impersonificazione, non una credenziale.

L'external ID controlla chi può assumere il ruolo, ma è comunque necessario definire che cosa il ruolo può fare mediante policy di autorizzazione restrittive. Anche un fornitore correttamente autorizzato deve ricevere solo le autorizzazioni minime necessarie. Combini external ID, un principal specifico e autorizzazioni con privilegi minimi per un accesso sicuro da parte di terze parti.

Il modello del confused deputy si applica anche ai servizi AWS che agiscono per Suo conto. L'attendibilità tra servizi utilizza spesso chiavi di condizione come aws:SourceArn e aws:SourceAccount nelle policy delle risorse, per garantire che il servizio chiamante agisca per la Sua risorsa: la stessa idea difensiva in una forma diversa.

Quando una domanda descrive una terza parte o un servizio SaaS che assume un ruolo tra account diversi, la risposta sicura prevede quasi sempre un external ID nella policy di attendibilità. Se lo scenario riguarda la comunicazione tra servizi, cerchi invece le condizioni aws:SourceArn/aws:SourceAccount. Riconoscere l'indizio conduce direttamente al controllo corretto.

Il problema del confused deputy consente a un aggressore di indurre una terza parte attendibile a utilizzare impropriamente il proprio accesso. L'external ID, univoco per cliente e controllato dal fornitore, lo impedisce richiedendo un valore corrispondente in AssumeRole. Per i servizi AWS, utilizzi aws:SourceArn e aws:SourceAccount. Abbini sempre questi controlli ad autorizzazioni con privilegi minimi.

Verifichi le Sue conoscenze sul concetto di confused deputy.

Il problema del confused deputy si verifica quando una terza parte attendibile viene indotta a utilizzare impropriamente il proprio accesso tra account. L'external ID, univoco per cliente e controllato dal fornitore, lo impedisce tramite una condizione nella policy di attendibilità basata su sts:ExternalId. Per l'attendibilità tra servizi AWS, utilizzi aws:SourceArn e aws:SourceAccount, sempre applicando il principio del privilegio minimo.