L'informatique de santé exige une sécurité renforcée en raison des enjeux juridiques et de la protection de la vie privée. Des règles strictes régissent l'externalisation des données de santé, dont l'hébergement doit être réalisé par des hébergeurs agréés, tandis que des menaces réelles, comme le piratage de dispositifs médicaux, nécessitent des mesures techniques et organisationnelles robustes. La sécurité ne doit pas seulement être une question de protection externe, mais également de gestion intérieure pour minimiser les risques de compromission des données.

1. La sécurité
en informatique de santé
Petite incursion dans la sécurisation en
informatique de santé
Tout d’abord, quelques mots pour
me présenter: je travaille depuis
2000, chez Atos Group activité
Multimédia, devenu depuis Atos
Origin Multimédia, Atos Worldline
puis Worldline au gré des fusions de
la maison mère. J’y ai été ingénieur
responsable d’application pour des
clients média, puis responsable
d’une équipe transverse de type
R&D dédiée aux marchés médias,
télécom et utilities. Je travaille
maintenant depuis deux ans chez
SANTEOS, l’unité informatique de
Santé de Worldline, à Seclin. J’y ai
une triple casquette d’ingénieur
avant-vente, consultant fonctionnel
et architecte technique. A ce titre,
j’ai découvert le monde de
l’informatique de santé et ses
contraintes de sécurité. Je vous en
propose un rapide survol assez
personnel, qui ne prétend pas être
exhaustif.
L’informatique de santé nécessite
une sécurisation particulière pour
des raisons juridiques, de vie
privé, vitales.
En France, l’externalisation du
traitement informatique de données
de santé à caractère personnel est
soumise à des règles particulières.
L’hébergement doit être effectué
chez un hébergeur agréé de santéi
.
Cela correspond à certaines
obligations, telles que la définition
précise des données de santé
manipulées, la nature précise des
personnes y accédant,
l’authentification forte des accès, la
traçabilité des accès externes et
internes, un audit régulier des
risques de sécuritéii
, la présence
d’un médecin de l’hébergeur garant
notamment des droits des patients
et un chiffrement adéquat des
données. De fait, parler d’hébergeur
agréé de données de santé est un
abus de langage: l’agrément est
donné à un hébergeur dans un
cadre précisant le type de données,
l’accès à ces données et la finalité
de traitement. Ce qui explique qu’il y
ait 57 agréments pour 46
hébergeurs.iii
L’informatique de santé doit
particulièrement protéger la vie
privée. On n’imagine pas nos
données de santé communiquées à
des assureurs ou à un futur
employeur. Et pourtant. Les vingt
applications mobiles de santé
communiquent des informations à
plus de soixante-dix sociétésiv
. Et
encore, il s’agit des données
communiquées directement par
l’application mobile, sans compter
les données échangées directement
de serveur à serveur. Cela concerne
aussi des simples applications
sportives comme du suivi de course
à pieds. Cependant, méfiez-vous :
on pourrait se demander pourquoi
vous vous êtes arrêtés brutalement
de courir pendant plusieurs moisv
.
Sécuriser l’informatique de santé,
c’est aussi répondre à un besoin
vital. Ceux qui connaissent la série
TV Homelandvi
savent que William
Walden, le vice-président des USA,
est tué par le piratage de son
pacemaker. Ce n’est
malheureusement pas de la
science-fiction. Barnaby Jack a
démontré qu’il est possible de
modifier à distance le réglage d’un
pacemaker avec un équipement
très réduitvii
infligeant des
décharges de plusieurs centaines
de volts. Il avait démontré par le
passé qu’il était possible de modifier
le réglage d’une pompe à insuline à
cent mètres de distance, tuant ainsi
la cible en quelques minutes. Enfin,
les serveurs hébergeant les mises à
jour des firmwares de la plupart des
dispositifs médicaux sont
insuffisamment protégésviii
.
Imaginez la conséquence d’un
firmware modifié par un pirate.
Sécuriser le stockage et l’accès à
ces informations nécessite plus
que des mesures techniques
Évidemment, il faut un minimum de
bon sens technique, qui n’est
malheureusement pas toujours en
action. Il faut a minima chiffrer les
informations stockées localement
en cache sur un mobile, chiffrer bien
sûr mais aussi signer les échanges
entre client et serveur. Il ne faut pas
supposer que l’humain qui utilise
l’application est bien intentionné: il
peut s’agir d’un humain

