Beschrijving

Elke applicatie MOET beveiliging toepassen. Dus een applicatie MOET zich authenticeren en MOET autorisatie krijgen bij het opvragen of afgeven van gegevens bij een dienst. Geldt ook voor licht gewicht applicaties (eHealth modules).

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. Echter ook zonder deze uitwisseling is het ongewenst dat onbevoegden toegang krijgen tot het stelsel,

Toepassing en restricties

HTTPS

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

Access Control (toegangscontrole)

• Om de koppelingen tussen de diensten te minimaliseren, moet de besluitvorming over de toegang tot de diensten, lokaal worden genomen via (voor gedefinieerde) 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.
• URL validatie

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 - [review]) 

• 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

Output encoding

• Maak gebruik van security headers, zoals X-Content-Type-Options: nosniff en X-Frame-Options: deny

Manage de endpoints

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. De volgende kopteksten moeten in alle (RESTful) API-reacties worden opgenomen.

Eisen

Voorbeelden

[code]

Links naar gerelateerde onderwerpen

TOP-KT-005 - Toegangsbeheersing [oud]

TOP-KT-007 - Koppeltaal Launch [review]

TOP-KT-012 - Foutafhandeling en Statuscodes - [review]

Zie ook: REST Security - OWASP Cheat Sheet Series

Oude tekst (kan op termijn weg)

Beschrijving

Elke applicatie MOET beveiliging toepassen. Dus applicatie MOET zich authenticeren en MOET autorisatie krijgen bij het opvragen of afgeven van gegevens bij een dienst. Geldt ook voor licht gewicht applicaties (eHealth modules).

HTTPS

• Beveiligde REST diensten/services mogen alleen hun diensten via een HTTPS-enpoint aanbieden.
  • Dit beschermt de 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.

Access Control (toegangscontrole)

• Om de koppelingen tussen de diensten te minimaliseren, moet de besluitvorming over de toegang tot de diensten, lokaal worden genomen via (voor gedefinieerde) REST-endpoints
• Gebruikers authenticatie moet worden gecentraliseerd bij een Identiteit Provider  (IdP), die authenticatie tokens uitgeeft.
• Systeem authenticatie moet bij een Autorisatie Server worden gecentraliseerd.
• URL validatie

JWT

• Gebruik een (digitale) handtekening om de integriteit van JSON Web Tokens te waarborgen
• Een vertrouwende partij moet de integriteit van het JWT verifiëren op basis van zijn eigen configuratie of gecodeerde logica. Het mag niet vertrouwen op de informatie van de JWT-header om het verificatiealgoritme te selecteren.

Autoriseer HTTP interacties op de verschillende resources d.m.v. een autorisatie lijst.

Input validatie

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

Output encoding

• Maak gebruik van security headers, zoals X-Content-Type-Options: nosniff en X-Frame-Options: deny

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. De volgende kopteksten moeten in alle (RESTful) API-reacties worden opgenomen.

Rationale

Behandel de (gebruikte) infrastructuur als onbekend en (niet) veilig.

Zie: REST Security - OWASP Cheat Sheet Series

Implicaties

Voorbeelden

Toepassingsgebied

Onderbouwen

Eisen

Referenties

{}