Nimbiora AWS Landing Zone - Appendice Tecnica

Appendice per responsabili tecnici

Nimbiora Landing Zone v1.0.0 - Ultimo aggiornamento: 15/05/2026 - Luigi Clemente -

Scopo

Questa appendice è il complemento tecnico alla panoramica, presente sul sito, sulla Nimbiora Landing Zone. È rivolta a CTO, responsabili piattaforma, cloud architect, responsabili sicurezza e ingegneri senior che vogliono capire le scelte architetturali, il modello di controllo, l’approccio operativo e i confini di implementazione della landing zone prima di adottarla in un ambiente AWS reale.

L’architettura descrive una fondazione AWS multi‑account costruita intorno ad AWS Organizations, Terraform e Terragrunt, con una chiara separazione tra account di management, network, security, operations e workload. È progettata per offrire un punto di partenza a basso attrito per ambienti sandbox e fasi iniziali di training e migrazione, mantenendo però un percorso diretto verso una landing zone di produzione più estesa basata sullo stesso modello strutturale.

Assunzioni

Questa appendice presuppone familiarità con i concetti core di AWS, come account, IAM, VPC, CloudTrail, AWS Config, logging centralizzato e infrastructure as code . Spiega come questi building block sono assemblati nel modello Nimbiora, perché alcuni controlli sono collocati in account dedicati e quali compromessi di maturità sono stati scelti nella versione 1.0.0.

Sintesi architetturale

La landing zone implementa una topologia di base a cinque account: Management, Network, Security, Operations e Sandbox. Questo modello utilizza gli account AWS come principale boundary di blast radius: sicurezza, billing, ownership amministrativa e rischio operativo sono separati prima di tutto a livello di account, non solo tramite tag, convenzioni di naming o policy IAM.

Questa topologia è intenzionalmente minimale ma scalabile. Fornisce sufficiente separazione per implementare governance e controlli di sicurezza centralizzati, evitando allo stesso tempo il sovraccarico di una piattaforma enterprise completa fin dal primo giorno.

Principi di progettazione

Multi‑account governance

Il design tratta i singoli account AWS come boundary principali per privilegi, costi, sperimentazione e responsabilità operative. Questo modello è più solido rispetto all’esecuzione di tutti i workload in un unico account, perché limita l’impatto di errori di configurazione, permessi eccessivi, cancellazioni accidentali e sforamenti di budget in un confine più ristretto.

Una conseguenza pratica è che le funzionalità di piattaforma condivise non sono ospitate negli account workload. Servizi di sicurezza, archivi log, punti di controllo di rete e strumenti operativi sono isolati in account dedicati, così gli amministratori dei workload non possono facilmente alterare i controlli fondamentali.

Proprietà di infrastructure as code

La landing zone è interamente codificata tramite moduli Terraform orchestrati con Terragrunt, e il codice è scritto da zero invece di essere assemblato da moduli “landing zone” di terze parti. Questa scelta privilegia trasparenza, verificabilità e ownership di lungo periodo rispetto a una composizione iniziale più rapida ma più opaca.

La separazione chiave è tra moduli condivisi riutilizzabili e moduli di baseline specifici per ruolo di account. I moduli condivisi incapsulano implementazioni comuni di servizi (VPC, GuardDuty, budget, ecc.), mentre i moduli di baseline li compongono in baseline di account per management, network, security, operations o workload.

Fondazione scalabile

La versione 1.0.0 è ottimizzata per scenari di sandbox, training e migrazione iniziale, non per la massima complessità enterprise da subito. Il punto centrale è che la stessa struttura di account, il flusso IaC e i pattern di controllo possono essere successivamente irrobustiti ed estesi, invece di dover essere sostituiti.

Multi‑region

La landing zone definisce una regione primaria, una regione di backup e il supporto per us-east-1 dove esistono dipendenze da servizi globali AWS. Il profilo predefinito è eu-west-1 come region primaria, eu-central-1 come regione di backup e us-east-1 per integrazioni con servizi globali.

Ruoli multi‑account in dettaglio

Management account

Il Management account è l’account root di AWS Organizations e rimane il boundary amministrativo a sensibilità più elevata dell’intera piattaforma. Possiede costrutti organizzativi come OU, SCP, creazione e cancellazione degli account, billing centralizzato e policy di backup, ma l’operatività quotidiana dei servizi di sicurezza è intenzionalmente delegata ad account specializzati.

Questa separazione è importante per due motivi. Riduce il numero di persone e flussi operativi che richiedono accesso all’account più sensibile dell’organizzazione. Evita inoltre di trasformare il management account in un hub operativo multiuso, che indebolirebbe la separazione dei compiti e aumenterebbe il blast radius di un’eventuale compromissione.

Network account

Il Network account centralizza i servizi di connettività e governance IP, ad esempio Client VPN, peering VPC o Transit Gateway, IPAM e Network Manager. In questo modello, l’account di rete diventa il piano di controllo per la connettività condivisa, invece di lasciare a ciascun team workload la responsabilità di progettare una topologia di rete propria.

Il design supporta un percorso evolutivo ibrido: le implementazioni più piccole possono iniziare con il peering VPC per contenere costo e complessità, per poi migrare a un modello hub‑and‑spoke basato su Transit Gateway man mano che aumentano numero di account, VPC e requisiti di routing.

Security account

