Où nous hébergeons les données de nos membres et pourquoi

Pour lire une mise à jour sur l'hébergement de nos applications vous pouvez lire cet article.

Depuis le début d'Alan, nous avons choisi d'être hébergés chez Amazon Web Services (certifié hébergeur de données de santé). Pourquoi, comment, nous vous expliquons tout.

Une baie de serveurs.Photo : Taylor Vick (Unsplash)

Aujourd’hui, la sécurité des données personnelles est un sujet de préoccupation de tous les utilisateurs de services sur internet. Chez Alan, nous avons conscience que c’est encore plus le cas en matière de santé.

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.

Qu’est ce que l’hébergement de données, quels critères ont guidé notre choix, et comment on s’engage à toujours faire le meilleur choix pour la sécurité et la qualité du service ? On vous en dit un peu plus dans cet article.

Chez Alan, on collecte les données personnelles de nos membres pour leur fournir nos services d’assurances ainsi que d’autres services de santé qu’on propose. Les données qu’on collecte et le traitement qu’on en fait sont décrits dans notre politique de confidentialité.

Chez Alan, on parle de la santé de nos membres, et les données qu’on traite peuvent révéler des détails intimes de leur vie privée. C’est pourquoi on apporte beaucoup de soin aux choix qu’on fait concernant ces données. Et on trouve normal d’être transparents en expliquant où elles sont hébergées et pourquoi.

Quand on utilise un service numérique, on communique avec des machines (des « serveurs ») qui servent notamment à stocker l’information utilisée pour fournir le service.

Ces serveurs sont soit gérés directement par l’entreprise (le self-hosting), soit gérés par une entreprise spécialisée, qu’on appelle un hébergeur, qui possède l’espace de stockage et le met à disposition de ses clients à distance par internet (c’est ce qu’on appelle le cloud).

L’hébergeur construit, entretient, et gère les serveurs, mais n’a pas le droit d’accéder aux données qui y sont stockées, c’est inscrit dans le contrat qu’on a avec lui. Il existe quelques exceptions, notamment dans certains cas encadrés par la loi (notamment en cas de mandat ou d’injonction valable d’un tribunal), auxquelles l’hébergeur ne peut pas se soustraire.

Plusieurs acteurs proposent des hébergements de qualité.

Il y a les grands acteurs américains, comme AWS (« Amazon Web Services »), GCP (« Google Cloud Platform ») et Azure (le cloud de Microsoft) qui proposent des solutions. Ou encore Oracle (que TikTok a été « forcé » de choisir).

Il y a aussi les hébergeurs français OVHCloud (pour « On Vous Héberge ») et Scaleway (construit à l’origine par Iliad / Free).

Il y a enfin pléthore de petits hébergeurs. Leur offre de services est plus limitée et ils ne proposent pas forcément de garanties à la hauteur des besoins d’une entreprise comme Alan en termes de fiabilité et de flexibilité. Par exemple, un impératif pour Alan est de pouvoir solliciter des serveurs supplémentaires en temps réel en fonction de l’ajout d’utilisateurs et de services. Ces hébergeurs plus petits peuvent forcer l’entreprise (nous) à s’engager sur un nombre fixe de serveurs sur plusieurs années car ils doivent anticiper et amortir leurs coûts. Ce n’est pas compatible avec le rythme de croissance d’Alan.

Chez Alan, on héberge les données de nos membres chez AWS, à Francfort. On utilise la plateforme Heroku Private Spaces pour faire le lien entre ces serveurs et nos applications (voir plus bas).

AWS, c’est Amazon Web Services, le premier hébergeur mondial dans le cloud (environ 35% de parts de marché).

Créé en 2006, l’hébergeur accueille des services français et étrangers, tels que Engie ou Airbnb, y compris dans le domaine de la santé, à l’instar de Babylon Health ou Siemens.

Les serveurs que nous utilisons sont à Francfort (dans les datacenters d’AWS).

