Azure Policy – En grunnleggende innføring

Introduksjon

Mange organisasjoner opplever at skymiljøet deres blir mer og mer uoversiktlig etter hvert som flere team får tilgang til å opprette og konfigurere ressurser. Uten tydelige retningslinjer og automatisert håndhevelse av standarder kan dette føre til sikkerhetsrisikoer, uforutsigbare kostnader og operasjonelle utfordringer.

I denne artikkelen skal vi se på Azure Policy – et innebygd styringsverktøy som kan hjelpe deg med å få overordnet kontroll. Målet er å gi deg en praktisk innføring i hva Azure Policy er, hvordan det fungerer, og ikke minst – om det er det rette verktøyet for din organisasjon.

Vi går gjennom de viktigste konseptene, fordeler og ulemper, samt konkrete eksempler på hvordan policies påvirker både nye og eksisterende ressurser.

Etter å ha lest artikkelen skal du kunne vurdere om Azure Policy kan løse dine styringsutfordringer, og ha en god forståelse av hva implementering innebærer.

Hva er Azure Policy?

Azure Policy er et kraftig styringsverktøy som er innebygd i alle Azure Tenants.

Med Azure Policy kan du sikre at alle ressurser i skyen din følger virksomhetens krav til konfigurasjon, sikkerhet og samsvar.

Hvem trenger Azure Policy?

Azure Policy er essensielt hvis du:

• Har flere utviklingsteam som oppretter ressurser, og trenger konsistente standarder - uten å bremse innovasjon.
• Ønsker å sikre riktig tagging for alle ressurser slik at kostnader kan spores, men kan ikke stole på at alle husker dette manuelt.
• Må dokumentere samsvar med reguleringer (sikkerhetslogging, kryptering, dataoppbevaring) for revisorer eller tilsynsmyndigheter.
• Ser "kreative" unntak og omgåelser som bryter standarder på grunn av manglende håndhevelse.
• Vil unngå operasjonelle overraskelser, som utilsiktet sletting av kritiske ressurser, offentlig eksponering av tjenester, eller glemte sikkerhetskopier.
• Trenger sanntidsoversikt over samsvar og en måte å følge opp avvik på tvers av hele plattformen.

Eksempler:

• Sentralisert logging:
  Håndhev og overvåk at alle ressurser videresender logger til en sentral loggløsning automatisk.

• Tagging og kostnadskontroll:
  Forhindre opprettelse av ressurser uten riktige tagger, eller varsle når tagger mangler.

• Beskyttelse mot utilsiktede endringer:
  Forhindre at kritiske komponenter blir slettet eller endret ved en feil -- selv om brukere har høy autonomitet

• Regulatorisk samsvar:
  Overvåk og håndhev kryptering, sikkerhetskopier, regional plassering, nettverkskonfigurasjon mm.

Azure Policy: Fordeler og ulemper

Fordeler:

• Tilgjengelig ut av boksen:
  Innebygd i alle Azure tenant--ingen ekstra installasjon nødvendig.

• Skalerer utrolig godt:
  Håndhev krav på tvers av hele organisasjonen, uansett antall ressurser eller team.

• Gratis å bruke:
  Ingen ekstra lisenspris for policy-motoren.

• Fungerer uansett hvordan man deployer og konfigurerer ressurser:
  Gjelder uansett om ressurser deployes og konfigureres med ARM, Bicep, Terraform, Azure Portal eller CLI.

• Gir et fugleperspektiv:
  Se samsvar på tvers av alle ressurser i din tenant.

• Detaljert innsikt:
  Drill ned til landing zone, resource group eller individuell ressurs for detaljert kontroll.

• Revidering, håndhevelse og automatisering:
  Bruk policy til å revidere, håndheve eller til og med automatisk utbedre problemer.

• Muliggjør massive utbedringer på tvers av hele tenant:
  Korriger storskala avvik i ett trinn, uten å endre alle pipelines eller maler.

Ulemper:

• Kompleks å sette opp og forstå:
  Å skrive effektive policies og forstå deres innvirkning kan være utfordrende.

• Risiko for forstyrrelser ved feilkonfigurering:
  Feilkonfigurerte policies kan blokkere kritiske deployments eller endringer, og forårsake nedetid, forsinkelser og frustrasjon.

• Kan komme i konflikt med deklarativ kode (som Terraform):
  Policy-drevne endringer kan forårsake state drift.

• Driftskostnad:
  Azure Policy krever løpende vedlikehold, oppdatering og utvikling ettersom skymiljøer og krav utvikler seg. Det er ingen direkte kostnader forbundet med azure policy i seg selv, men det er viktig å sette av tid og ressurser til å jobbe aktivt med det.

Alt går gjennom ARM API

Uansett hvordan du oppretter eller endrer ressurser i Azure -- om det er via portalen, Azure CLI, PowerShell, Terraform, Bicep eller andre verktøy - alt ender opp som en forespørsel til Azure Resource Manager (ARM) API.

Det er dette API-et som "styrer" alt av ressurser i Azure.

• Azure Policy er en integrert del av ARM API og evaluerer alle forespørsler som går gjennom den.
• Dette gjør at reglene dine gjelder uansett hvilket verktøy eller metode du bruker.

Hvorfor er dette viktig for deg?

Dette betyr at du får konsistent håndhevelse av policies på tvers av alle verktøy og metoder. Team kan fritt velge sine foretrukne arbeidsverktøy – portalen, CLI, Terraform, eller andre løsninger – uten at det påvirker hvordan policyene evalueres. Du slipper å bekymre deg for at standarder kan bli utilsiktet omgått gjennom ulike arbeidsflyter, og kan stole på at reglene gjelder likt for alle, uansett teknisk tilnærming.

Hva dekker Azure Policy – og hva dekker det ikke?

Azure Policy gjelder kun for Azure-ressurser og ressurscontainere, altså alt som styres via ARM API:
virtuelle maskiner, lagring, nettverk, subscriptions, ressursgrupper, og til og med rolle-tildelinger (RBAC) som er knyttet til ressurser.

Azure Policy gjelder derimot ikke for identiteter, brukere og grupper i Entra ID (tidligere Azure AD).
Alt som håndteres via Microsoft Graph API – som brukere, grupper, roller og administrative rettigheter i Entra – omfattes ikke av Azure Policy.

Hvorfor er dette skillet viktig å forstå?

Dette påvirker hvordan du designer din overordnede styringsarkitektur. For ressursrelatert styring (sikkerhetskonfigurasjon, tagging, regional plassering) er Azure Policy det rette verktøyet. Men for bruker- og identitetsstyring (hvem som får tilgang til hva, administrative roller, brukerlivssyklus) må du bruke andre verktøy som Conditional Access, Privileged Identity Management, eller Identity Governance (identitetssikkerhet). Å forstå dette skillet hjelper deg med å velge riktig verktøy for riktig formål.

Eksempel:

• En rolle-tildeling på en storage account kan evalueres av Azure Policy
• En administratorrolle til en bruker i Entra ID kan ikke evalueres av Azure Policy

Policy-evaluering og compliance

Når du gjør en endring på en ressurs, skjer følgende rekkefølge:

1. Authentication – Valider brukerens identitet
2. Authorization – Har brukeren rettigheter nok til å gjennomføre endingen?
3. Policy evaluation – Er handlingen lov i henhold til gjeldende policyer?

Policyene har ulike effects, de mest brukte er:

• Deny: Blokkér handlingen

• Audit: Loggfør avvik

• Append/Modify: Legg til eller endre egenskaper

• DeployIfNotExists: Opprett eller konfigurer manglende ressurs

• AuditIfNotExists: Loggfør avvik hvis en gitt ressurs IKKE finnes

Hvorfor er det viktig å forstå dette?

Når du implementerer Azure Policy, må du forstå at policies evalueres hver gang noen prøver å gjøre endringer - ikke bare når du deployer dem første gang.

