SEC03-BP05 Definizione dei guardrail per le autorizzazioni dell'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 policy di controllo dei servizi (SCP) consentono di definire i guardrail delle autorizzazioni 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:
-
Creare membri di Account AWS all'interno di un'organizzazione AWS
, senza utilizzare SCP 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 rifiuto implicito di AWS IAM per limitare le autorizzazioni, confidando nel fatto che le policy non concedano un'autorizzazione esplicita indesiderata.
-
Eseguire più ambienti di carico di lavoro nello stesso Account AWS e affidarsi quindi a meccanismi come VPC, tag o policy sulle risorse per applicare i limiti delle 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 principali 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 organizzazione AWS o della stessa unità organizzativa. Puoi utilizzare le unità organizzative 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, puoi utilizzare le policy di controllo dei servizi, applicabili a un'unità organizzativa o a un account. Le policy di controllo dei servizi possono applicare controlli di accesso comuni, ad esempio limitare l'accesso a Regioni AWS specifiche, aiutare a prevenire l'eliminazione di risorse o disabilitare azioni di servizio potenzialmente rischiose. Le policy di controllo dei servizi applicate alla radice dell'organizzazione influiscono solo sugli account dei membri, non sull'account di gestione. Le policy di controllo dei servizi regolano solo i principali all'interno della tua organizzazione. Le tue policy di controllo dei servizi non regolano i principali esterni alla tua organizzazione che accedono alle tue risorse.
Un ulteriore passo consiste nell'utilizzare le policy delle risorse IAM per definire le azioni disponibili che puoi intraprendere sulle risorse da esse governate, oltre a tutte le condizioni che il principale che agisce deve soddisfare. Questo può essere un ambito ampio, come consentire tutte le azioni fintanto che il principale fa parte dell'organizzazione (utilizzando la chiave di condizione PrincipalOrgId), o granulare, come consentire solo azioni specifiche da parte di un ruolo IAM specifico. Puoi adottare un approccio simile con le condizioni nelle policy di attendibilità del ruolo IAM. Se una policy di attendibilità di una risorsa o di un ruolo nomina esplicitamente un principale nello stesso account del ruolo o della risorsa che governa, tale principale non ha bisogno di una policy IAM associata che conceda le stesse autorizzazioni. Se il principale si trova in un account diverso dalla risorsa, deve disporre di una policy IAM associata 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 al team di creare nuovi ruoli IAM e policy di autorizzazione. Puoi definire l'ambito massimo di autorizzazioni che il team può concedere in un limite delle autorizzazioni IAM e associare questo documento a un ruolo IAM, utilizzabile dal team per gestire autorizzazioni e ruoli IAM. Questo approccio può concedere la possibilità di completare il proprio lavoro mitigando al contempo i rischi di accesso amministrativo IAM.
Un passaggio più granulare consiste nell'implementazione delle tecniche di gestione degli accessi privilegiati (PAM) e di gestione temporanea degli accessi elevati (TEAM). Un esempio di gestione degli accessi privilegiati consiste nel richiedere ai principali di eseguire l'autenticazione a più fattori prima di intraprendere azioni privilegiate. Per ulteriori informazioni, consulta Configuring MFA-protected API access. La gestione temporanea degli accessi elevati richiede una soluzione che gestisca l'approvazione e i tempi in cui un principale può avere un accesso elevato. Un approccio consiste nell'aggiungere temporaneamente il principale alla policy di attendibilità dei ruoli per un ruolo IAM con accesso elevato. Un altro approccio consiste nel ridurre, in condizioni di funzionamento normale, le autorizzazioni concesse a un principale da un ruolo IAM mediante una policy di sessione, quindi revocare in modo temporaneo 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
-
Isola i carichi di lavoro e gli ambienti in Account AWS separati.
-
Usa le policy di controllo del servizio per ridurre il set massimo di autorizzazioni che possono essere concesse ai principali all'interno degli account membri della tua organizzazione.
-
Per scrivere le tue policy di controllo del servizio, ti consigliamo di adottare un approccio basato sulla lista consentita, che neghi tutte le azioni tranne quelle consentite e le condizioni alle quali sono consentite. Inizia definendo le risorse che desideri controllare e imposta l'effetto su Deny. Utilizza l'elemento NotAction per negare tutte le azioni tranne quelle specificate. Combinalo con una condizione NotLike per definire quando queste azioni sono consentite, se applicabile, come StringNotLike e ArnNotLike.
-
Consulta Service control policy examples.
-
-
Utilizza le policy relative alle risorse IAM per definire l'ambito e specificare le condizioni per le azioni consentite sulle risorse. Utilizza le condizioni nelle policy di fiducia dei ruoli IAM per creare restrizioni all'assunzione dei ruoli.
-
Assegna limiti delle autorizzazioni IAM ai ruoli IAM che i team del carico di lavoro possono quindi utilizzare per autorizzazioni e ruoli IAM del proprio carico di lavoro.
-
Valuta le soluzioni PAM e TEAM in base alle tue esigenze.
Risorse
Documenti correlati:
Esempi correlati:
Strumenti correlati:
