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 di gestione, 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 policy di gestione.
Poiché è possibile allegare più politiche di controllo del servizio (SCPs) a diversi livelli in AWS Organizations, comprendere come SCPs vengono valutate può aiutarti a scrivere SCPs il risultato giusto.
Come SCPs lavorare con 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 SCPs, AWS Organizations allega una policy SCP AWS gestita denominata Full AWSAccess
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 deny-by-default modello, il che significa che tutte le autorizzazioni non esplicitamente consentite in vengono negate SCPs . Se un'istruzione allow non è presente in SCPs a nessuno dei livelli come Root, Production OU 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 SCPs lavorare con 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 politica di negazione applicata a qualsiasi livello dell'organizzazione viene valutata per tutti gli account OUs e i membri sottostanti.
Figura 3: Esempio di struttura organizzativa con una istruzione Deny collegata all'unità organizzativa di produzione e relativo impatto sull'account B
Strategia di utilizzo SCPs
Durante la stesura, SCPs è possibile utilizzare una combinazione di Allow Deny dichiarazioni per consentire le azioni e i servizi previsti all'interno dell'organizzazione. Denyle dichiarazioni sono uno strumento efficace per implementare restrizioni che dovrebbero valere per una parte più ampia dell'organizzazione o OUs perché, quando vengono applicate alla radice o a livello di unità organizzativa, influiscono su tutti gli account che ne fanno parte.
Ad esempio, è possibile implementare una politica utilizzando Deny le istruzioni a L'account di gestione può anche impedire agli account membri di lasciare l'organizzazione. livello di root, che sarà efficace per tutti gli account dell'organizzazione. Le istruzioni deny supportano anche l'elemento condition che può essere utile per creare eccezioni.
Suggerimento
Puoi utilizzare i dati dell'ultimo accesso al servizio in IAM per aggiornare i tuoi SCPs dati 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 Allega un SCP AWS gestito denominato Full AWSAccessAllow in modo da consentire solo i servizi specifici.
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 AWSAccess politica Full e allegare invece questa.
Per dimostrare come è possibile applicare più politiche di controllo del servizio (SCPs) in un' AWS organizzazione, considera la struttura e gli scenari organizzativi seguenti.
Scenario 1: Impatto delle politiche Deny
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», il risultato è che l'Account B non può EC2 accedere a S3 (dalla modalità di negazione a livello di unità organizzativa) e (dalla politica di negazione a livello di account). EC2 L'account A non dispone dell'accesso a S3 (dalla negazione a livello di OU).
Scenario 2: le politiche di autorizzazione devono esistere a tutti i livelli
Questo scenario mostra come funzionano le politiche di autorizzazione SCPs. 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 dispone di una politica di «Consenti EC2 accesso», che consente solo esplicitamente l'accesso al EC2 servizio, gli account A e B avranno accesso solo. 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 EC2 accesso» e l'unità organizzativa di produzione ha «Accesso completo». AWS Di conseguenza, l'Account D ha accesso a tutti i servizi tranne gli Account EC2 E e F che hanno accesso a tutti i servizi.
Scenario 5: consentire l'adozione di politiche a livello di unità organizzativa per limitare l'accesso al servizio
Questo scenario mostra come è possibile utilizzare le politiche di autorizzazione per limitare l'accesso a servizi specifici. L'OU di test prevede una politica di «Consenti EC2 accesso», il che significa che solo EC2 i servizi 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 a livello di unità organizzativa mantenendo al contempo un'autorizzazione più ampia a livello di root.
Scenario 6: la negazione a livello di root 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.
