Hvad skal med i en penetrationstest af et SaaS‑produkt?

En penetrationstest af et SaaS-produkt er kun så nyttig over for kunderne, som omfanget tillader. Står den del af produktet, kunden skal bruge, uden for testen, hjælper rapporten ikke, uanset hvor grundig den ellers er. Svaret på titlens spørgsmål er derfor: det, kunderne faktisk bruger og stoler på, med særlig vægt på de steder, hvor kundernes data og adgange mødes.

Omfanget hviler på to kilder. Den ene er produktet selv: hvilke indgange, roller og integrationer det har. Den anden er kunderne: hvad de spørger til i spørgeskemaer og kontrakter, og hvad de bruger rapporten til. Et omfang, der tager udgangspunkt i begge, giver en rapport, kunderne kan genkende deres eget produkt i.

Begynd med produktets dele

Lav en liste over de dele, kunderne møder eller er afhængige af. For et SaaS-produkt kan den se nogenlunde sådan ud:

Webapplikationen · det, brugerne logger ind i, med alle de funktioner, kunderne betaler for.
Adskillelsen mellem kunder · at en kunde ikke kan se eller ændre en anden kundes data.
Roller og rettigheder · kundeadministrator, almindelig bruger, gæst og eventuelle særlige roller.
API’et · det, kundernes integrationer og jeres egen brugerflade bygger på.
Login og single sign-on · egne konti og login via kundernes egne løsninger.
Administrations- og supportmodul · jeres medarbejderes adgang til kundernes data.
Integrationer og webhooks · data, der kommer ind i produktet eller forlader det.
Filhåndtering · upload, eksport og rapporter.

Sammenlign listen med de spørgsmål, kunderne har stillet i det seneste års spørgeskemaer og møder. Hvis flere kunder har spurgt til en bestemt funktion, fx eksport eller single sign-on, er det et tegn på, at den skal have vægt i testen. Har nogle kunder særlige tilpasninger eller funktioner, der kun er slået til for dem, så beslut, om de skal med, eller om rapporten skal sige, at de ikke er dækket.

Ikke alle dele skal testes lige grundigt hver gang, men de skal alle tages stilling til. En del, der bevidst er holdt ude, skal stå i rapporten som udeladt. → Omfangsafsnittet i rapporten

Adskillelsen er det, kunderne spørger mest til

I et produkt med mange kunder på samme platform er det centrale spørgsmål fra kundens side, om andre kunder kan komme til deres data. OWASP’s projekt om API-sikkerhed har brudt autorisation på objektniveau øverst på sin liste over risici i 2023-udgaven, og spørgsmålet om, hvem der må se hvilke data, går igen i både webapplikationen og API’et. En test, der kun afprøver produktet som én kunde, kan ikke sige meget om adskillelsen.

Derfor bør testeren have adgang som flere kunder og i flere roller hos hver. Det gør det muligt at afprøve grænserne mellem kunder og mellem roller i samme kunde. → Multi-tenant: test af adskillelsen mellem kunderne

Udgangspunktet: indlogget eller udefra

Et SaaS-produkt har det meste af sin funktionalitet bag login. En test, der kun ser produktet udefra, afprøver loginsiden og det, der er offentligt, men ikke det, kunderne bruger til daglig. Kundernes sikkerhedsfolk ved det og vil se i rapporten, om testeren har været logget ind, og i hvilke roller.

Aftal derfor testkonti i de roller, der er relevante, og beskriv udgangspunktet i opgavebeskrivelsen, så det også står i rapporten. OWASP’s testguide til webapplikationer er en almindeligt anvendt faglig ramme for, hvad der afprøves i en webapplikation, og kan bruges som fælles reference, når I taler med testeren om omfanget. → Roller og rettigheder i produktet

Jeres egen adgang hører også med

