Microsoft 365 sikkerhed check: Identitet og backup

De fleste angreb mod SMB starter med adgang: en stjålet session, en for svag MFA eller en konto, der aldrig burde have haft rettigheder. Når angriberen først er inde, går de efter backuppen før de går efter data. Et Microsoft 365 sikkerhed check kan typisk lukke de tre huller på få uger: identitet, adgangsregler og gendannelse.

• Skift fra “MFA kan stadig phishes” til phishing-resistent login: udrul passkeys/FIDO2 og fjern SMS, hvor det giver mening.
• Stop token-tyveri i praksis: kræv compliant enheder og stram session-kontroller med Conditional Access.
• Adskil retention fra backup: retention hjælper jura – backup hjælper jer tilbage i drift efter ransomware.
• Gør backup svær at slette: brug immutable/off-site backup og test gendannelse på tid.
• Få styr på ikke-menneskelige identiteter: kortlæg servicekonti, API-nøgler og app-registreringer og fjern “evige” secrets.

Hvorfor jeres MFA ikke længere er nok

Angribere går i stigende grad uden om klassisk MFA ved at stjæle sessionen (token theft). Microsoft peger i Digital Defense Report 2025/2026 på både væksten i token-baserede angreb og at phishing-resistent MFA (fx passkeys/FIDO2) stopper langt de fleste identitetsangreb.

Beslutningsregel: hvornår skal I vælge passkeys?

• Hvis I har eksterne brugere (konsulenter/leverandører): brug passkeys eller FIDO2-nøgler for at reducere kontoovertagelser.
• Hvis I har høj risiko på e-mail (økonomi, ledelse, HR): start her. Disse konti rammes først.
• Hvis I stadig bruger SMS-MFA: planlæg udfasning. SMS er en svag nødmekanisme, ikke et mål.

Før → Efter #1
Før: Login med password + SMS/Authenticator på alle – uanset enhed og risiko.
Efter: Passkeys/Windows Hello for Business for nøglebrugere + Conditional Access, der blokerer ukendte enheder og risikable logins. Resultat: færre succesfulde phishingforsøg og mindre support på “jeg blev låst ude”.

Sådan bruger I Conditional Access til at gøre adgang kedelig for angribere

Conditional Access i Microsoft Entra ID er jeres daglige håndhævelse. Ikke politik på papir. Målet er enkelt: kun de rigtige brugere på de rigtige enheder får adgang til de rigtige data.

Tjekliste: 6 regler vi typisk implementerer i et Entra ID setup

Kontrol	Hvad I sætter	Hvad I kigger efter i audit
1) Blokér legacy authentication	Deaktivér protokoller der omgår moderne login	Sign-ins med “legacy client” og gamle mail-klienter
2) Kræv phishing-resistent MFA for admin	FIDO2/passkeys/Windows Hello for admins	Admins med SMS/voice tilbage som fallback
3) Kræv compliant device til SharePoint/OneDrive	Kun Intune-compliant enheder kan synkronisere	“Personal device” adgang til følsomme sites
4) Session controls	Stram sign-in frekvens og app-sessioner ved risiko	Meget lange sessioner på ukendte netværk
5) Risiko-baseret blokering	Blokér “high risk” sign-ins og kræv step-up ved “medium”	Brugere med gentagne risikoflag uden opfølgning
6) Adgang for leverandører	Separate policies for B2B-gæster + tidsbegrænset adgang	Gæstekonti uden ejer, uden udløb og med brede rettigheder

Hvis I vil holde det simpelt: start med at beskytte administratorer og e-mail. Udvid derefter til SharePoint/Teams og de systemer, der kan stoppe drift (ERP, løn, sagsstyring).

Hvorfor Microsoft 365 ikke er backup (og hvad der er)

Microsoft 365 har papirkurv, versionshistorik og retention. Det hjælper ved fejl og krav til opbevaring. Det er ikke det samme som at kunne gendanne hurtigt, når en angriber har krypteret eller slettet data på tværs af brugere og sites.

Beslutningsregel: retention vs. backup

• Retention: Brug når I skal bevare data for jura/compliance, også hvis brugeren vil slette.
• Backup: Brug når I skal gendanne data og hele konti/sites hurtigt efter ransomware, fejlkonfiguration eller insider-hændelser.
• Hvis jeres mål er “tilbage i drift på X timer”, så er det backup + testet restore der afgør det.

Før → Efter #2
Før: “Vi har retention, så vi er dækket” + restore sker manuelt og sjældent.
Efter: 3-2-1-princip med en immutable kopi off-site + kvartalsvise gendannelsestests (mailbox, SharePoint-site, Teams). Resultat: I kan dokumentere recovery og reducere nedetid, når det brænder.

