Integrationer til kundernes systemer: hvor går jeres ansvar til?

En integration forbinder jeres produkt med et system, I ikke ejer, og derfor er det ikke altid klart for kunden, hvor jeres pentest slutter, og hvor deres eget ansvar begynder. Svaret hviler på en enkel opdeling: det, I har bygget og driver, er jeres at teste og dokumentere; det, kunden har bygget, driver eller konfigurerer, er kundens. Det svære er at få grænsen skrevet så tydeligt, at kunden kan læse den i rapporten og i kontrakten.

Uden den opdeling ender I med at blive spurgt om ting, I ikke kan svare på, eller med at love noget, der ligger uden for jeres rækkevidde.

Tre slags integrationer, tre slags ansvar

Integrationer kan se ens ud for kunden, men ansvaret ligger forskelligt:

Kundens system kalder jeres API · I ejer API’et og dets kontroller. Kunden ejer sin integration og de nøgler, kunden har fået. → Produktets API
Jeres produkt kalder kundens system · I ejer den del af produktet, der sender og modtager, og den måde, I opbevarer kundens adgangsoplysninger på. Kunden ejer det system, der tager imod. → Webhooks og udgående integrationer
Jeres færdige forbindelse til et standardsystem · når I har bygget en forbindelse til et udbredt system, som kunderne bruger, ejer I forbindelsen. Selve standardsystemet og kundens opsætning af det ejer I ikke.

Den tredje slags giver flest misforståelser. Kunden ser en knap i jeres produkt og regner med, at alt bag knappen er jeres.

Det, der er jeres

Jeres ansvar omfatter alt, hvad I selv har skrevet og driver, også den del af en integration, der kører hos jer. Det betyder i praksis:

Integrationskoden · den del af produktet, der henter, sender og omsætter data.
Opbevaring af adgang · nøgler og adgangsoplysninger, som kunderne har givet jer til deres systemer.
Rettighederne · hvem hos kunden der kan oprette, ændre og slå integrationer fra.
Adskillelsen · at en integration hos én kunde aldrig kan berøre en anden kundes data.

Det er det, jeres pentest skal dække, og det er det, rapporten kan dokumentere over for kunderne.

Hold også øje med integrationer, der er bygget af en partner, men som kunderne aktiverer fra jeres produkt. Hvis partneren driver koden, ligger ansvaret dér, men kunden vil stadig spørge jer. Gør det klart, hvem der står bag.

Det, der er kundens

Kundens ansvar omfatter det system, integrationen forbinder til, og det, kunden selv vælger i opsætningen. Hvis kunden giver integrationen bredere rettigheder i sit eget system, end den har brug for, er det kundens valg og kundens risiko. Hvis kundens system modtager data fra jer og opbevarer dem dårligt, kan jeres test ikke se det.

NCSC skriver i sine principper for cloudtjenester, at konfigurationen er kundens ansvar, også når leverandøren har gjort de sikre indstillinger til standard. Den tanke kan bruges direkte i jeres dialog med kunderne. I kan gøre det let at sætte integrationen sikkert op, men I kan ikke teste den opsætning, kunden vælger. → Kundernes eget ansvar: det, I ikke kan teste for dem

Data, der kommer ind fra kundens systemer

Ansvaret går også den anden vej. Når jeres produkt modtager data fra en kundes system eller fra et standardsystem, skal produktet behandle dem med samme forsigtighed som data fra en bruger. OWASP beskriver det som en risiko, at udviklere har en tendens til at stole mere på data fra andre API’er end på brugerinput, og at et kompromitteret system i den anden ende derfor kan bruges til at ramme det system, der modtager dataene.

For jer betyder det, at testen også skal se på, hvordan produktet håndterer det, der kommer ind via integrationerne. Det er jeres del, selv om dataene stammer fra kundens system.

Skriv grænsen ind i omfanget og kontrakten

Grænsen skal stå to steder. I omfangsafsnittet af rapporten, så en kunde kan se, at integrationskoden var med, men at kundens egne systemer ikke var. Og i kontrakten eller sikkerhedsbilaget, så det er aftalt, hvem der står for hvad, før der opstår et problem. → Sikkerhedsbilaget til kundekontrakten

Et tænkt eksempel: et softwarehus med et system til vagtplanlægning har en færdig forbindelse til et udbredt lønsystem. Omfangsafsnittet kan sige, at forbindelsens kode, opbevaringen af kundernes adgang til lønsystemet og rettighederne til at slå forbindelsen til var med i testen, og at lønsystemet og kundernes opsætning af det ikke var. Kunden kan så selv vurdere, hvad der mangler, og hvem der skal svare på det.

Formuleringen behøver ikke være lang. Et par sætninger om, hvad I tester og vedligeholder, og hvad kunden selv skal vurdere, er nok til, at begge parter kan pege på det senere. Hvordan grænsen generelt trækkes for købere af en test, er beskrevet på penetrationtest.dk. → Omfangsafsnittet

Når kunden vil teste integrationen selv

Nogle kunder vil teste integrationen fra deres side, fordi den er en del af deres eget miljø. Det er rimeligt, men det kræver aftaler, fordi kundens test kan ramme jeres produkt og dermed andre kunder. Aftal, hvad kunden må teste, hvornår, og hvem der skal have besked, hvis noget går galt. → Kunden vil selv teste jeres produkt

Kundens test af egen integration kan supplere jeres test. Den erstatter den ikke, fordi den kun ser jeres produkt fra én kundes side. Bed om at få kundens fund i den del, der er jeres, så I kan rette dem for alle kunder og ikke kun for den ene.

Det skal I lade være med

Skrive, at integrationer er testet, uden at angive hvilke dele · kunden læser det som hele forbindelsen.
Påtage jer ansvar for kundens opsætning · I kan vejlede, ikke teste.
Glemme opbevaringen af kundernes adgangsoplysninger · den er jeres ansvar, ikke kundens.
Stole blindt på data fra standardsystemer · de skal behandles som anden input.
Lade grænsen være uskreven · uklarhed opdages først, når noget er gået galt.
Afvise kundens egen test uden at tilbyde en ramme · aftal i stedet, hvordan den kan foregå.

Hvad kan og ikke kan konkluderes

Jeres test kan dokumentere, at integrationskoden, opbevaringen af adgang og rettighederne i produktet holdt i den testede version. Den kan ikke dokumentere, at kundens eget system eller kundens opsætning er sikker, og den gælder ikke for integrationer, der kom til efter testen.

Tjekliste til grænsen for integrationerne

☐ Er alle integrationer listet med, hvem der ejer hvilken del?
☐ Står integrationskoden og opbevaringen af adgang i omfanget?
☐ Er det afprøvet, hvordan produktet håndterer data fra integrationerne?
☐ Står grænsen i rapportens omfangsafsnit?
☐ Står grænsen i kontrakten eller sikkerhedsbilaget?
☐ Findes der en ramme for kundens egen test af integrationen?

Kilder

NCSC (UK): Principle 14, Secure use of the service: fordelingen af ansvar mellem leverandør og kunde, og at konfigurationen er kundens ansvar.
OWASP API Security Top 10 2023: Unsafe Consumption of APIs: risikoen ved at stole mere på data fra andre API’er end på brugerinput.

Senest gennemgået: oktober 2026.