Sujet 4.2 — Gestion des identités et des accès

Dans la santé et l'action sociale, contrôler qui peut voir et faire quoi avec le dossier d'un patient n'est pas une tâche ménagère informatique mais un déterminant de première ligne de la sécurité clinique, de la confidentialité, et de la confiance publique.

Pourquoi c'est important dans la santé et l'action sociale#

Chaque décision clinique repose sur l'hypothèse que le dossier devant un clinicien est le bon dossier, appartient au bon patient, et a été atteint par la bonne personne. La gestion des identités et des accès (IAM) est la machinerie qui rend ces trois hypothèses vraies. Quand elle fonctionne, un ambulancier voit une allergie à temps, une note de protection n'atteint que ceux qui en ont besoin, et une piste d'audit peut répondre à la question « qui a consulté ce dossier et pourquoi ? ». Quand elle échoue, des patients sont blessés par des dossiers ouverts sous le mauvais nom, du personnel espionne des proches ou des célébrités, et la confiance dans toute l'entreprise numérique s'érode.

La santé et l'action sociale élèvent les enjeux au-dessus du cas d'entreprise ordinaire de trois façons. Premièrement, les données comptent parmi les plus sensibles qu'une personne créera jamais — santé mentale, santé sexuelle, usage de substances, identité de genre, préoccupations de protection — donc une violation de confidentialité n'est pas un inconvénient mais un préjudice durable. Deuxièmement, la main-d'œuvre est mobile, rotative, et multi-organisationnelle : les jeunes médecins tournent tous les quelques mois, le personnel d'agence et remplaçant arrive pour un seul service, et les soins intégrés signifient qu'une infirmière de district peut légitimement avoir besoin d'un dossier hospitalier. Troisièmement, le devoir de diligence est impitoyable face à la friction : un contrôle d'accès trop lent à 3h du matin en réanimation est lui-même un danger de sécurité. L'IAM dans ce secteur est donc une négociation constante entre verrouiller les données et laisser entrer la bonne personne rapidement.

Ce sujet traite de la profondeur de contrôle d'accès qui se situe sous les obligations plus larges couvertes au Sujet 1.7 — Gouvernance de l'information, protection des données et cybersécurité. Là où ce sujet fixe le cadre légal et organisationnel — le UK General Data Protection Regulation, le Data Security and Protection Toolkit, l'obligation de confidentialité — celui-ci concerne la mécanique concrète de prouver l'identité et d'accorder le moindre accès nécessaire pour faire le travail.

Concepts fondamentaux#

La gestion des identités et des accès est la discipline et l'ensemble de technologies qui assurent que les bonnes personnes ont le bon accès aux bonnes ressources au bon moment, et que cela peut être prouvé ensuite. Elle repose sur une distinction facile à brouiller et dangereuse à perdre : la différence entre l'authentification et l'autorisation.

L'authentification répond à « êtes-vous qui vous prétendez être ? ». Elle est prouvée avec des facteurs : quelque chose que vous savez (un mot de passe ou PIN), quelque chose que vous avez (une smartcard, un téléphone, un jeton matériel), et quelque chose que vous êtes (une empreinte digitale ou un visage). L'autorisation répond à une question différente — « maintenant que nous savons qui vous êtes, que pouvez-vous voir et faire ? ». Un consultant et une réceptionniste peuvent tous deux s'authentifier parfaitement bien, mais ils sont autorisés à des parties très différentes d'un dossier. Confondre les deux mène à des systèmes qui vérifient fortement l'identité puis laissent tout le monde tout voir.

L'autorisation dans la santé et l'action sociale est habituellement organisée comme un contrôle d'accès basé sur les rôles (RBAC), où les permissions s'attachent aux rôles — « infirmière de service d'urgence », « médecin généraliste », « secrétaire médicale » — et les gens héritent des permissions en détenant un rôle, plutôt qu'en recevant des droits un par un. Le RBAC est gouverné par le principe du moindre privilège : chaque personne, et chaque compte système, devrait détenir le minimum d'accès nécessaire pour faire le travail et pas plus. Le moindre privilège limite à la fois l'erreur accidentelle et le rayon d'impact d'un compte compromis.

L'authentification moderne renforce l'étape « prouvez qui vous êtes » avec l'authentification multifacteur (MFA), combinant deux ou plusieurs facteurs afin qu'un mot de passe volé seul ne suffise pas. Elle réduit la friction avec l'authentification unique (SSO), où une session authentifiée accorde l'accès à de nombreuses applications sans connexions répétées — un véritable bénéfice de sécurité quand un clinicien doit se déplacer entre une douzaine de systèmes en une heure. Le SSO à travers les frontières organisationnelles repose sur l'identité fédérée : une organisation se porte garante d'un utilisateur afin qu'une autre puisse lui faire confiance sans détenir ses identifiants.

La plomberie de la fédération et de l'authentification moderne est construite sur des normes ouvertes. OAuth est une norme d'autorisation déléguée — permettant à une application d'agir en votre nom sans remettre votre mot de passe. OpenID Connect superpose l'authentification par-dessus OAuth afin qu'une application puisse apprendre qui est l'utilisateur, et le plus ancien Security Assertion Markup Language (SAML) basé sur XML fait un travail similaire pour le SSO d'entreprise. Le cycle de vie d'une identité — l'octroi, le changement, et la révocation de l'accès à mesure que les gens rejoignent, se déplacent, et partent — est géré par des processus de provisionnement, communément appelés arrivants/mouvants/partants ou JML.

La direction stratégique du voyage est l'architecture de confiance zéro (zero trust) : l'hypothèse qu'aucun utilisateur ou appareil n'est fiable simplement parce qu'il se trouve à l'intérieur du réseau. Chaque demande est authentifiée, autorisée, et vérifiée contre le contexte — santé de l'appareil, localisation, sensibilité des données — plutôt que de s'appuyer sur un périmètre renforcé. Dans un secteur où le personnel travaille depuis des cliniques, des domiciles, des ambulances, et des sites partenaires, le périmètre s'est effectivement dissous, et zero trust nomme la réponse honnête à cela.

Bonnes pratiques#

1. Traitez l'authentification et l'autorisation comme des décisions de conception séparées. Décidez d'abord à quel point vous devez prouver fortement l'identité pour un système donné, et séparément à quel point finement vous devez contrôler ce que chaque rôle peut alors faire. Une connexion forte sur un système qui donne à tout le monde un accès complet est un faux confort, et des permissions granulaires derrière un mot de passe faible sont tout aussi creuses. Documentez les deux décisions explicitement pour chaque système clinique, et revisitez-les quand la sensibilité des données ou la population d'utilisateurs change.

2. Faites en sorte que le contrôle d'accès basé sur les rôles reflète de véritables rôles cliniques, puis gardez-le propre. Concevez les rôles autour de comment les soins sont réellement livrés — pas autour de l'organigramme ou des caprices de la configuration par défaut d'un fournisseur — et mappez chaque rôle au minimum de dossiers et fonctions dont il a besoin. Avec le temps, le RBAC se dégrade en « explosion de rôles », où des centaines de rôles qui se chevauchent s'accumulent et personne ne peut dire ce que chacun accorde. Programmez une rationalisation périodique des rôles, et résistez à la tentation de résoudre chaque demande d'accès en frappant un nouveau rôle sur mesure.

3. Appliquez le moindre privilège aux personnes et aux comptes machine de la même façon. Le moindre privilège est régulièrement appliqué aux cliniciens puis oublié pour les comptes de service, moteurs d'intégration, et outils de reporting qui détiennent souvent l'accès le plus large de tous. Une interface automatisée extrayant des données pour un tableau de bord a rarement besoin d'accès en écriture ou de texte libre identifiable, pourtant elle l'obtient fréquemment. Inventoriez les identités non humaines, réduisez leur portée, et faites tourner leurs identifiants selon un calendrier.

4. Mandatez l'authentification multifacteur pour l'accès à distance et privilégié, et choisissez des facteurs adaptés au contexte. Les mots de passe seuls ne sont plus défendables pour quoi que ce soit atteignant les données patient depuis l'extérieur d'un appareil de confiance, et la MFA est maintenant une attente de base à travers les systèmes du NHS. Choisissez des facteurs qui survivent à l'environnement clinique : des jetons matériels résistants au phishing ou des authentificateurs de plateforme pour l'accès privilégié et à distance, et méfiez-vous des codes SMS dans les services où le signal est faible et les téléphones partagés. Équilibrez le gain de sécurité contre la réalité qu'un clinicien en pleine réanimation ne peut pas fouiller pour un second facteur.

5. Utilisez l'authentification unique pour supprimer la friction qui pousse le personnel vers des solutions de contournement dangereuses. Lorsque le personnel doit se connecter séparément à dix systèmes, il écrit des mots de passe sur des post-it, partage des smartcards, et laisse des sessions ouvertes — chacune un risque de sécurité et de confidentialité. Un SSO bien implémenté, idéalement combiné avec des badges de proximité « tap in, tap out » aux postes de travail cliniques partagés, améliore à la fois la sécurité et rend du temps aux cliniciens. Traitez le SSO comme une intervention de sécurité patient, pas simplement une commodité, et mesurez le temps de connexion que vous supprimez.

6. Modernisez l'identité du NHS au-delà de la smartcard, sans casser ce qui fonctionne. Le NHS Care Identity Service (autrefois le Care Identity Service et, avant cela, le régime de Registration Authority construit sur les smartcards) authentifie le personnel du NHS et pilote l'accès aux systèmes nationaux tels que le Spine. La direction nationale est maintenant vers une authentification moderne basée sur des normes — CIS2 avec MFA et OpenID Connect — réduisant la dépendance envers les smartcards physiques et lecteurs de carte qui échouent, sont partagés, ou bloquent les soins. Planifiez votre migration délibérément : gardez la rigueur d'assurance et d'enregistrement du modèle smartcard tout en adoptant la flexibilité des jetons modernes.

7. Exploitez les arrivants/mouvants/partants comme un processus contrôlé et auditable — en particulier les partants. L'échec IAM grave le plus courant dans la santé et l'action sociale est le compte qui survit au besoin de la personne pour lui : le jeune médecin ayant tourné, l'infirmière d'agence partie, le contractant dont l'accès n'a jamais été révoqué. Automatisez le provisionnement depuis une source faisant autorité (habituellement le dossier électronique du personnel) afin que commencer, changer, et terminer un rôle déclenche le changement d'accès correspondant dans une fenêtre définie et courte. Traitez la révocation le jour même pour les partants et pour le personnel sous enquête comme une exigence stricte, pas une aspiration.

8. Recertifiez l'accès régulièrement et rendez les gestionnaires responsables de cela. L'accès qui était approprié le jour un dérive à mesure que les gens changent d'équipe et accumulent des droits dont ils n'ont plus besoin — le « fluage de privilège ». Menez des révisions d'accès périodiques (recertification) dans lesquelles le gestionnaire ou propriétaire de système responsable confirme activement que chaque personne a toujours besoin de chaque droit, le silence par défaut vers le retrait plutôt que la rétention. Rendez la révision significative en la présentant en langage de rôle clinique clair, pas en codes de permission bruts qu'aucun gestionnaire ne peut interpréter.

9. Gouvernez l'accès privilégié comme une catégorie à part. Les administrateurs, propriétaires de base de données, et ingénieurs d'infrastructure peuvent lire ou altérer tout dossier et désactiver les contrôles mêmes qui le protègent, donc leur accès nécessite un traitement plus fort que les utilisateurs ordinaires. Implémentez la gestion des accès privilégiés : séparez les identités admin des comptes quotidiens, accordez les droits élevés juste-à-temps et limités dans le temps plutôt que permanents, et enregistrez les sessions privilégiées pour révision indépendante. Ne laissez jamais un fournisseur ou un compte « break-glass » devenir une clé maîtresse permanente et non surveillée.

10. Rendez chaque décision d'accès auditable, et lisez réellement l'audit. Un contrôle d'accès qui ne peut pas être révisé ensuite n'est qu'à moitié un contrôle ; la capacité de répondre « qui a accédé à ce dossier, quand, et sur quelle base ? » sous-tend à la fois les enquêtes de confidentialité et la sécurité patient. Configurez une journalisation d'audit complète et inviolable, et — crucialement — dotez en ressources l'audit proactif, incluant des alertes pour les auto-consultations, les consultations de collègues ou VIP, et les volumes d'accès inhabituels. Une piste d'audit que personne n'examine ne dissuade personne.

11. Concevez l'accès break-glass afin que les urgences soient servies et les abus attrapés. Les cliniciens ont parfois légitimement besoin d'un dossier auquel ils ne sont pas habituellement autorisés à accéder — un patient inconscient, une urgence transorganisationnelle. Fournissez une voie explicite « break-glass » qui accorde un accès d'urgence avec une raison requise, un signalement immédiat, et une révision obligatoire après coup, plutôt que de forcer le personnel à choisir entre les règles et le patient. L'objectif est de rendre l'action d'urgence sûre facile et l'action injustifiée visible.

12. Adoptez zero trust comme une direction, et séquencez-le pragmatiquement. Passez de « réseau de confiance, ouvert à l'intérieur » à vérifier chaque demande contre l'identité, la santé de l'appareil, et le contexte, afin qu'un ordinateur portable compromis sur le LAN d'entreprise ne soit plus automatiquement fiable. C'est un voyage pluriannuel à travers l'identité forte, la conformité des appareils, l'accès conditionnel, et la micro-segmentation — pas un produit que vous achetez. Séquencez-le derrière les fondamentaux (MFA, moindre privilège, JML propre), et alignez-le avec le travail de parc au Sujet 4.0 — Architecture technique, cloud et héritage.

Questions à discuter avec votre équipe#

1. Où échangeons-nous délibérément la friction d'accès contre la sécurité clinique, et qui a décidé de l'équilibre ? Chaque connexion supplémentaire, second facteur, ou étape d'autorisation protège la confidentialité mais coûte des secondes qui, en urgence, sont elles-mêmes un risque de sécurité. Cette question force l'équipe à nommer les endroits spécifiques où les contrôles de sécurité pourraient retarder les soins — la connexion en réanimation, le poste de travail de service partagé, le système en dehors des heures ouvrables — et à demander si l'équilibre actuel a été choisi par des personnes qui comprennent les conséquences cliniques et de sécurité, ou est revenu par défaut au paramètre d'un fournisseur. Débattez de la tension honnêtement : un contrôle trop serré pousse vers des mots de passe post-it et des smartcards partagées qui sont pires que le risque qu'elles adressent, tandis qu'un contrôle trop lâche invite à l'espionnage et aux violations. Cherchez des signaux concrets d'un mauvais équilibre — personnel partageant des identifiants, sessions laissées ouvertes, break-glass utilisé routinièrement. Une bonne réponse identifie qui possède chaque compromis, montre que les cliniciens étaient dans la pièce quand il a été fixé, et pointe vers des temps de connexion mesurés et des taux de solutions de contournement plutôt que des suppositions. Elle s'engage aussi à revisiter l'équilibre à mesure que les rôles, systèmes, et menaces changent.

2. À quel point sommes-nous confiants qu'un partant ou un mouvant perd le bon accès, dans le bon délai, à chaque fois ? Le compte qui survit à son besoin est l'échec IAM classique, et dans une main-d'œuvre de santé rotative et multi-organisationnelle, le risque est aigu. Cette question sonde si les arrivants/mouvants/partants forment un processus fiable et automatisé piloté depuis une source faisant autorité, ou un ensemble d'e-mails manuels qui échouent discrètement quand quelqu'un est occupé. Discutez des cas difficiles : le jeune médecin tournant entre trusts, l'infirmière d'agence sur un service, le contractant, le membre du personnel suspendu en attente d'enquête. Considérez ce que « le bon délai » signifie pour chacun — la révocation le jour même est non négociable pour une suspension mais peut être plus douce pour un déplacement interne routinier. Une bonne réponse peut pointer vers des preuves, pas des intentions : les derniers résultats d'audit de partants, le nombre de comptes dormants trouvés et fermés, le temps entre le départ de quelqu'un et la fin de son accès. Elle est honnête sur les lacunes et nomme qui est responsable de les fermer.

3. Lorsque quelque chose tourne mal avec un dossier, pouvons-nous réellement reconstruire qui a fait quoi — et remarquerions-nous un abus sans qu'un incident ne nous le signale ? L'audit est le contrôle qui rend la confidentialité et la sécurité applicables après coup, mais il ne fonctionne que si les journaux sont complets, protégés, et véritablement révisés. Cette question sépare deux choses qu'une équipe confond souvent : la capacité d'enquêter réactivement quand une plainte arrive, et la capacité de détecter l'abus proactivement avant que quiconque ne se plaigne. Explorez ce que vos journaux capturent réellement, s'ils peuvent être altérés, combien de temps ils sont conservés, et — la question plus difficile — qui les regarde quand il n'y a pas d'incident. Considérez les menaces réalistes : un membre du personnel consultant un membre de la famille, un collègue, ou une personnalité publique ; un compte compromis exfiltrant des dossiers à l'échelle. Une bonne réponse montre que l'audit est doté en ressources comme une fonction active avec des alertes, pas une archive dormante, et peut citer un véritable exemple d'abus que l'organisation a détecté et sur lequel elle a agi. Elle relie aussi l'audit à l'équité, s'assurant que les révisions ne ciblent pas de manière disproportionnée des groupes de personnel particuliers.

4. Lorsqu'un clinicien a légitimement besoin d'un dossier auquel il n'est pas habituellement autorisé à accéder, notre voie break-glass rend-elle l'action sûre facile et l'action injustifiée visible ? La santé et l'action sociale diffèrent de l'informatique d'entreprise ordinaire précisément parce que les règles doivent parfois céder devant le patient qui se trouve devant vous — une arrivée inconsciente, une urgence transorganisationnelle, un clinicien en dehors des heures ouvrables couvrant une charge de cas peu familière. Cette question demande si l'accès d'urgence est conçu comme une voie explicite, raisonnée, et signalée, ou si le personnel est discrètement forcé de choisir entre la politique d'accès et le bien-être du patient. Sondez les modes d'échec aux deux extrémités : une voie break-glass si encombrante que les cliniciens l'évitent et partagent des identifiants à la place, ou une si sans friction et non révisée qu'elle devient la voie routinière d'entrée et vide le RBAC entièrement. Discutez de qui révise les événements break-glass, à quelle vitesse, et quelle proportion s'avère injustifiée — un taux proche de zéro peut signifier que le contrôle n'est pas utilisé plutôt que propre. Une bonne réponse peut décrire les étapes exactes qu'un clinicien prend, la capture de raison, le signalement immédiat à l'organisation d'origine du dossier, et la révision après coup qui ferme la boucle, et elle peut montrer que les urgences sont véritablement servies tandis que l'abus est véritablement attrapé. Elle est honnête sur si les volumes break-glass tendent dans une direction qui suggère une lacune d'autorisation plus profonde.

5. Gouvernons-nous l'accès privilégié et non humain aussi étroitement que nous gouvernons les cliniciens — ou est-ce là que se trouve la véritable exposition ? Les contrôles qui protègent les données patient sont eux-mêmes administrés par quelqu'un, et les administrateurs, propriétaires de base de données, moteurs d'intégration, et comptes de reporting peuvent souvent lire ou altérer tout dossier et éteindre les garanties mêmes qui contraignent tout le monde d'autre. Cette question traîne à la lumière l'accès que la discipline du moindre privilège est le plus susceptible de sauter : comptes admin permanents, connexions de support à distance de fournisseur, comptes de service avec droits mode-dieu, et l'interface automatisée extrayant discrètement du texte libre identifiable dont elle n'a jamais eu besoin. Discutez de si les identités admin sont séparées des comptes quotidiens, si l'élévation est juste-à-temps et limitée dans le temps ou permanente, et si les sessions privilégiées sont enregistrées et révisées indépendamment. Considérez le parc non humain spécifiquement — qui possède chaque compte de service, quand ses identifiants ont été tournés pour la dernière fois, et si quiconque pourrait les énumérer aujourd'hui. Une bonne réponse traite l'accès privilégié comme une catégorie à part avec des propriétaires nommés, une preuve d'élévation juste-à-temps, et un véritable inventaire d'identités machine, plutôt qu'une hypothèse que les fondamentaux appliqués aux cliniciens doivent aussi couvrir le back-office. Elle est franche sur les fournisseurs, et sur tout compte devenu une clé maîtresse permanente et non surveillée.

6. Quelle part de notre identité dépend de parties hors de notre contrôle, et sommes-nous délibérés sur cette dépendance ? L'identité moderne de santé et d'action sociale est fédérée par conception — un dossier partagé fait confiance aux assertions de chaque organisation partenaire, des services nationaux tels que le NHS Care Identity Service et CIS2 se portent garants du personnel, et NHS login se porte garant des citoyens — ce qui signifie que la force de votre contrôle d'accès n'est jamais meilleure que les fournisseurs d'identité sur lesquels vous vous appuyez et les normes qui vous lient ensemble. Cette question demande à l'équipe de cartographier où la confiance est déléguée : quelles organisations authentifient quels utilisateurs, ce qui se passe quand le processus d'arrivants/mouvants/partants d'un partenaire échoue, et comment une connexion fédérée est révoquée quand un membre du personnel d'un autre employeur part. Pesez la migration en cours des smartcards vers l'authentification basée sur des normes (CIS2 avec MFA et OpenID Connect), et la tension entre adopter la direction nationale et garder les flux de travail locaux fonctionnels à 3h du matin. Considérez aussi l'angle de résilience : si un service d'identité national est indisponible, les cliniciens peuvent-ils toujours atteindre en toute sécurité les dossiers dont ils ont besoin, ou la fédération devient-elle un point unique de défaillance. Une bonne réponse montre que l'équipe sait exactement de qui elle dépend pour l'assurance, a convenu comment la révocation et les incidents transorganisationnels sont gérés, et séquence son passage vers l'authentification moderne du NHS délibérément plutôt que d'être portée par elle. Elle est réaliste sur les parties du parc qui ne peuvent pas encore fédérer et comment elles sont pontées entre-temps.

En pratique : un exemple de santé et d'action sociale#

Le Meadowvale Integrated Care System déploie un dossier de soins partagé afin que le personnel hospitalier, communautaire, de santé mentale, de médecine générale, et d'action sociale pour adultes puisse voir une vue unifiée de chaque personne. Tôt dans la découverte, le programme réalise que son véritable risque n'est pas de construire le dossier mais de contrôler l'accès à celui-ci : une vue unique couvrant cinq organisations multiplie à la fois le bénéfice de sécurité du bon clinicien voyant la bonne information et le préjudice de la mauvaise personne voyant quelque chose de sensible.

L'équipe fait du contrôle d'accès un flux de conception de premier ordre. Elle convient d'un modèle de rôle exprimé en langage clinique — « infirmière communautaire », « professionnel de santé mentale approuvé », « gestionnaire de maison de retraite » — et mappe chaque rôle aux données minimales dont il a besoin, avec les dossiers de santé mentale et sexuelle soumis à un accès plus strict et séparément autorisé. L'authentification est fédérée : chaque organisation partenaire authentifie son propre personnel via le NHS Care Identity Service ou son fournisseur d'identité local utilisant OpenID Connect, et le dossier partagé fait confiance à ces assertions plutôt que d'émettre ses propres identifiants, donc il n'y a pas de nouveau mot de passe à gérer et les arrivants/mouvants/partants restent avec l'organisation employeuse où vit le dossier de personnel faisant autorité.

Parce qu'un ambulancier ou un clinicien en dehors des heures ouvrables aura parfois besoin d'un dossier auquel il n'est pas habituellement autorisé, l'équipe construit une voie break-glass explicite : l'accès d'urgence est accordé en entrant une raison, signalé immédiatement à l'organisation d'origine du dossier, et révisé dans les 48 heures. Ils mettent en place une petite fonction conjointe de gouvernance de l'information et d'audit qui révise les événements break-glass, exécute des alertes pour les auto-consultations et les consultations de personnes signalées, et rapporte trimestriellement au conseil d'administration de l'ICS.

Six mois après la mise en production, une alerte signale un coordinateur de soins consultant à plusieurs reprises le dossier de quelqu'un sans implication active dans sa charge de cas. La fonction d'audit enquête, trouve que l'accès était personnel plutôt que professionnel, et l'organisation employeuse prend une mesure disciplinaire. Aucun incident de sécurité patient ne s'est produit, la violation a été attrapée proactivement, et — parce que les contrôles ont démontrablement fonctionné — la confiance publique dans le dossier partagé a tenu. Le conseil d'administration note que la même capacité d'audit sert maintenant aussi de preuve pour sa soumission au Data Security and Protection Toolkit (voir Sujet 1.7 — Gouvernance de l'information, protection des données et cybersécurité).

Angles sectoriels#

Startup#

Une petite entreprise de santé numérique construisant, disons, une application de surveillance à distance a l'avantage de n'avoir aucun héritage : elle peut adopter l'authentification moderne, la MFA, et la fédération basée sur des normes dès le premier jour, et s'intégrer avec NHS login pour les citoyens et CIS2 pour les cliniciens plutôt que d'inventer son propre système d'identité. Le danger est la vitesse dépassant la discipline — identifiants admin codés en dur, un compte superutilisateur « fondateur » partagé, comptes de service avec accès mode-dieu, et aucun processus de partant car « tout le monde connaît tout le monde ». Le moindre privilège et l'audit semblent une charge à dix personnes mais deviennent une dette technique irrécupérable à cent. Le mouvement pragmatique est d'acheter l'identité comme un service géré, appliquer la MFA et le RBAC dès le premier commit, et traiter les exigences DTAC (Digital Technology Assessment Criteria) comme la barre minimale pour tout déploiement NHS.

Petite entreprise#

Un prestataire établi de petite taille — un cabinet de médecins généralistes, une pharmacie communautaire, une maison de retraite, une agence de soins à domicile, une clinique monosite, ou un petit fournisseur de health-tech ayant dépassé le stade pré-revenu — porte les mêmes obligations de confidentialité et de contrôle d'accès qu'un grand trust mais a de vrais patients sur les registres, une poignée de personnel, et peu ou aucune capacité informatique dédiée pour les satisfaire. Le risque pratique ici n'est pas exotique : c'est la connexion partagée à l'accueil, le mot de passe de système clinique scotché sur un moniteur, le remplaçant à qui l'on donne la smartcard d'un collègue parce qu'enregistrer une nouvelle prend trop de temps, et le partant dont le compte n'est jamais désactivé car personne ne possède ce travail. Le chemin pragmatique est de s'appuyer sur les fonctionnalités d'identité déjà intégrées dans les systèmes qu'ils achètent — appliquer la MFA et les comptes par personne, activer la journalisation d'audit du fournisseur, et utiliser NHS CIS2 et NHS login plutôt que des identifiants maison — et d'écrire une routine simple d'arrivants/mouvants/partants qui nomme une personne responsable, même si cette personne est le gestionnaire de cabinet le faisant à la main. Le moindre privilège et la révocation de partant le jour même comptent tout autant à dix personnes qu'à dix mille ; la différence est qu'ici ils doivent être atteints avec du processus et de la configuration plutôt qu'une équipe d'identité dédiée.

Entreprise#

Un grand trust du NHS ou un ICS exploite des dizaines de systèmes cliniques d'âges extrêmement différents, chacun avec son propre modèle d'identité, et son défi central est l'intégration et le cycle de vie à l'échelle. Les smartcards, le SSO, les flux de travail « tap in, tap out », et un pipeline JML fiable depuis le dossier électronique du personnel comptent tous plus ici que tout contrôle astucieux unique, car les modes d'échec sont des échecs de volume : des milliers de comptes dormants, l'explosion de rôles, et des journaux d'audit que personne n'a la capacité de réviser. La gestion des accès privilégiés est critique étant donné le nombre d'administrateurs et fournisseurs touchant le parc. Le progrès vient d'une stratégie d'identité qui rationalise les rôles, fédère à travers les systèmes, et dote en ressources une fonction d'audit permanente — pas de solutions ponctuelles ajoutées à chaque application.

Gouvernement#

Un organisme national tel que NHS England exploite l'identité comme une infrastructure partagée pour tout le système : le NHS Care Identity Service et CIS2 pour le personnel, NHS login pour les citoyens, et les normes et régimes d'assurance qui permettent à des centaines d'organisations de se faire confiance. Ses décisions fixent la direction du voyage — le passage des smartcards à l'authentification moderne, l'adoption d'OpenID Connect, la poussée vers zero trust — et sa responsabilité est envers le Parlement et le public pour la sécurité et l'accès équitable. La tension est entre la standardisation centrale et la flexibilité locale : mandater trop rigidement et vous cassez les flux de travail locaux, mandater trop lâchement et la fédération s'effondre en incohérence. Le prisme gouvernemental concerne donc l'établissement de normes interopérables (voir Sujet 4.3 — Interopérabilité et normes de données), la fourniture de services partagés fiables, et l'assurance de la conformité sans microgérer chaque trust.

Modes d'échec courants#

• Comptes orphelins et dormants. Les partants, le personnel ayant tourné, et les anciens contractants conservent un accès en direct car le JML repose sur une notification manuelle. Le correctif est le déprovisionnement automatisé depuis une source faisant autorité plus des balayages réguliers de comptes dormants.
• Explosion de rôles et fluage de privilège. Le RBAC se dégrade en centaines de rôles qui se chevauchent et les individus accumulent des droits qu'ils n'utilisent plus. Contrez avec une recertification périodique et une rationalisation de rôles programmée.
• Partage d'identifiants et postes de travail partagés. Des connexions lentes et des smartcards encombrantes poussent le personnel à partager des cartes et laisser des sessions ouvertes. Adressez la cause racine avec le SSO, les badges de proximité, et la commutation rapide plutôt qu'en exhortant le personnel à se comporter correctement.
• Accès privilégié permanent. Les administrateurs et fournisseurs détiennent des comptes mode-dieu permanents qui peuvent désactiver les contrôles eux-mêmes. Passez à une élévation juste-à-temps, limitée dans le temps, et enregistrée.
• Audit comme décoration. Les journaux sont collectés mais jamais révisés, donc l'abus n'est jamais trouvé que réactivement. Dotez en ressources l'audit proactif avec des alertes pour les auto-consultations et consultations VIP.
• Break-glass comme échappatoire. L'accès d'urgence existe mais n'est pas surveillé, donc il devient la voie routinière de moindre résistance. Exigez une raison, signalez chaque usage, et révisez après coup.
• Théâtre MFA. La MFA est activée mais sur des facteurs faibles et sujets au phishing, ou levée pour les utilisateurs privilégiés les plus occupés. Préférez des facteurs résistants au phishing là où le risque est le plus élevé.

