EXI EDC PSC 109-2

Document de conformité Pro Santé Connect
ans
Pro Santé Connect
Document de conformité
xxx
Chapitre 3 : Architecture et inventaire

En tant que FS, je m’engage à suivre et prouver le respect des points suivants :

  • Mettre en place des contrôles de traces et de certificats, à faire correspondre la partie publique du certificat à celle du certificat AUTH_CLI de l’offre ORG de l’IGC-Santé ;
  • Associer au proxy un certificat ORG_CLI pour chaque FS Utilisateur pour lequel il réalise des authentifications mutuelles ;
  • N’avoir qu’un certificat associé à un identifiant et une instance de l’application à chaque appel de l’API PSC utilisant le certificat du FS Utilisateur ;
  • Ne pas adopter d’architecture considérée interdite de l’EDC ;
EXI EDC PSC 109 – Contrôle 2
Opérateur de Service Proxy e-santé
[Il est attendu que le Fournisseur de Service détaille les mécanismes assurant l’authentification du proxy auprès du logiciel utilisateur ;
OU fasse référence à un extrait, clairement identifié, d’un document qu’il fournira.

]

Authentification du proxy auprès du logiciel utilisateur

En tant que Fournisseur de Service (FS), je m’engage à respecter et prouver les points suivants concernant l’authentification mutuelle entre le proxy eSanté et les FS Utilisateurs :

  • Certificat provenant d’une autorité reconnue pour le Proxy ESanté :
    Le Proxy doit exposer un certificat provenant d’une autorité de certification reconnue, c’est à dire, une autorité dont le certificat racine est présent dans les magasins de confiance des principaux navigateurs et systèmes d’exploitation. Le logiciel utilisateur doit reconnaître l’autorité utilisée par le proxy.

  • Contrôles de traces et de certificats :
    Tous les certificats clients sont vérifiés à chaque appel. La partie publique du certificat transmis par le client est comparée à celle du certificat AUTH_CLI fourni par l’offre ORG de l’IGC-Santé.

  • Certificat ORG_CLI pour chaque FS Utilisateur :
    Le proxy eSanté est configuré pour utiliser un certificat ORG_CLI dédié pour chaque FS Utilisateur avec lequel il réalise des authentifications mutuelles.

  • Un certificat par identifiant et instance :
    À chaque appel de l’API PSC, un seul certificat est associé à un identifiant FS et à l’instance de l’application. Cela garantit qu’aucune duplication ou utilisation croisée de certificats n’est possible.

  • Architecture conforme :
    L’architecture du proxy respecte les directives EDC et n’adopte aucune configuration interdite ou non conforme.

Mécanismes mis en place

  1. TLS sur les appels au Proxy
  • Le logiciel utilisateur valide le certificat serveur présenté par le proxy
  1. mTLS sur les appels a PSC
  • Le proxy présente le certificat ORG_CLI correspondant au FS Utilisateur.
  • PSC valide le certificat avant d’accepter la communication.
  1. Traçabilité et audit
  • Tous les échanges mTLS sont loggés avec horodatage et ID de l’utilisateur.
  • Les certificats clients et serveurs sont enregistrés pour audit et revue.
  1. Séparation des certificats par FS Utilisateur
  • Chaque FS Utilisateur dispose d’un certificat distinct associé à son identifiant et instance.
  • Les clés privées sont stockées de manière sécurisée côté proxy, inaccessibles depuis l’extérieur.
  1. Revue et mise à jour des certificats
  • Les certificats ORG_CLI sont renouvelés selon les recommandations IGC-Santé.
  • Une procédure de rotation est en place pour éviter toute utilisation prolongée d’un certificat expiré.

Ce dispositif garantit que le proxy eSanté authentifie de manière fiable chaque FS Utilisateur tout en respectant les standards de sécurité de l’EDC et de PSC.