Le produit Private Spaces de Heroku nous permet de faire tourner nos applications sur des serveurs AWS dans un cloud privé (dans le datacenter de Francfort) en déléguant à Heroku la gestion des serveurs (leur disponibilité, la mise à jour de leur système d’exploitation, les patchs de sécurité, etc.) et de bénéficier d’outils pour déployer facilement et très rapidement (plusieurs fois par jour) nos applications.

Grâce à Heroku, nos ingénieurs gagnent du temps pour se focaliser sur la création de produits pour nos utilisateurs.

On vous a fait un schéma pour mieux vous expliquer :

Et chose importante, Heroku ne stocke aucune donnée utilisateur (elles sont toutes hébergées directement par AWS, pour bénéficier de leur certification HDS).

Heroku est une filiale de Salesforce, entreprise américaine. Il y a des équivalents européens à Heroku, comme Platform.sh ou Clever Cloud, plus récents donc parfois moins matures. AWS a aussi sa propre offre concurrente (ElasticBeanstalk).

Comment en est-on arrivés à choisir AWS pour héberger les données qu’on traite ?

Tout d’abord, nous avons écarté la possibilité qu’Alan soit son propre hébergeur en choisissant de ne pas gérer nos serveurs nous-mêmes. Nous préférons nous concentrer sur notre métier : construire des produits d’assurance et de santé. Nous n’avons pas (encore) la taille suffisante pour que ce soit intéressant de construire notre propre infrastructure, ni pour mettre en place des mesures de sécurité à la hauteur des menaces qui pèsent sur les données.

Les cybercriminels sont très bien armés aujourd’hui, et il est de plus en plus difficile de réagir à temps pour éviter des failles. Nous préférons que ce soit des professionnels de l’infrastructure qui s’en chargent. C’est la même logique qui fait qu’on met notre argent à la banque plutôt que de le garder sous notre matelas: on préfère savoir nos données en lieu sûr.

En résumé, la combinaison AWS + Heroku que nous avons choisie nous permet d’avoir accès à des niveaux de sécurité et de qualité de service sur lesquels on peut asseoir l’expérience Alan de manière fiable, en confiance, et sur la durée.

Historiquement, nous avons lancé notre site en 2016 sur Heroku, pour la simplicité de gestion. Heroku hébergeait alors nos données (nous n’avions pas de données de santé ou assimilées à l’époque). Nous avons remis notre décision en question en 2019.

Après délibération sur les différents enjeux, nous avons décidé d’utiliser Heroku Private Spaces tout en migrant les données directement sur AWS (pour bénéficier de leur certification HDS).

Notre choix s’est fait sur la base des critères suivants:

De plus, toutes les opérations sont effectuées sur un « Cloud privé virtuel » qui fait que les bases de données ne sont pas directement accessibles depuis internet : AWS Virtual Private Cloud n'est pas connecté à internet, c’est Heroku qui l'est, et Heroku est connecté directement à AWS en “local” (voir le schéma).

Enfin, d’autres critères secondaires :

AWS (comme d’autres hébergeurs tels qu’OVH ou Scaleway d’ailleurs), est certifié « hébergeur de données de santé » auprès de l’Agence du Numérique en Santé (rattachée au ministère de la santé).

Techniquement, Alan, en tant que complémentaire santé, pourrait héberger les données utilisées dans le cadre de ses services d’assurance sur des serveurs autres que chez un hébergeur certifié HDS (lire la Question 2 dans ces réponses du ministère de la santé). Comme nous considérons que les données liées à l’assurance sont déjà sensibles (même si elles ne constituent pas techniquement des données de santé au sens de la loi) et que nous développons de plus en plus de services allant au-delà de l’assurance (notamment de la prévention santé), nous nous sommes imposés cette contrainte pour l’ensemble des données de nos membres que nous gérons directement.

Pour mériter le droit d’héberger des données de santé venant de France, AWS s’est soumis aux exigences de la procédure de certification « hébergeur de données de santé ». Ce sont les mêmes exigences qui s’appliquent à tous les autres hébergeurs certifiés à qui nous pourrions confier les données, qu’ils soient français, américains, ou établis dans un autre pays.

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 (ce qui est interdit par AWS hors salariés spécialement autorisés, par exemple pour l’entretien des serveurs) ne pourrait pas lire les données.

En plus de cela, nous mettons en place des mesures renforcées sur nos services les plus sensibles. Par exemple, pour notre chat médical, qui permet de parler à un médecin sur l’app Alan à tout moment de la journée, les discussions que vous avez avec les médecins sont chiffrées “de bout en bout” – du médecin à votre téléphone. Cela garantit que ni Alan, ni AWS ne sont en mesure de lire vos conversations avec le médecin.

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. Ces choses ne sont pas spécifiques aux prestataires d’hébergement américains.

In fine, mis dans la balance face à tous les autres facteurs (sécurité, fiabilité, services, flexibilité, etc.), AWS ressort vraiment comme l’hébergeur le plus proportionné à nos besoins, et on pense pouvoir offrir la meilleure qualité de services en faisant ce choix.

En tant que client d’un hébergeur, on peut faire toutes les vérifications que l’on veut et lire les contrats que nous proposent les hébergeurs, mais au final on ne peut se reposer que sur les informations qu’ils nous fournissent. La certification qu’ils ont obtenue pour être HDS a été validée par un auditeur (Bureau Veritas) qui lui-même a été validé par l’état français (via le COFRAC).

Peu d’hébergeurs offrent la possibilité d’auditer les centres d’hébergement aujourd’hui, à cause des soucis opérationnels et de confidentialité que cela créerait si tous les clients souhaitaient faire une visite en personne.

De la même manière, on n’a que peu de visibilité sur les endroits par où transitent les données qu’on confie à AWS, ou sur lesquels de leurs salariés ont accès à nos serveurs pour en faire la maintenance. Tout ce qu’on sait, c’est que les contrats qui nous lient à AWS prévoient ces cas et qu’ils risqueraient d’engager leur réputation (et leur responsabilité) si cela se révélait mensonger, en plus de remettre en cause leur certification.

Malheureusement, le manque de transparence n’est pas une spécificité américaine, et c’est le cas de tous les hébergeurs de taille suffisante pour répondre à nos besoins. Les conditions générales d’AWS sont plutôt plus détaillées que la moyenne au sujet, par exemple, des droits d’accès, de la localisation des données, et du respect du RGPD. Celles d’OVH le sont également. Certains hébergeurs, notamment français, ne détaillent pas ces points.

Quand des données sont stockées sur des serveurs situés dans un pays, ou par un hébergeur de ce pays, on dépend de l’hébergeur pour garantir que personne n’y a accès. Or, les lois de ce pays peuvent s’appliquer et donner le droit aux autorités d’accéder, sous certaines conditions, aux données de leurs clients.

On peut aussi craindre que l’hébergeur lui-même accède aux données. Même si les conditions générales de tous les services d’hébergement couvrent ce cas, un client peut être particulièrement sensible à ce risque quand il exerce une activité concurrente à celle de l’hébergeur, par exemple.

Amazon, la maison-mère d’AWS, est une entreprise américaine. Cela veut dire qu’elle est soumise aux lois américaines, notamment celles qui peuvent permettre de demander à un juge l’accès aux données hébergées au titre de la sécurité nationale (comme le fameux CLOUD Act).

Amazon publie volontairement tous les semestres un « rapport de transparence » recensant les demandes d’accès aux données de leurs clients qu’ils reçoivent à ce titre. Leur dernier rapport (juin 2020) montre qu’Amazon a répondu favorablement à seulement 14 demandes sur 177 au total (chiffre total des demandes “non-U.S.” de janvier à juin 2020, qui inclut les demandes sous CLOUD Act). Ils s’engagent également à faire une revue détaillée et critique de toute demande d’accès des tribunaux, et à employer des moyens juridiques pour y résister et protéger les données de leur clients.

