RFC0013 Meer mogelijkheden voor encryptie toestaan
Samenvatting
Waarom is deze RFC nodig? | Encryptie van persoonsgegevens in persoonsdomein moet vrijer en sterker. De huidige eis zie normenkader IB A.10.1.1 stelt minimale en beperkende eisen. Naar aanleiding van vragen van auditors en deelnemers hoe deze norm ingevuld moet worden. |
---|---|
Oplossingsrichting | Specificeer kaders waaraan encryptie moet voldoen met meer keuzevrijheid in de vorm van toegepaste encryptie waardoor het ook wordt toegestaan om bijvoorbeeld persoonsgebonden encryptie toe te passen. |
Aanpassing van | Eis norm 10.1.1: aanpassen zodat ook persoonsgebonden encryptie mogelijk wordt |
Impact op rollen | DVP en DVZA. Vergeet ook niet het versleutelen van logging. |
Impact op beheer | Eis moet getoetst worden tijdens jaarlijkse MedMij audit |
Impact op RnA | Nee, nu niet voorzien |
Impact op Acceptatie | Nee, nu niet voorzien |
Gerelateerd aan (Jira issues) | nvt |
Eigenaar | Johan Hobelman & Maarten Schmidt MedMij beheerorganisatie (beoogd voor architectuurteam MedMij |
Implementatietermijn | Release 1.3.0 |
Motivatie verkorte RFC procedure (patch) | Vanuit een deelnemer (DVP) kwam de vraag waarom er alleen disk en/of database level encryptie was toegestaan voor MedMij. Met deze RFC willen wij dit ook mogelijk dat een deelnemer, typische DVP ook andere vormen van encryptie zou kunnen toepassen om het doel van beveiligen van persoonlijke gezondheidsgegevens mogelijk te maken. |
Releasenote | Encryptie is niet meer beperkt tot disk en/of database encryptie maar er wordt nu verwezen naar de aanbevelingen in https://www.keylength.com/. en geldt voor alle persoonlijke gezondheidsgegevens. |
Goedkeuring
Beoordelaar | Datum | Toelichting | Beoordelaar | Datum | Toelichting |
---|---|---|---|---|---|
Productmanager Stichting MedMij | Productmanager Beheerorganisatie | ||||
Leadarchitect Stichting MedMij | Leadarchitect Beheerorganisatie | ||||
Ontwerpteam | |||||
Deelnemersraad | Eigenaarsraad |
Principe's
Principe | Principe | ||
---|---|---|---|
1 Het MedMij-netwerk is zoveel mogelijk gegevensneutraal | Positief | 11 Stelselfuncties worden vanaf de start ingevuld | Positief |
2 Dienstverleners zijn transparant over de gegevensdiensten | Positief | 12 Het afsprakenstelsel is een groeimodel | Positief |
3 Dienstverleners concurreren op de functionaliteiten | Positief | 13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders | Positief |
4 Dienstverleners zijn aanspreekbaar door de gebruiker | Positief | 14 Uitwisseling is een keuze | Positief |
5 De persoon wisselt gegevens uit met de zorgaanbieder | Positief | 15 Het MedMij-netwerk is gebruiksrechten-neutraal | Positief |
6 MedMij spreekt alleen af wat nodig is | Positief | 16 De burger regisseert zijn gezondheidsinformatie als uitgever | Positief |
7 De persoon en de zorgaanbieder kiezen hun eigen dienstverlener | Positief | 17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld | Positief |
9 De dienstverleners zijn deelnemers van het afsprakenstelsel | Positief | 18 Afspraken worden aantoonbaar nageleefd en gehandhaafd | Positief |
10 Alleen de dienstverleners oefenen macht uit over persoonsgegevens bij de uitwisseling | Positief | 19 Het afsprakenstelsel snijdt het gebruik van normen en standaarden op eigen maat | Positief |
Uitwerking
A.10.1.1 Beleid inzake het gebruik van cryptografische beheersmaatregelen
Norm
Rationale | Persoonlijke gezondheidsgegevens moeten versleuteld worden opgeslagen. Dit heeft als doel dat de vertrouwelijkheid en integriteit van de gezondheidsgegevens gewaarborgd is, ook indien: · Een onbevoegd persoon toegang krijgt tot de datadrager (het hardware medium) · Een onbevoegd persoon toegang verkrijgt tot de logische dataopslag (de database of het gegevensbestand) |
Implementatie | Opgeslagen persoonlijke gezondheidsgegevens MOETEN beschermd worden door middel van encryptie. Hiervoor wordt verwezen naar de aanbevelingen die gelden voor 'near term protection' en 'long-term protection' in de aanbevelingen, zie . https://www.keylength.com/ |
Toelichting |
|
NEN 7510:2017 | A.10.1.1 Beleid inzake het gebruik van cryptografische beheersmaatregelen |
NEN 7510:2011 | A.12.3.1 Beleid voor het gebruik van cryptografische beheersmaatregelen |
Beoordeling
Auditmethode |
|
Verificatie |
|
Risico's
Omschrijf de (privacy)risico's die kunnen ontstaan als deze RFC wordt aangenomen. In het onwaarschijnlijke geval dat deze RFC's geen risico's introduceert, geef dat dan wel aan.
Dreiging | Kans | Impact | Maatregelen |
---|---|---|---|
Bijlagen