Secrecy Care Blog
Find the latest news from Secrecy Care, new products, events, and articles from our experts here.
Find the latest news from Secrecy Care, new products, events, and articles from our experts here.
La santé numérique repose désormais sur des échanges permanents de données. Un patient transmet un document depuis une application mobile, un médecin consulte un dossier à distance, un laboratoire envoie un résultat, un hôpital partage une image médicale, une plateforme de télémédecine coordonne plusieurs professionnels, et des outils d’IA commencent à analyser des volumes croissants d’informations sensibles.
Cette évolution améliore le parcours de soin, mais elle fragilise le modèle de sécurité traditionnel. Pendant longtemps, la cybersécurité s’est construite autour d’une idée simple : protéger fortement l’extérieur du système, puis considérer l’intérieur comme relativement fiable. Ce raisonnement devient insuffisant lorsque les utilisateurs sont mobiles, que les applications sont dans le cloud, que les prestataires se multiplient et que les données circulent entre plusieurs acteurs.
Le Zero Trust répond à cette réalité avec un principe clair : ne jamais faire confiance par défaut, toujours vérifier.
Dans une architecture Zero Trust, un utilisateur, un terminal, une application ou un service technique n’obtient pas un accès simplement parce qu’il se trouve dans le réseau interne ou parce qu’il possède déjà un compte. Chaque accès doit être vérifié, limité, contextualisé, tracé et réévalué.
Ce qu’il faut retenir : en santé numérique, le Zero Trust consiste à ne plus accorder d’accès automatique aux données médicales. Chaque demande doit être vérifiée selon l’identité de l’utilisateur, le terminal utilisé, le contexte, le niveau de risque et le besoin réel. Cette approche complète le chiffrement de bout en bout en contrôlant qui peut accéder à quoi, quand, depuis quel appareil et pour quelle finalité.
Le Zero Trust est une architecture de cybersécurité qui supprime la confiance implicite. Dans le contexte de la santé numérique, cela signifie qu’un compte médecin, un compte patient, un terminal hospitalier, une application métier, une API ou un prestataire ne doit pas être considéré comme fiable par défaut.
L’objectif est de protéger les données médicales tout en maintenant la continuité des soins. Une bonne architecture Zero Trust vérifie l’identité, contrôle le terminal, limite les droits, segmente les systèmes, chiffre les données, surveille les comportements et trace les accès.
Le Zero Trust n’est pas une technologie unique. C’est une stratégie d’architecture qui associe plusieurs briques : authentification forte, contrôle d’accès contextuel, moindre privilège, micro-segmentation, supervision, journalisation, chiffrement et gouvernance des habilitations.
Le modèle de sécurité traditionnel ressemble à un château fort. On protège l’entrée avec des pare-feux, des VPN, des mots de passe et des règles réseau. Une fois à l’intérieur, l’utilisateur ou l’application bénéficie souvent d’un niveau de confiance beaucoup plus large.
Cette logique a longtemps été compréhensible. Elle devient pourtant fragile dans un environnement de santé numérique. Un établissement ou une application e-santé ne fonctionne plus dans un périmètre simple, fermé et stable. Les professionnels peuvent se connecter depuis plusieurs sites, les patients utilisent des applications mobiles, les prestataires interviennent à distance, les logiciels sont souvent hébergés dans le cloud, et les flux de données passent par des API, des plateformes interopérables et des services tiers.
Dans ce contexte, l’attaque ne vient pas toujours d’un acteur extérieur qui force une porte d’entrée. Elle peut aussi passer par un compte compromis, un terminal mal protégé, un accès distant mal configuré, une application exposée, un prestataire attaqué ou un compte de service trop permissif.
L’Agence du Numérique en Santé indique qu’en 2025, 764 incidents de sécurité ont été déclarés au CERT Santé. Elle précise aussi que les compromissions de comptes, les fuites de données et les tentatives d’escroquerie progressent, tandis que 38 % des signalements concernaient des incidents entraînant un fonctionnement en mode dégradé ou une interruption de la prise en charge. Source : Agence du Numérique en Santé — Observatoire 2025.
La cybersécurité santé n’est donc pas seulement un sujet informatique. Elle touche directement la confidentialité des patients, la continuité des soins, la capacité des équipes à travailler et la confiance dans les outils numériques.
Le NIST décrit le Zero Trust comme une approche qui ne donne aucune confiance implicite à un utilisateur, à un terminal ou à une ressource sur la seule base de sa localisation réseau. L’accès doit être authentifié et autorisé avant d’être accordé à une ressource. Source : NIST SP 800-207 — Zero Trust Architecture.
Appliqué à la santé, ce principe signifie qu’un utilisateur ne doit pas accéder largement à des données médicales simplement parce qu’il travaille dans l’hôpital, possède un badge ou se connecte depuis un réseau interne.
Avant d’ouvrir un dossier patient, une ordonnance, un résultat biologique, une image médicale ou un flux de télémédecine, le système doit comprendre qui demande l’accès, depuis quel terminal, dans quel contexte, pour quelle action, sur quelle donnée et avec quel niveau de risque.
Un médecin connecté depuis un poste professionnel connu, pendant ses horaires habituels et pour consulter un patient qu’il prend effectivement en charge, ne présente pas le même niveau de risque qu’un compte médecin utilisé depuis un appareil inconnu, à une heure inhabituelle et pour consulter un grand nombre de dossiers sans lien évident avec son activité.
Le Zero Trust transforme donc la logique d’accès aux données médicales. Il ne s’agit plus d’ouvrir largement une zone interne, mais d’accorder un accès précis, temporaire et justifié à une ressource donnée.
Définition à retenir : le Zero Trust appliqué à la santé numérique est une architecture de sécurité qui vérifie chaque accès aux données médicales selon l’identité, le terminal, le contexte, les droits et le niveau de risque, sans jamais faire confiance par défaut au réseau interne.
Le premier principe est l’absence de confiance implicite. Un utilisateur interne n’est pas automatiquement fiable. Un terminal administré n’est pas automatiquement sûr. Une API interne n’est pas automatiquement autorisée à tout appeler. Chaque session doit être vérifiée.
Le deuxième principe est le moindre privilège. Un professionnel doit accéder uniquement aux données nécessaires à sa mission. Un infirmier, un médecin, un chercheur, un administrateur technique et un prestataire n’ont pas les mêmes besoins. Les droits doivent refléter le rôle, mais aussi le contexte réel de l’action.
Le troisième principe est la vérification du terminal. L’identité d’un utilisateur ne suffit pas si son appareil est compromis. Une architecture Zero Trust peut tenir compte de l’état de mise à jour, du chiffrement local, de la présence d’un outil de sécurité, du statut du terminal et de son appartenance au parc connu.
Le quatrième principe est la limitation temporelle. Un accès permanent crée un risque permanent. Le Zero Trust favorise les accès courts, réévalués et révocables. L’accès peut être prolongé si le contexte reste légitime, ou réduit si le risque augmente.
Le cinquième principe est la segmentation. Une compromission locale ne doit pas devenir une compromission globale. Une attaque touchant une application de télémédecine ne devrait pas donner accès automatiquement à l’imagerie, aux sauvegardes, au dossier patient complet ou aux environnements de recherche.
Le sixième principe est la supervision continue. Le Zero Trust ne se limite pas à vérifier l’entrée. Il faut aussi surveiller les usages, repérer les anomalies, tracer les accès et pouvoir réagir rapidement en cas de comportement inhabituel.
Le septième principe est la protection des données elles-mêmes. Les accès doivent être contrôlés, mais les données doivent aussi être chiffrées. Le chiffrement en transit, le chiffrement au repos et le chiffrement de bout en bout jouent des rôles complémentaires.
Une architecture Zero Trust pour un cloud médical repose d’abord sur une couche identité solide. Cette couche permet de savoir qui agit : patient, professionnel de santé, administrateur, prestataire, application, API ou service automatisé. Elle s’appuie généralement sur une authentification forte, une fédération d’identité, des comptes de service maîtrisés et une gouvernance claire des habilitations.
La deuxième couche concerne le terminal. Dans la santé numérique, les accès peuvent venir d’un ordinateur hospitalier, d’un smartphone professionnel, d’une tablette en service, d’un poste de télétravail ou d’un appareil personnel autorisé. Le système doit évaluer si l’appareil est connu, à jour, protégé et conforme au niveau de sensibilité demandé.
La troisième couche concerne le contexte. L’heure, la localisation, le rôle métier, le type de donnée, le comportement habituel, l’urgence médicale ou l’indice de risque fourni par un outil de supervision peuvent influencer la décision d’accès.
La quatrième couche correspond aux politiques d’accès. Ces politiques traduisent les règles métier et sécurité. Elles déterminent, par exemple, si un utilisateur peut lire un document, modifier une donnée, exporter un fichier, partager un résultat, accéder à une API ou consulter un historique.
La cinquième couche est la donnée. Dans une architecture moderne, la donnée médicale doit être considérée comme la ressource centrale à protéger. Le périmètre n’est plus le réseau ; le périmètre devient le dossier, le document, l’image, le résultat, le message ou la clé de chiffrement.
La sixième couche est la supervision. Les logs, les alertes, la détection d’anomalies, les tableaux de bord et les procédures de réponse à incident permettent de passer d’une sécurité théorique à une sécurité opérationnelle.
Une fois ces couches réunies, le Zero Trust devient beaucoup plus concret. Il ne s’agit pas d’ajouter un contrôle de plus, mais de faire en sorte que l’accès à une donnée médicale soit toujours lié à une identité, un contexte, un besoin et une durée.
Prenons le cas d’un médecin qui souhaite consulter un résultat biologique depuis une application e-santé.
Dans une architecture traditionnelle, l’accès peut dépendre principalement du compte utilisateur et du fait que l’application soit accessible depuis le réseau autorisé. Dans une architecture Zero Trust, la décision est plus fine.
Le médecin s’authentifie d’abord avec un facteur fort. Le système vérifie ensuite que le terminal est connu et conforme. Il analyse le contexte de connexion, le rôle du médecin, la relation avec le patient, la sensibilité du résultat et le niveau de risque de la session. Si les conditions sont réunies, l’accès est accordé uniquement au document demandé, pour une durée limitée, avec une journalisation de l’action.
Si le même compte tente ensuite de télécharger un grand volume de résultats, de se connecter depuis un appareil inconnu ou d’accéder à des dossiers sans lien avec son activité, l’accès peut être bloqué, réduit ou soumis à une nouvelle vérification.
Ce mécanisme ne vise pas à ralentir les soins. Il vise à rendre l’accès plus intelligent, plus proportionné et plus résilient.
Un compte soignant compromis représente un risque majeur pour un établissement ou une plateforme de santé. L’attaquant peut chercher à consulter des dossiers patients, exporter des données, usurper une identité, accéder à des services internes ou préparer une attaque plus large.
Dans une approche Zero Trust, le compte compromis ne donne pas automatiquement un accès large. Le système peut limiter l’accès aux patients effectivement suivis, vérifier le terminal utilisé, détecter une localisation inhabituelle, bloquer les exports massifs et imposer une réauthentification forte lorsque le comportement s’écarte du profil habituel.
Le bénéfice est important : même si l’incident n’est pas évité à 100 %, sa propagation peut être limitée. L’objectif n’est pas de supposer que tout ira bien, mais de concevoir le système pour qu’une compromission reste confinée.
Dans un service hospitalier, cette nuance compte beaucoup. La sécurité ne doit pas empêcher le travail des soignants, mais elle doit éviter qu’un seul compte compromis devienne une porte ouverte vers tout le système d’information.
Une plateforme de télémédecine concentre des données sensibles. Elle peut gérer l’identité du patient, des questionnaires médicaux, des documents transmis, des photos, des messages, des ordonnances, des comptes rendus, des résultats biologiques et parfois des informations administratives.
Le Zero Trust permet de sécuriser chaque étape du parcours. Le patient accède à ses propres données avec un niveau d’authentification adapté. Le professionnel de santé consulte uniquement les informations nécessaires à la prise en charge. L’administrateur technique peut superviser l’infrastructure sans accéder aux contenus médicaux en clair. Les API disposent de droits limités et traçables. Les sessions sont journalisées et les comportements anormaux peuvent être détectés.
Le chiffrement de bout en bout renforce cette approche. Même si le cloud stocke ou transporte les données, il n’a pas vocation à les lire. Le serveur devient un intermédiaire technique, pas un point de confiance absolu.
Dans cette logique, la confidentialité ne dépend plus seulement de la promesse d’un serveur bien protégé. Elle devient une propriété de l’architecture.
En pratique : sur une plateforme de télémédecine, le Zero Trust limite chaque accès aux données strictement nécessaires, tandis que le chiffrement de bout en bout protège les documents, messages, photos et résultats médicaux contre la lecture par des intermédiaires non autorisés.
L’intelligence artificielle médicale a besoin de données pour détecter des signaux faibles, analyser des images, personnaliser des parcours ou soutenir la recherche. Mais plus les données sont nombreuses, plus leur exposition peut devenir problématique.
Une architecture Zero Trust appliquée à l’IA médicale doit contrôler les accès aux jeux de données, les finalités d’usage, les environnements d’exécution, les exports, les résultats, les modèles et les comptes techniques. Elle doit aussi différencier les données directement identifiantes, les données pseudonymisées, les données agrégées et les données anonymisées.
Le Zero Trust ne bloque pas l’innovation. Il crée un cadre pour que l’innovation ne repose pas sur une exposition excessive des données patients. Dans certains cas, il peut être complété par le chiffrement de bout en bout, le calcul confidentiel, l’apprentissage fédéré, la confidentialité différentielle ou des techniques de calcul sur données protégées.
C’est probablement l’un des grands équilibres à trouver dans les prochaines années : permettre aux données de santé de servir la recherche et l’amélioration des soins, sans transformer chaque usage innovant en nouveau risque de confidentialité.
Le Zero Trust ne se résume pas à un outil unique. C’est une architecture globale qui combine identité, accès, chiffrement, supervision et gouvernance. Dans cette architecture, Secrecy.tech peut jouer un rôle important sur la couche donnée.
Selon la présentation de Secrecy.tech, le SDK permet aux acteurs de la e-santé de bénéficier d’une technologie de chiffrement de bout en bout et de cloud chiffré pour faciliter l’échange de données et la protection de la vie privée. Source : Secrecy.tech — Technology for Healthcare.
Cette approche est cohérente avec une logique Zero Trust car elle réduit la confiance accordée aux intermédiaires. Le serveur ou le cloud peut stocker et transporter des données, mais l’objectif est d’éviter qu’il puisse les lire par défaut. La confiance n’est plus placée uniquement dans l’infrastructure ; elle est déplacée vers les clés, les autorisations, les terminaux et les destinataires légitimes.
Secrecy.tech ne remplace pas à lui seul toutes les briques Zero Trust. Il doit s’inscrire dans une stratégie plus large comprenant l’authentification forte, la gestion des identités, les politiques d’accès, la journalisation, la supervision, l’hébergement adapté, la documentation RGPD et la réponse à incident.
Sa valeur principale est de répondre à une question centrale : comment protéger les données médicales même lorsque l’infrastructure intermédiaire ne doit pas être considérée comme pleinement fiable ?
Mettre en place une démarche Zero Trust ne signifie pas tout reconstruire immédiatement. Pour une DSI, l’approche la plus efficace consiste souvent à réduire d’abord les risques les plus visibles, puis à renforcer progressivement les contrôles.
La première phase consiste à sécuriser les identités les plus sensibles. L’authentification forte doit être priorisée pour les comptes administrateurs, les accès distants, les comptes prestataires et les applications exposées. Les comptes partagés doivent être identifiés, réduits ou supprimés lorsque c’est possible.
Pendant cette phase, la DSI doit aussi cartographier les applications critiques, les principaux flux de données de santé, les comptes à privilèges, les prestataires ayant un accès technique et les environnements qui soutiennent directement la continuité des soins.
L’objectif n’est pas de déployer un Zero Trust complet en un mois. L’objectif est de diminuer rapidement les risques les plus évidents : accès trop larges, comptes peu protégés, applications critiques non cartographiées et absence de visibilité sur les connexions sensibles.
La deuxième phase consiste à passer d’une logique de confiance interne à une logique d’accès conditionnel. Les droits doivent être rapprochés des besoins réels. Les comptes administrateurs doivent être séparés des comptes nominaux. Les environnements de production, de test, de recherche et d’administration doivent être mieux isolés.
La DSI peut introduire des politiques d’accès basées sur le rôle, le contexte, la sensibilité de la donnée et l’état du terminal. Cette étape est aussi le bon moment pour renforcer les journaux, centraliser les événements prioritaires et construire les premiers scénarios de détection.
L’objectif est de faire en sorte qu’un incident local ne donne pas accès à l’ensemble du système d’information.
La troisième phase consiste à rendre les contrôles plus automatiques et plus mesurables. Les accès temporaires, la révocation, les alertes d’anomalie, les tableaux de bord DSI et les procédures de réponse à incident doivent être formalisés.
Cette phase doit inclure des tests concrets. Un scénario de compte compromis, un scénario de ransomware, un scénario d’indisponibilité cloud ou un scénario d’accès prestataire peuvent révéler des écarts entre la politique de sécurité théorique et la réalité opérationnelle.
Le résultat attendu n’est pas une sécurité parfaite, mais une trajectoire claire : moins de droits permanents, plus de visibilité, une meilleure segmentation, des accès mieux justifiés et une capacité de réponse plus rapide.
Le Zero Trust n’est pas une obligation nommée explicitement dans tous les textes, mais il aide à répondre à plusieurs exigences de sécurité et de gouvernance.
Le RGPD impose des mesures techniques et organisationnelles adaptées au risque. Pour des données de santé, ce risque est élevé par nature. Une architecture Zero Trust contribue à la minimisation des accès, à la confidentialité, à la traçabilité, à la limitation des droits et à la sécurité par conception. Source : CNIL — Guide de la sécurité des données personnelles.
L’HDS concerne l’hébergement de données de santé à caractère personnel en France lorsque le cadre s’applique. Le Zero Trust ne remplace pas l’hébergement certifié, mais il peut le compléter en limitant les accès, en séparant les environnements, en renforçant la traçabilité et en réduisant l’exposition des données. Source : Agence du Numérique en Santé — HDS.
La directive NIS2 renforce la logique européenne de cybersécurité pour les secteurs critiques, dont la santé fait partie. Le Zero Trust peut aider les organisations à structurer la gestion du risque, la continuité, la maîtrise des accès, la surveillance et la réponse à incident.
L’EHDS, ou European Health Data Space, organise progressivement l’échange, l’usage et la réutilisation sécurisée des données de santé en Europe. Cette évolution augmente le besoin d’architectures capables d’associer interopérabilité, sécurité, traçabilité et contrôle fin des accès. Source : Commission européenne — EHDS.
Le Zero Trust est puissant, mais il ne règle pas tout. Un terminal totalement compromis, une mauvaise configuration, une gouvernance des droits inexistante, une absence de sauvegarde, un prestataire mal contrôlé ou un SDK non audité peuvent toujours créer des risques importants.
La principale erreur consiste à croire que le Zero Trust est un produit à acheter. En réalité, c’est une architecture à construire progressivement. Les outils sont nécessaires, mais ils ne remplacent ni la cartographie, ni la gouvernance, ni les procédures, ni la formation des équipes.
Dans la santé, une autre erreur serait de créer une sécurité qui bloque les soins. Les parcours d’urgence doivent être prévus, documentés et tracés. La sécurité doit être forte, mais elle doit rester compatible avec la prise en charge médicale.
C’est là que la conception produit devient essentielle. Un contrôle trop lourd sera contourné. Un contrôle invisible mais mal documenté sera difficile à auditer. Le bon équilibre consiste à adapter la sécurité au risque, au contexte et au besoin réel des soignants.
L’IA médicale va augmenter la valeur des données de santé et la complexité des flux. Les futurs systèmes devront contrôler non seulement les accès humains, mais aussi les accès des modèles, des pipelines d’entraînement, des API, des environnements d’expérimentation et des résultats générés.
La cryptographie post-quantique doit aussi être anticipée. Le NIST a publié en 2024 ses premiers standards post-quantiques finalisés. Les organisations qui manipulent des données médicales à longue durée de sensibilité doivent commencer par réaliser un inventaire cryptographique, identifier les usages de RSA ou ECC, évaluer les dépendances fournisseurs et prévoir une trajectoire de migration. Source : NIST — Post-Quantum Encryption Standards.
L’IoT médical va multiplier les points d’entrée. Capteurs, tablettes, dispositifs de télésuivi, équipements d’imagerie et appareils connectés devront être considérés comme des ressources à contrôler. Le Zero Trust devra donc s’appliquer autant aux utilisateurs qu’aux machines.
Ces évolutions vont dans la même direction : la santé numérique aura besoin d’architectures capables de partager davantage de données, mais avec moins de confiance implicite.
Le Zero Trust n’est pas une mode de cybersécurité. C’est une réponse structurelle à la réalité de la santé numérique.
Les données médicales circulent désormais entre patients, soignants, hôpitaux, laboratoires, applications, prestataires, API et clouds. Dans ce contexte, la confiance implicite ne suffit plus.
Une architecture Zero Trust permet de vérifier chaque accès, de limiter les droits, de segmenter les systèmes, de tracer les actions et de réduire l’impact d’un incident. Combinée au chiffrement de bout en bout, elle devient particulièrement pertinente pour les applications e-santé : le Zero Trust contrôle l’accès, tandis que l’E2EE protège la donnée elle-même.
Message clé : en santé numérique, la confiance ne doit plus être donnée par défaut. Elle doit être prouvée, limitée, temporaire et traçable.
Le Zero Trust appliqué à la santé numérique est une architecture de sécurité qui vérifie systématiquement l’identité, le terminal, le contexte et les droits avant chaque accès aux données médicales. Il supprime la confiance implicite accordée au réseau interne.
Il permet de réduire les accès excessifs, de limiter la propagation d’une attaque et de protéger les données médicales dans des environnements cloud, mobiles et interconnectés. Il aide aussi à préserver la continuité des soins en cas d’incident.
Non. Les deux approches ne protègent pas la même chose. Le Zero Trust décide qui peut accéder à une ressource et dans quelles conditions. Le chiffrement de bout en bout protège la donnée elle-même, même lorsqu’elle transite ou qu’elle est stockée sur un serveur.
Il peut créer de la friction s’il est mal conçu. Une bonne architecture adapte le niveau de contrôle au risque, simplifie les accès légitimes et prévoit des procédures d’urgence tracées.
Le point de départ le plus réaliste consiste à renforcer l’authentification, supprimer les comptes partagés, cartographier les applications critiques, réduire les droits excessifs et centraliser les journaux de sécurité prioritaires.
Non. Il renforce la sécurité, la traçabilité et la minimisation des accès, mais il ne remplace pas les obligations de conformité, d’hébergement adapté, de documentation, de gestion des sous-traitants et de respect des droits des personnes.
Le Zero Trust est une stratégie d’architecture globale. Le ZTNA, ou Zero Trust Network Access, désigne une famille de solutions qui applique certains principes Zero Trust à l’accès réseau ou applicatif.
Secrecy.tech peut renforcer la couche donnée grâce au chiffrement de bout en bout et au cloud chiffré. Cette approche réduit la confiance accordée aux serveurs intermédiaires et complète les contrôles d’identité, d’accès et de supervision.
Le Zero Trust en santé numérique repose sur une idée simple : aucun accès aux données médicales ne doit être accordé automatiquement. Chaque demande doit être vérifiée selon l’identité, le terminal, le contexte, les droits et le niveau de risque.
Cette approche combine authentification forte, contrôle d’accès contextuel, moindre privilège, segmentation, supervision et chiffrement. Associée au chiffrement de bout en bout, elle permet de mieux protéger les données de santé dans des environnements cloud, mobiles et interconnectés.
Pour les hôpitaux, les éditeurs e-santé et les DSI, l’enjeu n’est pas seulement de bloquer les attaques. Il s’agit surtout de limiter leur impact, de préserver la continuité des soins et de renforcer la confiance des patients dans les services numériques.
Le Zero Trust supprime la confiance implicite dans le réseau interne. Il vérifie chaque accès selon l’identité, le terminal, le contexte et le risque.
En santé numérique, cette approche protège les dossiers patients, la télémédecine, les plateformes cloud, les API et les usages d’IA médicale.
Le chiffrement de bout en bout complète le modèle en protégeant la donnée elle-même. Secrecy.tech s’inscrit dans cette logique grâce à une approche de cloud chiffré et de chiffrement côté client.
Le Zero Trust en santé numérique vérifie l’identité, le terminal, le contexte et les droits avant chaque accès aux données médicales, afin de limiter les accès excessifs, réduire l’impact des cyberattaques et compléter le chiffrement de bout en bout.
Une architecture Zero Trust ne cherche pas seulement à bloquer les attaques : elle limite ce qu’un compte, un terminal ou un service compromis peut réellement faire dans un environnement de santé.
Dans la santé numérique, la confiance ne doit plus être donnée par défaut. Elle doit être prouvée, limitée, temporaire et traçable.
Le Zero Trust fonctionne comme un hôpital où chaque porte vérifie votre identité, votre rôle et la raison de votre passage. Avoir un badge ne donne pas accès à tout. Chaque accès est limité, temporaire et tracé, afin de mieux protéger les données médicales même si un compte ou un terminal est compromis.
Une architecture Zero Trust santé combine gestion des identités, authentification forte, contrôle d’accès RBAC et ABAC, politiques dynamiques, micro-segmentation, ZTNA, journalisation SIEM, classification des données, chiffrement de bout en bout et gestion rigoureuse des clés. L’objectif est de réduire la surface d’attaque, de limiter les mouvements latéraux et d’appliquer le moindre privilège au niveau des ressources médicales.
NIST SP 800-207 — Zero Trust Architecture
Agence du Numérique en Santé — Observatoire 2025 des incidents de sécurité
Commission européenne — Plan d’action cybersécurité des hôpitaux et prestataires de soins
CNIL — Guide de la sécurité des données personnelles
Agence du Numérique en Santé — Certification HDS
Commission européenne — European Health Data Space