In het Edu-V Ecosysteem worden gegevens uitgewisseld tussen Leveranciers ten behoeve van Onderwijsinstellingen. 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

In het Edu-V afsprakenstelsel is de beveiliging van M2M gegevensuitwisselingen op vijf lagen georganiseerd.

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:

• Eigenaar: gegevenssoorten kunnen van een onderwijsorganisatie of een leverancier zijn.

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

• Verwerkersovereenkomst: gegevenssoorten van een onderwijsorganisatie vallen al dan niet onder een verwerkersovereenkomst. Hier dient de Leverancier al dan niet over een mandaat 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.

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 en kan een Onderwijsinstelling mandaten verstrekken aan Leveranciers voor het uitwisselen van gegevens.

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 (Identificatie en authenticatie) 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-clasfiicatie per gegevenssoort en de scopes voor de gegevenssoort zijn beschreven in Verzender, Ontvanger(s) en BIV classificatie per gegegevensoort.

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

  • Acceptatieomgeving (endpoints voor testdoeleinden)

  • Productieomgeving (endpoints)

  • Technische documentatie

  • Certificaten (en client credentials) voor M2M identificatie en authenticatie

• 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 in staat om gegevens 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.

Iedere Verzender of Ontvanger in het Ecosysteem van Edu-V dient te voldoen aan de volgende eisen:

• De koppelvlakken voldoen aan het REST/SAAS profiel van Edukoppling [1].

• 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 [3] gerealiseerd.

• De koppelvlakken voldoen aan de afspraken over Versiebeheer.

• Identificatie en authenticatie is afhankelijk van de privacygevoeligheid van gegevens. Dit is nader uitgewerkt in M2M Identificatie en authenticatie [2].

  • Verzender en Ontvanger beschikken beiden over een geldig PKI Overheidscertificaat.

  • Voor M2M gegevensuitwisselingen met vertrouwelijke gegevens hanteren Verzender en Ontvanger:

  • Voor M2M gegevensuitwisselingen zonder vertrouwelijke gegevens hanteren Verzender en Ontvanger:

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

Verzender en Ontvanger zijn allebei in staat om gegevens veilig met elkaar uit te wisselen. Gegevens waarover Verzender zeggenschap heeft kunnen na deze laag veilig met elkaar uitgewisseld worden.

Laag 4. Activering – Uitwisseling gegevenssoort voor Onderwijsaanbieder

De Leveranciers die optreden als Verzender en Ontvanger zijn beide reeds gemandateerd door het Onderwijsbestuur om gegevens uit te wisselen (zie laag 4) voor de Onderwijsorganisatie. Echter dit wil niet zeggen dat voor alle Onderwijsaanbieders die onder dit Onderwijsbestuur vallen ook alle gegevenssoorten uitgewisseld kunnen gaan worden. In deze vijfde laag geven we iedere Onderwijsaanbieder de flexibiliteit om de uitwisseling van een gegevenssoort te activeren of deactiveren.

De combinatie van mandaat (laag 4) en activering (laag 5) is een uitwerking van het principe: ‘gegevens worden uitgewisseld na instemming van de rechthebbende’ en meer in het bijzonder ‘De Onderwijsinstelling heeft zeggenschap over zijn of haar gegevens van en over onderwijsdeelnemers en -medewerkers’.

Indien er gegevens worden uitgewisseld waar een Onderwijsorganisatie zeggenschap over heeft dan voldoen Verzender en Ontvanger aan de volgende additionele eisen:

• Verzender en Ontvanger zijn gemandateerd 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 van de gegevenssoort.

  • De Verzender van de gegevenssoort identificeert en authentiseert de Applicatiebeheerder met een hoog betrouwbaarheidsniveau.

  • Ontvanger heeft de mogelijkheid om:

    • de activatie vanuit de Verzender automatisch te bevestigen.

    • 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. Na deze additionele controle bevestigt de Verzender de activatie.

• 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 [5].

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

• De Onderwijsorganisatie is verantwoordelijk voor een correcte registratie van het Onderwijsbestuur en al haar Onderwijsaanbieders (inclusief identifiers) bij de Registerhouder met de referentiecomponent Scholenregister.

Gegevens waarover Onderwijsorganisatie zeggenschap heeft kunnen na deze laag veilig tussen Verzender en Ontvanger uitgewisseld worden.

