Authentification unique (SSO) et Système d`Information de l`Hôpital

Transcription

Authentification unique
(SSO) et Système
d’Information de
l’Hôpital
Le dossier étendu du patient et le
changement rapide d’utilisateur.
livre
blanc
39 F2 00LT 10
Evidian Enterprise SSO
Maîtriser l’accès aux applications de l’hôpital
L’informatique d’un hôpital doit obéir à des objectifs apparemment contradictoires. Il
faut stocker des données médicales complètes et pertinentes sur les patients, fournir
rapidement cette information à des personnels de santé qui travaillent dans l’urgence,
mais aussi respecter des contraintes strictes de confidentialité.
Dans la pratique, les audits de sécurité révèlent souvent des comportements dictés
par la nécessité médicale : mots de passe partagés, session commune, applications
qui restent ‘ouvertes’ pour demeurer accessibles…
Par ailleurs, budget et personnel ne sont pas infiniment extensibles. Il est difficile de
modifier des pratiques et applications qui ont parfois été conçues pour un autre
contexte réglementaire. Comment alors rationaliser les politiques d’accès dans un
établissement de santé ?
Ce livre blanc décrit l’apport d’une solution d’authentification unique (en anglais single
sign-on ou SSO) dans un établissement de santé. Le SSO est un moyen ‘peu intrusif’
de protéger l’accès aux données médicales sans porter atteinte à l’efficacité des
personnels de santé, qui peuvent ainsi consacrer plus de temps aux patients.
Il s’appuie sur un cas réel de mise en place d’un SSO dans un hôpital, avec contrôle
d’accès par carte de personnel de santé.
Il montre comment la solution Enterprise SSO d’Evidian répond aux besoins essentiels
du contexte hospitalier, notamment l’accès sécurisé avec changement rapide
d’utilisateur.
SSO pour Système d’Information de l’Hôpital
L'année dernière au restaurant de l'hôpital, Laurence, responsable informatique
d'un hôpital, discute avec des collègues des services de santé…
Laurence : Qu'est ce qu'il t'arrive Franck, tu ne manges pas beaucoup.
Franck : J'ai l'appétit coupé. On a failli perdre un patient pour une bourde
impardonnable.
Laurence : Que s'est-il passé ?
Franck : Il était allergique à un médicament et on ne l'a pas détecté.
Laurence : D'après ce que l'on m'a expliqué, cela peut malheureusement arriver. Du
moment que vous avez appliqué les procédures officielles, vous n'avez rien à vous
reprocher.
Franck : Nous avons parfaitement appliqué les procédures, comme tu dis, mais nous
avons quelque chose à nous reprocher.
Le dossier étendu du patient
2
Laurence : J'ose à peine te demander quoi ?
Franck : Ce patient est entré en neurochirurgie la semaine dernière, il avait alors
mentionné son allergie. Il a ensuite été transféré dans notre service et il n'a pas cru
bon de parler à nouveau de son allergie puisqu'il l'avait déjà fait.
Laurence : Je ne comprends pas. L'équipe de neurochirurgie ne l'a pas indiqué dans
son dossier ?
Franck : Si, ils l’ont mis dans son dossier du service de neurochirurgie.
Laurence : La neurochirurgie n'est pas encore passée sur le dossier central ?
Franck : Non, pas encore. C'est prévu mais pas pour tout de suite.
Laurence : Mais alors, ça veut dire que vous ne pouvez pas accéder aux informations
des patients qui viennent de ce service.
Franck : En fait si, ils nous ont donné un accès.
Laurence : Et pourquoi vous ne l'avez pas utilisé ?
Franck : Parce que sur le moment, le médecin ne s'est pas rappelé de l'identifiant et
du mot de passe pour y accéder et qu'ensuite il a oublié de le faire.
Laurence : Aïe ! Mais tous les problèmes d'accès aux données seront réglés lorsque
le dossier du patient sera centralisé et unique.
Franck : Pas forcément, car au niveau de chaque service, il y des applications
spécifiques très spécialisées qui ne sont pas et ne seront jamais gérées par
l'informatique centrale de l'hôpital. Les informations de ces applications font bien partie
du dossier du patient mais n'intéressent qu'un service et seraient trop compliquées à
intégrer en central.
En fait, le contenu du dossier du patient au sens large n'est pas une entité unique pour
tout le monde mais dépend de chaque service. Il y a bien entendu un cœur unique qui
regroupe par exemple les données sur l'identité et les protocoles (compte rendus) des
différents examens.
Et tout ça avec l'obligation de protection des données de santé privées qui ne doivent
pas être à la disposition de tout le monde.
Laurence : Donc, le dossier du patient, au sens large, est une collection d'applications
et de données dont il faut sécuriser, contrôler et simplifier les accès.
Laurence de retour à son bureau
Laurence : Comment faire pour simplifier, contrôler et sécuriser les accès aux
applications ? C'est à la fois une question de survie des patients et de protection de
leur vie privée…
Elle prend son téléphone.
3
Sauver des vies
Dans un hôpital, on trouve généralement trois familles d’applications
1.
Les systèmes bureautiques tels que les PC, la messagerie ou les serveurs
bureautiques.
2.
Le système de gestion administrative (dit aussi back office) qui regroupe gestion
du personnel et des achats, comptabilité, tarification, facturation des patients,
paye et relation avec les organismes sociaux.
3.
Les systèmes opérationnels de soins qui gèrent le patient en tant que tel
Ces applications partagent en général des informations, par exemple :
 L'accueil et le planning gèrent l’admission et les rendez-vous des patients. L'accueil
des urgences possède souvent ses propres écrans simplifiés à l'extrême pour des
informations spécifiques au traitement des urgences.
 Les applications d'accueil communiquent avec l'application de traitement
administratif du patient qui regroupe les informations telles que l'adresse, la
personne à contacter en cas de problème grave, le médecin traitant et les données
de prise en charge (assurance maladie, mutuelle, …) Elle contient aussi la liste des
prestations effectuées.
 Cette application alimente les systèmes médicaux des services comme le
laboratoire d'analyse du sang et des urines ou des tissus, la radiologie, la
neurologie, la psychiatrie ou encore les activités infirmières…
 Les applications spécifiques sont regroupées autour du dossier du patient qui
contient les protocoles ainsi que les résultats des différentes analyses. Elles
communiquent au travers d'un point d'accès sécurisé avec les acteurs extérieurs
de la santé au sein, par exemple, du réseau ville - hôpital.
Front office
Enregistrement du patient
Accueil
Accueil urgences
Traitement administratif
Identités
Prestations
Back office
Ressources humaines
Achats
Comptabilité
Facturation
Organismes
sociaux
Traitement médico-technique
Systèmes médicaux
(Labo, radio, cardio, psychiatrie...)
Dossier médical
Gestion du dossier
Serveur commun de résultats
Bureautique
PC
Serveur bureautique
Messagerie
Help desk
Communication des protocoles
Le système d'information de l'hôpital
4
Les informations du patient sont réparties sur plusieurs systèmes
La multiplicité des applications du front office rend difficile voire parfois impossible
l'échange des informations entre services.
Chaque service possède ses propres applications. Certaines informations de ces
applications peuvent concerner seulement le service lui-même. Mais elles peuvent
aussi être communiquées aux autres services qui s'occupent du même patient.
Du point de vue de l'informatique centrale, certaines applications spécifiques sont des
‘boites noires’ gérées par des équipes locales (mais qui sont tout de même des
sources de problèmes potentiels).
Le cloisonnement des applications a des impacts au niveau de la gestion des patients
lors des interactions inter-services. Ainsi, les demandes de prestations inter-services
utilisent des demandes papier. Il n'est pas rare de voir des infirmières consacrer la
moitié de leur temps de travail à vérifier que les dossiers fournis sont complets, que
les examens demandés ont bien été faits et que les résultats ont bien été transmis.
La protection des données de santé
Les informations sur notre santé sont l'un des aspects les plus importants de la vie
privée. Elles deviennent critiques lorsqu'elles révèlent une maladie ou un handicap ;
c'est alors qu'elles sont traitées par les systèmes d'information des acteurs de la
santé. Lorsque tout va bien, nous n'avons pas vraiment besoin d'ouvrir un dossier
médical.
La confidentialité est donc un enjeu incontournable. Les informations sont protégées à
différents niveaux par des lois, règlements et codes.
En France par exemple, le décret du 15 mai 2007 encadre la confidentialité des
informations médicales conservées sur support informatique ou transmises par voie
électronique. Il exige que l’accès aux données médicales se fasse nominativement,
après authentification par carte « CPS » à microprocesseur. Cela exclue donc les
accès partagés sous un même identifiant.
Au niveau européen, la directive 95/46 pour la protection des données à caractère
personnel définit les données de santé comme des données sensibles dont le
traitement est interdit sans le consentement explicite du patient.
Aux Etats-Unis, ce sont les directives issues de la loi HIPAA qui réglementent l'accès
et la sécurisation de ces données.
5
Secret médical
Protection des données informatiques
sur la vie privée
Protection des données informatiques
de santé
Secret médical et protection des données personnelles
informatiques.
Ces textes, ainsi que leur application par les tribunaux, placent la sécurité au cœur de
l'architecture du système d'information des acteurs de la santé.
Les hôpitaux ont l'obligation de sécuriser l'accès à ces informations.
Le dossier du patient
Dans de nombreux hôpitaux, un dossier informatisé du patient a été constitué pour
partager des informations de santé de façon contrôlée.
C'est une application centrale qui contient les éléments diagnostics et thérapeutiques
nécessaire à la coordination des soins du patient : compte rendus, protocoles,
résultats d'analyse…
On y trouve en général des informations de synthèse disponibles dans les différents
services. Il peut aussi être couplé à un serveur de résultats qui permet d'obtenir les
résultats complets d'analyse ou d'examen.
6
Les limites du dossier du patient
Malheureusement, le dossier du patient ne permet pas toujours d’accéder de façon
satisfaisante aux données du patient.
L'intégration des applications existantes dans les services peut prendre du temps.
Certaines applications anciennes sont même parfois impossibles à faire évoluer. En
effet, elles peuvent être des progiciels achetés à l'extérieur, ou encore des
applications développées par des médecins eux-mêmes sur leur PC.
De plus, le projet de consolidation autour du dossier du patient est en général un
projet avec plusieurs phases dans le temps. Il faut donc, même pendant la phase
transitoire, garantir l'accès sécurisé à toutes les informations du patient.
Pour finir, il y a des applications spécialisées dont les résultats n'intéressent qu'un
seul service. Ces applications sont parfois entièrement gérées par les équipes
médicales. Les intégrer au sein du dossier du patient serait une perte de temps et un
gaspillage de ressources financières. Il faut cependant garantir l'accès sécurisé à ces
applications.
Applications dédiées à un service
et gérées par le service
Données
analytiques
Applications dédiées à un service
et gérées par l’informatique
Données
analytiques
Dossier médical
Données
synthétiques
Les applications métiers des équipes médicales
7
Le médecin : un itinérant au sein de l’hôpital
Un médecin, au sein de l’hôpital, possède en général un poste fixe situé dans son
bureau ; c’est son poste de travail.
Ce médecin doit aussi, lors des visites à ses patients dans
l’hôpital, accéder à leurs dossiers médicaux. Il utilise alors
des PC en libre-service.
Il n’a pas le temps, à chaque fois qu’il souhaite obtenir une
information, de réinitialiser le PC, de s’identifier puis de
lancer les applications requises. Les applications sur les
PC sont donc elles aussi en libre service et les médecins
les utilisent sous l’identité d’un utilisateur générique. Les
informations sont donc accessibles dans l’hôpital, en zone
publique, sans contrôle ni traçabilité.
Un médecin doit pouvoir réquisitionner n’importe quel PC pour se connecter
rapidement à ses applications. Cette connexion doit cependant se faire en conformité
avec la politique d’accès aux applications et après contrôle de l’identité du médecin.
Cette réquisition n’est acceptable pour l’utilisateur habituel du PC que si ce dernier
peut retrouver, après l’intervention du médecin, son environnement de travail propre.
L’authentification par carte de santé
Au-delà de l’accès aux applications, se pose aussi la question de l’authentification de
l’utilisateur. Pour cela, de nombreux pays ont mis en œuvre une carte à
microprocesseur destinée aux professionnels de santé.
 En France, le GIP-CPS « délivre à chaque professionnel de santé qui en fait la
