Når ledelsen beslutter at få Microsoft 365 testet, lander det praktiske arbejde hos IT: testkonti, licensoverblik, kontaktpersoner og bagefter en bunke fund, der skal fordeles. En Microsoft 365-test afprøver jeres egen lejer, altså de konti, roller, delingsindstillinger, postkasser og tilknyttede programmer, som I eller driftsleverandøren har sat op. Svaret på, hvad testen kan og må, hviler på to ting: Microsofts fælles regler for test af deres onlinetjenester og jeres egen skriftlige tilladelse til testeren.
Lejeren er jeres, platformen er Microsofts
Microsoft beskriver ansvaret i skyen som delt. For en softwaretjeneste som Microsoft 365 står Microsoft for datacentre, netværk og selve tjenesten. Kunden beholder ansvaret for data, konti, adgangsstyring og de indstillinger, der er valgt. Det er den del, testen handler om.
For IT-afdelingen betyder det, at fundene som udgangspunkt vil være valg truffet i jeres egen administrationsflade. Det er en fordel. Et fund om en indstilling kan rettes af den, der passer lejeren, uden at vente på en leverandør. Det er også en forpligtelse: ingen andre retter det for jer.
Rammerne for selve testen står i Microsofts regler for penetrationstest af deres onlinetjenester. De begrænser aktiviteten til jeres egen lejer, forbyder blandt andet overbelastning af tjenesten og brug af andres adgangsoplysninger og giver Microsoft ret til at afbryde aktivitet, også under en gyldig test. Køberens side af reglerne og afgrænsningen er beskrevet på penetrationtest.dk.
Fem områder, testen typisk dækker
En test af lejeren kan ikke dække alt på én gang. Opdragene samler sig typisk om fem områder:
- Identitet og login · hvordan medarbejdere og eksterne logger ind, og hvor reglerne for tofaktor har huller. → Entra ID-test
- Administrative roller · antallet af personer med vide rettigheder, og om rollerne er i brug til almindeligt kontorarbejde. → Administrative roller i Entra ID
- Data og deling · hvad der er delt med personer uden for virksomheden, og hvilke links der stadig virker. → Ekstern deling i SharePoint, OneDrive og Teams
- Mail · videresendelse ud af huset, delte postkasser og hvem der har adgang til andres post. → Exchange Online
- Programmer med adgang · apps, der har fået lov til at læse mail, filer eller kalender.
Vælg de områder, hvor svaret betyder mest for jer, og skriv dem ind i opdraget. Et ønske om at få “det hele” testet giver en bred, men tynd rapport.
Tænk også over, hvilket udgangspunkt testen skal have. En test fra en almindelig medarbejderkonto svarer på, hvad en kompromitteret bruger kan nå. En gennemgang med en læsekonto svarer på, hvordan lejeren er sat op. De to giver forskellige svar, og mange IT-afdelinger har brug for begge. → Konfigurationsgennemgang eller penetrationstest af cloud
Det, IT-afdelingen gør klar
Forberedelsen afgør, hvor meget testeren når. Det meste er arbejde, som kun IT kan lave:
- Testkonti · en almindelig medarbejderkonto, en konto der kan læse indstillinger uden at ændre dem, og eventuelt en gæst fra en anden organisation.
- Licensoverblik · hvilke licenser der er i brug. Mange indstillinger findes kun i bestemte abonnementer, og testeren skal kunne skelne mellem det, der er slået fra, og det, der ikke findes.
- Kendte undtagelser · regler for login, der bevidst ikke gælder alle, og begrundelsen for dem.
- Partnere med adgang · driftsleverandører og andre eksterne, der administrerer dele af lejeren.
- Skriftlig tilladelse · underskrevet af den, der må give den, så den kan fremvises, hvis Microsoft henvender sig om aktiviteten.
Passer en driftsleverandør lejeren, skal leverandøren med i forberedelsen fra starten. Det kan være leverandøren, der kender undtagelserne, og leverandørens egne konti er en del af det, testen ser på. Aftal på forhånd, hvem der modtager fund, der handler om leverandørens adgang.
Opret testkontiene, så de ligner rigtige medarbejdere. En testkonto uden tofaktor eller med særlige undtagelser afprøver en opsætning, ingen medarbejder har.
Under testen
Testen kører i den lejer, medarbejderne bruger hver dag. Aftal derfor, hvem der overvåger. Sikkerhedsfunktioner i Microsoft 365 kan reagere på testerens aktivitet, og det er godt. Det skal bare ikke føre til, at en anden i IT låser testkontiene og sender servicedesken i gang. → Alarmer under testen
Hav en kontaktperson, der kan svare hurtigt, hvis testeren støder på data, der ikke burde være tilgængelige. Fund af følsomme data skal håndteres efter en aftalt fremgangsmåde, ikke ad hoc. Notér også selv, hvad jeres overvågning registrerede i testperioden. Sammenholdt med testerens tidslinje viser det, om I kunne have set aktiviteten, hvis den havde været ægte.
Når fundene kommer
Fund i Microsoft 365 falder groft i tre grupper. Nogle er indstillinger, der kan rettes på en eftermiddag, fx videresendelse ud af huset eller standardtypen for delingslinks. Andre kræver en beslutning i forretningen, fx hvem der må dele med eksterne. Den tredje gruppe kræver en anden licens og er dermed et budgetspørgsmål.
Rækkefølgen bør følge alvorligheden og ikke det, der er nemmest. Et fund om en administratorkonto uden tofaktor vejer tungere end ti små fund om standardindstillinger, også selv om de ti er hurtigere at lukke.
Sorter fundene i de tre grupper, før de lægges i opgavesystemet. Så får de hurtige rettelser en ejer i IT, beslutningerne går til ledelsen, og licensspørgsmålene kommer med i næste budget. → Fra fund til opgave
Som supplement kan I sammenligne opsætningen med en offentligt tilgængelig konfigurationsbaseline. CISA har fx udgivet anbefalede baselines for Microsoft 365, skrevet til amerikanske myndigheder, men brugbare for alle. En baseline siger, hvad der bør være slået til. Testen viser, hvad en konto faktisk kan.
Det skal I lade være med
- At give testeren en global administratorkonto. Testen viser så kun, hvad en administrator kan.
- At undtage testkontiene fra reglerne for login. Resultatet passer ikke på jeres medarbejdere.
- At glemme driftsleverandøren. Partnere med adgang skal kende testvinduet og være med i opdraget.
- At rette alt samme dag. En ændret regel for login kan låse medarbejdere ude.
- At blande licensspørgsmål med fejl. En manglende funktion er en beslutning, ikke en forglemmelse.
Hvad kan og ikke kan konkluderes
Testen viser, hvad de anvendte konti kunne se og gøre i de valgte områder af lejeren på testtidspunktet. Den siger ikke noget om Microsofts egen platform, og den dækker ikke områder, der ikke var med i opdraget. Indstillinger ændrer sig løbende, både fordi I ændrer dem, og fordi Microsoft tilføjer nye. Et godt resultat er derfor et øjebliksbillede.
Tjekliste før Microsoft 365-testen
- ☐ Er de områder, testen skal dække, skrevet ind i opdraget?
- ☐ Er testkontiene oprettet med almindelige medarbejderes regler?
- ☐ Har testeren fået et overblik over licenser?
- ☐ Er kendte undtagelser og deres begrundelse samlet?
- ☐ Kender driftsleverandøren testvinduet?
- ☐ Ligger den skriftlige tilladelse klar?
- ☐ Er det aftalt, hvem der overvåger alarmer?
Kilder
- Microsoft: Penetration Testing Rules of Engagement: test kun i egen lejer, forbudte aktiviteter, Microsofts ret til at afbryde aktivitet.
- Microsoft Learn: Shared responsibility in the cloud: kunden beholder ansvaret for data, konti, adgangsstyring og indstillinger, også i Microsoft 365.
- CISA: Secure Cloud Business Applications (SCuBA): konfigurationsbaselines for Microsoft 365, skrevet til amerikanske civile myndigheder og tilgængelige for alle organisationer.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Ekstern deling i SharePoint, OneDrive og Teams · Logning i Microsoft 365, Azure og AWS · Copilot og andre AI-assistenter i Microsoft 365
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
