Et softwarehus, der leverer sin løsning som en tjeneste, står med to spørgsmål på én gang: holder løsningen, og kan det dokumenteres over for kunderne? Svaret på begge hviler på, at testen afgrænses til det, kunderne faktisk bruger, og at resultatet kan forklares uden at afsløre mere end nødvendigt.
En SaaS-løsning adskiller sig fra et internt system ved, at mange kunder deler samme platform, at den ændres ofte, og at kunderne selv har krav til dokumentation. De tre forhold præger både bestillingen og brugen af rapporten. Uddybningen af kundernes krav og rapportens rolle i salget findes på pentestrapport.dk.
Mange kunder på én platform
Det mest særlige ved SaaS er, at kundernes oplysninger ligger på samme platform. Adskillelsen mellem dem er derfor et centralt spørgsmål. En kunde må ikke kunne se eller ændre en anden kundes data, heller ikke gennem en funktion, der normalt kun bruges af administratorer.
En test bør derfor have mindst to adskilte testkunder, hver med de roller, der findes i løsningen. Det gør det muligt at afprøve, om grænserne holder både mellem kunder og mellem roller hos samme kunde. → Kunders data holdt adskilt
Platformens administrative funktioner hører også med. Supportadgang, hvor softwarehusets egne medarbejdere kan logge ind hos en kunde, er et eksempel på en funktion, der skal være tydeligt afgrænset og dokumenteret. Det samme gælder funktioner til at oprette nye kunder, flytte data mellem kunder eller slette en kunde, når aftalen ophører.
Hvis kunderne kan tilpasse løsningen, fx med egne felter, egne roller eller egne skabeloner, bør det også overvejes. Tilpasninger kan give kombinationer af rettigheder, som ikke findes i standardopsætningen, og som derfor ikke bliver afprøvet, hvis testkunderne kun bruger standardrollerne.
API og integrationer
En SaaS-løsning giver ofte kunderne adgang via et API, så de kan koble løsningen sammen med deres egne systemer. API’et er en lige så vigtig indgang som brugerfladen og bør være med i overvejelserne, når scope fastlægges. → API-test
Integrationer til tredjeparter kan være en del af leverancen. Det kan være betaling, mailudsendelse eller single sign-on med kundernes egne identiteter. Hver integration skal placeres i eller uden for scope, og det skal fremgå af rapporten.
API’et kan have andre adgangsregler end brugerfladen, fordi det er bygget til maskiner frem for mennesker. Derfor er det ikke nok, at brugerfladen er afprøvet. Nøgler, der udleveres til kunder, og forskellen mellem kundernes adgang og softwarehusets interne kald er spørgsmål, der hører hjemme i bestillingen.
Hyppige udgivelser
En SaaS-løsning kan ændres med korte mellemrum. En rapport beskriver derfor en bestemt udgave. Det er ikke en svaghed ved testen, men det betyder, at rapporten skal have dato og versionsangivelse, og at softwarehuset bør have en praksis for, hvornår ændringer kræver en ny vurdering.
Store ændringer som et nyt modul, en ny rollemodel eller et nyt API er oplagte anledninger. Små rettelser er det sjældent. Det vigtigste er, at vurderingen sker bevidst, og at den ligger hos en bestemt person eller funktion i softwarehuset.
En praktisk løsning er at koble vurderingen til den eksisterende proces for udgivelser. Når en ændring påvirker login, roller, adskillelse mellem kunder eller API’et, markeres den, og der tages stilling til, om den skal med i næste test eller have en afgrænset vurdering for sig. Så kan softwarehuset også svare præcist, når en kunde spørger, hvad der er sket siden sidste rapport. → Efter en større opdatering
Cloudplatformen og det delte ansvar
Når løsningen kører hos en cloududbyder, deles ansvaret. Udbyderen har ansvar for sin egen platform, mens softwarehuset har ansvar for sin løsning, sin opsætning og sine adgange. Udbyderne har egne regler for, hvad kunder må teste, og de skal kontrolleres før testen. → Delt ansvar i cloud
Grænsen er også relevant for kunderne. Et tydeligt svar om, hvad softwarehuset selv har testet, og hvad udbyderen står for, gør dokumentationen mere troværdig.
Rapporten til kunderne
Kunder og deres revisorer kan bede om dokumentation for test. Den fulde rapport indeholder ofte detaljer, der ikke bør deles bredt. En mulighed er derfor et kortere dokument, der beskriver opgaven, tidspunktet og den overordnede konklusion, mens den fulde rapport kun deles, hvor det er nødvendigt, og under fortrolighed. → Testerklæring
Et fast format gør det også lettere at svare ens til alle kunder. Hvad der deles, er en beslutning for softwarehuset og bør aftales med testeren på forhånd, så rapporten kan skrives med det formål for øje. Når kunden selv stiller kravet, er de første skridt beskrevet i → Kunden beder om en pentestrapport.
Testmiljø og rigtige kunder
En SaaS-test rejser et særligt spørgsmål om miljø. Tester man i produktionen, er rigtige kunders data i nærheden, og en fejl kan ramme dem. Tester man i et testmiljø, skal det ligne produktionen i de dele, der er vigtige for testen, herunder adskillelsen mellem kunder og opsætningen af adgange.
Begge valg kan være forsvarlige. Det afgørende er, at valget er truffet bevidst, at rapporten siger, hvor testen blev gennemført, og at kunderne får det samme svar, hvis de spørger. Uanset valget skal testkunderne være adskilt fra rigtige kunder, og det skal være aftalt, hvordan de fjernes bagefter. → Penetrationstest i produktion eller testmiljø
Det skal I lade være med
- At teste med én testkunde · Adskillelsen mellem kunder kan ikke vurderes uden mindst to.
- At udelade API’et · Det er en indgang til de samme oplysninger som brugerfladen.
- At dele den fulde rapport med alle · Detaljer om fund hører til hos dem, der skal rette eller vurdere dem.
- At lade rapporten stå uden dato og version · Kunden skal kunne se, hvilken udgave den beskriver.
- At blande cloududbyderens ansvar med jeres eget · Kunderne vil vide, hvad I selv har kontrolleret.
Hvad kan og ikke kan konkluderes
En test af en SaaS-løsning kan dokumentere, hvordan den aftalte udgave, de valgte roller og de afgrænsede integrationer holdt under testen. Den kan ikke dokumentere senere udgaver, dele af platformen uden for scope eller cloududbyderens egen sikkerhed.
Over for kunderne kan rapporten vise, at løsningen er testet og hvordan. Den kan ikke garantere, at løsningen er sikker, og den bør ikke præsenteres sådan.
Tjekliste til en SaaS-test
- ☐ Er der mindst to testkunder med alle relevante roller?
- ☐ Er supportadgang og administrative funktioner med i scope?
- ☐ Står det klart, om API og integrationer er med?
- ☐ Er cloududbyderens regler for test kontrolleret?
- ☐ Er det aftalt, hvilket dokument kunderne skal have?
- ☐ Har rapporten dato og versionsangivelse?
- ☐ Er der en praksis for, hvornår ændringer kræver en ny vurdering?
Kilder
- OWASP API Security: oversigt over risici ved API’er, herunder adgangskontrol til de enkelte oplysninger.
- OWASP Web Security Testing Guide: faglig ramme for test af autorisation og roller i webapplikationer.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler om penetrationstest
Læs også: Penetrationstest af webapplikationer · Single sign-on
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT
