Pourquoi la sécurité du cloud dans le secteur de la santé ne peut-elle pas être traitée comme la sécurité standard du cloud d’entreprise ?

En quoi la sécurité des données de santé diffère-t-elle de la sécurité standard des données d’entreprise ?

La sécurité des données de santé est soumise à un ensemble de considérations de sécurité qui apparaissent rarement dans les débats habituels sur la confidentialité et la sécurité au sein des entreprises. Une multitude d’exigences réglementaires strictes, des données à caractère personnel qui ne peuvent être ni dupliquées ni remplacées, ainsi que la santé du patient en jeu : tous ces éléments expliquent pourquoi les obligations en matière de protection des données de santé ne s’inscrivent dans aucun autre cadre de sécurité générique du cloud.

En quoi les informations de santé protégées (PHI) sont-elles particulièrement sensibles ?

Les informations de santé protégées (PHI) présentent un niveau de sensibilité différent de celui du reste des données d’entreprise d’une organisation. Le ministère américain de la Santé et des Services sociaux (DHHS) définit les PHI comme des informations de santé permettant d’identifier une personne et qui concernent son état de santé physique ou mentale passé, présent ou futur, la prestation de soins de santé ou le paiement de ces soins.

Une carte de crédit peut être invalidée dès que l’intrusion est découverte, puis remplacée par une nouvelle carte. Ce n’est pas le cas pour les maladies, les facteurs génétiques ou les diagnostics de santé mentale : ces informations sont véritablement permanentes.

Chaque fois que des PHI sont compromises, les risques liés à ces violations vont bien au-delà du simple vol d’identité. Les dossiers médicaux peuvent être utilisés pour exclure des patients de la couverture d’assurance, nuire à leurs opportunités professionnelles et commettre des fraudes ciblées à l’encontre des personnes âgées et handicapées. La confidentialité des PHI est d’autant plus cruciale que l’éventail des informations pouvant être qualifiées de PHI est très large.

Voici les exemples les plus marquants :

• Nom complet et coordonnées liés à une pathologie ou à un traitement
• Dates de naissance, d’admission, de sortie ou de décès
• Données géographiques à une échelle inférieure à celle d’un État
• Identifiants biométriques tels que les empreintes digitales ou vocales
• Tout autre numéro ou code d’identification unique associé aux soins

Pourquoi la confidentialité, l’intégrité et la disponibilité revêtent-elles une importance différente dans le secteur de la santé ?

La confidentialité, l’intégrité et la disponibilité (parfois appelées la « triade CIA ») s’appliquent à tous les protocoles de sécurité. Cependant, les environnements cloud du secteur de la santé ont tendance à considérer ces piliers différemment des déploiements d’entreprise habituels.

Par exemple, la disponibilité a des conséquences cliniques importantes, ne serait-ce qu’en raison de simples pannes qui n’ont pas d’équivalent ailleurs dans le secteur. La perte de service ne se résume pas à une simple perte de productivité dans les environnements de santé : elle empêche la passation de commandes de médicaments, bloque l’accès aux résultats d’imagerie ou empêche les ambulanciers de consulter le dossier médical du patient.

Vous trouverez ci-dessous des informations plus générales sur les trois piliers susmentionnés :

En quoi la nécessité d’une conservation à long terme et d’une traçabilité modifie-t-elle les exigences en matière de sécurité ?

Les dossiers médicaux et la documentation de sécurité associée doivent être conservés bien plus longtemps que ne le prévoient les calendriers de conservation habituels des données d’entreprise.

HIPAA (Health Insurance Portability and Accountability Act) stipule que les entités concernées doivent conserver leurs politiques, leurs procédures et les documents associés pendant 6 ans à compter de leur date de création ou de leur dernière date d’entrée en vigueur. Ce délai peut même être plus long dans certains États pour certains types de documents spécifiques.

Les contrôles de sécurité dans le cloud qui prennent en charge et protègent ces données doivent également être maintenus pendant cette même période. Ces contrôles doivent être applicables, vérifiables et restaurables pendant toute la durée de ces six ans.

Ces exigences influencent la conception globale de l’architecture de sécurité du cloud dans le secteur de la santé. La gestion des clés de chiffrement, les journaux d’accès et l’intégrité des sauvegardes : aucun de ces éléments ne peut être considéré comme une simple préoccupation opérationnelle à court terme. Une piste d’audit permettant d’enquêter sur une faille de sécurité, ou une enquête réglementaire dans cinq ans, dépendra des contrôles mis en œuvre et exploités aujourd’hui.

En quoi la conformité et les réglementations du secteur de la santé modifient-elles les exigences en matière de sécurité du cloud ?

Les obligations réglementaires dans le secteur de la santé ne constituent pas simplement un cadre supplémentaire pour la sécurité du cloud. Ces obligations impliquent également de redéfinir les contrôles requis, les responsables de leur mise en œuvre et les conséquences en cas de défaillance. La loi HIPAA, le RGPD, la loi HITECH et une liste croissante de réglementations au niveau des États imposent chacune leurs propres exigences (techniques et contractuelles) aux environnements cloud, auxquelles les cadres de conformité d’entreprise standard n’ont pas été conçus pour répondre.

Quelles obligations spécifiques la loi HIPAA, le RGPD et d’autres réglementations du secteur de la santé imposent-elles à l’utilisation du cloud ?

Chaque grand cadre réglementaire a sa propre approche en matière de sécurité du cloud :

• La loi HIPAA couvre les informations médicales protégées (PHI) stockées au sein des entités concernées basées aux États-Unis et de leurs partenaires commerciaux ; cela inclut également les solutions cloud qui stockent, traitent et transmettent des données sensibles sur les patients pour leur compte.
• Le RGPD s’applique aux situations impliquant les données de santé des résidents de l’UE, même si l’infrastructure de stockage dans le cloud est située ailleurs.
• La loi HITECH étend et renforce les capacités d’application de la loi HIPAA, en augmentant les niveaux de sanctions tout en élargissant les exigences en matière de notification obligatoire des violations.

Les obligations imposées par chaque cadre réglementaire à l’environnement cloud diffèrent considérablement les unes des autres en termes de portée, de mécanisme et de conséquences :

En quoi les délais et la portée des notifications de violation diffèrent-ils pour les établissements de santé ?

Les notifications de violation de données concernant les informations de santé sont également beaucoup plus contraignantes (et les enjeux y sont plus importants) que celles en vigueur dans la plupart des secteurs d’activité. Les délais sont fixes, les destinataires des notifications sont variés et les seuils déclenchant les différentes obligations de notification sont très précis :

• 60 jours – délai maximal dont dispose une entité soumise à la loi HIPAA pour informer les personnes concernées après avoir découvert une violation
• 60 jours – ce même délai s’applique à la notification au ministère américain de la Santé et des Services sociaux (HHS)
• Plus de 500 personnes concernées – déclenche l’obligation d’informer les principaux médias de l’État ou de la juridiction concernée
• Moins de 500 personnes – les incidents peuvent être consignés et déclarés au HHS une fois par an, mais la notification individuelle reste obligatoire dans un délai de 60 jours
• RGPD – impose la notification à l’autorité de contrôle compétente dans les 72 heures suivant la prise de connaissance d’une violation, ainsi qu’aux personnes concernées sans retard injustifié lorsqu’un risque élevé est probable
• Lois des États – plusieurs États imposent des délais plus courts que les 60 jours prévus par la loi HIPAA ; certains exigent une notification dans un délai de 30 jours ou moins

Tous ces délais se compliquent encore davantage lorsqu’il s’agit d’environnements cloud. Chaque fois que des données de santé protégées (PHI) sont réparties entre différents fournisseurs de cloud, régions ou services tiers, l’identification de l’étendue totale d’une violation (pour une notification précise) prend beaucoup plus de temps que dans des environnements sur site bien délimités.

Pourquoi le secteur de la santé exige-t-il une validation plus stricte de la conformité du cloud ?

La principale faiblesse d’une validation rigoureuse de la conformité du cloud dans le secteur de la santé réside dans le fait qu’aucune certification de conformité existante ne correspond directement aux exigences réglementaires spécifiques à ce secteur, et que le fait de supposer une équivalence expose potentiellement votre organisation à un risque de lacune importante.

Par exemple, lorsqu’un fournisseur de services cloud dispose d’une certification SOC 2 Type II ou d’une accréditation ISO 27001, il respecte un niveau de sécurité de référence reconnu. Dans le même temps, aucun de ces référentiels n’a été conçu en tenant compte des informations médicales protégées (PHI), de la nécessité d’un accès clinique ou des mesures de protection techniques prévues par la loi HIPAA.

Une validation plus stricte dans les environnements cloud du secteur de la santé implique d’aller au-delà des simples examens de certification habituels. Cela comprend :

• Vérifier que les accords de partenariat commercial (BAA) reflètent fidèlement les pratiques réelles du fournisseur en matière de traitement des données
• S’assurer que les configurations des journaux d’audit respectent à la fois les exigences de conservation prévues par la loi HIPAA et celles au niveau de l’État
• Vérifier si les implémentations de chiffrement couvrent les informations médicales protégées (PHI) au repos, en transit et surtout pendant leur traitement

Pourquoi la sécurité des patients est-elle un enjeu de sécurité que les services informatiques négligent souvent ?

La plupart des secteurs subissent des pertes financières, des pertes de données ou une atteinte à leur réputation à la suite d’une faille de sécurité. Cependant, les problèmes de sécurité dans le secteur de la santé peuvent causer directement un préjudice au patient. Cette distinction à elle seule modifie fondamentalement la manière dont les décisions en matière de sécurité du cloud sont hiérarchisées et gérées.

Pourquoi les établissements de santé doivent-ils protéger les données des patients pour garantir la sécurité des soins ?

La disponibilité constante des données des patients est indispensable aux soins cliniques. Les répercussions de tout incident affectant un environnement cloud (une faille de sécurité, une panne, une corruption de données) se répercutent immédiatement bien au-delà du service informatique. Cela inclut :

• Des médecins privés d’accès aux antécédents médicamenteux
• Des infirmières ne pouvant plus accéder aux plans de soins en cours
• Des équipes d’urgence contraintes de prendre des décisions sans disposer du contexte diagnostique essentiel

La possibilité d’accéder aux données des patients, et le fait de disposer de données valides, ne constituent pas un indicateur de performance informatique, mais bien un indicateur de sécurité des patients. L’établissement de santé qui considère la sécurité du cloud comme un problème « administratif » fait courir un risque aux patients chaque fois que son système tombe en panne ou que le dossier médical d’un patient est modifié sans preuve.

Pourquoi les SLA de disponibilité doivent-ils être traités comme des contrôles des risques cliniques ?

La protection de la continuité d’activité est sans doute l’un des thèmes centraux d’un SLA d’entreprise classique. Dans les environnements cloud du secteur de la santé, ce document doit servir de contrôle des risques cliniques, en tenant compte des conséquences qu’une interruption de service aurait pour les patients.

Les garanties génériques de disponibilité ne permettent pas de répondre aux réalités opérationnelles des environnements cliniques. Un SLA régissant un déploiement cloud dans le secteur de la santé doit préciser :

• L’objectif de temps de reprise (RTO) aligné sur la criticité des flux de travail cliniques – l’accès au DME, par exemple, nécessite un RTO bien plus court que les systèmes de facturation
• L’objectif de point de reprise (RPO) suffisamment strict pour empêcher toute perte de données cliniquement significative entre la dernière sauvegarde et le moment de la défaillance
• Des fenêtres de maintenance planifiées programmées pendant les périodes de faible affluence, et non pendant les heures creuses standard
• Des procédures d’escalade qui acheminent les notifications d’interruption critiques directement à la direction des opérations cliniques, et pas uniquement au service informatique
• Un soutien en cas de temps d’arrêt – documentation ou outils permettant de mettre en œuvre des flux de travail cliniques manuels lorsque les systèmes cloud sont indisponibles

En quoi la collaboration entre les équipes chargées de la sûreté et de la sécurité doit-elle différer de celle des services informatiques et de sécurité classiques ?

Dans un environnement d’entreprise classique, l’équipe de sécurité définit les contrôles tandis que les équipes informatiques les mettent en œuvre. L’avis clinique est rarement pris en compte dans l’un ou l’autre de ces processus.

L’exploitation des technologies cloud dans le secteur de la santé exige un modèle opérationnel entièrement nouveau qui fait évoluer le rôle des responsables de la sécurité des patients, des équipes d’informatique clinique et des ingénieurs biomédicaux : ceux-ci ne sont plus de simples destinataires du processus décisionnel en matière de sécurité, mais deviennent des participants à part entière de ce même processus.

Ce modèle modifie également la manière dont le risque est appréhendé dans son ensemble. Une équipe de sécurité chargée de déterminer si une authentification supplémentaire est nécessaire aura besoin de l’avis clinique sur l’impact de contrôles renforcés sur le flux de travail des urgences. Un ingénieur biomédical chargé de gérer l’intégration de la connectivité doit avoir une vue d’ensemble de toute la segmentation du cloud qui influe sur la communication entre les appareils.

Les politiques de sécurité conçues sans prise en compte des aspects cliniques ont tendance à être contournées (non pas par négligence, mais parce qu’elles introduisent des frictions qui empêchent les soins directs de fonctionner correctement). Une collaboration adéquate entre la sûreté et la sécurité dans le contexte des soins de santé est une exigence structurée, et non une simple bonne pratique facultative.

En quoi la sécurité du cloud dans le secteur de la santé modifie-t-elle le modèle de responsabilité partagée ?

Le modèle de responsabilité partagée détaille généralement comment et où la charge de la sécurité est répartie entre le fournisseur de services cloud et le client. Cette répartition est bien plus complexe dans les environnements de soins de santé, car le simple fait d’héberger des informations de santé protégées (PHI) ne dégage pas l’organisation de sa responsabilité réglementaire. Par ailleurs, les mécanismes contractuels régissant cette responsabilité doivent être bien plus précis que ceux utilisés pour les contrats d’entreprise standard.

Quelles sont les responsabilités du fournisseur de services cloud par rapport à celles de l’établissement de santé ?

Le modèle classique de responsabilité partagée confie la sécurité de l’infrastructure au fournisseur, tandis que la sécurité des données incombe au client. Cette séparation est maintenue dans les environnements cloud du secteur de la santé, mais la portée des obligations de chacun s’étend considérablement lorsque des données de santé protégées (PHI) sont en jeu :

Pourquoi les hypothèses relatives aux mesures de protection gérées par les prestataires peuvent-elles exposer des données sensibles et des informations médicales protégées (PHI) ?

Contre toute attente, les attaques complexes ne constituent pas la principale source d’exposition des environnements cloud dans le secteur de la santé. Ce titre revient aux problèmes liés à un environnement mal configuré, construit sur la base d’hypothèses non vérifiées.

Il n’est pas rare que les établissements de santé partent du principe qu’un fournisseur de cloud conforme à la norme HIPAA garantit automatiquement que l’environnement déployé au sein de celui-ci est lui aussi conforme à cette norme par défaut. Cette hypothèse est erronée. Les fournisseurs peuvent certes proposer toutes les capacités techniques nécessaires pour garantir le respect des exigences de conformité, mais la configuration, la mise en œuvre et la vérification des résultats de ces capacités relèvent de la responsabilité du client.

Prenons le chiffrement au repos comme premier exemple. Il peut être activé par défaut sur le stockage principal, mais pas sur les niveaux de sauvegarde, les exportations de journaux ou les environnements de traitement temporaires où les données de santé protégées (PHI) transitent au cours des workflows d’analyse. La journalisation d’audit peut être activée par défaut, mais pas avec le niveau de granularité requis. Les compartiments de stockage d’objets contenant des données de santé protégées (PHI) ont pu être créés avec des politiques d’accès assouplies lors d’une migration et n’ont jamais été renforcées par la suite.

Chacune de ces lacunes serait pratiquement invisible lors des opérations courantes, mais ressortirait considérablement lors d’un audit réglementaire ou d’une enquête sur une violation de données.

Quelles mesures de sécurité les contrats et les SLA doivent-ils inclure pour les environnements de santé dans le cloud ?

Un accord de partenariat commercial (BAA) signé constitue l’exigence contractuelle minimale pour tout environnement cloud interagissant avec des PHI – et même dans ce cas, le BAA à lui seul ne suffit pas. Les contrats de cloud de santé doivent pouvoir répondre à des obligations de sécurité allant bien au-delà des conditions commerciales standard :

