IT-afdelinger, der vil have deres Microsoft 365, Azure eller AWS undersøgt, bliver hurtigt mødt af to ord: gennemgang og test. De lyder ens, men de svarer på forskellige spørgsmål. En konfigurationsgennemgang ser bredt på, hvordan miljøet er sat op, og sammenligner det med anbefalinger. En penetrationstest afprøver, hvad en bestemt konto eller adgangsvej faktisk kan nå. Valget hviler på, hvad I vil vide bagefter, og det er sjældent et enten eller.
To metoder, to slags svar
En konfigurationsgennemgang foregår typisk med en konto, der kan læse indstillinger uden at ændre dem. Den, der gennemgår, går systematisk igennem områder som login, roller, deling, logning og netværksadgang og noterer, hvor opsætningen afviger fra en anbefaling eller fra jeres egne regler. Resultatet er bredt. Det dækker mange indstillinger, også dem, der ikke umiddelbart kan misbruges.
En penetrationstest tager udgangspunkt i en situation: en almindelig medarbejders konto, en gæst, en adgangsnøgle, der er kommet i forkerte hænder, eller en tjeneste, der vender ud mod internettet. Testeren afprøver, hvor langt man kan komme derfra. Resultatet er dybt. Det viser sammenhænge mellem indstillinger, som hver for sig ser harmløse ud.
Forskellen kan siges kort: gennemgangen svarer på “er vi sat op efter anbefalingerne?”, testen svarer på “hvad kan en angriber gøre med det, vi har?”.
Hvornår gennemgangen passer bedst
Gennemgangen er stærkest, når spørgsmålet handler om bredde og om, hvorvidt jeres grundopsætning holder:
- Nyt miljø · lejeren eller abonnementet er sat op for nylig, og I vil vide, om fundamentet er i orden.
- Skift af driftsleverandør · I overtager et miljø og har brug for et overblik over, hvad der er slået til og fra. → Overdragelse ved skifte af leverandør
- Mange abonnementer eller konti · bredden er stor, og I har brug for at finde mønstre.
- Krav om dokumentation · I skal kunne vise, at opsætningen er gennemgået mod en kendt baseline.
Offentlige baselines gør gennemgangen lettere at bestille og at læse. CISA har fx udgivet anbefalede konfigurationsbaselines for Microsoft 365. Til Azure og AWS har udbyderne deres egne anbefalinger. En baseline er dog altid et udgangspunkt, som I tilpasser til jeres virksomhed. → Hærdningsstandarder
Hvornår testen passer bedst
Testen er stærkest, når spørgsmålet handler om konsekvens:
- Efter en hændelse eller et nærved · I vil vide, hvad en kompromitteret konto kunne have nået.
- Følsomme data i skyen · I vil vide, om data kan nås ad andre veje end de tilsigtede.
- Sammenhæng mellem lokalt og cloud · et fund i det ene miljø kan åbne for det andet. → Hybrid identitet
- Efter større ændringer · nye integrationer, nye apps eller ny netværksopbygning.
Den britiske myndighed NCSC beskriver penetrationstest som en måde at få sikkerhed for, at ens egne processer for sårbarhedsstyring virker, og ikke som den primære metode til at finde sårbarheder. Den tankegang passer godt til cloud. Gennemgangen og den løbende overvågning finder afvigelserne. Testen viser, om afvigelserne betyder noget i praksis.
Kombinationen, der kan give mest
Mange IT-afdelinger får mest ud af en kombination: først en gennemgang, der rydder de åbenlyse forhold af vejen, og derefter en test, der går i dybden med de områder, hvor risikoen er størst. Rækkefølgen sparer tid. En tester, der bruger dagene på at notere standardindstillinger, når mindre af det, kun en test kan vise.
Den omvendte rækkefølge kan også give mening. Hvis ledelsen har brug for at forstå konsekvensen, før der bruges tid på en lang liste af indstillinger, kan en kort test åbne for prioriteringen.
For en MSP med mange kunder kan kombinationen se anderledes ud. En gennemgang af alle kunders lejere mod den samme baseline giver et overblik over, hvor standardopsætningen holder. En test hos et par udvalgte kunder viser, om de fælles administrationsveje er stærke nok. Begge dele siger noget om leverandørens egen drift og ikke kun om den enkelte kunde.
Skriv under alle omstændigheder ind i opdraget, hvilken metode der bruges på hvilket område. En rapport, der blander de to uden at sige det, er svær at læse bagefter.
Hvad IT-afdelingen forbereder
Forberedelsen afhænger af metoden:
- Til gennemgangen · en læsekonto med adgang til indstillinger i alle relevante tjenester, et overblik over licenser og abonnementer og jeres egne regler, hvis I har dem.
- Til testen · testkonti, der ligner rigtige brugere, et klart udgangspunkt, kendte undtagelser og en kontaktperson under testvinduet.
- Til begge · en liste over, hvad der er i scope, og hvilke dele der ejes af en leverandør.
Husk udbydernes regler for test. Microsoft og AWS har hver deres, og de gælder, uanset hvilken metode der bruges. → AWS’ politik for penetrationstest
Sådan læser I resultaterne
En gennemgang kan give en lang liste med mange fund af lav eller middel alvorlighed. Det er ikke et tegn på, at miljøet er dårligt. Det er en følge af metoden. Sorter listen efter, hvad der kan rettes hurtigt, og hvad der kræver en beslutning.
En test giver færre fund, men hvert fund har en historie: fra hvilken konto, via hvilke indstillinger, til hvilke data. Læs dem som kæder. Det kan være nok at bryde ét led for at lukke hele vejen. Det ene led kan være en indstilling, som gennemgangen allerede havde på listen som et mindre fund.
Det skal I lade være med
- At bestille en test og forvente fuld dækning af indstillinger. Det er gennemgangens opgave.
- At bestille en gennemgang og forvente at se konsekvenser. Det er testens opgave.
- At bruge en baseline uden at tilpasse den. Ikke alle anbefalinger passer til jeres drift.
- At lade metoderne flyde sammen i rapporten. Bed om tydelig markering af, hvad der er afprøvet, og hvad der er aflæst.
- At glemme logningen. Uanset metode bør I se, hvad jeres egne spor viste. → Logning i Microsoft 365, Azure og AWS
Hvad kan og ikke kan konkluderes
En gennemgang kan konkludere, at opsætningen på et givet tidspunkt fulgte eller afveg fra en bestemt baseline. Den kan ikke vise, hvad afvigelserne betyder, når de kombineres. En test kan vise, hvad bestemte konti og adgangsveje kunne nå. Den kan ikke garantere, at der ikke findes andre veje, og den dækker kun det, der var i scope. Ingen af dem kan sige noget om udbyderens egen platform.
Tjekliste til valget
- ☐ Har I formuleret, hvad I vil vide bagefter?
- ☐ Er det besluttet, om bredde eller dybde er vigtigst lige nu?
- ☐ Er der valgt en baseline, hvis der skal laves en gennemgang?
- ☐ Er udgangspunktet for testen beskrevet, hvis der skal testes?
- ☐ Står det i opdraget, hvilken metode der bruges hvor?
- ☐ Er udbydernes regler for test læst?
Kilder
- NCSC (UK): Penetration testing: penetrationstest som sikkerhed for, at egne processer for sårbarhedsstyring virker, ikke som primær metode til at finde sårbarheder.
- CISA: Secure Cloud Business Applications (SCuBA): offentlige konfigurationsbaselines for Microsoft 365, som organisationer kan tilpasse.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: AWS-test · Flere cloudmiljøer i samme test
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
