Integrationer og dataudveksling med kundens systemer

En integration er en fast forbindelse mellem jeres system og kundens, hvor data flyttes automatisk, måske uden at et menneske ser på det undervejs. For en NIS2-kunde er det netop forbindelsen, der vurderes: hvad den kan sende ind i kundens systemer, hvilke rettigheder den har, og hvad der sker, hvis den ene ende bliver kompromitteret. Testen skal derfor dække forbindelsen fra begge sider, og det kræver en aftale om, hvem der tester hvad.

Kunden ejer sin ende, I ejer jeres, og ingen af jer kan teste hele forbindelsen alene. Teksten er ikke juridisk rådgivning.

Hvorfor forbindelsen vejer tungt hos kunden

Gennemførelsesforordning (EU) 2024/2690 gælder direkte for bestemte digitale udbydere, fx cloud, datacentre og administrerede tjenester, og bruges af andre NIS2-kunder som inspiration. To punkter i bilaget handler om forbindelser mellem systemer:

Pålidelige kanaler · punkt 6.7.2, litra i, siger, at kommunikation mellem særskilte systemer kun etableres gennem pålidelige kanaler, der er adskilt fra andre kanaler, kan identificere deres slutpunkter og beskytter data mod ændring eller videregivelse.
Adskillelse fra tredjeparter · punkt 6.8.1 siger, at enheden opdeler sine systemer og net, så de er adskilt fra tredjeparters systemer og net.

SAMSIK’s vejledning om foranstaltninger, afsnittet om adgangskontrol (9.b), nævner også processers adgang, fx når et eksternt net- og informationssystem skal forbindes til et internt system. Jeres integration er netop sådan et eksternt system set fra kunden. → Adskillelse i netværket

Tre spørgsmål, kunden stiller til forbindelsen

Kundens vurdering af en integration kan handle om tre ting:

Hvad kommer ind · om data fra jer kontrolleres, før kundens system bruger dem, og om forbindelsen kan bruges til andet end det aftalte.
Hvad kan den gøre · hvilke rettigheder kontoen eller nøglen bag forbindelsen har i kundens system.
Hvem kan bruge den · hvordan nøgler og adgangsoplysninger opbevares hos jer, og hvem der kan se dem.

Det sidste spørgsmål peger tilbage på jer. Hvis en angriber kommer ind i jeres system, kan nøglen til kundens integration være det mest værdifulde, der kan findes. Kunden vil derfor vide, hvordan I beskytter den, hvem hos jer der kan se den, og hvordan den skiftes, hvis en medarbejder med adgang stopper, eller der er mistanke om, at den er kommet i forkerte hænder. En nøgle, der aldrig er blevet skiftet, er et spørgsmål, kunden kan stille, uden at en test er nødvendig for at besvare det. → API’et, kunden kalder

Del testen af forbindelsen

En integration kan opdeles i tre afsnit, der kan testes af forskellige parter:

Jeres ende · den del af jeres system, der sender og modtager data, og opbevaringen af nøgler. Den kan I teste selv.
Selve forbindelsen · hvordan parterne identificerer hinanden, og hvordan data beskyttes undervejs. Den kan kræve begge parters medvirken.
Kundens ende · det, kundens system gør med de data, der kommer fra jer, og de rettigheder, jeres konto har dér. Den kræver kundens tilladelse og kan blive testet af kundens egen tester.

Aftal på forhånd, hvem der tester hvert afsnit, og hvordan resultaterne deles. Ellers kan begge parter tro, at den anden har testet forbindelsen. → Afgrænsning mod kundens eget miljø

Testdata og kundens produktion

En test af en integration kan sende data ind i kundens system. Hvis forbindelsen kun findes i kundens produktion, kan testdata ende i kundens fagsystem, i kundens rapporter eller hos kundens egne modtagere. Det kan forstyrre kundens drift og give forkerte oplysninger videre.

Brug derfor et testmiljø, hvis kunden har et, eller aftal præcist, hvilke data testen må sende, og hvordan de fjernes bagefter. Et testmiljø giver ikke altid samme billede som produktionen, så skriv i dokumentationen, hvor testen er foretaget, og hvad forskellen betyder. → Når en fejl hos jer kan ramme kundens egne modtagere

Integrationer, I har arvet

En integration kan være opsat for år tilbage af medarbejdere, der ikke længere er i virksomheden. Dokumentationen kan være mangelfuld, og ingen husker, hvilke rettigheder kontoen fik. Før testen kan det betale sig at lave en oversigt: hvilke integrationer findes, hvilke data flyttes, hvem ejer kontiene, og hvornår blev nøglerne sidst skiftet. Oversigten er i sig selv nyttig for kunden og kan afsløre forbindelser, som ingen længere bruger, men som stadig er åbne. Luk dem, før testen starter, og skriv i dokumentationen, at de er lukket. Så bruger testen tiden på de forbindelser, der faktisk er i brug, og kunden får samtidig et opdateret billede af, hvad der forbinder jer.

Et tænkt eksempel

En leverandør af et system til lønberegning har en integration til et universitets personaleadministration, hvor medarbejderdata hentes hver nat. Universitetet oplyser, at det er omfattet af NIS2, og beder om dokumentation for, at integrationen er sikker.

Leverandøren tester sin egen ende og opbevaringen af nøglen. Universitetet lader sin egen tester afprøve, hvad leverandørens konto kan i personalesystemet. Testen hos universitetet viser, at kontoen kan læse alle medarbejderdata, ikke kun de felter, lønberegningen bruger. Universitetet begrænser rettighederne, og leverandøren bekræfter, at integrationen fortsat virker. De to rapporter samles i ét notat, der beskriver hele forbindelsen. Notatet nævner også, hvem der ejer hvert afsnit, og hvornår forbindelsen skal gennemgås igen, fx når lønsystemet får en ny version, eller universitetet skifter personalesystem.

Det skal I lade være med

At teste kundens ende uden tilladelse · det er kundens system, også når jeres konto findes dér.
At sende testdata ind i kundens produktion uden aftale · data kan forstyrre kundens drift.
At overse nøglerne · opbevaringen hos jer er en del af forbindelsens sikkerhed.
At antage, at den anden part har testet · aftal ansvaret skriftligt.
At lade gamle integrationer stå · lukkede forbindelser kan ikke misbruges.

Hvad kan og ikke kan konkluderes

En test af en integration kan vise, om de afprøvede afsnit af forbindelsen holdt på testtidspunktet, og hvor rettighederne var bredere end nødvendigt. Den viser ikke, at forbindelsen er sikker i de afsnit, der ikke blev testet, og den siger intet om de systemer, kundens data senere sendes videre til. Hvordan kunden samlet vurderer forbindelsen, afhænger af kundens risikovurdering og aftalen med jer. → Mail og filudveksling med kunden