...
| 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 en geef daarbij voorkeur aan persoonsgebonden encryptie.Diskencryptie is te weinig. Beter is persoonlijke / persoonsgebonden encryptie |
| Aanpassing van | Eis norm 10.1.1: aanpassen zodat persoonsgebonden encryptie mogelijk wordt en deze wijze van toepassing |
| 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 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 |
...