Il Security account funge da punto di amministrazione delegata per Security Hub, GuardDuty, Inspector, Firewall Manager e Macie, e contemporaneamente da repository centrale per log di sicurezza come CloudTrail, AWS Config e VPC Flow Logs. Centralizzare sia i finding sia le evidenze in un account dedicato è una delle scelte architetturali più forti: preserva l’integrità delle evidenze e fornisce un unico punto di vista sulla postura di sicurezza.

Per un responsabile tecnico, l’implicazione principale è operativa: gli amministratori degli account workload non devono poter alterare l’archivio principale di audit a livello di organizzazione. Questa separazione è essenziale se la landing zone deve supportare flussi di forensic, audit interni o due diligence verso i clienti.

Operations account

L’Operations account ospita le funzionalità di gestione e osservabilità condivise, come Systems Manager, aggregazione delle metriche CloudWatch, Resource Explorer, backend Terraform centralizzati e amministrazione delegata di AWS Backup. Diventa la centrale operativa della piattaforma: non è dove girano i workload, ma è da dove vengono monitorati, inventariati e gestiti.

È anche il posto logico in cui ancorare automazioni di piattaforma, attività di manutenzione ricorrente e pattern di osservabilità cross‑account, evitando di sovraccaricare Management o Security con responsabilità operative quotidiane.

Sandbox account

Il Sandbox account è l’account workload iniziale, esplicitamente destinato a sperimentazione, training e testing non critico.

Modello di identità e accesso

Il design utilizza AWS Identity Center come piano di accesso delle persone ed evita esplicitamente IAM user di lunga durata per l’amministrazione quotidiana. Gli utenti ottengono credenziali temporanee tramite SSO e assumono ruoli per account definiti attraverso permission set, soluzione nettamente migliore rispetto alla distribuzione di access key statiche a ingegneri o fornitori.

I ruoli operativi includono Organization Admin, Operations, Security, Network, Developer, Finance e Audit. Questa tassonomia di ruoli è un buon punto di partenza perché mappa le responsabilità alle funzioni di piattaforma, anziché assegnare un ruolo admin generico ovunque.

La configurazione utilizza anche permission boundary per i ruoli developer, per ridurre il rischio di privilege escalation . Per un’evoluzione “production‑grade”, il modello dovrebbe essere esteso verso una governance dei permessi più completa, che combini permission set, permissions boundary dove opportuno e SCP a livello di OU o account, così sviluppatori, operatori e auditor ricevono solo il sottoinsieme di azioni necessario.

Baseline di sicurezza

La piattaforma è progettata per raggiungere oltre il 95% di allineamento rispetto a CIS AWS Foundations Benchmark v5, AWS Foundational Security Best Practices v1.0.0 e NIST SP 800‑53 Rev. 5, tramite una combinazione di servizi centralizzati e default per account.

Servizi di sicurezza

Il Security account gestisce centralmente GuardDuty, Inspector, Macie e Security Hub. In pratica questo sistema fornisce telemetria AWS nativa per rilevamento delle minacce, gestione delle vulnerabilità, discovery di dati sensibili e aggregazione della postura di conformità.

Configurazione ed evidenze di audit

AWS Config è abilitato in ogni account e regione; CloudTrail e gli altri log di audit sono mantenuti centralmente; log DNS e VPC Flow Logs vengono esportati verso storage centralizzato. Questa combinazione è significativa perché supporta sia il reporting di conformità sia l’analisi delle root cause : Config indica cosa è cambiato, CloudTrail indica chi ha agito, e i log di rete o DNS aiutano a spiegare come si è comportato il traffico o la risoluzione dei domini durante un evento.

Hardening di default per gli account

La baseline globale include cleanup delle VPC di default, cifratura EBS di default, S3 Public Access Block, hardening della password policy IAM, IAM Access Analyzer, postura VPC Block Public Access, contatti alternativi, budget di base e alias di account. Questi controlli sono richiesti dai benchmark di sicurezza e rimuovono molti dei default insicuri e dei blind spot operativi tipici di account AWS non governati.

Guardrail

È incluso un catalogo espandibile di guardrail obbligatori implementati come SCP. Dal punto di vista di un responsabile tecnico, questa è un’area importante da estendere nel tempo, perché gli SCP rappresentano il controllo preventivo più forte disponibile a livello di organizzazione per bloccare intere classi di azioni, indipendentemente da cosa consentono le policy IAM a livello di account.

Architettura di logging ed evidenze

La scelta di centralizzare i log critici per la sicurezza nel Security account, invece di conservarli negli account workload, è architettonicamente corretta. Migliora in modo sostanziale la resistenza alla manomissione, perché un amministratore di workload non dovrebbe essere in grado di cancellare, sovrascrivere o riconfigurare l’archivio principale di evidenze per il proprio account.

Le categorie di log includono CloudTrail, Config, log DNS, VPC Flow Logs, findings di GuardDuty e Macie, con controlli di retention e analytics tramite Athena su storage S3 centralizzato. Questo design supporta sia revisioni periodiche sia indagini ad hoc, ed è adatto a operazioni di sicurezza che necessitano di query a basso attrito senza dover costruire subito un SIEM separato.

Operations e osservabilità

La baseline operativa si appoggia ad AWS Systems Manager per inventario degli host, fondamenta di patching e prerequisiti per la gestione dei fleet. Include anche centralizzazione delle metriche CloudWatch, Resource Explorer per la discovery a livello di organizzazione, rilevamento delle anomalie di costo, budget mensili e scheduling per lo spegnimento automatico delle istanze EC2 non di produzione.