Modèle de maturité#

Liste de contrôle#

• La force d'authentification et le périmètre d'autorisation sont décidés et documentés séparément pour chaque système clinique.
• La MFA est appliquée pour tout accès à distance et privilégié, en utilisant des facteurs appropriés au contexte clinique.
• L'authentification unique et la commutation rapide de poste de travail sont déployées pour supprimer la friction de connexion et le partage d'identifiants.
• Le modèle de rôle est exprimé en langage clinique, mappé au moindre privilège, et rationalisé selon un calendrier.
• Les arrivants/mouvants/partants sont automatisés depuis une source de personnel faisant autorité, avec révocation le jour même pour les partants et suspensions.
• La recertification d'accès périodique est menée par des gestionnaires responsables, avec retrait par défaut pour l'accès non confirmé.
• L'accès privilégié est géré comme une catégorie distincte : identités séparées, élévation juste-à-temps, enregistrement de session.
• Les comptes non humains et d'intégration sont inventoriés, limités au moindre privilège, et leurs identifiants tournés.
• Une journalisation d'audit complète et inviolable est en place, avec des alertes proactives pour les auto-consultations, consultations de collègues, et VIP.
• L'accès d'urgence break-glass est conçu avec une raison obligatoire, un signalement immédiat, et une révision après coup.
• La migration des smartcards vers l'authentification moderne du NHS (CIS2 / OpenID Connect) est planifiée et séquencée.
• La feuille de route zero trust est convenue et alignée avec la stratégie d'architecture technique.

Sources clés#

• NHS England — NHS Care Identity Service and Care Identity Service 2 (CIS2) guidance
• NHS England — Data Security and Protection Toolkit
• National Cyber Security Centre (NCSC) — Zero Trust Architecture Design Principles
• National Cyber Security Centre (NCSC) — Multi-factor authentication and identity/access management guidance
• NIST — Special Publication 800-207, Zero Trust Architecture
• NIST — Special Publication 800-63, Digital Identity Guidelines
• NHS England / NHS login — citizen identity verification service documentation
• DTAC — Digital Technology Assessment Criteria for health and social care
• Caldicott Principles and the common law duty of confidentiality (UK)

Références#

1. Identity management (identity and access management) — Wikipédia — https://en.wikipedia.org/wiki/Identity_management
2. Authentication — Wikipédia — https://en.wikipedia.org/wiki/Authentication
3. Authorization — Wikipédia — https://en.wikipedia.org/wiki/Authorization
4. Role-based access control — Wikipédia — https://en.wikipedia.org/wiki/Role-based_access_control
5. Principle of least privilege — Wikipédia — https://en.wikipedia.org/wiki/Principle_of_least_privilege
6. Multi-factor authentication — Wikipédia — https://en.wikipedia.org/wiki/Multi-factor_authentication
7. Single sign-on — Wikipédia — https://en.wikipedia.org/wiki/Single_sign-on
8. Federated identity — Wikipédia — https://en.wikipedia.org/wiki/Federated_identity
9. OAuth — Wikipédia — https://en.wikipedia.org/wiki/OAuth
10. OpenID (and OpenID Connect) — Wikipédia — https://en.wikipedia.org/wiki/OpenID
11. Security Assertion Markup Language (SAML) — Wikipédia — https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language
12. Provisioning (technology) — Wikipédia — https://en.wikipedia.org/wiki/Provisioning_(technology)
13. Zero trust architecture — Wikipédia — https://en.wikipedia.org/wiki/Zero_trust_architecture
14. NHS Care Identity Service 2 (CIS2) — NHS England — https://digital.nhs.uk/services/care-identity-service
15. Data Security and Protection Toolkit — NHS England — https://www.dsptoolkit.nhs.uk/
16. Zero Trust Architecture Design Principles — National Cyber Security Centre — https://www.ncsc.gov.uk/collection/zero-trust-architecture
17. Special Publication 800-207: Zero Trust Architecture — National Institute of Standards and Technology (NIST) — https://csrc.nist.gov/pubs/sp/800/207/final
18. Special Publication 800-63: Digital Identity Guidelines — National Institute of Standards and Technology (NIST) — https://pages.nist.gov/800-63-3/
19. Digital Technology Assessment Criteria (DTAC) — NHS England — https://www.nhs.uk/digital-technology-assessment-criteria-dtac/
20. NHS login — NHS England — https://www.nhs.uk/nhs-services/online-services/nhs-login/