Vad ett undantag kostar
En landing zone designas en gång och byggs sedan ut i drift, och det är just där dess egentliga historia börjar. Det första projektet med en hård deadline får sin subscription utanför hierarkin, för att en policy-review skulle ha tagit längre tid än sprinten. Leverantören som en fredagseftermiddag inte kom vidare med Contributor-behörighet tilldelas Owner på Management Group och behåller den, för att ingen tänker på det efter go-live. Och när firewall:en i hubben drar ner genomströmningen för en spoke, får den spoken sitt peering direkt, förbi hubben. Varje sådant beslut var rimligt i stunden, och samtliga gäller fortfarande.
Konsekvenserna är konkreta. En subscription utanför hierarkin ärver ingen policy, så policyn skyddar den inte heller. En Owner på Management Group-nivå ärvs ned till varje subscription under den, även de som inte existerade då. Ett peering utan route till firewall:en är en nätverksstig som ert SOC inte ser. Azure Landing Zone Review lägger designen och nuläget ovanpå varandra, längs de åtta Design Areas i Cloud Adoption Framework, och sorterar avvikelserna efter konsekvens, inte efter ålder.
De åtta Design Areas i Cloud Adoption Framework
Microsoft har delat upp besluten i en landing zone i åtta Design Areas, för att de flesta fel annars gömmer sig i glappen mellan teamen: nätverksteamet bygger hubben, identity-teamet tilldelar roller, och vem som godkände policy-undantaget syns i ingetdera protokollet. Vi går igenom alla åtta, med samma fråga för varje: vad var tänkt, vad är byggt, och vad följer av skillnaden.
Azure Billing och Entra-Tenant
Enrollment, billing-hierarki och den tenant som allt vilar på. En andra tenant från ett förvärv är sällan ett problem, förrän någon ska sammanföra licenser, identiteter och fakturor.
Identity och Access Management
Roller på plattformsnivå, Service Principals och PIM. En Owner på Root Management Group ärvs tyst ned till varje subscription som skapas senare.
Resource Organization
Management Group-hierarki, subscription-design, namn och taggar. Workloads i fel Management Group ärver fel policies, och det märks inte förrän en audit ställer frågan.
Network Topology och Connectivity
Hub-and-Spoke eller Virtual WAN, hybridanslutning, DNS, firewall, Private Endpoints. Ett peering förbi hubben är tekniskt korrekt och osynligt för SOC.
Security
Defender for Cloud, kryptering, Key Vaults och allt som ligger på plattformen snarare än i workloaden. En Defender-plan som är aktiv på en del av subscriptionerna skyddar exakt den delen.
Management
Monitoring, logging, backup och recovery. Saknade Diagnostic Settings syns inte i drift, utan under en incident, när loggarna som aldrig skrevs plötsligt behövs.
Governance
Azure Policy, initiativ, undantag och kostnadskontroll. En exemption har ett utgångsdatum om någon har satt ett. De flesta har inget.
Platform Automation och DevOps
Infrastructure as Code, pipelines, Azure Verified Modules. En plattform som ändras via portalen har två sanningar: den i repositoryt och den i Azure. Det är den andra som gäller.
Så går det till
- Intervjua teametIntervjua teametVi börjar med de personer som driver plattformen, inte med verktyget: arkitektur, verktyg, driftprocesser, strategi. De flesta fynd som en scan senare levererar har en förhistoria, och den som känner till den kan bedöma dem rätt. Ett medvetet beslut är något annat än en bortglömd lösning på hälft.
- Läs av miljönLäs av miljönSedan läser vi av miljön med tooling: Management Groups, policies och exemptions, rolltilldelningar, nätverksstigar, Diagnostic Settings, kostnader. Automatiserat och mot det aktuella läget i Cloud Adoption Framework, inte mot hur det såg ut för tre år sedan.
- Prioritera fyndenPrioritera fyndenVerktyget hittar avvikelsen, intervjun förklarar den, och först tillsammans ger de en prioritet. Överst hamnar det som ärver behörigheter eller blockerar loggar, längst ned det som bryter mot ett namnschema. Ett fynd utan konsekvens är en notering, inte en uppgift.
- Gå igenom rapportenGå igenom rapportenNi får rapporten med mognadsgrad per Design Area, fynd och rekommendationer, och vi går igenom den tillsammans. Inte för att ni ska känna till hundra fynd, utan för att ni på måndag ska veta vilket ni börjar med.
En rapport med prioritetsordning
Ni får en rapport som kartlägger er landing zone utifrån de åtta Design Areas: mognadsgrad per område, prioriterade fynd och rekommendationer som ett plattformsteam kan genomföra utan att fråga oss. Till det en distinktion som ingen scanner klarar: vilken avvikelse från ramverket som var ett beslut och vilken som var ett förbiseende. Den riktar sig till plattformsteam och IT-ledning som har driftat en landing zone i några år och vill veta vad som förändrats sedan dess, i miljön och i ramverket. Den som står inför en migration granskar hellre fundamentet än flytten. Den som tagit över plattformen från en leverantör behöver ett andra par ögon som inte byggt det de bedömer. Genomförandet ingår inte. Det löper som ett eget projekt, med oss, med en partner eller med ert team.
Och sedan
Vanliga frågor innan vi sätter igång
Frågorna från de första samtalen, besvarade på samma sätt som vi gör dem där.
Behöver vi ha en landing zone från glueckkanja?
Nej. Vi granskar vilken landing zone som helst, oavsett om den kommer från Enterprise-Scale-templaten, från en annan leverantör eller har vuxit fram i portalen. Måttstocken är Cloud Adoption Framework, inte vår Azure Foundation. Att vi rekommenderar den när rapporten ger skäl för det är ingen överraskning, men det är heller inget krav.
Vad skiljer reviewen från Modul Azure der Preventive Services?
Frågan som ställs. Modul Azure frågar hur en angripare tar sig från en subscription till kontrollplanet, och mynnar ut i en härdnings-roadmap. Landing Zone Review frågar om plattformen som helhet håller: organisation, nätverk, governance, drift, automatisering, kostnader. Security är där en av åtta Design Areas. Den som vill ha båda börjar med reviewen, eftersom den levererar kartan som modulen sedan ritar vägarna på.
Vilka behörigheter behöver ni?
Läsbehörighet. För analysen räcker en Reader-roll på den översta Management Group, kompletterad med läsrättigheter på Cost Management. Vi ändrar ingenting, och åtkomsten tas bort efter reviewen. Att reviewen går att genomföra med Reader-rättigheter är i sig ett fynd: en landing zone där det inte fungerar har hittat sitt första ämne.
Granskar ni även kostnaderna?
Ja, för i en landing zone har de samma orsaker som governance-fynden. Utan taggar går det inte att koppla en faktura till ett team, utan budget-alerts märks en bortglömd VM först i månadsskiftet, och en reservation som ingen underhåller betalar för kapacitet som ingen använder. Det som uppmärksammas där står i rapporten, med siffra.
Hur lång tid tar reviewen?
Intervju och analys tar några dagar. På er sida kräver det en intervjutid, godkännande av läsrättigheter och ett möte där vi går igenom rapporten. Den mer tidskrävande delen är vad ni sedan gör med listan, och den är er.
Ingår genomförandet?
Nej, och det är ett medvetet val. En review som prioriterar sina egna följduppdrag vore ingen review. Ni får prioritetsordning och rekommendationer, och genomförandet löper som ett eget projekt, med oss, med en partner eller med ert team. Den som vill sätta upp landing zonen på nytt efteråt hittar vägen dit i Azure Foundation.
