Podium communicatie- en rapportagelijnen, de inhoud (inclusief frequentie) van de rapportages, het melden van incidenten die zich voordoen bij de SaaSleverancier 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 SaaSleverancier. 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 SaaSapplicatie wordt toegang verleend tot de gegevens. 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 Nummer 46, april 2023 Selectie 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. 33
34 Online Touch Home