Certificate requests for hospitals

Présentation au sujet: "Certificate requests for hospitals"— Transcription de la présentation:

1 Certificate requests for hospitals
UREG Certificate requests for hospitals session FR eHealth platform April 24th, 2014 Kris VAN AKEN Project Manager eHealth platform 1

2 Processus de certificat - Aperçu
Service de base certificats numériques : but et caractéristiques Fonction d'un certificat numérique Fonction dans un contexte eHealth Types de certificats eHealth Critères pour la demande d’un certificat eHealth Distinction selon l'emploi et l'environnement (application) Déroulement du processus de demande De quoi avez-vous besoin pour créer la demande de certificat? Application en ligne pour une demande de certificat eHealth Concrètement pour les hôpitaux UREG UMAN + demande de certificat établissement de soins (hôpital) Installation, emploi, cycle de vie

3 Processus de certificat - Aperçu
Service de base certificats numériques : but et caractéristiques Fonction d'un certificat numérique Fonction dans un contexte eHealth Types de certificats eHealth Critères pour la demande d’un certificat eHealth Distinction selon l'emploi et l'environnement (application) Déroulement du processus de demande De quoi avez-vous besoin pour créer la demande de certificat? Application en ligne pour une demande de certificat eHealth Concrètement pour les hôpitaux UREG UMAN + demande de certificat établissement de soins (hôpital) Installation, emploi, cycle de vie

4 Objectif et fonction du service de base « Certificats eHealth »
Fonction d'un certificat numérique Un certificat est un fichier numérique qui fait office de passeport numérique pour le propriétaire de ce fichier. Ce fichier est délivré et géré par une autorité de certification (CA) et il certifie la partie publique d’une paire de clés, dont le propriétaire protège la partie privée au moyen d’un mot de passe. Un certificat délivré par une autorité de certification est une confirmation électronique de l'identité et contient des informations qui sont utilisées pour protéger des données ou pour réaliser une connexion réseau sécurisée. Objectif dans un contexte eHealth Identification et authentification sûres d’un prestataire de soins afin de permettre un échange de données électronique sécurisé de système à système.

5 Objectif et fonction du service de base « Certificats eHealth »
Fonction dans un contexte eHealth Identification et authentification des acteurs du secteur belge des soins de santé Pour l'accès aux services de base eHealth via connexion système à système (et non via application web); Pour l'utilisation des services de base et SAV sous forme de services web Certificat d'authentification est complété par une clé de chiffrement eHealth Intégrateurs de logiciels (non prestataires de soins): Possibilité d'obtenir des certificats de test. Permettent aux collaborateurs IT des intégrateurs de logiciels actifs dans le secteur belge des soins de santé de tester l'intégration des services de base eHealth eHealth Integrated User and Access Management Après l’authentification avec le certificat eHealth, l’UAM pourra, sur base de règles d'accès, autoriser ou non les utilisateurs pour des sous-processus et des données spécifiques. Distinction ‘application access’/’data access’ Lorsqu'un prestataire de soins souhaite obtenir accès à certains services de base de la Plate-forme eHealth en ayant recours à une connexion système-à-système et non à une application web, il doit disposer d'un certificat eHealth. Le partenaire "système" est identifié et authentifié à l'aide de ce certificat, tandis que l'utilisateur (personne) est identifié et authentifié sur la base de son eID ou du token citoyen. Ceci vaut tant pour l'utilisation de services de base que pour l'utilisation de services à valeur ajoutée sous forme de services web. Les intégrateurs de logiciels (non prestataires de soins) ont par ailleurs la possibilité d'obtenir des certificats de test. Ceci permet aux collaborateurs IT des intégrateurs de logiciels actifs dans le secteur belge des soins de santé de tester l'intégration des services de base.

