NordForm AS —
scenariobasert lab-serie

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.

AZ-104 MS-102 MD-102 SC-300 AZ-305 25 laber Progressiv vanskegrad

🏢 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
Fase 1 — Grunnmur AZ-104 kjerne
01
Opprett og konfigurer Azure-tenanten til NordForm
Management groups · Subscriptions · Resource Groups · Tagging-strategi
AZ-104AZ-305
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.
  • 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.
  • 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
02
Brukere, grupper og RBAC i Entra ID
Entra ID · Users · Groups · RBAC · Least Privilege
AZ-104SC-300
«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.
  • 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.
  • Fire brukere opprettet med korrekte gruppemedlemskap
  • RBAC er tildelt grupper, ikke enkeltbrukere
  • Bob kan opprette ressurser i rg-workloads men ikke rg-network (verifisert)
03
Azure Policy — governance fra dag én
Azure Policy · Tagging enforcement · Allowed locations · Audit vs Deny
AZ-104AZ-305
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.
  • 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.
  • Ressursopprettelse i West Europe blokkeres av policy
  • Ressurs uten environment-tag kan ikke opprettes
  • Compliance-dashboard viser minst én audit-policy med data
04
Virtuelt nettverk og subnett-arkitektur
VNet · Subnets · NSG · Service Endpoints
AZ-104AZ-305
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.
  • 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.
  • 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
05
Windows Server VM og Azure Bastion
Virtual Machines · Bastion · Disk · Managed Identity
AZ-104
«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.
  • 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.
  • 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
06
Azure Storage — blob, files og tilgangsstyring
Storage Account · Blob · Azure Files · SAS · RBAC · Lifecycle
AZ-104
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.
  • 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.
  • 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
07
Azure Monitor, Log Analytics og Alerts
Log Analytics Workspace · Diagnostic Settings · Alerts · KQL
AZ-104AZ-305
«Vi ble nylig rammet av en incident vi ikke visste om på to dager. Det skal aldri skje igjen», sier CISO. Du skal sette opp overvåking som fanger avvik og varsler automatisk.
  • Opprett Log Analytics Workspace law-nordform-prod. Dette er sentralt hjertet i all overvåking.
  • Aktiver Diagnostic Settings på VM, Storage Account og Key Vault. Koble alle til samme workspace.
  • Skriv en KQL-spørring som viser påloggingsfeil siste 24 timer: SecurityEvent | where EventID == 4625 | summarize count() by Account, Computer.
  • Sett opp en Alert Rule som sender e-post hvis CPU overstiger 80% i mer enn 5 minutter. Konfigurer en Action Group.
  • Se på VM Insights — aktiver det fra Monitoring-seksjonen for ferdige dashboards uten KQL.
Ett workspace for alt: Et sentralt workspace lar deg kombinere Azure AD-logger, VM-logger og nettverkslogger i én spørring — kritisk for incident response.
  • Log Analytics Workspace mottar data fra minimum to ressurser
  • KQL-spørring for påloggingsfeil returnerer resultater
  • Alert Rule med Action Group er konfigurert og testet
Fase 2 — Identitet og tilgangsstyring SC-300 tyngde
08
MFA, SSPR og Conditional Access grunnleggende
Entra ID · MFA · SSPR · Conditional Access · Named Locations
SC-300MS-102
«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.
  • 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.
  • 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
09
Azure Key Vault — hemmeligheter og sertifikater
Key Vault · Secrets · RBAC-modell · Rotation · Managed Identity
AZ-104SC-300
«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.
  • 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.
  • Key Vault med RBAC-modell og tre secrets
  • VM henter secret via Managed Identity uten passord i script
  • Rotation-alert konfigurert
10
Privileged Identity Management (PIM)
PIM · Eligible roles · JIT · Approval workflow · Access Reviews
SC-300AZ-305
«Vi vil ikke at noen skal ha Global Administrator permanent. Admin-rettigheter skal aktiveres ved behov, med begrunnelse og tidsavgrensning», sier CISO.
  • Aktiver PIM i Entra ID (krever P2-lisens — Business Premium inkluderer dette).
  • Konverter din Global Administrator fra Active (permanent) til Eligible. Du mister rollen umiddelbart.
  • Aktiver rollen via PIM: gi begrunnelse, sett varighet 1 time. Rollen forsvinner automatisk etter en time.
  • Konfigurer aktiveringsinnstillinger: krev MFA, krev begrunnelse, maksimal varighet 4 timer.
  • Sett opp Access Review for GA-rollen: månedlig review, reviewer = deg selv.