Laag 5. Mandaat – Deelnemer is gemandateerd als Verwerker

De gegevens die uitgewisseld worden zijn van de Onderwijsorganisatie of van een Leverancier. Zo vallen gegevens over gebruikersgegevens (onderwijsdeelnemers of onderwijsmedewerkers) en gebruiksgegevens (onder meer gebruiksgegevens over leermiddelen, voortgangsgegevens over leermaterialen en toetsresultaten over toetsen) onder de verwerkersverantwoordelijkheid van het Onderwijsbestuur. Een uitwisseling van deze gegevenssoorten kan alleen plaats vinden nadat het Onderwijsbestuur de Leverancier heeft gemandateerd. Voor het uitwisselen van gegevens van een Leverancier, zoals bijvoorbeeld catalogusinformatie, is dit mandaat niet noodzakelijk.

Indien er gegevens worden uitgewisseld waar een Onderwijsorganisatie zeggenschap over heeft dan voldoen Verzender en Ontvanger aan de volgende additionele eisen:

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

• De mandaten voortkomend uit de verwerkersovereenkomst zijn door de Onderwijsorganisatie geregistreerd bij één Ondersteunende rol Registerhouder met de referentiecomponent Mandatenregister.

• De door de Onderwijsinstelling gekozen Registerhouder beschikt over de referentiecomponent Mandatenregister en voldoet aan de van toepassing zijnde functionele, technische en operationele afspraken zoals beschreven in Verlenen van mandaten [4] en Activeren en deactiveren van een gegevensuitwisseling [5].

• Mandaten worden in dit Mandatenregister gespecificeerd op het niveau van Onderwijsbestuur en Leverancier. De Leverancier is Verwerker van het Verwerkersverantwoordelijke Onderwijsbestuur.

• Verzender en Ontvanger zijn met de referentiecomponent Consentmanagement aangesloten op het Mandatenregister van de door de Onderwijsorganisatie gekozen Registerhouder

• Verzender en Ontvanger beschikken over de referentiecomponent Consentmanagement en voldoen aan de voor hen geldende functionele, technische en operationele afspraken zoals beschreven in Verlenen van mandaten [4].

• De Onderwijsorganisatie heeft de gegevensuitwisseling vanuit het Mandatenregister naar de referentiecomponent Consentmanagement van de Verzender of Ontvanger geactiveerd. Op deze wijze kan bijvoorbeeld:

  • Verzender (of Ontvanger) controleren of een nieuwe Ontvanger (Verzender) een geldig mandaat heeft gekregen vanuit het Onderwijsbestuur van de Onderwijsorganisatie.

  • Bij het intrekken van een mandaat door Onderwijsbestuur de Verzender en Ontvanger op de hoogte worden gesteld en alle gegevensuitwisselingen worden gedeactiveerd.

  • Verzender (of Ontvanger) periodiek controleren of een mandaat voor Ontvanger (of Verzender) nog actief is.

• Verzender en Ontvanger controleren minimaal dagelijks of zijzelf en de wederpartij nog beschikken over een geldig mandaat.

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

  • Verzender en Ontvanger sturen minimaal 60 dagen, 30 dagen, 14 dagen en 3 dagen voordat een mandaat verloopt een melding naar de Applicatiebeheerder(s).

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

  • Onderwijsbestuur is verantwoordelijk voor een overgangssituatie van minimaal 30 dagen waarin zowel de mandaten vanuit de nieuwe Onderwijsorganisatie en de oude Onderwijsorganisatie actief zijn.

  • Verzender en Ontvanger zijn verantwoordelijk voor het actualiseren van de mandaten binnen de overgangssituatie zodat gegevensuitwisselingen die geactiveerd zijn blijven werken.

• Indien een Onderwijsorganisatie de intentie heeft om een mandaat in te trekken, en als gevolg hiervan alle gegevensuitwisselingen te deactiveren dan trekt het Onderwijsbestuur het mandaat voor een Leverancier in. Verzender en Ontvanger alle geactiveerde gegevensuitwisselingen voor de onderliggende Onderwijsaanbieders.

Applicatiebeheerders van de Onderwijsorganisatie zijn na registratie van het mandaat in staat om een gegevensuitwisseling te activeren en deactiveren.

Release notes