HIPAA dans le cloud : architecture conforme

HIPAA est la loi américaine qui encadre la protection des données de santé. Pour un éditeur de logiciel santé français qui vise le marché des États-Unis, elle devient un prérequis contractuel : sans conformité démontrable, aucun établissement de soins américain ne vous confiera de données de patients. Cette page explique ce que HIPAA exige réellement dans le cloud, comment construire une architecture conforme sur Microsoft Azure et AWS (BAA, chiffrement, contrôle des accès, journalisation), et comment situer HIPAA par rapport à la certification HDS française.

• Santé, marché US
• PHI / ePHI
• Security & Privacy Rule
• Business Associate Agreement
• Azure & AWS

HIPAA dans le cloud : de quoi parle-t-on ?

HIPAA (Health Insurance Portability and Accountability Act, 1996), renforcée par le HITECH Act en 2009 et par l'Omnibus Rule en 2013, est le socle réglementaire de la protection des données de santé aux États-Unis. Elle est appliquée par l'Office for Civil Rights (OCR), rattaché au ministère américain de la santé (HHS). Contrairement à une norme comme ISO 27001, HIPAA n'est pas un référentiel volontaire : c'est une obligation légale, opposable, assortie de sanctions.

Point essentiel, souvent mal compris depuis la France : HIPAA ne se « certifie » pas. Aucun organisme officiel ne délivre un label « conforme HIPAA ». Un prestataire qui vous vend une infrastructure « certifiée HIPAA » vend une formule marketing, pas une réalité juridique. La conformité se démontre par des mesures techniques et organisationnelles documentées, une analyse de risque à jour, des contrats en règle, et la capacité à produire ces preuves lors d'un contrôle ou après un incident. C'est une différence de nature avec la logique de certification française, sur laquelle nous revenons plus bas.

Qui est concerné : covered entities et business associates

HIPAA distingue deux grandes catégories d'acteurs, et cette distinction commande tout le reste.

• Les covered entities (entités couvertes). Ce sont les acteurs de santé au premier chef : établissements et professionnels de santé qui transmettent des données de santé sous forme électronique, organismes de couverture santé (health plans), et chambres de compensation de données de santé (health care clearinghouses).
• Les business associates (sous-traitants). Ce sont les prestataires qui traitent des PHI pour le compte d'une covered entity : hébergeur cloud, éditeur SaaS de santé, prestataire d'analyse de données, service de facturation. Un éditeur de logiciel santé français qui traite des données de patients américains est un business associate. À ce titre, il est directement soumis à HIPAA depuis l'Omnibus Rule de 2013, et il doit lui-même contractualiser avec ses propres sous-traitants (les subcontractors).

Cette chaîne de responsabilité est le point d'entrée du sujet cloud. Quand un éditeur français héberge son application santé sur Azure ou AWS pour servir des clients américains, il devient business associate de ses clients covered entities, et le fournisseur cloud devient son propre business associate. Chaque maillon de la chaîne doit être couvert par un contrat dédié, le BAA, faute de quoi toute la conformité s'effondre.

PHI et ePHI : ce que HIPAA protège exactement

HIPAA protège les PHI (Protected Health Information) : toute information de santé qui permet, seule ou combinée, d'identifier une personne. Dans le cloud, on manipule presque toujours leur forme électronique, les ePHI (electronic PHI), qui sont au cœur de la Security Rule.

La réglementation liste 18 identifiants dont la présence, associée à une donnée de santé, qualifie une information de PHI : nom, adresse, dates liées à l'individu, numéros de téléphone, adresses e-mail, numéros de sécurité sociale, numéros de dossier médical, identifiants de compte, données biométriques, photographies du visage, adresses IP, entre autres. Retirer complètement ces identifiants, selon les méthodes prévues par HIPAA (Safe Harbor ou détermination par un expert), produit une donnée dé-identifiée qui sort du champ de la loi.

Cette notion est stratégique dans une architecture cloud : plus vous séparez, minimisez et dé-identifiez les PHI, plus vous réduisez la surface soumise à HIPAA, et donc le coût et le risque de conformité. Cloisonner les ePHI dans un périmètre dédié, chiffré et étroitement journalisé, plutôt que de les laisser se disséminer dans tout le système d'information, est l'un des premiers réflexes d'architecture que nous cadrons avec les prestataires du réseau.

La Security Rule : trois familles de sauvegardes

