SEC03-BP05 Definisci barriere di autorizzazione per la tua organizzazione - Pilastro della sicurezza

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à.

SEC03-BP05 Definisci barriere di autorizzazione per la tua organizzazione

Utilizza i guardrail delle autorizzazioni per ridurre l'ambito delle autorizzazioni disponibili concedibili ai principali. La catena di valutazione delle policy di autorizzazione comprende i guardrail così da determinare le autorizzazioni effettive di un principale quando adotta decisioni relative alle autorizzazioni.  È possibile definire i guardrail utilizzando un approccio basato sui livelli. Applica alcuni guardrail in modo esteso all'intera organizzazione e applicane altri in modo granulare alle sessioni di accesso temporaneo.

Risultato desiderato: hai un chiaro isolamento degli ambienti utilizzando Account AWS separati.  Le politiche di controllo del servizio (SCPs) vengono utilizzate per definire barriere di autorizzazione a livello di organizzazione. I guardrail più estesi sono impostati ai livelli gerarchici più vicini alla radice dell'organizzazione, mentre i guardrail più rigidi sono impostati più vicino al livello dei singoli account.  Se supportate, le policy sulle risorse definiscono le condizioni che un principale deve soddisfare per ottenere l'accesso a una risorsa. Le policy per le risorse, inoltre, definiscono l'insieme delle azioni consentite, laddove appropriato.  I limiti delle autorizzazioni sono posti sui principali che gestiscono le autorizzazioni del carico di lavoro, delegando la gestione delle autorizzazioni ai singoli proprietari del carico di lavoro.

Anti-pattern comuni:

  • Creazione di membri Account AWS all'interno di un'AWS organizzazione, ma non utilizzo SCPs per limitare l'uso e le autorizzazioni disponibili alle relative credenziali root.

  • Assegnare le autorizzazioni in base al privilegio minimo, senza però porre guardrail sull'insieme massimo di autorizzazioni concedibili.

  • Affidarsi alla base di negazione implicita AWS IAM per limitare le autorizzazioni, confidando che le politiche non concedano autorizzazioni di autorizzazione esplicite indesiderate.

  • Eseguiamo più ambienti di carico di lavoro nello stesso ambiente e poi Account AWS facciamo affidamento su meccanismi come tag o politiche delle risorse per far rispettare i limiti delle VPCs autorizzazioni.

Vantaggi derivanti dall'adozione di questa best practice: i guardrail di autorizzazione contribuiscono a creare la certezza che le autorizzazioni indesiderate non possano essere concesse, anche quando una policy di autorizzazione tenta di farlo.  Ciò può semplificare la definizione e la gestione delle autorizzazioni riducendo l'ambito massimo delle autorizzazioni da prendere in considerazione.

Livello di rischio associato se questa best practice non fosse adottata: medio

Guida all'implementazione

Ti consigliamo di utilizzare un approccio basato sui livelli per definire i guardrail di autorizzazione per la tua organizzazione. Questo approccio riduce in modo sistematico il set massimo di autorizzazioni possibili con l'applicazione di livelli aggiuntivi. Ciò consente di concedere l'accesso in base al principio del privilegio minimo, riducendo il rischio di accessi non intenzionali dovuti a un'errata configurazione delle policy.

Il primo passo per definire i guardrail delle autorizzazioni è isolare i carichi di lavoro e gli ambienti in Account AWS separati.  I responsabili di un account non possono accedere alle risorse di un altro account senza l'autorizzazione esplicita in tal senso, anche se entrambi gli account fanno parte della stessa AWS organizzazione o fanno parte della stessa unità organizzativa (OU).  Puoi utilizzarli OUs per raggruppare gli account che desideri amministrare come una singola unità.   

Il passaggio successivo consiste nel ridurre il set massimo di autorizzazioni che è possibile concedere ai principali all'interno degli account dei membri dell'organizzazione.  A tale scopo è possibile utilizzare le politiche di controllo del servizio (SCPs), che è possibile applicare a un'unità organizzativa o a un account.  SCPspuò applicare controlli di accesso comuni, ad esempio limitare l'accesso a determinati elementi Regioni AWS, impedire l'eliminazione di risorse o disabilitare azioni di servizio potenzialmente rischiose.   SCPsle informazioni applicate alla radice dell'organizzazione influiscono solo sugli account dei membri, non sull'account di gestione.  SCPsgestisci solo i dirigenti all'interno della tua organizzazione. SCPsNon siete i dirigenti esterni all'organizzazione che accedono alle vostre risorse.