demande une carte d'identité professionnelle électronique, la CPS, qui lui permet
de se faire reconnaître de manière sûre par les applications ou les autres
professionnels du secteur ». Le décret de confidentialité du 15 mai 2007 rend
l’usage de la CPS obligatoire pour accéder aux données de santé à caractère
personnel.
 Au Royaume-Uni, la carte du programme NHS Connecting for Health (CfH), dite «
NHS smart card », permet aux personnels soignants de s’authentifier pour se
connecter à leurs applications.
Cette carte doit, idéalement, permettre aux personnels de santé d’accéder à toutes
leurs applications, y compris les applications mises à disposition par les hôpitaux.
La généralisation de l’authentification par carte à tout le personnel soignant peut
permettre de mettre en place, au niveau de l’hôpital, un système unique de contrôle,
d’authentification et d’accès aux applications.
8
Cas réel de projet de SSO avec changement rapide de l’utilisateur et préservation
du contexte
La direction d’un hôpital a demandé à son service informatique de mettre en place une
authentification unique (SSO) par carte à microprocesseur : carte de personnel de
santé ou carte vierge. L’objectif : simplifier l'accès à toutes les applications et protéger
la confidentialité des données.
Changement rapide d’utilisateur avec préservation du contexte
Ce SSO doit aussi permettre à un médecin qui se connecte à tout poste de travail de
trouver immédiatement son environnement de connexion et de lancer ses applications
sous son identité. Lorsque le médecin s’absente, le poste de travail doit retrouver son
environnement initial afin que son utilisateur puisse continuer à travailler.
9
Un projet de SSO pour simplifier et sécuriser l'accès aux données
vitales du patient
La direction informatique a décidé de mettre en place un système de SSO sécurisé :
 qui s'appuie sur les procédures existantes de gestion des utilisateurs,
 qui intègre toutes les applications de l'hôpital, même celles qui ne sont pas gérées
