Risorse IAM - AWS Guida prescrittiva

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Risorse IAM

Influenza il futuro della AWS Security Reference Architecture (AWSSRA) rispondendo a un breve sondaggio.

Sebbene AWS Identity and Access Management (IAM) non sia un servizio incluso in un diagramma di architettura tradizionale, riguarda ogni aspetto dell'organizzazione AWS, degli account AWS e dei servizi AWS. Non puoi distribuire alcun servizio AWS senza prima creare entità IAM e concedere le autorizzazioni. Una spiegazione completa di IAM non rientra nell'ambito di questo documento, ma questa sezione fornisce importanti riepiloghi delle raccomandazioni sulle migliori pratiche e indicazioni su risorse aggiuntive.

 

Caso d'uso o policy

Effetto

Gestito da

Scopo

Riguarda

Influisce

Implementato in

Policy di controllo dei servizi (Service Control Policies, SCP)

Restrict

Team centrale, ad esempio il team di piattaforma o di sicurezza [1]

Guardrail, governance

Organizzazione, unità organizzativa, account

Tutti i responsabili dell'organizzazione, dell'unità organizzativa e degli account

Account di gestione dell'organizzazione [2]

Politiche di automazione degli account di base (i ruoli IAM utilizzati dalla piattaforma per gestire un account)

Concedi e limita

Team centrale, ad esempio team di piattaforma, sicurezza o IAM [1]

Autorizzazioni per ruoli (di base) di automazione diversi dal carico di lavoro [3]

Account singolo [4]

Principi utilizzati dall'automazione all'interno di un account membro

Account membri

Politiche umane di base (i ruoli IAM che concedono agli utenti le autorizzazioni per svolgere il proprio lavoro)

Concedi e limita

Team centrale, ad esempio team di piattaforma, sicurezza o IAM [1]

Autorizzazioni per ruoli umani [5]

Account singolo [4]

Responsabili federati [5] e utenti IAM [6]

Account membri

Limiti delle autorizzazioni (autorizzazioni massime che uno sviluppatore autorizzato può assegnare a un altro responsabile)

Restrict

Team centrale, ad esempio team di piattaforma, sicurezza o IAM [1]

Guardrails per i ruoli applicativi (devono essere applicati)

Account singolo [4]

Ruoli individuali per un'applicazione o un carico di lavoro in questo account [7]

Account membri

Politiche relative ai ruoli delle macchine per le applicazioni (ruolo associato all'infrastruttura implementata dagli sviluppatori)

Concedi e limita

Delegato agli sviluppatori [8]

Autorizzazione per l'applicazione o il carico di lavoro [9]

Account singolo

Un intestatario in questo conto

Account membri

Policy delle risorse

Concedi e limita

Delegato agli sviluppatori [8,10]

Autorizzazioni alle risorse

Account singolo

Un intestatario in un conto [11]

Account membri

  

Note dalla tabella:

  1. Le aziende dispongono di molti team centralizzati (ad esempio team che si occupano di piattaforme cloud, addetti alle operazioni di sicurezza o di gestione delle identità e degli accessi) che si dividono le responsabilità di questi controlli indipendenti e sottopongono a revisione paritaria le rispettive politiche. Gli esempi riportati nella tabella sono segnaposto. Dovrete determinare la separazione delle mansioni più efficace per la vostra azienda.

  2. Per utilizzare gli SCP, devi abilitare tutte le funzionalità all'interno di AWS Organizations.

  3. In genere sono necessari ruoli e policy di base comuni per consentire l'automazione, come le autorizzazioni per la pipeline, gli strumenti di distribuzione, gli strumenti di monitoraggio (ad esempio, le regole AWS Lambda e AWS Config) e altre autorizzazioni. Questa configurazione viene in genere fornita al momento del provisioning dell'account.

  4. Sebbene riguardino una risorsa (come un ruolo o una policy) in un singolo account, possono essere replicati o distribuiti su più account utilizzando AWS. CloudFormation StackSets

  5. Definisci un set base di ruoli umani e politiche di base da distribuire a tutti gli account dei membri da un team centrale (spesso durante il provisioning degli account). Gli esempi includono gli sviluppatori del team della piattaforma, del team IAM e dei team di controllo della sicurezza.

  6. Utilizza la federazione delle identità (anziché gli utenti IAM locali) quando possibile.

  7. I limiti delle autorizzazioni vengono utilizzati dagli amministratori delegati. Questa policy IAM definisce le autorizzazioni massime e sostituisce le altre politiche (incluse le “*:*” politiche che consentono tutte le azioni sulle risorse). I limiti delle autorizzazioni dovrebbero essere richiesti nelle politiche umane di base come condizione per creare ruoli (come i ruoli relativi alle prestazioni dei carichi di lavoro) e allegare politiche. Configurazioni aggiuntive come gli SCP impongono il collegamento del limite delle autorizzazioni.

  8. Ciò presuppone che siano stati implementati parapetti sufficienti (ad esempio, SCP e limiti di autorizzazione).

  9. Queste politiche opzionali potrebbero essere fornite durante il provisioning dell'account o come parte del processo di sviluppo delle applicazioni. L'autorizzazione a creare e allegare queste politiche sarà regolata dalle autorizzazioni dello sviluppatore dell'applicazione.

  10. Oltre alle autorizzazioni degli account locali, un team centralizzato (come il team della piattaforma cloud o il team delle operazioni di sicurezza) spesso gestisce alcune politiche basate sulle risorse per consentire l'accesso tra più account per gestire gli account (ad esempio, per fornire l'accesso ai bucket S3 per la registrazione).

  11. Una policy IAM basata sulle risorse può fare riferimento a qualsiasi principale di qualsiasi account per consentire o negare l'accesso alle sue risorse. Può anche fare riferimento a principi anonimi per consentire l'accesso pubblico.

 Garantire che le identità IAM dispongano solo delle autorizzazioni necessarie per una serie ben delineata di attività è fondamentale per ridurre il rischio di abuso doloso o involontario delle autorizzazioni. La definizione e il mantenimento di un modello di privilegio minimo richiedono un piano deliberato per aggiornare, valutare e mitigare continuamente i privilegi in eccesso. Ecco alcuni consigli aggiuntivi per questo piano:

  • Utilizza il modello di governance e la propensione al rischio consolidata della tua organizzazione per stabilire barriere e limiti di autorizzazione specifici.

  • Implementa il privilegio minimo attraverso un processo iterativo continuo. Non si tratta di un esercizio da eseguire una sola volta.

  • Usa gli SCP per ridurre i rischi attuabili. Questi sono pensati per essere ampi guardrail, non controlli strettamente mirati.

  • Utilizza i limiti delle autorizzazioni per delegare l'amministrazione di IAM in modo più sicuro.

    • Assicurati che gli amministratori delegati applichino la policy di confine IAM appropriata ai ruoli e agli utenti che creano.

  • Come defense-in-depth approccio (in combinazione con le politiche basate sull'identità), utilizza politiche IAM basate sulle risorse per negare un ampio accesso alle risorse.

  • Utilizza IAM access advisor, AWS CloudTrail, AWS IAM Access Analyzer e gli strumenti correlati per analizzare regolarmente l'utilizzo cronologico e le autorizzazioni concesse. Correggi immediatamente le ovvie sovraautorizzazioni.

  • Se applicabile, assegna azioni generali a risorse specifiche anziché utilizzare un asterisco come carattere jolly per indicare tutte le risorse.

  • Implementa un meccanismo per identificare, rivedere e approvare rapidamente le eccezioni alle policy IAM in base alle richieste.