Eligible fremfor Active: En permanent GA-konto som kompromitteres gir angriperen full kontroll for alltid. En Eligible-konto gir ingenting — de kan ikke aktivere rollen uten MFA. JIT-tilgang er et kjernekrav i Zero Trust og NSMs grunnprinsipper.
  • Global Administrator er Eligible, ikke permanent Active
  • Rolleaktivering krever MFA og begrunnelse
  • Access Review konfigurert og sendt
Fase 3 — Microsoft 365 administrasjon MS-102 tyngde
11
Exchange Online — e-post, routing og sikkerhet
Exchange Online · Anti-spam · DKIM · DMARC · Shared Mailbox
MS-102
«Vi mottar spam og phishing, og vi har fått rapport om at noen spoofer domenet vårt. Vi trenger bedre e-postsikkerhet og en felles postkasse for kontakthenvendelser», sier IT-sjefen.
  • Aktiver DKIM-signering for NordForms domene i Exchange Admin Center.
  • Konfigurer DMARC-policy via DNS TXT-record: start med p=none, deretter p=quarantine etter 2 uker.
  • Gjennomgå Anti-spam policies i Defender for Office 365. Forstå forskjellen mellom Spam, High Confidence Spam og Phishing.
  • Opprett Shared Mailbox kontakt@nordformas.no med alice og bob som members.
  • Opprett Distribution Group alle@nordformas.no og test distribusjon til alle members.
SPF + DKIM + DMARC er treenigheten: SPF sier hvilke servere som kan sende. DKIM signerer mailen. DMARC binder dem sammen og definerer hva som skjer ved feil. Uten alle tre er domenet sårbart for spoofing.
  • DKIM aktivert og verifisert (grønn status i EAC)
  • DMARC TXT-record publisert i DNS
  • Shared Mailbox opprettet og tilgjengelig for alice og bob
12
Microsoft Teams — governance og ekstern tilgang
Teams Admin Center · Policies · Guest Access · Retention · DLP
MS-102
«Teams har blitt en jungel. Folk oppretter team for alt, inkludert sensitive prosjekter med eksterne konsulenter. Vi trenger kontroll», sier IT-sjefen.
  • Begrens teamopprettelse til gruppen grp-teams-creators.
  • Konfigurer Guest Access: tillat gjester, krev Terms of Use, sett utløp på invitasjoner til 180 dager.
  • Sett opp Retention Policy for Teams-meldinger: bevar i 3 år, deretter slett.
  • Opprett en DLP-policy som varsler hvis noen deler et personnummer i Teams. Varsle bruker, send alert til compliance-admin.
  • Se på Teams Advisor i Admin Center for en skreddersydd utrullingsplan.
Governance fra dag én: Å rydde opp i 500 utdaterte teams er langt vanskeligere enn å sette retningslinjer fra starten. Retention og DLP beskytter mot utilsiktet datadeling og sikrer at sensitiv info ikke forsvinner med en ansatt som slutter.
  • Kun grp-teams-creators kan opprette nye teams
  • Guest Access konfigurert med Terms of Use
  • Retention Policy aktiv for Teams
  • DLP-policy varsler ved personnummer i Teams
13
Microsoft Purview — informasjonsbeskyttelse og compliance
Sensitivity Labels · DLP · Compliance Manager · Retention
MS-102SC-300
«Styret ber oss dokumentere at vi er GDPR-compliant. Vi trenger en måte å klassifisere sensitiv informasjon og hindre at den lekker ut», sier CISO.
  • Opprett Sensitivity Labels: Intern, Konfidensiell, Svært konfidensiell. Konfigurer sistnevnte til å kryptere og kun tillate spesifikke grupper.
  • Publiser labels via Label Policy til alle brukere.
  • Opprett DLP-policy som blokkerer e-post med Svært konfidensiell-label til eksterne. Override mulig med begrunnelse, men logges.
  • Sjekk Compliance Manager — se Compliance Score og identifiser tiltak med størst forbedring.
Klassifisering er grunnmuren: DLP, retention og tilgangsstyring er bare effektive hvis dataen er klassifisert. Sensitivity Labels er utgangspunktet som alt annet bygger på.
  • Tre sensitivity labels publisert til alle brukere
  • DLP blokkerer ekstern deling av Svært konfidensiell
  • Compliance Score gjennomgått og minst to tiltak identifisert