Questo profilo operativo è importante per una landing zone perché affronta presto i problemi di visibilità di primo ordine: cosa esiste, quali risorse sono in esecuzione, quali account spendono in modo inatteso e come sono ancorati i controlli di base su agent e patch. Evita anche l’anti‑pattern in cui l’osservabilità è considerata un problema dei singoli workload invece che una capability di piattaforma.

Modello di networking

La sezione networking descrive un approccio volutamente graduale. Il punto di partenza a bassa complessità è una connettività centralizzata basata su VPC peering, mentre il modello scalabile è il Transit Gateway con connettività condivisa, propagazione delle route e governance hub‑and‑spoke.

Sono inclusi IPAM centralizzato, condivisione cross‑account degli address pool con RAM, pattern di provisioning VPC, strategia di subnet pubbliche e private, configurazione NAT, VPC endpoint, supporto DNS, flow logging e ciclo di vita del Client VPN come codice. Per i responsabili tecnici, il messaggio chiave è che il networking viene trattato come un servizio condiviso governato, non come qualcosa che ogni account improvvisa in autonomia.

Backup e ripristino

La responsabilità del backup è delegata all’Operations account e realizzata tramite policy a livello di organizzazione basate su tag, con classi come critical cross‑region, critical same‑region, standard e archive. Questo pattern è solido perché disaccoppia l’intento di backup dalla configurazione manuale su singole risorse e rende l’assegnazione delle policy coerente tra gli account.

Il design implementa anche copie centrali su vault, Vault Lock, copie regionali e controlli di retention. Questa combinazione è particolarmente rilevante per la resilienza al ransomware e per workload regolamentati, perché aiuta a garantire che le copie di backup non solo vengano create, ma siano anche protette da cancellazioni o manomissioni accidentali e malevole.

Modello di deployment e struttura del repository

L’implementazione si basa sul modello di configurazione a cascata di Terragrunt per ridurre la duplicazione tra account e region, mantenendo gli identificativi specifici del cliente e i feature toggle in un piccolo set di file HCL. Il repository è organizzato intorno a codice riutilizzabile, configurazione globale a livello di account e cartelle regionali.

Terraform e Terragrunt vengono eseguiti dentro container Docker con versioni degli strumenti fissate, caching dei plugin, backend di stato su S3 e locking su DynamoDB. Questa scelta ingegneristica riduce il drift tra workstation e rende più deterministici gli ambienti di esecuzione, sia per gli ingegneri sia per i job CI.

Perché Terragrunt è importante

Per i responsabili tecnici che valutano la manutenibilità, Terragrunt svolge tre funzioni principali: ereditarietà gerarchica della configurazione, orchestrazione di pattern di modulo ripetuti su molti account e region, e riduzione del “copia e incolla”. Il beneficio reale non è solo avere meno duplicazione, ma ridurre il rischio di divergenze silenziose tra baseline che dovrebbero rimanere identiche tra account e regioni.

Modello di automazione

Le automazioni di supporto includono script di orchestrazione multi‑account, generazione di profili AWS SSO, refresh delle credenziali SSO e rilevamento del drift dell’infrastruttura. Questi script sono importanti, perché impattano direttamente l’usabilità futura della piattaforma: senza di essi, una landing zone ben progettata può diventare rapidamente scomoda da gestire quando include un numero elevato di account.

Gli script possono opzionalmente essere eseguiti all’interno di un container Docker, migliorando la portabilità su ambienti Windows e Mac.

Punti di forza dell’attuale design

L’architettura presenta diversi punti di forza per una landing zone v1.0.0 pensata per supportare l’adozione in sandbox e un successivo hardening verso la produzione:

• Chiara separazione delle responsabilità sui cinque account, invece di collassare tutto in un unico boundary amministrativo.
• Forte enfasi su servizi di sicurezza centralizzati e storage centralizzato delle evidenze.
• Buona adozione iniziale di servizi detective e di postura nativi AWS, come Security Hub, GuardDuty, Inspector, Macie e AWS Config.
• Baseline operativa che include Systems Manager, Resource Explorer, controlli di costo e metriche centralizzate.
• Percorso credibile da sandbox a maturità di produzione senza dover abbandonare struttura del repository e modello di account.
• Piena ownership sull’ infrastructure as code , con verificabilità e riproducibilità integrate nel modello di piattaforma.

Funzionalità

Architettura Terraform/Terragrunt

L’intera landing zone è codificata in moduli Terraform, orchestrati con Terragrunt per ottenere un’esecuzione DRY e coerente. La landing zone separa due ambiti:

• Moduli condivisi – configurazioni riutilizzabili di servizi AWS (GuardDuty, VPC, Budget, ecc.) consumate da molti account
• Moduli di baseline – composizioni specifiche per tipo di account che collegano i moduli condivisi per un determinato ruolo di account (management, security, operations, network)

Tutti i valori specifici del cliente (ID account, ARN, feature toggle, ID delle OU) sono concentrati in un piccolo set di file di configurazione HCL.

Terraform dockerizzato

Tutti i comandi Terraform/Terragrunt vengono eseguiti all’interno di container Docker per garantire coerenza e riproducibilità. I container sono creati con:

• Versioni esatte degli strumenti (Terraform, Terragrunt, TFLint)
• Credenziali AWS e chiavi SSH montate nel container
• Caching dei plugin Terraform (per esempio AWS provider) per velocizzare le esecuzioni ripetute
• Impone la coerenza di versioni all’interno del team
• File di stato per modulo su S3 (ogni modulo ha il proprio state isolato)
• Locking su DynamoDB per prevenire modifiche concorrenti

