Anpassa Arkitekturen för Azure-landningszoner efter behov
Som en del av vägledningen för Azure-landningszonen finns det flera alternativ för referensimplementering:
- Azure-landningszon med Azure Virtual WAN
- Azure-landningszon med traditionell hubb och eker
- Grund för Azure-landningszon
- Azure-landningszon för små företag
De här alternativen kan hjälpa din organisation att komma igång snabbt med hjälp av konfigurationer som levererar konceptuell arkitektur och metodtips för Azure-landningszonen i designområdena.
Referensimplementeringarna baseras på bästa praxis och lärdomar från Microsoft-team från kontakter med kunder och partner. Den här kunskapen representerar "80"-sidan av 80/20-regeln. De olika implementeringarna tar ställning till tekniska beslut som ingår i arkitekturdesignprocessen.
Eftersom inte alla användningsfall är desamma kan inte alla organisationer använda en implementeringsmetod på exakt det sätt som den var avsedd. Du måste förstå övervägandena när ett behov av att skräddarsy identifieras.
Vad är en arketyp för landningszoner i Azure-landningszoner?
En arketyp för landningszoner beskriver vad som måste vara sant för att säkerställa att en landningszon (Azure-prenumeration) uppfyller de förväntade miljö- och efterlevnadskraven i ett specifikt omfång. Exempel:
- Azure Policy-tilldelningar.
- Rollbaserade åtkomstkontrolltilldelningar (RBAC).
- Centralt hanterade resurser, till exempel nätverk.
Överväg att varje hanteringsgrupp i resurshierarkin bidrar till den slutliga utdata för landningszonens arketyp på grund av hur arv av principer fungerar i Azure. Tänk på vad som tillämpas på de övre nivåerna i resurshierarkin när du utformar de lägre nivåerna.
Det finns en nära relation mellan hanteringsgrupper och arketyper för landningszoner, men enbart en hanteringsgrupp är inte en arketyp för landningszonen. I stället utgör den en del av ramverket som används för att implementera var och en av landningszonens arketyper i din miljö.
Du kan se den här relationen i konceptarkitekturen för Azure-landningszonen. Principtilldelningar skapas i den mellanliggande rothanteringsgruppen, till exempel Contoso, för inställningar som måste gälla för alla arbetsbelastningar. Fler principtilldelningar skapas på lägre nivåer i hierarkin för mer specifika krav.
Prenumerationsplacering i hanteringsgruppshierarkin avgör den resulterande uppsättningen med Tilldelningar av Azure Policy och åtkomstkontroll (IAM) som ärvs, tillämpas och tillämpas på den specifika landningszonen (Azure-prenumeration).
Fler processer och verktyg kan krävas för att säkerställa att en landningszon har de centralt hanterade resurser som krävs. Vissa exempel inkluderar:
- Diagnostikinställningar för att skicka aktivitetsloggdata till en Log Analytics-arbetsyta.
- Inställningar för kontinuerlig export för Microsoft Defender för molnet.
- Virtuellt nätverk med hanterade IP-adressutrymmen för programarbetsbelastningar.
- Länkning av virtuella nätverk till ett DDoS-nätverk (Distributed Denial of Service).
Kommentar
I referensimplementeringar för Azure-landningszoner används Azure-principer med DeployIfNotExists effekterna och Modify för att uppnå distributionen av några av de föregående resurserna. De följer principen för principdriven styrningsdesign .
Mer information finns i Använda principdrivna skyddsräcken.
Inbyggda arketyper för konceptarkitekturen i Azure-landningszonen
Den konceptuella arkitekturen innehåller exempel på arketyper för landningszoner för programarbetsbelastningar som corp och online. Dessa arketyper kan gälla för din organisation och uppfylla dina krav. Du kanske vill göra ändringar i dessa arketyper eller skapa nya. Ditt beslut beror på organisationens behov och krav.
Dricks
Information om hur du granskar arketyperna för landningszoner i Azure-landningszonens accelerator finns i Hanteringsgrupper i Azure-landningszonacceleratorn.
Du kanske också vill skapa ändringar någon annanstans i resurshierarkin. När du planerar hierarkin för implementeringen av Azure-landningszoner för din organisation följer du riktlinjerna i designområdena.
Följande exempel på arketyp i landningszonen från den konceptuella arkitekturen hjälper dig att förstå deras syfte och avsedda användning:
| Arketyp för landningszon (hanteringsgrupp) | Syfte eller användning |
|---|---|
| Corp | Den dedikerade hanteringsgruppen för företagslandningszoner. Den här gruppen är avsedd för arbetsbelastningar som kräver anslutning eller hybridanslutning med företagsnätverket via hubben i anslutningsprenumerationen. |
| Online | Den dedikerade hanteringsgruppen för landningszoner online. Den här gruppen är avsedd för arbetsbelastningar som kan kräva direkt internet-inkommande/utgående anslutning eller för arbetsbelastningar som kanske inte kräver ett virtuellt nätverk. |
| Begränsat läge | Den dedikerade hanteringsgruppen för prenumerationer som endast ska användas för testning och utforskning av en organisation. Dessa prenumerationer kopplas från från företagets och online-landningszonerna på ett säkert sätt. Sandbox-miljön har också en mindre restriktiv uppsättning principer som har tilldelats för att aktivera testning, utforskning och konfiguration av Azure-tjänster. |
Scenarier där anpassning kan krävas
Som nämnts tillhandahåller vi vanliga arketyper för landningszoner i konceptuell arkitektur för Azure-landningszoner. De är corp och online. Dessa arketyper är inte fasta och är inte de enda tillåtna arketyperna för landningszoner för programarbetsbelastningar. Du kan behöva skräddarsy arketyper för landningszoner för att passa dina behov och krav.
Innan du skräddarsyr arketyper för landningszoner är det viktigt att förstå begreppen och även visualisera det område i hierarkin som vi föreslår att du anpassar. Följande diagram visar standardhierarkin för den konceptuella arkitekturen för Azure-landningszonen.
Två områden i hierarkin är markerade. Den ena är under landningszoner och den andra under Plattformen.
Skräddarsy arketyper för programlandningszoner
Observera det område som är markerat i blått under hanteringsgruppen Landningszoner . Det är den vanligaste och säkraste platsen i hierarkin att lägga till fler arketyper för att uppfylla nya eller fler krav som inte kan läggas till som fler principtilldelningar till en befintlig arketyp med hjälp av den befintliga hierarkin.
Du kan till exempel ha ett nytt krav på att vara värd för en uppsättning programarbetsbelastningar som måste uppfylla pcI-efterlevnadskrav (payment card industry). Men det här nya kravet behöver inte gälla för alla arbetsbelastningar i hela din egendom.
Det finns ett enkelt och säkert sätt att uppfylla det här nya kravet. Skapa en ny hanteringsgrupp med namnet PCI under hanteringsgruppen Landningszoner i hierarkin. Du kan tilldela fler principer som Initiativet för regelefterlevnad i Microsoft Defender för molnet för PCI v3.2.1:2018 till den nya PCI-hanteringsgruppen. Den här åtgärden utgör en ny arketyp.
Nu kan du placera nya eller flytta befintliga Azure-prenumerationer till den nya PCI-hanteringsgruppen så att den ärver nödvändiga principer och bildar den nya arketypen.
Ett annat exempel är Microsoft Cloud for Sovereignty, som lägger till hanteringsgrupper för konfidentiell beräkning och är anpassat för användning i reglerade branscher. Microsoft Cloud for Sovereignty tillhandahåller verktyg, vägledning och skyddsmekanismer för implementering av offentliga moln med lämpliga suveränitetskontroller.
Dricks
Du behöver veta vad du bör tänka på och vad som händer när du flyttar Azure-prenumerationer mellan hanteringsgrupper i förhållande till RBAC och Azure Policy. Mer information finns i Överföra befintliga Azure-miljöer till den konceptuella arkitekturen i Azure-landningszonen.
Skräddarsy arketyper för plattformslandningszoner
Du kanske också vill skräddarsy det område som är markerat i orange under plattformshanteringsgruppen . Zonerna i det här området kallas plattformslandningszoner.
Du kan till exempel ha ett dedikerat SOC-team som kräver sin egen arketyp som värd för sina arbetsbelastningar. Dessa arbetsbelastningar måste uppfylla kraven för Azure Policy- och RBAC-tilldelningar som skiljer sig från kraven för hanteringsgruppen .
Skapa en ny säkerhetshanteringsgrupp under plattformshanteringsgruppen i hierarkin. Du kan tilldela nödvändiga Azure Policy- och RBAC-tilldelningar till den.
Nu kan du placera nya eller flytta befintliga Azure-prenumerationer till den nya säkerhetshanteringsgruppen så att den ärver nödvändiga principer och bildar den nya arketypen.
Exempel på en skräddarsydd Azure-landningszonhierarki
Följande diagram visar en anpassad Azure-landningszonhierarki. Den använder exempel från föregående diagram.
Några saker att tänka på
Tänk på följande när du tänker på att skräddarsy implementeringen av Arketyper för Azure-landningszoner i hierarkin:
Det är inte obligatoriskt att skräddarsy hierarkin. Standardarketyperna och hierarkin som vi tillhandahåller är lämpliga för de flesta scenarier.
Skapa inte organisationshierarkin, teamen eller avdelningarna på nytt i arketyper.
Försök alltid att bygga vidare på befintliga arketyper och hierarkier för att uppfylla nya krav.
Skapa bara nya arketyper när de verkligen behövs.
Ett nytt efterlevnadskrav som PCI krävs till exempel endast för en delmängd av programarbetsbelastningar och behöver inte gälla för alla arbetsbelastningar.
Skapa endast nya arketyper i de markerade områdena som visas i föregående diagram.
Undvik att gå längre än ett hierarkidjup på fyra lager för att undvika komplexitet och onödiga undantag. Expandera arketyper vågrätt i stället för lodrätt i hierarkin.
Skapa inte arketyper för miljöer som utveckling, testning och produktion.
Mer information finns i Hur hanterar vi landningszoner för utvecklings-/test-/produktionsarbetsbelastningar i den konceptuella arkitekturen för Azure-landningszoner?
Om du kommer från en brownfield-miljö eller letar efter en metod för att vara värd för prenumerationer i hanteringsgruppen för landningszoner med principer i ett "endast granskningsläge" granskar du Scenario: Övergå till en miljö genom att duplicera en hanteringsgrupp för landningszoner