• Champ d’application du BAA et couverture des sous-traitants – l’accord doit nommer explicitement ou couvrir de manière catégorique tous les sous-traitants susceptibles d’avoir accès aux PHI
• Droits d’audit – l’organisme de santé doit conserver le droit de mener ou de faire réaliser des évaluations de sécurité de l’environnement du prestataire
• Délais de notification des incidents – les contrats doivent prévoir des délais de notification du prestataire au client plus courts que le plafond de 60 jours fixé par la loi HIPAA, afin de laisser à l’établissement de santé le temps de remplir ses propres obligations de déclaration
• Propriété des clés de chiffrement – les accords doivent préciser si l’établissement de santé contrôle ses propres clés de chiffrement ou s’il s’appuie sur des clés gérées par le prestataire, ainsi que l’étendue des droits d’accès conservés par ce dernier
• Résidence et souveraineté des données – les contrats doivent préciser les limites géographiques applicables au stockage et au traitement des PHI, en particulier lorsque le RGPD ou des exigences de localisation des données au niveau des États s’appliquent
• Suppression vérifiée des données – les clauses de résiliation doivent exiger une confirmation écrite de la suppression des PHI de tous les niveaux de stockage, y compris les sauvegardes et les environnements de reprise après sinistre
• Engagements en matière de disponibilité et de délai de reprise (RTO) – les garanties de disponibilité doivent être adaptées au contexte clinique, et non génériques

En quoi l’interopérabilité et l’échange de données modifient-ils le modèle de menace ?

De par leur nature même, les environnements cloud du secteur de la santé ne peuvent pas être des systèmes fermés. Les obligations réglementaires, les exigences en matière de coordination des soins et les obligations d’accès des patients nécessitent toutes que les données puissent circuler – entre prestataires, patients, payeurs et applications tierces.

Cette nature ouverte ne constitue pas une faille de sécurité, mais une exigence de conception. Malheureusement, c’est précisément cette exigence qui contribue à l’expansion massive de la surface d’attaque dont les programmes de sécurité du secteur de la santé doivent tenir compte.

Pourquoi les API, les intégrations FHIR et la connectivité des dossiers médicaux électroniques augmentent-elles les risques de sécurité dans le cloud ?

La loi « 21st Century Cures Act », ainsi que les règles d’interopérabilité ultérieures du CMS, imposent aux organismes de santé de mettre à disposition les données des patients via des API FHIR (Fast Healthcare Interoperability Resources) normalisées. L’échange de données avec des tiers devient ainsi une obligation légale, et non plus un simple choix architectural.

Chaque point de terminaison d’API fournissant des informations de santé protégées (PHI) à un utilisateur autorisé peut également constituer un point d’entrée potentiel pour des utilisateurs non autorisés. La surface d’attaque créée par l’interopérabilité n’est pas fortuite, mais structurelle – et elle s’étend à chaque nouvelle intégration mise en place par les établissements de santé.

La connectivité avec les systèmes de DME ne fait qu’aggraver encore ce problème. Les plateformes de DME modernes s’intègrent régulièrement à des environnements d’analyse hébergés dans le cloud, à des portails d’engagement des patients, à des outils de santé publique et à des systèmes de prise en charge. Chacune de ces connexions représente un flux de données qui doit être authentifié, chiffré, surveillé et examiné périodiquement.

Le modèle de menace des environnements de santé n’est pas statique : il s’étend à chaque nouvelle intégration approuvée, mais il se réduit rarement lorsque des intégrations sont remplacées ou abandonnées.

Comment sécuriser l’authentification, les échanges de jetons et le chiffrement des données pour les flux de travail cliniques ?

Les modèles d’authentification d’entreprise classiques fonctionnent dans des environnements contrôlés où les utilisateurs se connectent à partir d’appareils connus au sein de réseaux gérés. Les flux de travail cliniques ne fonctionnent pas ainsi. Les médecins doivent accéder à des systèmes hébergés dans le cloud depuis des postes de travail partagés, des appareils personnels et des sites distants – souvent sous la pression du temps, ce qui fait d’une authentification trop contraignante un véritable risque pour la prise en charge des patients.

SMART (Substitutable Medical Applications, Reusable Technologies) sur FHIR est un cadre d’autorisation basé sur OAuth 2.0, conçu spécifiquement pour les contextes d’applications cliniques, qui représente la norme de référence actuelle pour sécuriser l’accès par jeton aux API FHIR.

Cependant, la qualité de sa mise en œuvre varie selon les fournisseurs et les déploiements. Les délais d’expiration des jetons, les limitations de portée et la gestion des jetons de rafraîchissement nécessitent tous une configuration explicite, car les paramètres par défaut privilégient régulièrement la commodité au détriment de la sécurité.

Au-delà de l’authentification, l’application du protocole TLS à l’ensemble des flux de données PHI est obligatoire, et le chiffrement doit s’étendre aux données au repos au sein de tout système cloud recevant des informations provenant d’un DME ou d’une intégration d’API.

Les domaines clés nécessitant une attention particulière plutôt que de se contenter des paramètres par défaut :

• Portée du jeton limitée à l’accès minimal nécessaire aux données
• Des jetons d’accès à durée de vie courte avec des politiques de rafraîchissement contrôlées
• Le protocole TLS réciproque pour les connexions API de serveur à serveur
• Un chiffrement vérifié sur tous les niveaux de stockage recevant des données de santé protégées (PHI) provenant d’API

En quoi la connectivité des applications tierces accroît-elle les risques liés à la chaîne d’approvisionnement et aux mouvements latéraux ?

Les entreprises du secteur de la santé qui connectent des applications tierces à leurs environnements cloud héritent d’une partie de la posture de sécurité de chaque fournisseur – qu’elles l’aient évaluée ou non.

Une application destinée aux patients disposant d’un accès en écriture au dossier médical électronique (DME), un outil d’analyse de la santé de population doté de larges autorisations de requête de données, ou une intégration de facturation ayant accès aux données de remboursement et aux données démographiques constituent chacun un point d’entrée potentiel dans la chaîne d’approvisionnement. Si une application tierce est compromise, un attaquant peut hériter de tous les accès dont dispose cette application. Dans les environnements cloud du secteur de la santé, cet accès inclut souvent des voies d’accès à des systèmes contenant des informations médicales protégées (PHI) à grande échelle.

Les questionnaires de sécurité réguliers adressés aux fournisseurs suffisent rarement à mettre en évidence les risques spécifiques liés aux intégrations d’API cliniques, et la surveillance continue du comportement des connexions tierces n’est toujours pas une pratique systématique dans l’ensemble du secteur.

Pourquoi les contrôles d’identité et d’accès sont-ils essentiels pour la sécurité du cloud dans le secteur de la santé ?

Contrôler qui peut accéder à quoi et dans quelles circonstances constitue l’un des plus grands défis de sécurité pour tout environnement cloud. Dans le secteur de la santé, ce même défi est encore amplifié par la grande diversité des personnes nécessitant un accès à des systèmes sensibles, par l’urgence avec laquelle cet accès est parfois requis, ainsi que par les graves conséquences d’une restriction excessive ou insuffisante des accès.

En quoi les besoins en matière d’accès basé sur les rôles et sur les attributs varient-ils entre les utilisateurs cliniques et administratifs ?

Le contrôle d’accès basé sur les rôles (RBAC) repose sur le principe consistant à attribuer des autorisations système en fonction du poste occupé par l’utilisateur plutôt que de son identité individuelle. Un coordinateur de facturation a accès aux dossiers financiers. Un radiologue a accès aux systèmes d’imagerie. Une infirmière de service a accès aux dossiers d’administration des médicaments de son service.

Le RBAC constitue la norme de base en matière de gestion des accès au cloud dans le secteur de la santé et il réduit considérablement le risque que des utilisateurs aient accès à des informations qu’ils ne sont pas habilités à consulter d’un point de vue clinique ou opérationnel (s’il est correctement mis en œuvre).

Le principal problème réside dans le fait que les rôles dans le secteur de la santé peuvent rarement être classés en catégories bien distinctes. Le contrôle d’accès basé sur les attributs (ABAC) étend le RBAC en intégrant divers facteurs contextuels : le service dans lequel un utilisateur travaille actuellement, l’heure de la journée, le patient spécifique qu’il traite, ou encore le fait qu’il accède au système depuis un appareil approuvé sur un réseau interne.

Un médecin intervenant dans plusieurs services, une infirmière praticienne disposant de privilèges dans deux établissements, ou un coordinateur de soins travaillant à la fois en milieu hospitalier et en ambulatoire ont tous des besoins d’accès complexes qu’une définition statique des rôles aurait du mal à prendre en compte de manière claire. L’ABAC permet d’exprimer ces nuances sous forme de politique plutôt que de les gérer comme des exceptions.

Pourquoi un accès contextuel, fondé sur le principe du « droit le plus restreint », est-il essentiel dans les situations de soins au chevet du patient et d’urgence ?

