M2M gegevensuitwisselingen

Titel

M2M gegevensuitwisselingen

Status

In ontwikkeling ROSA-Architectuurscan BEsluitvorming in beheer

Versie

0.0.14

Datum

31 januari 2024

Auteur

Architectenraad Edu-V

Acties

Geen acties

In het Ecosysteem worden gegevens uitgewisseld tussen Leveranciers ten behoeve van Onderwijsorganisaties. De gegevensuitwisselingen vinden tussen referentiecomponenten (M2M, van systeem naar systeem) plaats. Deze gegevensuitwisselingen dienen veilig te zijn en kunnen in sommige gevallen alleen plaatsvinden nadat een onderwijsorganisatie de uitwisseling van een gegevenssoort voor een Onderwijsaanbieder heeft geactiveerd.

Vijf beveiligingslagen in M2M gegevensuitwisselingen

De beveiliging van M2M gegevensuitwisselingen is op vijf lagen georganiseerd.

Beveiligingslaag

Toelichting

Relatie

Beveiligingslaag

Toelichting

Relatie

1. Registratie

Een Leverancier (L) registreert zich bij het Edu-V afsprakenstelsel en wordt Deelnemer (D).

L → D

2. Aansluiting

Een Deelnemer (D) sluit zich voor een gegevensuitwisseling aan bij een andere Deelnemer en wordt Verzender (DV) of Ontvanger (DO).

D → DV of DO

3. Uitwisseling

Een Verzender (DV) wisselt gegevens uit met een Ontvanger (DO). De uitwisseling (u) tussen de Verzender en Ontvanger is veilig.

DV <-u-> DO

 

4. Activering

Een Applicatiebeheerder van een Onderwijsorganisatie activeert de uitwisseling van een gegevenssoort tussen een Verzender (DV) en Ontvanger (DO) voor een specifieke Onderwijsaanbieder (Oa) binnen een Onderwijsbestuur (Ob).

DV <-u-> DO voor Oa

5. Verwerker

Het Onderwijsbestuur (Ob) verleent als verwerkersverantwoordelijke toestemming aan een Deelnemer voor het verwerken van gegevens. De Deelnemer wordt Deelnemer met Verwerkersovereenkomst (Dvo) voor het desbetreffende Onderwijsbestuur.

Indien de gegevenssoort dit vereist, dan hebben zowel Verzender (DvoV) als Ontvanger (DvoO) een verwerkersovereenkomst voor het uitwisselen van de gegevens namens Onderwijsbestuur (Ob).

D → Dm voor Ob

DvoV <-u-> DvoO voor Oa binnen Ob

De vijf beveiligingslagen worden hieronder nader uitgewerkt. Hierbij is de toepassing van de beveiligingsniveau afhankelijk van de classificatie van de gegevenssoorten. We onderscheiden hierbij vier classificaties.

Classificatie van gegevenssoorten: I, II, III en IV.

Afhankelijk van de eigenschappen van de gegevenssoort dienen Leveranciers de beveiligingslagen in M2M gegevensuitwisselingen toe te passen. Als kader hanteren we de volgende eigenschappen van gegevenssoorten:

  • Vertrouwelijkheid: gegevenssoorten kunnen vertrouwelijke of niet vertrouwelijke gegevens bevatten.

  • Regie op gegevensuitwisseling: de regie over het uitwisselen van gegevenssoorten kan liggen bij een onderwijsorganisatie of een leverancier. Hieraan is sterk gerelateerd wie zeggenschap en/of (verwerkers)verantwoordelijk van de gegevens is.

  • Verwerkersovereenkomst: gegevenssoorten van een onderwijsorganisatie vallen, indien deze persoonsgegevens bevatten onder de verwerkersverantwoordelijkheid van het onderwijsbestuur. In dat geval dient het onderwijsbestuur een verwerkersovereenkomst te hebben met de leverancier die optreedt als verwerker. De Leverancier verkrijgt via deze verwerkersovereenkomst een toestemming om de gegevens als Verwerker namens de Onderwijsorganisatie uit te wisselen.

Deze eigenschappen hebben geresulteerd in vier classificaties van gegevenssoorten. Deze vier classificaties vragen ieder om een andere toepassing van de beveiligingslagen. De classificatie is uitgewerkt in onderstaand schema.