Kunderne spørger ikke kun til, hvad andre kunder kan, men også til, hvad jeres egne medarbejdere kan. Et administrations- eller supportmodul, der giver adgang til alle kunders data, er en del af produktet set fra kundens side, selvom kunderne aldrig ser det. Tag det med i omfanget, eller forklar, hvordan det ellers er afprøvet. Det samme gælder de dele af sikkerheden, kunderne selv styrer, fx deres egne brugere og indstillinger. Dem kan testen ikke dække for kunden, men rapporten kan vise, at de muligheder, produktet giver kunderne, virker efter hensigten. → Kundernes eget ansvar → Supportadgang og administrationsmodul

Platformen bag produktet

Hostes produktet hos en cloududbyder, gælder udbyderens regler for test. Microsoft oplyser på Microsoft Learn, at test af egne ressourcer i Azure ikke kræver forudgående godkendelse, men skal følge Microsofts regler for penetrationstest, og at tredjeparter skal have skriftlig tilladelse fra ejeren af ressourcerne. AWS skriver, at kunder kan teste deres egen AWS-infrastruktur uden forudgående godkendelse for en række nævnte tjenester, og nævner aktiviteter, der ikke er tilladt. Læs reglerne for jeres egen platform, før omfanget lægges fast.

Hvor meget af infrastrukturen der skal med i den rapport, kunderne får, er et særskilt spørgsmål. Kontornettet og jeres interne systemer er en anden opgave end produktet. → Produktet hostes hos en cloududbyder

Miljø, tid og omfang hænger sammen

Et bredt omfang kræver mere testtid, og et miljø, der ligner produktionen, giver de mest brugbare resultater. Beslut, om testen skal foregå i produktionen eller i et separat miljø, og hvordan andre kunder skånes. Omfanget, antallet af roller og integrationer og ønsket om retest og kundeversion påvirker alle opgavens størrelse. Hvordan det hænger sammen med prisen, kan I læse om under pris og tilbud. Den generelle gennemgang af afgrænsning findes på penetrationtest.dk. → Et staging-miljø til testen

Det skal I lade være med

Teste som én kunde i én rolle · Så siger rapporten intet om adskillelse og rettigheder.
Udelade API’et, fordi brugerfladen testes · Integrationerne bruger API’et direkte.
Glemme jeres egen supportadgang · Kunderne spørger til den.
Lade omfanget være uskrevet · Det skal stå i rapporten, hvad der var med og ude.
Overse platformens regler · Test af cloudressourcer følger udbyderens vilkår.
Blande kontornettet ind i produkttesten · De to rapporter besvarer forskellige spørgsmål.

Hvad kan og ikke kan konkluderes

Et omfang, der dækker produktets dele, roller og adskillelse, giver en rapport, kunderne kan bruge til at vurdere det, de køber. Testen siger kun noget om de dele, der var med, i den version, der blev testet. Dele, der bevidst er udeladt, er ikke afprøvet, og det skal kunderne kunne se.

Tjekliste til omfanget

☐ Er alle dele af produktet listet og taget stilling til?
☐ Har testeren adgang som flere kunder og i flere roller?
☐ Er API, integrationer og single sign-on med eller bevidst udeladt?
☐ Er administrations- og supportmodulet med?
☐ Er platformens regler for test læst?
☐ Står udgangspunkt og udeladelser i opgavebeskrivelsen, så de kommer med i rapporten?

Kilder

OWASP API Security: Top 10-listen over risici ved API’er (2023), med brudt autorisation på objektniveau som første punkt.
OWASP Web Security Testing Guide: faglig ramme for test af webapplikationer.
Microsoft Learn: Penetration testing (Azure): ingen forudgående godkendelse for test af egne Azure-ressourcer; reglerne for penetrationstest skal følges; tredjeparter skal have skriftlig tilladelse fra ejeren.
AWS: Penetration testing: kunder kan teste egen AWS-infrastruktur uden forudgående godkendelse for de nævnte tjenester; visse aktiviteter er ikke tilladt.

Senest gennemgået: oktober 2026.