Fase 4 — Endpoint Management MD-102 tyngde
14
Intune — Entra ID Join og Autopilot-klargjøring
Intune · Entra ID Join · Enrollment · Windows Autopilot
MD-102SC-300
«Vi kjøper 20 nye laptoper til Stavanger-kontoret. IT-avdelingen sitter i Oslo og kan ikke reise dit for å sette dem opp. Vi trenger at brukerne kan klargjøre dem selv», sier IT-sjefen.
  • Konfigurer automatisk Intune-enrollment: Intune → Enrollment → Automatic Enrollment, sett MDM scope til All.
  • Join din lab-PC til Entra ID (Settings → Accounts → Access work or school → Join). Verifiser at enheten vises i Intune som "Managed".
  • Utforsk Autopilot-konseptet: hardware hash registreres hos Microsoft, Windows gjenkjenner maskinen ved første oppstart og joiner Entra ID automatisk.
  • Opprett en Enrollment Status Page policy: brukeren ser fremgang under oppsett og kan ikke bruke PC-en før konfigurasjonen er fullført.
Zero-touch provisioning: Med Autopilot sendes laptopen direkte fra leverandøren til brukeren og konfigurerer seg selv. For NordForm med to kontorer er dette forskjellen på én dag vs. en uke ved nyansettelser.
  • Automatisk enrollment aktivert for tenanten
  • Enhet er Entra-joined og vises i Intune som Managed
  • Enrollment Status Page policy er opprettet
15
Intune — Compliance Policies og Conditional Access
Compliance Policies · Device Compliance · Conditional Access · Remediation
MD-102SC-300
«Vi vil at kun enheter som oppfyller våre sikkerhetskrav skal få tilgang til bedriftsdata. En privateid PC uten kryptering skal ikke kunne lese e-posten vår», sier CISO.
  • Opprett Windows Compliance Policy: BitLocker påkrevd, minimum Windows 11 22H2, antivirus aktiv, firewall aktiv.
  • Sett Non-compliance action: e-post til bruker etter 1 dag, merk enhet som non-compliant etter 3 dager, pensjoneringsvarsel etter 30 dager.
  • Koble Conditional Access til device compliance: CA-policy "Krev compliant device for M365" — all tilgang til Exchange, SharePoint og Teams krever Compliant device.
  • Test flyten: se statusen på din Intune-enrolled enhet. Er den Compliant? Hvilke krav er oppfylt og hvilke mangler?
Device compliance er Zero Trust i praksis: Entra ID vet hvem du er. Intune vet om enheten er sikker. Conditional Access kombinerer: rett person + godkjent enhet = tilgang. Mangler én faktor, nektes tilgang.
  • Compliance Policy med minimum fire krav opprettet
  • Non-compliance actions konfigurert med tidsintervaller
  • CA-policy krever Compliant device for M365-tilgang
  • Din enrolled enhet viser Compliant eller konkret årsak til Non-compliant
16
Intune — App-deployment og App Protection Policies
App Deployment · Win32 Apps · App Protection · MAM · BYOD
MD-102
«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.
  • 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.
  • M365-apper deployet som Required til enrolled enheter
  • App Protection Policy for mobil med copy-paste blokkering
  • BYOD-scenario testet og policyen verifisert
Fase 5 — Avansert nettverk og hybrid AZ-104 / AZ-305
17
VNet Peering og hub-spoke arkitektur
VNet Peering · Hub-spoke · Route Tables · UDR
AZ-104AZ-305
«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.
  • 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.
  • Tre VNet-er med ikke-overlappende adresserom
  • Peering konfigurert: Stavanger↔Hub og Oslo↔Hub
  • VM i Stavanger kan nå Hub men ikke Oslo direkte
18
Load Balancer og skalering av VM-er
Azure Load Balancer · VM Scale Sets · Health Probes · Autoscale
AZ-104AZ-305
«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.
  • 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.
  • 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
19
Azure Backup og disaster recovery
Recovery Services Vault · VM Backup · File Recovery · RTO / RPO
AZ-104AZ-305
«Styret spør: hva skjer hvis en server krasjer og vi mister data? Kan vi bevise at vi er sikret?», sier IT-sjefen. Du skal implementere backup og gjøre en faktisk gjenoppretting.
  • Opprett Recovery Services Vault rsv-nordform-prod med Soft Delete aktivert (14 dager).
  • Aktiver VM Backup: daglig kl. 02:00, behold daglige i 30 dager, ukentlige i 12 uker, månedlige i 12 måneder.
  • Gjør en File Recovery: monter et backup-punkt som lokal disk på VM-en og gjenopprett én enkelt fil.
  • Dokumenter RTO/RPO for NordForm: maksimalt akseptabelt datatap og maksimal nedetid.
