Kunderne ser kun applikationen, men deres data ligger på servere, i databaser og på en platform, som de aldrig kommer i nærheden af. Når de spørger, om produktet er testet, mener mange derfor hele miljøet. Om infrastrukturen skal med i den rapport, kunderne får, afhænger af, hvilke dele af den der kan påvirke kundernes data og adskillelsen mellem kunderne. De dele hører med. Det, der kun handler om jeres egen virksomhed, fx kontornettet, hører til en anden test og en anden rapport.
Grænsen er ikke altid skarp, og det er netop derfor, den skal beskrives. En kunde, der ved, hvad rapporten dækker, kan selv vurdere, om det er nok.
Lagene under applikationen
Under et SaaS-produkt ligger der typisk flere lag:
- Platformen · cloududbyderens tjenester eller jeres egne servere, med de indstillinger, I har valgt.
- Data · databaser, fillager og sikkerhedskopier med kundernes oplysninger.
- Netværket · de regler, der bestemmer, hvad der kan nås udefra, og hvad der kan tale sammen indbyrdes.
- Administrationen · de konti og adgange, jeres medarbejdere bruger til at drive miljøet.
- Udrulningen · den kæde, der bygger og sender nye versioner ud i produktionen. → Pipeline og pentest
Hvert lag kan svække det, applikationen gør rigtigt. En applikation med god adskillelse mellem kunderne hjælper ikke meget, hvis databasen kan nås fra internettet, eller hvis en administrativ konto uden ekstra beskyttelse kan ændre det hele.
Det, kunderne har grund til at spørge om
Den britiske NCSC’s principper for cloudsikkerhed handler bl.a. om adskillelse mellem kunderne i en tjeneste. Som dokumentation for adskillelsen nævner NCSC bl.a. regelmæssige penetrationstest. Adskillelsen afhænger ikke kun af applikationen, men også af, hvordan data og systemer er sat op nedenunder.
For kunden betyder det, at et svar om applikationen alene er et delvist svar. Kundens sikkerhedsansvarlige vil gerne vide, om de dele af infrastrukturen, der rummer kundens data, har været undersøgt, og hvem der kan administrere dem. Det er rimelige spørgsmål, og de kan besvares uden at udlevere en teknisk beskrivelse af miljøet. Kunden har brug for at vide, hvad der blev undersøgt, af hvem og hvornår. Kunden har ikke brug for at vide, hvordan netværket er delt op, eller hvilke servere der står hvor, og den slags oplysninger bør heller ikke ligge i et dokument, der sendes rundt til mange kunder.
Hvad der hører med i kundens rapport
Som tommelfingerregel hører de dele med, som kundernes data passerer eller ligger i, og de adgange, der kan ændre dem:
- Det, der er synligt udefra · alle adresser og tjenester, der hører til produktet og kan nås fra internettet.
- Opsætningen af platformen · lager, databaser, nøgler og netværksregler for produktmiljøet. → Produktet hostes hos en cloududbyder
- Den administrative adgang · hvordan jeres medarbejdere og driftsleverandører når produktmiljøet.
- Supportadgangen · værktøjer, der lader jeres folk se ind i kundernes data. → Supportadgang og administrationsmodul
Sikkerhedskopierne fortjener en særlig bemærkning. De rummer de samme kundedata som produktionen, men kan ligge et andet sted og med andre adgange. Kunder spørger ikke altid til dem, men et omfang, der udelader dem, efterlader et hul i svaret om, hvor kundens data findes.
Det betyder ikke, at alt skal testes på samme måde. Nogle dele afprøves bedst med en pentest, andre med en gennemgang af opsætningen. Rapporten skal sige, hvilken form der blev brugt for hver del. → Omfangsafsnittet
Det, der hører til en anden test
Kontornettet, medarbejdernes computere og virksomhedens mail er vigtige, men de er ikke produktet. Kunderne spørger måske også til dem i et spørgeskema om hele virksomheden, og så skal de have et svar. Men svaret hører til en anden test og bør ikke blandes ind i den rapport, der skal dokumentere produktet. → Kontornettet og produktet
Grænsen går dér, hvor kontornettet har adgang til produktmiljøet. Den forbindelse hører med i produktets test, for det er den vej, et angreb på kontoret kan nå kundernes data. Test af kontornet, servere og cloudplatforme i dybden hører til IT-afdelingens emner og er beskrevet på penetration-test.dk.
Når driften ligger hos en anden
Mange softwarehuse har en driftsleverandør eller bruger en cloududbyders administrerede tjenester. Det ændrer ikke kundens spørgsmål, men det ændrer, hvem der kan svare. Aftal med driftsleverandøren, at deres del af produktmiljøet kan indgå i testen, og hvem der giver tilladelsen.
Det, driftsleverandøren eller cloududbyderen selv driver, og som I ikke har adgang til, kan ikke testes af jeres tester. Det dokumenteres af leverandøren. Sig det tydeligt i svaret til kunderne, så de ikke tror, at jeres rapport dækker noget, den ikke gør. → Produktet eller hele virksomheden?
Et tænkt eksempel
Et softwarehus leverer et system til kvalitetsstyring i fødevarebranchen. Produktet kører hos en cloududbyder, og en driftsleverandør passer databaser og sikkerhedskopier. En kunde spørger i sit spørgeskema, om hele produktionsmiljøet er testet inden for det seneste år.
Softwarehuset svarer i tre dele. Applikationen, API’et og alt, der kan nås udefra, blev testet af en ekstern tester på en bestemt dato. Opsætningen af platformen og den administrative adgang blev gennemgået i samme forløb, også den del, driftsleverandøren har ansvaret for. Cloududbyderens egen platform er dokumenteret med udbyderens erklæringer. Kontornettet er ikke nævnt, fordi det ikke har adgang til produktmiljøet, og det står der også. Kunden kan se, hvad der er dækket, uden at have fået en tegning af miljøet.
Det skal I lade være med
- At teste applikationen og kalde det hele miljøet · kunden vil læse det som en test af alt.
- At blande kontornettet ind i produktets rapport · det gør rapporten svær at læse for kunderne.
- At glemme den administrative adgang · den kan ændre alt, applikationen beskytter.
- At udlevere en detaljeret beskrivelse af infrastrukturen til kunderne · beskriv, hvad der blev testet, ikke hvordan miljøet er bygget.
- At lade driftsleverandørens del stå uafklaret · aftal den før testen.
Hvad kan og ikke kan konkluderes
En rapport, der dækker applikation og infrastruktur, kan vise, om testeren kunne nå kundernes data gennem de lag, der var med. Den siger intet om lag uden for omfanget, og den siger intet om dele, som en udbyder eller driftsleverandør driver uden jeres adgang. En rapport om applikationen alene kan ikke bruges som svar på spørgsmål om miljøet bagved.
Tjekliste til infrastrukturen i omfanget
- ☐ Er alle adresser og tjenester, der hører til produktet, med i omfanget?
- ☐ Er opsætningen af platform, lager og databaser med?
- ☐ Er den administrative adgang og supportadgangen med?
- ☐ Er forbindelsen mellem kontornettet og produktmiljøet med?
- ☐ Er driftsleverandørens del aftalt?
- ☐ Siger rapporten, hvilken form for afprøvning hver del fik?
Kilder
- NCSC (UK): Principle 3, Separation between customers: adskillelse mellem kunderne i en cloudtjeneste og regelmæssige penetrationstest som dokumentation.
Senest gennemgået: oktober 2026.
Næste skridt
Del af: Artikler om pentestrapporten
Læs også: Omfanget af testen · Pipeline og pentest
→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest af SaaS hos Nielco IT