Classificatie

I.

II.

III.

IV.

Classificatie

I.

II.

III.

IV.

Vertrouwelijkheid

Niet vertrouwelijk

Niet vertrouwelijk

Vertrouwelijk

Vertrouwelijk

Regie op gegevens-uitwisseling

Leverancier

Onderwijs-organisatie

Leverancier

Onderwijs-organisatie

Persoonsgegevens

Nee

Nee

Nee

Ja

Verwerkers-overeenkomst

Nee

Nee

Nee

Ja

Voorbeeld

Catalogus-informatie

SchoolVak
SchoolPeriode

Orders

Normeringen

Onderwijs-deelnemers en –medewerkers

Leermiddel-gebruik

Beveiligingslagen

1 t/m 3

1 t/m 4

1 t/m 3 met extra veiligheidseisen

1 t/m 5 met extra veiligheidseisen

Op de pagina Gegevenssoorten, Verzender en Ontvangers is voor alle gegevenssoorten in het Ecosysteem de classificatie bepaald conform bovenstaande richtlijn.

Laag 1. Registratie – Leveranciers zijn bekend

Alle Leveranciers in het Ecosysteem dienen zich te conformeren aan de afspraken uit het Afsprakenstelsel Edu-V. Op deze manier beheersen we de continuïteit en de veiligheid van het Ecosysteem. Bij de registratie wordt tevens de identiteit van de Leverancier vastgelegd. Op deze manier kan een Leverancier in het Ecosysteem worden geïdentificeerd en kan een Leverancier op een veilige manier deelnemen aan gegevensuitwisselingen.

Onderwijsorganisatie als Leverancier

Indien Onderwijsorganisaties in-house applicaties hebben ontwikkeld dan kunnen ze als zijnde ‘eigen’ Leverancier deelnemen aan het Ecosysteem. Ze vervullen dan net als alle andere Leveranciers één of meerdere gekozen referentiecomponenten en worden hiermee Deelnemer aan het Afsprakenstelsel Edu-V. Ze conformeren zich net als alle Leveranciers die de gekozen referentiecomponenten vervullen aan de bijbehorende afspraken.

Een voorbeeld is bijvoorbeeld een MBO-instelling die de referentiecomponent Leermiddelendashboard gaat vervullen en leermateriaalgebruik en leerresultaten combineert in een eigen ontwikkeld Dashboard leervoortgang en -resultaten.

Alvorens een Leverancier gegevens kan gaan uitwisselen in het Ecosysteem, dient een Leverancier te beschikken over:

  • Organisatie Identificerend Nummer (OIN). Binnen Edu-V hanteren we de richtlijn vanuit Edukoppeling voor het opbouwen van het OIN voor Leveranciers wordt conform de standaard Edukoppeling het Handelsregisternummer (HRN) gebruikt.

  • Een geldige registratie bij Edu-V. De volgende informatie is tenminste bij Edu-V bekend:

    • Organisatie Identificerend Nummer (OIN)

    • Referentiecomponenten en gegevensdiensten

    • Endpoints

    • Contactgegevens

  • Technische kwalificatie voor de gekozen referentiecomponenten en gegevensdiensten.

De Leverancier is na registratie te herkennen binnen het Ecosysteem op basis van het OIN.

Werkgroep Beheersing

De registratie van Leveranciers wordt in een later stadium nader uitgewerkt als onderdeel van de afspraken over de wijze van toetreden binnen de Werkgroep Beheersing. In een volgende versie zal deze paragraaf naar deze expliciete afspraken verwijzen.

Laag 2. Aansluiting – Deelnemers zijn gekoppeld

Om een gegevensuitwisseling tot stand te brengen tussen Deelnemers dienen de Deelnemers technisch op elkaar aangesloten te zijn. In het Edu-V afsprakenstelsel worden afspraken gemaakt over de specificatie van koppelvlakken voor iedere referentiecomponent.

Een Deelnemer kan met een andere Deelnemer koppelen vanuit één of meerdere van deze referentiecomponenten. Bij het koppelen worden afspraken gemaakt welke gegevensdiensten en gegevenssoorten (scopes) er tussen de referentiecomponenten uitgewisseld worden.

