En test af jeres cloudmiljøer er en sjælden mulighed for at få svar på et spørgsmål, der ellers først stilles under en hændelse: kan vi se, hvad der skete? Testeren laver aktivitet, der ligner en angribers, på kendte tidspunkter og med kendte konti. Om jeres logning kan følge med, afhænger af to forhold, som alle tre platforme beskriver i deres dokumentation: hvad der registreres som standard, og hvor længe det gemmes, før det slettes.
Hvorfor cloudlogning er anderledes
I et lokalt netværk ejer I serverne, og logfilerne ligger hos jer. I Microsoft 365, Azure og AWS registrerer udbyderen meget af aktiviteten for jer, men på udbyderens betingelser. Nogle spor er slået til fra start og gemmes i en fast periode. Andre skal slås til, før de findes. Og når perioden udløber, er sporene væk, medmindre I selv har sendt dem et andet sted hen.
Det betyder, at den logning, I har, kan være bestemt af standardindstillinger og licenser frem for et bevidst valg. En test gør det synligt.
Hvad der gemmes som standard
De tre platforme har hver deres model. Kort sagt, ifølge udbydernes egen dokumentation:
- Microsoft 365 · revisionsloggen i Microsoft Purview gemmer som standard poster i 180 dage. Med bestemte licenser gemmes poster fra Exchange, SharePoint, OneDrive og Entra ID i et år, og med en tilkøbslicens kan perioden blive længere.
- Azure · aktivitetsloggen registrerer administrative handlinger på ressourcer, fx når en ressource oprettes eller ændres, og gemmer dem i 90 dage. Logs fra selve ressourcerne, fx når nogen henter en hemmelighed eller spørger en database, indsamles ikke som standard og kræver en diagnostisk indstilling.
- AWS · CloudTrail viser hændelseshistorikken for administrative handlinger de seneste 90 dage i hver region. Skal sporene gemmes længere eller sendes videre til overvågning, kræver det, at I opretter et såkaldt trail eller et tilsvarende datalager.
Læg mærke til forskellen mellem administrative handlinger og brug af data. Alle tre platforme registrerer som udgangspunkt, når nogen ændrer opsætningen. Det er sværere at få svar på, hvem der læste en fil, hentede en nøgle eller spurgte en database, hvis ingen har slået den slags logning til. For en test, der handler om adgang til data, er det netop de spor, der betyder mest.
Perioderne kan ændre sig, og licensforhold spiller ind. Tjek derfor den aktuelle dokumentation for jeres abonnementer, før I regner med dem.
Det, testen kan afsløre
En test i cloud giver typisk tre slags svar om logningen:
- Sporene findes ikke · fordi den relevante log aldrig blev slået til, fx logs fra lagerkonti eller databaser i Azure.
- Sporene findes, men forsvinder · fordi de kun gemmes i standardperioden, og ingen sender dem videre.
- Sporene findes, men ingen ser dem · fordi der ikke er alarmer eller en person, der kigger.
Det sidste svar kan være det, der overrasker mest i ledelsen, fordi der er betalt for overvågning. Det er heller ikke et teknisk problem, men et spørgsmål om ansvar og tid. Opdagelse og reaktion som selvstændig disciplin hører hjemme i en anden type øvelse. → Opdagelse og reaktion
Før testen: sørg for, at der er noget at sammenligne med
Sammenligningen kræver, at sporene findes, når testen er slut. Forbered det sådan:
- Kontrollér, hvad der er slået til · revisionslog i Microsoft 365, aktivitetslog og ressourcelogs i Azure, trails i AWS.
- Sikr opbevaringen · send sporene til et sted, hvor de gemmes mindst så længe, sammenligningen tager.
- Aftal en tidslinje · bed testeren om en oversigt over aktiviteter med tidspunkt, konto og mål.
- Synkroniser tidszoner · cloudplatforme bruger typisk universel tid, mens jeres egne noter måske bruger dansk tid.
- Udpeg en ansvarlig · den person i IT, der laver sammenligningen bagefter.
Den samme fremgangsmåde bruges på det lokale netværk, men platformene er forskellige. → Logning under den interne test
Efter testen: sammenlign og ret
Gå testerens tidslinje igennem punkt for punkt, gerne sammen med den, der passer overvågningen til daglig. For hver aktivitet skal I svare på tre spørgsmål: blev den registreret, kunne I have fundet den, og ville nogen have reageret? Svarene bliver til opgaver.
Typiske rettelser på begrebsniveau er at slå logs til i de ressourcer, der rummer følsomme data, at forlænge opbevaringen for de vigtigste spor, at samle logs fra flere platforme ét sted og at oprette alarmer for få, tydelige hændelser, fx nye administratorer eller nye adgangsnøgler. → Logning efter testen
Prioritér rettelserne efter, hvad testen faktisk nåede. Hvis testeren kom til følsomme data uden at efterlade spor, er det første opgave at få netop den adgangsvej logget. Hvis sporene fandtes, men forsvandt, er opbevaringen det næste. Hvis sporene fandtes og blev gemt, men ingen så dem, handler det om alarmer og bemanding.
Vælg få alarmer, der bliver fulgt op, frem for mange, der bliver ignoreret. Et overvågningssystem, som ingen tør slå fra, men heller ikke læser, giver en falsk tryghed.
Når en driftsleverandør eller MSP har logningen
Nogle virksomheder har lagt overvågningen hos en leverandør. Aftal i så fald før testen, om leverandøren skal informeres eller ej, og hvem der modtager testerens tidslinje. Hvis leverandøren skal være uvidende, fordi I vil se, om aktiviteten opdages, skal en person hos jer kunne stoppe en eskalering, der går for vidt. → Alarmer under testen
Bed også leverandøren om at bekræfte, hvor længe logs gemmes hos dem, og hvem der har adgang til dem. Det er en del af svaret på, om I kan bruge sporene i en reel hændelse.
Det skal I lade være med
- At antage, at alt logges. Mange ressourcelogs skal slås til, før de findes.
- At vente med sammenligningen. Standardperioderne er begrænsede, og sporene forsvinder.
- At glemme licenserne. Opbevaringsperioden i Microsoft 365 afhænger af dem.
- At slå alt til uden en plan. Store mængder logs, som ingen læser, koster uden at hjælpe.
- At overlade sammenligningen til testeren alene. Det er jeres spor, og I skal kunne læse dem.
Hvad kan og ikke kan konkluderes
Sammenligningen viser, om bestemte aktiviteter fra testen blev registreret, og hvor længe sporene var tilgængelige. Den siger noget om logningens dækning, ikke om hele beredskabets evne til at reagere. En aktivitet, der ikke var med i testen, kan stadig være uden spor. Og en log, der fandtes, er ikke det samme som en hændelse, der blev opdaget.
Tjekliste til cloudlogning
- ☐ Ved I, hvad der logges som standard på hver platform?
- ☐ Er ressourcelogs slået til for følsomme ressourcer?
- ☐ Gemmes sporene længe nok til, at de kan bruges?
- ☐ Har I bedt om testerens tidslinje?
- ☐ Er der udpeget en ansvarlig for sammenligningen?
- ☐ Kender driftsleverandøren sin rolle under testen?
Kilder
- Microsoft Learn: Manage audit log retention policies: standardopbevaring på 180 dage, et år for bestemte tjenester med bestemte licenser, længere opbevaring med tilkøb.
- Microsoft Learn: Activity log in Azure Monitor: aktivitetsloggen registrerer administrative handlinger, gemmes i 90 dage, ressourcelogs indsamles ikke som standard.
- AWS: What is AWS CloudTrail?: hændelseshistorik for administrative handlinger i 90 dage pr. region, trails og datalagre til længere opbevaring.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler til IT-afdelingen
Læs også: Azure-test · AWS-test
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
