En sammenhengende lab-serie der du bygger og drifter hele Microsoft-infrastrukturen til et fiktivt norsk konsulentfirma. Azure, Entra ID, Intune, M365 og sikkerhet — fra dag én til Zero Trust.
🏢 Bedriftsstory — NordForm AS
NordForm AS er et norsk konsulentfirma med 80 ansatte fordelt på kontorer i Stavanger og Oslo. De selger rådgivningstjenester innen bygg og anlegg. IT-sjefen har nettopp sluttet, og du er ansatt som ny IT-ansvarlig med mandat til å modernisere hele infrastrukturen.
Firmaet har i dag ingen strukturert Azure-tenant, ingen Intune-styring og ingen formell sikkerhetsstrategi. De har Microsoft 365 Business Premium-lisenser, men bruker dem dårlig. Styret har vedtatt at de innen 12 måneder skal oppfylle NSM grunnprinsipper og være klare for ekstern revisjon.
Du starter med blanke ark. Hver lab er et oppdrag du mottar fra IT-sjef, CISO eller styret — og beslutningene du tar tidlig vil påvirke hva som er mulig senere.
Fremdrift: 25 av 25 laber fullført
AZ-104: Lab 1–13
MS-102: Lab 8–15
MD-102: Lab 14–19
SC-300: Lab 10–25
AZ-305: Lab 16–25
Oppdraget
IT-sjefen ber deg sette opp Azure-fundamentet. «Vi trenger en ryddig struktur fra dag én — vi vil ikke rydde opp kaos om to år», sier hun. Du skal opprette hierarkiet som all fremtidig drift skal leve i.
Hva du gjør
- Opprett Management Group kalt
mg-nordform-root under Tenant Root Group. Dette er paraply-nivået som lar deg sette policyer som gjelder alle subscriptions under.
- Knytt din Pay-As-You-Go subscription under management group-en. Nå arver subscriptionen fremtidige policyer automatisk.
- Opprett tre Resource Groups:
rg-identity, rg-network, rg-workloads. Disse speiler de tre ansvarssonene i en reell arkitektur — identitet skilles fra nettverk som skilles fra applikasjoner.
- Definer en tagging-konvensjon og tag alle resource groups med:
environment: lab, owner: nordform-it, costcenter: infra. Tags er grunnlaget for kostnadsrapportering og policy-håndhevelse.
- Sett opp et Budget Alert på NOK 300/mnd på subscriptionen med e-postvarsling til deg selv. Dette hindrer overraskelser på regningen.
Hvorfor dette valget: Management Groups lar deg administrere hundrevis av subscriptions som én enhet. NordForm er lite nå, men hvis de vokser eller splitter environments (prod/dev) trenger de dette hierarkiet på plass. Det er umulig å retroaktivt legge til management groups uten å flytte ressurser.
Akseptansekriterier
- Management group eksisterer og subscription er koblet til den
- Tre resource groups med korrekte tags er opprettet
- Budget alert er konfigurert og bekreftet på e-post
Oppdraget
«Vi trenger testbrukere som speiler roller i firmaet, og vi vil ikke at alle skal ha tilgang til alt i Azure», sier IT-sjefen. Du skal opprette brukerstrukturen og knytte Azure-tilganger til roller — ikke enkeltpersoner.
Hva du gjør
- Opprett fire brukere i Entra ID:
alice.admin (IT), bob.developer (utvikling), carol.finance (økonomi), dave.readonly (konsulent). Gi dem sterke passord.
- Opprett tre sikkerhetsgrupper:
grp-azure-contributors, grp-azure-readers, grp-azure-admins. Legg alice i admins, bob i contributors, carol og dave i readers.
- Tildel RBAC via grupper — ikke direkte til brukere: admins → Contributor på subscription, readers → Reader på subscription, contributors → kun
rg-workloads.
- Test tilgangene ved å logge inn som bob og verifisere at han kan opprette ressurser i
rg-workloads men ikke i rg-network.
Hvorfor grupper fremfor direkte RBAC: Med 80 ansatte som slutter og starter, er det umulig å vedlikeholde individuelle RBAC-tildelinger. Grupper gir deg én plass å administrere tilganger — du fjerner personen fra gruppen, og alle Azure-tilganger forsvinner automatisk.
⚠️ RBAC-endringer i Azure kan ta opptil 5 minutter å propagere. Hvis testpålogging som bob feiler, vent litt og prøv igjen.
Akseptansekriterier
- Fire brukere opprettet med korrekte gruppemedlemskap
- RBAC er tildelt grupper, ikke enkeltbrukere
- Bob kan opprette ressurser i rg-workloads men ikke rg-network (verifisert)
Oppdraget
CISO-en har lest om GDPR og datalokalitet. «Vi vil at ingenting av vår data skal forlate Norge uten at vi aktivt bestemmer det», sier hun. Du skal håndheve dette teknisk — ikke bare som en retningslinje.
Hva du gjør
- Opprett en policy-assignment som begrenser tillatte lokasjoner til
norwayeast og norwaywest. Effect: Deny. Test at du ikke kan opprette en Storage Account i West Europe.
- Opprett en tagging-policy med effect
Deny som krever at alle ressurser har taggen environment. Uten den kan ressursen ikke opprettes.
- Opprett en audit-policy som identifiserer VM-er uten Defender for Cloud aktivert. Effect:
Audit — dette logger, men blokkerer ikke.
- Se Compliance-dashboardet og forstå forskjellen på Compliant, Non-compliant og Exempt.
Audit vs Deny: Deny stopper fremtidige feil, men kan knekke eksisterende arbeidsflyter. Audit gir synlighet uten å blokkere. I en ny tenant starter du gjerne med Audit for å kartlegge tilstand, deretter oppgraderer du til Deny.
Akseptansekriterier
- Ressursopprettelse i West Europe blokkeres av policy
- Ressurs uten environment-tag kan ikke opprettes
- Compliance-dashboard viser minst én audit-policy med data
Oppdraget
NordForm skal ha et internt nettverksmiljø i Azure. «Vi trenger å separere servere fra klienter og sikre at ingenting snakker med omverdenen uten at vi har eksplisitt åpnet for det», sier nettverksansvarlig.
Hva du gjør
- Opprett VNet
vnet-nordform-prod med adresserom 10.10.0.0/16 i Norway East.
- Opprett tre subnett:
snet-servers (10.10.1.0/24), snet-clients (10.10.2.0/24), snet-bastion (10.10.3.0/27 — Bastion krever minimum /27).
- Opprett NSG
nsg-servers og knytt den til snet-servers. Legg til Deny-regel for inbound fra internett (port Any), men Allow fra snet-clients.
- Aktiver Service Endpoint for Microsoft.Storage på
snet-servers. Servere når Azure Storage over Microsofts backbone — ikke via internett.
Hvorfor subnett-segmentering: Hvis én server kompromitteres, hindrer NSG-reglene lateral bevegelse til andre subnett. Dette er grunnleggende i Zero Trust og et krav i NSMs grunnprinsipper: minimer angrepsflate mellom soner.
Akseptansekriterier
- VNet med tre subnett opprettet med korrekte adresserom
- NSG er knyttet til snet-servers med korrekte inbound-regler
- Service Endpoint for Storage aktivert på snet-servers
Oppdraget
«Vi trenger en Windows Server for intern filbehandling. Og vi vil absolutt ikke ha RDP eksponert mot internett», sier IT-sjefen. Du skal deploye en VM og gi deg selv sikker tilgang uten å åpne brannmuren.
Hva du gjør
- Deploy Windows Server 2022 VM i
snet-servers. Velg Standard_B2s. Deaktiver Public IP under opprettelse.
- Deploy Azure Bastion i
snet-bastion (Basic SKU). Gir RDP direkte i nettleseren over HTTPS — ingen port 3389 åpen.
- Koble til VM-en via Bastion og verifiser at du kommer inn. Prøv deretter vanlig RDP på port 3389 — det skal feile.
- Aktiver System-assigned Managed Identity på VM-en. VM-en får en identitet i Entra ID uten lagrede passord.
Managed Identity vs lagrede credentials: Uten Managed Identity måtte du lagret et service principal-passord i konfigurasjonen — en sikkerhetsrisiko. VM-en henter token automatisk fra Entra ID. Ingen passord å stjele, rotere eller glemme.
⚠️ Bastion Basic SKU koster ca. NOK 130/dag. Slett Bastion-ressursen etter lab, og gjenopprett ved behov.
Akseptansekriterier
- VM kjører i snet-servers uten public IP
- Innlogging via Bastion fungerer
- Direkte RDP på port 3389 feiler
- Managed Identity er aktivert på VM
Oppdraget
NordForm trenger et sted å lagre prosjektfiler og backup-data. «Vi vil ha forskjellige tilgangsnivåer — noen skal bare lese, andre skal kunne skrive, og sensitive filer skal ikke være tilgjengelig for alle», sier CISO.
Hva du gjør
- Opprett Storage Account
stnordformprod01 i Norway East. Deaktiver "Allow Blob public access".
- Opprett Blob Container
prosjektfiler og tildel bob rollen Storage Blob Data Contributor via RBAC — ikke via Access Keys.
- Generer et SAS-token med kun lesettilgang og utløp om 1 time. Test at det fungerer og utløper korrekt.
- Opprett Azure Files Share og mount den som nettverksstasjon (Z:) på VM-en fra lab 05.
- Sett opp Lifecycle Management: filer ikke åpnet på 30 dager → Cool tier, etter 90 dager → Archive.
RBAC vs Access Keys: Access Keys gir full tilgang til alt i Storage Account. Hvis én lekker er all data eksponert. RBAC-roller er scopet, kan trekkes tilbake uten å rotere nøkler, og auditlogges per bruker.
Akseptansekriterier
- Storage Account uten public blob access
- Bob har RBAC-tilgang til blob, ikke via Access Keys
- SAS-token fungerer og utløper korrekt
- Azure Files montert som Z: på VM
- Lifecycle policy er konfigurert
Oppdraget
«Vi har hatt tre phishing-forsøk denne måneden. Vi trenger MFA for alle, og vi vil ikke at folk skal kunne logge inn fra land vi ikke driver i», sier CISO.
Hva du gjør
- Aktiver SSPR for alle brukere med to autentiseringsmetoder påkrevd: mobilapp og e-post.
- Opprett Named Location kalt "NordForm kontorer" med NordForms offentlige IP-adresser (bruk din egen for lab).
- Opprett CA-policy "Krev MFA utenfor kontor": alle brukere, alle apper, location NOT IN "NordForm kontorer", Grant: Require MFA. Start i Report-only.
- Opprett CA-policy "Blokker høyrisikoland": alle land UNNTATT Norge, Grant: Block. Sett til Report-only og verifiser i Sign-in logs.
- Aktiver begge policies etter at Report-only viser korrekt oppførsel.
Report-only er ikke valgfritt: En feil CA-policy kan låse alle brukere ute — inkludert deg. Report-only viser effekten i Sign-in logs uten å håndheve den. Alltid start her for Block-policies.
⚠️ Sørg for at din Global Admin-konto er ekskludert fra Block-policyen. Ellers risikerer du å låse deg selv ute av tenanten.
Akseptansekriterier
- SSPR aktivert og verifisert med testbruker
- Named Location for kontorer opprettet
- MFA-policy aktiv og treffer riktige pålogginger
- Admin-konto er eksplisitt ekskludert fra Block-policy
Oppdraget
«Vi fant passord hardkodet i en konfigurasjonsfil på en server. Det er ikke akseptabelt», sier CISO. Du skal opprette en sentral hemmelighetsforvaltning og vise at applikasjoner kan hente passord uten å lagre dem noe sted.
Hva du gjør
- Opprett Key Vault
kv-nordform-prod-01 med RBAC-tilgangmodell (ikke Vault Access Policy).
- Tildel deg selv rollen
Key Vault Secrets Officer. Uten denne kan du ikke lese secrets selv som eier av ressursen.
- Opprett tre secrets:
db-password, api-key-external, smtp-password.
- Gi VM-ens Managed Identity rollen
Key Vault Secrets User og hent en secret via PowerShell uten passord: Get-AzKeyVaultSecret -VaultName "kv-nordform-prod-01" -Name "db-password" -AsPlainText
- Sett opp rotation-alert: e-post 30 dager før en secret utløper.
Managed Identity + Key Vault er gullstandarden: VM-en spør Entra ID om et token, presenterer det til Key Vault, og får tilgang. Angripere finner ingen passord å stjele — bare et midlertidig token som utløper.
Akseptansekriterier
- Key Vault med RBAC-modell og tre secrets
- VM henter secret via Managed Identity uten passord i script
- Rotation-alert konfigurert
Oppdraget
«Noen ansatte vil bruke sin private mobiltelefon til å sjekke e-post. Vi vil tillate det, men uten at bedriftsdata havner i private apper eller synkroniseres til iCloud», sier IT-sjefen.
Hva du gjør
- Deploy Microsoft 365-apper til enrolled Windows-enheter via Intune. Velg "Required" — appen installeres automatisk.
- Opprett App Protection Policy for iOS/Android (MAM uten enrollment): krypter app-data, blokker copy-paste fra bedriftsapp til personlig app, krev PIN.
- Test BYOD-scenariet: installer Outlook på en ikke-enrolled mobil. Verifiser at App Protection Policy håndheves.
- Forstå forskjellen mellom MDM (fullt managed enhet) og MAM (kun appen er managed).
MDM vs MAM: Med MDM kan IT tørke hele telefonen. For privattelefoner er MAM riktig — bedriften sletter kun bedriftsdata fra appen, ikke personlige bilder og meldinger.
Akseptansekriterier
- M365-apper deployet som Required til enrolled enheter
- App Protection Policy for mobil med copy-paste blokkering
- BYOD-scenario testet og policyen verifisert
Oppdraget
«Oslo-kontoret trenger et eget Azure-miljø, men vi vil at begge kontorene skal nå felles tjenester — uten at Oslo og Stavanger kan snakke direkte med hverandre», sier nettverksansvarlig.
Hva du gjør
- Opprett VNet
vnet-nordform-oslo (10.20.0.0/16) og Hub VNet vnet-nordform-hub (10.0.0.0/16).
- Konfigurer VNet Peering: Stavanger ↔ Hub og Oslo ↔ Hub. Aktiver "Allow gateway transit" i Hub. Stavanger og Oslo er ikke direkte peerete.
- Verifiser at en VM i Stavanger-VNet kan pinge Hub, men ikke Oslo direkte.
Hub-spoke er standard arkitekturpattern: Sentralisert kontroll i Hub (logging, firewall), spoke-nettverkene isolert fra hverandre. AZ-305 tester om du kan begrunne designbeslutninger som denne.
Akseptansekriterier
- Tre VNet-er med ikke-overlappende adresserom
- Peering konfigurert: Stavanger↔Hub og Oslo↔Hub
- VM i Stavanger kan nå Hub men ikke Oslo direkte
Oppdraget
«Vi lanserer et internt webverktøy. Det må tåle at alle 80 ansatte bruker det samtidig på mandager, men vi vil ikke betale for kapasitet vi ikke trenger resten av uken», sier IT-sjefen.
Hva du gjør
- Opprett en VM Scale Set med minimum 2 og maksimum 5 instanser.
- Konfigurer Autoscale-regler: legg til én VM når CPU > 70% i 5 min, fjern én når CPU < 30% i 10 min. Behold minimum 2.
- Deploy Azure Load Balancer foran Scale Set. Konfigurer Health Probe på port 80.
- Test redundansen: stopp én VM og verifiser at Load Balancer ruter trafikk uten nedetid.
Availability vs cost: To VM-er gir null nedetid ved én feil. Autoscaling er kompromisset: du betaler for kapasitet ved behov, men beholder redundans som grunnlinje.
Akseptansekriterier
- VM Scale Set med autoscale-regler konfigurert
- Load Balancer med health probe er aktiv
- Stopp av én VM gir ikke tap av tilgang til tjenesten
Oppdraget
«Vi vil at all trafikk ut av Azure-miljøet går gjennom ett kontrollpunkt. Ingen VM skal ha direkte internettilgang», sier CISO.
Hva du gjør
- Deploy Azure Firewall i Hub-VNet (Standard SKU). Sentralt kontrollpunkt for all outbound trafikk.
- Opprett User Defined Route (UDR) i alle spoke-subnett: default route (0.0.0.0/0) peker til Firewall-ens private IP.
- Opprett Application Rule som tillater outbound HTTPS til
*.microsoft.com og *.windows.net. Alt annet blokkeres.
- Aktiver Firewall-logging til Log Analytics Workspace.
Egress kontroll er like viktig som ingress: Malware kommuniserer utover til command and control-servere. Azure Firewall med application rules håndhever allowlist for outbound — eksfiltrering til ukjente domener blokkeres automatisk.
⚠️ Azure Firewall koster ca. NOK 1000/dag. Deploy, fullfør lab, slett Firewall. Behold UDR-konfigurasjonen for referanse.
Akseptansekriterier
- Azure Firewall i Hub-VNet med UDR i alle spoke-subnett
- VM-er kan kun nå godkjente domener (Application Rule)
- Firewall-logger strømmer til Log Analytics Workspace
Oppdraget
«Styret vil ha en konkret sikkerhetsscore de kan følge over tid. Og vi trenger å vite om vi møter kravene i NSMs grunnprinsipper», sier CISO.
Hva du gjør
- Aktiver Defender for Cloud (CSPM gratis tier). Se Secure Score.
- Gå gjennom Recommendations sortert etter "Max score increase". Implementer de tre øverste.
- Aktiver Regulatory Compliance-dashboardet mot ISO 27001 eller CIS Benchmarks.
- Aktiver Defender for Servers Plan 1 på VM-en for agentbasert endepunktsbeskyttelse og Just-in-time VM access.
CSPM gir synlighet, ikke sikkerhet: Defender for Cloud oppdager misconfigurasjoner og anbefaler tiltak, men håndhever ingenting. Verdien er systematisk prioritering basert på risikopåvirkning.
Akseptansekriterier
- Secure Score synlig og minimum tre anbefalinger implementert
- Regulatory Compliance dashboard aktivert
- Defender for Servers Plan 1 aktivert på VM
Oppdraget
«Revisor kommer om to måneder. Vi trenger å dokumentere hva vi har på plass, hva vi mangler, og en prioritert plan for å lukke gapene», sier CISO. Dette er en arkitekturgjennomgang, ikke en teknisk lab.
Hva du gjør
- Kartlegg de seks Zero Trust-pillarene mot det NordForm har bygget: Identitet, Enheter, Applikasjoner, Data, Infrastruktur, Nettverk.
- Gjennomgå NSMs 4 kategorier: Identifisere og kartlegge, Beskytte og opprettholde, Oppdage, Håndtere og gjenopprette.
- Skriv en gap-liste med prioritet (Kritisk / Høy / Medium). Bruk Secure Score og Compliance Manager som input.
- Lag en 90-dagers plan for de tre viktigste gapene med konkrete tiltak og eier.
Hvorfor denne laben: AZ-305 tester ikke bare om du kan deploye ressurser — men om du forstår helheten og kan begrunne arkitekturvalgene. Dette er treningen i å tenke som en arkitekt, ikke bare en administrator.
Akseptansekriterier
- Zero Trust-kartlegging fullført for alle seks pilarer
- NSM-kategorisering av eksisterende kontroller
- Gap-liste med prioritering og 90-dagers plan
Oppdraget
Kl. 08:47 mandag morgen mottar du varsel: Defender for Cloud rapporterer uvanlig outbound trafikk fra VM-en. En bruker har logget inn fra Romania midt på natten. Det mangler en hel mappe med prosjektfiler. Du har fått oppdrag om å håndtere hendelsen fra A til Å.
Hva du gjør
- Containment: deaktiver den kompromitterte brukerkontoen i Entra ID, revoke alle aktive sessions, isoler VM-en ved å endre NSG til Deny All.
- Etterforskning: bruk Log Analytics til å søke i SecurityEvent og SignInLogs for tidslinje. Hva ble gjort, av hvem, fra hvilken IP?
- Omfang: sjekk om andre kontoer har logget inn fra samme IP. Sjekk Defender for Cloud Alerts for relaterte hendelser.
- Recovery: gjenopprett filene fra backup (lab 19), roter alle secrets i Key Vault, oppdater CA-policy.
- Post-incident: dokumenter hendelsesforløp, rotårsak og tiltak som forhindrer gjentakelse.
Dette er hva alle 24 labene bygget til: PIM, Bastion, Key Vault, Backup, Log Analytics, Conditional Access — alle er deler av en helhetlig arkitektur som gjør det mulig å oppdage, inneholde og gjenopprette fra en hendelse. Verdien er i helheten.
Akseptansekriterier
- Kompromittert konto deaktivert og sessions revokert
- VM isolert fra nettverket
- KQL-spørring produserer tidslinje for hendelsen
- Filer gjenopprettet fra backup
- Secrets i Key Vault rotert
- Post-incident rapport skrevet