Deelnemers hebben hun eigen procedure voor het aansluiten van andere Deelnemers. Voor deze procedure gelden de volgende operationele afspraken:

  • Deelnemers bepalen welke gegevensdiensten en gegevenssoorten (scopes) er onderling uitgewisseld gaan worden.

    • De mogelijkheden voor de gegevenssoorten zijn afhankelijk van de door de Deelnemers gekozen en geïmplementeerde referentiecomponenten en gegevensdiensten.

Voorbeeld

Als referentiecomponent Distributiefaciliteit is het mogelijk om adresgegevens van Onderwijsdeelnemers te ontvangen van een Administratiesysteem onderwijsdeelnemers. Zo kan een leverancier in de fijndistributie Leermiddelen op thuisadres laten bezorgen.

  • Deelnemers testen de aansluiting. Deelnemers delen hiervoor de noodzakelijke gegevens met elkaar:

    • Acceptatieomgeving (endpoints voor testdoeleinden)

    • Productieomgeving (endpoints)

    • Technische documentatie

    • Client credentials voor M2M identificatie, authenticatie en autorisatie

      • Client id per referentiecomponent

      • (optioneel) secret per Client Id

      • Scopes per Client id

Een Leverancier kan meerdere Clients hebben

Doordat in het Edu-V afsprakenstelsel een Leverancier meerdere referentiecomponenten kan vervullen, is het van belang om in de gegevensuitwisseling te kunnen bepalen vanuit welke hoedanigheid een Leverancier deel gaat nemen aan een gegevensuitwisseling.

Zoals in het vorige informatieblok toegelicht bepaalt namelijk de referentiecomponent welke gegevens beschikbaar zijn om uit te kunnen wisselen. Dit dient ook geborgd te zijn bij de identificatie, authenticatie en autorisatie.

Bij het aansluiten van twee Leveranciers wordt voor iedere referentiecomponent een eigen Client id uitgewisseld (eventueel met een eigen secret). In aanvulling hierop wordt bij het Client id geregistreerd welke gegevenssoorten uitgewisseld mogen worden. Dit wordt vastgelegd in de scope.

Een Leverancier kan vervolgens in de uitwisseling (laag 3) een gegevensuitwisseling starten in een bepaalde scope. Zo kan geverifieerd worden of de Leverancier ook deze gegevens mag uitwisselen op basis van de scopes die beschikbaar zijn voor de client.

Leveranciers sluiten optioneel een Service Level Agreement

  • Leveranciers zijn collegiaal in het aansluiten op elkaar. De hiervoor noodzakelijke gegevens, overeenkomsten en documentatie wordt tijdig verstuurd, behandeld en ondertekend.

De Leveranciers zijn na de aansluiting overeengekomen om gegevenssoorten met elkaar uit te gaan wisselen.

Laag 3. Uitwisseling – Iedere uitwisseling is veilig

Iedere gegevensuitwisseling dient plaats te vinden via een beveiligde connectie en vanuit systemen die voldoen aan de eisen voor informatiebeveiliging. Edu-V benut op dit vlak de door Edustandaard ontwikkelde en beheerde standaard Edukoppeling.

Om gegevens van de classificatie I, II, III en IV uit te kunnen wisselen dienen Verzender en Ontvanger te voldoen aan de volgende eisen:

Niet van toepassing: Edukoppeling REST/SaaS-profiel

Het Edukoppeling REST/SaaS-profiel profiel wordt niet toegepast binnen Edu-V. Classificatie IV gegevenssoorten worden uitgewisseld na activering door de Onderwijsorganisatie (laag 4). Onderwijsorganisaties en Leveranciers zijn daarnaast gehouden aan de wettelijke plicht om een verwerkersovereenkomst te tekenen. Routering en controle op een mandaat is hiermee op een andere wijze geborgd.

  • De koppelvlakken zijn in staat om de transactiepatronen voor M2M gegevensuitwisselingen te ondersteunen.

    • Voor de transactiepatronen Abonneren op wijzigingen middels notificaties en Georkestreerde uitwisseling wordt de hiervoor benodigde berichteninfrastructuur voor het versturen en ontvangen van berichten gerealiseerd.

  • De koppelvlakken voldoen aan de afspraken over Versiebeheer.

  • Leveranciers voldoen aan alle technische, operationele en organisatorische eisen die voortkomen uit het kader voor Informatiebeveiliging. In dit kader zijn voorgeschreven:

    • Certificeringsschema informatiebeveiliging en privacy ROSA

    • Uniforme Beveiligingsvoorschriften Veilig en Betrouwbaar e-mailverkeer

    • Uniforme Beveiligingsvoorschriften Security Headers

    • Uniforme Beveiligingsvoorschriften – Transport Layer Security (TLS)

