Logning og revisionsspor i produktet, som kunderne spørger til

Kunderne vil vide, om de kan se, hvem der har gjort hvad med deres data i jeres produkt, og om I selv kan finde ud af det, hvis noget går galt. En penetrationstest kan sige noget om det, men kun om en del af spørgsmålet: den kan vise, om revisionssporet holder sammen, når nogen forsøger at misbruge produktet, men den kan ikke vise, at alt det, der burde logges, faktisk bliver det.

Det korte svar til kunden hviler derfor på to ting: en beskrivelse af, hvad produktet logger, hvem der kan se det, og hvor længe det gemmes, og en test, der har set på sporet med en angribers øjne.

Hvad kunderne spørger om

Spørgsmålene om logning kommer fra flere sider. Kundens sikkerhedsfolk vil kunne opdage og undersøge misbrug. Kundens revisor vil kunne se, hvem der har ændret hvad. Og kundens jurister tænker på, om en hændelse kan opklares, hvis den skal anmeldes.

I sikkerhedsspørgeskemaet kan det blive til spørgsmål som disse:

Hvad logges · login, mislykkede login, ændringer af rettigheder, adgang til data, eksport og sletning.
Hvem logges · kundens egne brugere, men også jeres egne medarbejdere, når de arbejder i kundens data.
Hvem kan se loggen · om kundens administrator har adgang, og i hvilken form.
Hvor længe · hvor længe sporet gemmes, og om det kan udleveres.
Kan sporet ændres · om nogen, inklusive jer, kan slette eller rette i det.

Den britiske NCSC beskriver det som et af principperne for cloudtjenester, at leverandøren giver kunden de revisionsoplysninger, der skal til for at opdage og undersøge hændelser, og at jeres egne medarbejderes handlinger også bliver logget. Spørgsmålene hænger tæt sammen med dem om hændelser. → Spørgsmål om hændelser

Det, en pentest kan sige om sporet

Testeren bruger produktet som forskellige brugere og forsøger at nå det, rollerne ikke tillader. Undervejs kan testen se på revisionssporet som en funktion i produktet, på linje med de andre:

Adskillelsen · kan en kunde se en anden kundes log, eller kan oplysninger fra loggen nås ad andre veje?
Rettighederne · kan en almindelig bruger se eller ændre det, kun administratoren burde have adgang til?
Pålideligheden · kan en bruger påvirke, hvad der står i sporet, så det viser noget andet end det, der skete?
Synligheden af testens egne handlinger · dukker testerens forsøg op i den log, kundens administrator kan se?

Det sidste punkt er nyttigt for jer. Efter testen kan I lægge testerens tidslinje ved siden af jeres egne logs og se, hvad der blev registreret, og hvad der ikke gjorde. OWASP nævner det netop som et tegn på mangler i logning og alarmering, når en penetrationstest ikke udløser nogen alarm. → Fundene som læring for udviklerne

Aftal på forhånd, at revisionssporet er et eget punkt i omfanget, og at I vil have testerens tidslinje udleveret. Ellers bliver det let overset, fordi testen har travlt med de funktioner, der rummer data. → Omfangsafsnittet

Det, testen ikke kan vise

En pentest er en afgrænset undersøgelse. Den kan ikke gennemgå hver eneste handling i produktet og kontrollere, at den bliver logget korrekt. Den kan heller ikke sige noget om, hvorvidt nogen hos jer kigger på loggen, eller om der kommer en alarm, når der sker noget usædvanligt.

Det er værd at skrive tydeligt i jeres svar til kunden. Testen er dokumentation for, at sporet blev afprøvet i de situationer, testen dækkede. Beskrivelsen af, hvad der logges, og hvordan I bruger det, er dokumentation for jeres proces. De to dele supplerer hinanden, men den ene kan ikke stå i stedet for den anden.

Jeres egne medarbejdere i sporet

Kunderne kan spørge mest til det, de ikke selv kan se: når jeres supportfolk eller udviklere arbejder i kundens data. Et revisionsspor, der kun viser kundens egne brugere, svarer ikke på det spørgsmål.

Hvis jeres egne medarbejderes adgang bliver logget og kan vises for kunden, er det et stærkt svar. Hvis den ikke gør, bør I sige det ærligt og forklare, hvordan adgangen ellers er styret. Testen af supportadgangen kan også se på, om den adgang efterlader spor. → Supportadgang og administrationsmodul

Når kunden vil have loggen udleveret

Nogle kunder nøjes ikke med at kunne se sporet i produktet. De vil kunne hente det ud og lægge det ind i deres egen overvågning, eller de vil have det udleveret, når de undersøger en hændelse hos sig selv. Det rejser spørgsmål, som også hører til testen: hvem kan hente loggen, sker det med samme kontrol af rettigheder som resten af produktet, og indeholder den oplysninger om andre kunder eller om jeres interne opbygning?

En udtræksfunktion eller et API til loggen er en vej ud af produktet for data. Den bør derfor stå i omfanget på linje med andre eksportfunktioner. Beslut også, hvad I gør, hvis en kunde beder om log fra en periode, der ligger uden for det, I gemmer. Det svar skal være klart, før kunden har brug for det. → Filupload, eksport og rapporter i produktet

Svaret i skemaet

Skriv svaret, så det passer med det, produktet faktisk gør. Et tænkt eksempel: en kunde spørger, om al adgang til data logges. Produktet logger login, ændringer af rettigheder og eksport, men ikke hver visning af en post. Det rigtige svar er at nævne de tre, sige, at visninger ikke logges enkeltvis, og nævne, at revisionssporet var med i seneste test. Et ja til hele spørgsmålet ville være forkert, og det opdager kunden, første gang loggen skal bruges. → Svar, I ikke kan dokumentere

Det skal I lade være med

Svare ja til al logning · beskriv, hvilke handlinger der logges, og hvilke der ikke gør.
Lade sporet stå uden for testen · adskillelse og rettigheder gælder også for loggen.
Glemme jeres egne medarbejdere · kunderne spørger netop til den adgang, de ikke selv kan se.
Kalde testen for et bevis på fuldstændig logning · den afprøver udvalgte situationer.
Smide testerens tidslinje væk · den er jeres bedste mulighed for at se, hvad loggen fangede.

Hvad kan og ikke kan konkluderes

En test kan vise, om revisionssporet holdt adskillelsen og rettighederne i de situationer, der blev afprøvet, og om testens egne handlinger blev registreret. Den kan ikke vise, at alle handlinger logges, at loggen bliver fulgt, eller at en hændelse vil blive opdaget i tide.

Tjekliste til revisionssporet

☐ Er det beskrevet, hvilke handlinger produktet logger, og hvilke det ikke logger?
☐ Logges jeres egne medarbejderes adgang til kundedata?
☐ Er revisionssporet et eget punkt i testens omfang?
☐ Har I bedt om testerens tidslinje og sammenholdt den med jeres logs?
☐ Passer svarene i spørgeskemaet med det, produktet faktisk gør?

Kilder

NCSC (UK): Principle 13, Audit information and alerting for customers: revisionsoplysninger til kunden, logning af leverandørens egne medarbejdere og beskyttelse mod ændringer.
OWASP Top 10:2025, A09 Security Logging and Alerting Failures: mangler i logning og alarmering, herunder at en penetrationstest ikke udløser alarmer, og at loggens integritet ikke er beskyttet.

Senest gennemgået: oktober 2026.