L’accès fondé sur le « droit le plus restreint » est une pratique de sécurité bien établie : ce principe stipule que tout utilisateur ne doit avoir accès qu’au strict minimum de données et de systèmes nécessaires à la tâche qu’il effectue. Dans la plupart des environnements d’entreprise, l’application de cette pratique relève principalement d’un exercice technique et administratif. Dans le secteur de la santé, cependant, cette pratique est en contradiction flagrante avec les réalités des soins d’urgence.

Un médecin traumatologue traitant un patient inconscient admis sans pièce d’identité a besoin d’un accès immédiat à l’ensemble du dossier médical de ce patient (antécédents d’allergies, traitements en cours et diagnostics antérieurs). Le fait que ce médecin n’ait eu aucune relation thérapeutique antérieure avec le patient signifie qu’une application stricte du modèle du « moindre privilège » va précisément bloquer l’accès indispensable à la prise en charge médicale.

C’est là qu’intervient le modèle d’accès « briser la vitre ». Il s’agit d’un mécanisme de dérogation contrôlée qui permet aux cliniciens de contourner les restrictions d’accès standard en cas d’urgence réelle, tout en enregistrant chaque action effectuée au cours de cette session en vue d’un examen ultérieur.

L’accès « d’urgence » ne constitue pas une faille de sécurité, mais une soupape de sécurité délibérée et vérifiable. Cependant, il peut devenir un problème de sécurité lorsqu’il est mal défini, mal consigné ou utilisé si fréquemment qu’il perd tout son sens en tant qu’exception.

C’est pourquoi des politiques d’accès tenant compte du contexte sont nécessaires. Elles prennent en compte la localisation du patient, l’affectation de l’équipe soignante et l’urgence clinique afin de réduire la fréquence d’utilisation du modèle d’accès « d’urgence » sans pour autant le supprimer en tant qu’option.

Comment les accès temporaires, conditionnels et des prestataires doivent-ils être régis et audités ?

Les environnements cloud du secteur de la santé accueillent souvent des utilisateurs dont les besoins d’accès sont, par défaut, limités dans le temps. Cela inclut les infirmières itinérantes et les médecins remplaçants comblant des absences de courte durée, les prestataires tiers effectuant la maintenance des systèmes, les consultants en mise en œuvre disposant de privilèges administratifs temporaires, ainsi que les auditeurs externes examinant la documentation de conformité. Accorder un accès à l’un de ces utilisateurs représente un risque qui ne cesse de croître lorsqu’il n’est pas géré activement.

Les exigences fondamentales sont simples, même si leur mise en œuvre cohérente ne l’est pas :

• Les autorisations d’accès pour les utilisateurs temporaires doivent comporter des dates d’expiration explicites fixées au moment de l’attribution
• L’accès des prestataires et des tiers doit être limité aux systèmes et données spécifiques requis pour la mission – rien de plus
• Toutes les sessions d’accès temporaires doivent être consignées avec suffisamment de détails pour permettre une piste d’audit complète
• Les révisions des accès doivent être programmées de manière proactive plutôt que d’être déclenchées uniquement par des événements de départ

La situation de défaillance la plus courante n’est même pas de nature malveillante, mais administrative. Cela inclut les identifiants temporaires qui n’ont jamais été révoqués, les comptes de fournisseurs dont la validité a dépassé la durée de la mission, et les accès des sous-traitants qui se sont étendus progressivement sans examen formel.

En quoi les dispositifs médicaux et l’IoT modifient-ils les exigences en matière de sécurité dans le cloud ?

Les dispositifs médicaux et les équipements cliniques connectés relèvent d’une catégorie de risques distincte qui ne peut être correctement prise en compte par les recommandations standard relatives à l’IoT. Ces dispositifs ne sont pas de simples capteurs de bâtiment ou des thermostats intelligents, mais des systèmes critiques pour la sécurité ayant un impact direct sur les patients – c’est pourquoi les contraintes de sécurité auxquelles ils sont soumis diffèrent considérablement de celles de tout autre élément d’un environnement cloud classique.

Pourquoi les contraintes liées aux dispositifs (systèmes d’exploitation hérités, possibilités de correctifs limitées) sont-elles importantes pour l’intégration dans le cloud ?

De nombreux dispositifs médicaux (pompes à perfusion, systèmes d’imagerie, moniteurs de surveillance des patients, ventilateurs) utilisent des systèmes d’exploitation obsolètes. Windows 7, Windows XP et même des plateformes plus anciennes sont encore activement utilisés en milieu clinique à ce jour. Cela se produit généralement lorsque les fabricants de dispositifs développent et certifient leurs logiciels pour une version spécifique du système d’exploitation, ce qui signifie que le remplacement ou la mise à jour de ces logiciels nécessiterait de repasser par l’ensemble du processus d’examen réglementaire de la FDA.

C’est la principale raison pour laquelle l’application de correctifs – le mécanisme le plus élémentaire pour remédier aux vulnérabilités logicielles – n’est pas disponible pour une grande partie des dispositifs connectés aux environnements cloud du secteur de la santé.

Un dispositif qui ne peut pas être corrigé ne peut pas non plus être considéré comme sécurisé au sens conventionnel du terme. Chaque fois que ces dispositifs doivent transmettre des données de télémétrie à des plateformes cloud ou recevoir des mises à jour de configuration provenant de systèmes de gestion hébergés dans le cloud, la sécurité de cette connexion doit être gérée exclusivement du côté du réseau ou du cloud, car le dispositif lui-même ne peut pratiquement rien offrir à cet égard.

Comment la télémétrie, l’identité des dispositifs et la segmentation doivent-elles être conçues pour les dispositifs critiques en matière de sécurité ?

La segmentation du réseau constitue la première ligne de défense dans les environnements liés aux soins de santé. Les dispositifs médicaux doivent être confinés dans des segments de réseau isolés, n’ayant accès qu’aux systèmes cloud spécifiques dont ils ont besoin. Un moniteur de surveillance des patients ne devrait pas pouvoir établir de connexion avec un stockage cloud, des serveurs d’administration, un réseau externe ou tout autre élément, à l’exception de ce système cloud particulier. La segmentation ne résout pas la vulnérabilité du dispositif lui-même, mais elle peut au moins limiter la « portée » de l’une des vulnérabilités exploitées.

L’identité du dispositif est tout aussi importante. Chaque appareil se connectant à un environnement cloud doit prouver son identité à l’aide d’un identifiant unique (idéalement, un certificat associé à l’appareil, et non de simples identifiants de connexion). Ainsi, tout appareil présentant des comportements inhabituels peut être identifié et traité sans affecter les autres appareils du même réseau. La possibilité de disposer à tout moment d’un inventaire précis des appareils connectés constitue également un avantage.

Les flux de télémétrie provenant des appareils médicaux doivent également faire l’objet d’une surveillance afin de détecter d’éventuelles anomalies. Tout type de schéma inhabituel peut constituer un indicateur de compromission ou de mauvaise configuration (qu’il s’agisse de volumes de données inhabituels, de cibles de connexion inattendues ou de schémas de communication s’écartant du comportement normal d’un appareil).

En quoi l’analyse côté cloud peut-elle présenter des risques pour la confidentialité des données générées par les appareils ?

Une idée reçue courante concernant la télémétrie des appareils consiste à considérer que ces données sont, par nature, peu sensibles, s’apparentant davantage à des sorties de machine qu’à des informations de santé protégées (PHI). Ce genre d’hypothèse est souvent erronée.

Les flux de données continus provenant d’appareils tels que les glucomètres, les appareils de télémétrie cardiaque ou les moniteurs respiratoires peuvent contenir suffisamment d’informations pour identifier des patients spécifiques, déduire des diagnostics et reconstituer le parcours de soins (même après suppression des identifiants évidents). Chaque fois que ces données sont transférées vers des plateformes d’analyse basées sur le cloud, elles peuvent être agrégées, conservées, partagées avec des prestataires d’analyse tiers, voire utilisées pour entraîner des modèles de manière inhabituelle.

Le risque de réidentification des données de santé générées par des appareils est important et souvent sous-estimé. Le caractère critique de ces informations implique qu’elles méritent au moins le même traitement que les informations de santé protégées (PHI), à l’instar de toute donnée qualifiée de dossier médical.

Que réalisent généralement trop tard les établissements de santé après avoir transféré des données sensibles vers le cloud ?

Dans le secteur de la santé, l’adoption du cloud devance souvent le développement des programmes de sécurité conçus pour l’accompagner. Les failles de sécurité qui en résultent passent souvent inaperçues jusqu’à ce qu’un incident se produise.

