Beschrijving

Binnen koppeltaal worden standaarden en technieken toegepast. Deze specifieke standaarden en technieken worden per topic omschreven. Dit topic is een uitzondering hierop, omdat dit topic de beveiligingsoverwegingen van koppeltaal bespreekt, en niet een of meerdere specifieke standaarden die worden toegepast rond een onderwerp. We kiezen ervoor dit als topic te bespreken om zo een overzicht van de aspecten te verzamelen.

Overwegingen

Binnen Koppeltaal gaat het om de interacties tussen applicaties t.b.v. het realiseren van hybride zorg van een zorgverlener aan een cliënt. Hierbij worden vaak persoons- en/of medische gegevens worden uitgewisseld. Deze gegevens zijn vertrouwelijk en dienen onder de hoogste bescherming te staan.

Toegang wordt op applicatieniveau bepaald

In koppeltaal worden FHIR resources uitgewisseld via een FHIR resource service. Wie daar wat mag wordt door de authorisatieservice bepaald. In Koppeltaal wordt bewust de keuze gemaakt dat applicaties en niet personen toegang krijgen tot de FHIR resources in de FHIR resource service. Dit heeft te maken met de huidige status quo: de applicaties die we koppelen hebben reeds een toegangsmodel. Daar een ander toegangsmodel aan toevoegen brengt onnodige complexiteit. Als gevolg van deze beslissing is het dus van belang te stellen dat de verantwoordelijkheid voor wat de gebruiker mag doen en mag inzien bij de applicaties in het domein ligt, en niet bij de autorisatie service of de FHIR resource service. Om toch een beperking te stellen aan de applicaties, wordt met de autorisatieregels de applicaties beperkt in hun acties op de FHIR resource service.

Toepassing en restricties

HTTPS

• REST diensten/services mogen alleen hun diensten via een HTTPS-enpoint aanbieden.

  • Dit beschermt het transport van authenticatie gegevens, zoals de JSON Web Tokens.

  • Het stelt cliënten (dienst afnemers) ook in staat om de dienst te authenticeren en de integriteit van het bericht te waarborgen.

Geheimhouding private sleutels - publicatie publieke sleutels

De applicaties gebruiken een publiek - privaat sleutelpaar om bij koppeltaal te identificereren. Het publieke deel wordt gedeeld om zo verificatie mogelijk te maken, het private deel dient in hoge mate afgezonderd te worden.

• Koppeltaal geeft er de sterke voorkeur aan JWKS in te zetten om de publieke sleutels te delen. Dit maakt het mogelijk meerdere sleutelparen actief te hebben, en gemakkelijk nieuwe sleutels te publiceren en sleutels uit te faseren.

• De geheimhouding van private sleutels is van uiterste noodzaak, het wordt dat ook de (applicatie) leveranciers vereist om hier op alle vlakken rekening mee te houden. Door JWKS toe te passen wordt het leveranciers mogelijke gemaakt meerdere sleutels in gebruik te hebben, ze makkelijk in gebruik te nemen en gemakkelijk weer uit te faseren. Zo hoeven sleutels zo min mogelijk over de infrastructuur gedeeld te worden.

• Om domain highjacking lastig te maken adviseren we het JWKS endpoint niet op een veel voorkomende URL te plaatsen.

Access Control (toegangscontrole)

• Om de koppelingen tussen de diensten te minimaliseren, moet de besluitvorming over de toegang tot de diensten, lokaal worden genomen via (voorgedefinieerde) REST-endpoints

• Gebruikers authenticatie moet worden gecentraliseerd bij een Identiteit Provider (IdP), die authenticatie tokens uitgeeft. Geldt alleen bij de SMART on FHIR App Launch

• Systeem authenticatie moet bij een Autorisatie Server worden gecentraliseerd.

Bewaartermijnen en gegevenslifecycle

Koppeltaal hanteert gescheiden bewaartermijnen voor persoonsgegevens en logging (opslagbeperking, AVG art. 5 lid 1 onder e; NEN 7513):

• Persoonsgegevens (PII) worden maximaal 2 jaar bewaard, gerekend vanaf de laatste betrokkenheid van de patiënt. De gecontroleerde verwijdering (aankondiging per applicatie, grace period, noodrem en definitieve erase) is beschreven in TOP-KT-028 - Opschoning patiëntgegevens.

• AuditEvents (NEN 7513-logging) worden minimaal 5 jaar bewaard en zijn uitgezonderd van de verwijdering. Dit conflicteert niet met de PII-termijn: de bewaring van het audit-log steunt op de wettelijke logging-verplichting (NEN 7513; AVG art. 17 lid 3 sub b); zie "Logging en persoonsgegevens".

