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 un modo 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. È possibile scegliere di sostituire Full AWSAccess al livello principale o a tutti i livelli. Se si collega alla radice una lista di autorizzazioni SCP specifica del servizio, questa si applica automaticamente a tutti gli OUs account sottostanti, il che significa che una singola politica a livello di root determina l'elenco di servizi consentito effettivo nell'intera organizzazione, come illustrato nello scenario 7. In alternativa, è possibile rimuovere e sostituire Full AWSAccess in ogni unità organizzativa e account, in modo da implementare liste di servizio più granulari che differiscono tra le unità organizzative o i singoli account.
Nota: affidarsi esclusivamente alle istruzioni allow e al deny-by-default modello implicito 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 Full e allegare invece questa. AWSAccess
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.
Scenario 7: policy di autorizzazione personalizzate a livello root per limitare l'accesso a livello di unità organizzativa
Questo scenario dimostra come, SCPs con un servizio esplicito, gli elenchi di autorizzazione funzionino se applicati a livello root all'interno di un. AWS Organizations A livello principale dell'organizzazione, SCPs sono allegati due «Service Allow» personalizzati che consentono esplicitamente l'accesso a un set limitato di AWS servizi: SCP_1 consente IAM e Amazon, SCP_2 consente Amazon EC2 S3 e Amazon. CloudWatch A livello di unità organizzativa (OU), la policy completa predefinita rimane allegata. AWSAccess Tuttavia, a causa del comportamento di intersezione, gli account A e B corrispondenti OUs 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, S3 e ai CloudWatch servizi EC2, indipendentemente dalle autorizzazioni più ampie concesse a livelli organizzativi inferiori.