La Security Rule est le cœur technique de HIPAA appliqué au cloud. Elle impose des « sauvegardes » (safeguards) réparties en trois familles. Chaque exigence est classée « obligatoire » (required) ou « adressable » (addressable) : une mesure adressable n'est pas facultative, elle doit être mise en œuvre ou remplacée par une mesure équivalente justifiée et documentée.

• Sauvegardes administratives

  Analyse de risque documentée, politique de gestion des accès, désignation d'un responsable sécurité, formation, gestion des incidents, procédures de sanction interne. C'est la partie gouvernance, la plus souvent négligée.

• Sauvegardes physiques

  Contrôle d'accès aux installations, sécurité des postes de travail et des supports. Dans le cloud public, cette couche est assurée par le datacenter d'Azure ou d'AWS, couvert par le BAA.

• Sauvegardes techniques

  Contrôle d'accès, contrôles d'audit (journalisation), intégrité des données, authentification des personnes et des services, sécurité des transmissions (chiffrement en transit). C'est le cœur de votre configuration cloud.

La Privacy Rule, complémentaire, encadre l'usage et la divulgation des PHI (principe du minimum nécessaire, droits des patients sur leurs données). La Breach Notification Rule, enfin, impose de notifier une violation de données de santé : à l'OCR et aux personnes concernées sous 60 jours, avec information des médias si l'incident touche au moins 500 personnes. Dans le cloud, cela suppose une capacité de détection et de traçabilité qui n'existe que si la journalisation a été mise en place avant l'incident.

Le Business Associate Agreement (BAA) avec Azure et AWS

Le BAA (Business Associate Agreement, parfois Business Associate Addendum) est le contrat qui rend l'hébergement de PHI possible dans le cloud. Sans lui, utiliser Azure ou AWS pour des données de santé américaines est une non-conformité de principe, quelle que soit la qualité de votre configuration. Le BAA formalise les responsabilités du fournisseur en tant que business associate : sécurité des services couverts, gestion des incidents, restrictions d'usage des données.

• Microsoft Azure. Microsoft propose un BAA intégré à ses conditions contractuelles pour les entreprises (le Microsoft Product Terms et le Data Protection Addendum). Il couvre les services Azure et Microsoft 365 entrant dans son périmètre HIPAA. Pour un client sous contrat entreprise, le BAA s'applique sans négociation spécifique, mais il vous appartient de vérifier que chaque service que vous utilisez est bien couvert.
• AWS. AWS met à disposition un Business Associate Addendum activable en libre-service via AWS Artifact, le portail de conformité et de documents contractuels. Une fois le BAA accepté, vous devez restreindre le traitement des PHI aux seuls services éligibles HIPAA de la liste publiée par AWS.

Le point commun aux deux fournisseurs est fondamental : le BAA ne couvre que certains services, et ne vous dispense d'aucune obligation de configuration. Signer le BAA est nécessaire, jamais suffisant. C'est la logique du modèle de responsabilité partagée appliquée à HIPAA, que nous détaillons sur le pilier sécurisation d'infrastructure cloud.

Services éligibles HIPAA chez Azure et AWS

Ni Azure ni AWS ne rendent l'intégralité de leur catalogue utilisable pour des ePHI. Chacun publie une liste de services éligibles HIPAA (dits HIPAA Eligible Services chez AWS). Une règle d'architecture en découle : les PHI ne doivent transiter, être traitées ou stockées que par des services de cette liste. Voici la correspondance des briques les plus courantes.

À vérifier au cas par cas. Ces listes évoluent, et un service peut être éligible dans une région et pas dans une autre. Avant toute décision d'architecture, la liste officielle du fournisseur fait foi. Utiliser un service hors périmètre pour manipuler des ePHI, même temporairement (un espace de test, un pipeline d'export), suffit à créer une non-conformité.

Architecture conforme HIPAA sur Azure et AWS

Une fois le BAA signé et le périmètre de services restreint, la conformité se joue dans la configuration. Les mêmes leviers reviennent sur les deux plateformes, alignés sur les sauvegardes techniques de la Security Rule.

Chiffrement au repos et en transit

Le chiffrement doit être systématique et, surtout, prouvable sur chaque ressource contenant des ePHI. Au repos, activez le chiffrement des disques, du stockage objet, des bases et des sauvegardes, avec des clés gérées par le client (CMK) via Azure Key Vault ou AWS KMS, plutôt que les clés par défaut du fournisseur. Vous gardez ainsi la maîtrise de la rotation et de la révocation. En transit, imposez TLS sur tous les flux, y compris internes entre composants applicatifs. La méthode technique complète (chiffrement at-rest/in-transit, gestion du cycle de vie des clés) est traitée sur le pilier sécurisation d'infrastructure cloud.

