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 politiche di backup, le politiche sui tag, le politiche sulle applicazioni di chat o le politiche di opt-out dei servizi di intelligenza artificiale. 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 https://console.aws.amazon.com/organizations/v2/home/policies/service-control-policy/p-FullAWSAccess
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 puoi utilizzare una combinazione di Deny dichiarazioni Allow e per consentire le azioni e i servizi previsti nella tua 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 riguardano tutti gli account OU-level che ne fanno parte.
Suggerimento
Puoi utilizzare i dati a cui hai effettuato l'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 collega un SCP AWS gestito denominato FullAWSAccess Allow in modo da consentire solo i servizi specifici. Puoi scegliere di sostituire FullAWSaccess al livello principale o a tutti i livelli. Se si allega una lista consentita specifica del servizio alla radice, questa si applica automaticamente a tutte le unità organizzative e gli account sottostanti, il che significa che una singola policy a livello di root determina l'effettiva lista dei servizi consentiti nell'intera organizzazione, come mostrato nello scenario 7. In alternativa, puoi rimuovere e sostituire FullAWSAccess in ogni unità organizzativa e account, consentendoti di implementare elenchi di autorizzazione di servizio più granulari che differiscono tra unità organizzative o singoli account.
Nota: affidarsi esclusivamente alle istruzioni allow e al modello implicito deny-by-default può portare ad accessi involontari, perché istruzioni Allow più ampie o sovrapposte possono sostituire 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ù politiche di controllo dei servizi (SCP) in un'organizzazione, considera la struttura e gli scenari organizzativi seguenti. AWS
Scenario 1: Impatto delle politiche di rifiuto
Questo scenario dimostra come le politiche di rifiuto ai livelli più alti dell'organizzazione influiscano su tutti gli account sottostanti. Quando l'unità organizzativa Sandbox ha entrambe le politiche « AWS Accesso completo» e «Nega accesso S3" e l'Account B ha una politica di «Nega accesso EC2", il risultato è che l'Account B non può accedere a S3 (dal rifiuto) e EC2 (dal OU-level rifiuto a livello di account). L'account A non dispone dell'accesso S3 (in caso di rifiuto). 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 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 accesso solo a EC2.
Scenario 3: Impatto della mancanza di un'istruzione Allow a livello principale
Quando l'istruzione principale contiene solo un'istruzione Deny senza un'istruzione Allow « AWS Accesso completo», tutti gli account dei membri non hanno accesso al servizio. Gli SCP richiedono un Allow esplicito a tutti i livelli del percorso. Un Deny-only SCP alla radice blocca quindi tutti i servizi a meno che non sia coperto da un Allow esplicito.
Scenario 4: dichiarazioni di negazione a più livelli e autorizzazioni risultanti
Questo scenario dimostra una struttura dell'unità organizzativa profonda a due livelli. Sia l'unità organizzativa principale che quella dei carichi di lavoro 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 tutti gli accessi ai servizi tranne EC2 e gli Account E e F hanno tutti gli accessi ai servizi.
Scenario 5: consenti alle policy di limitare l'accesso OU-level al servizio
Questo scenario mostra come utilizzare le politiche di autorizzazione per limitare l'accesso a servizi specifici. L'unità organizzativa di test ha una politica «Consenti l'accesso a 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 consenso più ampio 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 rifiuto a livello principale influisce su tutti gli account dell'organizzazione, indipendentemente dalle politiche di autorizzazione ai livelli inferiori. Il sistema root prevede sia politiche di « AWS Accesso completo» che di «Negare l'accesso a S3». Anche se l'unità organizzativa di test ha una politica «Consenti accesso S3", la negazione S3 a livello root ha la precedenza. L'account D non ha accesso al servizio perché l'unità organizzativa di test consente solo l'accesso a S3, ma S3 viene negato a livello di root. Gli account E ed F possono accedere ad altri servizi ad eccezione di S3 a causa del rifiuto esplicito a livello di root.
Scenario 7: politiche di autorizzazione personalizzate di livello root per limitare l'accesso OU-level
Questo scenario dimostra come funzionano gli SCP con elenchi di autorizzazioni con servizio esplicito quando 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 di queste unità organizzative possono accedere solo ai servizi esplicitamente consentiti dall'SCP a livello di root. La policy root più restrittiva ha la precedenza, limitando di fatto l'accesso solo a IAM, EC2, S3 e ai CloudWatch servizi, indipendentemente dalle autorizzazioni più ampie concesse ai livelli organizzativi inferiori.