Gerarchia delle cartelle

L’infrastruttura utilizza un modello di configurazione a cascata che elimina la duplicazione di codice. Ogni livello include impostazioni condivise per i livelli sottostanti.

• La cartella modules contiene il codice Terraform condiviso riutilizzato da più account.
• Ogni account ha una cartella global che include tutte le risorse e le impostazioni che devono essere create una sola volta, o che non sono regionali in AWS.
• Le cartelle regionali includono le risorse con scope regionale.

Questa architettura gestisce infrastrutture AWS multi‑account complesse mantenendo semplicità ed evitando errori comuni, come deployare negli account sbagliati o applicare tagging in modo incoerente.

Script di automazione

Il codice della landing zone viene fornito con script per automatizzare attività di deploy e manutenzione.
Gli script possono essere eseguiti nativamente in un ambiente Linux oppure tramite container Docker per garantire compatibilità multi‑OS.

• Orchestrazione multi‑account: esecuzione di comandi su più account in modo coordinato.
• Generazione profili AWS SSO: generazione automatica dei profili AWS CLI per ogni account.
• Refresh delle credenziali SSO: login una sola volta ed export delle credenziali temporanee verso tutti gli account.
• Rilevamento del drift dell’infrastruttura: rilevazione di modifiche manuali o di codice non allineato su tutta la landing zone.

Modello di amministrazione delegata

L’architettura utilizza un modello di amministrazione delegata in cui i servizi vengono attivati a livello di Organization ma gestiti da account di piattaforma specializzati.
Questo approccio copre aree critiche come:

• Monitoraggio di sicurezza
• Gestione delle vulnerabilità
• Governance di rete
• Amministrazione dei backup

Spostando la responsabilità dal management account verso account dedicati, la landing zone applica un modello di ownership operativa a privilegi minimi e previene colli di bottiglia amministrativi.

Baseline globale tra gli account

La configurazione di ogni account è standardizzata in modo che le funzionalità vengano applicate in modo coerente.
La baseline include:

• AWS Config abilitato e log centralizzati
• Logging delle query DNS (Route53 Resolver) verso storage centrale
• Configurazione standard di un workgroup Athena in tutti gli account
• Budget mensili
• Rimozione delle VPC di default 
• Cifratura EBS abilitata di default
• Blocco dell’accesso pubblico S3 a livello di account
• Hardening della password policy IAM
• Abilitazione di IAM Access Analyzer
• Modalità VPC Block Public Access
• Configurazione per inventario con Systems Manager
• Metriche CloudWatch centralizzate nell’Operations account
• Configurazione dei contatti alternativi di default per billing, security e operations
• Alias di account

Sicurezza

• AWS GuardDuty per il rilevamento delle minacce, con opzioni configurabili per:
  • S3
  • Runtime EC2
  • RDS
  • Malware EC2
  • Runtime EKS
  • Lambda
  • Audit log EKS
• AWS Macie per la sicurezza dei dati, con enrollment automatico e export centralizzato dei finding.
• AWS Inspector per il vulnerability management su EC2, ECR e Lambda.
• AWS Config recorder abilitato in ogni account e regione.
• AWS Route53 DNS query log inviati a CloudWatch.
• AWS Route53 Resolver query log centralizzati in un bucket S3.
• AWS Security Hub come CSPM per la postura di sicurezza cloud, con policy di controllo basate su standard:
  • CIS AWS Foundations Benchmark v5.0.0
  • AWS Foundational Security Best Practices v1.0.0
  • NIST Special Publication 800‑53 Revision 5
• Retention dei log di audit su bucket S3 centralizzati, con scadenze configurabili per:
  • CloudTrail
  • Config
  • Log DNS
  • VPC Flow Logs
  • Finding di GuardDuty
  • Finding di Macie
• Capacità di analisi dei log di sicurezza tramite query centralizzate con Athena.
• Catalogo espandibile di guardrail obbligatori implementati come Service Control Policy, incluse:
  • Eliminazione del VPC di default in ogni regione abilitata
  • Cifratura EBS di default in ogni account e regione
  • S3 Public Access Block di default in ogni account
  • Hardening della password policy IAM (password più robuste e controllo sul riuso)
  • Abilitazione di IAM Access Analyzer in ogni account e regione
  • Postura VPC Block Public Access: modello di prevenzione predefinito per l’accesso pubblico alle risorse di rete

Identità e accesso (AWS Identity Center)

• Gestione centralizzata di utenti e gruppi con Identity Center: genera credenziali a breve durata e scope di ruolo on‑demand, senza IAM user di lunga durata.
• Permission set per i ruoli operativi:
  • Organization Admin
  • Operations
  • Security
  • Network
  • Developer
  • Finance
  • Audit
• Boundary policy per mitigare il rischio di privilege escalation del ruolo Developer.

Operations

• AWS Systems Manager: crea la baseline per inventario degli host, patching e gestione dei fleet.
• Gestione automatizzata dell’agente SSM e impostazioni opzionali dell’agente CloudWatch.
• Resource Scheduler per istanze EC2 non di produzione, con finestre di start/stop basate su schedule iCal e targeting tramite tag.
• Sink centralizzato per le metriche CloudWatch: l’Operations account riceve metriche (e opzionalmente log e trace) da tutti gli account sorgente.
• AWS Backup con account delegato.
• Budget Anomaly Detection a livello di organizzazione.
• Backend Terraform centralizzati, isolati e regolarmente salvati per maggiore sicurezza.
• Resource Explorer con indice aggregato a livello di organizzazione: qualsiasi risorsa, in qualunque account e regione abilitata, è ricercabile da un unico punto.