6 Le Certificate Manager génère également les clés de chiffrement
Les clés de chiffrement (ETK) sont créées sur base du certificat eHealth Le certificat eHealth est utilisé chaque fois qu'il est fait appel aux services web de la Plate-forme eHealth Pour l'obtention du certificat, la Plate-forme met une interface à la disposition. Cette interface requiert une authentification forte (sur base de l'eID du demandeur). Après que le demandeur du certificat a automatiquement introduit sa demande de certificat (fichier ehcsr), il recevra le certificat d'authentification quelques jours après (après la validation). Ce certificat eHealth lui permettra ensuite de créer, via la même interface, le certificat de cryptage correspondant dont il aura besoin lors de l'utilisation du service de base de chiffrement end-to-end.

7 Aperçu Service de base certificats numériques : but et caractéristiques Fonction d'un certificat numérique Fonction dans un contexte eHealth Types de certificats eHealth Critères pour la demande d’un certificat eHealth Distinction selon l'emploi et l'environnement (application) Déroulement du processus de demande De quoi avez-vous besoin pour créer la demande de certificat? Application en ligne pour une demande de certificat eHealth Concrètement pour les hôpitaux UREG UMAN + demande de certificat établissement de soins (hôpital) Installation, emploi, cycle de vie

8 Critères pour obtenir un certificat eHealth
Tout prestataire de soins peut, en tant qu'entité, faire appel aux certificats eHealth qui sont délivrés aux prestataires de soins. Le certificat d'authentification eHealth certifie l'identité soit d'une personne physique connue dans la source authentique "Cadastre des professions de santé", soit d’établissements qui sont actifs dans le secteur belge des soins de santé. Il incombe au responsable de l’établissement de demander un certificat. Cette personne doit être enregistrée dans les statuts en tant que représentant légal de l'organisation.

9 Type de demandes de certificat Portail eHealth
Les deux types de certificats suivent le standard international pour PKI de single sign-on L’ordre des attributs (contenu) n’est pas garanti (déterminé par le CA)

10 Aperçu Service de base certificats numériques : but et caractéristiques Fonction d'un certificat numérique Fonction dans un contexte eHealth Types de certificats eHealth Critères pour la demande d’un certificat eHealth Distinction selon l'emploi et l'environnement (application) Déroulement du processus de demande De quoi avez-vous besoin pour créer la demande de certificat? Application en ligne pour une demande de certificat eHealth Concrètement pour les hôpitaux UREG UMAN + demande de certificat établissement de soins (hôpital) Installation, emploi, cycle de vie

11 Point de départ demande de certificat: Portail eHealth

12 Portail eHealth: section download documents

13 Acceptation - Étape 1

14 Acceptation - Étape 1

15 Acceptation - Étape 1: enregistrement cas de test
Lien entre établissement de soins NIHII (RIZIV, INAMI ) et responsable du certificat SSIN (INSZ, NISS) Cas de test hôpital

16 Acceptation - Étape 2: Confirmation de la procuration
Coordination: chef de projet SPF SPSE: Benoît Schyns Coordination: chef de projet SPF SPSE: Benoît Schyn

17 Envoi du formulaire de procuration + cas de test

18 Envoi du formulaire de procuration + cas de test
UREG : Régistration des cas de test sera effectuée en une opération, pour tous les hôpitaux participants à UREG. Dès que l'enregistrement est effectué par eHealth, vous recevrez une confirmation et vous pourrez procéder à la demande de certificat (étape 3)  Validation eHealth

19 Acceptation - Étape 3: Certificate Manager (ACC)

20 Acceptation -Étape 3: Certificate Manager (ACC)

21 Le processus de demande en résumé
La procédure de demande d'un certificat eHealth comprend en gros trois phases: Dans une première phase, vous introduisez la demande au moyen d'une application qui est disponible sur le portail eHealth Validation de la demande La Plate-forme eHealth vérifie si vous êtes effectivement la personne que vous prétendez être de façon automatique, si le cas de test est enregistré sinon de façon manuelle (cette phase peut durer quelques jours) La Plate-forme eHealth vous avertira par courriel de l'approbation de votre demande. Après que vous avez reçu la confirmation (courriel), vous devez faire appel à l'application pour compléter la demande 2. Notification par courriel certificat d'authentification est disponible Demande certificat eHealth 3. Achèvement de la demande de certificat eHealth 21 21

22 De quoi avez-vous besoin?
Afin de pouvoir introduire la demande, votre PC doit disposer d’un lecteur eID du middleware nécessaire afin d’utiliser l’eID d’une version récente de Java Vous devez aussi tenir à ‘portée’ de main les cartes et numéros suivants votre carte d’identité et le code PIN correspondant le numéro INAMI ou le numéro BCE (i.e. le numéro d’entreprise) qui correspond à votre établissement, à votre cabinet médical ou à votre pharmacie. Si vous éprouvez un problème avec la demande de certificat, vous êtes prié de contacter le centre de contact eHealth. Vous trouverez également ce lien vers le centre de contact dans l’application de demande de certificat Par téléphone au 02/ ou via le formulaire en ligne

23 Manuel Certificate Manager
L'application vous aide à parcourir les étapes pour introduire la demande de certificat Manuel en ligne

24 Java webstart: génération locale de clés
Ce processus est effectué à l'aide de l'eHealth Requestor utility. Il s'agit d'une application webstart Java qui requiert une version Java 1.6 ou supérieur. Ce logiciel doit tourner en local sur votre ordinateur pour la génération locale de clés qui est importante pour garantir la sécurité de vos clés privées. Ce type de processus effectué en local est important, parce que c'est la seule façon pour la Plate-forme eHealth de garantir la sécurité et la non-compromission de votre clé d'authentification privée Vous devez générer la clé privée sur votre système local et la protéger à tout moment. C'est pourquoi il est important que vos systèmes soient correctement et suffisamment protégés pour le stockage de vos clés personnelles avant que vous ne démarriez ce processus.

25 Structure de l’exposé Concrètement pour les hôpitaux UREG
Service de base certificats numériques: but et caractéristiques Fonction d’un certificat numérique Fonction dans un contexte eHealth Type de certificats eHealth Critères pour la demande d’un certificat eHealth Distinction selon l’usage et l’environnement (application) La procédure de demande se déroule comment? De quoi avez-vous besoin pour créer la demande de certificat? Application en ligne pour une demande de certificat eHealth Concrètement pour les hôpitaux UREG Principe d’authorisation Acceptation resp Production Production : UMAN + demande certificat institution de soins de santé (hôpital) Installation, usage, cycle de vie

26 Certificat au nom d'un hôpital
Processus à parcourir par un hôpital afin d'obtenir un certificat de production Quelle personne au sein de l'hôpital peut demander un certificat eHealth? Acceptation resp. production

27 Qui peut demander un certificat au nom d’un hôpital
Qui peut demander un certificat au nom d’un hôpital? Environnement de production L'administrateur (compétence juridique au nom de l'hôpital) Peut intervenir comme représentant légal de l'hôpital Il peut donner une procuration au nom de l'hôpital Apporter les pièces justificatives nécessaires (statuts, décision du conseil d'administration, ...) qui confirment de manière concluante que l'intéressé est légalement autorisé à donner une procuration au nom de l'institution en question Mandataire Par le biais d'un formulaire de procuration (de l'administrateur au mandataire) À télécharger depuis le portail eHealth (support services de basegestion des accèscertificats section download)

28 Environnement de production Enregistrement en ligne au moyen de l’UMan
Enregistrement en tant que 'certificate manager' au moyen du eHealth User Management (UMAN) Portail eHealth  Prestataire de soins  Comment accéder à la eHP  Obtenir accès Choisissez le type d'institution : Hôpital : ONSS ou ONSSAPL RAE Responsable Accès Entité compétence juridique à travers les statuts de l’établissement de soins (entité) RAE désigne le gestionnaire local (GL)  GL2  GL3 GL reçoit automatiquement le rôle de "Certificate Manager" dans l’UMan Ce mandataire (gestionnaire local) sera dorénavant, au nom de l'hôpital, reconnu comme 'gestionnaire de certificat' lors de la demande de certificat Démarrage du eHealth Certificate Manager via le portail eHealth Support  services de base  gestion des accès  certificats eHealth Démarrage du “eHealth Certificate Manager” (Prestataire de soins = certificat de production) Utilisez NIHII-HOSPITAL comme 'identifiertype' de l‘établissement de soins de santé

29 Production - Étape 1 UMan
au nom de l'hôpital: enregistrement “gestionnaire de certificat” (certificate manager) dans UMan Bon nombre d'hôpitaux ont enregistré un RAE dans l’UMan dans le cadre d’une première application eHealth Le centre de contact eHealth peut vous confirmer si le Responsable Accès Entité (RAE) est connu dans l’UMan pour l'hôpital Centre de contact: 02/ Indiquez le nom+ numéro INAMI de l'hôpital

30 Production Étape 2 : eHealth Certificate Manager

31 En résumé: Certificat au nom d'un hôpital
ACCEPTATION Enregistrement cas de test 3 étapes PRODUCTION Enregistrement du RAE dans UMan RAE  Gestionnaire local pour l'application eHealth platform Certificate Manager Le gestionnaire local lance la demande (application)

32 Structure de l’exposé Installation, usage, cycle de vie
Service de base certificats numériques: but et caractéristiques Fonction d’un certificat numérique Fonction dans un contexte eHealth Type de certificats eHealth Critères pour la demande d’un certificat eHealth Distinction selon l’usage et l’environnement (application) La procédure de demande se déroule comment? De quoi avez-vous besoin pour créer la demande de certificat? Application en ligne pour une demande de certificat eHealth Concrètement pour hôpitaux UREG Principe d’authorisation Acceptation resp Production Production : UMAN + demande certificat institution de soins de santé (hôpital) Installation, usage, cycle de vie

33 Cycle de vie d'un certificat
Installation Manipulation de fichiers par l’utilisateur n’est plus requise (recherche du fichier sur l’ordinateur, envoi du fichier par courriel, recevoir les fichiers de certificat par courriel et les enregistrer sur le disque dur) Le certificat est installé en arrière-plan sur votre pc Consignes de sécurité (page de support du portail eHealth) Durée de vie Période de validité: nominal 1 an ACCEPTATION 3 ans PRODUCTION + 3 mois période de renouvellement Période au cours de laquelle un renouvellement est autorisé: 3 mois avant la date d’échéance Rappels automatiques à partir de trois mois avant la date d’échéance Responsabilité du propriétaire du certificat de renouveler le certificat Demande de renouvellement  aucune prolongation n’est effectuée Important lors du renouvellement: Rétrocompatibilité pour le cryptage n’est pas garanti. Étant donné que le cryptage est effectué pour les “données en transit”, un nouveau certificat et un nouvel ETK sont délivrés lors de l’implémentation du renouvellement sans garantie que les anciens messages puissent être déchiffrés à l’aide d’un nouvel ETK. When a Health Care actor is forced to perform any manipulations such as searching a file on his file system, sending a mail with an attachment, receiving files by mail and store them on his hard disk Lorsqu'un nouvel ETK est créé et activé, les nouveaux messages seront cryptés pour ce nouvel ETK, et donc déchiffrables avec la clé privée de ce nouvel ETK. Les anciens messages seront toujours décryptables à l'aide de la clé privée de l'ancien ETK, que l'utilisateur doit conserver. A lui simplement de sélectionner le bon p12 (keystore)

34 Support eHealth portal (section support) eHealth centre de contact
Manuels eHealth Certificate Manager UMAN eHealth centre de contact Centre de contact : Lundi à vendredi de 07:00 à 20:00 Par exemple: Statut d’une demande de certificat