Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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 gegevenssoort informatieobject voor een Onderwijsaanbieder heeft geactiveerd.

...

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 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 gegevenssoort 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 gegevenssoorteninformatieobjecten. We onderscheiden hierbij vier classificaties.

Table of Contents
minLevel3
maxLevel3
outlinefalse
typelist
printablefalse

Classificatie van

...

informatieobjecten: I, II, III en IV.

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

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

  • Regie op gegevensuitwisseling: de regie over het uitwisselen van gegevenssoorten informatieobjecten kan liggen bij een onderwijsorganisatie of een leverancier. Hieraan is sterk gerelateerd wie zeggenschap en/of (verwerkers)verantwoordelijk van de gegevens is.

  • Verwerkersovereenkomst: gegevenssoorten 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 gegevenssoorteninformatieobjecten. 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 Gegevenssoorten, Verzender en Ontvangers Informatieobjecten is voor alle gegevenssoorten informatieobjecten in het Ecosysteem afsprakenstelsel de classificatie bepaald conform bovenstaande richtlijn.

...

Een Deelnemer kan met een andere Deelnemer koppelen vanuit één of meerdere van deze referentiecomponenten. Bij het koppelen worden afspraken gemaakt welke gegevensdiensten en gegevenssoorten informatieobjecten (scopes) er tussen de referentiecomponenten uitgewisseld worden.

...

  • Deelnemers bepalen welke gegevensdiensten en gegevenssoorten informatieobjecten (scopes) er onderling uitgewisseld gaan worden.

    • De mogelijkheden voor de gegevenssoorten informatieobjecten zijn afhankelijk van de door de Deelnemers gekozen en geïmplementeerde referentiecomponenten en gegevensdiensten.

...

Info

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

...

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

Laag 3. Uitwisseling – Iedere

...

gegevensdienst is veilig

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

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

...

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 gegevenssoort gegevensdienst te activeren of deactiveren.

Om gegevens 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 gegevensuitwisseling gegevensdienst tussen Verzender en Ontvanger of Bron en Afnemer voor een specifieke:

    • Gegevenssoort Gegevensdienst (bijvoorbeeld de gegevenssoort onderwijsdeelnemers, aanspraken of leermiddelgebruik).

    • Onderwijsaanbieder binnen het Onderwijsbestuur

    • En optioneel een subset van informatieobjecten

  • De Applicatiebeheerder activeert de gegevensuitwisseling gegevensdienst bij de Bron of Verzender van de gegevenssoortinformatieobjecten. 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 gegevenssoort gegevensdienst identificeert en authentiseert de Applicatiebeheerder met een beveiligingsvniveau 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 gegevenssoort 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 gegevens van informatieobjecten in de gegevenssoort gegevensdienst van de Onderwijsaanbieder controleren Bron en Afnemer of Verzender en Ontvanger of de gegevensuitwisseling geactiveerd is.

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

Laag 5. Verwerker – Deelnemer heeft toestemming als Verwerker

Gegevens Persoonsgegevens die vallen onder de verwerkersverantwoordelijkheid van een Onderwijsbestuur kunnen alleen uitgewisseld worden door Leveranciers die hiertoe toestemming hebben gekregen door het Onderwijsbestuur.

Info

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

...

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:

  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.

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

...