2. malintentionné, ou d’un programme
pirate qui a pris le contrôle du
navigateur web ou du clavier. Il faut
chiffrer les données stockées sur le
serveur, sans pour autant que cela
ralentisse ou rende impossible
certaines fonctionnalités. Ainsi, le
chiffrement des données patient ne
doit pas rendre impossible la
recherche de patient par nom. Plus
difficile: il faudrait s’assurer que
l’application web, mobile ou desktop
qui échange avec le serveur est
légitime et qu’il ne s’agit pas d’une
application maligne tierce.
À cela s’ajoute la nécessité d’audits
externes et internes réguliers afin
de vérifier par exemple que les
traces d’accès ne sont ni perdues,
ni modifiables après coup ou que
les logs serveurs ne contiennent
aucune information sensible.
Enfin, il faut prendre conscience
qu’on ne vit pas dans un monde de
bisounours et que l’ennemi peut
être à l’intérieur. Ainsi, chez google,
seuls les quelques centaines de
Site Reliability Engineers peuvent
accéder en clair aux mails et aux
données des centaines de millions
d’utilisateurs des services google.
Mais pour des données de santé,
quelques centaines, c’est encore
bien trop: seule une personne peut
y accéder : le médecin de
l’hébergeur. Il est donc nécessaire
d’une part d’utiliser des HSMix
pour
chiffrement ou stockage des clés et
d'autre part mettre en place une
véritable séparation des pouvoirs
entre développeurs, administrateurs
et exploitants. Il faut aller au-delà de
l’état de l’art technique et arriver à
l’état de l’art processus afin que le
vol de données nécessite la
corruption d’un grand nombre de
personnes et pas d’une seule.
En synthèse, la sécurité, ce n’est
plus construire une forteresse
qui permet de se protéger de
l’extérieur, mais un avion qui
reste en l’air quelles que soient
les variations extérieures et
intérieures, et même si le pilote
lui donne l’ordre de se crasher.
Cela grâce à des mécanismes
techniques (alarme en cas de perte
d'altitude) et humains (présence
d'un navigateur, d'un co-pilote qui
prend la relève si le pilote devient
fou et veut crasher l'avion).
Ludovic TANT, promotion ISEN
2000

4. i http://esante.gouv.fr/services/referentiels/securite/hebergement-faq
ii Le Référentiel Général de Sécurité v1.0 recommande l'utilisation de la méthodologie EBIOS qui est conforme à la norme ISO 27005.
iii http://esante.gouv.fr/services/referentiels/securite/hebergeurs-agrees
iv https://www.evidon.com/blog/healthy-data-set
v À titre personnel, évitez d’utiliser une même identité quand vous utilisez des applications mobiles de santé ou intervenez sur des forums
de santé.
vi http://www.imdb.com/title/tt1796960
vii http://bigbrowser.blog.lemonde.fr/2012/10/24/coeur-a-prendre-un-hacker-parvient-a-pirater-un-pacemaker/
viii http://www.larecherche.fr/actualite/technologie/securite-informatique-proteger-pacemakers-fil-virus-01-01-2010-88444
ix Un Hardware Security Module est un matériel permettant de créer, stocker et contrôler l'usage de clés cryptographiques avec un niveau
d’inviolabilté garanti logiciellement et matériellement. (http://fr.wikipedia.org/wiki/Hardware_Security_Module)