Pourquoi des environnements cloud techniquement conformes sont-ils encore victimes de fuites de données de santé ?

Les évaluations de conformité réglementaire ne permettent de vérifier que l’existence des contrôles de sécurité nécessaires à un moment donné. Ces tests ne permettent pas de déterminer si ces contrôles continueront de fonctionner correctement plusieurs mois plus tard, une fois que l’environnement les entourant aura évolué.

L’infrastructure cloud elle-même est rarement statique et inerte. Les développeurs créent de nouvelles ressources de stockage, des intégrations entre les systèmes sont régulièrement ajoutées, et les autorisations sont souvent ajustées pour résoudre rapidement les problèmes d’accès (sans jamais être réexaminées par la suite). Aucun de ces changements ne va déclencher à lui seul un contrôle de conformité, mais chacun d’entre eux peut néanmoins être considéré comme une occasion pour l’environnement de s’éloigner de l’état qui lui avait permis de passer le dernier audit.

Il est indispensable d’évoquer ces sujets, car les erreurs de configuration restent à ce jour la principale cause des violations de données dans le cloud – aucune des attaques sophistiquées menées par des États-nations ni aucun des exploits « zero-day » ne s’en approche, même de loin. Une part importante des incidents liés au cloud dans le secteur de la santé résulte :

• De compartiments de stockage exposés
• De politiques d’accès trop permissives
• De la désactivation de la journalisation

Il est assez courant qu’un établissement de santé réussisse un audit HIPAA, puis subisse une violation évitable quelques mois plus tard seulement. L’environnement de l’établissement ne présentait aucun problème au moment de l’audit, mais l’environnement lui-même a évolué. C’est pourquoi la conformité est un état, et non une garantie.

Comment les hypothèses relatives à la migration vers le cloud affaiblissent-elles insidieusement la sécurité du cloud dans le secteur de la santé ?

La pire erreur que l’on puisse commettre lors d’une migration est de supposer que les contrôles de sécurité sur site fonctionneront exactement de la même manière une fois transférés vers le cloud. Cette approche est parfois appelée « lift-and-shift » : il s’agit de prendre des charges de travail préexistantes et de les déplacer vers une infrastructure cloud sans apporter aucune modification pour les adapter au nouvel environnement. C’est une solution rapide à certains problèmes, mais elle est également extrêmement risquée.

• Les règles de pare-feu qui protégeaient un centre de données ne s’appliquent pas aux compartiments de stockage dans le cloud
• Les périmètres réseau qui limitaient les mouvements latéraux sur site n’existent pas de la même manière dans un environnement cloud
• Les contrôles d’accès que l’équipe informatique sur site gérait manuellement ne migrent pas avec les données et doivent être délibérément recréés dans le cloud

La cause principale de la quasi-totalité des vulnérabilités liées à la migration tient à la confusion qui règne autour du modèle de responsabilité partagée. Les entreprises qui migrent leurs données vers un fournisseur de cloud partent du principe que les paramètres de sécurité par défaut de ce dernier couvriront ce que leur équipe interne avait l’habitude de faire sur site – ce qui n’est pas le cas.

L’un des constats les plus fréquemment rapportés après une migration concerne les rôles de gestion des identités et des accès (IAM) dotés de droits excessifs : des configurations créées avec des droits d’accès étendus lors de la migration afin d’éviter tout contretemps, signalées comme temporaires, mais qui n’ont jamais été supprimées par la suite. Ces rôles peuvent subsister de manière passive dans l’environnement pendant longtemps, offrant aux attaquants qui parviennent à les exploiter un accès bien plus étendu que celui qui devrait jamais être accordé à un seul utilisateur.

Ce genre de problèmes n’est jamais spectaculaire ni évident, car les systèmes continuent de fonctionner, les journaux continuent d’être générés, etc. Les problèmes commencent à apparaître lors d’un incident, lorsqu’on se rend compte que le compartiment mal configuré était accessible depuis des mois, ou que le rôle doté de droits excessifs dispose d’un accès en lecture à l’ensemble des ensembles de données PHI de l’environnement.

Pourquoi les défaillances de sauvegarde et de restauration sont-elles souvent plus préjudiciables que l’attaque initiale sur le cloud ?

De nombreuses attaques sur le cloud ne peuvent perturber les opérations que sur le moment. En revanche, un échec de restauration risque de prolonger indéfiniment cette perturbation.

Il n’est pas rare que les établissements de santé découvrent des problèmes critiques liés à leurs sauvegardes sur le cloud lors d’attaques par ransomware – au moment où ils peuvent le moins se le permettre. Cela inclut :

• Les sauvegardes étaient stockées dans le même environnement que les systèmes principaux et chiffrées en même temps que ceux-ci
• Les tâches de sauvegarde s’étaient terminées avec succès sur le tableau de bord – mais les données restaurées étaient incomplètes ou corrompues
• La restauration n’avait jamais été testée de bout en bout dans un scénario réaliste
• Les politiques de conservation avaient été mal définies, laissant des points de restauration trop anciens pour être cliniquement exploitables

Le deuxième point concernant les rapports de sauvegarde mérite une attention particulière. De par leur nature même, les tableaux de bord de sauvegarde signalent l’achèvement des tâches, et non la réussite de la restauration. Il est tout à fait possible qu’une tâche se termine sans erreur tout en créant une sauvegarde qui ne peut pas être utilisée pour restaurer un système fonctionnel. La seule façon de savoir si une sauvegarde fonctionne est de la tester – mais les tests sont une étape que bien trop d’entreprises négligent régulièrement.

Les sauvegardes immuables constituent la contre-mesure directe face aux risques liés aux sauvegardes à l’ère des ransomwares. Il s’agit de copies qui ne peuvent être créées qu’une seule fois, sans possibilité de les modifier, de les supprimer ou de les chiffrer par la suite. L’immuabilité n’empêche pas une attaque de se produire, mais elle garantit que la restauration restera possible après une attaque.

L’absence de sauvegardes immuables constitue un problème critique, car de nombreux auteurs de rançongiciels disposant d’un accès suffisant aux systèmes principaux ont souvent également accès aux sauvegardes, ce qui peut compromettre fondamentalement tout plan de sauvegarde.

Comment se déroule généralement une violation de données dans le cloud du secteur de la santé ?

Les violations dans les environnements cloud du secteur de la santé commencent rarement par une faille technique complexe. Ces incidents trouvent leur origine chez une personne et s’aggravent rapidement à partir de là.

Comment les attaquants passent-ils du phishing à la compromission d’un système de santé basé sur le cloud ?

Un simple e-mail suffit généralement à déclencher toute la chaîne. N’importe quel membre du personnel pourrait cliquer sur un lien qui ressemble à une demande d’identification informatique de routine ou à une mise à jour du portail patient. Une fois ses identifiants saisis, l’attaque passe à une phase différente.

Le chemin menant du hameçonnage à l’accès à l’environnement cloud est bien plus court que ne le pensent la plupart des entreprises, car de nombreux professionnels de santé utilisent encore le même jeu d’identifiants sur différents systèmes (alors que les consoles de gestion du cloud sont accessibles depuis n’importe quel navigateur).

Un attaquant n’a pas besoin de franchir le périmètre de sécurité lorsqu’il dispose d’une combinaison valide de nom d’utilisateur et de mot de passe : il lui suffit de se connecter en se faisant passer pour n’importe qui d’autre.

Une fois l’intrusion établie, l’accent est mis sur l’expansion et la persistance. L’attaquant tente de localiser les environnements de stockage cloud contenant le plus de données, les comptes de service disposant des autorisations les plus étendues, ainsi que les systèmes connectés susceptibles d’être utilisés pour acquérir des informations médicales protégées (PHI) supplémentaires.

La plupart des attaques visant le cloud dans le secteur de la santé atteignent le stade de l’exfiltration des PHI en l’espace de quelques jours après l’intrusion initiale. Au moment où le comportement anormal est détecté, il est fort probable que l’attaquant ait déjà atteint son objectif.

Pourquoi les plateformes de stockage dans le cloud et les API du secteur de la santé sont-elles de plus en plus ciblées ?

Les API du secteur de la santé et les plateformes de stockage dans le cloud sont ciblées principalement en raison de leur retour sur investissement considérable.

Un seul compartiment de stockage dans le cloud mal configuré dans un environnement de santé suffit à exposer des millions de dossiers de patients. Parallèlement, des identifiants d’API compromis permettraient d’obtenir un accès continu et authentifié à un flux de données mis à jour en temps réel.

