Brevet FR3021140A1 — publié le 20151120

Connexion sécurisée à un système d'information partagé de santé L'invention concerne un procédé de contrôle de requêtes entre un Logiciel de Gestion d'un acteur de la santé, appelé LG par la suite, installé sur un système informatique d'un acteur de la santé, et un Système d'Information Partagé de Santé, appelé SIPS par la suite, hébergé sur un serveur distant. Conformément à l'article L. 1111-24 du code français de la santé publique, en particulier modifié par ordonnance n°2010-177 du 23 février 2010 - art. 19, l'ASIP Santé (Agence française des systèmes d'information partagés de santé) est un groupement d'intérêt public qui a pour rôle de structurer le cadre national français des systèmes d'information partagés de santé, définis par l'article L1111-8 du code français de la santé publique en particulier modifié par ordonnance n°2010-177 du 23 février 2010 - art. 19, tels que le Dossier Médical Personnel, ou le Dossier Pharmaceutique, en concertation avec l'ensemble des acteurs français de la santé. A cet effet, l'ASIP Santé intègre la mise en oeuvre de dispositifs de sécurité (identification, authentification, signature et chiffrement) nécessaires pour assurer la protection de la confidentialité des données dans le cadre des applications de santé communicantes, et donc pour générer la confiance des utilisateurs des systèmes d'information partagés de santé. Cette mise en oeuvre doit prendre en compte un certain nombre de contraintes. Notamment, l'établissement d'une connexion entre des logiciels de gestion de acteurs de la santé, et les serveurs hébergeant les SIPS sous forme de bases de données, préalablement à l'utilisation des différents services liés aux SIPS, est conditionné par l'usage d'un certificat de Carte de Professionnel de Santé, appelé encore certificat CPS, valide, c'est-à-dire non expiré et non opposé, et authentifiant l'acteur du domaine de la santé, c'est-à-dire un professionnel (médecin, pharmacien, etc.) ou établissement de santé, se connectant au S IPS. A cet effet, l'ASIP Santé délivre à chaque acteur de la santé qui en fait la demande un certificat CPS, utilisé en France afin d'assurer la confidentialité de l'accès aux données personnelles dans le cadre des applications de santé communicantes. L'utilisation des différents services proposés par les LG, qui manipulent, en entrée comme en sortie des SIPS, des données d'historique inscrites sur une base de données, est également obligatoirement soumise à des règles définies par l'ASIP Santé qui garantissent la confidentialité et la sécurité des données, dont en particulier l'utilisation d'un certificat CPS de signature non expiré et non opposé, pour la signature électronique des requêtes, telles qu'une création, suppression, ou alimentation, qui modifient l'état d'une donnée d'un SIPS. Pour établir une connexion avec les SIPS, les logiciels de gestion doivent établir un canal SSL/TLS sécurisant les échanges, en présentant un certificat CPS d'authentification qui permet d'authentifier le professionnel de la santé ou l'établissement de santé auprès du serveur hébergeant le SIPS. Cette authentification est basée sur un certificat CPS délivré par l'ASIP Santé et porté sur une carte à puce CPS, ou installé sur un serveur informatique (on parle alors de « certificat serveur »). Ce certificat porte les informations d'authentification de l'acteur de la santé. La carte CPS d'un professionnel de la santé est par exemple insérée dans un lecteur de carte accessible par le LG du système informatique du professionnel de santé souhaitant établir la connexion avec un SIPS. Le LG a dans ce cas la charge d'identifier la carte en demandant la saisie d'un code connu par le propriétaire de la carte. Les requêtes modifiant l'état d'une donnée d'un SIPS sont de la même manière sécurisées à l'aide d'un certificat CPS de signature porté par exemple par une carte de Personnel d'Etablissement (CPE), ou la carte CPS, qui permet d'authentifier l'utilisateur du LG. Les certificats sont tous signés par des autorités de certification reconnues, et répertoriés par l'ASIP Santé. La vérification des certificats d'authentification CPS est en l'état actuel effectuée au niveau d'un logiciel serveur http Apache installé sur le serveur hébergeant le SIPS, au moment de la connexion du LG. A cet effet, un module Apache de validation des certificats est rendu disponible par l'ASIP Santé. Ce module vérifie si les certificats ont bien été émis par l'ASIP Santé, et s'ils n'ont pas été révoqués, via la récupération de listes de révocation des certificats, dites communément CRL, également signées par les mêmes autorités de certification reconnues, et téléchargées régulièrement sur le site internet de l'ASIP Santé. Le module Apache vérifie donc la signature du certificat d'authentification utilisé par le professionnel de la santé dans le cadre de la connexion sécurisée SSL/TLS, et compare ce certificat avec la liste de révocation des certificats correspondante, afin de valider ou non la connexion. Plus précisément, si le certificat n'est pas authentifié, ou si le certificat est révoqué, la connexion n'est pas validée. Or, il s'avère que le module Apache de validation des certificats CPS n'est compatible qu'avec des logiciels serveurs http Apache dont la version ne dépasse pas 2.2.17. Cette version de serveur http Apache, et les précédentes, ne sont pas adaptées à la gestion simultanée d'un nombre important de connexions provenant de LG. En effet, à partir d'un grand nombre de connexions simultanées au serveur apache hébergeant le SIPS, on observe des problèmes de perte de connexion entre les LG et le SIPS, ou des erreurs de transmission de données, dus à une consommation importante, cumulative, et sans libération, de mémoire vive (ou RAM), par différents composants d'Apache. Cette version est donc peu adaptée à l'utilisation du SIPS. Dans l'état actuel, il est malheureusement impossible de passer à une version supérieure du serveur http Apache à cause du manque de compatibilité du module de validation des certificats précité. Afin de permettre l'évolution du serveur utilisé pour l'hébergement du SIPS, l'invention propose un procédé de contrôle de requêtes adressées à un serveur distant hébergeant un SIPS, tel par exemple que défini à l'article L1111-8 du code français de la santé publique, lesdites requêtes étant accompagnées de certificats électroniques d'authentification d'acteurs de la santé, appelés généralement certificats CPS, et délivrés par un tiers agréé, ce dernier étant généralement l'ASIP Santé, caractérisé en ce qu'il comprend des étapes consistant : - à utiliser, sur le serveur, un logiciel conteneur de servlets, - à télécharger sur une mémoire rémanente du serveur des listes de révocation des certificats d'authentification des acteurs de la santé, rendues accessibles par un tiers agréé, ce dernier étant généralement l'ASIP Santé, - à utiliser un composant Valve installé et déclaré au conteneur de servlets, ledit composant Valve étant conçu pour le traitement des requêtes de connexion au serveur, et étant apte à contrôler la validité des certificats qui accompagnent ces requêtes, - à faire charger, par le composant Valve, dans une mémoire vive du serveur, les listes de révocation des certificats téléchargées, - à recevoir une requête adressée au serveur, - à faire effectuer, par le composant Valve et/ou par un autre composant logiciel installé sur le serveur, un contrôle de la requête, comprenant un contrôle de révocation du certificat accompagnant la requête, par comparaison avec les listes de révocation des certificats chargées dans la mémoire vive, et - soit à accepter la requête, soit à la refuser, en fonction du contrôle de révocation, le refus de la requête pouvant être accompagné de la génération d'un message d'erreur. On notera qu'il est en particulier fait référence à l'article L1111-8 du code français de la santé publique modifié par ordonnance n°2010-177 du 23 février 2010 - art. 19. En effet, le logiciel conteneur de servlets est utilisé pour le traitement des requêtes relatives à des services web, en liaison avec le serveur http 30 Apache qui gère les connexions réseau avec les LG. Ainsi, le conteneur de servlets offre en outre en standard ou en option un composant appelé Valve. Lorsqu'une Valve est configurée, toutes les requêtes de connexion que le serveur reçoit passent par celle-ci. La Valve a la possibilité soit d'accepter les requêtes de connexion au serveur, soit de refuser directement les requêtes, en générant un message d'erreur par exemple. L'invention utilise donc ce composant Valve pour mettre en mémoire les listes de révocation des certificats CPS, et pour contrôler, au moyen de ces listes, la validité des certificats utilisés pour la connexion au SIPS. Ainsi, selon l'invention, on s'affranchit de la dépendance du module Apache de validation des certificats, ce qui permet de pouvoir utiliser des serveurs http Apache, ou d'autre types de serveurs http, dont les versions respectent les derniers standards et qui permettent un accès optimal au SIPS. Par exemple, le conteneur de servlets peut être un logiciel Tomcat ou tout autre logiciel conteneur de servlets proposant un composant Valve. Avantageusement, pour chaque contrôle d'une requête adressée au serveur, un évènement correspondant est écrit dans un fichier de registre du serveur. Ce fichier, aussi appelé « log », créé sur la mémoire rémanente du serveur, permet de garder une traçabilité de l'ensemble des requêtes adressées au serveur, et du résultat de contrôle effectué au niveau du serveur. Avantageusement, le composant Valve refuse une requête de connexion au serveur si au moins l'une des conditions suivantes est vérifiée lors d'un démarrage du serveur : - une des listes de révocation de certificats chargée en mémoire n'est pas valide syntaxiquement par rapports aux normes de rédaction des listes, - une de ces listes a expiré, par comparaison de la date du jour du contrôle et une date d'expiration indiquée dans la liste, et - une de ces listes n'a pas été signée électroniquement par une autorité de certification reconnue. Préférentiellement, le composant Valve refuse une requête de connexion au serveur si au moins l'une des conditions suivantes est vérifiée lors d'un contrôle de la requête de connexion au serveur: - un certificat n'est pas présent avec la requête de connexion, - le certificat n'a pas été émis et signé électroniquement par une autorité de certification de confiance agrée, - la date du jour du contrôle n'est pas comprise dans l'intervalle compris entre une date de début et une date de fin de validité du certificat, ces dates étant indiquées dans le certificat, - le certificat ne prouve pas l'existence d'une clé privée détenue par l'émetteur du certificat, - le certificat a été révoqué, c'est-à-dire que l'autorité de certification estime que le certificat a été compromis. Selon une autre caractéristique avantageuse, le composant Valve refuse une requête de connexion au serveur si au moins l'une des conditions suivantes est vérifiée lors du contrôle de révocation du certificat accompagnant la requête de connexion : - aucun émetteur des listes de révocation de certificats chargées en mémoire ne correspond à l'émetteur du certificat accompagnant la requête de connexion, - un numéro de série du certificat accompagnant la requête correspond à un numéro trouvé dans la liste de révocation des certificats 25 de même émetteur chargée en mémoire, - la liste de révocation des certificats chargée en mémoire, de même émetteur que celui du certificat contenu dans la requête, n'est plus valide, c'est-à-dire que la date d'expiration de la liste est dépassée. Par ailleurs, un composant logiciel du serveur peut refuser toute 30 requête signée adressée au serveur, telle qu'une requête XML par exemple pour la modification d'une donnée contenue dans le SIPS, si au moins l'une des conditions suivantes est vérifiée lors du contrôle de révocation du certificat accompagnant la requête signée : - il n'existe pas de liste de révocation de certificats dont l'émetteur correspond à l'émetteur du certificat accompagnant la requête signée, - un numéro de série du certificat accompagnant la requête correspond à un numéro trouvé dans la liste de révocation des certificats de même émetteur chargée en mémoire, - la liste de révocation des certificats chargée en mémoire, de même émetteur que celui du certificat contenu dans la requête, n'est plus valide, c'est-à-dire que la date d'expiration de la liste est dépassée. Ce contrôle de la requête signée permet d'ajouter un niveau de sécurité lors des requêtes de modifications des données contenues dans le SIPS, telles qu'un ajout, une création, une suppression. Préférentiellement, les certificats d'authentification des acteurs de la 15 santé, ou certificats CPS, se trouvent sur des cartes à puce de professionnel de santé, dites cartes CPS, ou sur des cartes de personnel d'établissement, dites cartes CPE, ou sur des systèmes informatiques. De plus, l'utilisation de ces certificats sur carte CPS peut être soumise à la saisie d'un code de sécurité délivré au professionnel de santé 20 détenteur de ce certificat. Selon une autre caractéristique proposée, les listes de révocation des certificats sont téléchargées périodiquement, et préférentiellement une fois par jour. Il est également avantageux qu'une des listes de révocation de 25 certificats téléchargées remplace une liste déjà chargée en mémoire si toutes les conditions suivantes sont vérifiées lors d'un test périodique de comparaison entre ces deux listes, qui a lieu de préférence chaque minute : - la liste téléchargée a été modifiée depuis son dernier chargement, - la liste téléchargée a été modifiée depuis au moins trente 30 secondes, - la liste téléchargée est plus récente que la liste déjà chargée, par comparaison des dates d'émission des deux listes, - la liste téléchargée est émise par la même autorité de certification que la liste déjà chargée, - la liste téléchargée possède le même nom qu'une liste téléchargée présente lors d'un démarrage précédent du serveur. L'invention sera mieux comprise et d'autres caractéristiques, détails et avantages de celle-ci apparaîtront plus clairement à la lecture de la description qui suit, faite à titre d'exemple. On appelle ici « serveur » aussi bien le dispositif informatique matériel ou logiciel, qui offre des services, à différents clients, sur un réseau local ou sur le World Wide Web. Dans le cas présenté à la suite en exemple, le serveur héberge et donne l'accès à des Dossiers Pharmaceutiques, dit par la suite DP, propres aux patients des systèmes de santé. L'article L. 1111-23 du code français de la santé publique, en particulier modifié par la loi n°2011-2012 du 29 décembre 2011 - art. 23 (V), prévoit la création d'un dossier pharmaceutique pour chaque bénéficiaire de l'assurance maladie, avec son consentement, afin de favoriser la coordination, la qualité, la continuité des soins et la sécurité de la dispensation des médicaments et produits et objets définis à l'article L.4211-1 du même code. Sauf opposition du patient, tout pharmacien d'officine est tenu d'alimenter le dossier pharmaceutique à l'occasion de la dispensation des 25 médicaments. La mise en oeuvre du dossier pharmaceutique est assurée par le Conseil National de l'Ordre des Pharmaciens. Le dossier pharmaceutique fait aujourd'hui partie des systèmes d'information partagés de santé, et doit donc respecter les normes de 30 sécurité énoncées par l'ASIP Santé et décrites plus haut. Les optimisations de sécurité décrites ci-après en lien avec le dossier pharmaceutique, peuvent donc être portées sans difficulté particulière aux autres systèmes d'information partagés de santé. Le serveur hébergeant le DP a pour rôle de vérifier la non-expiration et la non-révocation des certificats CPS utilisés pour la connexion depuis les LG se trouvant généralement pour cet exemple dans une officine pharmaceutique, ladite connexion se faisant communément par le réseau internet. Il pourra toutefois s'agir d'un autre type de réseau d'échanges de données. Lors d'une authentification mutuelle de type SSL/TLS entre un LG d'une officine et le serveur hébergeant le DP, le LG présente un certificat CPS, contenu soit sur une carte CPS, soit sur une carte CPE. L'utilisation de la carte Vitale du patient est également nécessaire pour l'accès à son DP. Le serveur recevant la requête de connexion vérifie la validité du certificat CPS. D'après les normes de sécurité, si l'un des contrôles suivants échoue, la requête ne doit pas être traitée : - Le certificat a été émis par une autorité de certification de confiance. Ce contrôle permet de s'assurer que les informations contenues sur le certificat n'ont pas été modifiées par un tiers. - La date du jour du contrôle est comprise dans l'intervalle compris entre la date de début et la date de fin de validité du certificat, ces dates étant indiquées dans le certificat. - Le client possède bien la clé privée associée au certificat. - Le certificat n'a pas été révoqué, c'est-à-dire que l'autorité de certification n'estime pas que le certificat a été compromis. Le contrôle des révocations de certificats s'effectue à l'aide de listes de révocations mises à disposition sur le site de l'ASIP Santé. En l'état actuel, ce contrôle est effectué par un module lié au logiciel serveur http Apache installé sur le serveur. Ce type de contrôle présente les inconvénients cités plus haut. Un serveur http est un logiciel servant des requêtes respectant le protocole de communication client-serveur de norme http. Le logiciel Apache a quant à lui été créé et est maintenu au sein de la fondation Apache, et est téléchargeable sur le site internet « httpd.apache.org/» Il est donc proposé d'utilisé un logiciel conteneur de servlets, tel que Tomcat, sur le serveur, pour le contrôle des révocations des certificats. Un conteneur de servlets est un logiciel qui exécute des servlets, c'est-à-dire des objets qui permettent de créer dynamiquement des données au sein d'un serveur, afin d'effectuer le traitement de requêtes relatives à des services web. A titre d'illustration, le logiciel Tomcat est téléchargeable sur le site internet « tomcat.apache.org/ ». Plus particulièrement, régulièrement, et généralement chaque matin, les listes de révocation des certificats CPS, communément appelées CRL, sont téléchargées sous forme de fichiers informatiques vers une mémoire rémanente du serveur hébergeant les DP depuis le site internet de l'ASIP Santé. Les CRL sont téléchargées dans des répertoires informatiques appropriés pour être accessible par le conteneur de servlets. Un composant de type Valve du conteneur de servlets est installé et utilisé. A cet effet, un fichier informatique consacré doit être placé dans un répertoire informatique approprié du serveur, et le composant Valve doit être déclaré dans un fichier de configuration du conteneur. Cette Valve agit comme un filtre qui contrôle les requêtes de connexion au serveur. Comme le conteneur Tomcat gère l'ensemble des interactions avec le DP, toutes les connexions des LG aux DP sont soumises au composant Valve. La Valve spécifiquement utilisée est configurée pour le contrôle des requêtes accompagnées d'un certificat d'authentification. Par défaut, le composant Valve de contrôle des certificats agit de la façon suivante au lancement du serveur : - il charge dans une mémoire vive du serveur les listes de révocation des certificats dernièrement téléchargées, vérifie leur validité syntaxique par rapports aux normes de rédaction de ces listes, et vérifie qu'aucune liste n'a expiré en comparant la date du jour et des dates d'expiration indiquées dans les listes, et - il vérifie que ces listes ont bien été signées par les autorités de certification reconnues, afin de s'assurer de leur authenticité. Si une de ces deux vérifications échoue, le serveur démarre mais ne pourra valider aucune requête accompagnée d'un certificat, envoyée depuis les LG. Par la suite, régulièrement, et plus généralement toutes les 60 secondes environ, la Valve vérifie si les listes de révocation des certificats doivent être rechargées depuis le répertoire de téléchargement vers la mémoire. Une liste de révocation de certificats sera chargée si toutes les conditions suivantes sont remplies : - elle a été modifiée depuis son dernier chargement, - elle a été modifiée depuis au moins trente secondes, ceci afin d'éviter les rechargements en cours de copie, - elle est plus récente que la précédente, en comparant les dates d'émission des listes, - elle est toujours émise par la même autorité de certification, - le répertoire de téléchargement contient les mêmes noms de listes de révocation des certificats que lors du démarrage du serveur. Au contrôle d'authentification de chaque requête de connexion provenant d'un LG pour un accès à un DP, la requête est rejetée et l'accès au DP est refusé si : - aucun certificat n'est présent avec la requête de connexion, - aucun émetteur des listes de révocation de certificats chargées en mémoire ne correspond à l'émetteur du certificat contenu dans la requête de connexion, - le numéro de série du certificat contenu dans la requête correspond à un numéro trouvé dans la liste de révocation des certificats de même 30 émetteur, 3 02 1 140 12 - la liste de révocation des certificats, de même émetteur que celui du certificat contenu dans la requête, n'est plus valide, c'est-à-dire que la date d'expiration de la liste est dépassée. Le refus de la requête de connexion au DP se traduit par l'envoi d'un 5 message d'erreur à l'émetteur de la requête. De façon optionnelle, un paramétrage de la Valve permet de passer cette dernière en mode dit « informatif ». Dans ce cas, les phases de lancement du serveur et de rechargement des listes se dérouleront de la même manière, mais le contrôle des requêtes de connexion ne pourra pas 10 résulter en un refus de l'accès au DP. Seule une trace de l'historique des connexions sera inscrite dans un fichier de registre sur la mémoire du serveur. Au sujet de cette trace écrite, et afin de garantir une traçabilité des requêtes de connexion au DP, le composant Valve inscrit dans un fichier de 15 registre sur la mémoire du serveur une série de messages, lors du démarrage du serveur, du rechargement des listes de révocation des certificats, et lors du contrôle des requêtes de connexion au serveur, afin de conserver un historique des évènements liés au composant Valve. Le serveur doit également authentifier les requêtes signées, telles 20 que des requêtes de type XML, postérieures à la connexion et concernant la modification d'un DP, c'est-à-dire sa création, son alimentation en informations, sa suppression, etc. A cet effet, ces requêtes signées doivent aussi être accompagnées de certificats CPS présents sur les cartes CPS ou CPE, afin d'être sécurisées. 25 On propose ici de contrôler au moment de cette authentification la révocation des certificats utilisés avec les requêtes signées de modification des DP. A partir de ce qui a été présenté plus haut, il est facile et avantageux de réutiliser les listes de révocations de certificats déjà chargées en mémoire par le composant Valve, pour le contrôle de révocation des certificats accompagnant les requêtes signées. Etant donné que, selon l'invention, les listes de révocation de certificats sont déjà chargées en mémoire par la Valve, il n'est pas nécessaire d'effectuer au niveau du serveur de chargement supplémentaire des listes de révocation des certificats. Lorsqu'une requête signée de modification d'un DP est reçue par le serveur, un composant logiciel de traitement des requêtes signées, installé sur le serveur, récupère la liste déjà chargée en mémoire par la Valve. Ce composant logiciel extrait alors le certificat de la requête et contrôle : - s'il existe une liste de révocation des certificats dont l'émetteur correspond à l'émetteur du certificat utilisé par l'utilisateur du LG effectuant la requête. Si ce n'est pas le cas la requête est rejetée, - si le certificat est révoqué, en utilisant la liste de révocation de certificats de même émetteur. Si c'est le cas, la requête est rejetée. Il est possible de filtrer les requêtes signées en fonction des résultats de ce contrôle, ou d'accepter les requêtes signées quels que soient les résultats du contrôle. Lorsqu'une requête signée est rejetée, le serveur renvoie à l'émetteur de la requête un message d'erreur. Ici aussi, un historique est inscrit dans un fichier de registre pour 20 chaque évènement lié à un contrôle d'une requête signée de modification d'un DP. REVENDICATIONS1. Procédé de contrôle de requêtes adressées à un serveur distant hébergeant un système d'information partagé de santé, tel par exemple que défini à l'article L1111-8 du code français de la santé publique, lesdites requêtes étant accompagnées de certificats électroniques d'authentification d'acteurs de la santé, appelés généralement certificats CPS, et délivrés par un tiers agréé, ce dernier étant généralement l'ASIP Santé, caractérisé en ce qu'il comprend des étapes consistant : - à utiliser, sur le serveur, un logiciel conteneur de servlets, - à télécharger vers une mémoire rémanente du serveur des listes de révocation des certificats d'authentification des acteurs de la santé, rendues accessibles par un tiers agréé, ce dernier étant généralement l'ASIP Santé, - à utiliser un composant Valve installé et déclaré au conteneur de servlets, ledit composant Valve étant conçu pour le traitement des requêtes de connexion au serveur et étant apte à contrôler la validité des certificats qui accompagnent ces requêtes, - à faire charger, par le composant Valve, dans une mémoire vive du serveur, les listes de révocation des certificats téléchargées, - à recevoir une requête adressée au serveur, - à faire effectuer, par le composant Valve et/ou par un autre composant logiciel installé sur le serveur, un contrôle de la requête, comprenant un contrôle de révocation du certificat accompagnant la requête, par comparaison avec les listes de révocation des certificats chargées dans la mémoire vive, et - soit à accepter la requête, soit à la refuser, en fonction du contrôle de révocation. 2. Procédé de contrôle de requêtes selon la revendication 1, caractérisé en ce que le conteneur de servlets est un logiciel Tomcat. 3. Procédé de contrôle de requêtes selon l'une des revendications 1 ou 2, caractérisé en ce que pour chaque contrôle d'une requête adressée au serveur, un évènement correspondant est écrit dans un fichier de registre du serveur. 4. Procédé de contrôle de requêtes selon l'une des revendications précédentes, caractérisé en ce que le composant Valve refuse une requête de connexion au serveur si au moins l'une des conditions suivantes est vérifiée lors d'un démarrage du serveur : - une des listes de révocation de certificats chargée en mémoire 10 n'est pas valide syntaxiquement par rapports aux normes de rédaction des listes, - une de ces listes a expiré, par comparaison de la date du jour du contrôle et une date d'expiration indiquée dans la liste, et - une de ces listes n'a pas été signée électroniquement par une 15 autorité de certification reconnue. 5. Procédé de contrôle de requêtes selon l'une des revendications précédentes, caractérisé en ce que le composant Valve refuse une requête de connexion au serveur si au moins l'une des conditions suivantes est vérifiée lors d'un contrôle de la requête de connexion au serveur: 20 - un certificat n'est pas présent avec la requête de connexion, - le certificat n'a pas été émis et signé électroniquement par une autorité de certification de confiance agrée, - la date du jour du contrôle n'est pas comprise dans l'intervalle compris entre une date de début et une date de fin de validité du certificat, 25 ces dates étant indiquées dans le certificat, - le certificat ne prouve pas l'existence d'une clé numérique privée détenue par l'émetteur du certificat, - le certificat a été révoqué, c'est-à-dire que l'autorité de certification estime que le certificat a été compromis. 30 6. Procédé de contrôle de requêtes selon l'une des revendications précédentes, caractérisé en ce que le composant Valve refuse une requêtede connexion au serveur si au moins l'une des conditions suivantes est vérifiée lors du contrôle de révocation du certificat accompagnant la requête de connexion : - aucun émetteur des listes de révocation de certificats chargées en mémoire ne correspond à l'émetteur du certificat accompagnant la requête de connexion, - un numéro de série du certificat accompagnant la requête correspond à un numéro trouvé dans la liste de révocation des certificats de même émetteur chargée en mémoire, - la liste de révocation des certificats chargée en mémoire, de même émetteur que celui du certificat contenu dans la requête, n'est plus valide, c'est-à-dire que la date d'expiration de la liste est dépassée. 7. Procédé de contrôle de requêtes selon l'une des revendications précédentes, caractérisé en ce qu'un composant logiciel du serveur refuse une requête signée, telle qu'une requête de modification d'une donnée contenue dans le système d'information partagé de santé du serveur si au moins l'une des conditions suivantes est vérifiée lors du contrôle de révocation du certificat accompagnant la requête signée : - il n'existe pas de liste de révocation de certificats dont l'émetteur correspond à l'émetteur du certificat accompagnant la requête signée, - un numéro de série du certificat accompagnant la requête correspond à un numéro trouvé dans la liste de révocation des certificats de même émetteur chargée en mémoire, - la liste de révocation des certificats chargée en mémoire, de même émetteur que celui du certificat contenu dans la requête, n'est plus valide, c'est-à-dire que la date d'expiration de la liste est dépassée. 8. Procédé de contrôle de requêtes selon l'une des revendications précédentes, caractérisé en ce que les certificats d'authentification des acteurs de la santé se trouvent sur des cartes à puce de professionnel de 30 santé, généralement appelées cartes CPS, ou sur des cartes de personneld'établissement, généralement appelées cartes CPE, ou sur des systèmes informatiques. 9. Procédé de contrôle de requêtes selon l'une des revendications précédentes, caractérisé en ce que les listes de révocation des certificats sont téléchargées périodiquement, et préférentiellement une fois par jour. 10. Procédé de contrôle de requêtes selon l'une des revendications précédentes, caractérisé en ce qu'une des listes de révocation de certificats téléchargées remplace une liste déjà chargée en mémoire si toutes les conditions suivantes sont vérifiées lors d'un test périodique de comparaison entre ces deux listes, qui a lieu de préférence chaque minute : - la liste téléchargée a été modifiée depuis son dernier chargement, - la liste téléchargée a été modifiée depuis au moins trente secondes, - la liste téléchargée est plus récente que la liste déjà chargée, par comparaison des dates d'émission des deux listes, - la liste téléchargée est émise par la même autorité de certification que la liste déjà chargée, - la liste téléchargée possède le même nom qu'une liste téléchargée présente lors d'un démarrage précédent du serveur. 20