par les administrateurs centraux,
 qui ne modifie pas les applications du système d'information.
Les 3 catégories d'applications du système d'information
Du point de vue de la gestion des accès, le personnel médical peut accéder à trois
types d’application.
1. les applications communes comme les serveurs de groupe de travail ou la
messagerie.
•
Pratiquement tous les utilisateurs possèdent une messagerie ou accèdent à
un serveur de groupe de travail.
2. les applications métier comme le dossier du patient ou les systèmes médicaux.
Ces applications contiennent des informations relatives à la santé des patients.
•
Leur accès doit donc être sécurisé et contrôlé en central en fonction du profil
de l'utilisateur.
Écran de l'application de radiologie
10
3. les applications dédiées qui sont des applications métiers gérées et utilisées, soit
au niveau d'un service, soit par une personne unique.
•
Leurs accès sont gérés au niveau du service lui-même par le propriétaire de
l'application.
Application de gestion des chutes développée par un médecin
L'annuaire des utilisateurs
Dans le cas de cet hôpital, le répertoire des utilisateurs est un annuaire LDAP qui
contient les informations publiques telles que le nom, le prénom, l'identifiant, le numéro
de téléphone ou la localisation géographique. Le système de contrôle des accès et de
SSO utilise et met à jour ces données pour définir les profils des utilisateurs.
Gestion des applications et des identifiants et mots de passe
La gestion des identifiants et des mots de passe applicatifs diffère en fonction de
l'application.
Les mots de passe des applications communes (e-mail, frais, congés) étant déjà
distribués dans l’hôpital, ce sont les utilisateurs qui initialisent leurs identifiants et leurs
mots de passe dans le système de SSO.
Pour les applications métier qui donnent accès aux données de santé des patients,
l’hôpital souhaite sécuriser leur utilisation et a donc mis en œuvre l’administration
centralisée des identifiants et mots de passe. Ce sont les administrateurs qui
initialisent les identifiants et les mots de passe.
Les applications dédiées sont entièrement gérées au niveau des services, tant pour
la déclaration de l'application et de ses paramètres de connexion que pour
l'enregistrement de l'identifiant et du mot de passe.
11
Une chambre forte pour stocker les attributs de sécurité
Les attributs de sécurité des utilisateurs, tels que les mots de passe pour accéder aux
applications cibles, sont stockés dans une chambre forte.
Chambre forte
Applications communes
Applications métiers
Applications personnelles
Identifiants
mots de passe
La chambre forte pour les identifiants et mots de passe
L'utilisateur utilise différents types d'identifiants et mots de passe :
 Son identifiant et mot de passe d’accès à une station. Ce sont des attributs dits
« primaires » qui ne sont connus que du système sécurisé de SSO.
 Les identifiants et mots de passe « secondaires » qui vont lui servir lors de la
