...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
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.
...
| Info | ||
|---|---|---|
| ||
| 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
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.
...
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
...
- 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.
| 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 |
Eisen
Voorbeelden
[code]
Links naar gerelateerde onderwerpen
TOP-KT-005 - Toegangsbeheersing [oud]
TOP-KT-007 - Koppeltaal Launch
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).
...
- 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.
| 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 |
Rationale
Behandel de (gebruikte) infrastructuur als onbekend en (niet) veilig.
Zie: REST Security - OWASP Cheat Sheet Series