Titel | M2M gegevensuitwisselingen |
Status | IN ONTWIKKELING ROSA-ARCHITECTUURSCAN BESLUITVORMING IN BEHEER |
Versie | 1.0.1 |
Datum | 25 Juni 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 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. 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 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:
Vertrouwelijkheid: informatieobjecten kunnen vertrouwelijke of niet vertrouwelijke gegevens bevatten.
Regie op gegevensuitwisseling: de regie over het uitwisselen van informatieobjecten kan liggen bij een onderwijsorganisatie of een leverancier. Hieraan is sterk gerelateerd wie zeggenschap en/of (verwerkers)verantwoordelijk van de gegevens is.
Verwerkersovereenkomst: informatieobjecten 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 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 | 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. 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 toetreding te herkennen binnen het Ecosysteem op basis van het OIN.
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 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:
Deelnemers bepalen welke gegevensdiensten en informatieobjecten (scopes) er onderling uitgewisseld gaan worden.
De mogelijkheden voor de informatieobjecten 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 informatieobjecten 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 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:
De identificatie, authenticatie en autorisatie voldoet aan het NL GOV Assurance profile voor OAuth 2.0. De globale werking van dit profiel is toegelicht op de pagina M2M identificatie en authenticatie.
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.
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 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:
Een hiertoe gemachtigde Applicatiebeheerder van de Onderwijsaanbieder activeert de gegevensdienst tussen Verzender en Ontvanger of Bron en Afnemer voor een specifieke:
Gegevensdienst (bijvoorbeeld onderwijsdeelnemers, aanspraken of leermiddelgebruik).
Onderwijsaanbieder binnen het Onderwijsbestuur
En optioneel een subset van informatieobjecten
De Applicatiebeheerder activeert de gegevensdienst bij de Bron of Verzender van de informatieobjecten. 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 gegevensdienst identificeert en authentiseert de Applicatiebeheerder met een beveiligingsniveau 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 gegevensdienst waarbij een hoge integriteit voor de informatieobjecten 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 informatieobjecten in de gegevensdienst van de Onderwijsaanbieder controleren Bron en Afnemer of Verzender en Ontvanger of de gegevensuitwisseling geactiveerd is.
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:
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:
Niet aanwezig zijn van een verwerkersovereenkomst kan geen operationele blokkade zijn.
Verwerkersovereenkomst kan ook ergens anders opgeslagen zijn.
De huidige dekkingsgraad van verwerkersovereenkomsten is nog te laag.
Het controleren van een verwerkersovereenkomst van een andere leverancier is niet de verantwoordelijkheid van leveranciers
Dit is de verantwoordelijkheid van de andere leverancier en de school.
Als leverancier wil ik de vrijheid hebben om de verwerkersovereenkomsten in mijn eigen applicatie te laten ondertekenen.
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.
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
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.