Azure Landing Zone Review
Hvad en undtagelse koster
En landing zone designes én gang og udvides derefter i drift, og det er præcis der, den egentlige historie begynder. Det første projekt med en hård deadline får sin subscription uden for hierarkiet, fordi policy-reviewet ville have taget længere tid end sprintet. Den leverandør, der en fredag eftermiddag ikke kom videre med Contributor-rettigheder, får Owner på Management Group og beholder det, fordi ingen tænker på det efter go-live. Og når firewallen i hub'en bremser gennemstrømningen for en spoke, får spoke'en sit peering direkte, uden om hub'en. Hver af disse beslutninger var fornuftig i sit øjeblik, og alle er stadig i kraft.
Konsekvenserne er konkrete. En subscription uden for hierarkiet arver ingen policy, og derfor beskytter policyen den heller ikke. En Owner på Management Group-niveau nedarves til alle subscriptions nedenunder, også dem, der ikke fandtes dengang. Et peering uden rute til firewallen er en netværkssti, som jeres SOC ikke kan se. Azure Landing Zone Review lægger designet og den faktiske tilstand oven på hinanden langs de otte Design Areas i Cloud Adoption Framework og sorterer afvigelserne efter deres konsekvenser, ikke efter deres alder.
De otte Design Areas i Cloud Adoption Framework
Microsoft har organiseret beslutningerne i en landing zone i otte Design Areas, fordi de fleste fejl ellers gemmer sig i mellemrummene mellem teamene: netværksteamet bygger hub'en, identity-teamet tildeler rollerne, og hvem der godkendte policy-undtagelsen, fremgår af ingen af de to logs. Vi gennemgår alle otte, med det samme spørgsmål til hver: hvad var hensigten, hvad er bygget, og hvad følger af forskellen.
Azure Billing og Entra-tenant
Enrollment, billing-hierarki og den tenant, alt kører på. En anden tenant fra en overtagelse er sjældent et problem, indtil nogen skal samle licenser, identiteter og fakturaer.
Identity og Access Management
Roller på platformniveau, Service Principals og PIM. En Owner på Root Management Group nedarves lydløst til alle subscriptions, der oprettes senere.
Resource Organization
Management Group-hierarki, subscription-design, navne og tags. Workloads i den forkerte Management Group arver de forkerte policies, og det opdages først, når en audit spørger.
Network Topology og Connectivity
Hub-and-spoke eller Virtual WAN, hybridforbindelser, DNS, firewall, Private Endpoints. Et peering uden om hub'en er teknisk korrekt og usynligt for SOC.
Security
Defender for Cloud, kryptering, Key Vaults og alt det, der ligger på platformen frem for i workloaden. En Defender-plan, der er aktiv på en del af subscriptions, beskytter præcis den del.
Management
Monitoring, logging, backup og recovery. Manglende Diagnostic Settings opdages ikke i drift, men under en hændelse, når de logs, der aldrig blev skrevet, pludselig er nødvendige.
Governance
Azure Policy, initiativer, undtagelser og omkostningsstyring. En exemption har en udløbsdato, hvis nogen har sat én. De fleste har ingen.
Platform Automation og DevOps
Infrastructure as Code, pipelines, Azure Verified Modules. En platform, der ændres via portalen, har to sandheder: den i repositoryet og den i Azure. Det er den anden, der gælder.
Sådan foregår det
- Interview med teametInterview med teametVi starter med de mennesker, der driver platformen, ikke med toolingen: arkitektur, værktøjer, driftsprocesser, strategi. De fleste fund, et scan leverer senere, har en forhistorie, og den, der kender den, vurderer dem rigtigt. En bevidst beslutning er noget andet end en glemt nødløsning.
- Aflæsning af miljøetAflæsning af miljøetDerefter læser vi miljøet ud med tooling: Management Groups, policies og exemptions, rolletildelinger, netværksruter, Diagnostic Settings, omkostninger. Automatiseret og holdt op mod den aktuelle version af Cloud Adoption Framework, ikke den fra for tre år siden.
- Prioritering af fundPrioritering af fundToolingen finder afvigelsen, interviewet forklarer den, og først begge tilsammen giver en prioritet. Øverst står det, der nedarver rettigheder eller forhindrer logs, nederst det, der bryder et navngivningsskema. Et fund uden konsekvens er en note, ikke en opgave.
- Gennemgang af rapportenGennemgang af rapportenI får rapporten med modenhedsniveau pr. Design Area, fund og anbefalinger, og vi gennemgår den sammen. Ikke for at I skal kende hundrede fund, men for at I mandag morgen ved, hvilket I begynder med.
En rapport med rækkefølge
I får en rapport, der placerer jeres landing zone langs de otte Design Areas: modenhedsniveau pr. område, prioriterede fund og anbefalinger, som et platformteam kan omsætte uden at spørge os. Dertil den sondring, ingen scanner leverer: hvilken afvigelse fra frameworket var en beslutning, og hvilken var et fejlskøn. Rapporten er beregnet til platformteams og IT-ledelse, der har drevet en landing zone i nogle år og vil vide, hvad der har ændret sig siden da, både i miljøet og i frameworket. Den, der står over for en migration, bør undersøge fundamentet frem for selve flytningen. Den, der har overtaget platformen fra en leverandør, har brug for et ekstra par øjne, der ikke har bygget det, de vurderer. Implementeringen er ikke inkluderet. Den kører som et selvstændigt projekt, med os, med en partner eller med jeres eget team.
Og hvad så
Hvad vi bliver spurgt om på forhånd
Spørgsmålene fra de første samtaler, besvaret på samme måde, som vi besvarer dem der.
Skal vi have en landing zone fra glueckkanja for at bruge dette?
Nej. Vi gennemgår enhver landing zone, uanset om den stammer fra Enterprise-Scale-templaten, fra en anden leverandør eller er vokset frem via portalen. Målestokken er Cloud Adoption Framework, ikke vores Azure Foundation. At vi anbefaler den, når rapporten giver anledning til det, er ingen overraskelse, men heller ingen betingelse.
Hvad adskiller reviewet fra Modul Azure i Preventive Services?
Det spørgsmål, der stilles. Modul Azure spørger, hvordan en angriber kommer fra en subscription til kontrolplanet, og munder ud i en hardening-roadmap. Landing Zone Review spørger, om platformen som helhed bærer: organisation, netværk, governance, drift, automatisering, omkostninger. Security er i den sammenhæng én af otte Design Areas. Den, der vil have begge dele, begynder med reviewet, fordi det leverer kortet, som modulet tegner ruterne ind på.
Hvilke rettigheder har I brug for?
Læserettigheder. Til analysen er en Reader-rolle på den øverste Management Group tilstrækkelig, suppleret med læseadgang til Cost Management. Vi ændrer ingenting, og adgangene fjernes efter reviewet. At reviewet kan gennemføres med Reader-rettigheder er i sig selv et fund: en landing zone, hvor det ikke er muligt, har allerede fundet sit første emne.
Gennemgår I også omkostningerne?
Ja, fordi de i en landing zone har de samme årsager som governance-fundene. Uden tags kan en faktura ikke henføres til et team, uden budget-alerts opdages en glemt VM først ved månedens afslutning, og en reservation, som ingen vedligeholder, betaler for kapacitet, som ingen bruger. Det, der springer i øjnene der, står i rapporten med et tal.
Hvor lang tid tager reviewet?
Interview og analyse tager nogle få dage. På jeres side kræver det én interviewaftale, frigivelse af læserettighederne og den session, hvor vi gennemgår rapporten sammen. Den mest tidskrævende del er det, I bagefter gør med listen, og den tilhører jer.
Er implementeringen inkluderet?
Nej, og det er med vilje. Et review, der prioriterer sine egne følgeopgaver, er ikke et review. I får rækkefølge og anbefalinger; implementeringen kører som et selvstændigt projekt, med os, med en partner eller med jeres eget team. Den, der bagefter vil genopbygge landing zone fra bunden, finder vejen dertil i Azure Foundation.
