Samenvatting
| Waarom is deze RFC nodig? | Technical debt, tijd heeft zaken ingehaald. Twee factor authenticatie voor DVP en DVZA moeten vergelijkbaar zijn en ook voldoen aan de stand der techniek. |
|---|---|
| Oplossingsrichting | Het gebruik van SMS als tweede factor wordt door experts als minder betrouwbaar gezien. Ook Logius DigiD gaat het gebruik van Digid met SMS als tweede factor afbouwen verminderen. Zie https://www.security.nl/posting/672857/Overheid+wil+inloggen+via+DigiD+met+sms-code+terugdringen+ten+gunste+van+app. |
| Aanpassing van | Richtlijnen voor het gebruik van Digid substantieel of hoger door DVZA's en aanpassing van normenkader A9.4.1 Deze norm is in AS 1.2.0 ook al uitgebreid en in dit geval zou dat ook moeten. Zie ook /RFC0006+Expliciete+eisen+2-factor+authenticatie |
| Impact op rollen | DVP en DVZA |
| Impact op beheer | |
| Impact op RnA | NVT |
| Impact op Acceptatie | Als dit onderdeel is van de acceptatie |
| PIA noodzakelijk | |
| Gerelateerd aan (Andere RFCs, PIM issues) | RfC0056 |
| Eigenaar | VZVZ-SC/R&S, Former user (Deleted) |
| Implementatietermijn | 1.5.0: Verplichting om een veiliger methode dan sms/email als tweede factor te bieden. 1.6.0: Nieuwe aanpassingen worden in overleg met Security Management en deelnemers doorgevoerd. |
| Motivatie verkorte RFC procedure (patch) | Twee factor authenticatie voor DVP en DVZA moeten vergelijkbaar zijn en ook voldoen aan de stand der techniek. |
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 | 11 Stelselfuncties worden vanaf de start ingevuld | ||
| 2 Dienstverleners zijn transparant over de gegevensdiensten | 12 Het afsprakenstelsel is een groeimodel | ||
| 3 Dienstverleners concurreren op de functionaliteiten | 13 Ontwikkeling geschiedt in een half-open proces met verschillende stakeholders | ||
| 4 Dienstverleners zijn aanspreekbaar door de gebruiker | 14 Uitwisseling is een keuze | ||
| 5 De persoon wisselt gegevens uit met de zorgaanbieder | 15 Het MedMij-netwerk is gebruiksrechten-neutraal | ||
| 6 MedMij spreekt alleen af wat nodig is | 16 De burger regisseert zijn gezondheidsinformatie als uitgever | ||
| 7 De persoon en de zorgaanbieder kiezen hun eigen dienstverlener | 17 Aan de persoonlijke gezondheidsomgeving zelf worden eisen gesteld | ||
| 9 De dienstverleners zijn deelnemers van het afsprakenstelsel | 18 Afspraken worden aantoonbaar nageleefd en gehandhaafd | ||
| 10 Alleen de dienstverleners oefenen macht uit over persoonsgegevens bij de uitwisseling | 19 Het afsprakenstelsel snijdt het gebruik van normen en standaarden op eigen maat | ||
| Toelichting | |||
Uitwerking
Normenkader Informatiebeveiliging A.9.4.1 Beperking toegang tot informatie.
Huidige tekst; "Authenticatie van personen (eindgebruikers) MOET plaatsvinden op basis van minimaal twee factoren. Na succesvolle authenticatie krijgen personen alleen toegang tot hun eigen persoonlijke gezondheidsgegevens."
Voorgestelde tekst "Authenticatie van personen (eindgebruikers) MOET plaatsvinden op basis van minimaal twee factoren. Na succesvolle authenticatie krijgen personen alleen toegang tot hun eigen persoonlijke gezondheidsgegevens."
Nieuwe accounts moet op basis van twee factoren authentiseren waarbij de tweede factor geen SMS of email code betreft. Bestaande accounts die SMS of e-mail gebruiken als tweede factor moet de mogelijkheid geboden worden om een andere tweede factor te kiezen en bij een volgende release van het Afsprakenstelsel zullen alle accounts verplicht een sterke tweede factor gebruiken.
Redactie:
1.5.0: Op pagina A. 9.4.1 Beperking toegang tot informatie aanpassen in Norm-tabel:
Implementatie Authenticatie van personen (eindgebruikers) MOET plaatsvinden op basis van minimaal twee factoren. Na succesvolle authenticatie krijgen personen alleen toegang tot hun eigen persoonlijke gezondheidsgegevens of de gegevens van de vertegenwoordigde.
Naast SMS MOET een deelnemer ook een sterkere tweede factor aanbieden. De Persoon bepaalt zelf welke tweede factor wordt gebruikt.
In deze versie van het Afsprakenstelsel wordt SMS als tweede factor nog geaccepteerd. Het voornemen is deze methode te schrappen. Dit kan, op het moment dat grotere beveiligingsrisico's optreden, via een snel door te voeren patch van het Afsprakenstelsel.
1.5.0: Op pagina A. 9.4.1 Beperking toegang tot informatie aanpassen in Twee-factoren-tabel:
SMS
Als onderdeel van de authenticatie wordt een dynamische SMS-code gecontroleerd. De SMS-code is voldoende lang en steeds een andere. Naast SMS MOET een deelnemer ook een sterkere tweede factor aan kunnen bieden.
1.6.0: Op pagina A. 9.4.1 Beperking toegang tot informatie aanpassen in Norm-tabel:
Implementatie
Authenticatie van personen (eindgebruikers) MOET plaatsvinden op basis van minimaal twee factoren. Na succesvolle authenticatie krijgen personen alleen toegang tot hun eigen persoonlijke gezondheidsgegevens.Authenticatie van personen (eindgebruikers) MOET plaatsvinden op basis van minimaal twee factoren. Na succesvolle authenticatie krijgen personen alleen toegang tot hun eigen persoonlijke gezondheidsgegevens."
Nieuwe accounts moet op basis van twee factoren authentiseren waarbij de tweede factor geen SMS of email code betreft. Bestaande accounts die SMS of e-mail gebruiken als tweede factor moet de mogelijkheid geboden worden om een andere tweede factor te kiezen en bij een volgende release van het Afsprakenstelsel zullen alle accounts verplicht een sterke tweede factor gebruiken.
1.6.0: Op pagina A. 9.4.1 Beperking toegang tot informatie aanpassen in Twee-factoren-tabel:
SMS
Als onderdeel van de authenticatie wordt een dynamische SMS-code gecontroleerd. De SMS-code is voldoende lang en steeds een andere. SMS-code mag binnen MedMij niet als (enige) tweede factor worden toegepast.
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 | DreigingsID (intern) | Maatregelen |
|---|---|---|---|---|
Gebruikers account overnemen, geen effectieve tweede factor | midden | groot | Stand der techniek, aanpassen wijze van authenticeren. |
Bijlagen