Titel

M2M gegevensuitwisselingen

Status

Versie

1.0.1

Datum

25 Juni 2024

Auteur

Architectenraad Edu-V

Acties

Geen acties

In het Edu-V afsprakenstelsel 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 informatieobject voor een Onderwijsaanbieder heeft geactiveerd.

Vijf beveiligingslagen in M2M gegevensuitwisselingen

De beveiliging van M2M gegevensuitwisselingen is op vijf lagen georganiseerd.

Beveiligingslaag

Toelichting

Relatie

1. Toetreding

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

L → D

2. Registratie

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 informatieobject 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 informatieobject 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 informatieobjecten. We onderscheiden hierbij vier classificaties.

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

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

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

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 Informatieobjecten is voor alle informatieobjecten in het afsprakenstelsel de classificatie bepaald conform bovenstaande richtlijn.

Laag 1. Toetreding – Leveranciers zijn bekend

Alle Leveranciers in het Edu-V afsprakenstelsel 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 afsprakenstelsel. Bij de toetreding wordt tevens de identiteit van de Leverancier vastgelegd. Op deze manier kan een Leverancier in het afsprakenstelsel 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 afsprakenstelsel. 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 afsprakenstelsel, dient een Leverancier te beschikken over:

De Leverancier is na toetreding te herkennen binnen het afsprakenstelsel op basis van het OIN.

Laag 2. Registratie – 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 informatieobjecten (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:

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.

Een Leverancier kan meerdere Clients hebben

Doordat in het Edu-V afsprakenstelsel een Leverancier meerdere referentiecomponenten kan vervullen en organisaties meerdere applicaties aan kunnen bieden, is het van belang om in de gegevensuitwisseling te kunnen bepalen met welke applicatie een Leverancier deel gaat nemen aan een gegevensuitwisseling.

Zoals in het vorige informatieblok toegelicht bepaalt 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 applicatie een eigen client_id uitgewisseld. In een applicatie van een leverancier kunnen meerdere referentiecomponenten zitten.

In aanvulling hierop wordt bij in de Clientregistratie het OIN en de scopes vastgelegd. De scopes representeren de gegevensdiensten die met deze Client worden uitgewiseld.

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

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

Laag 3. Uitwisseling – Iedere gegevensdienst is veilig

Iedere uitwisseling in een gegevensdienst dient plaats te vinden via een beveiligde connectie en vanuit systemen die voldoen aan de eisen voor informatiebeveiliging.

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

Edukoppeling

De werkgroep Edukoppeling heeft een Best Practice ontwikkeld voor implementatie van het NL GOV Assurance profile voor OAuth 2.0. Deze Best Practice is ook van toepassing op het Edu-V afsprakenstelsel. Edu-V conformeert zich aan de afspraken die zijn gemaakt in de werkgroep Edukoppeling waardoor we technische interoperabiliteit over alle onderwijssectoren borgen.

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

Laag 4. Activering – Uitwisseling informatieobject 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 gegevensdienst te activeren of deactiveren.

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

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

Laag 5. Verwerker – Deelnemer heeft toestemming als Verwerker

Persoonsgegevens 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 persoonsgegevens van de classificatie IV uit te kunnen wisselen dienen Verzender en Ontvanger te voldoen aan de volgende eisen:

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.

Persoonsgegevens 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

note

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 /wiki/spaces/AFSPRAKENS/pages/9175055 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.

  • 0.0.15: De werkgroep Edukoppeling gaat het Secure API OAuth Client Credentials profiel niet verder ontwikkelen en direct verwijzen naar het NL GOV Assurance profile voor OAuth 2.0. Dit leidt ook tot wijzigingen binnen de toepassing van M2M identificatie, authenticatie en autorisatie voor Edu-V. De wijzigingen zijn verwerkt op deze pagina.

  • 1.0.0: Het Architectuurkader Edu-V is vastgesteld als startpunt voor de implementatie. Tevens is instemming verleend op verdere doorontwikkeling van het Architectuurkader Edu-V op basis van de Architectuurprincipes. Dit akkoord is verleend op het Bestuurlijk Overleg van 27 mei 2024.

  • 1.0.1: Verwijzing naar Best Practice Edukoppeling voor NL GOV Assurance profile voor OAuth 2.0 toegevoegd en op laag van Registratie verwezen naar beheerproces Toetreding.

  • 1.0.2: Verduidelijking van de onderlinge registratie en aansluiting van leveranciers die met elkaar gegevens gaan uitwisselen:

    • Verduidelijkt welke gegevens er uitgewisseld worden.

    • Verduidelijkt op welke wijze de client_id wordt bepaald.

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.

  • 0.0.15: De werkgroep Edukoppeling gaat het Secure API OAuth Client Credentials profiel niet verder ontwikkelen en direct verwijzen naar het NL GOV Assurance profile voor OAuth 2.0. Dit leidt ook tot wijzigingen binnen de toepassing van M2M identificatie, authenticatie en autorisatie voor Edu-V. De wijzigingen zijn verwerkt op deze pagina.

  • 1.0.0: Het Architectuurkader Edu-V is vastgesteld als startpunt voor de implementatie. Tevens is instemming verleend op verdere doorontwikkeling van het Architectuurkader Edu-V op basis van de Architectuurprincipes. Dit akkoord is verleend op het Bestuurlijk Overleg van 27 mei 2024.

  • 1.0.1: Verwijzing naar Best Practice Edukoppeling voor NL GOV Assurance profile voor OAuth 2.0 toegevoegd en op laag van Registratie verwezen naar beheerproces Toetreding.

  • 1.0.2: Verduidelijking van de onderlinge registratie en aansluiting van leveranciers die met elkaar gegevens gaan uitwisselen:

    • Verduidelijkt welke gegevens er uitgewisseld worden.

    • Verduidelijkt op welke wijze de client_id wordt bepaald.