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à.
Valutazione SCP
Nota
Le informazioni contenute in questa sezione non si applicano ai tipi di policy dichiarative, incluse le policy di backup, le policy di tag, le policy delle applicazioni di chat o le politiche di opt-out dei servizi AI. Per ulteriori informazioni, consulta Comprendere l'ereditarietà delle politiche dichiarative.
Poiché è possibile collegare più policy di controllo dei servizi (SCP) a diversi livelli in AWS Organizations, comprendere come vengono valutate le SCP può aiutarti a scrivere SCP che producano il risultato giusto.
Argomenti
Come funzionano le SCP con l'istruzione allow
Affinché sia concessa un'autorizzazione per un account specifico, deve esserci una istruzione Allow esplicita a ogni livello, dalla radice a ciascuna unità organizzativa nel percorso diretto verso l'account (incluso l'account di destinazione stesso). Ecco perché quando abiliti gli SCP, AWS Organizations allega una policy SCP AWS gestita denominata FullAWSAccess che consente tutti i servizi e le azioni.
Ad esempio, esaminiamo lo scenario illustrato nelle figure 1 e 2. Per consentire un'autorizzazione o un servizio sull'account B, una SCP che consente l'autorizzazione o il servizio deve essere collegata alla radice, all'unità organizzativa di produzione e all'account B stesso.
La valutazione SCP segue un modello deny-by-default, il che significa che tutte le autorizzazioni non esplicitamente consentite nelle SCP vengono negate. Se un'istruzione allow non è presente nelle SCP a nessuno dei livelli come radice, unità organizzativa di produzione o account B, l'accesso viene negato.
Figura 1: Esempio di struttura organizzativa con una istruzione Allow collegata alla radice, all'unità organizzativa di produzione e all'account B
Figura 2: Esempio di struttura organizzativa con una istruzione Allow mancante sull'unità organizzativa di produzione e relativo impatto sull'account B
Come funzionano le SCP con l'istruzione deny
Affinché un'autorizzazione venga negata per un account specifico, qualsiasi SCP dalla radice a ciascuna unità organizzativa nel percorso diretto verso l'account (incluso l'account di destinazione stesso) può negare tale autorizzazione.
Ad esempio, supponiamo che all'unità organizzativa di produzione sia associata una SCP con un'istruzione Deny esplicita specificata per un determinato servizio. È inoltre presente un'altra SCP collegata alla radice e all'account B che consente esplicitamente l'accesso a quello stesso servizio, come mostrato nella Figura 3. Di conseguenza, sia all'account A che all'account B verrà negato l'accesso al servizio, in quanto una policy di negazione applicata a qualsiasi livello dell'organizzazione viene valutata per tutte le unità organizzative e gli account dei membri sottostanti.
Figura 3: Esempio di struttura organizzativa con una istruzione Deny collegata all'unità organizzativa di produzione e relativo impatto sull'account B
Strategie per l'utilizzo delle SCP
Durante la stesura degli SCP, è possibile utilizzare una combinazione di Deny dichiarazioni per consentire le azioni Allow e i servizi previsti all'interno dell'organizzazione. Denyle dichiarazioni sono un modo efficace per implementare restrizioni che dovrebbero valere per una parte più ampia dell'organizzazione o delle unità organizzative, perché quando vengono applicate alla radice o OU-level influiscono su tutti gli account che ne fanno parte.
Suggerimento
Puoi utilizzare i dati dell'ultimo accesso al servizio in IAM per aggiornare i tuoi SCP e limitare l'accesso solo a quelli di Servizi AWS cui hai bisogno. Per ulteriori informazioni, consulta Visualizzazione degli ultimi dati di accesso al servizio per Organizations nella Guida per l'utente di IAM.
AWS Organizations AWS allega un SCP gestito denominato FullAWSAccess a ogni root, unità organizzativaAllow in modo da consentire solo i servizi specifici. Puoi scegliere di sostituire FullAWSAccess a livello root o a tutti i livelli. Se si collega alla radice una lista di autorizzazioni SCP specifica del servizio, questa si applica automaticamente a tutte le unità organizzative e agli account sottostanti, il che significa che una singola politica a livello di root determina l'elenco effettivo dei servizi consentiti nell'intera organizzazione, come illustrato nello scenario 7. In alternativa, puoi rimuovere e sostituire FullAWSAccess in ogni unità organizzativa e account, consentendoti di implementare elenchi di autorizzazione dei servizi più granulari che differiscono tra le unità organizzative o i singoli account.
Nota: affidarsi esclusivamente alle istruzioni allow e al modello implicito di negazione per impostazione predefinita può portare ad accessi non intenzionali, poiché le istruzioni Allow più ampie o sovrapposte possono prevalere su quelle più restrittive.
Questa policy, che combina le due istruzioni potrebbe essere simile al seguente esempio, impedisce agli account membri di lasciare l'organizzazione e consente l'uso dei servizi AWS desiderati. L'amministratore dell'organizzazione può scollegare la policy FullAWSAccess e collegare questa al suo posto.
Per dimostrare come è possibile applicare più policy di controllo dei servizi (SCP) in un'organizzazione, prendete in considerazione la struttura organizzativa e gli scenari seguenti. AWS
Scenario 1: Impatto delle politiche di negazione
Questo scenario dimostra come le politiche di negazione ai livelli più alti dell'organizzazione influiscano su tutti gli account sottostanti. Quando l'unità organizzativa Sandbox dispone sia di policy di « AWS Accesso completo» che di «Nega accesso a S3» e l'Account B dispone di una politica di «Nega accesso EC2», il risultato è che l'Account B non può accedere a S3 ( OU-level negando) ed EC2 (a livello di account). L'account A non dispone dell'accesso a S3 (derivante dalla negazione). OU-level
Scenario 2: le politiche di autorizzazione devono esistere a tutti i livelli
Questo scenario mostra come funzionano le policy di autorizzazione negli SCP. Affinché un servizio sia accessibile, deve esserci un'autorizzazione esplicita a tutti i livelli, dalla radice fino all'account. In questo caso, poiché l'unità organizzativa Sandbox ha una politica «Consenti l'accesso a EC2», che consente solo esplicitamente l'accesso al servizio EC2, gli account A e B avranno solo l'accesso a EC2.
Scenario 3: Impatto della mancanza di un'istruzione Allow a livello di root
La mancanza di un'istruzione «Consenti» a livello di root in un SCP è un grave errore di configurazione che bloccherà di fatto l'accesso ai AWS servizi e alle azioni per tutti gli account membri dell'organizzazione.
Scenario 4: istruzioni Layered Deny e autorizzazioni risultanti
Questo scenario dimostra una struttura dell'unità organizzativa profonda a due livelli. Sia l'unità organizzativa Root che quella Workloads hanno « AWS Accesso completo», l'unità organizzativa di test ha « AWS Accesso completo» con «Nega accesso EC2" e l'unità organizzativa di produzione ha «Accesso completo». AWS Di conseguenza, l'Account D ha accesso a tutti i servizi tranne EC2 e gli Account E e F hanno accesso a tutti i servizi.
Scenario 5: consentire alle policy di limitare l'accesso OU-level al servizio
Questo scenario mostra come è possibile utilizzare le policy di autorizzazione per limitare l'accesso a servizi specifici. L'OU di test ha una politica «Consenti accesso EC2», il che significa che solo i servizi EC2 sono consentiti per l'Account D. L'unità organizzativa di produzione mantiene l' « AWS accesso completo», quindi gli account E e F hanno accesso a tutti i servizi. Ciò dimostra come sia possibile implementare politiche di autorizzazione più restrittive mantenendo al OU-level contempo un'autorizzazione più ampia a livello di root.
Scenario 6: la Root-level negazione ha effetto su tutti gli account indipendentemente dalle autorizzazioni di livello inferiore
Questo scenario dimostra che una politica di negazione a livello principale influisce su tutti gli account dell'organizzazione, indipendentemente dalle politiche di autorizzazione ai livelli inferiori. La root ha politiche sia di « AWS Accesso completo» che di «Nega accesso a S3». Anche se la Test OU ha una politica «Consenti l'accesso a S3», la negazione di S3 a livello di root ha la precedenza. L'account D non ha accesso al servizio perché l'unità di test consente solo l'accesso a S3, ma S3 viene negato a livello di root. Gli account E e F possono accedere ad altri servizi ad eccezione di S3 a causa dell'esplicita negazione a livello di root.
Scenario 7: policy di autorizzazione personalizzate a livello principale per limitare l'accesso OU-level
Questo scenario dimostra come funzionano gli SCP con elenchi di autorizzazione dei servizi espliciti se applicati a livello root all'interno di un. AWS Organizations A livello principale dell'organizzazione, sono allegati due SCP personalizzati «Service Allow» che consentono esplicitamente l'accesso a un set limitato di AWS servizi: SCP_1 consente IAM e Amazon EC2, SCP_2 consente Amazon S3 e Amazon. CloudWatch A livello di unità organizzativa (OU), la policy FullAWSAccess predefinita rimane allegata. Tuttavia, a causa del comportamento di intersezione, gli account A e B in queste unità organizzative possono accedere solo ai servizi esplicitamente consentiti dall'SCP a livello di root. La root policy più restrittiva ha la precedenza, in quanto limita efficacemente l'accesso solo a IAM, EC2, S3 e ai CloudWatch servizi, indipendentemente dalle autorizzazioni più ampie concesse ai livelli organizzativi inferiori.
