Versions Compared

Version Old Version 18 New Version Current
Changes made by

Casper van der Harst

Casper van der Harst

Saved on

Key

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

...

Expand
titleToelichting

Op deze laag worden de infrastructurele rollen (Nodes) op het MedMij-netwerk bepaald en voorzien van verantwoordelijkheden op het gebied van versleuteling, authenticatie van Nodes en autorisatie van Nodes. Met dat laatste wordt bedoeld dat er steeds opnieuw moet worden vastgesteld dat een Node gerechtigd is zich te bewegen op het MedMij-netwerk. Voor versleuteling en authenticatie worden PKI-certificaten gebruikt.

Autorisatie zou op grofweg twee manieren in het MedMij Afsprakenstelsel kunnen worden opgenomen:

  • via diezelfde PKI-certificaten, waarin aan de domeinnaam van de houder van het certificaat gezien kan worden of het om een MedMij Node gaat, door daarvan te eisen dat die domeinnaam de vorm <dienstverlener>.medmij.nl heeft;
  • via een door MedMij-zelf beheerde lijst van geautoriseerde MedMij Nodes (een whitelist).

De voordelen van de eerste optie zouden zijn dat:

  • er zo maximaal gebruik wordt gemaakt van afspraken die ook voor andere doeleinden al nodig zijn, namelijk het gebruik van PKI-certificaten;
  • zo de mate van operationele centrale betrokkenheid van de Stichting MedMij wordt geminimaliseerd, en dus de kosten en risico's daarvan. In de tweede optie zou Stichting MedMij zelf een lijst moeten gaan beheren en ontsluiten naar alle servers om het operationele verkeer mogelijk te maken. In de eerste optie is alleen een name service nodig voor de medmij.nl-domeinnamen. Dat laatste is een goed gestandaardiseerde, goed begrepen en goed uit te besteden service, die lagere kosten, lagere risico's en minder afhankelijkheid voor de deelnemers met zich mee zal brengen;
  • MedMij zich zo maximaal houdt aan haar architectuurprincipe P6: MedMij spreekt alleen af wat nodig is.

Toch is voor de tweede optie gekozen, omdat de voor de eerste optie benodigde controle over de hostnames en de certificaten alleen met ongewenste bijeffecten gepaard zou gaan. De volgende opties zijn daarbij verkend:

  • De MedMij-beheerorganisatie wordt Registration Authority (RA) in PKIoverheid, jegens alle betrokken Certificate Authorities (CA's). PKIoverheid kent echter die mogelijkheid niet.
  • De MedMij-beheerorganisatie geeft een domeinverklaring af, zodat deelnemers zelf een subdomein onder .medmij.nl kunnen aanvragen bij een CA. Daarmee heeft de beheerorganisatie wel invloed op de uitgifte van een certificaat, maar laten intrekken is niet mogelijk, tenzij er sprake is van misbruik. Er is immers geen juridische relatie tussen de eigenaar van het domein (de beheerorganisatie) en de CA.
  • Analoog aan de wijze waarop door sommigen beroepsgebonden certificaten worden uitgegeven, is een maatwerk-certificeringsdienst denkbaar. In de voorwaarden van het product (geldend vanaf de aanvraag van het certificaat) wordt dan expliciet geregeld dat wanneer de inschrijving in een extern register wegvalt, het certificaat door de CA wordt ingetrokken. Dat vereist dat de registerhouder (beheerorganisatie) wijzigingen doorgeeft aan alle CA's. Dit is economisch pas interessant bij een aanzienlijke hoeveelheid certificaathouders, waarvan in MedMij voorlopig geen sprake zal zijn.
  • MedMij zou een eigen PKI-omgeving kunnen inrichten. Dit is niet verder verkend, vanwege de complexiteit en verantwoordelijkheid die op de schouders van de beheerorganisatie zou rusten.
  • De Stichting MedMij zou zelf houder kunnen zijn van alle certificaten, waarbij deelnemers gemandateerd worden voor beheerstaken rond hun eigen subset van certificaten. De Stichting kan certificaten intrekken. Identificatie van de dienstverlener naar de gebruiker is niet mogelijk, want de certificaten staan op naam van Stichting MedMij.
  • Er zou een custom field gebruikt kunnen worden in certificaten. De MedMij Beheerorganisatie zou de controle kunnen krijgen over de wijze waarop met dit veld wordt omgegaan. Dit vereist waarschijnlijk afspraken met alle CA's. Dit geeft controle op het uitgeven van certificaten, maar geeft de beheerorganisatie geen mogelijkheden het certificaat te laten intrekken.

De Nodes op Netwerk-niveau worden geïdentificeerd met een hostname. Omdat dus ook elke PGO Node en ZA Node bij één Dienstverlener hoort, is aan de hostname de Dienstverlener te herkennen.

In het persoonsdomein geldt zo dat:

  • één Dienstverlener Persoon één of meerdere Uitgevers verzorgt en elke Uitgever verzorgd wordt door één Dienstverlener Persoon;
  • één Uitgever door één of meerdere PGO Servers wordt gerealiseerd en elke PGO Server één Uitgever realiseert;
  • één PGO Server door één of meerdere PGO Nodes wordt ondersteund en elke PGO Node één PGO Server ondersteunt.

Zo kan dus ook in de OAuth Clientlist de hostname van een PGO Node geassocieerd worden met één (gebruikersvriendelijke naam van de) PGO Server .

In het zorgaanbiedersdomein geldt zo dat:

  • één Dienstverlener Zorgaanbieder één of meerdere Bronnen en/of Lezers verzorgt en elke Bron en/of Lezer verzorgd wordt door één Dienstverlener Zorgaanbieder;
  • één Bron en/of Lezer door één of meer combinaties van één Authorization Server en één Resource Server  wordt gerealiseerd en elke combinatie van één Authorization Server en één Resource Server één Bron en/of Lezer realiseert;
  • één Authorization Server, net als één Resource Server, door één of meerdere ZA Nodes wordt ondersteund;
  • elke ZA Node hetzij één  Authorization Server  ondersteunt, hetzij één Resource Server , hetzij de combinatie van één Authorization Server en één Resource Server ondersteunt;
  • elke ZA Node één of meerdere endpoints kent en elk endpoint hoort bij één ZA Node, zodanig dat de hostname in een endpoint-adres de hostname van die ZA Node is.

...

1.
In het MedMij-netwerk functioneert:
  • elke PGO Server, met inbegrip van zijn OAuth-rol, op één of meerdere PGO Nodes. Voor al diens frontchannel-verkeer gebruikt elke PGO Server één PGO Node, en wel met een hostname die voor die PGO Server voorkomt op de OAuth Client List.
  • elke Authorization Server, met inbegrip van zijn OAuth-rol, op één of meer ZA Nodes;
  • elke Subscription Server, met inbegrip van zijn OAuth-rol, op één of meer ZA Nodes;
  • elke Notification Client op één of meer ZA Nodes;
  • elke Notification Server op één of meer PGO Nodes;
  • elke Resource Server, met inbegrip van zijn OAuth-rol, op één of meer ZA Nodes;
  • precies één MedMij Stelselnode, waarop MedMij Registratie functioneert.
Expand
titleToelichting

Voor de algemene uitgangspunten inzake de getalsverhoudingen tussen de rollen, zie de pagina Architectuur en technische specificaties.

Het is toegestaan om een Authorization Server en een Resource Server te verdelen over verschillende ZA Nodes, maar ook te combineren op dezelfde. De afsprakenset staat het zelfs toe dat Authorization Server en Resource Server elk apart op meerdere ZA Nodes worden geprojecteerd. Het kan dan voorkomen dat, bij de betreffende ZorgaanbiederGegevensdiensten in de Zorgaanbiederslijst, hostnames in de endpointadressen staan die verschillen tussen het authorization endpoint, het token endpoint en het resource endpoint, zelfs bij eenzelfde Interfaceversie. Een belangrijke eis blijft evenwel dat al deze hostnames bij ZA Nodes van eenzelfde Dienstverlener Zorgaanbieder horen. De hele flow behorend bij een zekere ZorgaanbiederGegevensdienst moet namelijk onder de eindverantwoordelijkheid van één zo'n Dienstverlener vallen, namelijk van de Dienstverlener die die ZorgaanbiederGegevensdienst ontsluit. Zo blijft die integrale eindverantwoordelijk­heid ook op net­werk-niveau toetsbaar. Zie de drie (ingewikkelde) invarianten bij Zorgaanbie­derGegevensdienst van het soort “niet-lokale afhankelijkheid”.

De uitzondering daarop inzake het frontchannel-verkeer is noodzakelijk om de OAuth Client List te laten functioneren. Het is dus mogelijk voor een PGO Server om verschillende certificaten te hanteren voor frontchannel- en backchannel-verkeer, zolang op de OAuth Client List maar de hostname in het certificaat voor frontchannelverkeer voorkomt die tevens voorkomt in de redirect URI inzake OAuth.

Er is precies één MedMij Stelselnode in het MedMij-netwerk. Zonder die MedMij Stelselnode is er geen MedMij-netwerk.

In lijn met keuzes op deProces- en Informatielaag, treden in het zorgaanbiedersdomein alleen de ZA Nodes op in het MedMij-netwerk. Dat wil zeggen dat bijvoorbeeld achterliggende xIS'en niet over het MedMij-netwerk communiceren met de ZA Node. Dat verkeer is verborgen achter de ZA Node. Alle daarvoor benodigde routering wordt afgehandeld door de server-implementaties en speelt zich buiten het zicht van het MedMij Afsprakenstelsel af.


2.
Op één:
  • PGO Node functioneert hetzij één PGO Server, hetzij één Notification Server, hetzij de combinatie van één PGO Server en één Notification Server.
  • ZA Node functioneert hetzij één Authorization Server, hetzij één Resource Server, hetzij één Subscription Server, hetzij één Notification Client, hetzij een combinatie van voorgaande rollen.
Expand
titleToelichting
Voor de algemene uitgangspunten inzake de getalsverhoudingen tussen de rollen, zie de pagina Architectuur en technische specificaties.


3.Een of meerdere PKIoverheid Trust Service Providers treden op als Trust Server Provider voor de uitgifte van certificaten die bij backchannel-verkeer gebruikt moeten worden.
4.Een of meerdere Trust Service Providers treden op als Trust Server Provider voor de uitgifte van certificaten die bij frontchannel-verkeer gebruikt moeten worden.

...

1a.Al het verkeer over het MedMij-netwerk is beveiligd met Transport Layer Security (TLS).
1b.

Er wordt gebruikgemaakt van TLS-versies en -algoritmen die zijn geclassificeerd als "goed" in de ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS), versie 2.1 van het NCSC. Indien meerdere TLS-versies als "goed" geclassificeerd zijn, moet minimaal de laagste TLS-versie worden ondersteund. Hogere TLS-versies mogen worden aangeboden.

1c.Van verantwoordelijkheid 1b kan in het MedMij Afsprakenstelsel worden afgeweken, indien dit expliciet benoemd wordt in nadere eisen binnen de afsprakenset.
1d.

Gebruik van TLS False Start is verboden.

Expand
titleToelichting

Gebruik van TLS False Start is verboden om te voorkomen dat er inhoudelijke verwerking plaatsvindt van uitgewisselde gegevens voordat voor de betreffende uitwisseling authenticatie en autorisatie geslaagd zijn (zie onder).


1e.Bij de TLS-handshake moet de hoogste toegestane TLS-versie gekozen worden die beide partijen ondersteunen.
1f.

Als invulling van 1c geldt, in afwijking van 1b:

  • TLS 1.2 moet door elke deelnemer ondersteund worden.
  • TLS 1.3 moet door elke deelnemer ondersteund worden, indien redelijkerwijs mogelijk.
Note
titleTLS 1.2

TLS 1.3 wordt in de ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS), versie 2.1 van het NCSC als enige met "goed" geclassificeerd. Daarmee is dit de enige TLS-versie die volgens eis 1b ondersteund mag worden. Bij deze release van dit afsprakenstelsel kan TLS 1.3 niet door alle deelnemers ondersteund worden, omdat dit niet wordt aangeboden in door sommigen gebruikte componenten. Daarom maken we gebruik van de mogelijkheid die regel 1c biedt om een afwijkende regeling te treffen.

De afwijkende regeling bestaat eruit dat TLS 1.3 door iedere deelnemer aangeboden moet worden, indien redelijkerwijs mogelijk. Om redenen van interoperabiliteit moet iedere deelnemer TLS 1.2 blijven ondersteunen.

Het voornemen is deze afwijking te schrappen zodra TLS 1.3 breed ondersteund wordt, waardoor verantwoordelijkheid 1b weer onverkort geldt en TLS 1.3 de enige toegestane versie wordt. Dit kan al dan niet met behulp van een snel door te voeren patch op het MedMij Afsprakenstelsel.


2.

Voor authenticatie en autorisatie bij backchannel-verkeer op het MedMij-netwerk, kunnen elke PGO Node, elke ZA Node en de MedMij Stelselnode een PKIoverheid-certificaat overleggen, en wel een G1-certificaat van een PKIoverheid TSP.

  • Private Root CA (per medio 2020 de standaard voor m2m)
    • Stamcertificaat
      • Staat der Nederlanden Private Root CA - G1
    • Domein Private Services, maar alleen de volgende:
      • Staat der Nederlanden Private Services CA - G1
      • KPN PKIoverheid Private Services CA - G1
      • QuoVadis PKIoverheid Private Services CA - G1
      • Digidentity BV PKIoverheid Private Services CA - G1
Note

Partijen die op <DATUM> al 25-02-2022 Deelnemer van MedMij waren en gebruikmaken van een publiek certificaat voor de beveiliging van hun backchannel-verkeer, kunnen dit certificaat tot uiterlijk 4 december 2022 gebruiken. Hierna is het gebruik van een privaat (G1) certificaat van PKIoverheid ook voor deze deelnemers verplicht voor de beveiliging van al het backchannel-verkeer.

  • Stamcertificaat
    • Staat der Nederlanden EV Root CA
  • Intermediair Domein Server CA 2020
    • QuoVadis PKIoverheid Server CA 2020
    • Digidentity PKIoverheid Server CA 2020
    • KPN PKIoverheid Server CA 2020


3.

Voor authenticatie en autorisatie bij frontchannel-verkeer tussen productieomgevingen op het MedMij-netwerk, kunnen elke PGO Node, elke ZA Node en de MedMij Stelselnode een PKI-certificaat overleggen dat aan de volgende eisen voldoet:

  • De vereisten aan de certificaat leverancier voor PKI certificaten zijn:
    1. De meest up-to-date WebTrust audit is succesvol doorlopen en de certificering is geldig voor de ‘Certificatie Authority’ op iedere schakel in de keten van ondertekeningen tot en met de uitgifte processen.
  • De technische vereisten zijn:
    1. De ‘private key’ moet worden gegenereerd op het doelplatform waar het PKI certificaat wordt toegepast.
    2. Bij gebruik van publieke PKI certificaten is de toepassing van ‘Certification Authority Authorization Resource Record’ vereist.
    3. Het toepassen van DNSSEC op de gebruikte domeinen is vereist onder de voorwaarden van pas-toe-of-leg-uit. Strengere eisen kunnen worden gesteld vanuit aanvullende kaders, zoals aansluitvoorwaarden.
    4. Het gebruik van wildcard certificaten wordt niet toegestaan.
    5. Het gebruik van ‘multi-domain’-certificaten is toegestaan, onder de voorwaarde dat de eigenaar van het certificaat gelijk is aan de eigenaar van alle domeinen die opgenomen zijn in de Subject Alt Name DNS waarden van het certificaat.
  • Uitgifte:
    1. Het zekerheidsuitgifte niveau moet minimaal op het OV-niveau (Organisation Validated) of met hogere zekerheid zijn uitgegeven voor publieke PKI webserver certificaten wanneer persoonsgegevens van bijzondere aard worden verwerkt. Dit is relevant voor de aanschaf van het certificaat en dit valt achteraf te controleren op het bestaan van Policy Object Identifiers (OIDs) die markeren welk type certificaat het betreft.
    2. De uitgever van de PKI certificaten is verantwoordingsplichtig aan de AVG en/of GDPR.
  • Beheer:
    1. Veilig beheer moet zijn toegepast zoals toegelicht in ‘Factsheet Veilig beheer van digitale certificaten’.
