Status | ||
---|---|---|
|
Titel | M2M gegevensuitwisselingen | |
Status |
|
title | DRAFT |
---|
|
|
|
Stadium
Status | ||||
---|---|---|---|---|
|
Status | ||
---|---|---|
|
| ||
Versie | 0.0. |
13 |
Datum |
5 December 2023 | |
Auteur | Architectenraad Edu-V |
Acties | Geen acties |
In het Ecosysteem worden gegevens uitgewisseld tussen Leveranciers ten behoeve van Onderwijsorganisaties. De gegevensuitwisselingen vinden tussen systemen referentiecomponenten (M2M, van systeem naar systeem) plaats. Deze gegevensuitwisselingen dienen veilig te zijn en kunnen in sommige gevallen alleen plaatsvinden na een mandaat van een Onderwijsbestuur en het activeren van een nadat een onderwijsorganisatie de uitwisseling van een gegevenssoort voor een Onderwijsaanbieder heeft geactiveerd.
POC Scope
Tijdens de POC wordt geverifieerd of de huidige uitwerking van de M2M gegevensuitwisselingen een passende oplossing is voor de trade-off van de ontwerpprincipes:
Open en flexibel (#2)
Laagdrempelig en gebruiksvriendelijk (#3)
Technische interoperabiliteit (#5.4)
Toekomstbestendig en modern (#6)
Instemming vanuit de rechthebbende (#7)
Informatiebeveiliging (#9)
Data uit de bron (#10)
Traceerbaarheid en te beoordelen op compliance (#11)
Betrouwbaarheid (#12)
Vijf beveiligingslagen in M2M gegevensuitwisselingen
De beveiliging van M2M gegevensuitwisselingen is op vijf lagen georganiseerd.
...
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
...
Vijf beveiligingslagen in M2M gegevensuitwisselingen
De beveiliging van M2M gegevensuitwisselingen is op vijf lagen georganiseerd.
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 |
Info |
---|
Verzender is de bron, Ontvanger is de afnemer van gegevens Op deze pagina wordt, conform de definities voor Rollen, gesproken over Verzender en Ontvanger. Ter verduidelijk is de Verzender de bron van de gegevens en de Ontvanger de afnemer van de gegevens. |
De 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.
...
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. |
---|---|---|---|---|
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 | 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.
...
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. Tevens kan een Onderwijsorganisatie mandaten verstrekken aan Leveranciers voor het uitwisselen van vertrouwelijke gegevens waarvoor de Leverancier optreedt als Verwerker van het Verwerkersverantwoordelijke Onderwijsbestuur van de Onderwijsorganisatie.
...
Info |
---|
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 een Business of Ondersteunende rol en kunnen voor de desbetreffende rol en de gekozen referentiecomponenten één of meerdere gekozen referentiecomponenten en worden hiermee Deelnemer aan het Afsprakenstelsel Edu-V worden. Ze conformeren zich net als alle Leveranciers die de gekozen Business of Ondersteunende rol referentiecomponenten vervullen aan de bijbehorende afspraken. Een voorbeeld is bijvoorbeeld een MBO-instelling die de rol van Dashboardaanbieder referentiecomponent Dashboard gaat vervullen en voortgangsgegevens leermateriaalgebruik en toetsresultaten leerresultaten combineert in een eigen ontwikkeld Overkoepelend dashboard Dashboard leervoortgang en toetsresultaten-resultaten. |
Alvorens een Leverancier gegevens kan gaan uitwisselen in het Ecosysteem, dient een Leverancier te beschikken over:
...
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 Business of Ondersteunende rol en referentiecomponent.
Een Deelnemer kan met een andere Deelnemer koppelen vanuit één of meerdere van deze referentiecomponenten. Bilateraal kunnen daarnaast Bij het koppelen worden afspraken gemaakt worden welke gegevensdiensten en gegevenssoorten (scopes) er tussen de Deelnemers referentiecomponenten uitgewisseld worden.
Deelnemers hebben hun eigen procedure voor het aansluiten van andere Deelnemers. Voor deze procedure gelden de volgende operationele afspraken:
Voorbeeld
...
Deelnemers bepalen welke gegevensdiensten en gegevenssoorten (scopes) er onderling uitgewisseld gaan worden.
De mogelijkheden voor de gegevenssoorten zijn afhankelijk van de Business en Ondersteunende rollen die de Deelnemers vervullen en de door de Deelnemers gekozen en geïmplementeerde referentiecomponenten en koppelvlakkengegevensdiensten.
De Verzender en Ontvanger(s) van de gegevenssoorten, de BIV-clasficatie per gegevenssoort en de scopes voor de gegevenssoort zijn beschreven in Gegevenssoorten, Verzender en Ontvangers.
...
Info |
---|
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. Andere Business en Ondersteunende rollen hebben binnen het Ecosysteem niet de beschikking over de adresgegevens van Onderwijsdeelnemers. |
Deelnemers testen de 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
Info |
---|
Een Leverancier kan meerdere Clients hebben Doordat in het Edu-V afsprakenstelsel een Leverancier meerdere rollen referentiecomponenten kan vervullen en binnen deze rollen ook verschillende keuzes mogelijk zijn in referentiecomponenten , 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. |
Deelnemers Leveranciers sluiten optioneel een Service Level Agreement
Deelnemers Leveranciers zijn collegiaal in het aansluiten op elkaar. De hiervoor noodzakelijke gegevens, overeenkomsten en documentatie wordt tijdig verstuurd, behandeld en ondertekend.
De Deelnemers Leveranciers zijn na de aansluiting overeengekomen om gegevenssoorten met elkaar uit te gaan wisselen.
...
Note |
---|
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) en verificatie van de verwerkersovereenkomst bij de activering (laag 5). Op deze wijze wordt de verwerkersovereenkomst indirect geverifieerd. Routering . 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.
Verzender en Ontvanger 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 Verzender en Ontvanger Leveranciers via een beveiligde verbinding gegevens met elkaar uitwisselen.
Laag 4. Activering – Uitwisseling gegevenssoort voor Onderwijsaanbieder
De Leveranciers die optreden als Verzender en Ontvanger zijn op elkaar aangesloten (laag 2) en zijn beiden in staat om gegevens veilig uit te wisselen (laag 3). Een ontwerpprincipe is dat ‘gegevens worden uitgewisseld na instemming van de rechthebbende’ en meer in het bijzonder ‘De Onderwijsorganisatie heeft zeggenschap over zijn of haar gegevens van en over onderwijsdeelnemers en -medewerkers’. 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 Verzender en Ontvanger 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 gegevensoort gegevenssoort onderwijsdeelnemers of gebruiksgegevensleermiddelgebruik).
Onderwijsaanbieder binnen het Onderwijsbestuur
De Applicatiebeheerder activeert de gegevensuitwisseling bij de Bron of Verzender (de bron) van de gegevenssoort. Hiermee wordt voldaan aan het principe ‘In het Ecosysteem komt data uit de bron’.
De Bron of Verzender van de gegevenssoort identificeert en authentiseert de Applicatiebeheerder met een beveiligingsvnieau beveiligingsvniveau van substantieel in de referentiecomponent Consentmanagement.
Afnemer en Ontvanger heeft 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 Activeren en deactiveren van een gegevensuitwisseling.
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 Verzender en Ontvanger leveranciers uitgewisseld worden.
Laag 5. Verwerker – Deelnemer heeft toestemming als Verwerker
...
Om gegevens van de classificatie IV uit te kunnen wisselen dienen Verzender en Ontvanger te voldoen aan de volgende eisen:
Verzender en Ontvanger Leveranciers beschikken allebei over een geldige en door het Onderwijsbestuur ondertekende verwerkersovereenkomst.door het Onderwijsbestuur ondertekende verwerkersovereenkomst.
Note |
---|
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:
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. |
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. Hierbij gelden de volgende mogelijkheden:
De verwerkersovereenkomsten zijn door de Onderwijsorganisatie geregistreerd bij één Ondersteunende rol Registerhouder met de referentiecomponent Verwerkersregister.
De door de Onderwijsorganisatie gekozen Registerhouder beschikt over de referentiecomponent Verwerkersregister en voldoet aan de van toepassing zijnde functionele, technische en operationele afspraken zoals beschreven in Activeren en deactiveren van een gegevensuitwisseling.
Verwerkersovereenkomsten worden in dit Verwerkersregister gespecificeerd op het niveau van Onderwijsbestuur en Leverancier. De Leverancier is Verwerker van het Verwerkersverantwoordelijke Onderwijsbestuur. De registratie geeft hiermee aan of het Onderwijsbestuur een overeenkomst heeft met Leverancier.
Info |
---|
Verschil tussen Toestemming als verwerker en Activering of consent op gegevensuitwisseling In de verwerkersovereenkomst geeft een Onderwijsbestuur toestemming aan een Leverancier om als verwerker gegevens uit te wisselen. Dit staat niet gelijk aan een activering van een gegevensuitwisseling van een specifieke gegevenssoort voor een Onderwijsaanbieder (zie laag 4). In de registratie van de verwerkersovereenkomst hoeft hierdoor ook niet vastgelegd te worden welke gegevenssoorten er geactiveerd zijn ten behoeve van de onderwijsorganisatie. |
Verzender en Ontvanger zijn Leverancier is met de referentiecomponent Consentmanagement aangesloten op het Verwerkersregister van de door de Onderwijsorganisatie gekozen Registerhouder
De Onderwijsorganisatie heeft de gegevensuitwisseling vanuit het Verwerkersregister naar de referentiecomponent Consentmanagement van de Verzender of Ontvanger geactiveerd. Op deze wijze kan bijvoorbeeld:
Verzender Leverancier controleren of een nieuwe Ontvanger andere Leverancier een geldige registratie van een verwerkersovereenkomst heeft vanuit het Onderwijsbestuur van de Onderwijsorganisatie.
Bij het intrekken van een verwerkersovereenkomst door Onderwijsbestuur de Verzender en Ontvanger Leverancier op de hoogte worden gesteld en alle gegevensuitwisselingen worden gedeactiveerd.
Verzender Leverancier periodiek controleren of een registratie van een verwerkersovereenkomst voor Ontvanger een andere Leverancier nog actief is.
Verzender Leverancier controleert minimaal dagelijks of zijzelf en alle Ontvangers aangesloten Leveranciers nog beschikken over een geldige verwerkersovereenkomst.
Indien een verwerkersovereenkomst een einddatum heeft dan informeren Verzender en Ontvanger Leveranciers hun Applicatiebeheerder(s) hier tijdig over. Dit stelt de Applicatiebeheerder(s) in staat om de verwerkersovereenkomst (indien gewenst) te verlengen.
Verzender en Ontvanger Leveranciers sturen minimaal 60 dagen, 30 dagen, 14 dagen en 3 dagen voordat een verwerkersovereenkomst verloopt een melding naar de Applicatiebeheerder(s).
Indien een Onderwijsorganisatie fuseert of splitst dan is Onderwijsorganisatie verantwoordelijk voor het tijdig verlenen van toestemming aan alle Leveranciers die ook in de nieuwe Onderwijsorganisatie een verwerkersovereenkomst dienen te hebben.
Onderwijsbestuur is verantwoordelijk voor een overgangssituatie van minimaal 30 dagen waarin zowel de verwerkersovereenkomsten vanuit de nieuwe Onderwijsorganisatie en de oude Onderwijsorganisatie als actief zijn geregistreerd in het verwerkersregister.
Verzender en Ontvanger Leveranciers zijn verantwoordelijk voor het actualiseren van de registraties binnen de overgangssituatie zodat gegevensuitwisselingen die geactiveerd zijn blijven werken.
Indien een Onderwijsorganisatie de intentie heeft om een verwerkersovereenkomst in te trekken, en als gevolg hiervan alle gegevensuitwisselingen te deactiveren dan trekt het Onderwijsbestuur de registratie van de verwerkersovereenkomst voor een Leverancier in. Verzender en Ontvanger Leveranciers deactiveren vervolgens alle geactiveerde gegevensuitwisselingen voor de onderliggende Onderwijsaanbieders.
De Onderwijsorganisatie is verantwoordelijk voor een correcte registratie van het Onderwijsbestuur en al haar Onderwijsaanbieders (inclusief identifiers) bij de Registerhouder een Leverancier met de referentiecomponent ScholenregisterRegister onderwijsorganisaties.
Vertrouwelijke gegevens waarvoor de Onderwijsorganisatie Verwerkersverantwoordelijke is kunnen na deze laag veilig uitgewisseld worden door Deelnemers Leveranciers die als verwerker toestemming hebben gekregen van het Onderwijsbestuur.
...