• De definitieve verwijdering is een harde erase: alle versies worden gewist en een latere GET geeft 404. Het destroy-AuditEvent vormt het blijvende, aantoonbare bewijs van de vernietiging (verantwoordingsplicht, AVG art. 5 lid 2).

Het ECD blijft als dossierhouder verantwoordelijk voor de eigen (WGBO-)bewaarplicht en voor het tijdig veiligstellen van data; de Koppeltaalvoorziening is verwerker en initieert en faciliteert de opschoning.

Aandachtspunt: domein-transparantie. De opschoon-flow is domein-breed leesbaar: elke deelnemende applicatie binnen het DPA-domein kan zien welke patiënten (pseudonieme referenties, coded data, geen demografie) voor verwijdering zijn aangekondigd en welke statusovergangen plaatsvinden. Dit is een bewuste ontwerpkeuze van TOP-KT-028 - Opschoning patiëntgegevens (voorlopig besloten, 19 aug 2026); de privacy-toets op deze domein-transparantie is randvoorwaardelijk voor ingebruikname, en footprint-versmalling (de flow alleen zichtbaar voor applicaties die de patiënt daadwerkelijk kennen, vgl. AVG art. 19) blijft als mogelijke doorontwikkeling genoteerd.

Logging en persoonsgegevens

AuditEvents zijn immutable en worden bij de opschoning expliciet behouden. De geaggregeerde delete-flow-AuditEvents van het opschoonproces bevatten uitsluitend coded data en technische, pseudonieme referenties (zoals een Patient-UUID), zonder demografie en zonder vrije tekst. Voor het reguliere access-log ligt dat anders: search-events leggen per TOP-KT-011 - Logging en tracing de uitgevoerde query vast (entity.query), inclusief eventuele business-identifiers (bijvoorbeeld Patient?identifier=…), plus referenties naar de gevonden resources. Ook ná de definitieve verwijdering blijven zulke AuditEvents daarmee persoonsgegevens.

De bewaring van het audit-log steunt daarom niet op anonimiteit of pseudonimisering, maar op de wettelijke logging-verplichting (NEN 7513); het recht op wissing geldt niet voor zover de verwerking nodig is voor het nakomen van die plicht (AVG art. 17 lid 3 sub b). Als waarborg gelden strikte toegangsbeperkingen: de beveiligingseisen van dit topic en het toegangsregime van TOP-KT-005 - Toegangsbeheersing blijven onverkort op AuditEvents van toepassing, AuditEvents zijn voor applicaties read-only en de opschoon-AuditEvents zijn uitsluitend leesbaar voor deelnemende applicaties binnen hetzelfde DPA-domein.

JWT

• Gebruik een (digitale) handtekening om de integriteit van JSON Web Tokens te waarborgen.

• De ondertekening moet gedaan worden met asymmetrische algoritmen. Symmetrische algoritmen zijn niet toegestaan.

• De volgende algoritmen zijn toegestaan om JWT documenten te ondertekenen:

  • RS256, RS384, en RS512

  • ES256, ES384, and ES512

Autoriseer HTTP interacties op de verschillende resources d.m.v. een autorisatie lijst. Deze lijst kan via beheerschermen beheerd worden.

Input validatie (zie ook TOP-KT-012 - Foutafhandeling en Statuscodes)

• vertrouw geen input parameters en/of (binaire) objecten

• valideer lengte / formaat, enums en types - strong typing (number, boolean, date, time, enums, etc)

• valideer strings met reguliere expressies. Bv oid, id, uri, etc voldoen aan bepaalde formaten en worden vaak als string doorgegeven

• valideer inkomende content-types (application/xml of application/json). Content-Type header en content MOETEN hetzelfde zijn

• valideer response types. Kopieer NIET de Accept header naar de Content-Type header van de response

Manage de endpoints

• CORS (Cross Origin Resource Sharing) - Beperkt het opvragen van resources in een ander domein, vanwaar uit de eerste resource vandaan komt

Security Headers

• Er zijn een aantal beveiliging gerelateerde headers die kunnen worden geretourneerd in de HTTP-responses om browsers te instrueren om op specifieke manieren te handelen, specifiek als de browser gebruik maakt van RESTful APIs. De volgende headers moeten in deze APIs gebruikt worden. Zie ook REST Security - OWASP Cheat Sheet Series

Links naar gerelateerde onderwerpen

TOP-KT-005 - Toegangsbeheersing

TOP-KT-007 - Koppeltaal Launch

TOP-KT-011 - Logging en tracing

TOP-KT-012 - Foutafhandeling en Statuscodes

REST Security - OWASP Cheat Sheet Series

{}