Données de santé : la société française Alan explique pourquoi elle utilise Amazon Web Services

Données de santé : la société française Alan explique pourquoi elle utilise Amazon Web Services

Données de santé : la société française Alan explique pourquoi elle utilise Amazon Web Services

Alors que la question de l’hébergement du Health Data Hub remonte à la surface, Alan apporte sa contribution sous la forme d’un retour d’expérience : « On lit souvent qu’il faudrait héberger les données en France coûte que coûte. Par transparence, nous avons décidé de faire le point sur notre choix d’héberger les données de nos membres chez le prestataire américain Amazon Web Services », qui est certifié HDS (Hébergement de Données de Santé).

La société explique : « en chiffrant les données hébergées, on empêche que des personnes qui y accèderaient éventuellement de manière non autorisée (y compris l'hébergeur lui-même) puissent en prendre connaissance. Toutes nos données sur AWS sont chiffrées au repos. Ce qui veut dire que même quelqu’un qui aurait accès physiquement aux serveurs […] ne pourrait pas lire les données ». L’entreprise ne donne aucune information supplémentaire sur ce « chiffrement » ni sur l'origine et/ou la détention de la clé.

Alan reconnaît néanmoins que « quand on choisit un hébergeur, il y a aussi un certain nombre de choses qu’on ne peut pas contrôler, comme la transparence dont fait preuve l’hébergeur, les lois de son pays d’origine, ou le contrôle qu’on laisse à l’hébergeur sur ses serveurs et l’accès qu’il y donne à des tiers ».

Au final, la société doit bien reconnaître que, « si, suite à une saisine, un tribunal américain demandait à accéder aux serveurs d’AWS de manière valable et incontestable en droit américain, ils le pourraient. Le fait que nous chiffrions les données nous permet d’ajouter une barrière technique à la lecture dans ces cas. ». 

Elle ajoute : « si nous avions choisi un hébergeur français, le problème serait finalement assez similaire […] Certes, le droit français est un petit peu plus protecteur que le droit américain à ce titre, et il serait plus facile pour nous de nous “battre” devant un tribunal français, en terrain connu, si nous étions prévenus d’un tel cas ».

Commentaires (20)


Comprendre : c’était moins cher.


Ben pour comparer régulièrement, c’est pas plus cher, bien au contraire… Quand je vois les tarifs d’un AWS en comparaison de bare metal chez Online par exemple, ma facture ferait x3 tous les mois pour le même usage.



Après c’est certain : utiliser des instances AWS, c’est beaucoup plus facile à monter que créer/maintenir une infra sur du dédié à configurer soi-même. Je pense que c’est surtout ça l’argument principal.


Voilà merci :D


Alan est bien gentil mais Microsoft peut déchiffrer les données du hdh



Mediapart “La Cnil demande l’arrêt du stockage de nos données de santé par Microsoft”
9 octobre 2020 Par Jérôme Hourdeaux



La Cnil s’inquiétait par ailleurs également de la manière dont sont gérées les clefs de chiffrement, permettant de déchiffrer les données, et dont une copie sera conservée « par l’hébergeur au sein d’un boîtier chiffrant, ce qui a pour conséquence de permettre techniquement à ce dernier d’accéder aux données », ainsi que d’un manque d’encadrement des procédures d’accès des administrateurs de la plateforme.


Pour le cas de Microsoft (Azure, Exchange, Sharepoint et maintenant Teams) il est possible de gérer ses propres clés avec son propre HSM (exemple : Thales Luna – ex Gemalto), qui sont validés au plus haut niveau par l’état français. Après oui, en soit, si Microsoft le voulait, il y aurait toujours des moyens d’intercepter/voir des données des clients. Mais dans ce cas, alors on arrête d’utiliser windows, macos, ios, android by google etc. Car en soit, qui dé-compile toutes les mises à jours de ses OS pour vérifier que les éditeurs US n’ont pas collé des backdoors ? qui désactive à 100% les stores grand publics (oui, y’a des programmes de transparency, avec audit de code, mais c’est pas pour chaque mise à jour qui est poussé en prod… et pour les devices mobiles, c’est bien pire, très peu d’orgas désactivent les syncro icloud/google).



Et dans le même compte alors, on arrête d’utiliser des équipements réseau/firewall de marques américaines car ils sont tous ou presque en mode maj auto pour les vuln crititiques, et tous les établissements de santé n’attendent pas le go de l’état francais pour chaque mise à jour… Donc en soit, des sociétés / agences US à 3 lettres pourraient (conditionnel) faire nous espionner par là. Car oui, si on n’accepte / n’accepte pas de leur confier nos données, c’est pour des raisons d’espionnage industriel/défense principalement…



lien azure byok : https://docs.microsoft.com/fr-fr/azure/key-vault/keys/hsm-protected-keys


Ca ressemble plutôt à une tentative de justifier et de rationaliser un choix passé.



C’est sur que c’est compliqué à changer après coup, et que plus le temps passe, plus ça devient compliqué. Pourtant quand on voit les batailles qui se jouent actuellement, ne pas faire de virage au plus vite relève à mon sens d’une erreur grave.


On m’aurait menti ? Les partisans du cloud n’arrêtent pas de dire que tes VMs, tu les déplaces au gré du vent, comme bon te semble, que la VM c’est la liberté pas comme le bare metal. En fait, c’est du flan ?


Il faut arrêter de parler de certificat HDS sans dire la catégorie.
Il y a 6 catégories et elles ne recoupent les aspects:
https://esante.gouv.fr/labels-certifications/hds/certification-des-hebergeurs-de-donnees-de-sante



zongap a dit:


Après oui, en soit, si Microsoft le voulait, il y aurait toujours des moyens d’intercepter/voir des données des clients.




Pourquoi? Avec un chiffrement de bout en bout, comment feraient-ils? Bon ok, mis à part de l’espionnage directement sur le terminal avant chiffrement, mais le reste de la chaîne doit être safe, non?



(À condition bien sûr qu’il n’y ait pas d’entourloupe sur qui possède les clés)


Le chiffrement de bout en bout ça ne marche que si le serveur n’a pas à connaitre les données, ce qui est en réalité pas très courant.
Alan c’est une complémentaire santé, ils ont besoin de connaitre et traiter les données, donc d’accéder aux données déchiffrées. Ca se passe sur les infra d’Amazon, donc ça implique forcément de faire confiance à Amazon.
Il doit être possible de protéger avec quelque chose qui ressemble à du chiffrement de bout en bout certaines des données qu’ils manipulent (par exemple s’ils ont une copie de la CNI pour valider quelque chose, on pourrait imaginer un mécanisme qui fait qu’elle ne peut être vue que par le titulaire et la personne qui valide sans passer en clair sur les serveurs), mais pour tout ce qui est de la “donnée métier”, c’est pas crédible.



Le chiffrement dans le cloud c’est généralement du chiffrement du stockage, avec les clés sur les serveurs de traitement qui sont eux-mêmes aussi dans le cloud. Perso j’ai jamais été très convaincu: ça ne protège pas des failles applicatives, ça ne protège que partiellement de l’hébergeur…


Zerdligham

Le chiffrement de bout en bout ça ne marche que si le serveur n’a pas à connaitre les données, ce qui est en réalité pas très courant.
Alan c’est une complémentaire santé, ils ont besoin de connaitre et traiter les données, donc d’accéder aux données déchiffrées. Ca se passe sur les infra d’Amazon, donc ça implique forcément de faire confiance à Amazon.
Il doit être possible de protéger avec quelque chose qui ressemble à du chiffrement de bout en bout certaines des données qu’ils manipulent (par exemple s’ils ont une copie de la CNI pour valider quelque chose, on pourrait imaginer un mécanisme qui fait qu’elle ne peut être vue que par le titulaire et la personne qui valide sans passer en clair sur les serveurs), mais pour tout ce qui est de la “donnée métier”, c’est pas crédible.



Le chiffrement dans le cloud c’est généralement du chiffrement du stockage, avec les clés sur les serveurs de traitement qui sont eux-mêmes aussi dans le cloud. Perso j’ai jamais été très convaincu: ça ne protège pas des failles applicatives, ça ne protège que partiellement de l’hébergeur…


Merci pour la réponse :chinois:
C’est logique, je pensais juste au stockage, pas au reste.


La question c’est aussi de qui / quoi souhaite-t-on se protéger.



AWS c’est aussi des services de sécurité relativement faciles à utiliser même pour une entreprise de taille modeste comme Alan. Niveaux services managés, les hébergeurs européens sont très en retard sur les très gros que sont AWS, Azure et GCP. Une société de la taille d’Alan n’aurait absolument pas les moyens de monter sur une infra OVH le même type de services que ce qu’AWS leur offre.



Si on a peur des pirates motivés par l’argent, AWS est certainement un très bon choix. Si on a peur de la NSA peut-être moins.



zongap a dit:


Pour le cas de Microsoft (Azure, Exchange, Sharepoint et maintenant Teams) il est possible de gérer ses propres clés avec son propre HSM (exemple : Thales Luna – ex Gemalto), qui sont validés au plus haut niveau par l’état français.




Précision, seul les Atos Proteccio bénéficient d’une qualification ANSSI. Les HSM Luna sont certifiés, pas qualifiés.



quand on choisit un hébergeur, il y a aussi un certain nombre de choses qu’on ne peut pas contrôler, comme la transparence dont fait preuve l’hébergeur, les lois de son pays d’origine




Vivement 2013, qu’un lanceur d’alerte nous informe sur les programmes de surveillance états-unien, et sur ces lois qui imposent aux hébergeurs de livrer leurs données aux services de renseignements (Patriot Act, Cloud Act, …) !


:dix:


Toutes nos données sur AWS sont chiffrées au repos. ça veut bien dire qu’ils déchiffrent les données à un moment donné pour des traitements (recherche, agrégation), pas seulement un téléchargement. Si leurs serveurs sont aussi sur AWS, les clés sont sur les serveurs, donc on empêche que des personnes qui y accéderaient éventuellement de manière non autorisée (y compris l'hébergeur lui-même) c’est probablement faux (même avec chiffrement du disque, il faudrait un autre serveur ailleurs avec les clés pour le démarrage).



Zerdligham a dit:



Le chiffrement dans le cloud c’est généralement du chiffrement du stockage, avec les clés sur les serveurs de traitement qui sont eux-mêmes aussi dans le cloud. Perso j’ai jamais été très convaincu: ça ne protège pas des failles applicatives, ça ne protège que partiellement de l’hébergeur…




Je partage ton point de vue. La seule utilité au chiffrement du seul stockage, c’est qu’on ne peut rien faire à partir des seuls disques physiques (qu’on les vole ou qu’on les trouve dans une poubelle).


La sécurité ultime n’existe pas, de toutes façons, le but étant de minimiser les risques.
Déjà, je suppose que quand on construit ce genre d’archi, on ne duplique pas les clés sur tous les serveurs de traitement? On doit avoir un “garant” qui sert les clés aux autres, et celui-ci, j’imagine, sera plus sécurisé / moins exposé? Histoire qu’un serveur compromis ne suffise pas à tout compromettre.


jotak

La sécurité ultime n’existe pas, de toutes façons, le but étant de minimiser les risques.
Déjà, je suppose que quand on construit ce genre d’archi, on ne duplique pas les clés sur tous les serveurs de traitement? On doit avoir un “garant” qui sert les clés aux autres, et celui-ci, j’imagine, sera plus sécurisé / moins exposé? Histoire qu’un serveur compromis ne suffise pas à tout compromettre.


Il y a plusieurs façons de chiffrer le contenu des disques, déjà :




  1. par le contrôleur ou le NAS/SAN : pour le serveur les données sont accédées normalement (il les lit et les écrit non chiffrées), et c’est le contrôleur ou le SAN qui chiffre en écrivant ; avantage : la clé est sur le SAN, la transparence pour une appli et disque illisible tout seul ; inconvénient ; accéder aux montages/périphériques sur le SAN/NAS permet de lire les données

  2. le chiffrement est au niveau du serveur (et de chaque serveur qui veut chiffrer ses données) : chaque serveur applicatif doit avoir une clé

  3. autre chose ?



C’est comme les gens qui veulent que la base de données chiffre ses données ; mais quand tu te connectes au serveur SQL, tu fais un “SELECT” et tu as les données, et c’est souvent là que sont les piratages (ou via injections SQL).



Si l’hébergement des données dans le Cloud doit servir aussi à des traitement sur le Cloud, les clefs devront également y être. Si c’est seulement du stockage pur, ça va, la clef peut rester sur les serveurs locaux.


J’aime bien AWS, mais si ils ne précisent pas qui détient la clé maitre, certainement, ils sont full AWS pour la gestion des clés, et ça s’est moche.



En plus, AWS ne garantie pas la gestion des clés dans le cas où la clé maitre n’est pas gérée chez eux. (bah ouai, … faut leur faire confiance jusqu’au bout).



Pour le coup, utilise AWS avec une gestion PKI en restant maitre de ses clés/HSM c’est pas déconnant. Mais pas certain que tout le monde s’amuse a gérer sa clé et les dérivées multiples derrière.



Pour le coup, c’est un taf a plein temps :) (se remémore des souvenirs de clés pour son ancien employeur…)


Fermer