Risorse IAM - AWSGuida 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 future dellaAWS Security Reference Architecture (AWSSRA) partecipando a un breve sondaggio.

Sebbene AWS Identity and Access Management (IAM) non sia un servizio incluso in un diagramma di architettura tradizionale, tocca ogni aspetto dell'organizzazione AWS, degli account AWS e dei servizi AWS. Non puoi distribuire alcun servizio AWS senza prima creare i principi IAM e concedere le autorizzazioni. Una spiegazione completa dell'IAM esula dallo scopo di questo documento, ma questa sezione fornisce importanti riassunti delle raccomandazioni sulle migliori pratiche e indicazioni per risorse aggiuntive.

 

Caso d'uso o politica

Effetto

Gestito da

Scopo

Appartiene a

Influisce

Implementato in

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

Restrict

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

Guardrails, governance

Organizzazione, unità organizzativa, account

Tutti i principali in Organizzazione, Unità Operativa e Contabilità

Account di gestione dell'organizzazione [2]

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

Concedere e limitare

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

Autorizzazioni per ruoli di automazione (di base) diversi dai carichi di lavoro [3]

Conto 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)

Concedere e limitare

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

Autorizzazioni per ruoli umani [5]

Conto singolo [4]

Principi federati [5] e utenti IAM [6]

Account membri

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

Restrict

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

Guardrail per i ruoli delle candidature (devono essere applicati)

Conto singolo [4]

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

Account membri

Politiche relative al ruolo delle macchine per le applicazioni (ruolo assegnato all'infrastruttura distribuita dagli sviluppatori)

Concedere e limitare

Delegato agli sviluppatori [8]

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

Account singolo

Un preside in questo conto

Account membri

Policy delle risorse

Concedere e limitare

Delegato agli sviluppatori [8,10]

Autorizzazioni per le risorse

Account singolo

Un capitale in un conto [11]

Account membri

  

Note dalla tabella:

  1. Le aziende hanno molti team centralizzati (ad esempio piattaforme cloud, operazioni di sicurezza o team di gestione delle identità e degli accessi) che dividono le responsabilità di questi controlli indipendenti e revisionano reciprocamente le politiche. Gli esempi nella tabella sono segnaposti. Dovrai determinare la separazione dei compiti più efficace per la tua azienda.

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

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

  4. Sebbene si riferiscano a una risorsa (ad esempio un ruolo o una politica) in un singolo account, possono essere replicati o distribuiti su più account utilizzando AWS CloudFormation StackSets.

  5. Definisci una serie di regole e ruoli umani di base che vengono implementati in tutti gli account dei membri da un team centrale (spesso durante la fornitura degli account). Gli esempi includono gli sviluppatori del team della piattaforma, il team IAM e i team di controllo della sicurezza.

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

  7. I limiti delle autorizzazioni vengono utilizzati dagli amministratori delegati. Questa politica IAM definisce le autorizzazioni massime e sostituisce le altre politiche (comprese“*:*” 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 del carico di lavoro) e per allegare politiche. Configurazioni aggiuntive come gli SCP impongono il collegamento del limite delle autorizzazioni.

  8. Ciò presuppone che siano stati schierati sufficienti guardrail (ad esempio, SCP e limiti delle autorizzazioni).

  9. Queste politiche opzionali potrebbero essere fornite durante la fornitura dell'account o come parte del processo di sviluppo delle applicazioni. L'autorizzazione a creare e allegare queste politiche sarà regolata dalle autorizzazioni proprie 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 account e gestire gli account (ad esempio, per fornire l'accesso ai bucket S3 per la registrazione).

  11. Una politica IAM basata sulle risorse può fare riferimento a qualsiasi responsabile di qualsiasi account per consentire o negare l'accesso alle sue risorse. Può anche fare riferimento a principi anonimi per consentire l'accesso del 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. Stabilire e mantenere un modello con privilegi minimi richiede un piano deliberato per aggiornare, valutare e mitigare continuamente i privilegi in eccesso. Ecco alcuni consigli aggiuntivi per quel piano:

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

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

  • Usa gli SCP per ridurre i rischi attuabili. Si tratta di ampi guardrail, non di controlli strettamente mirati.

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

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

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

  • Usa IAM access advisor, AWS CloudTrail, AWS IAM Access Analyzer e i relativi strumenti per analizzare regolarmente l'utilizzo storico e le autorizzazioni concesse. Correggi immediatamente le ovvie autorizzazioni in eccesso.

  • Se applicabile, indirizza le azioni generali a risorse specifiche invece di utilizzare un asterisco come jolly per indicare tutte le risorse.

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