Zero Trust bliver ofte omtalt, som om det var et produkt. Det er det ikke. Det er en måde at designe sikkerhed på, hvor man stopper med at antage, at noget er sikkert, bare fordi det befinder sig på virksomhedens netværk eller kommer fra en kendt bruger. I praksis handler det om at verificere adgang løbende, begrænse rettigheder systematisk og indrette miljøet, som om et brud allerede kan være i gang.
Det er også derfor, Zero Trust giver mening i Microsoft-miljøer. De fleste organisationer har allerede mange af byggestenene i Microsoft 365 og Azure: identiteter i Microsoft Entra ID, enheder i Intune, mail og samarbejde i Microsoft 365, endpoint-signaler i Defender og politikmotorer som Conditional Access. Udfordringen er sjældent, at teknologien mangler. Udfordringen er rækkefølgen, prioriteringen og den praktiske implementering.
Microsofts egen Zero Trust-oversigt beskriver modellen ud fra tre principper: verificer eksplicit, brug mindst mulige adgang og antag brud. Det er en god ramme, men i de fleste virksomheder er spørgsmålet mere jordnært: Hvor starter vi, uden at skabe unødigt driftskaos?
Start med identitet, ikke netværk
Det første kontrolpunkt i Zero Trust er identitet. Ikke firewall-regler. Ikke mikrosegmentering. Ikke endnu et dashboard. Hvis en angriber kan logge ind som en legitim bruger, er resten af miljøet allerede under pres.
Derfor bør den første prioritet være at få styr på, hvordan brugere autentificeres, hvilke signaler der bruges til adgangsbeslutninger, og hvordan risikable sessioner håndteres. I Microsoft-verdenen betyder det typisk Microsoft Entra ID, multifaktorgodkendelse og Conditional Access.
Microsoft dokumenterer Entra som den centrale identitetsplatform i Entra-dokumentationen. I praksis er det her, I samler brugeridentiteter, gruppemedlemskaber, roller, applikationsadgang og politikker for login. Hvis det lag ikke er stramt, bliver resten af Zero Trust-arkitekturen porøs.
Et pragmatisk udgangspunkt er:
- kræv MFA for alle brugere
- blokér legacy authentication
- indfør Conditional Access med tydelige adgangsbetingelser
- hold særligt skarpt øje med administratorer og andre privilegerede konti
Conditional Access er vigtig, fordi den flytter jer væk fra en binær tanke om adgang. Adgang bliver i stedet en vurdering baseret på kontekst: hvem brugeren er, hvilken enhed de bruger, hvor sessionen kommer fra, om enheden er compliant, og om loginet ser risikabelt ud. Microsofts dokumentation om Conditional Access er værd at læse, fordi den gør det tydeligt, at politikkerne ikke bare er et MFA-lag, men selve beslutningsmotoren i en moderne adgangsmodel.
Least privilege er et driftsprincip, ikke kun et sikkerhedsprincip
Det næste centrale element er mindst mulige adgang. Det bliver ofte reduceret til en snak om admin-konti, men det gælder bredere end det. Brugere, applikationer, service principals, enheder og supportroller bør alle have så lidt adgang som muligt, i så kort tid som muligt.
I en Microsoft-kontekst betyder det blandt andet:
- færre globale administratorer i Entra
- rolleopdeling i stedet for brede admin-roller
- tidsbegrænset privilegeret adgang
- styring af gruppebaserede rettigheder
- gennemgang af applikationers Graph- og API-tilladelser
Hvis alle problemer løses ved at tildele Global Administrator, er miljøet ikke modent. Microsofts rollebaserede adgangskontrol i Entra giver langt mere granulære muligheder. For organisationer med de relevante licenser er Privileged Identity Management et stærkt værktøj, fordi det gør privilegeret adgang midlertidig, godkendt og sporbar.
Least privilege handler også om almindelige brugere. Delte konti, gamle projektgrupper, brede SharePoint-rettigheder og mailbokse med historisk tildelte tilladelser er ofte en større reel risiko end manglen på avancerede sikkerhedsprodukter. Den praktiske opgave er ikke at tegne den perfekte model på en tavle. Den praktiske opgave er at fjerne unødvendig adgang lidt efter lidt og gøre det til en fast del af driften.
Kontinuerlig validering er forskellen på teori og praksis
En klassisk misforståelse er, at Zero Trust bare betyder streng login-kontrol. Men hvis kontrollen kun ligger ved første login, er modellen for svag. Risici ændrer sig undervejs i en session. En enhed kan falde ud af compliance. Et login kan senere klassificeres som risikabelt. En bruger kan få ændret sin rolle. Et endpoint kan begynde at vise tegn på kompromittering.
Derfor giver det mening at tænke i løbende validering. Microsoft understøtter det på flere lag. Entra kan bruge risikosignaler til at kræve ekstra godkendelse eller blokere adgang. Intune kan markere enheder som ikke-compliant. Defender kan levere signaler om endpoint-risiko. Session controls og app-baserede politikker kan begrænse, hvad brugeren må gøre, selv når adgang er givet.
Relevant dokumentation her er blandt andet Entra Identity Protection, Intune compliance policies og Microsoft Defender for Endpoint onboarding og capabilities. Pointen er ikke at aktivere alt på én gang. Pointen er at bygge en kæde af signaler, så adgangsbeslutninger ikke står alene på brugernavn og password plus en enkelt MFA-prompt.
De Microsoft-komponenter der typisk indgår
I de fleste mellemstore Microsoft-miljøer er følgende komponenter de vigtigste i en praktisk Zero Trust-implementering:
Microsoft Entra ID
Entra er identitetsfundamentet. Her håndteres brugere, grupper, applikationsadgang, roller, MFA, risikovurdering og Conditional Access. Hvis I skal vælge ét sted at starte, er det her.
Microsoft Intune
Intune er centralt, fordi Zero Trust ikke kun handler om brugeren, men også om enhedens tilstand. En adgangsbeslutning er markant bedre, når systemet ved, om enheden er krypteret, opdateret, styret og compliant. Microsoft beskriver Intune i produktoversigten. I praksis er det forbindelsen mellem endpoint management og adgangskontrol.
Microsoft Defender
Defender-porteføljen bidrager med trusselsdetektion og risikosignaler. Det gælder både mail, identiteter og endpoints. For mange organisationer er værdien ikke kun beskyttelsen i sig selv, men at signalerne kan bruges operativt i Zero Trust-modellen. Microsoft Defender XDR giver et overblik over, hvordan signaler samles på tværs.
Microsoft Purview
Zero Trust uden styr på data bliver hurtigt for snævert. I sidste ende handler sikkerhed om at beskytte data og forretningsprocesser. Microsoft Purview er relevant, når I skal arbejde med labels, databeskyttelse, retention og mere præcise kontroller omkring følsomt indhold.
Det betyder ikke, at alle virksomheder skal implementere hele Microsoft-sikkerhedsstakken fra dag ét. Men det er nyttigt at vide, hvilke roller komponenterne spiller, så prioriteringen bliver realistisk.
En prioriteret implementeringsmodel
Den mest praktiske tilgang er faseopdelt. Ikke fordi modenhedsmodeller er elegante, men fordi organisationer sjældent kan absorbere store sikkerhedsændringer på én gang.
Fase 1: Få styr på identitet
Første fase bør handle om konti og login:
- gennemgå alle administratorroller
- indfør MFA konsekvent
- identificér break-glass-konti og beskyt dem særskilt
- blokér legacy authentication
- implementér basis-politikker i Conditional Access
- gennemgå inaktive brugere, gæster og gamle servicekonti
Brug gerne report-only, hvor det giver mening, inden politikker håndhæves. Microsoft beskriver denne arbejdsgang i guiden til Conditional Access deployment. Det er et vigtigt praktisk punkt, fordi mange fejl i Zero Trust-arbejde ikke skyldes for lidt sikkerhed, men for hurtig aktivering uden test.
Fase 2: Gør enheden til et krav i adgangsbeslutningen
Når identitetslaget er rimeligt stabilt, bør næste fase være at koble device posture på. Det betyder typisk:
- onboard Windows-enheder i Intune
- definér compliance policies
- kræv kryptering, opdateringsniveau og beskyttelse på endpoints
- brug Conditional Access til at kræve compliant eller hybrid-joined enheder for udvalgte apps
- håndtér BYOD med app protection policies, hvor fuld enrollment ikke er realistisk
Microsofts dokumentation om adgangsbeskyttelse med Intune og Conditional Access er nyttig her. Det væsentlige er, at enheden bliver en aktiv del af tillidsvurderingen. En bruger med korrekt password og MFA bør ikke automatisk få adgang fra en ukendt eller usund enhed.
Fase 3: Stram privilegier og adgangsstyring
Når basisadgangen er på plads, er næste skridt at reducere rettigheder:
- minimer antallet af permanente admin-rettigheder
- brug PIM hvor muligt
- gennemgå gruppemedlemskaber og adgangspakker
- ryd op i app-consent og enterprise applications
- etabler faste review-cyklusser for privilegeret adgang
Her er governance vigtigere end teknologi. Hvis ingen ejer oprydningen, vokser adgangsporteføljen igen.
Fase 4: Kobl data og trusselsrespons på
Til sidst giver det mening at koble flere signaler og datakontroller ind:
- brug Defender-signaler i drift og incident response
- klassificér følsomme data
- anvend labels og beskyttelsespolitikker hvor det giver forretningsmæssig mening
- sørg for logging, alarmer og opfølgning på hændelser
Først her begynder Zero Trust at ligne en sammenhængende driftsmodel frem for en samling enkeltstående kontroller.
Typiske fejl i virkelige Microsoft-miljøer
Der er nogle fejl, som går igen.
1. For meget fokus på værktøj, for lidt på rækkefølge
Organisationen køber E5 eller aktiverer en række sikkerhedsfeatures, men uden prioritering. Resultatet er mange dashboards og få reelle forbedringer. Start med identitet og adgang, før I udvider.
2. Conditional Access-politikker uden undtagelser og test
Hvis alt håndhæves med det samme, låser man hurtigt administratorer eller brugere ude. Hav altid styr på nødadgang, pilotgrupper og testforløb.
3. For mange globale administratorer
Det er stadig almindeligt. Det gør både risiko og fejlmargin unødigt stor.
4. Intune uden realistisk BYOD-strategi
Hvis politikken kun fungerer på firmastyrede enheder, men virkeligheden er blandet, opstår der hurtigt omgåelser og utilfredshed. Zero Trust skal passe til driften, ikke kun til den ideelle model.
5. Ingen løbende review-model
Zero Trust er ikke færdigimplementeret efter et projekt. Brugere skifter rolle, enheder bliver gamle, projekter opstår, apps bliver tilføjet, og gæsteadgang breder sig. Hvis ingen følger op, falder modenheden igen.
En pragmatisk start for de næste 90 dage
Hvis I vil i gang uden at gøre det til et halvårs analyseprojekt, er en enkel roadmap ofte nok:
De første 30 dage
- kortlæg administratorer og privilegerede konti
- identificér legacy auth og gamle konti
- indfør eller stram MFA
- definér de første Conditional Access-politikker
- udpeg break-glass-konti og dokumentér processen
Dag 31 til 60
- onboard de vigtigste enheder i Intune
- etabler compliance baseline
- kræv compliant enhed for admin-adgang og følsomme apps
- ryd op i grupper og brede rettigheder
Dag 61 til 90
- gennemgå enterprise apps og samtykker
- reducer antallet af permanente admin-roller
- aktivér relevante Defender-signaler og alarmer
- definér næste bølge: data protection, labels og mere moden governance
Det er ikke en komplet sluttilstand. Men det er et realistisk første skridt, som reducerer risiko hurtigt og uden at kræve et totalprojekt.
Hvad det betyder i praksis
Zero Trust med Microsoft virker bedst, når det behandles som en prioriteret driftsforbedring og ikke som et markedsføringsbegreb. Den største værdi kommer som regel ikke fra de mest avancerede features, men fra disciplinen i de grundlæggende kontroller: stærk identitet, tydelige adgangspolitikker, enheder med kendt tilstand, begrænsede privilegier og løbende validering.
For de fleste organisationer er den rigtige start ikke at gøre alt. Den rigtige start er at få identitet og adgang på plads, derefter koble endpoint-signaler på, og først bagefter udvide til mere avancerede kontroller. Det giver bedre sikkerhed, mindre friktion og en implementering, som driften faktisk kan bære.
Har I brug for at få prioriteret de første konkrete skridt i jeres Microsoft-miljø, kan vi hjælpe med at omsætte Zero Trust fra principper til en realistisk plan.