API’et, kunden kalder: hvad der skal med, når kunden er afhængig af det

En leverance kan være helt uden skærmbilleder, som kundens medarbejdere ser. Kundens egne systemer henter og sender data gennem et API hos jer: ordrer, målinger, bookinger eller brugerdata. Når en NIS2-kunde spørger til test af leverancen, er det API’et, kunden er afhængig af, og derfor det, testen skal dække. Svaret hviler på kundens forsyningskæde: kunden skal vurdere den risiko, en leverance udgør for kundens systemer, og et API, som kundens systemer stoler på, er en direkte vej ind i den risiko.

Testen skal derfor ikke kun spørge, om API’et har svagheder. Den skal spørge, om netop kundens adgang til API’et er afgrænset, og om andre kan misbruge den forbindelse, kunden bruger. Teksten er ikke juridisk rådgivning.

Hvorfor API’et vejer tungt for en NIS2-kunde

For kunden er jeres API en del af kundens egen drift. Hvis API’et svarer forkert, er utilgængeligt eller afleverer data til den forkerte, mærkes det i kundens systemer. NIS 2-lovens § 6, stk. 1, nr. 4, om forsyningskædesikkerhed og direktivets artikel 21, stk. 3, om de sårbarheder, der er specifikke for hver direkte leverandør, er grunden til, at kunden spørger.

Kunden kan have tre bekymringer: at kundens data kan læses eller ændres af andre, at kundens adgangsnøgler kan misbruges, og at API’et kan bruges som springbræt ind i kundens egne systemer. Testen skal kunne sige noget om alle tre. → Integrationer og dataudveksling

Hvad der skal med i testen

Når kundens afhængighed er udgangspunktet, bør testens omfang mindst rumme:

De funktioner, kunden kalder · ikke kun dem, der står i dokumentationen, men dem, kundens systemer faktisk bruger.
Kundens adgang · den type nøgle eller login, kundens systemer bruger, og hvilke rettigheder den giver.
Adskillelse mellem kunder · om en kundes adgang kan bruges til at se eller ændre en anden kundes data.
De versioner, kunden er på · ældre versioner, som kunden stadig kalder, er en del af leverancen.
Data, der sendes tilbage · om API’et returnerer mere, end kunden har brug for.

OWASP’s API Security Project udgiver en liste over de mest udbredte risici i API’er. Den nyeste udgave på projektets side er fra 2023. Listen kan bruges som fælles reference, når I beskriver omfanget for kunden og testeren, uden at I selv skal gå i teknisk detalje. → Fra effektivitetskrav til testplan

Kundens egne roller i API’et

Et API kan have flere roller, fx en, der kun kan læse, og en, der kan oprette og slette. Kunden bør vide, hvilken rolle kundens integration har, og testen bør afprøve, om rollen begrænser det, den skal. Hvis kunden har bedt om flere rettigheder end nødvendigt, er det kundens valg, men testen kan vise konsekvensen. → Kundens brugere hos jer

Aftal med kunden, hvem der må bruge testadgange i kundens navn. En test, der bruger kundens rigtige nøgle, berører kundens data. Det er bedre at oprette en testadgang med samme rettigheder i et miljø, der ligner produktionen. Hvis testen alligevel skal køre mod produktionen, bør kunden vide det på forhånd, så kundens egen overvågning ikke tolker testen som et angreb, og så kunden kan stoppe den, hvis noget opfører sig uventet.

Tilgængelighed er også et spørgsmål

Kunden er ikke kun afhængig af, at API’et er sikkert, men også af, at det svarer. En penetrationstest er som udgangspunkt ikke en test af, hvor meget API’et kan tåle, og nogle platforme forbyder test, der skal overbelaste tjenesten. Spørgsmål om tilgængelighed besvares derfor bedre med en beskrivelse af jeres driftskontinuitet, fx hvordan API’et genetableres efter et nedbrud, og hvordan kunden får besked. → Driftskontinuitet hos leverandøren

Testen kan dog belyse, om der er begrænsninger på, hvor meget en enkelt adgang kan kalde, så en misbrugt nøgle ikke kan tømme kundens data i ét hug.

Det, kunden skal have at vide

Dokumentationen til kunden bør vise, at testen dækkede det, kunden er afhængig af. Det betyder, at den skal oplyse:

Hvilken version af API’et der blev testet.
Hvilke funktioner der var med, og om kundens funktioner var blandt dem.
Hvilke roller testeren brugte, og om adskillelsen mellem kunder blev afprøvet.
Hvad der ikke var med · fx funktioner, kunden ikke bruger, eller belastningstest.

For de digitale udbydere, som gennemførelsesforordning (EU) 2024/2690 gælder for, beder bilagets punkt 6.5.2, litra c, om dokumentation af testens type, omfang, tid og resultater. Andre kunder kan spørge til de samme fire oplysninger. → Fire oplysninger om testen

Testområdet API i dybden, set fra IT-afdelingen, behandles på penetration-test.dk (https://penetration-test.dk/).

Et tænkt eksempel

En leverandør af et system til måleraflæsning har et API, som et vandselskab bruger til at hente forbrugsdata hver time. Vandselskabet er omfattet af NIS 2-loven og beder om dokumentation for, at API’et er testet.

Leverandøren tester API’et med en testadgang, der har samme rolle som selskabets integration, og afprøver, om adgangen kan nå andre kunders data. Testen dækker også den ældre version, selskabet stadig bruger. Rapporten viser det, og leverandøren aftaler med vandselskabet en dato for skiftet til den nyeste version. Når skiftet er sket, lukkes den gamle version for selskabet, så den ikke længere er en del af leverancen. Indtil da står den i oversigten over det, der er testet, og det, der stadig er åbent.

Det skal I lade være med

At teste med kundens rigtige nøgle uden aftale · det berører kundens data og drift.
At udelade ældre versioner, kunden stadig bruger · de er en del af leverancen.
At lade adskillelsen mellem kunder være uprøvet · det er kundens største bekymring.
At love en belastningstest som del af penetrationstesten · det er en anden type test med andre regler.
At sende dokumentationen til API’et uden at nævne det, der ikke var med · kunden skal se grænsen.

Hvad kan og ikke kan konkluderes

En test af API’et kan dokumentere, hvordan de testede funktioner, roller og versioner modstod testen, herunder adskillelsen mellem kunder, hvis den var med. Den kan ikke vise, at API’et altid er tilgængeligt, og den siger intet om kundens egen håndtering af adgangsnøgler. Kunden vurderer, om testen dækker kundens afhængighed.