Contrôle d'accès et moindre privilège

La sauvegarde technique « contrôle d'accès » se traduit par un IAM strict : rôles au moindre privilège via Entra ID (Azure) ou IAM Identity Center (AWS), authentification multifacteur généralisée, comptes d'administration à privilèges élevés activés juste-à-temps (Privileged Identity Management côté Azure), et revues d'accès périodiques documentées. Chaque accès à une ePHI doit être attribuable à une identité unique : les comptes partagés sont incompatibles avec la traçabilité qu'exige HIPAA.

Contrôles d'audit et intégrité

HIPAA exige des contrôles d'audit : enregistrer et pouvoir examiner l'activité sur les systèmes qui contiennent des ePHI. C'est l'objet de la section suivante. L'exigence d'intégrité, elle, impose de garantir que les ePHI ne sont ni altérées ni détruites de façon non autorisée : versionnage du stockage, verrous d'immuabilité sur les sauvegardes, contrôles de cohérence.

Journalisation et détection : la mémoire de la conformité

Les contrôles d'audit de la Security Rule et la Breach Notification Rule imposent une capacité de journalisation robuste. Sans elle, vous ne pouvez ni prouver qui a accédé à quelles ePHI, ni détecter une violation, ni notifier dans les délais légaux. C'est le chantier le plus structurant, et celui que l'on découvre trop tard s'il n'a pas été posé dès le départ.

• Côté AWS. CloudTrail enregistre les appels d'API du plan de contrôle (qui a fait quoi, quand), CloudWatch Logs centralise les journaux applicatifs et d'accès aux données, GuardDuty et Security Hub détectent les comportements anormaux. Les journaux doivent être protégés contre l'altération et conservés selon une durée cohérente avec vos obligations contractuelles américaines, souvent 6 ans pour la documentation HIPAA.
• Côté Azure. Azure Monitor et Log Analytics centralisent les journaux, l'Activity Log trace les opérations sur les ressources, Microsoft Defender for Cloud assure la posture et la détection. Les mêmes exigences de conservation et d'inaltérabilité s'appliquent.

La durée de conservation est un point de vigilance particulier : HIPAA attend une rétention longue de la documentation, bien au-delà des 90 jours souvent configurés par défaut. Ce sujet de journalisation et de détection est développé côté technique sur le pilier sécurisation d'infrastructure cloud, et côté organisationnel dans notre approche de la cybersécurité cloud.

HIPAA vs HDS : le pont pour l'audience française

C'est la question qui revient systématiquement côté français : « HIPAA, est-ce comme le HDS ? » Les deux protègent des données de santé, mais leur logique diffère profondément. Les confondre conduit à viser le mauvais objectif, ou à payer pour un dispositif inadapté au marché ciblé.

La différence structurante : HIPAA ne se certifie pas, HDS se certifie. Pour HDS, c'est l'hébergeur qui détient le certificat, pas votre application. Azure et AWS disposent de régions et services certifiés HDS pour le marché français. Un éditeur santé français qui adresse à la fois l'Europe et les États-Unis devra donc mener deux démarches distinctes : viser un hébergement certifié HDS pour ses clients français, et bâtir une conformité HIPAA documentée avec BAA pour ses clients américains. Ces deux volets peuvent partager le même socle technique (chiffrement, IAM, journalisation), mais répondent à des logiques réglementaires séparées.

Le panorama complet des référentiels français et européens (RGPD, HDS, SecNumCloud, NIS2) est traité sur notre page conformité cloud, et l'hébergement de santé en France sur notre approche du secteur santé. HIPAA n'y apparaît qu'en survol : cette page-ci est la référence sur le volet américain.

Sauvegardes, continuité et objectifs RTO/RPO

La disponibilité des données de santé n'est pas un détail de confort : la Security Rule inclut un volet contingency planning (plan de secours) qui impose des sauvegardes, un plan de reprise et des procédures de fonctionnement en mode dégradé. Un système de santé indisponible ou une perte de données de patients constituent des incidents à part entière.

Concrètement, cela se traduit par des exigences de continuité que l'on retrouve dans toute architecture sérieuse :

