Federazione IAM

Nota

Se disponi già di un elenco utenti centrale per la gestione di utenti e gruppi, ti consigliamo di utilizzare IAM Identity Center come servizio principale di accesso alla forza lavoro. Se una delle considerazioni di progettazione discusse più avanti in questa sezione ti impedisce di utilizzare IAM Identity Center, utilizza la federazione IAM anziché creare utenti IAM separati all'interno di AWS.

La federazione IAM stabilisce un sistema di fiducia tra due parti allo scopo di autenticare gli utenti e condividere le informazioni necessarie per autorizzare il loro accesso alle risorse. Questo sistema richiede un provider di identità (IdP) connesso all'elenco utenti e un provider di servizi (SP) gestito in IAM. L'IdP è responsabile dell'autenticazione degli utenti e della fornitura dei dati contestuali di autorizzazione pertinenti a IAM, mentre IAM controlla l'accesso alle risorse negli account e negli ambienti AWS.

La federazione IAM supporta standard di uso comune come SAML 2.0 e OpenID Connect (OIDC). La federazione basata su SAML è supportata da molti IdPs e consente l'accesso single sign-on federato per consentire agli utenti di accedere alla Console di gestione AWS o chiamare un'API AWS senza dover creare utenti IAM. Puoi creare identità utente in AWS utilizzando IAM o connetterti al tuo IdP esistente (ad esempio, Microsoft Active Directory, Okta, Ping Identity o Microsoft Entra ID). In alternativa, puoi utilizzare un provider di identità IAM OIDC quando desideri stabilire un rapporto di fiducia tra un IdP compatibile con OIDC e il tuo account AWS.

Esistono due modelli di progettazione per la federazione IAM: federazione con più account o federazione con account singolo.

Federazione IAM con più account

In questo modello IAM multi-account, stabilisci una relazione SAML-trust separata tra l'IdP e tutti gli account AWS che devono essere integrati. Le autorizzazioni sono mappate e assegnate in base a ciascun account. Questo modello di progettazione offre un approccio distribuito alla gestione di ruoli e policy e offre la flessibilità necessaria per abilitare un IdP SAML o OIDC separato per ogni account e utilizzare attributi utente federati per il controllo degli accessi.

La federazione IAM con più account offre i seguenti vantaggi:

• Fornisce l'accesso centrale a tutti i tuoi account AWS e ti consente di gestire le autorizzazioni in modo distribuito per ogni account AWS.

• Raggiunge la scalabilità in una configurazione multi-account.

• Soddisfa i requisiti di conformità.

• Consente di gestire le identità da una posizione centrale.

Il design è particolarmente utile se desideri gestire le autorizzazioni in modo distribuito, separate da account AWS. È utile anche in scenari in cui non si dispone di autorizzazioni IAM ripetibili tra gli utenti di Active Directory nei loro account AWS. Ad esempio, supporta gli amministratori di rete che potrebbero fornire l'accesso alle risorse con lievi variazioni tra gli account.

I provider SAML devono essere creati separatamente in ogni account, quindi ogni account AWS richiede processi per gestire la creazione, l'aggiornamento e l'eliminazione dei ruoli IAM e delle relative autorizzazioni. Ciò significa che puoi definire autorizzazioni di ruolo IAM precise e distinte per gli account AWS con diversi livelli di sensibilità per la stessa funzione lavorativa.

Il diagramma seguente illustra il modello di federazione IAM multi-account.

Federazione IAM con account singolo (modello) hub-and-spoke

Nota

Utilizza questo modello di progettazione per gli scenari specifici descritti in questa sezione. Per la maggior parte degli scenari, l'approccio consigliato è la federazione basata su IAM Identity Center o la federazione IAM con più account. Per domande, contatta AWS Support.

Nel modello di federazione a account singolo, la relazione di trust SAML viene stabilita tra l'IdP e un singolo account AWS (l'account di identità). Le autorizzazioni vengono mappate e fornite tramite l'account di identità centralizzato. Questo modello di progettazione offre semplicità ed efficienza. Il provider di identità fornisce asserzioni SAML mappate a ruoli (e autorizzazioni) IAM specifici nell'account di identità. Gli utenti federati possono quindi presumere cross-account-roles di accedere ad altri account AWS dall'account di identità.

Il diagramma seguente illustra il modello di federazione IAM a account singolo.

Casi d'uso: 

• Aziende che dispongono di un solo account AWS, ma a volte devono creare account AWS di breve durata per sandbox o test isolati.

• Istituti scolastici che gestiscono i propri servizi di produzione in un account principale ma forniscono account temporanei per studenti basati su progetti. 

Nota

Questi casi d'uso richiedono una governance solida e processi di riciclaggio limitati nel tempo per garantire che i dati di produzione non vengano trasferiti negli account federati e per eliminare potenziali rischi per la sicurezza. Anche il processo di revisione è difficile in questi scenari.

Considerazioni di progettazione per la scelta tra la federazione IAM e l'IAM Identity Center

• IAM Identity Center supporta la connessione degli account a una sola directory alla volta. Se utilizzi più directory o desideri gestire le autorizzazioni in base agli attributi utente, prendi in considerazione l'utilizzo della federazione IAM come alternativa di progettazione. È necessario disporre di un IdP che supporti il protocollo SAML 2.0, ad esempio Microsoft Active Directory Federation Service (ADFS), Okta o Microsoft Entra ID. Puoi stabilire una fiducia bidirezionale scambiando i metadati IdP e SP e configurando le asserzioni SAML per mappare i ruoli IAM ai gruppi e agli utenti delle directory aziendali.

• Se utilizzi un provider di identità IAM OIDC per stabilire un rapporto di fiducia tra un IdP compatibile con OIDC e il tuo account AWS, prendi in considerazione l'utilizzo della federazione IAM. Quando utilizzi la console IAM per creare un provider di identità OIDC, la console tenta di recuperare l'impronta personale per te. Consigliamo di ottenere manualmente anche l'identificazione personale dell'IdP OIDC e di verificare che la console abbia recuperato la corretta identificazione personale. Per ulteriori informazioni, consulta Creare un provider di identità OIDC in IAM nella documentazione IAM.

• Utilizza la federazione IAM se gli utenti della directory aziendale non dispongono di autorizzazioni ripetibili per una funzione lavorativa. Ad esempio, diversi amministratori di rete o di database potrebbero aver bisogno di autorizzazioni di ruolo IAM personalizzate negli account AWS. Per raggiungere questo obiettivo in IAM Identity Center, puoi creare policy separate gestite dai clienti e fare riferimento a esse nei tuoi set di autorizzazioni. Per ulteriori informazioni, consulta il post del blog AWS Come usare le policy gestite dai clienti in AWS IAM Identity Center per casi d'uso avanzati.

• Se utilizzi un modello di autorizzazioni distribuito, in cui ogni account gestisce le proprie autorizzazioni, o un modello di autorizzazioni centralizzato tramite AWS, prendi in considerazione l'utilizzo della federazione CloudFormation StackSets IAM. Se utilizzi un modello ibrido che prevede autorizzazioni sia centralizzate che distribuite, prendi in considerazione l'utilizzo di IAM Identity Center. Per ulteriori informazioni, consulta Provider di identità e federazione nella documentazione IAM.

• Servizi e funzionalità come Amazon Q Developer Professional e AWS CLI versione 2 dispongono del supporto integrato per AWS Identity Center. Tuttavia, alcune di queste funzionalità non sono supportate dalla federazione IAM.

• IAM Access Analyzer attualmente non supporta l'analisi delle azioni degli utenti di IAM Identity Center.