Tjekliste: 3-2-1 backup for Microsoft 365 og Azure

1. 3 kopier: produktion + 2 backup-kopier (fx én primær og én sekundær).
2. 2 medier/placeringer: adskil platforme eller storage-konti, så én fejl ikke rammer alt.
3. 1 off-site og immutable: krypteret kopi, som ikke kan slettes/overskrives inden for jeres retention-vindue.

Konkrete kontroller vi måler på

• Scope: Dækker backuppen Exchange, OneDrive, SharePoint og Teams (samt evt. Azure VM’er/SQL)?
• Adgang: Er backup-administrator adskilt fra global admin? Bruger I separate konti og stærk MFA/passkeys?
• Immutability: Kan en kompromitteret admin slette backup-job og repositories? (Veeam peger i Data Protection Trends 2026 på at mange angreb forsøger at slette backuppen først.)
• Restore-tid: Har I et mål (RTO) pr. system og en målt gendannelsestid fra test?
• Dokumentation: Kan I vise en enkel Incident Response-plan, som ENISA fremhæver som typisk mangel i NIS2-audits?

Fejl der koster jer mest: servicekonti og “evige” nøgler

Ikke-menneskelige identiteter (service accounts, app registrations, API keys) bliver ofte glemt, fordi “det virker jo”. Det er samtidig en voksende angrebsflade, fordi en lækket nøgle kan give adgang uden MFA.

Mini-tjekliste: sådan rydder I op på 30 dage

• Kortlæg alle app-registreringer og servicekonti: hvem ejer dem, og hvad bruges de til?
• Fjern permanente secrets: brug certifikater eller managed identities hvor muligt.
• Sæt udløb på nøgler og kræv rotation med ansvarlig ejer.
• Log og alarmer: alarmer på nye credentials, ændringer i permissions og usædvanligt token-forbrug.

FAQ: spørgsmål vi får om Microsoft 365 sikkerhed check

Hvad er et Microsoft 365 sikkerhed check helt konkret?

En gennemgang af jeres Entra ID (identitet), Conditional Access (adgangsregler), admin-rettigheder, enheds-krav (Intune) og backup/restore. Leverancen bør være en prioriteret plan + implementering af de vigtigste ændringer.

Er passkeys det samme som MFA?

Passkeys (FIDO2) erstatter typisk password og giver phishing-resistent login. Det kan ses som “stærkere MFA”, fordi brugeren beviser besiddelse af en nøgle/enhed og ofte biometri/PIN lokalt. Tommelfingerregel: brug passkeys til admins og højrisiko-konti først.

Hvilke Conditional Access regler skal vi starte med?

Start med: (1) blokér legacy authentication, (2) kræv phishing-resistent MFA for administratorer, (3) kræv compliant device til SharePoint/OneDrive. Det giver hurtigt fald i kontoovertagelser og datalæk.

Er Microsoft 365 backup et lovkrav (NIS2/GDPR)?

Reglerne handler om, at I kan beskytte og gendanne data og fortsætte driften. ENISA peger i 2026 på strengere fokus på krypteret, off-site backup og dokumenteret hændelseshåndtering i audits. Beslutningsregel: hvis I ikke kan bevise restore med test, er I ikke “klar”, uanset hvad der står i jeres politik.

Hvor ofte skal vi teste gendannelse?

Minimum kvartalsvist for de vigtigste datatyper (mailbox, SharePoint-site, Teams) og efter større ændringer (ny backup-platform, stor migrering, ændret retention). Mål tiden og gem log/rapport som dokumentation.

Kan vi spare et tredjeparts antivirus væk med Defender for Business?

Ofte ja, især hvis I allerede har Microsoft 365 Business Premium. Gartner fremhæver i Top Tech Trends for SMBs 2026 konsolidering som en tydelig retning. Tommelfingerregel: hvis I alligevel mangler EDR, device compliance og central politik, så giver det mere effekt at udnytte Defender + Intune end at betale for et isoleret antivirus.

Sådan kommer I i gang de næste 14 dage

1. Udpeg 5 konti (IT/admin, CFO, HR, salgschef, ekstern leverandør) og skift dem til passkeys/FIDO2, hvor muligt.
2. Implementér 3 Conditional Access baselines: blokér legacy auth, kræv phishing-resistent MFA for admins, kræv compliant device til SharePoint/OneDrive.
3. Lav en backup-gap-liste: hvad dækkes (Exchange/SharePoint/Teams/Azure), hvor er off-site, og er der immutability?
4. Kør én restore-test (fx en mailbox + et SharePoint-site) og skriv RTO/RPO ned som jeres første mål.
5. Kortlæg ikke-menneskelige identiteter: liste over app-registreringer/secrets, ejer og udløb. Start rotation på de 10 mest kritiske.