Dette påvirker brukeropplevelsen og kan potensielt blokkere kritisk arbeid hvis du ikke har planlagt godt nok. Ved å forstå de ulike effektene kan du velge riktig tilnærming: streng håndhevelse der det er kritisk, eller kun logging der du trenger synlighet først.

I tillegg til å evalueres når en request kommer inn til ARM APIet, kjører Azure Policy compliance-skanning daglig og kan også trigges manuelt.

Dette gjør at du alltid har oversikt over om ressursene er i samsvar med policyene:

Policy-struktur: Policy, Initiative, Assignment, Exemption

Azure Policy er bygd opp av fire hovedelementer:

1. Policy Definition – En enkelt regel skrevet i JSON (f.eks. “Alle lagringskontoer skal være kryptert”)
2. Initiative Definition – En samling av flere policyer, samlet under ett formål (f.eks. “Storage Baseline”)
3. Assignment – Selve tilordningen: policy(er) eller initiative(r) aktivert på et valgt nivå (scope)
4. Exemption – Unntak fra policy eller initiative for spesifikke ressurser

Dette gir fleksibel og strukturert styring, fra enkeltregler til omfattende samlinger som dekker hele områder (f.eks. sikkerhetskrav for all lagring).

Arv og overordnet styring

• Policy assignments arves nedover i hierarkiet: Setter du en policy på management group-nivå, gjelder den automatisk for alle subscriptions og ressursgrupper under.
• Dette gjør det mulig å sette brede, virksomhetskritiske krav én gang – og være sikker på at de gjelder overalt, uansett lokale rettigheter.
• Best practice: Bruk management group for brede “guardrails”, og detaljerte policyer lenger ned kun der det er nødvendig.
• Team og eiere får fleksibilitet, men kan aldri omgå overordnede policyer.

Hvorfor er denne strukturen viktig?

Oppdelingen gjør at du kan skalere styringen på en håndterbar måte. I stedet for å administrere hundrevis av individuelle policy-assignments, kan du gruppere relaterte regler i initiatives og tilordne hele pakker på én gang.

Assignments lar deg kontrollere hvor reglene gjelder (hele organisasjonen vs. spesifikke team), mens exemptions gir deg en kontrollert måte å håndtere legitime unntak uten å undergrave hele styringsmodellen.

Spesielt viktig: Når du tilordner policies på management group-nivå, kan ikke engang subscription-eiere overstyre dem. Dette gjør det mulig å gi team høy grad av autonomi innenfor trygge rammer.

Pris og kostnadsforståelse

Azure Policy er en innebygd og gratis funksjon i Azure – det koster ingenting å definere, tilordne eller evaluere policyer. Du kan med andre ord bruke Azure Policy på tvers av hele miljøet ditt uten direkte kostnader. Men det er viktig å være klar over at enkelte policyhandlinger kan utløse indirekte kostnader, avhengig av hva policyene faktisk gjør:

• Eksempel uten kostnad:
  En policy som krever at alle storage accounts har TLS 1.2 aktivert og nekter bruk av SAS-nøkler vil ikke medføre ekstra utgifter, uansett hvor mange ressurser du har.
• Eksempel med indirekte kostnad:
  En policy som automatisk setter opp diagnostic settings på alle storage accounts vil føre til kostnader knyttet til logginnsamling og lagring, basert på mengden data som sendes til for eksempel Log Analytics eller en Event Hub.
• Automatisk ressursopprettelse:
  Policyer som automatisk oppretter nye ressurser (for eksempel via DeployIfNotExists) vil utløse de vanlige kostnadene for bruk av de ressursene som blir opprettet.

Det er derfor lurt å vurdere konsekvensene av policyene, spesielt i store miljøer, slik at du har kontroll på eventuelle kostnader som kan oppstå indirekte gjennom policy-handlinger.

Policy effects: Hvordan påvirker dette nye og eksisterende ressurser?

