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 Modifyfö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.
Sandbox-miljö	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 Microsoft Defender för molnet regelefterlevnadsprincip 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