De keten platslaan

In de Code voor Informatiebeveiliging: 2000, deel 1 (het equivalent van de ISO 27002 norm nu) staan wat opvallende zinnen:

• ‘Er zijn diverse redenen om derden toegang te verlenen’ en:
• ‘Derden dienen pas toegang… te verkrijgen wanneer er passende maatregelen zijn geïmplementeerd en er een contract is ondertekend…’.|

Hierachter zit een gedachte: het is niet gewoon dat derden toegang krijgen. Derden krijgen toegang vanaf de fysieke locatie van de organisatie of via een specifiek communicatiekanaal. Derden krijgen pas toegang nadat er een risicoanalyse is uitgevoerd, maatregelen zijn genomen en er een geldig contract is. Vierentwintig jaar later is het wel anders: toegang door derden over het internet is de norm. De risicoanalyse is gebleven. Contracten zijn steeds meer standaard geworden. Particuliere derden krijgen bescherming: privacybeleid, bancaire zorgplicht.

Deze column gaat over derden met toegang tot de eigen infrastructuur. De principes kunnen ook afgebeeld worden op een SaaS-oplossing, maar dan draaien af en toe de rollen beheerder/gebruiker om, wat het complexer maakt.

Wanneer je gecertificeerd bent tegen de ISO 27001 of NEN 7510 norm, dan mag je stellen dat je zicht hebt op je eigen beveiliging. Heb je dan ook genoeg zicht op de risico’s van derden in de infrastructuur van de organisatie? Hier wordt het moeilijk. Het is lastig tot onmogelijk om leveranciers jouw beveiligingsregime op te leggen.

Wat je minstens kunt bereiken is dat je weet wie er allemaal toegang hebben tot welk deel van je infrastructuur, hoe je met deze gebruikers in contact kunt komen en – zonodig – de onmisbare beveiligingsmaatregelen kunt coördineren. Digitale toegang wordt verkregen via een gebruikersinterface (UI) of via een programmainterface
(API). Hoe minder de invloed en medewerking van de ander, hoe meer je deze gebruikers wilt isoleren in je infrastructuur. Gebruikers van internetbankieren gebruiken de app en de gateway (API) of de webapplicatie (UI). Op het banknetwerk zul je niet kunnen komen.

Die toegang wordt gecontroleerd door software in de infrastructuur van de organisatie, al moet ik hierbij aantekenen dat daar ook vaak een beroep wordt gedaan op andere dienstverleners, zoals de verificatie van een organisatie-account door de Entra ID service van Microsoft. Het kan snel een wirwar van communicatie via API’s over en weer worden, en wat er overblijft is een zogenaamd ‘access token’ dat vervolgens het bewijs van de gebruiker is dat hij geauthenticeerd en geautoriseerd is: Zero Trust heet dat.

Als het werkt vormt het een prima beveiliging. Als het niet werkt, ligt potentieel je infrastructuur open. De werking van dit mechanisme wil je dus heel goed monitoren. Functioneel én op signalen van misbruik.

De andere maatregel is toch om het bereik van accesstokens van derden in je infrastructuur te beperken. De meest eenvoudige beperking is de locatie in de infrastructuur en data die toegankelijk is. Maar ook functionaliteit en tijd kunnen factoren zijn. Bij een hoog risico: geef alleen rechten af die beperkt zijn tot de situatie en voor een beperkte tijd.

Het aparte is dat dit geen zaken zijn die je (exclusief) in relatiemanagement regelt. Veel komt neer op het hebben van een veilige infrastructuur, een goede toegangsbeveiliging erop en monitoring van de hoog risico activiteiten in jouw infrastructuur. Dit mag je in principe ook verwachten van je SaaS-provider, al is het verstandig dat dan wel contractueel te regelen en je te beseffen dat de regie bij de provider ligt en je mogelijkheden om te monitoren veel beperkter zijn.

Lex Borger
Security consultant bij Tesorion en oud-hoofdredacteur van iB-Magazine.
Lex is bereikbaar via lex.borger@tesorion.nl

Deze column verscheen in IB4-2024.