Azure-leietakeren din er et policyfyllingsområde
Rammeverk for skyadopsjon: Hvordan administrasjonsgrupper fikser sikkerhetskaoset dere har tolerert
På sin første dag åpnet Marta Azure-portalen og telte abonnementene som lå direkte under rotadministrasjonsgruppen. Førtisju.
Ingen hierarki. Ingen arvet policy. Ingen konsistent RBAC. Sikkerhetsvarsler lyser opp Defender for Cloud uten en klar eier. Hvert team hadde klargjort det de trengte, når de trengte det, under den som hadde eierrettigheter den uken.
Leietakeren hadde drevet med dyrking i tre år. Ingen hadde noen gang trukket en grense i bakken og sagt: Slik er ting strukturert her.
Dette er den vanligste tilstanden i et modent Azure-miljø. Ikke et sikkerhetsbrudd eller en feilkonfigurasjon i én ressurs, men et strukturelt problem; fraværet av sikkerhetsfundamentet som gjør alt annet mulig.
Ledergruppen er ikke et organisasjonskart
Den første feilen de fleste lag gjør med Azure-administrasjonsgrupper behandler dem som en refleksjon av organisasjonskartet deres. Finansabonnementer under en finansgruppe. Markedsføring under markedsføring. IT under IT. Ryddig på en lysbildesamling. Ubrukelig for sikkerhet.
Administrasjonsgrupper finnes av én grunn: for å gi deg plass til å tildele Azure-policy og RBAC-roller som arver nedover til hvert abonnement og hver ressurs under dem. Det betyr at hierarkiet ditt bør gjenspeile sikkerhetstilstand og tilkoblingskrav, ikke forretningsenheter.
Ocuco Veiledning for CAF-ledelsesgruppen er klart: hold hierarkiet flatt (tre til fire nivåer er målet), og motstå dybdens tiltrekning. Et hierarki på seks nivåer eksisterer som en hard plattformgrense, og du bør aldri komme i nærheten av det.
«Ikke dupliser organisasjonsstrukturen din til et dypt innebygd hierarki for administrasjonsgrupper. Bruk administrasjonsgrupper til policytildeling kontra fakturering og RBAC-formål.» – Microsoft CAF, Administrasjonsgrupper
Arkitekturen som fungerer
Referansearkitekturen for Azure-landingssonen definerer en administrasjonsgruppestruktur som har blitt validert på tvers av tusenvis av bedriftsdistribusjoner. Den ser slik ut.
MellomrotLigger rett under leietakerroten. Alle andre grupper ligger her. Isolerer hierarkiet ditt fra rotgruppen og lar deg flytte eksisterende abonnementer inn.
PlattformInneholder undergrupper for administrasjon, tilkobling, identitet og sikkerhet. Disse er vert for abonnementene på delt infrastruktur som hele organisasjonen er avhengig av.
TrygghetDedikert abonnement for Microsoft Sentinel, syslog-samlere og SIEM-verktøy. Sikkerhetsteamet eier dette. Ingen andre.
AdministrasjonAzure Monitor Logs-arbeidsområde, Log Analytics-løsninger og overvåkingsinfrastruktur.
TilkoblingAzure-brannmur, virtuelle WAN-nettverk, private DNS-soner, nettverksgatewayer. Motorveien arbeidsbelastningene dine kjører på.
IdentitetVirtuelle AD DS-domenekontrollere eller Microsoft Entra Domain Services for arbeidsbelastninger som krever tradisjonell domenetilslutning, LDAP eller Kerberos. Organisasjoner som kun bruker Entra ID, hopper vanligvis over denne gruppen helt.
LandingssonerOverordnet gruppe for alle arbeidsbelastningsabonnementer. Policytildelinger her gjelder for alt teamene dine bygger.
CorpArbeidsbelastninger som trenger hybrid tilkobling tilbake til lokale enheter via huben i Tilkobling.
på nettArbeidsbelastninger som trenger direkte internettilgang, med eller uten et VNet.
SandkasserIsolert fra Corp og Online. Mindre restriktiv policy. Kun for eksperimentering og utforskning.
AvvikletLandingssoner venter på sletting. Flyttes hit før Azure fjerner dem om 30–60 dager.
Dette er ikke en teoretisk modell. Når den distribueres via Azure Landing Zones Bicep-malene, får du hierarkiet, RBAC-tildelingene og det første policysettet i én enkelt distribusjonsflyt.
Politikken flyter nedover. Det er poenget.
Hver Azure-policy eller policyinitiativ som er tilordnet på administrasjonsgruppenivå, arves av hvert abonnement og hver ressursgruppe under den. Tilordne en policy til den mellomliggende rotgruppen, og den gjelder overalt. Tilordne til landingssoner, og den gjelder for alle arbeidsbelastningsabonnementer; både Corp og Online.
Slik håndhever du sikkerhet i stor skala uten manuell inngripen. CAF sikkerhetsdesignområde anbefaler et spesifikt sett med grunnleggende retningslinjer for landingssoner på nett og i bedriftstilkoblede områder:
Du tilordner disse én gang i administrasjonsgruppen for landingssoner, og hvert arbeidsbelastningsabonnement som selges til Corp eller Online arver dem automatisk. Utviklerteamet som klargjør en ny tjeneste får et abonnement som allerede er kompatibelt før de distribuerer sin første ressurs.
Politikk i bunn og grunn: vær konservativ.
CAF-veiledningen anbefaler eksplisitt å begrense policytildelinger ved rotadministrasjonsgruppen. Det er en elendig ettermiddag å feilsøke hvorfor en policy arvet fra roten blokkerer en distribusjon syv lag ned. Tildel bare de bredeste og mest universelle kontrollene ved roten. Alt spesifikt går til landingssoner eller lavere.
RBAC i ledelsesgruppens omfang: Bruk det med omhu
RBAC-tildelinger arver også nedover. Det betyr at det å tildele bidragsyterrollen til et team på ledergruppenivå gir dem tilgang til alle abonnementer i den gruppen – og alle abonnementer som legges til i fremtiden.
Det er kraftig. Det er også farlig hvis det brukes feil. anbefalinger fra ledergruppen er eksplisitte: ikke tildel applikasjonsteamtillatelser via RBAC på administrasjonsgruppenivå. Gi dem tilgang på abonnements- eller ressursgruppenivå – vanligvis håndtert gjennom abonnementssalgsprosessen.
Plattformteam er unntaket. De trenger ofte tilgang til kryssabonnement for å gjøre jobben sin. Men selv det bør lukkes bak Microsoft går inn i Privileged Identity Management (PIM) — ATT-tilgang, ikke permanente rettigheter. En plattformingeniør bør ikke ha en permanent eier på alle abonnementer i leietakeren fordi det er praktisk.
Sandkasser og fristelsen til permanente unntak
Alle landingssonearkitekturer trenger en sandkassegruppe. Sandkasseadministrasjonsgruppen har bevisst et mindre restriktivt policysett, ettersom det er der team eksperimenterer, utforsker nye Azure-tjenester og bryter ting trygt. Det er jobben deres.
Feilmodusen er når sandkassen ved et uhell blir et permanent produksjonsmiljø. En prototype som aldri ble flyttet til Corp. En engangs pipeline som fortsatt kjører i et abonnement som skulle være midlertidig. Decommissioned-gruppen eksisterer av en grunn: abonnementer som overlever formålet sitt, hører hjemme der, ikke i sandkasser på ubestemt tid.
Konfigurer en standard administrasjonsgruppe slik at nye abonnementer ikke havner under rotadministrasjonsgruppen. Ethvert abonnement som havner på roten har ingen policyarv og ingen definert RBAC-struktur. Sett standardinnstillingen til sandkasser. Da er det i det minste et gjerde.
Regionbaserte hierarkier: Ikke gjør det
En av de mest vedvarende feilene i flerregionsdistribusjoner er å bygge et administrasjonsgruppetre som speiler geografien. En Europa-gruppe. En Amerika-gruppe. En APAC-gruppe. Den ser organisert ut. Den kjemper mot deg på alle måter.
CAF-en er entydig: ikke opprett administrasjonsgrupper utelukkende for å modellere forskjellige Azure-regioner. Ikke endre hierarkiet ditt basert på bruk i flere regioner. Det eneste unntaket er ekte regulatoriske krav; dataopphold og datasuverenitet, der du trenger stedsbaserte policykontroller. I så fall er en stedsbasert struktur på et bestemt nivå i hierarkiet forsvarlig. Bekvemmelighet er ikke en kvalifiserende grunn.
Martas andre uke
Ved slutten av den første uken hadde Marta et forslag på papiret: en mellomliggende rotgruppe, plattform- og landingssoner under den, abonnementer tilordnet Corp eller Online basert på deres tilkoblingsbehov, sikkerhetsteamets Sentinel-arbeidsområde flyttet til et dedikert sikkerhetsabonnement under Platform.
Uke to var migrering. Førtisju abonnementer omorganiserer seg ikke selv. Men når strukturen var på plass, gjorde policyarven det tunge arbeidet. Anbefalingene fra Defender for Cloud sluttet å være støyende og begynte å bli handlingsrettede. Nye team fikk solgt kompatible abonnementer på dag én. Varslene fikk eiere.
Det er hva et velstrukturert hierarki i en administrasjonsgruppe gir deg: Fundamentet som gjør konsistent, håndhevbar og reviderbar sikkerhet mulig. Du kan ikke legge til det etterpå. Hierarkiet må komme først.
Å få riktig hierarkium er den vanskeligste delen
De fleste organisasjoner implementerer sikkerhetsstyringen i Cloud Adoption Framework for sent. Etter at abonnementene har spredt seg, er retningslinjene inkonsekvente, og RBAC-tildelinger har spredt seg til noe ingen helt forstår. Å restrukturere en aktiv leier er vanskeligere enn å bygge den riktig fra starten av, og beslutningene blir mer komplekse: hvert nytt abonnement arver den strukturen du har nå, på godt og vondt.
Fortytwo jobber med organisasjoner på akkurat dette vendepunktet: Hjelper plattform- og sikkerhetsteam med å designe landingssonearkitekturer som tåler reelt driftspress, og oversetter CAF-prinsipper til distribuerbare Bicep- og policykonfigurasjoner som fungerer i ditt spesifikke miljø. Hvis Azure-leietakeren din har vokst raskere enn styringen, er det samtalen du bør ha.
Snakk med oss
Ring oss hvis du ønsker å diskutere dine utfordringer eller spørsmål.
