AWS Organizations e le Service Control Policy

AWS Organizations è la base della governance multi-account: raggruppa gli account in una gerarchia di Organizational Unit (OU) sotto un management account (o payer account), con consolidated billing e policy applicate per ereditarietà. Il pattern enterprise tipico separa gli ambienti (Security, Infrastructure, Workloads Prod/Non-Prod, Sandbox) in OU distinte per applicare guardrail differenziati.

Le Service Control Policy sono guardrail che definiscono il perimetro massimo di permessi di un account: limitano, non concedono mai. Un’azione è consentita solo se la SCP la permette E una IAM policy la concede; le SCP filtrano ciò che l’IAM potrebbe autorizzare. Valgono per tutti i principal degli account membri, incluso il root user, ma non si applicano al management account: per questo si isolano i workload fuori da esso. Due strategie: deny list (si parte da FullAWSAccess e si aggiungono Deny mirati, es. bloccare region non approvate) o allow list (più restrittiva, elenca esplicitamente i servizi consentiti). Non sostituiscono le IAM policy né implementano da sole il least-privilege sui singoli utenti: sono un tetto, non un permesso.

Control Tower e le landing zone

AWS Control Tower automatizza il setup di una landing zone multi-account well-architected orchestrando Organizations, IAM Identity Center, Config, CloudTrail e S3. Crea OU predefinite, un Log Archive account e un Audit account, e applica guardrail: preventivi (implementati come SCP, bloccano azioni non conformi), detettivi (Config rules che segnalano deviazioni) e proattivi (CloudFormation hooks). Account Factory (basato su Service Catalog) standardizza il provisioning di nuovi account. Si sceglie Control Tower quando serve una baseline pronta e conforme; si gestisce Organizations “a mano” quando esistono già strutture custom o serve controllo fine sui guardrail.

Accesso federato con IAM Identity Center e condivisione con RAM

AWS IAM Identity Center centralizza l’accesso workforce a più account senza creare IAM user duplicati. I permission set sono modelli che diventano ruoli IAM negli account target; l’identity source può essere la directory interna, AD o un IdP esterno (Entra ID, Okta) via SAML 2.0 con provisioning SCIM. È la scelta corretta per accesso human federato e temporaneo; per l’accesso machine-to-machine cross-account restano i ruoli IAM con AssumeRole e trust policy.

AWS Resource Access Manager condivide risorse tra account della stessa Organization (o OU/account specifici) senza duplicarle. Le risorse condivisibili includono subnet (VPC sharing), Transit Gateway, Route 53 Resolver rules e altre. Con VPC sharing più account deployano in subnet condivise gestite centralmente, riducendo la proliferazione di VPC e di peering. RAM sostituisce la gestione manuale di resource-based policy per le risorse supportate.

Logging centralizzato con CloudTrail

Un organization trail di CloudTrail, creato nel management account (o da un delegated administrator), si applica automaticamente a tutti gli account membri, presenti e futuri, e consegna i log a un bucket S3 centralizzato nel Log Archive account. Gli account membri vedono i propri eventi ma non possono modificare o disabilitare il trail dell’organizzazione: questo garantisce un audit trail immutabile. Si abbinano log file integrity validation, cifratura KMS e, dove serve near-real-time, l’integrazione con CloudWatch Logs o EventBridge.

Trappole tipiche d’esame

  • Dare permessi a un utente tramite una SCP → soluzione: impossibile. Le SCP non concedono mai; definiscono solo il tetto. I permessi effettivi restano nelle IAM policy, che devono comunque autorizzare l’azione.
  • Bloccare azioni anche per il root e per il management account → soluzione: le SCP coprono il root degli account membri ma NON il management account. Sposta i workload sensibili in un account membro dedicato.
  • Baseline multi-account conforme e rapida vs controllo totale → soluzione: Control Tower per una landing zone pronta con guardrail gestiti; Organizations “puro” quando serve personalizzazione o esiste già una struttura custom.
  • Accesso federato dei dipendenti a più account → soluzione: IAM Identity Center con permission set e IdP esterno via SAML/SCIM, non IAM user per account né chiavi statiche.
  • Condividere una subnet o un Transit Gateway fra account → soluzione: AWS RAM (VPC sharing), non VPC peering né duplicazione delle risorse.
  • Audit trail centralizzato e a prova di manomissione → soluzione: organization trail di CloudTrail verso un bucket nel Log Archive account, che gli account membri non possono disattivare né alterare.