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à.
SCPvalutazione
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 dei chatbot 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 abilitiSCPs, AWS Organizations allega una SCP policy AWS gestita denominata F ullAWSAccess
Ad esempio, esaminiamo lo scenario illustrato nelle figure 1 e 2. Affinché un'autorizzazione o un servizio siano consentiti sull'Account B, è necessario allegare un'SCPautorizzazione o un servizio a Root, all'unità organizzativa di produzione e all'Account B stesso.
SCPla valutazione segue un deny-by-default modello, il che significa che tutte le autorizzazioni non esplicitamente consentite in SCPs vengono negate. Se un'istruzione allow non è presente in SCPs a nessuno dei livelli come Root, Production OU o Account B, l'accesso viene negato.
Note
-
Un'
Allow
istruzione in an SCP consente all'Resource
elemento di avere solo una"*"
voce. -
Un'
Allow
istruzione in un non SCP può avere affatto unCondition
elemento.
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 utente SCP dalla radice a ciascuna unità organizzativa che conduce direttamente all'account (incluso l'account di destinazione stesso) può negare tale autorizzazione.
Ad esempio, supponiamo che all'unità organizzativa di produzione sia SCP allegata un'Deny
istruzione esplicita specificata per un determinato servizio. Ne esiste anche un'altra SCP allegata a Root 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, poiché 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. Deny
le 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 L'account di gestione può anche impedire agli account membri di lasciare l'organizzazione. a livello principale, 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
È possibile utilizzare i dati dell'ultimo accesso IAMal servizio per SCPs aggiornare i dati in modo da limitare l'accesso solo a Servizi AWS quelli necessari. Per ulteriori informazioni, vedere Viewing Organizations Service Last Access Data for Organizations nella Guida per l'IAMutente.
AWS Organizations Allega una F AWS Allow
in modo da consentire solo i servizi specifici.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:*", "cloudwatch:*", "organizations:*" ], "Resource": "*" } ] }
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 ullAWSAccess politica F e allegare invece questa.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:*", "cloudwatch:*", "organizations:*" ], "Resource": "*" }, { "Effect": "Deny", "Action":"organizations:LeaveOrganization", "Resource": "*" } ] }
Consideriamo ora la seguente struttura organizzativa di esempio per capire come applicarne di più SCPs a diversi livelli in un'organizzazione.
La seguente tabella mostra le policy efficaci nell'unità organizzativa dell'ambiente di sperimentazione (sandbox).
Scenario | SCPa Root | SCPin Sandbox OU | SCPpresso l'account A | Policy risultante sull'account A | Policy risultante sull'account B e sull'account C |
---|---|---|---|---|---|
1 | AWS Accesso completo | AWS Accesso completo + nega l'accesso a S3 | AWS Accesso completo + negazione dell'accesso EC2 | Nessun S3, nessun accesso EC2 | Nessun accesso a S3 |
2 | Accesso completo AWS | Consenti EC2 l'accesso | Consenti EC2 l'accesso | Consenti EC2 l'accesso | Consenti EC2 l'accesso |
3 | Nega l'accesso a S3 | Consenti l'accesso a S3 | AWS Accesso completo | Nessun accesso al servizio | Nessun accesso al servizio |
La seguente tabella mostra le policy efficaci nell'unità organizzativa dei carichi di lavoro.
Scenario | SCPa Root | SCPpresso Workloads OU | SCPpresso Test OU | Policy risultante sull'account D | Policy risultanti a livello di unità organizzativa di produzione, account E e account F |
---|---|---|---|---|---|
1 | AWS Accesso completo | AWS Accesso completo | AWS Accesso completo + negazione EC2 dell'accesso | Nessun accesso EC2 | AWS Accesso completo |
2 | AWS Accesso completo | AWS Accesso completo | Consenti EC2 l'accesso | Consenti EC2 l'accesso | AWS Accesso completo |
3 | Nega l'accesso a S3 | AWS Accesso completo | Consenti l'accesso a S3 | Nessun accesso al servizio | Nessun accesso al servizio |