“Zero Trust” lyder som et slogan, men det er en brugbar sikkerhedsmodel, når den oversættes til konkrete kontroller. Princippet er enkelt: stol ikke på en bruger, en enhed eller en netværksforbindelse, blot fordi den ser ud til at befinde sig inden for organisationen. Verificér eksplicit, giv den mindst nødvendige adgang, og antag brud.
Modellen passer til moderne Microsoft-miljøer, fordi arbejdet har bevæget sig ud af den gamle perimeter. Medarbejdere logger ind hjemmefra, partnere skal have adgang, applikationer ligger i cloud-tjenester, og angribere starter oftere med stjålne legitimationsoplysninger end med malware på en server.
Microsoft har de vigtigste Zero Trust-byggeklodser i Microsoft 365 og Azure. I skal stadig have en plan. Værktøjer skaber ikke arkitektur af sig selv.
De tre principper i Zero Trust
Microsofts Zero Trust-vejledning er bygget op omkring tre principper:
- Verificér eksplicit: autentificér og autorisér hver anmodning ud fra identitet, enhed, lokation, applikation og risikosignaler.
- Brug mindst mulige adgang: giv brugere og systemer kun den adgang, de skal bruge, og kun så længe de skal bruge den.
- Antag brud: design, som om en angriber allerede kan være til stede, og begræns bevægelsesfrihed gennem segmentering, overvågning og stærke kontroller.
Principperne er ikke abstrakte, når I kortlægger dem til Microsoft-teknologi. Entra ID verificerer identitet. Conditional Access vurderer risiko. Intune tjekker enhedens compliance. Defender opdager trusler. Purview beskytter information. Implementeringsarbejdet består i at koble de dele sammen på en måde, forretningen kan drive videre.
Fase 1: sikr identiteten først
Identitet er udgangspunktet for Zero Trust. Kan en angriber logge ind som en rigtig bruger, redder netværksfirewalls jer ikke. Start med at gøre login sværere at misbruge og lettere at overvåge.
Aktivér multifaktorgodkendelse
Multifaktorgodkendelse er den enkeltvis vigtigste kontrol for de fleste organisationer. Microsoft oplyser, at MFA kan blokere mere end 99,9 % af forsøg på kontoovertagelse, når det håndhæves korrekt. Selve tallet betyder mindre end den driftsmæssige pointe: adgang med kun adgangskode er ikke længere acceptabelt.
Brug Security Defaults til meget små tenants, hvis I har brug for en hurtig baseline. For de fleste etablerede organisationer bør I bruge Conditional Access, så I kan styre politikker efter brugergruppe, applikation, risiko og enhedstilstand.
Blokér forældet autentificering
Forældede autentificeringsprotokoller understøtter ikke moderne MFA-flows. Angribere målretter dem stadig, fordi de er en svag vej ind i Microsoft 365.
Gennemgå login-logs i Microsoft Entra ID, og blokér forældet autentificering, når I har overblik over eventuelle resterende afhængigheder. Har en gammel applikation stadig brug for det, så behandl det som teknisk gæld med en ejer og en deadline.
Beskyt administratorkonti
Administratorkonti skal have stærkere kontroller end almindelige brugere. Som minimum:
- Adskil admin-konti fra daglige brugerkonti
- Kræv phishing-resistent MFA, hvor det er muligt
- Brug Privileged Identity Management til kvalificerede roller, hvis licensen tillader det
- Alarmér ved usædvanlige administrator-logins
- Gennemgå rolletildelinger regelmæssigt
Microsoft Entra Privileged Identity Management hjælper med at reducere fast tildelte rettigheder ved at gøre admin-roller tidsbegrænsede og godkendelsesbaserede.
Fase 2: implementér Conditional Access
Conditional Access er der, hvor Zero Trust bliver til politik. Det gør det muligt at bestemme, hvad der skal være opfyldt, før en bruger kan tilgå en applikation.
Start med et lille sæt klare politikker:
- Kræv MFA for alle brugere
- Kræv MFA eller stærkere kontroller for administratorroller
- Blokér forældet autentificering
- Kræv compliant eller hybrid joined enheder til følsomme applikationer
- Blokér eller begræns adgang fra højrisikolokationer, hvor det er relevant
- Kræv afhjælpning af login-risiko, hvis Entra ID Protection er tilgængelig
Brug report-only-tilstand før håndhævelse. Den viser, hvem der ville blive berørt, uden at blokere arbejdet med det samme. Gennemgå konsekvenserne, ret undtagelserne, og håndhæv derefter.
Undgå politik-uorden
Conditional Access kan blive svært at administrere, hvis enhver anmodning skaber endnu en politik. Hold modellen enkel. Brug navngivningskonventioner, dokumentér formålet med hver politik, og gennemgå undtagelser månedligt.
Gode politiknavne forklarer kontrollen:
CA001-AllUsers-RequireMFA-AllCloudAppsCA010-Admins-RequirePhishingResistantMFACA020-SensitiveApps-RequireCompliantDevice
Selve navngivningsformatet betyder mindre end konsekvensen. Seks forståelige politikker er bedre end 30 overlappende, som ingen tør røre.
Fase 3: tag enhederne med ind i adgangsmodellen
I en Zero Trust-model betyder enheden noget. Et login fra en patchet, managed bærbar er ikke det samme som et login fra en ukendt privat enhed.
Microsoft Intune giver jer det enhedssignal, Conditional Access kan bruge. Det giver også IT en måde at konfigurere og sikre Windows-, macOS-, iOS- og Android-enheder på.
Definér compliance, før I håndhæver den
En compliance-politik for enheder bør afspejle reel risiko, ikke en vilkårlig tjekliste. Almindelige baseline-krav omfatter:
- Diskkryptering aktiveret
- Understøttet OS-version
- Microsoft Defender kørende og sund
- Firewall aktiveret
- Ingen aktiv jailbreak- eller root-registrering på mobile enheder
- Krævede adgangskode- eller biometri-indstillinger
Intune-compliancepolitikker kan levere signal til Conditional Access. Start med at rapportere compliance, og håndhæv den derefter for udvalgte applikationer eller brugergrupper.
Byg sikkerhedsbaselines med omtanke
Microsofts sikkerhedsbaselines er nyttige, men anvend ikke enhver indstilling blindt. Test med en pilotgruppe, og dokumentér undtagelser. Nogle kontroller påvirker ældre applikationer, printere, VPN-klienter eller specialiseret forretningssoftware.
Målet er en baseline, der styrker sikkerheden og kan overleve den daglige drift.
Fase 4: opdag og reagér med Defender
Zero Trust antager brud, så detektion betyder noget. Microsoft Defender-produkterne leverer signaler på tværs af identitet, endpoint, e-mail, cloud-apps og Azure-ressourcer.
For Microsoft 365-miljøer er de typiske startpunkter:
- Microsoft Defender for Endpoint
- Microsoft Defender for Office 365
- Microsoft Defender for Cloud Apps
- Microsoft Defender for Cloud til Azure-workloads
I behøver ikke alle produkterne fra dag ét. Start, hvor risikoen er størst. For mange organisationer er endpoint- og e-mailbeskyttelse de første prioriteter, fordi angreb oftest starter der.
Kobl signaler til handling
Detektion uden reaktion skaber blot støj. Beslut, hvem der håndterer alarmer, hvilke alarmer der betyder mest, og hvad der sker, når en bruger eller enhed bliver risikabel.
Eksempler:
- Et højrisiko-login kræver nulstilling af adgangskode og MFA
- En enhed med aktiv malware mister adgang til følsomme apps
- En mistænkt phishing-kampagne udløser en postkasseundersøgelse
- En alarm om en privilegeret konto gennemgås øjeblikkeligt
Har organisationen ikke selv kapacitet til security operations, må I beslutte, om en partner eller managed service skal stå for overvågning og reaktion.
Fase 5: beskyt data med Purview
Zero Trust handler ikke kun om login og enheder. Data skal også beskyttes. Microsoft Purview kan hjælpe med at klassificere, mærke, opbevare og beskytte følsom information.
Start med et lille sæt følsomhedsmærker, som medarbejderne kan forstå:
- Offentlig
- Intern
- Fortrolig
- Meget fortrolig
Beslut derefter, hvad hvert mærke betyder. Meget fortrolige filer kan for eksempel kræve kryptering og blokere ekstern deling. Interne filer kan tillade normalt samarbejde inden for organisationen.
Microsoft Purview Information Protection virker bedst, når mærkerne matcher forretningens eget sprog. Kan brugerne ikke forstå mærkerne, vil de enten ignorere dem eller vælge tilfældigt.
En trin-for-trin-tidsplan
For en typisk dansk Microsoft 365-organisation ser en realistisk tidsplan sådan ud:
Uge 1-2: vurdér og prioritér
- Gennemgå den nuværende MFA-dækning
- Tjek brugen af forældet autentificering
- Eksportér administratorers rolletildelinger
- Gennemgå Conditional Access-politikker og huller
- Identificér følsomme applikationer og dataområder
Uge 3-6: identitetsbaseline
- Håndhæv MFA for alle brugere
- Blokér forældet autentificering
- Adskil admin-konti
- Anvend stærkere kontroller på privilegerede roller
- Konfigurér grundlæggende login-alarmer
Uge 7-10: enhedsbaseline
- Tilmeld prioriterede Windows-enheder i Intune
- Definér compliance-politikker
- Test sikkerhedsbaselines med en pilotgruppe
- Kræv compliant enheder til udvalgte applikationer
Uge 11-14: detektion og reaktion
- Aktivér Defender-dækning for prioriterede brugere og enheder
- Definér ejerskab af alarmer
- Opret responsplaner for typiske scenarier
- Gennemgå risikable brugere og enheder ugentligt
Uge 15-18: databeskyttelse
- Definér følsomhedsmærker
- Pilotér mærker på HR-, finans- eller ledelsesdata
- Gennemgå ekstern deling
- Anvend kontroller på de mest følsomme områder først
Tidsplanen kan være kortere eller længere afhængigt af størrelse og modenhed. Rækkefølgen betyder mere end de præcise datoer.
Almindelige implementeringsfejl
Zero Trust-projekter fejler typisk, når de bliver for brede eller for teoretiske.
At forsøge at gøre alt på én gang
Start ikke med hvert eneste Microsoft-sikkerhedsprodukt, hver eneste politik og hver eneste afdeling. Start med identitet, admin-adgang og de mest risikofyldte data.
At håndhæve politikker uden report-only-test
Conditional Access kan blokere kritisk arbejde, hvis den rulles ud uforsigtigt. Brug report-only-tilstand, gennemgå konsekvenserne, og kommunikér før håndhævelse.
At ignorere undtagelser
Enhver undtagelse bør have en ejer, en begrundelse og en udløbsdato. Permanente undtagelser bliver til skjult risiko.
At behandle Zero Trust som et engangsprojekt
Modellen skal genbesøges. Brugere skifter, enheder ældes, applikationer flytter sig, og angribere tilpasser sig. Byg månedlig eller kvartalsvis gennemgang ind i driften.
Sådan ser det gode ud
En moden Zero Trust-implementering betyder ikke, at brugerne konstant afbrydes. Den betyder, at normal adgang er gnidningsfri, når risikoen er lav, og at strengere kontroller træder til, når risikoen er højere.
Gode tegn er blandt andet:
- MFA er håndhævet, og forældet autentificering er blokeret
- Admin-rettigheder er begrænsede og bliver gennemgået
- Følsomme applikationer kræver compliant enheder
- Risikable logins udløser handling
- Sikkerhedsalarmer har ejere
- Følsomme data har mærker og delingsregler
- Undtagelser er synlige og midlertidige
Zero Trust er en praktisk måde at reducere risiko i Microsoft-miljøer på. Start med identitet, kobl enheder og detektion til, og beskyt derefter data. Hold det forståeligt nok til, at forretningen kan leve med det.
Book en strategisk samtale – vi gennemgår jeres nuværende Microsoft-setup og giver jer en klar prioriteret plan for Zero Trust-implementering.