Organizations, OU e strategia SCP

AWS Organizations consente di gestire centralmente molti account AWS come un'unica struttura. Al suo interno, le Service Control Policies (SCPs) impostano limiti massimi alle autorizzazioni e le Organizational Units (OUs) raggruppano gli account per applicare le policy. Progettare correttamente questa gerarchia è una competenza fondamentale per l'area di governance dell'esame SCS-C02.

Un'organizzazione ha in cima un management account (in precedenza chiamato master), un contenitore root e OUs che possono essere annidate per raggruppare gli account membri. Le policy associate a qualsiasi livello si propagano a tutto ciò che si trova al di sotto. Questa struttura ad albero consente di applicare controlli ampi o mirati con una sola associazione.

Una Organizational Unit (OU) raggruppa account con esigenze di governance comuni, ad esempio una OU "Production", una OU "Sandbox" e una OU "Security". Associando un SCP a una OU, questo viene applicato a ogni account al suo interno; gli account vengono quindi organizzati in base alle policy che devono ereditare.

Gli SCP vengono ereditati lungo la struttura ad albero: un account è soggetto agli SCP della root, delle OU padre e dell'account stesso, considerati insieme. Per consentire un'azione, questa deve essere autorizzata a ogni livello. Un deny in qualsiasi punto della catena la blocca. Questo effetto cumulativo è fondamentale per la progettazione degli SCP.

Esistono due strategie. Una deny-list parte da FullAWSAccess, attivo per impostazione predefinita, e aggiunge deny espliciti per le operazioni che non si vogliono mai consentire, come la disattivazione di CloudTrail. Una allow-list rimuove FullAWSAccess ed elenca esplicitamente solo i servizi consentiti, adottando una postura molto più rigorosa. La maggior parte delle organizzazioni inizia con una deny-list per mantenere maggiore flessibilità.

Questo SCP impedisce a chiunque di arrestare la registrazione di CloudTrail, una protezione comune applicata a livello di organizzazione affinché nessun account membro possa oscurare il registro di controllo.

Una regola fondamentale: gli SCP non concedono mai autorizzazioni; impostano solo il limite massimo. Un'azione deve essere consentita sia da uno SCP sia da una policy IAM nell'account. Uno SCP con allow-list rende semplicemente i servizi disponibili per essere concessi; deve comunque essere IAM a concederli.

Gli SCP non si applicano all'account di gestione e non influiscono sui ruoli collegati ai servizi. Inoltre, in alcuni casi non agiscono sulle concessioni delle policy basate sulle risorse provenienti dall'esterno dell'organizzazione. Conoscere queste eccezioni evita di scegliere risposte errate quando uno scenario presuppone che uno SCP blocchi qualcosa che non può bloccare.

Due SCP protettivi classici negano l'azione di lasciare l'organizzazione (organizations:LeaveOrganization) e impediscono agli account membro di disabilitare i servizi di sicurezza come GuardDuty, Security Hub, Config e CloudTrail. Applicati alla root, garantiscono che nessun account membro possa sottrarsi alla governance o rendere ciechi i sistemi di rilevamento dell'organizzazione: sono una baseline fortemente consigliata.

Un'architettura tipica prevede uno SCP di deny-list di base alla root (per proteggere CloudTrail, impedire di lasciare l'organizzazione e limitare le regioni), SCP più restrittivi sull'OU Production e SCP più permissivi sull'OU Sandbox. Raggruppare gli account nelle OU in base al profilo di rischio consente di regolare con precisione la governance, riducendo al minimo la proliferazione delle policy.

Organizations struttura gli account in OU sotto una root e un account di gestione. Gli SCP vengono ereditati lungo la gerarchia e un'azione deve essere consentita a ogni livello. Scelga una strategia di deny-list (flessibile) o di allow-list (rigida); ricordi che gli SCP pongono solo un limite, non concedono mai autorizzazioni e che non si applicano all'account di gestione né ai ruoli collegati ai servizi.

Verifichi la sua strategia SCP.

AWS Organizations raggruppa gli account in OU sotto una root e un account di gestione. Gli SCP vengono ereditati lungo la gerarchia e richiedono un allow a ogni livello; qualsiasi deny blocca l'azione. Utilizzi una strategia di deny-list (flessibile) o di allow-list (rigida). Gli SCP pongono solo un limite, non concedono mai autorizzazioni e non si applicano all'account di gestione né ai ruoli collegati ai servizi.