Azure Landing Zone Review
Wat een uitzondering kost
Een Landing Zone wordt eenmalig ontworpen en daarna in productie uitgebreid, en precies daar begint haar eigenlijke geschiedenis. Het eerste project met een harde deadline krijgt zijn subscription buiten de hiërarchie, omdat de policy-review langer zou hebben geduurd dan de sprint. De dienstverlener die op een vrijdagmiddag met Contributor-rechten niet verder kon, krijgt Owner op de Management Group en behoudt die rechten, omdat niemand er na de go-live nog aan denkt. En als de firewall in de hub de doorvoer van een spoke beperkt, krijgt de spoke zijn peering rechtstreeks, buiten de hub om. Elke beslissing was op dat moment verstandig, en elke is tot op heden van kracht.
De gevolgen zijn concreet. Een subscription buiten de hiërarchie erft geen policy, dus beschermt de policy haar ook niet. Een Owner op Management Group-niveau erft door naar elke subscription daaronder, ook naar de subscriptions die er destijds nog niet waren. Een peering zonder route naar de firewall is een netwerkpad dat jullie SOC niet ziet. De Azure Landing Zone Review legt het ontwerp en de huidige situatie naast elkaar, langs de acht Design Areas van het Cloud Adoption Framework, en sorteert de afwijkingen op hun gevolgen, niet op hun leeftijd.
De acht Design Areas van het Cloud Adoption Framework
Microsoft heeft de beslissingen van een Landing Zone in acht Design Areas onderverdeeld, omdat de meeste fouten zich anders verbergen in de gaten tussen teams: het netwerkteam bouwt de hub, het identity-team wijst rollen toe, en wie de policy-uitzondering heeft goedgekeurd, staat in geen van beide logboeken. We gaan alle acht langs, elk met dezelfde vraag: wat was bedoeld, wat is gebouwd, en wat volgt uit het verschil.
Azure Billing en Entra-tenant
Enrollment, billing-hiërarchie en de tenant waarop alles draait. Een tweede tenant uit een overname is zelden een probleem, totdat iemand licenties, identiteiten en facturen moet samenvoegen.
Identity en Access Management
Rollen op platformniveau, Service Principals en PIM. Een Owner op de Root Management Group erft stilletjes door naar elke subscription die later wordt aangemaakt.
Resource Organization
Management Group-hiërarchie, subscription-ontwerp, namen en tags. Workloads in de verkeerde Management Group erven de verkeerde policies, en dat valt pas op als een audit ernaar vraagt.
Network Topology en Connectivity
Hub-and-spoke of Virtual WAN, hybride connectiviteit, DNS, firewall, Private Endpoints. Een peering buiten de hub om is technisch correct en voor het SOC onzichtbaar.
Security
Defender for Cloud, versleuteling, Key Vaults en alles wat op platformniveau ligt in plaats van in de workload. Een Defender-plan dat actief is op een deel van de subscriptions, beschermt precies dat deel.
Management
Monitoring, logging, backup en recovery. Ontbrekende Diagnostic Settings vallen niet op tijdens normale operatie, maar tijdens een incident, wanneer de logs nodig zijn die nooit zijn geschreven.
Governance
Azure Policy, initiatieven, uitzonderingen en kostenbeheer. Een exemption heeft een vervaldatum als iemand die heeft ingesteld. De meeste hebben er geen.
Platform Automation en DevOps
Infrastructure as Code, pipelines, Azure Verified Modules. Een platform dat via de portal wordt aangepast, heeft twee waarheden: die in de repository en die in Azure. De tweede geldt.
Zo werkt het
- Team bevragenTeam bevragenWe beginnen met de mensen die het platform beheren, niet met het tool: architectuur, tooling, operationele processen, strategie. De meeste bevindingen die een scan later oplevert, hebben een voorgeschiedenis, en wie die kent, beoordeelt ze juist. Een bewuste beslissing is iets anders dan een vergeten noodoplossing.
- Omgeving uitlezenOmgeving uitlezenDaarna lezen we de omgeving uit met tooling: Management Groups, policies en exemptions, roltoewijzingen, netwerkpaden, Diagnostic Settings, kosten. Geautomatiseerd en getoetst aan de huidige stand van het Cloud Adoption Framework, niet aan die van drie jaar geleden.
- Bevindingen sorterenBevindingen sorterenHet tool vindt de afwijking, het interview verklaart haar, en pas samen leveren ze een prioriteit op. Bovenaan staat wat rechten doorgeeft of logs verhindert, onderaan wat een naamgevingsschema schendt. Een bevinding zonder gevolg is een notitie, geen opdracht.
- Report besprekenReport besprekenJullie ontvangen het report met het volwassenheidsniveau per Design Area, bevindingen en aanbevelingen, en we lopen het samen door. Niet om honderd bevindingen te kennen, maar zodat jullie maandag weten met welke je begint.
Een report met volgorde
Jullie ontvangen een report dat jullie Landing Zone langs de acht Design Areas in kaart brengt: volwassenheidsniveau per gebied, geprioriteerde bevindingen en aanbevelingen die een platformteam zelf kan uitvoeren, zonder ons te hoeven raadplegen. Daarbij het onderscheid dat geen scanner kan maken: welke afwijking van het framework een bewuste beslissing was en welke een omissie. Het report is bedoeld voor platformteams en IT-management die een Landing Zone al enkele jaren beheren en willen weten wat er sindsdien is veranderd, aan de omgeving en aan het framework. Wie voor een migratie staat, kan beter het fundament beoordelen dan de verhuizing zelf. Wie het platform van een dienstverlener heeft overgenomen, heeft een tweede paar ogen nodig dat niet heeft gebouwd wat het beoordeelt. De uitvoering is niet inbegrepen. Die loopt als een apart project, met ons, met een partner of met jullie eigen team.
En daarna
Wat vooraf gevraagd wordt
De vragen uit de eerste gesprekken, beantwoord zoals we ze daar beantwoorden.
Hebben we daarvoor een Landing Zone van glueckkanja nodig?
Nee. We beoordelen elke Landing Zone, of die nu uit het Enterprise-Scale-template komt, van een andere dienstverlener afkomstig is of in de portal is gegroeid. De maatstaf is het Cloud Adoption Framework, niet onze Azure Foundation. Dat we die aanbevelen als het report daar aanleiding toe geeft, is geen verrassing, maar ook geen voorwaarde.
Wat onderscheidt de review van het Modul Azure der Preventive Services?
De vraag die gesteld wordt. Het Modul Azure vraagt hoe een aanvaller van een subscription naar het controlevlak komt, en mondt uit in een hardening-roadmap. De Landing Zone Review vraagt of het platform als geheel draagt: organisatie, netwerk, governance, beheer, automatisering, kosten. Security is daarbij één van de acht Design Areas. Wie beide wil, begint met de review, omdat die de kaart levert waarop de module de routes intekent.
Welke rechten hebben jullie nodig?
Leesrechten. Voor de analyse volstaat een Reader-rol op de bovenste Management Group, aangevuld met leesrechten op Cost Management. We wijzigen niets, en de toegangen worden na de review verwijderd. Dat de review met Reader-rechten uit te voeren is, is op zichzelf al een bevinding: een Landing Zone waarbij dat niet mogelijk is, heeft haar eerste onderwerp gevonden.
Beoordelen jullie ook de kosten?
Ja, omdat ze in een Landing Zone dezelfde oorzaken hebben als de governance-bevindingen. Zonder tags valt een factuur niet aan een team toe te wijzen, zonder budget-alerts valt een vergeten VM pas eind van de maand op, en een reservering die niemand bijhoudt, betaalt capaciteit die niemand gebruikt. Wat daar opvalt, staat in het report, met cijfer.
Hoe lang duurt de review?
Interview en analyse kosten enkele dagen. Aan jullie kant vraagt het een interviewafspraak, het vrijgeven van de leesrechten en de sessie waarin we het report doornemen. Het meeste werk zit in wat jullie daarna met de lijst doen, en dat is voor jullie rekening.
Is de uitvoering inbegrepen?
Nee, bewust niet. Een review die zijn eigen vervolgopdrachtens prioriteert, is geen review meer. Jullie krijgen volgorde en aanbevelingen, de uitvoering loopt als een apart project, met ons, met een partner of met jullie eigen team. Wie de Landing Zone daarna opnieuw wil opzetten, vindt via de Azure Foundation de weg daarnaartoe.