connexion aux applications. Ces attributs sont différents pour chaque application.
Ils sont gérés de manière différente en fonction du type d'application.
Scénario 1 : mise en place du SSO pour les applications communes
Certaines applications (e-mail par exemple) sont utilisées par tous les personnels
déclarés dans l'annuaire des utilisateurs de l'hôpital.
Les administrateurs n’ont donc pas besoin de gérer de liste des utilisateurs autorisés à
y accéder. Ils doivent seulement déclarer ces applications pour qu’elles soient prises
en compte par le SSO.
Pour les applications
communes, ce sont les
utilisateurs eux-mêmes
qui mettent à jour leurs
identifiants et mots de
passe qu'ils
connaissent déjà.
Un utilisateur, s’il connaît son identifiant et son mot de passe pour ses applications
communes, peut renseigner directement ces paramètres.
Le SSO détectera le lancement de l'application et demandera alors à l’utilisateur
l'identifiant et le mot de passe associé. Ces valeurs sont automatiquement
mémorisées par le système de SSO.
Par la suite, le système de SSO réalise lui-même les connexions aux applications et
les changements de mot de passe.
12
Délégation d’accès
Durant les congés ou lors d’un déplacement professionnel prolongé, un utilisateur peut
déléguer à un autre l’accès à une ou plusieurs applications afin de lui permettre
d’effectuer certaines tâches.
Précédemment, il était obligé de révéler son identifiant et son mot de passe, ce qui est
contraire à la politique de sécurité et formellement interdit.
A présent, le système de SSO sécurisé lui permet d’autoriser l’accès sous son nom à
un remplaçant temporaire. Cette délégation se fait sous contrôle de la politique de
sécurité, avec des dates de validité, historisation des accès sous délégation et sans
dévoiler les identifiants et mots de passe.
Scénario 2 : sécurisation de l’accès aux applications métier
L’accès aux applications métier est restreint à une liste donnée d'utilisateurs.
Ce sont les administrateurs qui mettent en œuvre l’administration centralisée. Dans ce
système de SSO sécurisé (voir encadré) les administrateurs :
Dans le cadre d'un
SSO sécurisé,
l'utilisateur ne connaît
pas l'identifiant et le
mot de passe qu'il
utilise pour se
connecter à son
application métier
 déclarent les applications : le nom et les paramètres qui permettent d'en détecter la
fenêtre de lancement ou la fenêtre de demande de changement de mot de passe,
 enregistrent les utilisateurs autorisés avec leur identifiant et leur mot de passe
secondaire. Parallèlement, l'administrateur doit créer/modifier le compte utilisateur
sur l'application métier cible.
Par la suite, le système de SSO automatise les connexions aux applications et les
changements de mot de passe. À aucun moment, l'utilisateur n'a connaissance de ses
identifiants et mots de passe secondaires.
Renforcement de la sécurité pour l’accès aux applications métiers critiques
L’application de gestion des relations avec les organismes sociaux doit être
particulièrement sécurisée car elle traite de données confidentielles du patient et du
financement de l’hôpital.
Cette application, bien qu’intégrée dans le système de SSO, est protégée de manière
particulière : lors du lancement de l’application, le système de SSO redemande à
l’utilisateur son code PIN pour s’authentifier via la carte de santé.
Cette re-authentification permet d’augmenter la sécurité d’accès à l’application tout en
conservant les avantages du SSO.
De plus, l’option de délégation des accès est désactivée pour cette application. Ainsi,
seules les personnes réellement autorisées peuvent accéder à cette application.
Enfin, afin de limiter les risques au maximum, l’accès à cette application est restreint
aux seuls PC du service concerné. Un utilisateur ne pourra pas utiliser cette
application à partir d’un autre poste.
13
L'accès au dossier du patient ou aux systèmes médicaux des services est ainsi
intégré dans une solution centralisée et globale de contrôle des accès aux
données du patient.
Scénario 3 : simplification de la prise en compte des applications dédiées
Les utilisateurs qui accèdent à des applications spécifiques à un service peuvent
souhaiter, eux aussi, les intégrer dans le système de SSO sécurisé.
Le système de SSO leur donne la possibilité de :
Pour les applications
dédiées, c'est
l'utilisateur qui définit
tous les paramètres de
l'application.
 déclarer eux-mêmes ces applications, c'est à dire d'en définir le nom et les
paramètres qui vont permettre de détecter le lancement ou la demande de
changement de mot de passe,
 s’auto-enregistrer à ces applications, c'est à dire de définir l'identifiant et le mot de