Les données de santé constituent une marchandise bien plus précieuse sur les marchés criminels que les données financières. Un dossier médical complet vaut plusieurs fois plus qu’un numéro de carte bancaire, car il contient des données immuables pouvant être exploitées de multiples façons sur une longue période.

La nature accessible des API en fait également des cibles attrayantes. Une API est nécessaire pour transférer des informations entre les systèmes de manière transparente, ce qui les rend accessibles, fonctionnelles et interrogeables à grande échelle sans déclencher de nombreuses alertes au sein de l’environnement.

Quelles perturbations opérationnelles surviennent lorsque des attaquants accèdent à des environnements cloud du secteur de la santé ?

Une violation de sécurité dans le cloud du secteur de la santé a des répercussions cliniques et opérationnelles de grande envergure qui vont bien au-delà des systèmes compromis eux-mêmes. Parmi les perturbations courantes, on peut citer :

• Indisponibilité des dossiers médicaux électroniques (DME) – les cliniciens perdent l’accès aux antécédents médicamenteux, aux plans de soins et aux résultats diagnostiques, ce qui les oblige à recourir à des processus manuels sur support papier
• Réacheminement des ambulances – les hôpitaux fonctionnant selon des procédures de secours peuvent déclarer des situations d’urgence internes et réacheminer les patients vers d’autres établissements
• Annulation d’interventions – les interventions chirurgicales non urgentes et programmées, les rendez-vous d’imagerie médicale et les consultations externes sont reportés lorsque les systèmes permettant les vérifications préopératoires sont hors ligne
• Retards dans la délivrance des médicaments – les systèmes de prescription électronique tombent en panne, ce qui engendre des risques au moment de l’administration des médicaments
• Paralysie de la facturation et des demandes de remboursement – les systèmes de cycle de revenus qui dépendent d’une infrastructure cloud cessent de fonctionner, créant des retards financiers qui persistent longtemps après la restauration des systèmes cliniques
• Risques réglementaires et juridiques – les obligations de notification des violations s’activent immédiatement, alourdissant la charge de travail liée à la conformité au moment même où la reprise opérationnelle mobilise au maximum les capacités de l’organisation

Les perturbations cliniques pourraient être résolues en quelques jours ou semaines, mais les conséquences réglementaires, juridiques et en termes de réputation d’une seule attaque ont tendance à durer bien plus longtemps que cela.

Pourquoi la réponse aux incidents et l’analyse forensic doivent-elles être adaptées aux environnements cloud du secteur de la santé ?

L’objectif principal de la réponse aux incidents dans la plupart des secteurs est de contenir la menace et de rétablir l’environnement. Le secteur de la santé y ajoute un autre objectif : assurer la sécurité des patients tout au long du processus. Or, ces deux objectifs ne vont pas toujours dans le même sens.

En quoi la nécessité d’assurer rapidement la continuité des soins modifie-t-elle les stratégies de confinement des incidents ?

Les principes standard de la réponse aux incidents reposent largement sur l’isolement. Lorsqu’un système est compromis, il est mis hors ligne et déconnecté du réseau afin d’empêcher la propagation de l’attaque. C’est une bonne approche pour la plupart des systèmes soutenant les opérations commerciales. Malheureusement, on ne peut pas en dire autant des systèmes qui prennent en charge les soins actifs aux patients.

Mettre un dossier médical électronique (DME) hors ligne lors d’un incident en cours prive le personnel soignant de l’accès aux dossiers de médication, aux antécédents d’allergies et aux données de surveillance en temps réel. Tenter d’isoler un environnement cloud prenant en charge la télémétrie en soins intensifs ou la délivrance de médicaments par la pharmacie crée un risque clinique direct. La mesure de confinement elle-même peut causer un préjudice, c’est pourquoi les équipes d’intervention en cas d’incident dans les environnements de santé ne peuvent pas se contenter de suivre le guide d’intervention habituel utilisé par tous.

Une approche plus ciblée s’impose ici. Au lieu de procéder à un isolement généralisé, les équipes d’intervention en cas d’incident (IR) du secteur de la santé doivent disposer de stratégies de confinement prédéfinies, capables de distinguer les systèmes pouvant être mis hors ligne des environnements qui doivent rester disponibles quoi qu’il arrive. Toutes ces décisions doivent être prises bien avant qu’un incident ne se produise, car prendre en temps réel des décisions concernant les systèmes cliniques pouvant être interrompus en toute sécurité lors d’une faille de sécurité constitue une pratique à haut risque.

Quels contrôles d’investigation et quelle journalisation sont nécessaires pour soutenir à la fois les enquêtes juridiques et cliniques ?

La plupart des violations typiques du cloud dans le secteur de la santé nécessitent au moins deux enquêtes menées en parallèle :

1. L’examen de la conformité et des litiges
2. L’examen de la compromission des données cliniques et de l’impact sur les décisions de soins aux patients

L’élément essentiel que chaque enquête recherchera reposera sur exactement les mêmes preuves : les journaux. Pratiquement toute la valeur d’investigation d’un environnement cloud est déterminée par les décisions de journalisation prises bien avant l’incident. Les preuves qui n’ont pas été capturées ne peuvent pas non plus être récupérées a posteriori.

Les exigences fondamentales en matière de journalisation pour les environnements cloud du secteur de la santé comprennent :

• Les journaux d’accès couvrant chaque interaction avec les données de santé protégées (PHI) — qui y a accédé, quand, depuis où et quelles actions ont été effectuées
• Les journaux d’authentification, y compris les tentatives de connexion infructueuses, les événements de contournement de l’authentification multifactorielle (MFA) et l’escalade de privilèges
• Les journaux d’appels API capturant toutes les requêtes adressées aux interfaces de gestion du cloud et aux API de données de santé
• Les journaux de flux réseau suffisants pour reconstituer les mouvements latéraux et les chemins d’exfiltration des données
• Les journaux de modification de configuration permettant de suivre les modifications apportées aux autorisations de stockage, aux rôles IAM et aux règles des groupes de sécurité

Les durées de conservation de ces journaux doivent être conformes à la fois à l’obligation de conservation des documents pendant six ans prévue par la loi HIPAA et à toute réglementation étatique applicable. Les journaux doivent être stockés séparément des systèmes qu’ils surveillent afin d’empêcher un attaquant ayant accédé à l’infrastructure principale de modifier ou de supprimer les preuves.

En quoi les exercices sur table et les guides d’intervention doivent-ils différer des scénarios réservés aux entreprises ?

La plupart des exercices de simulation de réponse aux incidents (IR) en entreprise impliquent généralement les équipes informatiques et de sécurité (les équipes juridiques et de communication y participent parfois également). Les exercices de simulation dans le secteur de la santé nécessitent un cadre nettement plus large – et des scénarios très différents.

Les responsables des opérations cliniques doivent être présents, car les décisions concernant les systèmes à mettre hors ligne doivent être prises sous l’autorité clinique. Le service d’ingénierie biomédicale doit être impliqué dès lors que les scénarios concernent des appareils connectés. Les responsables de la protection de la vie privée doivent participer aux processus décisionnels relatifs à la notification des violations.

Les scénarios eux-mêmes doivent refléter les menaces spécifiques au secteur de la santé :

• Un rançongiciel qui chiffre simultanément les systèmes de DME principaux et les sauvegardes dans le cloud
• Des identifiants d’API compromis permettant un accès furtif aux données des patients pendant une période prolongée
• Une erreur de configuration du cloud ayant exposé publiquement des informations médicales protégées (PHI) pendant une durée indéterminée
• Une violation chez un fournisseur tiers qui se propage dans l’environnement cloud de l’établissement de santé via une intégration active

Un guide d’intervention ne peut être considéré comme suffisant dans un contexte de santé s’il ne prévoit pas l’activation de la procédure en cas d’indisponibilité (workflows manuels auxquels le personnel clinique a recours lorsque les systèmes sont indisponibles). Cette partie de la réponse présente le plus grand risque pour la sécurité des patients et est le plus souvent absente des plans empruntés à des secteurs non cliniques.

Pourquoi la sécurité du cloud dans le secteur de la santé est-elle plus complexe que la sécurité traditionnelle du cloud d’entreprise ?

Tous les secteurs sont confrontés, dans une certaine mesure, à des défis en matière de sécurité du cloud, et le secteur de la santé ne fait pas exception – il comporte même un ensemble de contraintes qui ne concernent aucun autre secteur. La difficulté de la sécurité du cloud dans le secteur de la santé est d’ordre structurel, et non technique.

