Publié dans DroitInternet

12

Health Data Hub : Clever Cloud et d’autres acteurs saisissent le Conseil d’État

Entrée du Conseil d'EtatCrédits : Conseil d’État (CC BY 2.0)

Un groupe composé d’associations, d’entreprises et de particuliers vient de saisir le Conseil d’État. Il s’oppose au stockage des informations du projet EMC2 dans le cloud de Microsoft, ce qui représenterait les données médicales de 300 000 à 600 000 Français.

Ce recours fait suite à la décision de la CNIL, le 21 décembre dernier, d’autoriser ce stockage. On se souvient que la Commission semblait « coincée » dans sa formulation, forcée de reconnaitre la légalité de ce stockage en vertu du Data Privacy Framework. Ce dernier, pour rappel, consacre l’adéquation des mesures de sécurité et de vie privée entre l’Europe et les États-Unis.

Le groupe, dont fait partie Clever Cloud, a prévu une conférence de presse ce matin à 8h30. L’audience, elle, aura lieu demain au Conseil d'état. Nexedi, Rapid.space ainsi que des associations telles l’Open Internet Project et l’Association de défense des libertés constitutionnelles sont également présentes.

Il est officiellement demandé au Conseil d'état d’annuler la décision de la CNIL, « ou du moins la transmission d’une question préjudicielle à la CJUE ». Dans ce cas de figure, le groupe tenterait de faire sauter le DPF. Le communiqué de Clever Cloud rappelle d’ailleurs que les deux précédents cadres d’échanges entre Europe et États-Unis avaient sauté en 2015 et 2020, respectivement avec les arrêtés Schrems I et II.

« C’est un recours osé et bien construit, assorti d’une question préjudicielle. C’est tout ce que l’on souhaitait », nous a répondu le député Philippe Latombe, interrogé sur le sujet.

12

Tiens, en parlant de ça :

Le fichier des empreintes digitales sera interconnecté avec huit autres fichiers

FAED y verse

17:24 DroitSécu 5
Les logos de Facebook et Meta dans des carrés en 3D sur un fond grisé dégradé

Le ciblage publicitaire ne peut pas utiliser des données personnelles récupérées ailleurs

Schrems vs Meta, encore et encore

16:53 DroitSocials 6

Windows 11 ajoute des publicités dans le menu Démarrer, comment les supprimer

Rogntudjuuu !

11:18 Soft 67
next n'a pas de brief le week-end

Le Brief ne travaille pas le week-end.
C'est dur, mais c'est comme ça.
Allez donc dans une forêt lointaine,
Éloignez-vous de ce clavier pour une fois !

12

Fermer

Commentaires (12)


Hâte d'une décision rapide de la CJUE.

Je crois que me souvenir qu'un ministre avait répondu que le HDH avait une base juridique solide (alors que l'arrêté Schrem était en cours). Analyse juridique jamais publié il me semble.
C'est le moment de voir si il avait raison.
Pour des raisons de sécurité des données, je propose d'utiliser la même infrastructure que "France Travail".
:mrgreen:
Modifié le 18/03/2024 à 09h29

Historique des modifications :

Posté le 18/03/2024 à 09h29


Pour des raisons de sécurité des données, je suppose d'utiliser la même infrastructure que "France Travail".

Posté le 18/03/2024 à 09h29


Pour des raisons de sécurité des données, je propose d'utiliser la même infrastructure que "France Travail".

Ou sous-traiter à Viamédis et Almerys.
A mon avis, la question, c'est de savoir si nos data seront plus en sécurité dans un Cloud FR dont nous avons une mauvaise maîtrise, avec beaucoup de custom pour y arriver, ou bien aller sur un cloud US qui semble plutôt bien sécurisé mais qui n'est pas chez nous.

Dans le premier cas, la principale menace, c'est une attaque classique de hacker. Dans le second cas, c'est une injonction US.

Dans le second ca, je pense que c'est possible de palier au problème via du dev + hsm local.
Cloud US bien maitrisé ? Azure a déjà eu pas mal de failles et la dernière montrait un peu d’amateurisme (ancien compte de test avec droit d’admin).

bilbonsacquet

Cloud US bien maitrisé ? Azure a déjà eu pas mal de failles et la dernière montrait un peu d’amateurisme (ancien compte de test avec droit d’admin).
A cela j'ajouterai que la sécurité du Cloud est partagée. Le Cloud Provider a sa responsabilité, mais le client l'a tout autant.

Une souscription powned, ça arrive plus souvent qu'on ne le croit, et quand on se retrouve avec 500k€ de compute en une nuit, ça fait pas plaisir.

En soit, je ne vois pas encore quoi les CSP US seraient meilleurs sur les CSP Européens sur la sécurité.
De toute façon, peu importe chez qui nos données seront hébergées, ça sera fatalement géré par des bras cassés qui le sécuriseront mal.

Quand on voit les récentes affaires (Assurance Maladie, Pôle emploi, tiers payant Viamedis et Almerys, France Travail…) où les données de la quasi totalité des français se sont retrouvées dans la nature, ça ne sera à mon avis qu'une question de temps pour que nos données santé subissent le même sort ☹️

L'hébergeur n'est que la première pierre de l'édifice. Le plus important, c'est comment on va sécuriser tout ça, et qui va développer et maintenir tout l'applicatif (le plus important). Et comme on a plus ni les moyens, ni les compétences en interne, ça sera fatalement sous-traité, et jamais au plus compétent ☹️
Je me suis fait la même réflexion. La sécurité des données sera mise à mal quelque soit le lieu d'hébergement malheureusement. Je te sers un peu de peste ou de choléra ? :fou:
En cherchant des infos sur le type de données hébergées, je suis tombé sur cet article de 01 qui récapitule toute la polémique sur le HDH.

Il me semble assez complet et factuel.
Peut on facilement savoir si des données à nous sont dans ce HDH ? Et le cas échéant demander leur suppression ?
J'ai bien trouvé la possibilité de supprimer des données via https://www.health-data-hub.fr/politique-de-confidentialite mais je ne sais pas bien si cela concerne les données de santé ou seulement les données du site web (inscription à la newsletter etc)
Regarde du côté de mon espace santé: monespacesante.fr/

Mais certaines données type administrative (SECU) ou échange entre professionnels de Santé ne doivent pas être concernées par une demande de suppression.
Bien, des infos depuis ?
Le PDF de l saisie est relativement léger.