Présentation de la fonctionnalité
Objectif
Cette fonctionnalité vise à optimiser les interactions numériques dans le secteur de la santé. Elle permet désormais aux utilisateurs de se connecter à Pro Santé Connect en utilisant l'identité numérique fournie par leur établissement d'origine.
Bénéficiaires
Ce service est accessible à tous les établissements de santé qui gèrent leurs comptes utilisateurs via un fournisseur d'identité (FI) compatible. Ces établissements de santé peuvent offrir à leurs utilisateurs la possibilité de se connecter à Pro Santé Connect avec leurs identifiants locaux pour une durée prédéterminée.
Impact et Évolution
La mise en œuvre de cette fonctionnalité a nécessité une évolution significative de la plateforme Pro Santé Connect. Elle aura un impact direct sur les établissements de santé, les éditeurs de logiciels et les utilisateurs finaux. Une collaboration étroite entre notre équipe PSC et le support et l'expertise de l'éditeur de la solution de gestion des identités est nécessaire, ainsi que la participation active des établissements de santé intéressés.
Gouvernance et Collaboration
Une gouvernance de projet sera mise en place pour chaque fournisseur d'identités afin d'assurer le bon déroulement des travaux, la prise de décisions efficace et la gestion des différents intervenants. Cette gouvernance sera détaillée dans la documentation technique fournie par l'ANS, l'éditeur de la solution de gestion des identités, et sera communiquée aux établissements candidats.
Prérequis Techniques et Contractuels
Les établissements souhaitant utiliser cette fonctionnalité doivent satisfaire à certains prérequis techniques et contractuels. Ces prérequis seront détaillés sur cette page et mis à jour régulièrement pour refléter l'évolution de la fonctionnalité et les retours des participants.
Le processus d'authentification cible pour les ES
Participez au projet en tant qu'éditeur de solution de gestion des identités
Nous vous donnons la possibilité de proposer à vos établissements clients la délégation de l'authentification Pro Santé Connec à leurs identités locales.
- Pour cela votre solution doit être compatible avec les exigences de Pro Santé Connect à propos des fournisseurs d'identités tiers ;
- Vous devez constituer un panel d'établissements candidats afin de pouvoir pleinement tester la solution dans la plus grande partie des usages quotidiens du terrain ;
- Vous devez founir un ensemble documentaire technique à destination des établissements de santé ;
- Vous devez respecter le référentiel d'exigences dédié à la délégation des authentifications à un FI local.
Si vous souhaitez commencer les travaux d'intégration, transmettez nous votre demande :
Participez au projet en tant qu'établissement de santé
Nous permettons aux DSI des établissements de santé de déléguer à leurs comptes utilisateurs locaux l'authentification Pro Santé Connect.
- Pour cela vous devez être utilisateur d'une solution de gestion des identités déjà intégrées dans Pro Santé Connect ;
- Vous devez respecter le référentiel d'exigences dédié à la délégation des authentifications à un FI local.
Consultez la liste des fournisseurs d'identités déjà supportés par Pro Santé Connect
Si la solution de gestion d'identités que vous utilisez n'est pas dans la liste des solutions supportées nous vous invitons à prendre contact avec votre éditeur et lui proposer d'intégrer sa solution dans Pro Santé Connect en prenant contact avec l'équipe Pro Santé Connect.
Prérequis techniques
La solution de gestion des identités doit être pleinement compatible avec la norme OpenID Connect et prévoir d'être compatible avec OpenID for Verifiable Presentations.
Techniques
- Etre compatible OpenID Connect ;
- Définir conjointement avec l'ANS les valeurs AMR qui seront autorisées pour indiquer la force d'authentification dans le claim AMR (RFC8176) ;
- Indiquer dans les requêtes l'établissement source de la demande ;
- Sécurisation des échanges par TLS (Transport Layer Security) ;
- Implémentation de mécanismes de consentement utilisateur conformes aux réglementations ;
- Support des protocoles de cryptographie recommandés pour garantir la confidentialité et l'intégrité des données.
Fonctionnels
- Capacité d'audit de configuration ;
- Gestion des identités et des accès (IAM) avec prise en charge des rôles multiples, sans possibilité pour les utilisateurs de modifier eux-mêmes la force d'authentification ;
- Mécanismes de gestion des erreurs et des exceptions.
Organisationnels
- Panel d'établissements diversifiés pour valider la solution ;
- Documentation technique à destination des établissements ;
- Accompagnement et support des établissements ;
- Planification de la gestion de crise et des incidents.
Soumettez votre solution de gestion des identités
Vous êtes éditeur d'une solution de gestion des identités et des accès et vous intervenez dans le secteur de la santé ?
Le référentiel d'exigences pour les FI tiers
| Version | Statut | Evolutions | Date d'application |
|---|---|---|---|
| 1.0 | En construction | Création | 30 mars 2024 |
Exigences générales
| N° | Thématique | Description | Entités concernées |
|---|---|---|---|
| EXI FI 01 | équipes de sécurité | Au sein des équipes du fournisseur d’identités et de l’établissement de santé, les responsables de la sécurité DOIVENT être identifiés. Leurs responsabilités DOIVENT être formalisées. Elles DOIVENT couvrir les activités de conception, de développement, d'installation, d'exploitation, d'administration, de maintenance et de support afin d'assurer la mise en œuvre des mesures de sécurité | Fournisseur d’identités Etablissement de santé |
| EXI FI 02 | sensibilisation | Une sensibilisation générale aux enjeux et aux risques liés à la sécurité des systèmes d'information DOIT être menée pour les équipes du fournisseur d’identités et de l’établissement. Cette sensibilisation DOIT s'effectuer pour l'ensemble des équipes en charge des activités de conception, de développement, d'installation, d'exploitation, d'administration, de maintenance et de support. Un fournisseur d’identités étant destiné à traiter des données à caractère personnel, la sensibilisation DOIT intégrer des obligations légales ainsi que des réglementations applicables | Fournisseur d’identités Etablissement de santé |
| EXI FI 03 | plan d’assurance sécurité | Si l’établissement, le fournisseur d’identités ou un tiers sous sa responsabilité assure l'hébergement de tout ou partie des composants du système, ou fournit tout ou partie du système sous forme de service (SaaS) ALORS, il DOIT intégrer dans le plan d'assurance sécurité du système les mesures de sécurité et les engagements entre l'hébergeur et la structure utilisatrice, pour l'environnement de mise en œuvre du système | Fournisseur d’identités Etablissement de santé |
| EXI FI 04 | antivirus | L’établissement de santé et le fournisseur d’identités DOIVENT s’assurer que les postes de travail utilisant la solution disposent d’un antivirus à jour afin de se prémunir des attaques du type cheval de Troie, contre les fichiers malicieux, par exemple | Etablissement de santé |
| EXI FI 05 | guide de bonnes pratiques | Un standard ou guide de bonnes pratiques concernant l’installation et l’administration de la solution du fournisseur d’identités DOIT être défini par l’éditeur de la solution et suivi par l’établissement | Fournisseur d’identités Etablissement de santé |
| EXI FI 06 | test d’intrusion | Le fournisseur d’identités DOIT avoir fait l’objet d’un test d’intrusion réalisé par un prestataire d’audit de la sécurité des systèmes d’information (PASSI) qualifié*. Ce test d’intrusion est à la charge de l’éditeur. Il doit être réalisé conformément au guide d’utilisation mis à sa disposition et donne lieu au remplissage par le prestataire d’audit d’un formulaire qui permet de valider la conformité du système à des points de contrôles essentiels portant sur la sécurité de celui-ci. Ce formulaire qui constitue une preuve à fournir DOIT afficher le caractère éligible au référencement du système, être daté de moins d’un an et être signé électroniquement par le prestataire ayant réalisé l’audit. NB : La réalisation d’un audit PASSI (conditions de réalisation spécifiques et auditeur certifié PASSI) n’est pas requise. L’unique prérequis est de faire réaliser le test d’intrusion par un organisme qualifié PASSI. » *liste des prestataires de services qualifiés : https://www.ssi.gouv.fr/entreprise/qualifications/prestataires-de-services-de-confiance-qualifies/prestataires-daudit-de-la-securite-des-systemes-dinformation-passi-qualifies/ | Fournisseur d’identités |
| EXI FI 07 | processus de veille | Un processus de veille (automatisé ou non) sur les vulnérabilités des composants du fournisseur d’identités DOIT être défini et appliqué. Un processus de patch management ou de distribution des patchs (dans le cas d'une solution hébergée par une structure utilisatrice) DOIT être déterminé et mis en œuvre (distribution des patchs, des mises à jour, etc.) | Fournisseur d’identités Etablissement de santé |
| EXI FI 08 | procédure de sauvegarde | Le fournisseur d’identités et l’établissement DOIVENT proposer une procédure de sauvegarde et de restauration ainsi que la documentation associée | Fournisseur d’identités Etablissement de santé |
| EXI FI 09 | personne morale européenne | Le fournisseur d’identités DOIT être une personne morale (entreprise, association, groupement d’intérêt économique, etc.) de droit privé ou public, immatriculée dans l’Union Européenne | Fournisseur d’identités |
| EXI FI 10 | bonne conduite | Le fournisseur d’identités DOIT s'engager à ne pas prononcer des propos ou proposer des contenus contrevenant aux droits d'autrui ou à caractère diffamatoire, injurieux, obscène, offensant, violent ou incitant à la violence, politique, raciste ou xénophobe et de manière générale tous propos ou contenus contraires à l'objet du service, aux lois et règlements en vigueur, aux droits des personnes ou aux bonnes mœurs | Fournisseur d’identités |
| EXI FI 11 | langue française | Le service DOIT être proposé en langue française | Fournisseur d’identités |
| EXI FI 12 | respect des lois | Le fournisseur d’identités DOIT respecter la loi du 6 janvier 1978, dite « Informatique et Libertés », ainsi que le Règlement Général sur la Protection des Données (RGPD) | Fournisseur d’identités |
| EXI FI 13 | traitement des données | Le fournisseur d’identités DOIT, lorsqu’il traite de données à caractère personnel, assurer leur confidentialité et leur intégrité, tout en assurant leur hébergement sécurisé | Fournisseur d’identités Etablissement de santé |
| EXI FI 14 | modification du service | Le fournisseur d’identités DOIT prévenir l’ANS dans le cas où le service ne serait plus conforme à une des exigences du présent référentiel et/ou en cas de changement dans les informations qui ont été déclarées lors de la candidature au raccordement à Pro Santé Connect | Fournisseur d’identités |
Modalités de raccordement technique
| N° | Thématique | Description | Entités concernées |
|---|---|---|---|
| EXI FI 15 | compatibilité OIDC | Le fournisseur d’identités DOIT être compatible avec le standard OpenID Connect | Fournisseur d’identités |
| EXI FI 16 | support flux Authz Code Flow | Le fournisseur d’identités DOIT supporter le flux Authorization Code Flow | Fournisseur d’identités |
| EXI FI 17 | client id / client secret | Le fournisseur d’identités DOIT permettre à PSC de s’authentifier à son service en tant que client en utilisant un couple client ID / client secret | Fournisseur d’identités |
| EXI FI 18 | certificat client PSC | Le fournisseur d’identités DOIT permettre à PSC de s’authentifier à son service en tant que client en utilisant un certificat électronique | Etablissement de santé |
| EXI FI 19 | claim auth_time | Le fournisseur d’identités DOIT transmettre à PSC le timestamps indiquant la dernière authentification explicite du PS à son service. Cette information DOIT être contenue dans le claim auth_time de l’ID token transmis à PSC | Fournisseur d’identités |
| EXI FI 20 | claim contenant le MIE utilisé | Le fournisseur d’identités DOIT transmettre à PSC le moyen d’identification électronique utilisé par le PS pour s’authentifier à son service par le moyen des jetons OIDC | Fournisseur d’identités |
| EXI FI 21 | identifiant unique immuable PS | Le fournisseur d’identités DOIT transmettre à PSC un identifiant unique immuable permettant à PSC d’identifier l’utilisateur souhaitant s’authentifier à PSC par le moyen de l’ID token. Si le fournisseur d’identités dispose d’une architecture multi-instances, il DOIT s’assurer que l’identifiant transmis à PSC est unique et immuable parmi toutes les instances existantes du FI | Fournisseur d’identités |
| EXI FI 22 | identifiant unique immuable ES | Le fournisseur d’identités DOIT transmettre à PSC un identifiant unique immuable permettant à PSC d’identifier l’établissement de santé auquel appartient le compte du PS souhaitant s’authentifier à PSC. Par défaut, cette information est contenue dans le claim « iss » de l’ID token | Fournisseur d’identités |
| EXI FI 23 | informations d’identité du PS | Le fournisseur d’identités DOIT transmettre les informations suivantes à PSC concernant le PS souhaitant s’authentifier à PSC :
| Fournisseur d’identités |
| RECO FI 01 | paramètre MAX_AGE | Le fournisseur d’identités DEVRAIT supporter le paramètre MAX_AGE permettant à PSC de lui spécifier une durée de session utilisateur maximale | Fournisseur d’identités |
| RECO FI 02 | endpoint de déconnexion | Le fournisseur d’identités DEVRAIT proposer un endpoint de déconnexion globale des utilisateurs | Fournisseur d’identités |
Niveau d’authentification
| N° | Thématique | Description | Entités concernées |
|---|---|---|---|
| EXI FI 24 | fonctionnalités FI | Le fournisseur d’identités DOIT :
| Fournisseur d’identités |
| EXI FI 25 | durée de session | Lorsqu’un utilisateur est déjà authentifié auprès du FI, au moment de réaliser la fédération d’identités avec PSC, le fournisseur d’identités DOIT s’assurer que la dernière authentification explicite de l’utilisateur a eu lieu il y a moins de 4 heures. Si cette durée est dépassée, le fournisseur d’identités DOIT exiger une réauthentification de l’utilisateur. | Fournisseur d’identités |
| RECO FI 03 | propagation de l’authentification | Le fournisseur d’identités DEVRAIT proposer un mécanisme permettant à son service d’hériter de la session de l’utilisateur sur son poste de travail | Fournisseur d’identités |
| EXI FI 26 | qualité des données d’identité | L’établissement de santé DOIT s’assurer de la bonne gestion des données d’identité des PS avant toute fédération avec PSC : adresse email professionnelle sur un domaine appartenant à l’établissement, nom et prénom conformes. Cette liste pourra être complétée lors de l’intégration de l’établissement de santé. | Etablissement de santé |
| EXI FI 27 | garanties d’identité | L’établissement doit mettre en place les mesures de sécurité nécessaires et suffisantes permettant de garantir l’identité véhiculée à PSC (gestion de l’inactivité, etc.) | Etablissement de santé |
Contrôle et audit
| N° | Thématique | Description | Entités concernées |
|---|---|---|---|
| EXI FI 28 | capacité de contrôle | Le fournisseur d’identités et l’établissement DOIVENT mettre à disposition de l’ANS un moyen de récupérer des indicateurs présentant les politiques d’accès à l’application PSC (durée de session, MIE et force d’authentification autorisés, etc.) | Fournisseur d’identités Etablissement de santé |
| RECO FI 04 | API d’audit | Le fournisseur d’identités DEVRAIT mettre à disposition de l’ANS une API lui permettant de requêter des relevés d’indicateurs de façon autonome sans avoir à faire de demande à l’établissement dans lequel le service est implémenté | Fournisseur d’identités |
Tests et bac à sable
| N° | Thématique | Description | Entités concernées |
|---|---|---|---|
| EXI FI 29 | test PSC bac à sable | Le fournisseur d’identités DOIT avoir testé avec succès son service avec les endpoints de Pro Santé Connect Bac à Sable, préalablement à toute connexion à la production | Fournisseur d’identités |
| EXI FI 30 | accès service de test FI | Le fournisseur d’identités DOIT donner accès à l’ANS à son service de test | Fournisseur d’identités |
Exigences de « maturité » cyber
| N° | Thématique | Description | Entités concernées |
|---|---|---|---|
| EXI FI 31 | processus IAM mature | Au sein d’un établissement de santé, un fournisseur d’identités DOIT être intégré à un processus IAM mature (répertoire d’identité local, processus de gestion du cycle de vie des identités, synchronisation, etc.) | Etablissement de santé |
| EXI FI 32 | comptes à privilèges | La gestion des comptes à privilèges au sein du fournisseur d’identités doit suivre les Recommandations relatives à l'administration sécurisée des systèmes d'information publié par l’ANSSI | Fournisseur d’identités Etablissement de santé |
| EXI FI 33 | gouvernance des MIE | Les établissements DOIVENT avoir des processus de commande, d’enrôlement, et de distribution des MIE sécurisés | Etablissement de santé |
| EXI FI 34 | incident de sécurité | Un établissement de santé DOIT prévenir l’ANS sous 12h en cas de détection d’un incident de sécurité et/ou impliquant une violation de données à caractère personnel au sein de son infrastructure. Un fournisseur d’identités DOIT prévenir l’ANS sous 12h en cas de détection d’un incident de sécurité et/ou d’une faille au sein de ses services | Fournisseur d’identités Etablissement de santé |
| EXI FI 35 | suivi des traces | La solution du fournisseur d’identités DOIT disposer de capacités suffisantes de suivi des traces permettant de remonter les événements ayant mené à une identification fédérée auprès de PSC en cas de demande de l’ANS (investigation, réquisition juridique, etc.) | Fournisseur d’identités |
| EXI FI 36 | conservation des traces | Le fournisseur d’identités et/ou l’établissement doit conserver les traces sur une durée minimale de 3 mois | Fournisseur d’identités Etablissement de santé |