DNS e delega delle hosted zone

• Modello di hosted zone root centralizzata per il namespace della landing zone.
• Hosted zone delegate per account.
• Pattern automatizzato di delega NS nelle hosted zone degli account.

Governance dei costi

• Budget mensili di baseline su tutti gli account, con capacità di override.
• Rilevamento delle anomalie di costo nel Management account.
• Risparmio sui compute non di produzione basato su scheduler: spegnimento delle istanze fuori orario lavorativo se instance_scheduler_schedule = office-hours.

Networking

• Architettura IPAM centralizzata per la gestione degli IP privati e il deploy automatico di nuove VPC.
• Controlli opzionali di Transit Gateway per routing hub‑and‑spoke, supporto DNS e default di attachment:
  • Tutte le workload VPC si attaccano al TGW tramite condivisione RAM cross‑account
  • Le attachment cross‑account sono accettate automaticamente — nessun workflow di approvazione manuale
  • Le route vengono propagate automaticamente alla route table di default
• IPAM:
  • Pool privato di livello superiore gestito dal Network account
  • Sotto‑pool regionali condivisi con l’intera organizzazione tramite RAM
  • Le VPC dei workload account estraggono automaticamente i CIDR dal pool condiviso
  • Nessun coordinamento manuale necessario per il provisioning di nuove VPC
• Framework di provisioning VPC con:
  • Allocazione CIDR basata su IPAM
  • Strategia di subnet (public/private)
  • Configurazione NAT
  • Creazione VPC endpoint (interface/gateway)
  • Supporto DNS/hostname
  • VPC Flow Logs verso storage centralizzato
  • Controlli per attachment TGW e propagazione delle route
  • Workflow di richiesta/accettazione per VPC peering
  • Postura VPC BPA e relative esclusioni

Piattaforma Client VPN

• Ciclo di vita degli endpoint Client VPN gestito come codice.
• Autenticazione server basata su certificati con supporto per DNS validation.
• Modello di autenticazione federata SAML (Identity Center).
• Controlli di retention dei log.
• Controllo dei costi operativi tramite gestione delle associazioni di subnet (pattern pause/resume).

Backup

• Servizio di backup a livello di Organization, delegato all’Operations account.
• Policy di backup organization‑wide basata su tag, con più classi di piani:
  • Critical cross‑region: prima copia nell’account sorgente, copia verso un Vault centrale con Lock nell’Operations account (regione principale), copia verso una region secondaria nell’Operations account.
  • Critical same‑region (per servizi senza supporto alla copia cross‑region).
  • Standard: backup nell’account sorgente, copia verso un vault centrale nell’Operations account (regione principale).
  • Archive: singola copia nell’account sorgente.
• Policy di opt‑in basato sui tag, per abilitare il backup dove richiesto.
• Supporto per policy di Vault Lock critiche (inclusa governance mode e controlli di retention).

Dettagli tecnici

Controlli preventivi

Il catalogo di default definisce guardrail preventivi a livello di organizzazione, implementati come Service Control Policy (SCP) e applicati al root (“ROOT”).

A livello alto, questo set di controlli:

• Protegge l’integrità dell’organizzazione (nessuno può staccare un account membro dall’Organization).
• Protegge i servizi core di sicurezza e audit (CloudTrail, Config, Security Hub, GuardDuty, Macie, Access Analyzer) da disabilitazioni o indebolimenti significativi.
• Riduce gli abusi ad alto impatto del root e dell’IAM a scope di account (azioni del root, access key del root, indebolimento della password policy).

Puoi pensare a questi controlli come a controlli “non toccare”: non concedono permessi, ma eliminano la possibilità di cancellare o aggirare il piano di governance centrale, anche per utenti eccessivamente privilegiati negli account membri.

deny-leave-organization

Impedisce agli account membro di uscire dall’AWS Organization.

Cosa blocca
Qualsiasi tentativo da parte di un account membro di chiamare organizations:LeaveOrganization , indipendentemente da chi lo esegue all’interno di quell’account.

Perché è importante
Senza questo controllo, un amministratore in un account membro con permessi su Organizations potrebbe staccare l’account dall’org, uscendo istantaneamente dal perimetro di SCP, billing centralizzato e admin delegati. Questo rompe l’intero modello di governance per quell’account.

Implicazione di design
Rende il management account l’unico punto da cui controllare ciclo di vita e membership degli account nell’organizzazione. È un guardrail fondamentale per qualsiasi landing zone multi‑account.

deny-cloudtrail-configuration-changes

Impedisce di disabilitare, cancellare o modificare le impostazioni di CloudTrail organizzativo, ma solo per le organization trail.

Cosa blocca
cloudtrail:DeleteTrail, StopLogging, UpdateTrail, PutEventSelectors, PutInsightSelectors condizionati su cloudtrail:IsOrganizationTrail = true.

Perché la condition è importante
La condizione garantisce che siano protette solo le trail a livello di organizzazione. I workload possono comunque gestire trail locali non di organizzazione, se necessario, ma nessun account membro può spegnere o riconfigurare l'organizzazione trail che alimenta il log di audit centrale.