Un ulteriore passo consiste nell'utilizzare le politiche in materia di IAM risorse per definire le azioni disponibili che è possibile intraprendere sulle risorse da essi governate, oltre alle condizioni che il responsabile ad interim deve soddisfare.  Ciò può essere tanto ampio quanto consentire tutte le azioni purché il responsabile faccia parte dell'organizzazione (utilizzando la chiave di PrincipalOrgId condizione), oppure granulare, consentire solo azioni specifiche per un ruolo specificoIAM.  È possibile adottare un approccio simile con le condizioni nelle politiche di fiducia dei IAM ruoli.  Se una politica di fiducia in materia di risorse o ruoli nomina esplicitamente un responsabile nello stesso account del ruolo o della risorsa da essa governata, tale responsabile non necessita di una IAM policy allegata che conceda le stesse autorizzazioni.  Se il responsabile si trova in un account diverso da quello della risorsa, allora ha bisogno di una IAM politica allegata che conceda tali autorizzazioni.

Spesso, un team addetto al carico di lavoro vorrà gestire le autorizzazioni richieste dal proprio carico di lavoro.  Ciò potrebbe richiedere la creazione di nuovi IAM ruoli e politiche di autorizzazione.  È possibile acquisire l'ambito massimo di autorizzazioni che il team può concedere in un limite di IAM autorizzazione e associare questo documento a un IAM ruolo che il team può quindi utilizzare per gestire i propri IAM ruoli e le proprie autorizzazioni.  Questo approccio può fornire loro la possibilità di completare il proprio lavoro riducendo al contempo i rischi legati all'accesso amministrativo. IAM

Un passaggio più granulare consiste nell'implementazione di tecniche di gestione degli accessi privilegiati (PAM) e di gestione temporanea degli accessi elevati (). TEAM  Un esempio PAM è quello di richiedere ai responsabili di eseguire l'autenticazione a più fattori prima di intraprendere azioni privilegiate.  Per ulteriori informazioni, vedere Configurazione MFA dell'accesso protetto. API TEAMrichiede una soluzione che gestisca l'approvazione e il periodo di tempo entro il quale un principale può avere un accesso elevato.  Un approccio consiste nell'aggiungere temporaneamente il responsabile alla politica di fiducia del ruolo per un IAM ruolo con accesso elevato.  Un altro approccio consiste nel ridurre, in condizioni normali, le autorizzazioni concesse a un responsabile da un IAM ruolo utilizzando una politica di sessione e quindi revocare temporaneamente questa restrizione durante la finestra temporale approvata. Per ulteriori informazioni sulle soluzioni convalidate da AWS e da alcuni partner selezionati, consulta Temporary elevated access.

Passaggi dell'implementazione

  1. Isola i carichi di lavoro e gli ambienti in Account AWS separati.

  2. SCPsUtilizzatelo per ridurre il set massimo di autorizzazioni che possono essere concesse ai responsabili all'interno degli account membri dell'organizzazione.

    1. Ti consigliamo di adottare un approccio di tipo allowlist nella stesura del documento, SCPs che neghi tutte le azioni tranne quelle consentite e le condizioni in base alle quali sono consentite. Inizia definendo le risorse che desideri controllare e imposta l'effetto su Deny. Utilizzate l' NotAction elemento per negare tutte le azioni tranne quelle specificate. Combinalo con una NotLike Condizione per definire quando sono consentite queste azioni, se applicabili, come StringNotLike e ArnNotLike.

    2. Consulta Service control policy examples.

  3. Utilizza le politiche relative alle IAM risorse per definire e specificare le condizioni per le azioni consentite sulle risorse.  Utilizza le condizioni nelle politiche di fiducia dei IAM ruoli per creare restrizioni all'assunzione dei ruoli.

  4. Assegna limiti di IAM autorizzazione ai IAM ruoli che i team addetti al carico di lavoro possono quindi utilizzare per gestire i ruoli e le autorizzazioni dei propri carichi di lavoroIAM.

  5. Valuta le TEAM soluzioni PAM in base alle tue esigenze.

Risorse

Documenti correlati:

Esempi correlati:

Strumenti correlati: