HIPAA : auditer les garanties techniques côté Microsoft
Les organisations de santé et leurs sous-traitants tournent sous Microsoft comme tout le monde — avec des données de santé électroniques qui circulent dans les mêmes boîtes aux lettres, les mêmes canaux Teams et les mêmes sites SharePoint, authentifiées par le même annuaire. La Security Rule de la HIPAA a des choses précises à dire sur qui peut atteindre ces données et sur la façon de le prouver.
Qui est concerné
La Security Rule de la HIPAA s'applique aux entités couvertes — organismes d'assurance santé, chambres de compensation et la plupart des professionnels de santé — et à leurs sous-traitants, c'est-à-dire tout prestataire qui manipule des données de santé électroniques pour leur compte. Si vous êtes éditeur, MSP ou cabinet de conseil au service de clients du secteur santé, vous êtes très probablement un sous-traitant avec des obligations directes, et pas seulement un tiers lié par contrat.
Une cible mouvante. La Security Rule fait l'objet de propositions de modernisation qui renforceraient plusieurs exigences, notamment autour de l'authentification multifacteur et du chiffrement. Vérifiez l'état courant du texte avec un conseil juridique ou votre responsable conformité avant de bâtir un programme sur une lecture particulière.
Les trois familles de garanties
La Security Rule organise ses exigences en garanties administratives, physiques et techniques. Un audit de configuration Microsoft parle aux garanties techniques et à une partie des administratives. Les garanties physiques — accès aux locaux, sécurité des postes, mise au rebut des équipements — sont hors de portée de tout outil de configuration.
Contrôle d'accès
Quatre points comptent ici, et chacun se traduit par un réglage Microsoft concret :
- Identification unique des utilisateurs. Chaque utilisateur a son propre compte. Les connexions partagées — le compte de l'accueil, l'identifiant générique d'un poste clinique, la boîte de service dont le mot de passe traîne dans un tiroir — sont un problème direct, et elles sont fréquentes. Un audit fait remonter les comptes qui ressemblent à des comptes partagés : pas de MFA, pas de schéma de connexion interactive récent, nommage générique.
- Procédure d'accès d'urgence. Il vous faut un moyen d'entrer documenté quand l'authentification normale échoue. Côté Entra ID, c'est le compte de secours : exclu des stratégies d'accès conditionnel susceptibles de vous enfermer dehors, identifiants stockés en sécurité, et surveillé. Se tromper ici, c'est se retrouver soit verrouillé hors de son propre tenant, soit avec un super-compte sans surveillance.
- Déconnexion automatique. Les réglages d'expiration de session et d'inactivité, particulièrement pertinents là où le personnel clinique partage des postes.
- Chiffrement. Au repos et en transit, sur l'ensemble de la pile de collaboration.
Contrôles d'audit
Vous devez pouvoir enregistrer et examiner l'activité sur les systèmes qui contiennent des données de santé. En pratique : le journal d'audit unifié réellement activé, des journaux de connexion et d'annuaire conservés assez longtemps pour enquêter, et l'audit des boîtes aux lettres en marche. Un nombre surprenant de tenants échouent ici parce que l'audit n'a jamais été activé au niveau du tenant — et on ne produit pas rétroactivement des journaux qu'on n'a jamais collectés.
Authentification des personnes et des entités
Vérifier que celui qui demande l'accès est bien celui qu'il prétend être. C'est là que vit la couverture MFA, et c'est là que les protocoles d'authentification héritée font le plus de dégâts : POP, IMAP et SMTP AUTH contournent entièrement l'authentification moderne, ce qui vide de sa substance la politique que vous avez écrite.
Sécurité des transmissions
Protéger les données de santé en transit. Pour Microsoft 365, les risques concrets touchent au flux de messagerie : les règles de transfert automatique vers des boîtes externes sont un vecteur de fuite classique et un constat d'audit classique, au même titre que des réglages de partage externe SharePoint et OneDrive qui laissent un lien vers un document contenant des données de santé voyager plus loin que prévu.
Le recouvrement avec les garanties administratives
Deux garanties administratives s'appuient largement sur la même preuve technique :
- La gestion des accès à l'information — autoriser l'accès selon le rôle, et le revoir. Les attributions de rôles à privilèges et les appartenances aux groupes en sont la preuve.
- La sécurité du personnel — y compris les procédures de départ. Les comptes restés actifs après le départ d'une personne sont l'échec de contrôle d'accès le plus cité de tous les référentiels, et la HIPAA ne fait pas exception.
Deux périmètres, un seul corpus de preuves
Une organisation qui tourne sous Microsoft n'en exploite rarement qu'un seul des deux. Le tenant cloud et l'annuaire on-premises portent chacun leur part de l'exigence, et un évaluateur qui ne regarde que le premier passe à côté de l'endroit où se trouve l'essentiel du risque.
| Périmètre | Ce qu'il apporte à l'exigence |
|---|---|
| Entra ID & Microsoft 365 | Robustesse de l'authentification, accès conditionnel, rôles à privilèges, consentement applicatif, accès invité, politiques de messagerie et de partage, rétention des journaux d'audit. |
| Active Directory | Appartenance aux groupes privilégiés, comptes de service, délégations ACL, configuration Kerberos, modèles de certificat, approbations, couverture LAPS — et les chemins d'escalade qui les relient. |
La correspondance normative est la même dans les deux, et c'est ce qui fait que les preuves s'additionnent au lieu de rester dans deux piles séparées.
Pourquoi la revue manuelle échoue ici
Les équipes informatiques du secteur santé sont généralement sous tension, souvent en charge d'un mélange de services cloud et de systèmes on-premises, parfois avec des applications cliniques qui s'authentifient sur un domaine local. Vérifier à la main chaque réglage pertinent dans une douzaine de portails d'administration n'est pas une activité récurrente réaliste — alors elle a lieu une fois, mal, avant une évaluation, puis dérive.
La dérive est le vrai risque. Un tenant correctement configuré il y a dix-huit mois a depuis accumulé des exclusions, de nouveaux comptes invités, des règles de transfert et un cercle d'administrateurs élargi. Personne n'a décidé d'affaiblir la posture ; elle s'est simplement érodée.
Ce qu'apporte un audit en lecture seule
Exécuter un audit automatisé sur Entra ID et Microsoft 365 produit une mesure datée et reproductible des garanties techniques, chaque constat étant classé par gravité et accompagné de sa remédiation. Cela vous donne trois choses concrètes :
- Une référence — où vous en êtes réellement, plutôt que là où la documentation prétend que vous en êtes.
- Des preuves pour la discussion sur les garanties techniques lors d'une analyse de risque ou d'une évaluation.
- La détection de dérive — rejouez l'audit chaque trimestre, et l'écart vous dit ce qui a changé sans que personne ait décidé de le changer.
La lecture seule compte particulièrement dans la santé : un outil d'audit capable de modifier la configuration d'un environnement qui traite des données de santé est un risque en soi. Évaluer ne devrait jamais comporter la possibilité de casser un accès clinique.
Ceci n'est pas un avis juridique. Les obligations HIPAA dépendent de votre rôle, de vos flux de données et de votre analyse de risque. Un audit de configuration soutient la partie « garanties techniques » d'un programme de conformité — il n'est pas un programme de conformité, et il ne remplace ni un conseil juridique ni une analyse de risque formelle.