On sait malgré tout qu’il ne faut pas faire confiance aveuglément : avec le chiffrement des données au repos et la localisation au sein de l’UE, nous mettons en œuvre des mesures supplémentaires pour freiner la divulgation de données si Amazon faisait droit à une telle demande à l’encontre d’un des membres d’Alan.

En résumé, 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. .

Si nous avions choisi un hébergeur français, le problème serait finalement assez similaire : les tribunaux français pourraient aussi faire droit à des demandes d’accès à des données sur nos serveurs. 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. Mais globalement, si l’accès aux serveurs de notre hébergeur était demandé de manière valable et incontestable par un juge français, on ne pourrait pas y résister non plus.

Côté américain, les effets du CLOUD Act pourraient s’étendre à un hébergeur français à portée internationale aussi, dans la mesure où son territoire d’activité s’étend aux Etats-Unis. Là encore, le fait que les données soient chiffrées serait la mesure la plus protectrice que nous pourrions mettre en œuvre pour éviter la divulgation des données de nos membres.

Nous souhaitons utiliser les outils qui protègent le mieux nos membres, tout en leur permettant de pouvoir profiter du meilleur service de la part d’Alan.

Pour nous assurer d’être toujours à jour, nous nous engageons à sonder les solutions d’hébergement proposées sur le marché tous les 3 ans. Notre prochaine échéance d’appel d’offres sera fin 2021.

Les critères mentionnés ci-dessus feront partie de ceux que nous utiliserons pour évaluer les solutions concurrentes d’AWS à ce moment-là. Entre temps, nous serions bien entendu prêts à réévaluer notre choix si cela s’avérait nécessaire (par exemple, si la réglementation changeait).

Non. Les données qui sont dans une région ne sortent pas de cette région. AWS ne pourrait le faire que si on demandait explicitement de faire un transfert des données (ce qu’on ne fera pas).

Non, pas de manière directe. Il faudrait que le gouvernement saisissent un juge américain, qui, après contrôle de la justification et de la proportionnalité de la demande par rapport aux critères prévus par la loi, ordonne l’accès aux données. Ensuite, il faudrait qu’AWS coopère en répondant favorablement à la demande du juge. Ils sont également soumis à des règles européennes puisqu’ils proposent leurs services sur notre territoire, ce qui peut mener à des contradictions. Ce sont des situations complexes que les juristes d’Amazon prennent au sérieux en contestant les demandes d’accès qui leur proviennent quand il y a des arguments le permettant. Leur rapport de transparence annuel fournit quelques détails supplémentaires à ce sujet.

AWS n’est pas certifié sur l’activité 5 de la certification d’hébergement de données de santé. Cette activité est surnommée « administration et exploitation ». En effet, ce n’est pas AWS qui gère les données qui sont mises sur leurs serveurs, c’est Alan.

Eh bien, c’était prévu, jusqu’à cette décision (qui date d’il y a 18 mois) : le ministère de la santé veut sortir cette activité du périmètre de la certification.

Depuis… nous attendons la clarification promise. On ne leur en veut pas, il y a une pandémie qui a sévi entre-temps.

Aussi, le ministère chargé de la Santé a décidé de procéder à la modification du décret HDS pour retirer « l’activité 5 : administration et exploitation » du périmètre des activités soumises à certification. Cette activité étant importante dans la chaîne de sécurité des données de santé, le ministère chargé de la Santé va concomitamment engager des travaux pour étudier l’opportunité et les modalités de son encadrement.

Pendant ce temps, nous ne restons pas inactifs, nous travaillons en permanence à l’amélioration de notre posture en matière de sécurité. Si le ministère décide qu’en fin de compte nous devons être certifiés, nous serons prêts. Dans tous les cas, nous aurons fait, au-delà de nos obligations légales, tout ce qui nous paraît important pour protéger vos données.