En backup du ikke har testet er ikke en backup: Mange oppdager at backup er korrupt eller tar for lang tid kun når det er for sent. Regelmessige restore-tester er et krav i de fleste rammeverk.
  • Recovery Services Vault med Soft Delete aktivert
  • VM Backup aktivert med dokumentert policy
  • File Recovery gjennomført og verifisert
  • RTO og RPO er definert og dokumentert
Fase 6 — PaaS og arkitekturdesign AZ-305 tyngde
20
Azure App Service og Azure SQL Database
App Service · Azure SQL · Private Endpoint · Managed Identity
AZ-104AZ-305
«Vi vil flytte prosjektledelsesverktøyet til en PaaS-tjeneste. Vi slipper da å patche operativsystem og drifte web-server», sier IT-sjefen.
  • Deploy en App Service (gratis F1-tier for lab) med en enkel test-app.
  • Deploy Azure SQL Database (serverless tier). Sett SQL Admin til en Entra ID-konto.
  • Koble App Service til SQL via Managed Identity: aktiver system-assigned identity, gi den rollen db_datareader. Ingen connection string med passord.
  • Opprett Private Endpoint for SQL — databasen er kun tilgjengelig fra innsiden av VNet-et.
PaaS vs IaaS: App Service lar deg fokusere på koden — Microsoft tar ansvar for OS, runtime og web-server. Færre sårbare systemer å holde oppdatert.
  • App Service kjører og er tilgjengelig via URL
  • App Service kobler til SQL via Managed Identity (ingen passord)
  • SQL Database er kun tilgjengelig via Private Endpoint
21
Azure Firewall og sikker internetttrafikk
Azure Firewall · UDR · Application Rules · Network Rules
AZ-305SC-300
«Vi vil at all trafikk ut av Azure-miljøet går gjennom ett kontrollpunkt. Ingen VM skal ha direkte internettilgang», sier CISO.
  • 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.
  • 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
22
Microsoft Defender for Cloud — CSPM og sikkerhetsscore
Defender for Cloud · Secure Score · CSPM · Recommendations · Regulatory Compliance
AZ-104SC-300AZ-305
«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.
  • 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.
  • Secure Score synlig og minimum tre anbefalinger implementert
  • Regulatory Compliance dashboard aktivert
  • Defender for Servers Plan 1 aktivert på VM
23
ARM Templates og Infrastructure as Code
ARM Templates · Bicep · Idempotency · Template Specs
AZ-104AZ-305
«Vi har brukt tre uker på å sette opp dette Azure-miljøet manuelt. Hvis vi må gjøre det igjen tar det like lang tid. Det er ikke akseptabelt», sier IT-sjefen.
  • Eksporter ARM Template fra en eksisterende Resource Group og studer JSON-strukturen.
  • Skriv en enkel Bicep-fil som deployer en Storage Account. Deploy den to ganger og verifiser idempotens.
  • Parameteriser Bicep-filen: environment-navn og lokasjon som parametere.
  • Publiser som Template Spec i Azure for gjenbruk av teammedlemmer.
IaC er ikke bare for utviklere: Manuelt konfigurerte miljøer er ikke reproduserbare, ikke versjonert og er en sikkerhetsrisiko. Med Bicep har du historikk i Git og kan bevise for revisor at miljøet er konfigurert som dokumentert.
  • Bicep-fil med parametere deployer Storage Account
  • Andre kjøring feiler ikke (idempotens verifisert)
  • Template Spec publisert og tilgjengelig i portalen
24
Zero Trust-gjennomgang og gap-analyse
Zero Trust · NSM Grunnprinsipper · Gap-analyse · Sikkerhetsscore
SC-300AZ-305MS-102
«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.
  • 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.
  • Zero Trust-kartlegging fullført for alle seks pilarer
  • NSM-kategorisering av eksisterende kontroller
  • Gap-liste med prioritering og 90-dagers plan
25
Avsluttende oppdrag — full incident response-øvelse
Incident Response · SIEM · Forensics · Lockdown · Recovery
SC-300AZ-305AZ-104MS-102
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 Å.
  • 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.
  • 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