Versions Compared

Key

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

...

Iedere gegevensuitwisseling dient plaats te vinden via een beveiligde connectie . Deze connectie vindt plaats door een aantal stappen:

  1. Identificeren en authenticeren van Verzender of Ontvanger.

  2. Autoriseren van Verzender of Ontvanger.

  3. De uitwisseling vindt plaats via een beveiligde communicatielijn.

  4. De uitwisseling is gebaseerd op een modern protocol.

en vanuit systemen die voldoen aan de eisen voor informatiebeveiliging. Edu-V benut op dit vlak de door Bureau Edustandaard ontwikkelde en beheerde technische afspraken van 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.

  • Identificatie en authenticatie vindt plaats via het in ontwikkeling zijnde OAuth profiel van Edukoppeling met de volgende additionele afspraken:

    • Edukoppeling schrijft het gebruik van PKI Overheidscertificaten voor. Als alternatief is het ook mogelijk om een client certificaat uitgegeven door de Verzender te hanteren.

    • Edukoppeling heeft expliciete afspraken over routering op basis van het from-to principe bij iedere gegevensuitwisseling. Zo kan een Leverancier achter de voordeur een verzoek achter de voordeur routeren voor en naar de correcte onderwijsinstelling. Binnen Edu-V werken we niet met dit principe.

    • Bij het aanvragen van een Token hanteren we twee additionele afspraken:

      • Het is mogelijk om een Token aan te vragen voor een specifieke scope.

      • Het is mogelijk om een Token aan te vragen voor een specifieke School, zodat communicatie plaats kan vinden in een veilige context. Binnen deze veilige context kunnen vervolgens persoonsgegevens uitgewisseld worden. Voor het uitwisselen van deze gegevens zijn de lagen Mandaat en Activering ook van toepassing.

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

  1. Op welke wijze identificeren en authenticeren we een Verzender of Ontvanger?
    Voorstel: Hanteren van in ontwikkeling zijnde OAuth profiel van Edukoppeling. Dit profiel is gebaseerd op het OAuth Client Credentials protocol.
    Overweging: Edukoppeling Identificatie en Authenticatie heeft expliciete afspraken over het hanteren van PKI-overheidscertificaten voor het identificeren van een Partij. Is dit noodzakelijk of volstaat een geldig TLS-certificaat?

  2. Op welke wijze autoriseren we een Verzender of Ontvanger (de Leverancier die een API bevraagt)?
    Voorstel: Autorisatie voor de gegevenssoorten en de bilaterale overeenkomst tussen Leveranciers gebeurt op basis van de beide aansluiting overeengekomen API en scopes. De Verzender of Ontvanger vraagt een Token aan met een specifieke scope.
    Voorstel: Voor gegevenssoorten waarbij een mandaat van een Onderwijsinstelling verplicht is wordt periodiek door de Leveranciers gecontroleerd of de andere Leverancier beschikt over dit mandaat. Als alternatief kan dit ook bij iedere aanvraag van een Token, maar dit is mogelijk overkill.
    Voorstel: In aanvulling op het mandaat dient een Onderwijsinstelling een uitwisseling van een gegevensoort van een school te activeren. Dit betekent dat bij het benaderen van een endpoint gecontroleerd wordt of de gegevensuitwisseling voor de betreffende school geactiveerd is. Een Verzender of Ontvanger vraagt in het geval van een dergelijke uitwisseling een Token aan voor de School.
    Overweging: Edukoppeling Identificatie en Authenticatie heeft expliciete afspraken over routering op basis van het from-to principe bij iedere gegevensuitwisseling. Zo kan een Leverancier achter de voordeur een verzoek achter de voordeur routeren voor en naar de correcte onderwijsinstelling. Dit is een implementatiekeuze voor mandaten. Nemen we deze over?

  3. Op welke wijze beveiligen we de communicatielijn?
    Voorstel: Hanteren van Uniforme Beveiliging Voorschriften (UBV) voor M2M gegevensuitwisselingen. Het betreft dan zowel de Headers als TLS afspraken.

  4. Welke standaard hanteren we voor het protocol?
    Voorstel: Hanteren van REST/SAAS profiel zoals beschreven in Edukoppling, rekening houdend met de overwegingen zoals geformuleerd op deze pagina.

Laag 4. Mandaat –

...

Deelnemer is gemandateerd als Verwerker

De gegevens die uitgewisseld worden zijn van de Onderwijsinstelling of van de LeverancierDeelnemer. 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 een Onderwijsinstelling. Een uitwisseling van deze gegevenssoorten kan alleen plaats vinden nadat de Onderwijsinstelling de Leverancier heeft gemandateerd. Hiertoe heeft de Onderwijsinstelling een verwerkersovereenkomst getekend met de Leverancier.

...

. Voor het uitwisselen van gegevens van de Deelnemer, zoals bijvoorbeeld catalogusinformatie, is dit mandaat niet noodzakelijk.

Indien er gegevens worden uitgewisseld waar een Onderwijsinstelling 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 het Onderwijsbestuur geregistreerd bij één Ondersteunende rol Registerhouder in de referentiecomponent Mandatenregister.

  • Mandaten worden in dit Mandatenregister gespecificeerd op het niveau van:

    • School: daar waar een onderwijsdeelnemer is ingeschreven en waar het onderwijs wordt uitgevoerd.

    • Leverancier: deze Leverancier is Verwerker van het Verwerkersverantwoordelijke Onderwijsbestuur voor de gespecificeerde Scholen.

Info

Een mandaat is een overeenkomst tussen een Onderwijsinstelling (Bevoegd Gezag) Onderwijsbestuur en een Leverancier. Dit staat niet gelijk aan een instemming op de activatie van een uitwisseling van een specifieke gegevenssoort voor een School (zie laag 5).

Dit betekent dat afspraken gemaakt worden over:

  1. De verantwoordelijke voor de registratie van mandaten.

  2. De wijze waarop mandaten worden gecontroleerd.

  3. De locatie waar mandaten worden geregistreerd.

  4. De eisen aan het register van de mandaten.

...

Wie is verantwoordelijk voor het registreren van mandaten?
Overweging: De Onderwijsinstelling is Verwerkersverantwoordelijke.
Overweging: De praktijk leert dat Verwerkersovereenkomsten onvoldoende worden ingevuld ook na actief versturen van Leveranciers.
Voorstel: De Onderwijsinstelling is verantwoordelijk voor het registreren van mandaten.

...

Op welke wijze worden mandaten gecontroleerd?
Overweging: Een Leverancier die gemandateerd is door een Onderwijsinstelling heeft een verantwoordelijkheid om te controleren of een andere Leverancier ook gemandateerd is voor de Onderwijsinstelling.
Voorstel: Leveranciers controleren periodiek of aangesloten andere Leveranciers nog een actief mandaat hebben van een Onderwijsinstelling. Indien dit niet het geval is dan worden alle uitwisselingen van gegevenssoorten voor de scholen die vallen onder de Onderwijsinstelling gedeactiveerd.

...

Waar worden mandaten geregistreerd?
Overweging: Aangezien de Onderwijsinstelling verantwoordelijk is voor de registratie, is er een voorkeur voor één systeem voor een school.
Overweging: Scholen maken reeds gebruik van OSR voor het mandateren van gegevensuitwisselingen tussen LAS en DUO.
Voorstel: Advies om het OSR te hanteren voor het registreren van mandaten. Leveranciers kunnen bij het OSR, indien ze gemandateerd zijn voor een Onderwijsinstelling, opvragen of een andere Leverancier ook gemandateerd is voor de desbetreffende Onderwijsinstelling.
Overweging: Schrijven we OSR voor? Of is het beter om hier expliciet de rol van Mandatenregister voor uit te werken. Het OSR, maar ook andere Leveranciers, kunnen vervolgens deze rol gaan vervullen?

...

In het mandaat hoeft hierdoor ook niet vastgelegd te worden welke gegevenssoorten er uitgewisseld gaan worden.

  • Zijn dit voldoende niveaus?
    Overweging: dienen hier ook Producten gespecificeerd te zijn?

  • Verzender en Ontvanger zijn aangesloten op dit Mandatenregister van de door de Onderwijsinstelling gekozen Registerhouder.

  • Het Onderwijsbestuur heeft de gegevensuitwisseling vanuit dit Mandatenregister naar het 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.

    • 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 de wederpartij nog beschikt over een geldig mandaat.

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

  • 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 en /wiki/spaces/AFSPRAKENS/pages/9175055.

Laag 5. Activering – Uitwisseling van gegevenssoort voor school

...