Thread by @aeris22

Un petit thread sur #Doctolib parce qu’il paraît que c’est la saison 😊 …/…

On va commencer par le gros préjugé qui colle partout : non, votre praticien n’a pas à vous demander votre consentement avant de mettre vos données sur Doctolib ! …/…

De la même manière que votre employeur ne vous le demande pas pour choisir son logiciel de paie ou sa mutuelle, qu’un commerçant ne vous le fera pas pour son logiciel de caisse ou votre assurance pour son logiciel de facturation ! …/…

Le choix d’un prestataire/sous-traitant quelconque ne relève pas du consentement. La seule obligation faite est que l’utilisateur (du logiciel, donc pas vous, le praticien) vérifie sa conformité RGPD. C’est à mon avis là que le bât blesse… …/…

Ça blesse même certainement à double titre.
1- Toutes les chances du monde pour que votre praticien, le RGPD il s’en cogne complètement. Du coup, la vérif de la conformité, hein… …/…

2- Parce que la com’ (en tout cas publique) de Doctolib est peu claire sur certains sujets pourtant critiques pour une bonne appréhension de la conformité… …/…

Forcément que si on fait passer du pas chiffrement ou du chiffrement simple pour du chiffrement e2e, le praticien, déjà qu’il est comme un poisson devant un vélo sur le sujet, mais en plus avec un peu de paillettes et des bons commerciaux… …/…

On rappelle quand même l’article 5(1)a du RGPD à ce sujet : Les données à caractère personnel doivent être traitées de manière licite, ＊＊loyale et transparente＊＊ au regard de la personne concernée.
Forcément, ça tique un peu à ce niveau… …/…

Le 1er coupable serait ici du coup plus le praticien que Doctolib. La vérification de la conformité lui incombe, quelque soit le discours commerciale en face, il est supposé être compétent (ou se faire accompagner pour l’être) sur le sujet. …/…

On rappelle la condamnation de Slimpay sur ce créneau pour n’avoir fait que vaguement questionner son prestataire…
legifrance.gouv.fr/cnil/id/CNILTE…
Les fiches « d’audit » où le presta coche tout en vert, c’est fini. Vous devez vraiment vous sortir… social.imirhil.fr/@aeris/1083340…

Côté Doctolib, en dehors de la com’ qui fait de la com’, le problème principal est surtout celui de l’usage de AWS. On rappelle que SchremsII interdit tout transfert de données personnelles à un prestataire état-unien !
eur-lex.europa.eu/legal-content/…
…/…

RIP aussi les analyses de risque ou autre mesures de protection. Ça n’existe juste pas quand on parle de transfert de DCP à un pays tiers (chapitre 5 du RGPD), uniquement pour les traitements direct (chapitre 4).
noyb.eu/fr/mise-jour-s…
…/…

À la décharge de Doctolib (expliquer n’est pas excuser hein ! 🤣), les prestataires HDS sont rares, et vu la liste… y’en a vraiment pas des masses de conseillables ! La peste ou le cholera quoi…
esante.gouv.fr/offres-service…
…/…

