Quanto costa un'eccezione
Una Landing Zone viene progettata una volta e poi estesa durante l'esercizio, ed è esattamente lì che inizia la sua storia vera. Il primo progetto con una deadline rigida ottiene la sua subscription fuori dalla gerarchia, perché il policy review avrebbe richiesto più tempo dello sprint. Il fornitore che un venerdì pomeriggio non riusciva ad andare avanti con i diritti di Contributor riceve Owner sulla Management Group e lo conserva, perché dopo il go-live nessuno ci pensa più. E quando il firewall nell'hub limita il throughput di uno spoke, lo spoke ottiene il suo peering diretto, aggirando l'hub. Ognuna di queste decisioni era sensata nel momento in cui è stata presa, e ognuna è ancora in vigore oggi.
Le conseguenze sono concrete. Una subscription fuori dalla gerarchia non eredita alcuna policy, quindi la policy non la protegge. Un Owner a livello di Management Group si propaga in silenzio su ogni subscription sottostante, anche su quelle che all'epoca non esistevano ancora. Un peering senza route verso il firewall è un percorso di rete che il tuo SOC non vede. L'Azure Landing Zone Review sovrappone il progetto originale allo stato attuale, seguendo le otto Design Areas del Cloud Adoption Framework, e ordina le deviazioni in base alle loro conseguenze, non alla loro anzianità.
Le otto Design Areas del Cloud Adoption Framework
Microsoft ha organizzato le decisioni di una Landing Zone in otto Design Areas perché altrimenti la maggior parte degli errori si nasconde negli spazi tra i team: il team di rete costruisce l'hub, il team identity assegna i ruoli, e chi ha approvato l'eccezione alla policy non compare in nessuno dei due log. Le esaminiamo tutte e otto, ognuna con la stessa domanda: cosa era previsto, cosa è stato costruito, e cosa comporta la differenza.
Azure Billing e Entra ID Tenant
Enrollment, gerarchia di billing e il tenant su cui poggia tutto. Un secondo tenant derivante da un'acquisizione raramente è un problema, finché qualcuno non deve consolidare licenze, identità e fatture.
Identity e Access Management
Ruoli a livello di piattaforma, Service Principals e PIM. Un Owner sulla Root Management Group si propaga silenziosamente su ogni subscription creata in seguito.
Resource Organization
Gerarchia delle Management Groups, subscription design, nomi e tag. I workload nella Management Group sbagliata ereditano le policy sbagliate, e questo emerge solo quando un audit lo richiede.
Network Topology e Connectivity
Hub-and-Spoke o Virtual WAN, connettività ibrida, DNS, firewall, Private Endpoints. Un peering che aggira l'hub è tecnicamente corretto e invisibile al SOC.
Security
Defender for Cloud, crittografia, Key Vaults e tutto ciò che risiede sulla piattaforma anziché nel workload. Un piano Defender attivo solo su una parte delle subscription protegge esattamente quella parte.
Management
Monitoring, logging, backup e recovery. Le Diagnostic Settings mancanti non emergono durante l'esercizio ordinario, ma durante un incident, quando servono i log che non sono mai stati scritti.
Governance
Azure Policy, iniziative, eccezioni e controllo dei costi. Un'exemption ha una data di scadenza se qualcuno ne ha impostata una. La maggior parte non ne ha.
Platform Automation e DevOps
Infrastructure as Code, pipeline, Azure Verified Modules. Una piattaforma modificata tramite il portale ha due versioni della verità: quella nel repository e quella in Azure. Quella che conta è la seconda.
Come funziona
- Intervista al teamIntervista al teamCominciamo dalle persone che gestiscono la piattaforma, non dagli strumenti: architettura, tool, processi operativi, strategia. La maggior parte dei rilievi che uno scan produce in seguito ha una storia alle spalle, e chi la conosce li valuta correttamente. Una decisione consapevole è un'altra cosa rispetto a un provisorio dimenticato.
- Analisi dell'ambienteAnalisi dell'ambientePoi analizziamo l'ambiente con il tooling: Management Groups, policy ed exemption, assegnazioni di ruoli, percorsi di rete, Diagnostic Settings, costi. In modo automatizzato e confrontando con lo stato attuale del Cloud Adoption Framework, non con quello di tre anni fa.
- Prioritizzazione dei rilieviPrioritizzazione dei rilieviLo strumento individua la deviazione, l'intervista la spiega, e solo i due elementi insieme definiscono una priorità. In cima troviamo ciò che propaga diritti o blocca i log, in fondo ciò che viola uno schema di naming. Un rilievo senza conseguenze è una nota, non un'azione da intraprendere.
- Discussione del reportDiscussione del reportRicevi il report con il livello di maturità per ogni Design Area, i rilievi e le raccomandazioni, e lo esaminiamo insieme. Non perché tu conosca cento rilievi, ma perché il lunedì mattina tu sappia da quale iniziare.
Un report con una priorità
Ricevi un report che inquadra la tua Landing Zone lungo le otto Design Areas: livello di maturità per ogni area, rilievi prioritizzati e raccomandazioni che un platform team può implementare senza doverci chiedere nulla. In più, la distinzione che nessuno scanner è in grado di fare: quali deviazioni dal framework sono frutto di una decisione consapevole e quali di una svista. È pensato per platform team e responsabili IT che gestiscono una Landing Zone da alcuni anni e vogliono sapere cosa è cambiato nel frattempo, nell'ambiente e nel framework. Chi si trova di fronte a una migrazione farà bene a verificare prima le fondamenta che il trasloco. Chi ha preso in carico la piattaforma da un fornitore ha bisogno di un secondo sguardo che non abbia costruito ciò che valuta. L'implementazione non è inclusa. Viene gestita come progetto separato, con noi, con un partner o con il tuo team.
E dopo
Le domande che ci vengono poste in anticipo
Le domande emerse nei primi colloqui, con le stesse risposte che diamo in quella sede.
Dobbiamo avere una Landing Zone di glueckkanja?
No. Analizziamo qualsiasi Landing Zone, sia che provenga dall'Enterprise Scale template, da un altro fornitore o cresciuta direttamente nel portale. Il riferimento è il Cloud Adoption Framework, non la nostra Azure Foundation. Se la consigliamo quando il report lo giustifica, non è una sorpresa, ma nemmeno una condizione.
Cosa distingue il review dal modulo Azure dei Preventive Services?
La domanda che viene posta. Il modulo Azure chiede come un attaccante possa passare da una subscription al piano di controllo, e si conclude con una roadmap di hardening. Il Landing Zone Review chiede se la piattaforma nel suo insieme regge: organizzazione, rete, governance, operations, automazione, costi. La security è una delle otto Design Areas. Chi vuole entrambi inizia dal review, perché fornisce la mappa su cui il modulo traccia i percorsi.
Di quali permessi avete bisogno?
Solo di lettura. Per l'analisi è sufficiente un ruolo Reader sulla Management Group di livello più alto, integrato con i permessi di lettura su Cost Management. Non modifichiamo nulla, e gli accessi vengono rimossi al termine del review. Il fatto stesso che il review possa essere condotto con soli permessi di lettura è già un rilievo: una Landing Zone in cui questo non è possibile ha già trovato il suo primo tema da affrontare.
Analizzate anche i costi?
Sì, perché in una Landing Zone hanno le stesse cause dei rilievi di governance. Senza tag non è possibile attribuire una fattura a nessun team, senza budget alert una VM dimenticata emerge solo a fine mese, e una reservation che nessuno gestisce paga capacità che nessuno utilizza. Ciò che emerge viene riportato nel report, con i numeri.
Quanto dura il review?
Intervista e analisi richiedono pochi giorni. Dal tuo lato comporta un appuntamento per l'intervista, l'abilitazione dei permessi di lettura e un incontro per esaminare il report insieme. La parte più impegnativa è ciò che fai dopo con l'elenco, e quella appartiene a te.
L'implementazione è inclusa?
No, e intenzionalmente. Un review che dà priorità ai propri progetti successivi non è un review. Ricevi l'ordine di priorità e le raccomandazioni; l'implementazione viene gestita come progetto separato, con noi, con un partner o con il tuo team. Chi vuole ricostruire la Landing Zone da zero trova il percorso nella Azure Foundation.
