HIPAA et Microsoft 365 : auditer les garde-fous techniques

Les organisations de santé et leurs business associates tournent sur Microsoft 365 comme tout le monde — mais avec des informations de santé protégées (ePHI) qui transitent par les mêmes boîtes aux lettres, canaux Teams et sites SharePoint. La Security Rule HIPAA a des choses précises à dire sur qui peut atteindre ces données et comment vous le prouvez.

À qui cela s'applique

La Security Rule HIPAA s'applique aux covered entities — régimes de santé, chambres de compensation et la plupart des prestataires de soins — et à leurs business associates, c'est-à-dire tout fournisseur qui manipule des informations de santé protégées électroniques (ePHI) pour leur compte. Si vous êtes un éditeur de logiciels, un MSP ou un cabinet au service de clients de la santé, vous êtes très probablement un business associate avec des obligations directes, pas un simple spectateur contractuel.

Les trois familles de garde-fous

La Security Rule organise les exigences en garde-fous administratifs, physiques et techniques. Un audit de configuration Microsoft parle aux garde-fous techniques et à une partie des administratifs. Les garde-fous physiques — accès aux locaux, sécurité des postes, mise au rebut des appareils — échappent à tout outil de configuration.

Access Control

Quatre points comptent ici, et chacun correspond à un réglage Microsoft concret :

• Identification unique des utilisateurs. Chaque utilisateur a son propre compte. Les connexions partagées — le compte de l'accueil, la session générique du poste clinique, la boîte de service partagée avec le mot de passe dans un tiroir — sont un problème direct, et elles sont courantes. 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. En termes Entra ID, c'est un compte break-glass : exclu des accès conditionnels susceptibles de vous verrouiller dehors, identifiants stockés en sécurité, et surveillé. Se tromper ici signifie soit être enfermé hors de votre propre tenant, soit exploiter un super-compte sans surveillance.
• Déconnexion automatique. Délais de session et réglages d'inactivité, particulièrement pertinents là où le personnel clinique partage les postes.
• Chiffrement et déchiffrement. Au repos comme en transit, sur toute la pile collaborative.

Audit Controls

Vous devez pouvoir enregistrer et examiner l'activité des systèmes contenant des ePHI. En pratique : le journal d'audit unifié réellement activé, les journaux de connexion et d'annuaire conservés assez longtemps pour investiguer, et l'audit des boîtes aux lettres activé. Un nombre surprenant de tenants échoue ici parce que l'audit n'a jamais été activé au niveau du tenant — et vous ne pouvez pas produire rétroactivement des journaux jamais collectés.

Person or Entity Authentication

Vérifier que quiconque demande l'accès est bien qui il prétend être. C'est là que vit la couverture MFA, et 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 sape la politique que vous avez rédigée.

Transmission Security

Protéger les ePHI en transit. Pour Microsoft 365, les risques pratiques touchent le 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, avec les réglages de partage externe de SharePoint et OneDrive qui laissent un lien vers un document contenant des ePHI voyager plus loin que prévu.

Le recouvrement administratif

Deux garde-fous administratifs s'appuient lourdement sur la même preuve technique :

• Gestion des accès à l'information — autoriser l'accès selon le rôle, et le revoir. Les affectations de rôles privilégiés et les appartenances aux groupes en sont la preuve.
• Sécurité du personnel — y compris les procédures de départ. Les comptes restés actifs après le départ de quelqu'un sont l'échec de contrôle d'accès le plus cité tous référentiels confondus, et HIPAA ne fait pas exception.

Pourquoi la revue manuelle échoue toujours ici

Les équipes IT de santé sont généralement à flux tendu, supportent souvent un mélange de services cloud et de systèmes on-premises, parfois avec des applications cliniques qui s'authentifient contre un domaine on-premises. Vérifier chaque réglage pertinent à la main dans une douzaine de portails d'administration n'est pas une activité récurrente réaliste — alors on le fait une fois, mal, avant une évaluation, puis ça 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 ensemble élargi d'administrateurs. Personne n'a décidé d'affaiblir la posture ; elle s'est simplement érodée.

Ce qu'un audit en lecture seule vous apporte

Lancer un audit automatisé sur Entra ID, Active Directory et Microsoft 365 produit une mesure datée et répétable des garde-fous techniques, chaque constat classé par criticité et porteur d'une étape de remédiation. Cela vous donne trois choses pratiques :

1. Une base de référence — où vous en êtes réellement, plutôt que là où la documentation dit que vous êtes.
2. Des preuves pour la discussion sur les garde-fous techniques lors d'une analyse de risques ou d'une évaluation.
3. La détection de dérive — relancez chaque trimestre et le delta vous dit ce qui a changé sans que personne ait décidé de le changer.

La lecture seule compte particulièrement en santé : un outil d'audit capable de modifier la configuration d'un environnement manipulant des ePHI est un risque en soi. L'évaluation ne doit jamais porter le risque de casser l'accès clinique.