Skip to end of banner
Go to start of banner

TOP-KT-008 - Beveiliging aspecten

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 23 Next »

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 eenoverzicht van de aspecten te verzamelen.


Status

Dit topic betreft een verzameltopic van de beveligingsaspecten van Koppeltaal. Op dit moment is dit topic nog 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 en 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.

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.

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

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

HeaderBeschrijving
Cache-Control: no-storeVoorkom dat gevoelige informatie in de (browser) cache wordt opgeslagen
Content-Security-Policy: frame-ancestors 'none'Bescherming tegen drag-and-drop style clickjacking aanvallen
Content-TypeSpecificeer de content type van de response (antwoord). Dit MOET gevuld worden
Strict-Transport-SecurityOm een verbinding via HTTPS te vereisen en te beschermen tegen vervalste certificaten
X-Content-Type-Options: nosniffOm MIME-sniffing via de browser te voorkomen
X-Frame-Options: DENYBescherming 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

Zie ook: REST Security - OWASP Cheat Sheet Series


  • No labels