Versiegeschiedenis...

Versie	Datum	Status	Wijzigingen
1.0.0	24 Apr 2023	definitief

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.

Status

Dit topic betreft een verzameltopic van de beveligingsaspecten van Koppeltaal. Dit topic is niet compleet nog uitputtend.

Overwegingen

Binnen Koppeltaal gaat het om de interactie tussen zorgverleners en patiënten/cliënten. Vaak worden daarbij persoons- en/of medische gegevens 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.

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

Het is uitdrukkelijk niet de bedoeling dat de FHIR Service van Koppeltaal 2.0 direct vanuit de browser benaderd wordt.

Header	Beschrijving
Cache-Control: no-store	Voorkom dat gevoelige informatie in de (browser) cache wordt opgeslagen
Content-Security-Policy: frame-ancestors 'none'	Bescherming tegen drag-and-drop style clickjacking aanvallen
Content-Type	Specificeer de content type van de response (antwoord). Dit MOET gevuld worden
Strict-Transport-Security	Om een verbinding via HTTPS te vereisen en te beschermen tegen vervalste certificaten
X-Content-Type-Options: nosniff	Om MIME-sniffing via de browser te voorkomen
X-Frame-Options: DENY	Bescherming tegen clickjacking aanvallen met drag-and-drop style

Links naar gerelateerde onderwerpen

TOP-KT-005 - Toegangsbeheersing

TOP-KT-007 - Koppeltaal Launch

TOP-KT-012 - Foutafhandeling en Statuscodes

REST Security - OWASP Cheat Sheet Series