Din Azure-hyresgäst är en policydeponi
Ramverk för molnimplementering: Hur hanteringsgrupper åtgärdar säkerhetskaoset ni har tolererat
På sin första dag öppnade Marta Azure-portalen och räknade prenumerationerna som låg direkt under rothanteringsgruppen. Fyrtiosju.
Ingen hierarki. Ingen ärvd policy. Ingen konsekvent RBAC. Säkerhetsvarningar lyser upp Defender for Cloud utan tydlig ägare. Varje team hade provisionerat vad de behövde, när de behövde det, under den som hade ägarrättigheter den veckan.
Arrendatorn hade odlat i tre år. Ingen hade någonsin dragit en gräns i marken och sagt: Så här är det uppbyggt här.
Detta är det vanligaste tillståndet i en mogen Azure-miljö. Inte ett intrång eller en felkonfiguration i en resurs, utan ett strukturellt problem; avsaknaden av den säkerhetsgrund som gör allt annat möjligt.
Ledningsgruppen är inte ett organisationsschema
Det första misstaget de flesta lag gör med Azure-hanteringsgrupper behandlar dem som en återspegling av deras organisationsschema. Finansprenumerationer under en finansgrupp. Marknadsföring under marknadsföring. IT under IT. Ordnat i en bildspel. Oanvändbart för säkerhet.
Ledningsgrupper finns av en anledning: för att ge dig plats att tilldela Azure-policy och RBAC-roller som ärver nedåt till varje prenumeration och resurs under dem. Det innebär att din hierarki bör återspegla säkerhetsställning och anslutningskrav, inte affärsenheter.
Ocuco-landskapet Vägledning för CAF-ledningsgruppen är tydlig: håll hierarkin platt (tre till fyra nivåer är målet) och motstå djupets dragningskraft. En hierarki med sex nivåer existerar som en hård plattformsgräns, och du bör aldrig komma i närheten av den.
”Duplicera inte din organisationsstruktur till en djupt kapslad hanteringsgruppshierarki. Använd hanteringsgrupper för policytilldelning kontra fakturering och RBAC.” – Microsoft CAF, Hanteringsgrupper
Arkitekturen som fungerar
Referensarkitekturen för Azures landningszon definierar en hanteringsgruppsstruktur som har validerats i tusentals företagsdistributioner. Den ser ut så här.
MellanrotLigger direkt under klientorganisationens rot. Alla andra grupper finns här. Isolerar din hierarki från rotgruppen och låter dig flytta befintliga prenumerationer.
plattformInnehåller undergrupperna hantering, anslutning, identitet och säkerhet. Dessa är värdar för de delade infrastrukturprenumerationer som hela organisationen är beroende av.
SäkerhetDedikerad prenumeration för Microsoft Sentinel, syslog-insamlare och SIEM-verktyg. Säkerhetsteamet äger detta. Ingen annan.
VerksamhetsledningenAzure Monitor Logs-arbetsyta, Log Analytics-lösningar och övervakningsinfrastruktur.
AnslutningarAzure-brandvägg, virtuellt WAN, privata DNS-zoner, nätverksgatewayer. Motorvägen som dina arbetsbelastningar kör på.
IdentitetVirtuella AD DS-domänkontrollanter eller Microsoft Entra Domain Services för arbetsbelastningar som kräver traditionell domänanslutning, LDAP eller Kerberos. Organisationer som endast använder Entra ID hoppar vanligtvis över den här gruppen helt.
LandningszonerÖverordnad grupp för alla arbetsbelastningsprenumerationer. Policytilldelningar här gäller för allt som dina team bygger.
CorpArbetsbelastningar som behöver hybridanslutning tillbaka till lokalt via hubben i anslutning.
ONLINEArbetsbelastningar som behöver direkt internetåtkomst, med eller utan ett VNet.
SandlådorIsolerad från Corp och Online. Mindre restriktiv policy. Endast för experiment och utforskning.
AvveckladeLandningszoner väntar på borttagning. Flyttas hit innan Azure tar bort dem om 30–60 dagar.
Detta är inte en teoretisk modell. När den distribueras via Azure Landing Zones Bicep-mallarna får du hierarkin, RBAC-tilldelningarna och den initiala policyuppsättningen i ett enda distributionsflöde.
Politiken flyter nedåt. Det är poängen.
Varje Azure-policy eller policyinitiativ som tilldelas på hanteringsgruppsnivå ärvs av varje prenumeration och resursgrupp under den. Tilldela en policy till din mellanliggande rotgrupp, så gäller den överallt. Tilldela till landningszoner, så gäller den för alla arbetsbelastningsprenumerationer; både företag och online.
Så här upprätthåller du säkerhet i stor skala utan manuella åtgärder. CAF-säkerhetsdesignområde rekommenderar en specifik uppsättning grundläggande policyer för landningszoner online och företagsanslutna:
Du tilldelar dessa en gång i hanteringsgruppen för landningszoner, och varje arbetsbelastningsprenumeration som säljs i Corp eller Online ärver dem automatiskt. Utvecklarteamet som etablerar en ny tjänst får en prenumeration som redan är kompatibel innan de distribuerar sin första resurs.
Grundprincipen: var konservativ.
CAF-riktlinjerna rekommenderar uttryckligen att policytilldelningar begränsas vid rothanteringsgruppen. Att felsöka varför en policy som ärvs från root blockerar en distribution sju lager ner är en miserabel eftermiddag. Tilldela endast de bredaste, mest universella kontrollerna vid root. Allt specifikt hamnar vid landningszoner eller lägre.
RBAC inom ledningsgruppens omfattning: Använd den med omsorg
RBAC-tilldelningar ärver också nedåt. Det innebär att om man tilldelar rollen Medarbetare till ett team på ledningsgruppsnivå får de tillgång till varje prenumeration i den gruppen – och varje prenumeration som läggs till i framtiden.
Det är kraftfullt. Det är också farligt om det missbrukas. rekommendationer från ledningsgruppen är explicita: tilldela inte applikationsteambehörigheter via RBAC på hanteringsgruppsomfång. Ge dem åtkomst på prenumerations- eller resursgruppsnivå – vanligtvis hanteras det via prenumerationsförsäljningsprocessen.
Plattformsteam är undantaget. De behöver ofta åtkomst till olika prenumerationer för att utföra sina jobb. Men även det bör hållas bakom. Microsoft inför Privileged Identity Management (PIM) — just-in-time-åtkomst, inte permanenta stående rättigheter. En plattformsingenjör bör inte ha en permanent ägare på varje prenumeration i hyresgästen eftersom det är bekvämt.
Sandlådor och frestelsen att använda permanenta undantag
Varje landningszonsarkitektur behöver en sandlådegrupp. Sandlådehanteringsgruppen har avsiktligt en mindre restriktiv policyuppsättning, eftersom det är där team experimenterar, utforskar nya Azure-tjänster och bryter saker på ett säkert sätt. Det är dess uppgift.
Felläget är när sandlådan av misstag blir en permanent produktionsmiljö. En prototyp som aldrig flyttades till Corp. En engångspipeline som fortfarande körs i en prenumeration som skulle vara tillfällig. Gruppen Decommissioned existerar av en anledning: prenumerationer som överlever sitt syfte hör hemma där, inte i sandlådor på obestämd tid.
Konfigurera en standardhanteringsgrupp så att nya prenumerationer inte hamnar under rothanteringsgruppen. Alla prenumerationer som hamnar i roten har inget policyarv och ingen definierad RBAC-struktur. Ställ in standardvärdet på sandlådor. Då finns det åtminstone ett staket.
Regionbaserade hierarkier: Gör det inte
Ett av de mest återkommande misstagen vid implementeringar i flera regioner är att bygga ett ledningsgruppsträd som speglar geografisk plats. En Europa-grupp. En Amerika-grupp. En Asien-Stillahavsområdet-grupp. Den ser organiserad ut. Den bekämpar dig i varje steg.
CAF är entydig: skapa inte hanteringsgrupper enbart för att modellera olika Azure-regioner. Ändra inte din hierarki baserat på användning i flera regioner. Det enda undantaget är genuina myndighetskrav; datalagring och datasuveränitet, där du behöver platsbaserade policykontroller. I så fall är en platsbaserad struktur på en specifik nivå i hierarkin försvarbar. Bekvämlighet är inte ett kvalificerande skäl.
Martas andra vecka
I slutet av sin första vecka hade Marta ett förslag på papper: en mellanliggande rotgrupp, plattforms- och landningszoner under den, prenumerationer mappade till Corp eller Online baserat på deras anslutningsbehov, säkerhetsteamets Sentinel-arbetsyta flyttades till en dedikerad säkerhetsprenumeration under Platform.
Vecka två var migrering. Fyrtiosju prenumerationer omorganiserar sig inte själva. Men när strukturen väl var på plats gjorde policyarvet det tunga arbetet. Rekommendationerna från Defender for Cloud slutade vara bullriga och började bli handlingsbara. Nya team fick kompatibla prenumerationer levererade på dag ett. Aviseringarna fick ägare.
Det är vad en välstrukturerad ledningsgruppshierarki ger dig: Grunden för att konsekvent, verkställbar och granskningsbar säkerhet ska bli möjlig. Det kan du inte lägga till i efterhand. Hierarkin måste komma först.
Att få rätt hierarki är den svåraste delen
De flesta organisationer implementerar säkerhetsstyrningen i Cloud Adoption Framework för sent. Efter att prenumerationerna har spridit sig blir policyerna inkonsekventa och RBAC-tilldelningar har spridit sig till något som ingen helt förstår. Att omstrukturera en aktiv hyresgäst är svårare än att bygga den rätt från början, och besluten blir alltmer komplexa: varje ny prenumeration ärver den struktur du har nu, på gott och ont.
Fortytwo arbetar med organisationer vid just denna brytpunkt: Hjälper plattforms- och säkerhetsteam att utforma landningszonsarkitekturer som klarar verklig operativ press, och översätter CAF-principer till distribuerbara Bicep- och policykonfigurationer som fungerar i din specifika miljö. Om din Azure-klient har vuxit snabbare än dess styrning, är det det samtalet du ska ha.
Prata med oss
Ring oss om du vill diskutera dina utmaningar eller frågor.