Implicazione di design
È il guardrail per la tua pipeline di audit immutabile a livello CloudTrail. Anche se qualcuno ottenesse AdministratorAccess in un account membro, non potrebbe disattivare la trail di organizzazione.

deny-config-recorder-changes

Impedisce di disabilitare o cancellare il recorder di AWS Config e il delivery channel.

Cosa blocca
config:DeleteConfigurationRecorder, StopConfigurationRecorder e DeleteDeliveryChannel ovunque nello scope.

Perché è importante
AWS Config è il ledger dei cambi di configurazione. Se un utente può spegnere il recorder o cancellare il delivery channel, perdi lo storico di cosa è cambiato, quando e per mano di chi.

Implicazione di design
Mantiene AWS Config sempre attivo negli account governati. Puoi ancora decidere dove e come consegna, ma nessun admin locale può spegnerlo per “ripulire” le evidenze.

deny-securityhub-disable

Impedisce di disabilitare Security Hub o di disassociare gli account membro dalla governance centrale.

Cosa blocca
securityhub:DisableSecurityHub, DisassociateFromAdministratorAccount, DeleteFindingAggregator.

Perché è importante
Security Hub è il tuo CSPM e la vista sullo stato dei controlli. Se un account membro può disabilitarlo o disassociarsi, perdi visibilità centralizzata e la capacità di misurare la compliance per quell’account.

Implicazione di design
Garantisce che, una volta che un account è registrato in un Security Hub gestito centralmente, vi resti. Un account compromesso non può nascondersi uscendo dall’aggregazione dei finding.

deny-guardduty-disable

Impedisce di disabilitare GuardDuty o di disassociare gli account dall’amministrazione delegata.

Cosa blocca
guardduty:DeleteDetector, DisassociateFromAdministratorAccount, StopMonitoringMembers .

Perché è importante
GuardDuty è il segnale principale di rilevamento delle minacce. Cancellare i detector o interrompere il monitoring è il classico tentativo di “spegnere l’allarme” dopo una compromissione.

Implicazione di design
Mantiene GuardDuty attivo in tutti gli account governati e preserva la visibilità del delegated admin anche in presenza di account locali ostili.

deny-macie-disable

Impedisce di disabilitare Amazon Macie o di disassociare gli account dall’amministrazione delegata.

Cosa blocca
macie2:DisableMacie, DisassociateFromAdministratorAccount .

Perché è importante
Macie si occupa di discovery di dati sensibili ed esposizione dei dati. Un attore che vuole esfiltrare dati proverebbe a spegnerlo o rimuovere la delega per evitare di essere rilevato.

Implicazione di design
Mantiene Macie coerentemente abilitato e governato centralmente ovunque venga utilizzato, cosa importante per data protection e requisiti legali.

deny-access-analyzer-disable

Impedisce la cancellazione degli analyzer IAM Access Analyzer utilizzati per governance.

Cosa blocca
access-analyzer:DeleteAnalyzer globalmente nello scope.

Perché è importante
IAM Access Analyzer è il rilevatore di esposizioni cross‑account e pubbliche. Cancellare gli analyzer rimuove un controllo importante per identificare policy di risorse eccessivamente permissive.

Implicazione di design
Garantisce che qualsiasi analyzer distribuito per governance non possa essere rimosso da un admin locale che vuole nascondere nuove esposizioni public o cross‑account.

deny-iam-account-password-policy-changes

Impedisce di indebolire o cancellare la password policy dell’account.

Cosa blocca
iam:DeleteAccountPasswordPolicy, iam:UpdateAccountPasswordPolicy in tutti gli account membro.

Perché è importante
La password policy di account è il controllo globale per le password IAM di console. Se i team possono indebolirla, ti ritrovi con credenziali fragili e standard incoerenti.

Implicazione di design
Riporta il ciclo di vita della password policy alla piattaforma centrale. I cambi di complessità, rotazione o riuso devono avvenire dove gli SCP lo permettono (tipicamente Management/Security), non per singolo account.

deny-root-actions

Nega tutte le azioni del root user negli account membro (gli SCP non possono limitare il root del management account).

Cosa blocca
Qualsiasi azione (Action = "*") quando aws:PrincipalArn corrisponde a arn:aws:iam::*:root negli account governati.

Perché è importante
Il root user ha potere effettivamente illimitato. La best practice è “non usare mai il root se non per poche attività eccezionali”, ma in pratica capita che venga usato durante incidenti o migrazioni, con un rischio elevato.

Implicazione di design
Questo SCP disabilita di fatto il root per le operazioni quotidiane negli account membri. Il root esiste ancora, ma non può eseguire azioni finché l’SCP è attivo. Si riduce così il rischio che qualcuno “ripieghi sul root” bypassando tutti i controlli IAM.

Nota
Come da specifica AWS, gli SCP non possono limitare il root del management account, quindi questo controllo si applica solo agli account membri.

deny-root-access-key-creation

Impedisce la creazione di access key per il root user.

Cosa blocca
iam:CreateAccessKey quando aws:PrincipalArn è un root di account (arn:aws:iam::*:root).

Perché è importante
Le access key del root sono tra le credenziali più pericolose in assoluto: longeve, onnipotenti e difficili da contenere una volta esposte. Bypassano quasi tutti i normali guardrail.

Implicazione di design
Anche se qualcuno accedesse come root, non potrebbe generare una nuova access key di root. In combinazione con il controllo precedente, questo rafforza il principio “no root keys, no root usage” in tutti gli account governati.

