Hva et unntak koster
En Landing Zone designes én gang og utvides deretter i drift, og det er akkurat der den egentlige historien begynner. Det første prosjektet med en hard deadline får sin subscription utenfor hierarkiet, fordi en policy-review ville tatt lenger tid enn sprinten. Leverandøren som ikke kom videre med Contributor-rettigheter en fredagsettermiddag, får Owner på Management Group og beholder det, fordi ingen tenker på det etter go-live. Og når Firewall-en i Hub-en begrenser gjennomstrømmingen til en Spoke, får Spoke-en sitt peering direkte, utenom Hub-en. Hver av disse beslutningene var fornuftig i øyeblikket, og alle er fortsatt i kraft.
Konsekvensene er konkrete. En subscription utenfor hierarkiet arver ingen policy, og da beskytter ikke policyen den heller. En Owner på Management Group-nivå arves ned til alle subscriptions under, også de som ikke fantes den gangen. Et peering uten rute til Firewall-en er en nettverksvei SOC-en din ikke ser. Azure Landing Zone Review legger designet og nåsituasjonen oppå hverandre, langs de åtte Design Areas i Cloud Adoption Framework, og sorterer avvikene etter konsekvens, ikke etter alder.
De åtte Design Areas i Cloud Adoption Framework
Microsoft har delt beslutningene i en Landing Zone inn i åtte Design Areas, fordi de fleste feil ellers gjemmer seg i sprekkene mellom teamene: Nettverksteamet bygger Hub-en, Identity-teamet tildeler rollene, og hvem som godkjente policy-unntaket, fremgår ikke av noen av protokollene. Vi går gjennom alle åtte, med det samme spørsmålet til hver: Hva var tiltenkt, hva er bygget, og hva følger av forskjellen.
Azure Billing og Entra ID-tenant
Enrollment, billing-hierarki og tenanten alt kjører på. En ekstra tenant fra en oppkjøp er sjelden et problem, helt til noen må slå sammen lisenser, identiteter og fakturaer.
Identity og Access Management
Roller på plattformnivå, Service Principals og PIM. En Owner på Root Management Group arves lydløst ned til alle subscriptions som opprettes senere.
Resource Organization
Management Group-hierarki, subscription-design, navn og tags. Workloads i feil Management Group arver feil policies, og det oppdages først når et audit stiller spørsmål.
Network Topology og Connectivity
Hub-and-Spoke eller Virtual WAN, hybridtilkobling, DNS, Firewall, Private Endpoints. Et peering utenom Hub-en er teknisk korrekt og usynlig for SOC.
Security
Defender for Cloud, kryptering, Key Vaults og alt som ligger på plattformen fremfor i workload. En Defender-plan som er aktiv på en del av subscriptions, beskytter nøyaktig den delen.
Management
Monitoring, logging, backup og recovery. Manglende Diagnostic Settings oppdages ikke i drift, men under en incident, når loggene som aldri ble skrevet, plutselig trengs.
Governance
Azure Policy, initiativer, unntak og kostnadskontroll. En exemption har en utløpsdato hvis noen har satt en. De fleste har ingen.
Platform Automation og DevOps
Infrastructure as Code, pipelines, Azure Verified Modules. En plattform som endres via portalen, har to sannheter: den i repositoryet og den i Azure. Det er den siste som gjelder.
Slik foregår det
- Intervjue teametIntervjue teametVi starter med menneskene som drifter plattformen, ikke med verktøyet: arkitektur, verktøy, driftsprosesser, strategi. De fleste funnene et scan leverer senere, har en forhistorie, og den som kjenner den, vurderer dem riktig. En bevisst beslutning er noe annet enn et glemt provisorium.
- Lese ut miljøetLese ut miljøetDeretter leser vi ut miljøet med Tooling: Management Groups, Policies og Exemptions, rolletildelinger, nettverksstier, Diagnostic Settings, kostnader. Automatisert og mot gjeldende versjon av Cloud Adoption Framework, ikke den fra for tre år siden.
- Sortere funneneSortere funneneVerktøyet finner avviket, intervjuet forklarer det, og først begge to tilsammen gir en prioritet. Øverst står det som arver rettigheter eller hindrer logging, nederst det som bryter et navneskjema. Et funn uten konsekvens er et notat, ikke et oppdrag.
- Gjennomgå rapportenGjennomgå rapportenDere får rapporten med modenhetsnivå per Design Area, funn og anbefalinger, og vi går gjennom den sammen. Ikke for at dere skal kjenne til hundre funn, men for at dere mandag morgen skal vite hvilket dere begynner med.
En rapport med rekkefølge
Dere får en rapport som plasserer Landing Zone-en deres langs de åtte Design Areas: modenhetsnivå per område, prioriterte funn og anbefalinger et plattformteam kan gjennomføre uten å spørre oss. I tillegg får dere det skillet ingen scanner klarer å gjøre: hvilke avvik fra rammeverket som var en beslutning, og hvilke som var en glipp. Rapporten er beregnet for plattformteam og IT-ledelse som har driftet en Landing Zone i noen år og vil vite hva som har endret seg siden, i miljøet og i rammeverket. Den som står foran en migrasjon, gjør lurt i å sjekke fundamentet før selve flyttingen. Den som har overtatt plattformen fra en leverandør, trenger et annet sett øyne som ikke har bygget det de vurderer. Gjennomføringen er ikke inkludert. Den kjøres som et eget prosjekt, med oss, med en partner eller med teamet deres.
Og deretter
Spørsmål vi får på forhånd
Spørsmålene fra de første samtalene, besvart slik vi besvarer dem der.
Trenger vi en Landing Zone fra glueckkanja for dette?
Nei. Vi gjennomgår enhver Landing Zone, enten den er bygget fra Enterprise-Scale-templaten, levert av en annen leverandør eller vokst frem i portalen. Målestokken er Cloud Adoption Framework, ikke vår Azure Foundation. At vi anbefaler den hvis rapporten gir grunnlag for det, er ingen overraskelse, men heller ingen forutsetning.
Hva skiller review-en fra Modul Azure i Preventive Services?
Spørsmålet som stilles. Modul Azure spør hvordan en angriper kommer seg fra en subscription til kontrollplanet, og ender i en herdings-roadmap. Landing Zone Review spør om plattformen som helhet holder: organisering, nettverk, Governance, drift, automatisering, kostnader. Security er én av åtte Design Areas. Den som vil ha begge deler, begynner med review-en, fordi den leverer kartet modulet tegner veiene inn på.
Hvilke rettigheter trenger dere?
Leserettigheter. For analysen er en Reader-rolle på øverste Management Group tilstrekkelig, supplert med leserettigheter på Cost Management. Vi endrer ingenting, og tilgangene fjernes etter review-en. At review-en lar seg gjennomføre med Reader-rettigheter, er i seg selv et funn: en Landing Zone der det ikke er mulig, har allerede funnet sitt første tema.
Ser dere også på kostnadene?
Ja, fordi de i en Landing Zone har de samme årsakene som Governance-funnene. Uten tags kan ikke en faktura tilordnes noe team, uten Budget-Alerts oppdages en glemt VM først ved månedsslutt, og en reservering ingen vedlikeholder, betaler for kapasitet ingen bruker. Det som dukker opp der, står i rapporten, med tall.
Hvor lang tid tar review-en?
Intervju og analyse tar noen få dager. På deres side krever det ett intervjumøte, tilgang til leserettigheter og møtet der vi går gjennom rapporten. Den mest tidkrevende delen er det dere gjør med listen etterpå, og den tilhører dere.
Er gjennomføringen inkludert?
Nei, og det er tilsiktet. En review som prioriterer sine egne oppfølgingsoppdrag, er ingen review. Dere får rekkefølge og anbefalinger; gjennomføringen kjøres som et eget prosjekt, med oss, med en partner eller med teamet deres. Den som ønsker å sette opp Landing Zone-en på nytt etterpå, finner veien dit i Azure Foundation.
