Selectie van een SaaS-leverancier: Maak de eisen expliciet!

Bij de selectie van een SaaS-leverancier door de overheid valt op dat voorafgaand aan het sluiten van het contract nauwelijks inhoudelijk met de mogelijke leveranciers wordt gesproken. De selectie is hoofdzakelijk gebaseerd op de schriftelijke reactie op de eisen die onderdeel uitmaken van de marktuitvraag. Het gevolg is dat bij de in gebruik name van een SaaS-dienst de desbetreffende overheidsinstantie regelmatig geconfronteerd wordt met de nadelige gevolgen van deze aanpak.

De selectie van een SaaS-leverancier moet gebaseerd zijn op concrete eisen op het gebied van: zakelijke functionaliteit, inkoopvoorwaarden, beschikbaarheid, integriteit en vertrouwelijkheid, data vindbaarheid, dataformaat, beheer en technische implementatie. In de praktijk is de keuze veelal gebaseerd op de inkoopvoorwaarden van de betreffende overheidsinstantie en een opsomming van eisen. Het gehanteerde abstractieniveau van de beschreven eisen is dat de dienst moet voldoen aan de BIO, de AVG en de standaarden zoals die zijn beschreven door Forum Standaardisatie. Het is een utopie om te veronderstellen dat een mogelijke leverancier de tijd neemt om de hieraan gerelateerde documentatie door te nemen en beschikt over de benodigde diepgaande inhoudelijke kennis om invulling te geven aan deze technische eisen. Een directeur van een van de grootste IT-bedrijven ter wereld verwoordde het als volgt: “De overheid moet technisch inhoudelijk sturen en niet het probleem bij de leverancier leggen.”

Wat verwacht u van een leverancier?

Bij de selectie van een SaaS-leverancier is het belangrijk dat betrokken organisaties weten wat er van hen verwacht wordt. Maak vanuit IAM-oogpunt (identity and access management) afspraken over: verantwoordelijkheden, communicatie- en rapportagelijnen, de inhoud (inclusief frequentie) van de rapportages, het melden van incidenten die zich voordoen bij de SaaS-leverancier en welke events worden gestuurd naar het Security Operations Center (SOC) van de desbetreffende overheidsinstantie.

Naast de benodigde afspraken is het van belang om de technische implementatie van de SaaS-leverancier te kennen om afwijkingen van de standaarden te kunnen vaststellen. Het doorgronden van de technische implementatie vereist diepgaande inhoudelijke kennis, zowel aan de kant van de overheid als aan de kant van de SaaS-leverancier. De praktijk leert dat deze kennis in betrokken organisaties schaars is. Een onderwerp dat extra aandacht verlangt, is de technische implementatie van authenticatie en autorisatie.

Authenticatie (wie ben je?)

Dit vindt plaats op basis van een specifiek betrouwbaarheidsniveau. DigiD en eHerkenning bijvoorbeeld bieden beide vier betrouwbaarheidsniveaus. Authenticatie bij SaaS-applicaties vindt in de huidige markt veelal federatief plaats, op basis van het SAML 2.0 protocol. Het federatieve authenticatieproces valt voor het grootste gedeelte buiten de reikwijdte van de SaaS-leverancier. De authenticatie-informatie in transport (van Identity Provider – naar applicatie) vereist dat deze informatie beveiligd is met minimaal TLS 1.2 inclusief bijbehorende cipher suites (zie NCSC website). Het is raadzaam om enkele accounts bij een SaaS-leverancier aan te maken voor SaaS-applicaties die onderdeel uitmaken van een cruciaal proces. Op deze manier wordt het risico gemitigeerd dat een SaaS-applicatie onbruikbaar is op het moment dat federatief aanmelden niet mogelijk is.

Autorisatie (wat mag je?)

Uit oogpunt van vertrouwelijkheid moet worden vastgesteld op basis van welke risicoafweging de SaaS-leverancier functiescheiding heeft geïmplementeerd. Autorisatie vindt plaats op basis van voorwaarden. Eén van de voorwaarden is het authenticatie betrouwbaarheidsniveau. In het merendeel van de SaaS-applicaties is het betrouwbaarheidsniveau geen voorwaarde voor toegang.

Autorisatie in een SaaS-applicatie kan op de volgende manieren geïmplementeerd zijn:

1. Token gebaseerde autorisatie. De federatie Identity Provider levert een token dat attributen bevat op basis waarvan toegang wordt verleend tot gegevens.
2. Object gebaseerde autorisatie. Op basis van een accountobject in de SaaS-applicatie wordt toegang verleend tot de gegevens.

Op basis van het AVG-principe Minimale Gegevensverwerking worden, vanuit IAM-oogpunt, minimaal de volgende gegevens geregistreerd bij een accountobject:

Maak gebruik van het SCIM protocol

De huidige SaaS-implementaties zijn hoofdzakelijk gebaseerd op object gebaseerde autorisatie. Hierbij wordt bij de eerste keer aanmelden een accountobject in de applicatie aangemaakt. In een dergelijke situatie vormt het ‘identity lifecycle management’ een aandachtspunt omdat het verwijderen van een accountobject in de applicatie niet automatisch plaatsvindt op het moment dat het gerelateerde federatieve account wordt verwijderd/disabled. Deze situatie is in strijd met het AVG-principe Opslagbeperking.

Om dit probleem te mitigeren biedt het merendeel van de SaaS-applicaties de functionaliteit voor geautomatiseerd ‘identity lifecycle management’ voor een specifieke doelgroep. Deze functionaliteit omvat het automatisch aanmaken van accountobjecten in de applicatie, inclusief de bijbehorende identiteitsinformatie, voorafgaand aan de eerste keer aanmelden. Ook is het mogelijk de identiteitsinformatie te updaten en het accountobject te verwijderen in de applicatie. Het door Forum Standaardisatie aanbevolen protocol om deze functionaliteit te realiseren is SCIM. Op het moment dat deze functionaliteit wordt aangeboden maar niet op basis van het SCIM-protocol dan moet nagegaan worden of wel alle functionaliteiten (import, update, verwijderen) worden ondersteund. Het nadeel is dat deze functionaliteit uitsluitend bruikbaar is voor accounts die door de desbetreffende overheidsinstantie beheerd worden. Met als gevolg dat de niet beheerde accountobjecten handmatig verwijderd moeten worden op basis van door de overheidsinstantie vastgestelde voorwaarden.

Identity Governance and Administration

Een Identity Governance and Administration (IGA) applicatie bevat de benodigde identiteitsinformatie en biedt ‘user account provisioning’ functionaliteit op basis van het SCIM protocol. Ook biedt een IGA-applicatie de functionaliteit om autorisatierollen te sturen naar een applicatie. Een eis vanuit IAM-oogpunt is dat de SaaS-applicatie de beschreven functionaliteiten biedt op basis van een standaard API waar de IGA-applicatie op kan aansluiten.

Onduidelijkheid over eisen

Tot slot: verwijzingen naar onderwerpen die door Forum Standaardisatie beschreven zijn, zijn niet altijd direct bruikbaar voor de SaaS-leverancier. Bijvoorbeeld de toegang tot een REST API op basis van het NL GOV Assurance Profile for OAuth 2.0. Het desbetreffende profile bevat verscheidene implementatiekeuzes. In de praktijk hebben weinig overheidsinstanties een OAuth configuratie uitgewerkt op basis van het NL GOV Assurance Profile met als gevolg dat de SaaS-leverancier niet weet wat exact geëist wordt door de overheid. Het advies is om een OAuth configuratie (inclusief implementatiekeuzes) te beschrijven en niet een algemene verwijzing op te nemen naar Forum Standaardisatie.

Voor de selectie van een SaaS-leverancier die voldoet aan de verwachting van de overheidsinstantie, moet invulling gegeven worden aan de volgende aspecten:

• De in het selectieproces betrokken medewerkers hebben inhoudelijke kennis van de benodigde zakelijke functionaliteiten, inkoopvoorwaarden, informatiebeveiliging, IAM, data, IT-architectuur en IT-beheer.
• De technische eisen zijn zodanig gespecificeerd dat deze bruikbaar zijn voor een SaaS-leverancier. Het advies is om deze technische eisen op te nemen in de standaardvoorwaarden van de overheidsinstantie bij de aankoop van software/software ontwikkeling.
• De overheidsinstantie en de mogelijke SaaS-leverancier moeten met elkaar het gesprek aangaan over de wijze van samenwerken en de wijze waarop technisch invulling wordt gegeven aan de gestelde eisen.