Ce que HIPAA exige réellement d’une architecture
La règle de sécurité impose des sauvegardes administratives, physiques et techniques. Les sauvegardes physiques du centre de données relèvent de Microsoft dans le modèle de responsabilité partagée. Tout le reste est à vous, et l’essentiel est architectural.
Contrôle d’accès. L’identifiant unique par utilisateur et la procédure d’accès d’urgence sont requis. La déconnexion automatique et le chiffrement au repos sont adressables. Adressable ne veut pas dire facultatif : cela veut dire le mettre en œuvre, ou consigner pourquoi une mesure équivalente est raisonnable et appropriée. Cette justification écrite est un artefact, et son absence est une constatation.
Contrôles d’audit. Vous devez enregistrer et examiner l’activité dans les systèmes contenant des renseignements de santé électroniques. Notez le mot examiner : activer des journaux sans jamais les interroger ne satisfait ni la règle ni un enquêteur.
Intégrité, authentification et sécurité de transmission. La donnée ne peut être altérée ou détruite sans que cela se voie, les personnes et les services doivent prouver leur identité, et les renseignements en transit doivent être protégés.
Analyse de risque. Requise, récurrente, et c’est le manquement le plus souvent cité dans les décisions d’application. Elle doit couvrir chaque endroit où les renseignements sont créés, reçus, conservés ou transmis, ce qui est impossible sans un inventaire réel.
Conservation de la documentation. Six ans à compter de la création ou de la dernière date d’effet. C’est ce nombre qui dicte la conception de la journalisation et de l’archivage, et non l’inverse.
Notification de brèche. Aux personnes sans délai déraisonnable et au plus tard soixante jours, au ministère, et aux médias au-delà de cinq cents résidents d’un État. Soixante jours ne sont généreux que si vous avez détecté l’événement le premier jour.
L’entente de partenaire commercial. Microsoft la signe pour les services visés. Un service en préversion, ou hors de cette liste, n’est pas couvert. Un seul type de ressource choisi sans attention rompt la chaîne d’assurance de toute la charge de travail.
Ce que nous concevons et imposons dans Azure
Les renseignements de santé obtiennent leur propre frontière. Un groupe d’administration et une portée de souscription dédiés, avec les politiques assignées au-dessus de la souscription pour qu’un propriétaire ne puisse pas les assouplir. C’est la décision qui rend tous les contrôles suivants peu coûteux, et celle que la plupart des parcs ont sautée parce que tout a commencé dans une souscription unique.
Le choix des services devient une politique. Une assignation de types de ressources autorisés limitée aux services couverts par l’entente, les préversions refusées, et un refus sur toute ressource dépourvue d’étiquette de classification.
Aucun chemin public. Points de terminaison privés sur Azure SQL, le stockage, Key Vault et les services d’IA, zones DNS privées, accès réseau public refusé par politique, et segmentation hub-and-spoke comme décrit sur la page landing zone Azure. Transport imposé à TLS 1.2 au minimum.
Un chiffrement dont vous pouvez raconter l’histoire des clés. Chiffrement de plateforme au repos comme base, clés gérées par le client dans Key Vault ou Managed HSM lorsque vous devez détenir et faire tourner la clé vous-même, et un calendrier de rotation documenté. Si un questionnaire de sécurité demande qui peut déchiffrer vos données, la réponse devrait être un schéma, pas un paragraphe.
Une identité unique, aucun compte partagé. Authentification Microsoft Entra ID sur les services de données plutôt que des comptes de base de données partagés, Privileged Identity Management pour un accès administratif demandé et limité dans le temps, accès conditionnel avec fréquence de connexion et contrôles de session qui couvrent la déconnexion automatique, et des comptes de secours documentés, testés et alertés à chaque usage.
Des contrôles d’audit qui survivent à une vraie enquête. Paramètres de diagnostic sur chaque ressource porteuse, et surtout journalisation du plan de données sur le stockage et les bases de données, désactivée par défaut et pourtant exactement ce qu’un enquêteur veut. Journaux de connexion et d’audit Entra, rétention alignée sur l’obligation de six ans avec archivage au-delà de la fenêtre interactive.
Une détection calibrée sur le délai de soixante jours. Microsoft Defender for Cloud pour la posture et les vulnérabilités, Microsoft Sentinel pour l’exportation massive, les accès anormaux et les déplacements impossibles, et un chemin de notification écrit qui nomme la personne qui décide qu’il y a brèche.
L’IA sur la donnée clinique, avec la frontière écrite. Inférence dans votre locataire sur réseau privé, récupération qui respecte les permissions au niveau du dossier plutôt qu’un index plat, journalisation complète des invites et des réponses, et demande d’exemption de la surveillance des abus d’Azure OpenAI lorsque la rétention des invites n’est pas acceptable. La page santé traite la version sectorielle de ce sujet.
La preuve que produit le pipeline
- L’état de conformité Azure Policy rattaché à chaque spécification technique.
- Le tableau de conformité réglementaire Defender for Cloud pour l’initiative HIPAA HITRUST, suivi dans le temps plutôt que capturé une fois.
- L’inventaire des ressources déployées confronté à la liste des services couverts par l’entente.
- Les journaux d’accès au plan de données, avec des requêtes enregistrées répondant à qui a lu quoi et quand.
- L’historique d’activation PIM et les revues d’accès pour toute personne ayant un chemin vers la donnée.
- L’historique de rotation des clés Key Vault.
- La preuve de configuration de rétention et d’archivage contre l’exigence de six ans.
- L’inventaire et les flux qui alimentent l’analyse de risque récurrente.
Ce que vous gardez
- Un schéma de flux : où la donnée entre, où elle repose, où elle circule, quels tiers la touchent, tenu à jour par le pipeline qui déploie le parc.
- Un registre des spécifications adressables, avec la décision et la justification de chacune.
- Le jeu de politiques en code, assignation des types de ressources autorisés comprise.
- Le cahier d’analyse de risque, avec les faits d’architecture déjà remplis.
- Les requêtes de preuve enregistrées et le plan de rétention qui les sous-tend.
Pour qui
Les entreprises de santé numérique dont le premier client hospitalier ou assureur envoie un questionnaire de sécurité de deux cents lignes. Les organisations de soins qui quittent des systèmes sur place. Les partenaires commerciaux dont les clients répercutent les obligations HIPAA par contrat. Et toute organisation dont les renseignements de santé partagent aujourd’hui la souscription de tout le reste, ce qui est le cas de la plupart des parcs bâtis progressivement.
Pour qui ce n’est pas
Si vous cherchez un certificat HIPAA, aucun fournisseur ne peut vous en vendre un et ceux qui le laissent croire vendent un logo. Si séparer la donnée dans sa propre frontière est écarté parce que c’est incommode, le reste du travail est cosmétique. Et si votre donnée de santé est québécoise plutôt qu’américaine, HIPAA est le mauvais cadre : la Loi 25 et la législation provinciale sont ce qui vous lie.
Aller plus loin
- Architecture de conformité, la mission qui livre ce travail.
- SOC 2 sur Azure, ce que le client grand compte demande ensuite.
- Loi 25 et résidence des données, pour la donnée de santé canadienne.
- Santé, le contexte sectoriel.
- Conformité, le pilier.
Questions fréquentes
Azure est-il conforme à HIPAA ?
Aucune plateforme n’est conforme en soi. Microsoft signe une entente de partenaire commercial couvrant les services visés, ce qui est nécessaire et insuffisant. La conformité dépend des services que vous utilisez, du cloisonnement et du chiffrement des renseignements de santé, de qui peut les atteindre et de ce que vous journalisez. Cette configuration, c’est le travail.
Peut-on être certifié HIPAA ?
Ce certificat n’existe pas. Le Office for Civil Rights applique la règle, il ne certifie pas. HITRUST CSF est une certification privée que beaucoup de clients acceptent comme preuve, et c’est souvent un SOC 2 qui est réellement demandé. Nous construisons vers le référentiel sur lequel vous êtes mesurés.
Quelle est la différence entre une spécification requise et adressable ?
Adressable ne veut pas dire facultative. Cela veut dire mettre en œuvre la spécification, ou documenter pourquoi elle n’est pas raisonnable et appropriée chez vous et quelle mesure équivalente la remplace. Cette justification écrite est elle-même l’artefact qu’un enquêteur demande, et son absence est une constatation.
Tous les services Azure sont-ils couverts par l’entente ?
Non. L’entente couvre une liste définie de services, et les fonctionnalités en préversion en sont généralement exclues. Nous imposons la liste permise par Azure Policy, pour qu’un développeur ne place pas par accident des renseignements de santé dans un service hors portée : cette seule erreur rompt la chaîne d’assurance.
Combien de temps devons-nous conserver les journaux ?
HIPAA exige la conservation de la documentation pendant six ans à compter de sa création ou de sa dernière date d’effet, et les contrôles d’audit doivent rester examinables sur cette période. Nous réglons la rétention interactive de Log Analytics sur le besoin opérationnel et archivons le reste, ce qui coûte bien moins cher que six ans à chaud.
Sommes-nous visés si nous sommes une entreprise québécoise ?
Vous l’êtes si vous agissez comme partenaire commercial d’une entité américaine visée, ce qui arrive dès le premier client hospitalier ou assureur aux États-Unis. Si la donnée est plutôt de la donnée de santé québécoise, ce sont la Loi 25 et la législation provinciale qui s’appliquent, pas HIPAA.
Une question sur ce mandat ?
Trois champs. Un architecte le lit et répond en un jour ouvrable.