passe secondaire pour accéder à l'application.
Puisque ces applications sont gérées au niveau d'un service, le responsable de ce
service peut décider d'en donner l'accès à des membres d'un autre service. Ces
derniers, en paramétrant leur module de SSO, peuvent alors, de manière automatique
et sécurisée, accéder aux données des patients collectées et gérées par un autre
service que le leur.
Il est donc possible de prendre en compte les applications dédiées à un service
ou en cours de migration vers le dossier du patient pour les intégrer dans le
système de SSO.
Le changement rapide d’utilisateur avec préservation du contexte
Un médecin peut utiliser n’importe quel PC pour accéder à ses applications. Il applique
alors une procédure de réquisition.
Si le PC est en cours d’utilisation, son utilisateur enlève sa carte : le PC se met en
veille. Le médecin introduit alors sa carte de personnel de santé et s’authentifie en
fournissant son code PIN. Il obtient son environnement personnel de connexion, ses
applications principales sont lancées ; il peut alors effectuer les opérations qu’il
souhaite.
Lorsque le médecin n’a plus besoin du PC, il lui suffit de retirer sa carte pour
supprimer son environnement du PC.
L’utilisateur initial réintroduit alors sa propre carte, donne son code PIN et retrouve son
environnement initial.
14
L’authentification par carte de professionnels de santé
Chaque utilisateur se voit affecter une carte : soit la carte CPS avec un certificat déjà
présent pour les médecins, soit une carte « vierge » pour les utilisateurs qui ont
seulement besoin d’accéder aux applications locales.
Cette carte permet à chaque utilisateur de s’authentifier lorsqu’il se connecte à son PC
puis lors des demandes de ré-authentification associées aux applications sensibles.
Cette carte permet aussi au médecin de prendre la main sur un PC pour accéder
immédiatement à ses applications.
Perte ou oubli d’une carte
Si un personnel soignant, médecin ou non, oublie sa carte, l’hôpital peut lui en prêter
une de manière temporaire afin de lui permettre d’accéder aux applications de
l’hôpital. La carte oubliée est alors désactivée pour l’accès aux applications de
l’hôpital.
Si la carte est retrouvée, elle peut être réactivée. Sinon, le médecin devra demander
une nouvelle carte CPS. En attendant, il peut continuer à utiliser sa carte temporaire
pour accéder aux applications de l’hôpital.
Le système de SSO a permis de fluidifier et sécuriser l'accès aux données médicales
du patient grâce à la mise en place d'un système de contrôle des accès et de SSO :
 Les accès au dossier du patient, au serveur de résultats et aux systèmes médicaux
sont pilotés en central.
 Les accès aux systèmes spécialisés des services sont pilotés par les services euxmêmes.
