M2M gegevensuitwisselingen

In het Ecosysteem worden gegevens uitgewisseld tussen Leveranciers ten behoeve van Onderwijsorganisaties. De gegevensuitwisselingen vinden tussen systemen (M2M) 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 uitwisseling van een gegevenssoort voor een Onderwijsaanbieder.

Vijf beveiligingslagen in M2M gegevensuitwisselingen

De beveiliging van M2M gegevensuitwisselingen is op vijf lagen georganiseerd.

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 al dan niet onder een verwerkersovereenkomst. Hier dient de Leverancier al dan niet over een toestemming te beschikken 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.

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. 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.

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)

  • Business of Ondersteunende rollen, referentiecomponenten en koppelvlakken

  • Endpoints

  • Contactgegevens

• Technische kwalificatie voor de gekozen business of ondersteunende rollen, referentiecomponenten en koppelvlakken.

De Leverancier is na registratie 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 Business of Ondersteunende rol en referentiecomponent.

Een Deelnemer kan met een andere Deelnemer koppelen vanuit één of meerdere van deze referentiecomponenten. Bilateraal kunnen daarnaast afspraken gemaakt worden welke gegevenssoorten er tussen de Deelnemers uitgewisseld worden.

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

• Deelnemers bepalen welke gegevenssoorten 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 koppelvlakken.

  • 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.

• 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

Deelnemers sluiten optioneel een Service Level Agreement

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

De Deelnemers 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 Bureau 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:

• De identificatie, authenticatie en autorisatie voldoet aan het profiel: 2023-07-24 Edukoppeling - Secure API OAuth Client Credentials profielen v0.8 (concept). De globale werking van dit profiel is toegelicht op de pagina M2M identificatie en authenticatie.

• 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 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 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 te voldoen aan de volgende eisen:

• Verzender en Ontvanger zijn verwerker door het Onderwijsbestuur (zie laag 4).

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

  • Gegevenssoort (bijvoorbeeld de gegevensoort onderwijsdeelnemers of gebruiksgegevens).

  • Onderwijsaanbieder binnen het Onderwijsbestuur

• De Applicatiebeheerder activeert de gegevensuitwisseling bij de Verzender (de bron) van de gegevenssoort. Hiermee wordt voldaan aan het principe ‘In het Ecosysteem komt data uit de bron’.

  • De Verzender van de gegevenssoort identificeert en authentiseert de Applicatiebeheerder met een beveiligingsvnieau van substantieel.

  • Ontvanger heeft de mogelijkheid om:

    • de activatie automatisch te bevestigen aan Verzender.

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

• 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 Verzender en Ontvanger of de gegevensuitwisseling geactiveerd is.

Gegevens waarvan de Onderwijsorganisatie eigenaar is kunnen na deze laag veilig tussen Verzender en Ontvanger 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.

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

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

• 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.

• Verzender en Ontvanger zijn 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 controleren of een nieuwe Ontvanger 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 op de hoogte worden gesteld en alle gegevensuitwisselingen worden gedeactiveerd.

  • Verzender periodiek controleren of een registratie van een verwerkersovereenkomst voor Ontvanger nog actief is.

• Verzender controleert minimaal dagelijks of zijzelf en alle Ontvangers nog beschikken over een geldige verwerkersovereenkomst.

• Indien een verwerkersovereenkomst een einddatum heeft dan informeren Verzender en Ontvanger hun Applicatiebeheerder(s) hier tijdig over. Dit stelt de Applicatiebeheerder(s) in staat om de verwerkersovereenkomst (indien gewenst) te verlengen.

  • Verzender en Ontvanger 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 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 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 met de referentiecomponent Scholenregister.

Vertrouwelijke gegevens waarvoor de Onderwijsorganisatie Verwerkersverantwoordelijke is kunnen na deze laag veilig uitgewisseld worden door Deelnemers die als verwerker toestemming hebben gekregen van het Onderwijsbestuur.

Release notes