Publish Box goes here

Beveiligingsmodel

Beveiligingsmodel

Zorgaanbiederauthenticatie steunt op een keten van bewijzen. Iedere laag dekt een ander risico af en wordt door een specifieke actor gecontroleerd. Een implementatie mag een ontbrekende laag niet compenseren door een andere laag meer betekenis toe te kennen dan zij technisch heeft.

Te beschermen waarden

De flow beschermt:

• de identiteit van de aanvragende en bronhoudende zorgaanbieder;
• de samenhang tussen organisatie, issuer, sleutels en endpoints;
• de gevraagde en geaccepteerde autorisatie;
• het access token tegen gebruik door een ander sleutelpaar;
• het request tegen verplaatsing naar een andere methode of URI;
• de vertrouwelijkheid en integriteit van tokenverkeer en FHIR-payload;
• de beschikbaarheid van controleerbaar fout- en auditgedrag.

De klinische payload zelf wordt in dit profiel niet apart ondertekend. Haar vertrouwelijkheid en integriteit tijdens transport volgen uit de TLS-verbinding naar het exact geregistreerde en geautoriseerde endpoint.

Vertrouwensgrenzen

flowchart TB
    CLIENT["Clientsysteem<br/>URA-A"]
    TRUST["Vertrouwensvoorziening"]
    AUTH["Authorization server<br/>URA-B"]
    RESOURCE["FHIR resource server<br/>URA-B"]

    CLIENT -->|"Resolveer doelorganisatie"| TRUST
    TRUST -->|"Registratie, endpoints en publieke sleutels"| CLIENT
    CLIENT -->|"mTLS + client assertion + RAR + DPoP"| AUTH
    AUTH -->|"Getekend en DPoP-gebonden access token"| CLIENT
    CLIENT -->|"mTLS + access token + resource-DPoP"| RESOURCE
    RESOURCE -->|"FHIR-response over mTLS"| CLIENT

Binnen iedere organisatie blijven lokale gebruikersauthenticatie, mandatering, policy en sleutelbeheer eigen verantwoordelijkheden. Over iedere organisatiegrens moet de ontvangende actor alle relevante bewijzen opnieuw valideren.

Gestapelde bewijzen

Bewijs	Betekenis	Controleplaats	Bewijst niet
Vertrouwde organisatieregistratie	welke issuer, endpoints, JWKS en certificaten bij een organisatie horen	clientsysteem, authorization server	bezit van een privésleutel of actuele toestemming
mTLS-clientcertificaat	bezit van een privésleutel binnen een vertrouwde PKI en bescherming van het kanaal	token- en resource server tijdens TLS-handshake	de gevraagde autorisatie of tokenbinding
private_key_jwt	het aanvragende systeem bezit de geregistreerde signing key en richt de assertion aan de authorization-server-issuer	authorization server	toestemming voor een FHIR-resource
RAR	welke resource, doelorganisatie en gebruikscontext worden gevraagd	clientsysteem en authorization server	dat de server de aanvraag heeft geaccepteerd
Getekend access token	welke autorisatiedetails de issuer heeft geaccepteerd	clientsysteem en resource server	bezit van de DPoP-key of payloadintegriteit buiten TLS
DPoP-proof	bezit van de tokengebonden sleutel en binding aan methode, URI en eventueel token	authorization server en resource server	organisatietrust of kanaalversleuteling
TLS-servervalidatie	verbinding met een servernaam onder een vertrouwde certificaatketen	iedere client bij de TLS-handshake	dat het endpoint bij de bedoelde organisatie hoort zonder registratie

Belangrijkste dreigingen

Verwisseling van organisatie of endpoint

Een aanvaller kan proberen een geldig token, een JWKS-URI of een resource-URI naar een ander systeem te laten wijzen. Daarom moeten issuer, tokenendpoint, JWKS en resourcebasis uit één vertrouwde registratie komen. aud, authorization_details.locations en de uiteindelijke request-URI moeten vervolgens exact bij die registratie passen.

Gestolen of doorgestuurd token

Een access token zonder sender constraint kan door een andere partij worden hergebruikt. DPoP bindt het token via cnf.jkt aan een clientgegenereerde publieke sleutel. De resource server vereist daarna een verse proof met passende htm, htu en ath.

Replay

Een geldig ondertekend bericht kan nog steeds opnieuw worden aangeboden. Client assertions en DPoP-proofs hebben daarom een korte geldigheid en een unieke jti. De controlerende actor bewaart gebruikte waarden ten minste tot na het geldigheidsvenster.

Onbedoelde autorisatie

Clientauthenticatie bewijst wie aanvraagt, niet wat die organisatie mag lezen. De RAR beschrijft daarom resource, doelorganisatie en gebruiksdoel afzonderlijk. De authorization server past eigen beleid toe en tekent alleen de geaccepteerde details in het access token.

Lekken via observability

Compacte assertions, access tokens, DPoP-proofs en privésleutels zijn geen geschikte loginhoud. Fout- en auditregistratie gebruikt beslisregel-id's, actoren, tijd, correlatie en uitkomst. De workbench toont uitsluitend gesanitiseerde wirebeelden en publieke JOSE-claims.

Profielregel en productie-invulling

Profielregel: iedere ontvangende actor moet alle bewijzen controleren die op zijn vertrouwensgrens relevant zijn en moet bij een ontbrekend, tegenstrijdig, verlopen of herhaald bewijs veilig stoppen.

Conceptkeuze uit het VWS/Twiin-memo: de organisatiehandtekeningen worden verbonden aan sleutels van geregistreerde organisatiecertificaten.

Open ontwerpkeuze: landelijke governance moet nog vaststellen welke registratie, PKI en certificaatprofielen, statusvoorziening, sleutelrotatie, tijdsvensters en duurzame replayopslag in productie worden gebruikt.

Referentie-implementatie: de repository gebruikt een lokale registratie, demo-CA, certificaatgebonden P-256/ES256-signing keys en in-memory replaystores om deze grenzen uitvoerbaar en testbaar te maken.