Un médecin ou un chirurgien peut à présent accéder à toutes ses applications
autorisées de manière automatique via le SSO sur son poste de travail ou sur un PC
en libre-service à accès contrôlé.
Le Système d'Information de l'Hôpital est ainsi vu comme un seul dossier étendu du
patient accessible de manière sécurisée à partir de tous les postes de l’hôpital.
La solution mise en place dans l’hôpital
Pour le SSO et la mise en œuvre de la politique des accès aux applications, la solution
s’appuie sur Evidian Enterprise SSO qui est un module de l’offre de gestion des
identités et des accès d’Evidian.
15
Les principales fonctions d’Evidian Enterprise SSO
Evidian Enterprise SSO permet de déployer très simplement et de façon sécurisée un
SSO prêt à l’emploi. Ce SSO s’applique à vos applications sans les modifier, qu’elles
soient Web ou non Web, qu’elles résident sur des serveurs Windows, Citrix
MetaFrame, Unix, Linux ou des mainframes.
Pour gérer les utilisateurs, Evidian Enterprise SSO utilise directement sur les
informations contenues dans l’annuaire LDAP de l’hôpital (Figure ci-dessous). Il n’y a
aucun import, ni aucune redéfinition des identités.
SAP R/3
Mainframe
Administration basée
sur l’organisation
Evidian
Enterprise SSO
Fenêtre
de login
WebSphere
SSO vers les
applications
Web et
client/serveur
Administration
centralisée
Auto-administration
par l’utilisateur
Poste Windows
Console d’administration
ou terminal léger
Citrix, NFuse, Windows
Terminal Services
Principales fonctions d’Evidian Enterprise SSO
16
Connexions aux applications via Enterprise SSO
Les utilisateurs accèdent simplement à leurs applications grâce à Enterprise SSO.
Installé sur le PC, un module de SSO permet à l'utilisateur d‘enregistrer ses mots de
passe, de déclarer une application personnelle, d'utiliser de manière transparente son
identifiant et son mot de passe pour accéder à une application métier ou d’autoriser
l’accès sous son nom à un remplaçant temporaire.
Il peut aussi changer automatiquement les mots de passe des applications.
SAP
3
Récupération des identifiants et
mots de passe dans l'annuaire en
fonction des demandes
Mainframe
2
Récupération
informations
de SSO
1
Evidian
Enterprise SSO
WebSphere
Login
Windows
4
Poste client
Windows
ou terminaux légers
Citrix, NFuse, WTSE
SSO vers Web et
client/serveur
5
Changement automatique
des mots de passe
Evidian Enterprise SSO : connexion aux applications
17
Contrôler l’authentification des utilisateurs
Evidian Enterprise SSO renforce l’authentification sur le poste de travail. Il gère le
dialogue avec la carte pour vérifier le code PIN fourni par l’utilisateur. Il gère aussi
toutes les demandes de ré-authentification émises par la mise en veille ou par toute
application.
Sur détection du retrait de la carte, le poste de travail est mis en veille.
Lorsqu’une carte est à nouveau insérée, Evidian Enterprise SSO gère la réauthentification via le code PIN puis, en fonction de l’identité de l’utilisateur, redonne
accès au poste de travail ou déclenche un changement rapide d’utilisateur avec
préservation du contexte.
Gérer les accès en fonction du poste de travail
Une console d’administration permet aux administrateurs de définir et d’appliquer la
politique de sécurité des accès aux applications.
Définition de rôles d’administration : vues d’administration dédiées, en fonction des
unités organisationnelles ou des groupes d’utilisateurs concernés.
Politique de SSO étendue : suspendre, modifier ou révoquer des comptes applicatifs.
Il est également possible de définir des politiques de mots de passe ainsi que de
créer, mettre à jour ou supprimer des mots de passe.
Politique de point d’accès : définir les PC utilisables pour accéder à des applications
données, des plages horaires etc.
Analyse d’audit : rapports sur l’activité des utilisateurs, l’utilisation des applications ou
des points d’accès.
18
Faciliter et sécuriser l'accès aux données vitales du patient
Evidian Enterprise SSO permet de déployer très simplement et de façon sécurisée un
SSO et un contrôle des accès au SIH pour les utilisateurs mobiles de l’hôpital.
 L'amélioration de l'efficacité des utilisateurs
Le personnel médical de l'hôpital accède de manière efficace aux informations qui
permettent de soigner les patients en toute sécurité.
 La réduction des coûts de votre help desk
Le help desk n'est plus surchargé par des demandes de mots de passe. Les coûts
de support sont réduits jusqu'à 30 %, assurant un retour sur investissement rapide.
 La sécurisation des accès aux applications
Quel que soit le poste de travail utilisé, l’accès aux données privées des patients
est protégé par un système centralisé. Les connexions des utilisateurs aux
applications sont historisées pour faire l’objet d’audits si nécessaire.
19
Pour plus d’informations sur Evidian Enterprise SSO, connectez-vous à
http://www.evidian.com/fr/contact.php?c=wpssosih
Email: [email protected]
© 2013 Evidian
Les informations contenues dans ce document reflètent l'opinion d'Evidian sur les questions abordées à la date
de publication. En raison de l'évolution constante des conditions de marché auxquelles Evidian doit s'adapter,
elles ne représentent cependant pas un engagement de la part d'Evidian qui ne peut garantir l'exactitude de ces
informations passé la date de publication.
Ce document est fourni à des fins d'information uniquement. EVIDIAN NE FAIT AUCUNE GARANTIE
IMPLICITE NI EXPLICITE DANS LE PRÉSENT DOCUMENT.
Les droits des propriétaires des marques cités dans cette publication sont reconnus.
livre
blanc

Authentification unique (SSO) et Système d`Information de l`Hôpital

Transcription

Documents pareils

Group 4 Securicor

MTN Côte d`Ivoire

EADS Astrium

Tableaux comparatif de solutions logiciels pour M2L

L`îlot Oudeville - Société Lorraine d`Habitat

Professionnels de Santé

1 – Single Sign-On SSO - GCS e

Camp de Volleyball de Pâques

Itinéraire et correspondances Ligne M1

Mémo Radiologie 2016