Landing zone: da dove si comincia

Quasi tutte le aziende cominciano con un solo account AWS. Va benissimo, finché non arriva una di queste frasi: “il cliente vuole vedere le evidenze per l’audit”, “chi ha cancellato quel bucket?”, “quanto spende il team B?”. A quel punto serve una landing zone, e conviene farla prima che il disordine diventi abitudine.

Cos’è, senza gergo

Una landing zone è il punto di partenza comune per tutti gli account AWS dell’azienda: come sono organizzati, chi può entrare, cosa viene registrato e quali regole valgono per tutti, sempre.

L’idea chiave è che l’account è il confine più forte che AWS ti dà. Due ambienti in account diversi non si toccano per sbaglio: un errore in sviluppo non cancella la produzione, un permesso troppo largo resta dentro il suo account, e la bolletta si legge account per account.

La struttura minima

Non servono decine di account. Si parte da questa, e si allarga quando c’è un motivo.

Management accountFatturazione, Organizations, Control TowerNessun carico di lavoro qui

1. OU Security
   • Log ArchiveTutti i log di tutti gli account, in un posto solo e non modificabili.
   • AuditChi fa sicurezza guarda tutto da qui, in sola lettura.
2. OU Infrastructure
   • NetworkRete condivisa: Transit Gateway, DNS, connessione con l'ufficio.
3. OU Workloads
   • ProdSolo produzione. Pochi accessi, tutti tracciati.
   • Non-prodSviluppo e test, con le stesse regole ma meno vincoli.
4. OU Sandbox
   • Un account a personaPer provare. Budget basso e pulizia automatica.

OU	A cosa serve	Regola d’oro
Security	Log e controlli di sicurezza di tutti	Nessuno ci lavora, si consulta
Infrastructure	Rete e servizi condivisi	Una sola rete, gestita da un team
Workloads	Le applicazioni, per ambiente	Produzione separata dal resto
Sandbox	Provare senza rischi	Budget basso, si svuota da sola

L’account di management merita una nota a parte: è quello che comanda l’organizzazione, e le policy dell’organizzazione non si applicano a lui. Per questo non ci deve girare niente: solo fatturazione e gestione degli account.

Le regole che servono dal primo giorno

AWS Control Tower crea la struttura di base, gli account di Security e un insieme di controlli. I controlli sono di tre tipi: preventivi, che bloccano un’azione prima che avvenga; detective, che segnalano quando qualcosa non è conforme; proattivi, che controllano le risorse prima che vengano create.

Non bisogna attivarli tutti. All’inizio ne bastano pochi, scelti bene:

• Nessun utente IAM con password o chiavi. Si entra solo da IAM Identity Center, collegato al login aziendale. Quando una persona lascia l’azienda, perde l’accesso a tutti gli account in un colpo.
• Log che nessuno può spegnere. CloudTrail e Config attivi in ogni account, con i log copiati nell’account Log Archive. Nessuno, nemmeno un amministratore di un account, può disattivarli.
• Solo le regioni che usate. Se lavorate in Europa, le altre regioni si bloccano. Meno superficie da sorvegliare, e un modo in meno per sbagliare.
• Budget e avvisi per ogni account. Sapere entro un giorno che una sandbox sta spendendo troppo vale più di qualsiasi report di fine mese.

Come si comincia, in pratica

1. Fase 1
   Decidere nomi, tag e OUCome si chiamano gli account, quali tag sono obbligatori (team, ambiente, centro di costo). Cambiarli dopo costa più di tutto il resto.
2. Fase 2
   Attivare Control TowerNell'account di management, nella regione principale. Crea l'OU Security con gli account Log Archive e Audit.
3. Fase 3
   Accessi con IAM Identity CenterCollegato al provider aziendale. Gruppi per ruolo, permessi per account. Poi si spengono gli utenti IAM.
4. Fase 4
   Pochi guardrail, provatiRegioni, log non disattivabili, niente utenti IAM. Prima su una OU di prova, poi su tutte.
5. Fase 5
   Account come codiceNuovi account creati con Account Factory, anche per Terraform: in mezz'ora, già con rete, log e regole.
6. Fase 6
   Spostare i carichiUn ambiente alla volta, partendo da sviluppo. La produzione per ultima, quando tutto il resto è collaudato.

Gli errori che costano anni

• Carichi di lavoro nell’account di management. È l’unico che le policy non proteggono: va tenuto vuoto.
• Un’OU per ogni team. Le OU servono a raggruppare regole, non persone. Se due OU hanno le stesse regole, probabilmente sono una.
• Nomi e tag decisi dopo. Tutto il resto (costi, accessi, automazioni) si appoggia su di loro.
• Account creati a mano. Ogni account fatto a mano è diverso dagli altri, e la differenza si scopre durante un incidente.

Le domande per capire se vi serve adesso

1. Produzione e sviluppo stanno nello stesso account?
2. Qualcuno usa ancora utenti IAM con chiavi di accesso?
3. Sapreste dire in un minuto quanto spende ogni team?
4. Se un cliente chiede i log di accesso dell’ultimo anno, li avete, e sono integri?

Se a una di queste avete risposto male, la landing zone non è un progetto per il futuro. È il prossimo.