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

Poiché è possibile associare 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 che consente tutti i servizi e le azioni. Se questa politica viene rimossa e non sostituita a nessun livello dell'organizzazione, a tutti gli account OUs e a tutti gli account al di sotto di quel livello verrebbe impedito di intraprendere qualsiasi azione.

Ad esempio, esaminiamo lo scenario illustrato nelle figure 1 e 2. Per consentire un'autorizzazione o un servizio 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.

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'Denyistruzione 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 nell'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 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.

AWS Organizations Allega una F AWS gestita SCP denominata ullAWSAccess a ogni root, unità organizzativa e account al momento della creazione. Questa policy consente tutte le operazioni e i servizi. È possibile sostituire F ullAWSAccess con una politica che consenta solo un insieme di servizi, in modo che i nuovi non Servizi AWS siano consentiti a meno che non siano esplicitamente consentiti mediante l'aggiornamento. SCPs Ad esempio, se l'organizzazione desidera consentire nel proprio ambiente solo l'uso di un sottoinsieme di servizi, è possibile utilizzare un'istruzione 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).

La seguente tabella mostra le policy efficaci nell'unità organizzativa dei carichi di lavoro.