Ruoli tra account e policy delle risorse

Le architetture reali si estendono su molti account: un account di produzione, un account di logging e un account per i servizi condivisi. Spesso workload e persone devono raggiungere risorse tra questi confini.

Il metodo sicuro non consiste mai nel copiare le credenziali tra gli account. Si concede invece un accesso limitato usando ruoli tra account o policy basate sulle risorse.

Il modello più comune prevede un ruolo nell'account di destinazione che viene assunto da un principal nell'account di origine.

• La policy di attendibilità del ruolo indica l'account o il principal di origine.
• Il principal di origine chiama AssumeRole e riceve credenziali temporanee.
• Agisce quindi nell'account di destinazione entro i limiti delle autorizzazioni del ruolo.

Per assumere un ruolo tra account è necessario che entrambe le parti lo consentano:

• La policy di attendibilità del ruolo di destinazione consente l'accesso al principal di origine.
• La policy di identità del principal di origine consente sts:AssumeRole su quel ruolo.

Se manca una delle due, l'assunzione del ruolo non riesce. Questo doppio controllo è un punto frequente negli esami.

Alcuni servizi supportano policy basate sulle risorse associate direttamente alla risorsa, come una policy di bucket S3, una policy di chiave KMS o una policy di coda SQS.

Queste policy possono concedere l'accesso a un principal di un altro account senza che il principal debba assumere un ruolo. L'account esterno usa la propria identità e la policy della risorsa ne autorizza l'accesso.

Scelga il meccanismo in base al servizio:

• Per i servizi privi di policy delle risorse (EC2, la maggior parte delle API), usi un ruolo tra account.
• Per S3, KMS, SNS, SQS, Lambda e altri servizi, una policy della risorsa può concedere l'accesso diretto tra account.

Le policy delle risorse evitano un passaggio aggiuntivo con AssumeRole.

Quando concede l'accesso tra account a una terza parte (come un fornitore SaaS), aggiunga una condizione external ID alla policy di attendibilità.

Il fornitore deve trasmettere un valore segreto univoco quando assume il ruolo. Questo blocca il problema del confused deputy, in cui un aggressore induce il fornitore ad accedere all'account del cliente sbagliato.

I ruoli tra account devono concedere il minimo necessario, limitando l'accesso a risorse e azioni specifiche.

Un errore comune consiste nell'accordare un'attendibilità ampia a un intero account esterno insieme a permessi amministrativi. Limiti l'attendibilità a un ruolo o utente specifico e le autorizzazioni all'attività esatta.

Un modello frequente centralizza una funzione in un account che gli altri raggiungono tramite ruoli; ad esempio, un account di sicurezza assume ruoli di sola lettura in ogni account dei workload.

Ogni account dei workload ospita un ruolo con lo stesso nome, che considera attendibile l'account di sicurezza, così gli strumenti possono analizzare tutti gli account in modo uniforme.

AWS Resource Access Manager (RAM) condivide risorse specifiche, come sottoreti o Transit Gateway, tra gli account di un'organizzazione.

RAM serve a condividere la risorsa in sé, non a concedere autorizzazioni API per operare su di essa. Completa ruoli e policy delle risorse per la condivisione di rete e infrastruttura.

L'accesso tra account amplia la superficie di attendibilità, quindi deve essere sottoposto regolarmente a controllo.

• CloudTrail registra ogni chiamata AssumeRole e ogni chiamata API tra account.
• IAM Access Analyzer segnala le policy delle risorse che concedono l'accesso al di fuori dell'account.

Esamini questi dati per individuare tempestivamente condivisioni non intenzionali.

Per collegare gli account in modo sicuro: preferisca i ruoli per il calcolo e le API, le policy delle risorse per i servizi di archiviazione e messaggistica e applichi sempre il principio del privilegio minimo, usando un external ID per le terze parti.

Non condivida mai chiavi a lungo termine tra gli account.

Ragioni sull'accesso tra account.

Ha imparato a collegare gli account in modo sicuro.

• I ruoli tra account richiedono sia una policy di attendibilità sia una policy di identità nell'account di origine.
• Le policy basate sulle risorse concedono l'accesso diretto per servizi come S3 e KMS.
• Usi un external ID per le terze parti ed esegua controlli con Access Analyzer e CloudTrail.