Pourquoi les prestataires de soins ne peuvent-ils pas simplement restreindre tous les accès au cloud ?

Le secteur de la santé a déjà dépassé le stade où la restriction constituerait une stratégie viable. Bon nombre des éléments modernes d’un environnement de soins de santé sont pratiquement impossibles à mettre en œuvre sans le stockage dans le cloud. Par exemple :

• Les flux de travail cliniques dépendent de plateformes de DME hébergées dans le cloud
• Les patients s’attendent à pouvoir accéder à leur dossier via des portails en ligne
• La télésanté repose sur une infrastructure cloud
• Les images diagnostiques sont stockées et transmises via le cloud, car la taille des fichiers rend le stockage local impraticable à grande échelle

Restreindre de manière significative l’accès au cloud dans le secteur de la santé ne le rendra pas plus sûr, mais rendra son fonctionnement impossible. La question n’est jamais de permettre ou de refuser l’accès au cloud, mais de rendre cet accès aussi sûr que possible sans perturber les soins qu’il soutient.

En quoi les flux de travail des soins d’urgence entraînent-ils des compromis inévitables en matière de sécurité du cloud ?

La politique de sécurité ne suit pas le même rythme que les soins d’urgence. Une équipe de traumatologie s’occupant d’un patient dans un état critique n’attendrait pas que le processus d’authentification en plusieurs étapes soit mené à bien. Un médecin assurant une permanence dans un service qu’il ne connaît pas à 3 heures du matin n’attendra pas qu’une demande d’accès soit approuvée alors qu’il examine le dossier médical d’un patient dont l’état s’aggrave.

La nature même des soins d’urgence implique que tout contrôle de sécurité introduisant une friction sera contourné, et non respecté. Dans le secteur de la santé, ces contournements sont souvent justifiés sur le plan clinique, ce qui les rend extrêmement difficiles à empêcher par le seul biais de politiques.

Des contrôles de sécurité plus stricts peuvent réduire les risques dans des conditions stables, mais ils les augmentent également en situation d’urgence. Ce compromis est bien réel et tout à fait inévitable. La sécurité d’un établissement de santé doit être envisagée non pas comme une fin en soi, mais comme une liste de choix raisonnés et documentés concernant les domaines dans lesquels ces risques peuvent être acceptés (en tenant compte de l’avis clinique, et pas uniquement de la sécurité).

Pourquoi l’accès continu aux données engendre-t-il des risques de cybersécurité spécifiques aux systèmes de santé ?

La plupart des systèmes d’entreprise ont tendance à suivre des rythmes naturels, notamment :

• Un pic d’utilisation pendant les heures de bureau
• Une activité réduite pendant la nuit
• Des fenêtres de maintenance le week-end

Cela ne s’applique pas aux systèmes de santé. Les plateformes de dossiers médicaux électroniques (DME), les systèmes de pharmacie hébergés dans le cloud et les environnements de surveillance des patients fonctionnent à pleine capacité 24 heures sur 24, tous les jours de l’année.

Cette disponibilité continue exclut certaines options sur lesquelles les équipes de sécurité d’entreprise s’appuient habituellement. La planification d’arrêts pour la gestion des correctifs devient essentiellement un débat portant sur la gestion des risques cliniques. Les systèmes conçus pour détecter des anomalies dans le trafic réseau normal doivent tenir compte du fait que, dans le secteur de la santé, il existe très peu de périodes creuses au sens habituel du terme.

Un système toujours actif est un système constamment exposé. Mettre en place une sécurité adaptée à cette réalité nécessite une approche totalement différente de celle utilisée pour sécuriser la plupart des autres infrastructures dans d’autres secteurs.

En quoi l’architecture cloud native modifie-t-elle la sécurité cloud dans les environnements de santé ?

Les environnements informatiques traditionnels du secteur de la santé étaient construits autour de grandes applications centralisées où les données se trouvaient à des emplacements prévisibles et où les périmètres de sécurité étaient faciles à définir. L’avènement de l’architecture cloud native a modifié ces deux facteurs simultanément.

Pourquoi les microservices, les conteneurs et les solutions sans serveur nécessitent-ils une nouvelle modélisation des menaces pour les données de santé protégées (PHI) ?

Dans une application monolithique traditionnelle, l’essentiel des fonctionnalités s’exécute au sein d’un même système. Le processus est simple : les données de santé protégées (PHI) sont reçues, traitées, puis stockées. Tout cela se déroule au sein d’un système unique dont les limites de sécurité sont assez bien définies.

Les applications natives du cloud se comportent différemment. Une architecture de microservices transforme cette application unique en des dizaines, voire des centaines de services plus petits, indépendants les uns des autres mais capables de communiquer entre eux via le réseau. Chacun de ces services peut traiter brièvement des données de santé protégées (les recevoir, les transformer, les transmettre) sans les stocker de manière permanente.

Si cette approche moderne est extrêmement efficace, elle implique également que les données de santé protégées circulent en permanence à travers un grand nombre de composants, chacun d’entre eux représentant un point d’exposition potentiel.

Les conteneurs – de petits paquets portables exécutant des services individuels – sont éphémères par nature ; ils peuvent donc apparaître, remplir leur fonction, puis disparaître. La nature même des conteneurs les rend particulièrement problématiques en matière de surveillance continue et d’application de correctifs de sécurité au sens conventionnel du terme.

Les fonctions sans serveur poussent cette approche encore plus loin : le code s’exécute en réponse à un déclencheur, fonctionne brièvement, puis s’arrête. De cette manière, il n’y a pas de serveur persistant à surveiller ou à sécuriser, du moins de manière traditionnelle. Chaque fois que des données de santé protégées (PHI) transitent par une fonction sans serveur, la fenêtre permettant de les observer et de les consigner reste très réduite.

Toutes ces caractéristiques et approches nécessitent un modèle de menace nettement plus distribué que tout ce pour quoi la sécurité informatique traditionnelle du secteur de la santé avait été conçue.

Comment les pipelines CI/CD et le DevSecOps doivent-ils être adaptés pour répondre aux exigences de conformité du secteur de la santé ?

Un pipeline CI/CD (intégration continue et déploiement continu) est un mécanisme automatisé qui prend le code écrit par les développeurs, le teste et le déploie en production. Un tel processus peut être très rapide dans le contexte des environnements cloud natifs. De nouvelles configurations, des services mis à jour et des politiques d’accès modifiées peuvent être mises en production en quelques minutes.

Si les contrôles de sécurité ne sont pas intégrés au pipeline dès le départ, ce type de rapidité devient un risque en matière de conformité. Le DevSecOps consiste à intégrer des étapes de validation de la sécurité dans le processus de développement et de déploiement, plutôt que de les examiner séparément a posteriori.

Ce que cela signifie dans le contexte des soins de santé :

• Analyser automatiquement le code de l’infrastructure à la recherche de erreurs de configuration avant le déploiement
• Signaler les ressources de stockage ou les points de terminaison API susceptibles d’exposer des informations médicales protégées (PHI) sans chiffrement
• Bloquer les déploiements qui supprimeraient la journalisation d’audit requise
• Vérifier que les nouveaux services répondent aux exigences de sécurité pertinentes au titre du BAA avant leur mise en production

Détecter les lacunes de conformité au moment où leur correction est la moins coûteuse (avant la mise en production du code) est l’objectif principal de cette approche, qui s’avère nettement plus efficace que de découvrir tous les problèmes après un incident ou lors d’un audit.

Quels contrôles automatisés protègent l’infrastructure cloud du secteur de la santé contre les erreurs de configuration ?

La vérification manuelle des configurations est manifestement insuffisante compte tenu de la rapidité à laquelle évoluent les environnements natifs du cloud. Les contrôles automatisés sont pratiquement indispensables pour surveiller en continu l’environnement et détecter les dérives dès qu’elles se produisent.

Parmi les principales catégories de contrôles à garder à l’esprit, on peut citer :

• La gestion de la posture de sécurité dans le cloud (CSPM) — des outils qui analysent en continu les environnements cloud à la recherche de erreurs de configuration, en comparant les paramètres actuels aux références de sécurité et aux cadres de conformité en temps réel
• L’analyse « Infrastructure-as-Code » (IaC) — une analyse automatisée du code utilisé pour définir l’infrastructure cloud, permettant de détecter les configurations non sécurisées avant même leur déploiement
• Détection des dérives — surveillance permettant d’identifier les cas où un environnement cloud en production s’écarte de sa configuration de référence approuvée, en signalant les modifications non autorisées ou accidentelles dès qu’elles se produisent
• Application des politiques sous forme de code — règles de sécurité rédigées sous forme de politiques lisibles par machine, qui sont automatiquement appliquées et mises en œuvre sur l’ensemble des ressources cloud, éliminant ainsi la dépendance vis-à-vis d’une vérification manuelle