Postura di logging immutabile

La landing zone utilizza una trail multi‑region di AWS Organizations, di proprietà di un account centrale e visibile come organization trail negli account membro.

• La log file validation è abilitata, così CloudTrail produce file di digest firmati che rendono rilevabile la manomissione dei log; ogni alterazione degli eventi archiviati può essere verificata con gli strumenti nativi.
• Gli SCP impediscono di disabilitare, cancellare o riconfigurare le organization trail (StopLogging, DeleteTrail, UpdateTrail e modifiche agli selector limitati da cloudtrail:IsOrganizationTrail), in modo che un account workload compromesso non possa spegnere silenziosamente la pipeline di audit di organizzazione.

Per aumentare ulteriormente la resistenza alla manomissione, il design prevede l’abilitazione di AWS Backup per tutti i bucket di audit critici e la copia continua di tali log in un backup vault con Vault Lock in modalità di compliance.
Quando Vault Lock è abilitato con un periodo di retention adeguato, i recovery point nel vault non possono essere cancellati né avere la retention accorciata, nemmeno da IAM administrator o AWS stessa.

Questo trasforma il backup vault nello store di evidenze immutabile: anche se qualcuno ottenesse privilegi admin nell’account di logging e manomettesse o cancellasse gli oggetti di log primari, le copie bloccate resterebbero disponibili per l’intera finestra di retention configurata.

Profondità della governance delle identità

La landing zone utilizza AWS Identity Center come unico punto di ingresso per l’accesso delle persone fisiche, con credenziali a vita breve basate su ruoli e senza IAM user persistenti per il lavoro quotidiano.

I permission set sono specifici per team/ruolo, non generici per ambiente:

• I ruoli Developer sono limitati ai workload account (ad esempio sandbox e futuri account di produzione) e non hanno accesso agli account di piattaforma (Network, Security, Operations, Management).
• I ruoli Operations, Security e Network ricevono accesso agli account di piattaforma pertinenti e, dove necessario, ad alcuni workload account, in base alle responsabilità trasversali.
• I ruoli Finance/Billing e Audit sono limitati al set minimo di account e servizi necessario per analisi di billing e verifiche di sola lettura.

Gli sviluppatori ricevono un permission set in stile power‑user negli account workload per poter:

• Creare e gestire risorse applicative
• Creare i ruoli IAM necessari per le loro applicazioni
• Iterare velocemente nei propri account senza dipendere continuamente dal team di piattaforma

Per evitare che questo si trasformi in un controllo totale della piattaforma, al ruolo Developer è associato un permissions boundary:

• Il boundary blocca esplicitamente azioni ad alto rischio, come:
  • Creare IAM user
  • Escalare i propri privilegi o aggirare l’accesso SSO
  • Modificare costrutti di piattaforma condivisi come networking, servizi di sicurezza o log di organizzazione

Di conseguenza, gli sviluppatori possono creare ruoli e policy per le loro applicazioni solo entro i guardrail definiti dal boundary. Se una policy concedesse più privilegi di quanto il boundary permette, viene automaticamente rifiutata.

Opzioni di networking

La landing zone supporta al momento due modelli di connettività e rende esplicito il trade‑off.

Quando basta il VPC peering

Per ambienti in fase iniziale, il VPC peering è utilizzato come soluzione a costo zero e bassa complessità:

• Scope: un numero ridotto di workload account (ad esempio sandbox, dev, staging, prod).
• Topologia: ogni VPC workload è in peering con:
  • una VPC di network centrale (per Client VPN e traffico in ingresso/uscita condiviso)
  • una VPC di operations centrale (per osservabilità e tooling condiviso)
• Caratteristiche:
  • Routing semplice: sostanzialmente un hub‑and‑spoke con uno o due hub
  • Nessuna esigenza di routing transitivo o segmentazione est‑ovest complessa
  • Overhead operativo e costi ridotti; non c’è un data‑plane gestito da pagare o da operare

In questo modello, il peering fornisce connettività sufficiente perché:

• Gli ingegneri raggiungono i workload tramite Client VPN.
• Gli strumenti centrali di monitoraggio e operations raggiungono le risorse in ogni VPC workload.

Finché l’organizzazione rimane entro questo footprint ridotto hub‑and‑spoke, il peering è adeguato e conveniente.

Quando passare a Transit Gateway

Quando l’ambiente cresce verso una topologia multi‑account o multi‑VPC più ampia, il peering diventa velocemente complesso da gestire (connessioni N×N, routing complicato, assenza di route transitive). A quel punto la piattaforma dovrebbe passare ad AWS Transit Gateway (TGW).

Trigger tipici includono uno o più dei seguenti:

• Scala di account/VPC
  • Più di pochi workload account, o molte VPC per account, tali da rendere la gestione dei singoli peering e delle route table soggetta a errori.
• Complessità del routing
  • Necessità di connettività transitiva (workload‑to‑workload tramite un hub condiviso, non solo workload‑to‑network/operations).
  • Esigenze di segmentazione est‑ovest più spinte tra ambienti, tenant o business unit.
• Connettività ibrida
  • Integrazione con reti on‑premise o altri cloud, dove TGW diventa l’hub naturale per VPN o Direct Connect.
• Governance e standardizzazione
  • Necessità di definire policy di routing e segmentazione una sola volta in un punto centrale, anziché duplicare le regole in molte VPC route table.

In questa fase, TGW diventa l’hub autorevole:

• Tutte le VPC di workload, network e servizi condivisi sono attestate al Transit Gateway.
• Le policy di routing e segmentazione sono definite sulle route table del TGW, non più attraverso un mesh di peering individuali.
• Il pattern basato su peering è dismesso o mantenuto solo in casi speciali e isolati.

Dichiarazioni di compliance

La landing zone è progettata per fornire un forte allineamento di baseline a tre standard AWS nativi:

• CIS AWS Foundations Benchmark v5
• AWS Foundational Security Best Practices v1.0.0
• NIST SP 800‑53 Rev. 5 (come implementato in Security Hub)

In una landing zone vuota (senza workload applicativi distribuiti), con solo i servizi core di piattaforma abilitati, i punteggi di Security Hub per questi tre standard superano il 95%, dopo avere disabilitato intenzionalmente un set limitato di controlli che non si allineano al modello operativo desiderato.

Come viene misurata la baseline

• Il punteggio si riferisce specificamente alla copertura dei controlli Security Hub negli account della landing zone, con i controlli elencati qui sotto disabilitati per design.
• “>95%” significa che, per ciascun benchmark, almeno il 95% dei controlli abilitati è in stato “passed” o “not applicable” in una landing zone vuota appena distribuita.
• I controlli specifici per i workload che richiedono risorse applicative (per esempio log specifici su bucket S3 applicativi) sono attesi in carico ai team workload, usando lo stesso modello di governance; sono fuori dallo scope della baseline di sola piattaforma.

Controlli disabilitati intenzionalmente

I seguenti controlli Security Hub sono disabilitati a livello di piattaforma con la motivazione esplicita “Aligned to internal security” (o vincoli operativi), perché non si allineano al modello operativo previsto o sono meglio gestiti da processi interni:

• IAM.6 – Hardware MFA per il root user
  Il root non viene usato per le operazioni quotidiane negli account membro e le credenziali di root sono rigidamente controllate. L’enforcement dell’MFA hardware per ogni root in ogni account è trattato come decisione di policy interna, non come requisito di baseline della landing zone.
• IAM.18 – Ruolo dedicato per AWS Support
  L’uso e la struttura dei support role è definito dai processi di incident management interni. La piattaforma non impone globalmente un pattern specifico di ruolo di supporto.
• S3.20 – MFA delete per bucket S3 general purpose
  MFA delete non è abilitato di default perché complica automazione e lifecycle management dei bucket general purpose. Controlli robusti sono garantiti tramite logging centralizzato, SCP e pattern di backup/retention.
• S3.22 / S3.23 – Logging a livello di oggetto read/write su bucket S3 general purpose
  Il logging a livello di oggetto non è imposto su tutti i bucket general purpose, perché avrebbe impatti significativi su costi e rumore operativo. Dove necessario, può essere abilitato per workload classificati come sensibili, come parte di un design di sicurezza applicativo.
• CloudFormation.3 – Termination protection sugli stack CloudFormation
  L’enforcement globale della termination protection non si allinea al modello di automazione e ai cicli di vita previsti per alcuni stack, che sono comunque gestiti e creati da AWS internamente. Viene applicata selettivamente dove appropriato.
• CloudFormation.4 – Service role associati agli stack CloudFormation
  L’uso di service role espliciti per ogni stack è trattato come dettaglio di implementazione di specifiche pipeline/moduli, non come requisito universale a livello di landing zone.
• CloudWatch.16 – Retention minima di 365 giorni per tutti i log group
  Un minimo rigido di 365 giorni su tutti i log group è troppo costoso e poco flessibile; non può essere adattato per ambiente o workload. La retention viene gestita tramite policy e requisiti interni.
• S3.15 – Object Lock su bucket S3 general purpose
  S3 Object Lock non è abilitato di default su tutti i bucket general purpose. L’immutabilità dei dati di audit è gestibile a livello di backup tramite vault AWS Backup con Vault Lock in modalità di compliance, anziché bloccare ogni bucket primario.

FAQ tecniche

La landing zone supporta l’amministrazione delegata dei servizi?
Sì. Il design delega esplicitamente l’amministrazione dei servizi core di sicurezza e operations dal Management account ad account di piattaforma specializzati, in particolare Security e Operations.

È basata su Control Tower?
No. E’ una landing zone personalizzata per AWS Organizations, implementata con Terraform e Terragrunt, non una deployment di Control Tower. Persegue molti degli stessi obiettivi architetturali, ma ownership ed estendibilità sono incentrate sul codebase Terraform, non su un’opinione di landing zone gestita da AWS. L’utilizzo di Control Tower è sostanzialmente ancora in conflitto con una piattaforma gestita usando Terraform, ed impone vincoli architetturali restrittivi.

La sandbox può evolvere in produzione?
Sì. L’intento è partire con una baseline sandbox sicura e a basso costo, per poi irrobustire lo stesso modello strutturale fino a una landing zone di produzione, senza cambiare topologia di account o layout del repository.

Conclusione

La Nimbiora Landing Zone v1.0.0 offre una solida fondazione tecnica per una piattaforma AWS multi‑account personalizzata, basata su forte separazione degli account, servizi di sicurezza centralizzati, evidenze centralizzate, infrastructure as code e un percorso pragmatico dalla sandbox alla produzione. I suoi punti di forza principali sono la chiarezza architetturale e una preferenza per la manutenibilità di lungo periodo, rispetto a soluzioni rapide e manuali.