Hvorfor er det viktig å forstå dette?

Når du implementerer Azure Policy, må du vite nøyaktig hvilken påvirkning det har på miljøet. Mange blir overrasket over at eksisterende "non-compliant" ressurser fortsatt fungerer, eller forvirret over hvorfor noen endringer blokkeres mens andre går gjennom. Å forstå disse mekanismene hjelper deg med å forutse brukeropplevelsen og planlegge implementeringen riktig.

Eksempel: Når du bruker en policy med effekten Deny, vil Azure Policy blokkere opprettelse av nye ressurser som ikke oppfyller kravene dine.
For eksisterende ressurser som ikke er i samsvar (“noncompliant”), vil policyen ikke slette eller automatisk endre dem. Disse vises i stedet som ikke-kompatible (noncompliant) i compliance-rapporteringen.

Hva skjer hvis noen prøver å endre en eksisterende ressurs som ikke er compliant?

Hvis endringen ikke får ressursen til å oppfylle policykravene, vil handlingen bli blokkert.

Eksempel med DENY policy

Dersom du har en policy som sier “Alle storage accounts må ha TLS 1.2”, kan du ikke opprette en ny storage account uten TLS 1.2.

Hvis en eldre storage account fortsatt bruker TLS 1.1, vil den vises som noncompliant:

La oss prøve å gjøre en endring på denne ressursen, som er urelatert til TLS versjon:

Dette vil feile, fordi vi effektivt sender en forespørsel til API’et der vi fortsatt har TLS 1.1 satt:

La oss prøve å gjøre den samme endringen, men samtidig oppdatere TLS versjon til å være compliant med policykrav:

Dette går bra, fordi forespørselen til API’et nå spesifiserer TLS 1.2, og er compliant:

Men – her finnes det noen nyanser:

I Azure består en “ressurs” i portalen ofte av flere sammenkoblede deler. Noen av disse delene kalles extension resources – for eksempel rolle-tildelinger (role assignments), diagnostic settings, blobs, køer og tabeller. Disse er egne ressurser som “henger på” en hovedressurs, som en storage account.

• Viktig:
  Policyen gjelder som regel for hovedressursen, ikke extension resources.
  Det betyr at selv om en storage account er noncompliant, kan du ofte fortsatt legge til eller endre extension resources (for eksempel legge til en rolle eller endre diagnostic settings), fordi dette teknisk sett er en endring på en “underdel”, ikke hovedressursen selv.

Dette kan være forvirrende i portalen, fordi du ser alt som “en ressurs”, men i virkeligheten er det flere forskjellige objekter bak kulissene, som har en relasjon seg imellom.

Når du jobber med infrastruktur som kode (for eksempel Bicep eller Terraform), er dette skillet noe tydeligere, men det er fortsatt lett å bli forvirret hvis du er ny.

Kort oppsummert:

• Du kan ikke opprette eller endre hovedressurser slik at de bryter med policyen (Deny).
• Eksisterende ressurser som ikke følger policyen blir ikke slettet, men kan ikke endres (uten å bli compliant).
• Endringer på extension resources kan ofte fortsatt gjennomføres, selv om hovedressursen er noncompliant.

Dette er et viktig poeng å forstå når du jobber med Azure Policy, særlig hvis du får uventede feilmeldinger, eller ser at noen endringer fortsatt er mulige på noncompliant ressurser.

Oppsummering

• Azure Policy gir deg full kontroll på hvordan ressurser brukes og konfigureres i Azure.
• Alt går gjennom ARM API, og policyene evalueres alltid – uavhengig av verktøy som brukes for å gjøre endringer i Azure.
• Policy gjelder kun for Azure-ressurser (ikke Entra ID), og evaluerer både under operasjoner og i daglige compliance-skanninger.
• Policy assignments arves nedover, gir helhetlig styring og lar deg sette “spilleregler” for hele virksomheten.
• Strukturen med policy, initiative, assignment og exemption gir fleksibel, skalerbar og praktisk governance.