Kundespecifikke tilpasninger og konfigurationer

En pentest af et SaaS-produkt bliver lavet på én eller få opsætninger, men kunderne bruger produktet med hver deres indstillinger, moduler og i nogle tilfælde tilpasninger, I har lavet til netop dem. Svaret på, hvad en fælles test dækker, hviler på forskellen mellem det, alle kunder deler, og det, der kun findes hos nogle: den fælles kode og standardopsætningen er dækket, når de var med i testen; kodede tilpasninger og usædvanlige indstillinger er kun dækket, hvis de blev afprøvet.

Det er ikke en grund til at teste hver kunde for sig. Men det er en grund til at vide, hvor jeres kunder adskiller sig fra standarden, og til at kunne sige det præcist, når en kunde spørger.

Én test, mange opsætninger

Et SaaS-produkt er i princippet det samme for alle kunder. I praksis er det ikke altid helt så enkelt. Over tid får kunderne lov til at slå funktioner til og fra, vælge login, ændre regler for deling og koble integrationer på. Store kunder får måske en særlig rapport, et ekstra felt eller en forbindelse, der kun findes hos dem.

Hver af de forskelle kan betyde, at en kunde bruger en del af produktet, som testen aldrig så. Det behøver ikke være et problem, men det bliver et problem, hvis I har sagt til kunden, at rapporten dækker deres løsning. → Rapporten dækker ikke det modul, kunden køber

Indstillinger, tilpasninger og egne installationer

Det hjælper at skelne mellem tre ting, som kunderne kan kalde det samme:

Indstillinger · valg, som kundens administrator selv kan træffe i produktet, fx krav om totrinsbekræftelse, regler for deling eller hvilke moduler der er slået til.
Tilpasninger · noget, I har bygget eller sat op til en bestemt kunde, fx en særlig rapport, en integration eller et ekstra trin i et arbejdsforløb.
Egne installationer · en kunde, der har sin egen kopi af produktet, måske i en anden region eller med en anden version.

De tre giver forskellige svar på spørgsmålet om testen. Indstillinger kan i et vist omfang afprøves generelt. Tilpasninger skal testes for sig. Egne installationer kræver, at I kan forklare, om de kører samme kode og opsætning som det testede miljø.

Hvad en fælles test dækker

En fælles test dækker den kode, alle kunder kører, og de opsætninger, testlejerne havde. Hvis testlejerne var sat op med standardindstillingerne, siger rapporten noget om standarden, men mindre om kunder, der har valgt noget andet. → Testlejere

Det er derfor værd at vælge testlejernes opsætning med omtanke. I kan lade én lejer have standarden og en anden have de indstillinger, der giver brugerne mest frihed. Så siger rapporten noget om begge ender. Funktioner, der kun er slået til for udvalgte kunder, skal være slået til hos mindst én testlejer for at være med. → Funktioner slået til for udvalgte kunder

Indstillinger, der kan svække sikkerheden

Nogle indstillinger giver kunden lov til at gøre produktet mindre sikkert: at slå totrinsbekræftelse fra, at tillade deling med alle, der har et link, eller at give flere brugere administratorrettigheder. Kunden har lov til at vælge det, men I bestemmer, hvad der er standard, og hvor tydeligt konsekvensen fremgår.

NCSC skriver i sine principper for cloudtjenester, at leverandører bør gøre det let for kunderne at beskytte deres data, og at sikre indstillinger bør være slået til fra start. Samtidig er konfigurationen kundens ansvar. Den fordeling kan I bruge direkte: testen afprøver, at de sikre indstillinger virker, og at kun kundens administrator kan ændre dem. Hvad kunden vælger, er kundens beslutning. → Kundernes eget ansvar

OWASP beskriver fejl i konfigurationen som en risiko, der kan opstå på alle niveauer, fra netværket til applikationen. For et SaaS-produkt betyder det, at en indstilling, der er forkert sat som standard, rammer alle kunder, der aldrig har ændret den.

Kodede tilpasninger til én kunde

Tilpasninger, I har bygget til en bestemt kunde, er det, en fælles test dækker mindst. De er skrevet til et formål, har måske kun været brugt ét sted og bliver ikke altid vedligeholdt i samme takt som resten af produktet. Hvis tilpasningen kører i den fælles løsning, kan en fejl i den også ramme andre kunder.

Når en tilpasning kører i den fælles løsning, så overvej at tage den med i den fælles test, eller at teste den særskilt, når den bliver lavet. Hvis kunden har betalt for tilpasningen og kræver dokumentation for den, kan det være en del af aftalen med netop den kunde. Hvad der påvirker omfanget af en sådan særskilt test, kan I drøfte ud fra pris og tilbud.

Når kunden spørger, om deres opsætning er med

Spørgsmålet kan komme fra kunder med særlige behov eller egne tilpasninger. Svar konkret: hvilke dele af produktet, kunden bruger, var med i testen, hvilke indstillinger testlejerne havde, og om kundens tilpasninger var med. Hvis de ikke var, så sig det, og forklar, hvad I gør for at dække dem. → Kunden vil have testet netop deres opsætning af produktet

Hold en opdateret oversigt over, hvilke kunder der har tilpasninger, og hvornår de sidst blev afprøvet. Så kan sælgeren eller den kundeansvarlige svare uden at skulle spørge udviklingsteamet hver gang.

Et tydeligt omfangsafsnit gør svaret kortere, fordi kunden selv kan læse, hvad der blev testet. → Omfangsafsnittet

Det skal I lade være med

Sige, at rapporten dækker kundens løsning, uden at have tjekket deres opsætning · kunden tager jer på ordet.
Teste udelukkende med standardindstillinger · kunder med friere indstillinger er ikke dækket.
Glemme tilpasningerne i den fælles kode · en fejl i dem kan ramme alle.
Gøre den mindst sikre indstilling til standard · den rammer alle, der ikke ændrer den.
Påtage jer ansvaret for kundens valg · I kan vejlede og gøre det sikre let, ikke vælge for kunden.
Lade egne installationer stå uden forklaring · kunden skal vide, om de kører det testede.

Hvad kan og ikke kan konkluderes

En fælles test kan dokumentere den kode, alle kunder deler, og de opsætninger, testlejerne havde. Den kan ikke dokumentere tilpasninger og indstillinger, der ikke var med, og den siger intet om, hvordan den enkelte kunde senere har valgt at sætte produktet op.

Tjekliste til tilpasninger og konfigurationer

☐ Findes der en oversigt over kundespecifikke tilpasninger?
☐ Afspejler testlejerne både standarden og de friere indstillinger?
☐ Er tilpasninger i den fælles kode med i testen?
☐ Er de sikre indstillinger standard, og er de afprøvet?
☐ Kan I forklare, om egne installationer kører det testede?
☐ Er der et klart svar til kunder, der spørger til deres opsætning?

Kilder

OWASP API Security Top 10 2023: Security Misconfiguration: fejl i konfigurationen som risiko på alle niveauer, fra netværk til applikation.
NCSC (UK): Principle 14, Secure use of the service: sikre standardindstillinger fra leverandøren og konfigurationen som kundens ansvar.

Senest gennemgået: oktober 2026.