Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 39 Next »

Titel

M2M gegevensuitwisselingen

Status

DRAFT VOORBEREIDING CONCEPT EINDREDACTIE DEFINITIEF

Versie

0.0.4

Datum

15 April 2023

Acties

  • [1] Overleg met werkgroep Edukoppeling over OAuth profiel en REST profiel ten aanzien van:

    • M2M identificatie en authenticatie voor gegevensuitwisseling met privacygevoelige informatie

    • M2M identificatie en authenticatie voor gegevensuitwisseling zonder privacygevoelige informatie

    • M2M identificatie en authenticatie op basis van OAuth zonder mTLS

    • Afwegen van alternatieve oplossing voor routering (bijvoorbeeld via token, header of in bericht)

  • [2] M2M identificatie en authenticatie uitwerken

  • [3] Technische infrastructuur voor gegevenstransacties functioneel, technisch en operationeel uitwerken

  • [4] Verlenen van mandaten functioneel, technisch en operationeel uitwerken

  • [5] Activeren en deactiveren van gegevensuitwisseling functioneel, technisch en operationeel uitwerken

Voorstellen tot besluit voor werkconferentie 18 april:

  • Leveranciers registreren zich als Deelnemer van Edu-V. Onderwijsinstellingen met een eigen softwarehuis zijn ook een soort van ‘eigen’ leveranciers. Dit is aangepast in de registratiestap.

  • Alle niveaus zijn nader uitgewerkt in operationele afspraken en met verwijzigingen naar bestaande standaarden.

  • In de uitwerking is uitgegaan van één Mandatenregister per Onderwijsbestuur. In de praktijk kan dit ertoe leiden dat er één centraal Mandatenregister komt, maar dit schrijven we niet voor. Dit is conform de ontwerpprincipes:

    • 2.3: Rollen in het Ecosysteem kunnen door meerdere Leveranciers ingevuld worden

    • 2.4: Leveranciers kunnen meerdere rollen vervullen

    • 2.5: Onderwijsinstellingen hebben keuzevrijheid in de invulling van rollen door Leveranciers

  • M2M gegevensuitwisselingen in huidige vorm publiceren met status CONCEPT.

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 Onderwijsinstellingen en het activeren van een uitwisseling van een gegevenssoort voor een School. In het Edu-V afsprakenstelsel is deze beveiliging 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). Deze uitwisseling wordt gedaan via een veilige connectie (v).

DV <-v-> DO

4. Mandaat

Een Onderwijsinstelling (O) mandateert een Deelnemer voor het verwerken van gegevens. De Deelnemer wordt Deelnemer met Mandaat (DM) voor de desbetreffende Onderwijsinstelling.

D → DM voor O

5. Activering

Een Administrator van een School activeert de uitwisseling van een gegevenssoort tussen een Verzender met Mandaat (DMV) en Ontvanger met Mandaat (DMO) voor een specifieke School (s) binnen een Onderwijsinstelling (O)

DMVs <-v-> DMOs voor s binnen O

Indien Onderwijsinstellingen in-house applicaties hebben ontwikkeld dan kunnen ze als zijnde ‘eigen’ Leverancier deelnemen aan het Ecosysteem. Ze vervullen dan net als alle andere Leveranciers een Business of Ondersteunende rol en kunnen voor de desbetreffende rol deelnemer worden.

Een voorbeeld is bijvoorbeeld een MBO-instelling die de rol van Dashboardaanbieder gaat vervullen en voortgangsgegevens en toetsresultaten combineert in een eigen ontwikkeld Dashboard.

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:

  • Een unieke identifier zijnde het OIN gebaseerd op het KvK-nummer.

  • Een geldige registratie bij Edu-V. De volgende informatie is tenminste bij Edu-V bekend:

    • Business of Ondersteunende rollen, referentiecomponenten en koppelvlakken

    • Endpoints

    • Contactgegevens

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

De registratie van Leveranciers wordt in een later stadium nader uitgewerkt als onderdeel van de afspraken over Beheersing. In een volgende versie zal dit hoofdstuk naar deze expliciete afspraken verwijzen.

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 beperkt tot de Business rollen, referentiecomponenten en koppelvlakken die beide Deelnemers ondersteunen.

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

Voorbeeld

Als Leermiddelenshop is het mogelijk om adresgegevens van Onderwijsdeelnemers te ontvangen van de Administratiesysteemaanbieder indien de Leermiddelenshop beschikt over de referentiecomponent ‘Distributiefaciliteit voor levering van fysieke leermiddelen’. Zo kan een Leermiddelenshop in de fijndistributie Leermiddelen op thuisadres laten bezorgen.

Andere Business en Ondersteunende rollen hebben binnen het Ecosysteem niet de beschikking over de adresgegevens van Onderwijsdeelnemers.

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

    • Acceptatieomgeving (endpoints voor testdoeleinden)

    • Productieomgeving (endpoints)

    • Technische documentatie

    • Client credentials en/of certificaten 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.

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 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 [1].

  • De koppelvlakken zijn in staat om de Patronen voor M2M gegevensuitwisselingen te ondersteunen.

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

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

Laag 4. Mandaat – Deelnemer is gemandateerd als Verwerker

De gegevens die uitgewisseld worden zijn van de Onderwijsinstelling of van de Deelnemer. 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. 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 met de referentiecomponent Mandatenregister.

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

Een mandaat is een overeenkomst tussen een 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). In het mandaat hoeft hierdoor ook niet vastgelegd te worden welke gegevenssoorten er uitgewisseld gaan worden.

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

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

Laag 5. Activering – Uitwisseling van gegevenssoort voor school

De Leveranciers die optreden als Verzender en Ontvanger zijn beide reeds gemandateerd door het Onderwijsbestuur om gegevens uit te wisselen (zie laag 4). 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 Onderwijsaanbieder 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 onderwijsdeelnemers of gebruiksgegevens)

    • Onderwijsaanbieder binnen het Onderwijsbestuur

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

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


Status en totstandkoming

Deze uitwerking is gebaseerd op basis van de volgende stappen:

  1. Documentstudie van Edukoppeling en SEM Ecosysteem.

  2. Voorbereidende bijeenkomst voor de Architectenraad van RdB en KV.

  3. Uitwerking in een concept inclusief voorstellen tot besluit.

  4. Verwerking van feedback vanuit Architectenraad naar een nieuwe iteratie met expliciete operationele afspraken op de vijf niveaus.

  • No labels