Note

Partijen die op 25-02-2022 al Deelnemer van MedMij waren en gebruikmaken van een publiek certificaat voor de beveiliging van hun frontchannel-verkeer, kunnen dit certificaat tot uiterlijk 4 december 2022 gebruiken. Hierna is het gebruik van publiek certificaat dat voldoet aan de hierboven genoemde eisen verplicht.

  • Stamcertificaat
    • Staat der Nederlanden EV Root CA
  • Intermediair Domein Server CA 2020
    • QuoVadis PKIoverheid Server CA 2020
    • Digidentity PKIoverheid Server CA 2020
    • KPN PKIoverheid Server CA 2020


4.

Alle certificaathouders verbinden zich aan de op hen toepasselijke eisen van het PKI-stelsel. Een organisatie mag meerdere certificaten hebben.

Expand
titleToelichting

De keuze voor de PKI-standaard past bij principe P19 van het MedMij Afsprakenstelsel. Er bestaan andere manieren voor, en ideeën over, het borgen van vertrouwen in een netwerk van geautomatiseerde systemen, maar deze zijn nog lang niet zo bewezen als PKI, dat wereldwijd wordt ondersteund, en wereldwijd is beproefd, door overheden en marktspelers.

Bij gebruik van de PKI-standaard doet zich de vraag voor van welk(e) PKI-stelsel(s) gebruik gemaakt kan of moet worden. Zo'n PKI-stelsel voorziet in een hiërarchie van organisaties die certificaten uitgeven, zodanig dat de betrouwbaarheid van de certificaten van zo'n organisatie leunt op de betrouwbaarheid van de eerst-hogere organisatie in die hiërarchie, doordat de certificaten van de lagere-in-hiërarchie een handtekening hebben van die van de hogere-in-hiërarchie. Aan de top van zo'n hiërarchie staat een zogenoemde root Certificate Authority (root CA) die zijn betrouwbaarheid niet aan een hogere kan ontlenen, zijn eigen (stam)certificaten tekent, en zo een steunpilaar is van het vertrouwen in het hele betreffende PKI-stelsel.

Het MedMij Afsprakenstelsel had ervoor kunnen kiezen een PKI-stelsel specifiek voor MedMij in te richten, maar de kosten daarvan, voor zichzelf en voor haar deelnemers, wegen niet op tegen de voordelen, onder de voorwaarde dat er een ander geschikt PKI-stelsel voorhanden is. Deelnemers zullen met hun services immers ook in andere afsprakenstelsels betrokken kunnen zijn dan dat van MedMij. Zo'n keuze past bovendien niet bij principe P6.

Omdat het MedMij-netwerk een nationale en maatschappelijk kritische infrastructuur is, met hoge eisen aan betrouwbaarheid, kiest het MedMij Afsprakenstelsel voor het momenteel enige PKI-stelsel waarin de betrouwbaarheid uiteindelijk steunt op een Nederlandse publiekrechtelijke rechtspersoon: PKIoverheid met de Staat der Nederlanden als root CA. Zo is de governance van de root CA transparant en toegankelijk belegd.

Het MedMij Afsprakenstelsel bouwt ondermeer voor het door hem aan zijn deelnemers geboden vertrouwen dus mede op het PKIoverheid-stelsel, op het door dat stelsel vastgestelde programma van eisen voor de in dat stelsel betrokken TSP's en op de certificatiehiërarchie van PKIoverheid. Deelnemers in het MedMij Afsprakenstelsel zullen dus service-certificaten moeten betrekken bij een bij PKIoverheid aangesloten TSP die bij haar past.


...