Certains font même dans la petite blagounette du même style que e2e/pas e2e… Tu es HDS, mais sur 5 des 6 critères… Et forcément tu ne l’es pas sur le n°5, qui est le plus chiant et critique (en gros tu qualifies l’infra, le matos et les gens,… social.imirhil.fr/@aeris/1083341…

Vous avez du coup le choix entre des trucs qui très certainement ne tiendront pas la charge face à un système aussi volumineux que Doctolib, soit sont des SSII habituelles bien connues (les fameuses CASSOS), soit des GAFAM… Le classique quoi… …/…

Ensuite on va sortir un peu du sujet purement Doctolib, et parler de la situation pré-Doctolib. Encore une fois expliquer n’est certainement pas excuser, mais… …/…

(Ah si quand même, précision sur HDS mais les données de rendez-vous ne rentrent pas dans la catégorie officielle « données de santé » nécessitant du HDS. La liste réelle est (trop) courte et couvre vraiment que dalle en pratique. Donc… social.imirhil.fr/@aeris/1083341…

Si vous voulez le détail de pourquoi la certif légale HDS est fucked, c’est par là :

https://twitter.com/aeris22/status/1274403070915629056

.)
…/…

Bon du coup, le monde avant Doctolib, c’était quoi ? Un cabinet médical géré par le taxiphone du coin, tenu par des gens à peine mieux formé que le praticien en terme de sécurité informatique. Et absolument pas en donnée de santé. …/…

La maintenance était faite par TeamViewer. Ne rigolez pas… linuxfr.org/users/audionum…
Un truc encore moins sécurisé que Doctolib… Ouvert sur le net, protégé par un code à 4 chiffres. Fixes. 😱
…/…

C’était un carnet de rendez-vous souvent géré par la femme du médecin (oui, je sais que certain médecin sont des femmes, mais je doute que dans ce cas le conjoint restait à la maison prendre les rdv…). Quand le carnet était plein, c’était direction… social.imirhil.fr/@aeris/1083341…

Sur les données médicales elles-mêmes, vos données étaient/sont stockées sur des fiches cartonnées, accessibles à souvent trop de monde dans le cabinet (facile à dérober), sans suivi réel, avec des pertes possibles, les vieux dossiers aux ordures… …/.

La transmission à un autre praticien relève du parcours du combattant. Pour de la bobologie ça va, pour les pathologies plus importantes, longues ou multi-sectoriel, c’est le bordel. Le DMP/ENS adresse ça aussi d’ailleurs. …/…

Les sauvegardes étaient faites (quand elles l’étaient… 😑) sur des disques standards du taxiphone du coin. Mesure de protection proche du néant… …/…

Bref, pas pour encenser Doctolib non plus vu que je n’aime pas la politique du moins pire, mais ça fait quand même pas mal avancer le schmilblick ! …/…

Certains réclament la nationalisation de ce genre de service. Honnêtement j’ai un peu du mal à voir en quoi ça serait le boulot de l’État de développer et maintenir un service de rendez-vous, en tout cas pour les médecins libéraux. 🤔

Et connaissant la joie des CASSOS dans l’État, je ne suis pas certain qu’on aurait atteint le niveau technique de Doctolib 🤣 On en serait pas à parler de faux e2e vs vrai e2e, mais plutôt de chiffrement vs pas chiffrement tout court…… social.imirhil.fr/@aeris/1083342…

Sur la partie centralisation/décentralisation, je n’ai pas d’avis tranché sur la question. Elle est très complexe à analyser. …/…

Un système centralisé qui se fait powned, ça fait (très) mal. Un système décentralisé qui se fait powned, ça pique assez peu. …/…

À l’inverse, le RGPD impose désormais l’usage d’outils de détection préventive des accès abusifs. Du type des IAM/SIEM de chez Amazon pour ne pas les citer. …/…

Des boîtes se sont faites dégommer par la CNIL pour ne pas en avoir mis en place.
Les lignes directrices sur le sujet sont là : cnil.fr/fr/la-cnil-pub… …/…

Ces outils ont pour objectif de détecter bien plus en amont que l’éventuelle publication des données exfiltrées sur le marché noir ou autre, en alertant immédiatement qu’un truc anormal est en train de se passer dans le SI. …/…

L’outil de compta en train de remonter toutes les données de paie le 28 du mois, c’est normal. Le 15, ça l’est moins…

Sauf que ces outils sont assez coûteux, nécessitent des infras réseaux spécifiques Oubliez la location de machine unitaire chez votre prestataire adoré, on est plus proche du housing que d’autre chose à ce niveau… ou d’infra « battery included » du type AWS !!!!

Du coup sans une masse critique, donc de la centralisation, ce type d’outil vous pouvez oublier ! Sans parler du temps nécessaire pour auditer régulièrement les logs générés ! (Oui, c’est aussi une… social.imirhil.fr/@aeris/1083342…

Et le décentralisé, c’est aussi la plaie à maintenir sur le long terme. Comment « imposer » aux praticiens de mettre à jour ? Comment garantir que X00 solutions du marché sont en conformité avec les réglementations ? Et le resterons ?

Ça veut aussi dire des moyens de formation/accompagnement/suivi de la sécurité très dispersés. Vaut-il mieux X00 DPO et RSSI (mal) formés que X (bien) formés ? 🤔