Il est important de mentionner qu’aucun de ces contrôles ne supprime totalement la nécessité d’une supervision humaine, mais ils visent à garantir que le volume et le rythme des changements dans les environnements natifs du cloud ne puissent pas dépasser la capacité de l’équipe de sécurité à y faire face.

Comment les établissements de santé peuvent-ils améliorer la sécurité du cloud dans le secteur de la santé lors de l’adoption du cloud ?

Se contenter de comprendre pourquoi la sécurité du cloud dans le secteur de la santé est si complexe ne représente que la moitié du travail. L’autre moitié consiste à mettre en place des programmes suffisamment concrets pour être réellement suivis à la fois par le personnel clinique, les équipes de sécurité et la direction.

Quels risques liés au cloud computing les établissements de santé doivent-ils prendre en compte lors de la migration ?

La phase la plus risquée du parcours d’adoption du cloud est la migration : une prise de décision rapide sous la pression du projet entraîne des années de « dette de sécurité ». Avant que les données de santé protégées (PHI) ne soient transférées vers un environnement cloud, les établissements doivent traiter les points suivants :

• Classification des données — identifier quelles données constituent des PHI, où elles se trouvent actuellement et quels services cloud y auront accès
• Couverture des accords de partenariat commercial (BAA) — confirmer que des accords de partenariat commercial signés sont en place avec chaque prestataire et sous-traitant chargé de traiter les PHI
• Conception du contrôle d’accès — définir des politiques d’accès basées sur les rôles pour l’environnement cloud avant la migration, et non après
• Configuration de la journalisation — définir la portée des journaux d’audit, les durées de conservation et l’isolation du stockage dès la mise en place initiale
• Vérification du chiffrement — s’assurer que le chiffrement couvre tous les niveaux de stockage, les chemins de transit et les environnements de traitement qui traiteront les données de santé protégées
• Tests de sauvegarde et de restauration — vérifier que les processus de sauvegarde fonctionnent correctement dans l’environnement cloud avant la bascule des systèmes principaux
• Cartographie des responsabilités partagées — documenter explicitement quelles obligations de sécurité incombent au fournisseur et lesquelles incombent à l’organisation

Comment les établissements de santé peuvent-ils réduire les risques dans un environnement cloud lors d’une adoption progressive ?

Transférer l’ensemble des données vers le cloud en une seule fois maximise à la fois la rapidité et les risques. Une approche progressive, étape par étape, permet de vérifier les contrôles de sécurité à chaque étape avant de passer à la suivante.

Un point de départ raisonnable consiste à tester l’adoption du cloud avec des charges de travail moins sensibles — systèmes administratifs, outils de collaboration non cliniques ou environnements d’analyse anonymisés. Cela donne aux équipes de sécurité et informatiques le temps de comprendre comment les contrôles du fournisseur de cloud se comportent concrètement, d’identifier les écarts entre les paramètres de sécurité par défaut supposés et réels, et de se familiariser avec les opérations avant que les données de santé protégées (PHI) ne soient concernées.

Chaque phase doit inclure un point de contrôle de validation formel avant toute extension. Cela implique de tester la sauvegarde et la restauration, d’examiner les journaux d’accès à la recherche de comportements inattendus, de confirmer que la journalisation enregistre bien ce qu’elle doit enregistrer, et de vérifier que les limites de la responsabilité partagée sont bien respectées dans la pratique.

Une adoption par étapes ne signifie pas une adoption plus lente du cloud. Il s’agit d’une adoption du cloud qui ne génère pas de retard dans les mesures correctives qui pèseraient sur l’organisation pendant des années.

Quels indicateurs et KPI les responsables du secteur de la santé doivent-ils suivre pour évaluer la maturité en matière de sécurité du cloud ?

Déterminer la maturité en matière de sécurité constitue un véritable défi en l’absence de mesures spécifiques. Les indicateurs présentés ci-dessous visent à aider les responsables du secteur de la santé à vérifier si les mesures de sécurité du cloud sont opérationnelles et ne se limitent pas à une simple mise en œuvre.

Comment Bacula Systems peut-il améliorer la sécurité du cloud dans les environnements de santé ?

La sécurisation des données de santé protégées (PHI) dans le cloud nécessite bien plus que des contrôles préventifs : il faut également s’assurer que la restauration est possible lorsque ces contrôles sont testés correctement. Bacula Systems offre des capacités de sauvegarde de niveau entreprise, ainsi que des fonctionnalités de restauration et de gestion des données conçues pour répondre à la complexité des environnements cloud modernes du secteur de la santé.

Voici en quoi Bacula Systems fait directement la différence :

• Sauvegardes immuables — des copies de sauvegarde qui ne peuvent être ni modifiées, ni supprimées, ni chiffrées par un attaquant, même s’il dispose d’un accès administrateur aux systèmes principaux
• Restauration granulaire — restauration de fichiers individuels, de bases de données ou de systèmes entiers sans avoir à tout restaurer en une seule fois, ce qui réduit les temps d’arrêt cliniques en cas d’incident
• Contrôle des clés de chiffrement — les organisations conservent la propriété de leurs propres clés de chiffrement plutôt que de déléguer cette responsabilité aux paramètres par défaut d’un fournisseur de cloud
• Journalisation prête pour l’audit — des journaux détaillés de sauvegarde et de restauration qui répondent aux exigences de documentation de la loi HIPAA et répondent aux besoins des enquêtes judiciaires
• Prise en charge des environnements hybrides et multicloud — une protection cohérente des données dans les environnements sur site, en cloud privé et en cloud public à partir d’une interface de gestion unique
• Déploiement flexible — l’architecture de Bacula s’adapte à l’infrastructure de santé existante plutôt que d’imposer une approche de remplacement complet

En fin de compte, tous les programmes de sécurité cloud dans le secteur de la santé peuvent être évalués à l’aune d’une seule question : lorsqu’un incident survient, avec quelle rapidité et quelle efficacité les opérations peuvent-elles être rétablies ? Bacula Systems est conçu pour apporter une réponse définitive — dans des environnements informatiques de santé réels, hybrides, multicloud et hérités.

FAQ

Pourquoi les établissements de santé peinent-ils à maintenir des politiques de sécurité cloud cohérentes dans des environnements de santé multicloud et hybrides ?

Les environnements cloud utilisés par les établissements de santé sont rarement construits à partir de zéro. Ils sont souvent le fruit d’années d’achats indépendants, de fusions, d’acquisitions et d’accords avec des fournisseurs. Chaque environnement dispose de son propre modèle de contrôle d’accès, de son propre mécanisme de journalisation et de ses propres outils de surveillance de la sécurité. L’application d’une politique de protection des données de santé personnelles (PHI) nécessitera une couche de gestion centralisée que la plupart des établissements n’ont pas encore mise en place à ce jour.

Comment les établissements de santé doivent-ils mener leurs enquêtes sur les violations de sécurité dans le cloud lorsque les journaux et les preuves sont répartis entre plusieurs fournisseurs ?

La qualité d’une enquête sur une violation dépend entièrement de la qualité des journaux qui l’étayent. Les environnements multicloud stockent rarement les journaux en un seul emplacement ou dans un format cohérent. Les journaux devraient être transmis en temps réel depuis chaque environnement cloud vers un référentiel centralisé, distinct et sécurisé, plutôt que d’être récupérés de manière réactive après la découverte d’une violation. Les procédures d’investigation pour chaque fournisseur, y compris la manière d’obtenir les preuves conservées, devraient être prédéfinies avant une violation plutôt que d’être élaborées pendant celle-ci.

Pourquoi l’automatisation native du cloud et les pipelines DevSecOps peuvent-ils exposer accidentellement des données de santé sensibles à grande échelle ?

Si une erreur de configuration est intégrée de manière définitive dans un pipeline automatisé, elle n’aura pas d’impact sur un seul système. Elle se propagera à tous les environnements avec lesquels ce pipeline interagit. Un système de déploiement automatisé conçu pour créer une ressource de stockage accordant des autorisations d’accès ouvertes par défaut peut reproduire cette erreur des centaines de fois avant même qu’un être humain ne se rende compte de son existence. Dans le secteur de la santé, un contrôle de sécurité codé dans un pipeline automatisé n’est pas une simple commodité technique ; il s’agit d’une obligation en matière de confidentialité des patients.