Na deze laag kunnen Leveranciers via een beveiligde verbinding gegevens met elkaar uitwisselen.

Laag 4. Activering – Uitwisseling gegevenssoort voor Onderwijsaanbieder

De Leveranciers zijn op elkaar aangesloten (laag 2) en zijn beiden in staat om gegevens veilig uit te wisselen (laag 3). Get architectuurprincipe D. Regie op gegevens en meer in het bijzonder D3 ‘De onderwijsorganisatie geeft toestemming over de uitwisseling van eigen gegevens tussen leveranciers.'. In deze vierde laag geven we iedere Onderwijsorganisatie de flexibiliteit om de uitwisseling van een gegevenssoort te activeren of deactiveren.

Om gegevens van de classificatie II en IV uit te kunnen wisselen dienen Leveranciers te voldoen aan de volgende eisen:

  • Een hiertoe gemachtigde Applicatiebeheerder van de Onderwijsaanbieder activeert de gegevensuitwisseling tussen Verzender en Ontvanger of Bron en Afnemer voor een specifieke:

    • Gegevenssoort (bijvoorbeeld de gegevenssoort onderwijsdeelnemers of leermiddelgebruik).

    • Onderwijsaanbieder binnen het Onderwijsbestuur

  • De Applicatiebeheerder activeert de gegevensuitwisseling bij de Bron of Verzender van de gegevenssoort. Hiermee wordt voldaan aan het architectuurprincipe ‘De leverancier van brongegevens is verantwoordelijk voor de integriteit van en mutaties op de gegevens met als doelstelling een enkele bron van waarheid voor gegevens uit de bron.’.

    • De Bron of Verzender van de gegevenssoort identificeert en authentiseert de Applicatiebeheerder met een beveiligingsvniveau van substantieel in de referentiecomponent Consentmanagement.

    • Afnemer en Ontvanger hebben de mogelijkheid om:

      • de activatie automatisch te bevestigen aan Bron of Verzender.

      • aan Bron of Verzender terug te geven dat de activatie wordt gecontroleerd (pending) en bijvoorbeeld een additionele controle uit te laten voeren door de Applicatiebeheerder van de Afnemer of Ontvanger. Dit is bijvoorbeeld van toepassing op een gegevenssoort waarbij een hoge integriteit van toepassing is bij de Afnemer of Ontvanger. Na deze additionele controle bevestigt de Afnemer of Ontvanger de activatie aan Bron of Verzender.

  • Bron en Afnemer of Verzender en Ontvanger beschikken over de referentiecomponent Consentmanagement en voldoen aan de voor hen geldende functionele, technische en operationele afspraken zoals beschreven in Regie op gegevens.

  • Bij iedere uitwisseling van gegevens van de gegevenssoort van de Onderwijsaanbieder controleren Bron en Afnemer of Verzender en Ontvanger of de gegevensuitwisseling geactiveerd is.

Gegevens waarvan de Onderwijsorganisatie eigenaar is kunnen na deze laag veilig tussen leveranciers uitgewisseld worden.

Laag 5. Verwerker – Deelnemer heeft toestemming als Verwerker

Gegevens die vallen onder de verwerkersverantwoordelijkheid van een Onderwijsbestuur kunnen alleen uitgewisseld worden door Leveranciers die hiertoe toestemming hebben gekregen door het Onderwijsbestuur.

Hulpmiddel Verwerker en/of Verwerkersverantwoordelijke

De Autoriteit Persoonsgegevens heeft een hulpmiddel gepubliceerd om te bepalen of er sprake is van een Verwerker en een Verwerkersverantwoordelijke in het geval dat er persoonsgegevens worden verwerkt.

Om gegevens van de classificatie IV uit te kunnen wisselen dienen Verzender en Ontvanger te voldoen aan de volgende eisen:

  • Leveranciers beschikken allebei over een geldige en door het Onderwijsbestuur ondertekende verwerkersovereenkomst.

  • Leveranciers zijn als Verwerker gebonden aan de afspraken zoals vastgelegd in de verwerkersovereenkomst en dienen daarnaast te voldoen aan de AVG. De implicatie hiervan is dat alleen de persoonsgegevens worden verwerkt waarvoor een leverancier ook daadwerkelijk doelbinding heeft.

    • Als voorbeeld kan een leverancier met een methode Biologie voor de onderbouw toestemming vanuit de onderwijsorganisatie hebben om gegevens uit het Administratiesysteem onderwijsdeelnemer te bevragen. De leverancier mag echter alleen de persoonsgegevens verwerken van de onderwijsdeelnemers die ook daadwerkelijk het vak Biologie volgen en in de onderbouw zitten.

    • Leveranciers treffen maatregelen om enkel deze persoonsgegevens te verwerken en beschikbaar te stellen in de eigen applicaties. De overige persoonsgegevens worden niet opgeslagen.

  • Indien een Onderwijsorganisatie fuseert of splitst dan is Onderwijsorganisatie verantwoordelijk voor het tijdig verstrekken van een nieuwe verwerkersovereenkomst aan alle Leveranciers die ook in de nieuwe Onderwijsorganisatie een verwerkersovereenkomst dienen te hebben.

Optioneel kunnen Leveranciers gebruik maken van het Verwerkersregister van de het Onderwijsbestuur om te controleren of de Leverancier waarmee gegevens worden uitgewisseld ook Verwerker zijn namens het Onderwijsbestuur. Het verifieren van de geldigheid van een verwerkersovereenkomst is beschreven in de sectie Regie op gegevens.

Verwerkersregister is niet verplicht, wel een optie voor Leveranciers

In een eerdere versie van het Architectuurkader Edu-V was er verplicht gebruik van het Verwerkersregister. Deze verplichting heeft geleid tot principiële bezwaren vanuit leveranciers.

De belangrijkste argumenten zijn:

  1. Niet aanwezig zijn van een verwerkersovereenkomst kan geen operationele blokkade zijn.

    1. Verwerkersovereenkomst kan ook ergens anders opgeslagen zijn.

    2. De huidige dekkingsgraad van verwerkersovereenkomsten is nog te laag.

  2. Het controleren van een verwerkersovereenkomst van een andere leverancier is niet de verantwoordelijkheid van leveranciers

    1. Dit is de verantwoordelijkheid van de andere leverancier en de school.

  3. Als leverancier wil ik de vrijheid hebben om de verwerkersovereenkomsten in mijn eigen applicatie te laten ondertekenen.

  4. Applicatiebeheerders die toegang hebben tot de referentiecomponent consentmanagement zijn hiertoe bevoegd door de onderwijsorganisatie. Ze hebben ook de taak om te controleren of de verwerkersovereenkomst ondertekend is. Het is dus procedureel opgelost en hoeft niet technisch opgelost te worden.

  5. Een verwerkersregister met contracten van alle leveranciers levert veel marktinformatie op één plek op. Is dat wel wenselijk?

Deze argumenten hebben geleid tot het schrappen van het verplicht gebruik maken van het Verwerkersregister. Het verwerkersregister is niet geschrapt uit het Ecosysteem om leveranciers die wel gebruik willen maken van de dienst hier toch mee te laten experimenteren.

De wettelijke verplichting voor het ondertekenen van een verwerkersovereenkomst blijft uiteraard onverminderd van toepassing.

Vertrouwelijke gegevens waarvoor de Onderwijsorganisatie Verwerkersverantwoordelijke is kunnen na deze laag veilig uitgewisseld worden door Leveranciers die als verwerker een verwerkersovereenkomst hebben getekend met het Onderwijsbestuur.


Release notes

Deze uitwerking is gebaseerd op basis van de volgende stappen:

  • 0.0.1: Documentstudie van Edukoppeling en SEM Ecosysteem.

  • 0.0.2: Voorbereidende bijeenkomst voor de Architectenraad van RdB en KV.

  • 0.0.3: Uitwerking in een concept inclusief voorstellen tot besluit.

  • 0.0.4: Verwerking van feedback vanuit Architectenraad naar een nieuwe iteratie met expliciete operationele afspraken op de vijf niveaus.

  • 0.0.5: De uitwerking is besproken en aangescherpt tijdens de werkconferentie van de Architectenraad Edu-V op 18 april 2023. Dit heeft geleid tot een scherpere scheiding tussen laag 4 mandaat (juridisch) en laag 5 activering (operationeel) van een gegevensuitwisseling waarover een Onderwijsorganisatie zeggenschap heeft. Tevens is de technische invulling van de uitwisseling (laag 3) aangescherpt.

  • 0.0.6: De beveiligingslagen zijn herschreven op basis van feedback uit de bijeenkomst van de Architectenraad van 12 mei 2023 en het overleg met de Werkgroep Edukoppeling binnen Edustandaard. Dit heeft geleid tot:

    • De lagen Activering en Mandatering zijn omgewisseld.

    • Er zijn vier classificaties van gegevenssoorten toegevoegd.

    • Het proces van activeren is vereenvoudigd waarbij controle voornamelijk bij de bron (Verzender) plaatsvindt.

    • PKIoverheid-certificaat is toegevoegd.

    • De werkgroep Edukoppeling werkt nog aan een nieuwe versie van het REST/SAAS profiel. Dit wordt in een volgende iteratie verwerkt.

  • 0.0.7: De specificatie voor het (de)activeren van gegevensuitwisselingen inclusief een mandaatcontrole voor classificatie IV gegevenssoorten is bijgewerkt op basis van de feedback uit de Architectenraad van 12 mei 2023.

  • 0.0.8: In de Architectenraad van 24 mei 2023 is gesproken over de toevoeging van de classificatie van gegevenssoorten.

    • Het kenmerk Eigenaar is aangepast. Het is niet mogelijk om eigenaar te zijn van een gegeven. Als andere voorstellen zijn verantwoordelijke en zeggenschap genoemd. Deze hebben echter een sterke relatie met de AVG, terwijl de classificatie juist ook gaat over gegevens waar de AVG niet op van toepassing is. Als voorstel is het kenmerk verandert naar Regie op gegevensuitwisseling.

    • Er is een link toegevoegd naar een hulpmiddel van de Autoriteit Persoonsgegevens om te bepalen of er sprake is van een Verwerkersverantwoordelijke en/of een Verwerker.

  • 0.09: Uitkomsten uit werkgroep Edukoppeling ten aanzien van het Secure API OAuth profiel gewerkt in laag 3 uitwisseling. In aanvulling hierop is ook een tijdelijke pagina toegevoegd over de beoogde werking van deze profielen. Deze pagina wordt verwijderd zodra de specificatie van de profielen is afgerond door de Werkgroep Edukoppeling. Er zal dan een verwijzing gemaakt worden naar de specificaties bij Edustandaard.

  • 0.0.10: Op basis van de werkgroep Edukoppeling van 27 juni is de verwijzing naar het Secure API OAuth profiel aangepast. De documentatie wordt nog opgeleverd door de werkgroep. De tijdelijke pagina M2M identificatie, authenticatie en autorisatie beschrijft de beoogde werking voor in de proof of concept.

  • 0.0.11: De term mandatenregister is vervangen door verwerkersregister. In de tekst is dit consistent doorgevoerd en wordt gesproken over toestemming die verleend is door het Onderwijsbestuur (Verwerkersverantwoordelijke) aan Leverancier om als verwerker persoonsgegevens te verwerken. Dit wordt geregistreerd in het verwerkersregister van het onderwijsbestuur. De registratie van de verwerkersovereenkomst is opvraagbaar voor Leveranciers. Met deze wijziging is ook de term mandaat vervangen.

  • 0.0.12: Verwijzing gemaakt naar Edukoppeling profiel: 2023-07-24 Edukoppeling - Secure API OAuth Client Credentials profielen v0.8 (concept)

  • 0.0.13: Verwijzing naar herziening consent aangepast. Nieuwe documentatie is te vinden in een separate sectie op Confluence: Regie op gegevens.

  • 0.0.14: De pagina is besproken tijdens de bijeenkomst van de Architectenraad Edu-V en is gereed voor de ROSA-architectuurscan.