• Sauvegardes chiffrées, testées et immuables, isolées dans un compte ou un abonnement distinct pour résister au ransomware et à la compromission d'un administrateur (verrous d'immuabilité sur Azure Backup et AWS Backup Vault Lock).
• Objectifs RTO/RPO définis en fonction de la criticité des services de santé : le RTO (durée maximale d'interruption acceptable) et le RPO (perte de données maximale acceptable) dictent l'architecture, mono-zone, multi-zones ou multi-régions.
• Un plan de reprise testé par exercice réel : un PRA non testé n'est pas un PRA. Notre approche détaillée de la continuité figure sur la page PRA cloud.

La restauration doit être régulièrement validée : pouvoir prouver que l'on sait remettre en service des ePHI intactes fait partie de la conformité, pas seulement de la bonne pratique.

La démarche de mise en conformité HIPAA sur le cloud

Aligner un environnement cloud sur HIPAA suit une trajectoire structurée. Voici les étapes que nous cadrons avec le client avant de mobiliser les prestataires du réseau.

1. Cartographie des PHI et du périmètre Identifier où résident les ePHI, quels flux les transportent, quels services les traitent. On cloisonne et on minimise pour réduire la surface soumise à HIPAA.
2. Analyse de risque (risk assessment) Exigence explicite de la Security Rule : évaluer les menaces sur la confidentialité, l'intégrité et la disponibilité des ePHI, et documenter les décisions de traitement. C'est la pièce fondatrice du dossier.
3. Signature et cadrage du BAA Activer le BAA avec Azure ou AWS, et contractualiser les BAA avec vos propres sous-traitants. Vérifier que tous les services utilisés sont éligibles HIPAA.
4. Mise en œuvre des sauvegardes techniques Chiffrement avec clés maîtrisées, IAM au moindre privilège, journalisation centralisée et inaltérable, sauvegardes immuables, le tout décrit en Infrastructure as Code.
5. Politiques et procédures Formaliser les sauvegardes administratives : politique d'accès, gestion des incidents, procédure de notification de violation sous 60 jours, formation des équipes.
6. Évaluation et préparation aux audits clients Constituer le dossier de preuves qui répondra aux questionnaires de sécurité de vos clients américains et à un éventuel contrôle de l'OCR.

Budget, durée et livrables

Le coût de préparation d'un périmètre cloud conforme HIPAA dépend surtout de la maturité de départ et de l'étendue des ePHI à cloisonner. Les repères ci-dessous concernent la préparation du périmètre cloud et l'outillage des preuves, hors accompagnement juridique spécialisé en droit américain.

• 3 à 10 jpréparation du périmètre cloud (selon maturité)
• 8 à 18 k€budget indicatif, sur devis selon le périmètre
• BAAcontrat préalable indispensable, Azure ou AWS
• IaCconfiguration versionnée, réutilisable comme preuve

Les livrables types d'une préparation cloud HIPAA : la cartographie des ePHI et l'analyse de risque, l'architecture cible documentée et son code Infrastructure as Code versionné dans vos dépôts, les politiques de contrôle d'accès et de journalisation, la trame de procédure de notification de violation, et un dossier de preuves prêt à répondre aux questionnaires de sécurité de vos clients américains. Tout ce qui est construit vous appartient et reste reprenable par vos équipes.

Notre rôle : intermédiaire indépendant

Pour situer HIPAA dans l'ensemble de vos obligations, voyez les référentiels voisins que nous couvrons : le guide de conformité ISO 27001 dans le cloud qui sert souvent de socle de management, le rapport SOC 2 dans le cloud fréquemment demandé par les clients nord-américains d'un éditeur SaaS, la résilience opérationnelle DORA pour le secteur financier, et le panorama français complet sur la conformité cloud. Les éditeurs concernés relèvent le plus souvent du secteur SaaS. Pour aller plus loin, consultez nos services et le guide du cloud.

FAQ : HIPAA dans le cloud

Peut-on être « certifié HIPAA » ?

Non. HIPAA est une loi fédérale américaine sans organisme de certification officiel. On ne devient pas « certifié HIPAA » : on démontre sa conformité par une analyse de risque documentée, des mesures techniques et organisationnelles prouvables, et des contrats en règle. Tout prestataire qui vend une infrastructure « certifiée HIPAA » emploie une formule marketing sans valeur juridique.

Héberger sur Azure ou AWS rend-il automatiquement conforme HIPAA ?

Non. Le fournisseur ne couvre que sa part du modèle de responsabilité partagée, uniquement sur ses services éligibles HIPAA, et seulement si un Business Associate Agreement (BAA) est signé. Votre application, vos accès, votre chiffrement et votre journalisation restent votre responsabilité et doivent être configurés et prouvés par vos soins.

Qu'est-ce qu'un Business Associate Agreement (BAA) ?

Le BAA est le contrat qui autorise le traitement de données de santé américaines (PHI) par un sous-traitant, dont le fournisseur cloud. Il formalise les responsabilités du fournisseur en tant que business associate. Sans BAA, utiliser Azure ou AWS pour des PHI est une non-conformité de principe, quelle que soit la qualité de la configuration technique.

Comment obtenir un BAA chez Azure et chez AWS ?

Chez Microsoft, le BAA est intégré aux conditions contractuelles entreprise (Product Terms et Data Protection Addendum) et couvre les services Azure et Microsoft 365 concernés. Chez AWS, le Business Associate Addendum s'active en libre-service via AWS Artifact. Dans les deux cas, il faut restreindre le traitement des PHI aux seuls services éligibles HIPAA.

Qu'est-ce que le PHI et l'ePHI ?

Le PHI (Protected Health Information) désigne toute information de santé permettant d'identifier une personne, via l'un des 18 identifiants listés par HIPAA (nom, dates, adresses, numéros de dossier, etc.). L'ePHI est sa forme électronique, celle que l'on manipule dans le cloud et que vise la Security Rule. Dé-identifier correctement une donnée la fait sortir du champ de HIPAA.

Le chiffrement est-il obligatoire sous HIPAA ?

Le chiffrement des ePHI est classé « adressable » et non « obligatoire », mais il est en pratique incontournable. Chiffrer selon les standards reconnus (NIST) ouvre le safe harbor de la Breach Notification Rule : une donnée volée mais correctement chiffrée n'est pas considérée comme compromise, ce qui vous dispense de l'obligation de notification. Le chiffrement est donc autant une protection qu'une assurance juridique.

Quelles sont les trois familles de sauvegardes de la Security Rule ?

La Security Rule impose des sauvegardes administratives (analyse de risque, politiques, formation, gestion des incidents), physiques (sécurité des installations et des supports, assurée par le datacenter cloud) et techniques (contrôle d'accès, contrôles d'audit, intégrité, authentification, sécurité des transmissions). Les sauvegardes techniques constituent le cœur de votre configuration Azure ou AWS.

Quelle est la différence entre HIPAA et la certification HDS ?

HIPAA est une loi américaine de conformité déclarative, sans certificateur, contrôlée après coup par l'OCR. La HDS est une certification française obligatoire qui vise l'hébergeur des données de santé. HIPAA concerne les données de patients américains, HDS les données de santé hébergées en France. Un éditeur adressant les deux marchés mène deux démarches distinctes sur un socle technique commun.

Comment gérer la journalisation des accès aux ePHI ?

Via les services natifs : CloudTrail et CloudWatch Logs côté AWS, Azure Monitor, Log Analytics et Activity Log côté Azure, complétés par GuardDuty ou Defender for Cloud pour la détection. Les journaux doivent être inaltérables, chaque accès attribuable à une identité unique, et la conservation longue, souvent jusqu'à 6 ans pour la documentation HIPAA, bien au-delà des 90 jours par défaut.

Que dois-je faire en cas de violation de données de santé ?

La Breach Notification Rule impose de notifier l'OCR (HHS) et les personnes concernées sous 60 jours, avec information des médias si l'incident touche au moins 500 personnes. Cette capacité suppose une détection et une traçabilité mises en place avant l'incident. Si les données étaient chiffrées selon les standards NIST, le safe harbor peut vous dispenser de notification.

Un éditeur SaaS santé français est-il concerné par HIPAA ?

Oui, dès qu'il traite des données de patients américains pour le compte d'un acteur de santé américain. Il devient alors business associate et est directement soumis à HIPAA depuis l'Omnibus Rule de 2013. Il doit signer un BAA avec ses clients covered entities et avec ses propres sous-traitants, dont le fournisseur cloud.

Combien coûte la préparation d'un cloud conforme HIPAA ?

À titre indicatif, la préparation du périmètre cloud et l'outillage des preuves se situent entre 8 000 et 18 000 €, pour 3 à 10 jours selon la maturité de départ et l'étendue des ePHI. Ce budget est présenté en fourchette, sur devis après cadrage. Un accompagnement juridique en droit de la santé américain, s'il est nécessaire, se contractualise séparément.

Vous éditez une solution de santé et visez le marché américain ? Faites le point en quelques minutes avec notre diagnostic en ligne, ou contactez-nous : nous cadrons votre périmètre ePHI et vous orientons vers des prestataires qualifiés pour bâtir une architecture conforme HIPAA sur Azure ou AWS. Réponse sous 48 h ouvrées.