Anpassa Arkitekturen för Azure-landningszoner efter behov
Som en del av vägledningen för Azure-landningszon finns det flera referensimplementeringsalternativ :
- Azure-landningszon med Azure Virtual WAN
- Azure-landningszon med traditionell hubb-och-ekermodell
- 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 landningszonsarketyp 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 inom ett specifikt omfång. Exempel är:
- Azure Policy-tilldelningar.
- Rollbaserade åtkomstkontrolltilldelningar (RBAC).
- Centralt hanterade resurser, till exempel nätverk.
Betrakta varje hanteringsgrupp i resurshierarkin som bidragande till det slutgiltiga resultatet för landningszonens arketyp på grund av hur principarv 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 Contosofö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.
Prenumerationens placering inom hanteringsgruppshierarkin avgör den resulterande uppsättningen av tilldelningar av Azure Policy och åtkomstkontroll (IAM) som ärvs, tillämpas och verkställs för den specifika landningszonen (Azure subscription).
Fler processer och verktyg kan krävas för att säkerställa att en landningszon har de centralt hanterade resurser som krävs. Några exempel är:
- 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 nätverksskydd mot distribuerade överbelastningsattacker (DDoS-skydd).
Anteckning
I referensimplementeringar för Azure-landningszoner används Azure-policyer med DeployIfNotExists och Modify-effekter för att distribuera några av de föregående resurserna. De följer principdriven styrning designprincip.
För mer information, se Anta policybaserade 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.
Tips
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 din implementering av Azure-landningszoner för din organisation följer du riktlinjerna i designområden.
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 |
|---|---|
| Koncern | 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. |
| Sandlåda | 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 landningszoneroch den andra under Platform.
Skräddarsy arketyper för programlandningszoner
Observera det område som är markerat i blått under hanteringsgruppen för landningszoner. Det är den vanligaste och säkraste platsen i hierarkin för 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 arbetslaster som måste uppfylla PCI-efterlevnadskrav (betalningskortsindustrin). 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 microsoft defender för moln regelefterlevnad principinitiativ 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- hanteringsgrupp så att den ärver de principer som krävs 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 anpassad för användning i reglerade branscher. Microsoft Cloud for Sovereignty tillhandahåller verktyg, vägledning och skyddsräcken för implementering av offentliga moln med lämpliga suveränitetskontroller.
Tips
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 hanteringsgruppen Platform. Zonerna i det här området kallas plattformslandningszoner.
Du kan till exempel ha ett dedikerat SOC-team som kräver sin egen modell för att hantera sina arbetsbelastningar. Dessa arbetsbelastningar måste uppfylla azure policy- och RBAC-tilldelningskrav som skiljer sig från kraven för hanteringsgruppen Management.
Skapa en ny hanteringsgrupp för Security under hanteringsgruppen Platform 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 hanteringsgruppen Security så att den ärver de principer som krävs 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.
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 konceptarkitekturen för Azure-landningszoner?
Om du kommer från en brownfield-miljö eller letar efter en metod för att konfigurera prenumerationer i hanteringsgrupp för landningszoner med principer i "endast för granskning"-läge, granska Scenario: Övergå till en miljö genom att duplicera en hanteringsgrupp för landningszoner