Lois, réglementations et SSO Sécurisé

Lois, réglementations et SSO Sécurisé Un livre blanc de Bull Evidian LSF, SOX, Basel II, HIPAA, CFR 21 Part 11 et SSO Sécurisé. Sommaire Les lois, réglementations et Système d Information Les exigences relatives à la sécurisation des accès au S.I. Le SSO Sécurisé, un outil central pour l application des lois et réglementations

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.

Table des matières Les lois, réglementations et Système d Information... 4 Une loi répond à des exigences impérieuses...4 Loi sur la Sécurité Financière (LSF)... 4 Sarbanes-Oxley (SOX)... 5 Bâle II et l optimisation des risques opérationnels... 5 HIPAA et la protection des données de la vie privée des patients... 5 21 CFR Part 11 et la protection de la vie des patients.. 6 Les exigences relatives à la sécurisation des accès au S.I.... 7 L exigence sur la définition d une politique de sécurité...7 L exigence sur la mise en œuvre de cette politique pour la gestion des droits...8 L exigence sur la mise en œuvre de cette politique pour les accès...9 Les particularités...11 Loi sur la Sécurité Financière (LSF)... 11 Sarbanes-Oxley (SOX)... 11 Nouvel Accord de Bâle (Bâle II)... 12 HIPAA... 12 21 CFR Part 11... 13 Le SSO Sécurisé, un outil central pour l application des lois et réglementations... 14 SSO Versus SSO Sécurisé...14 Le SSO Sécurisé permet d appliquer la politique de sécurité...15 Une console unique... 15 L application de la politique de sécurité sur le poste de travail... 15 L adoption par les utilisateurs... 16 Le SSO Sécurisé vous permet de répondre aux exigences liées aux lois et réglementations... 18 39 F2 18LT Rev00 3

Les lois, réglementations et Système d Information Le système d information des entreprises devient l objet de plus en plus fréquent de lois et réglementations. Au-delà des simples normes et standards de type ISO qui ont jalonné le développement des nouvelles architectures, le législateur s est intéressé à la relation entre l utilisation de l informatique par les organisations et son impact sur les processus opérationnels. Les lois et réglementations assurant la protection des données privées des clients et prospects ont eu le plus large écho ces dernières années. Le développement de la messagerie et l application des méthodes de Marketing Direct ont relancé le débat à tous les niveaux. Cependant, il existe de nombreux autres cas de lois définies par le législateur s appliquant au système d information. Une loi répond à des exigences impérieuses Le législateur, lorsqu il doit définir, amender ou voter une loi s appliquant au Système d Information, se trouve confronté à de nombreux défis. Le Système d Information : Se situe au cœur des processus métiers des entreprises. Suit des cycles technologiques extrêmement rapides. Conquiert continuellement de nouveaux espaces. Légiférer dans ce domaine est donc risqué, soit parce que les lois pourraient freiner le développement des entreprises, soit parce que les lois pourraient, tout simplement, ne pas être applicables. C est pourquoi le législateur ne légifère que lorsqu apparaissent des exigences fortes pour la protection des biens et des personnes. Loi sur la Sécurité Financière (LSF) La LSF a été votée par le parlement français en août 2003 pour répondre aux préoccupations des actionnaires suite à des affaires touchant de grandes entreprises. Cette loi vise à améliorer la qualité de l'information fournie aux actionnaires et au public, renforcer la responsabilité des dirigeants dans l'élaboration des rapports d'activités, ainsi qu'à augmenter la fiabilité de ces rapports. Pour cela, les dirigeants des Sociétés Anonymes doivent rendre compte des procédures de contrôle interne dans le rapport annuel. De même, les commissaires aux comptes doivent auditer les procédures de contrôle interne "relatives à l'élaboration et au traitement de l'information comptable et financière" et inclure leurs conclusions dans le rapport d'activité. La fiabilité du processus de consolidation des données comptables et financières est au cœur de ces nouvelles dispositions. 39 F2 18LT Rev00 4

Sarbanes-Oxley (SOX) SOX est un autre exemple de législation relative au traitement des données comptables et financières. L objectif de la section 404 de cette loi est de renforcer les procédures de contrôle interne concernant le reporting financier. Le crash de la bulle Internet et d autres scandales financiers ont eu de lourdes répercussions sur le capital que s étaient constitué de nombreux petits épargnants pour leur retraite. Ces derniers ont parfois vu fondre en quelques jours les économies de toute une vie. C est pour empêcher que de tels scandales se renouvellent et pour rétablir la confiance dans les marchés que les lois de type SOX ont été promulguées. Pour une première comparaison entre SOX et LSF, vous pouvez vous connecter à http://www.senat.fr/rap/r03-431/r03-43148.html Bâle II et l optimisation des risques opérationnels La course aux parts de marché peut conduire une banque à adopter une stratégie de prises de risque importantes. Le problème survient lorsque cette stratégie s appuie non pas sur les fonds propres de la banque mais engage aussi les fonds déposés par ses clients. L encadrement de cette prise de risque ainsi que le partage et l application de règles communes permettent aujourd hui de réduire ces risques. Le nouvel accord de Bâle (Bâle II) vise donc à faire évaluer de manière méthodique les fonds propres d une banque, en prenant notamment en compte les risques opérationnels qu elle encourt. Le système d information est considéré maintenant comme l une des sources potentielles de risque opérationnel. La sécurisation des accès aux données permet de maîtriser et réduire ces risques et par là même d améliorer le positionnement concurrentiel de l institution financière. HIPAA et la protection des données de la vie privée des patients La loi HIPAA (Health Insurance Portability and Accountability Act of 1996) concerne plus précisément la protection des données de santé des patients américains. Les systèmes d information de santé au sein des établissements médicaux, mais aussi au sein des organismes de sécurité sociale, ont permis de centraliser les informations médicales des patients dans des systèmes accessibles par les réseaux. La mise en place et le maintien opérationnel des mécanismes de protection du secret médical est l une des contraintes fortes de tout système d information du domaine de la santé. 39 F2 18LT Rev00 5

21 CFR Part 11 et la protection de la vie des patients L automatisation et l informatisation des processus de gestion des cycles de vie des médicaments ont conduit dans le passé au lancement non contrôlé de médicaments. Ces médicaments, qui n avaient pas suivi le cycle complet de validation, ont été proposés à des patients. Les conséquences ont été si lourdes que les médicaments ont été immédiatement retirés du marché. Lors du cycle de vie d un médicament, les industries pharmaceutiques sont donc tenues à un processus contraignant de remise de documents à la Food and Drugs Administration (FDA), et à des procédures de stockage de ces mêmes documents. Ces procédures ayant été conçues à l origine pour des documents matériels (papier notamment), la section 21 CFR Part 11 précise selon quelles règles ces documents peuvent être remis et stockés sous forme électronique. La fiabilisation de l aspect informatique des processus de mise sur le marché des médicaments est maintenant encadrée par un ensemble de lois et réglementations. 39 F2 18LT Rev00 6

Les exigences relatives à la sécurisation des accès au S.I. Pour l accès au Système d Information, ces lois et réglementations s intéressent de manière générale à la sécurisation et à la fiabilisation des accès aux applications et aux données. Les exigences suivent en général une structure similaire même si elles sont exprimées de manières différentes. Définition d une politique de sécurité Application et suivi de la politique de gestion des droits des utilisateurs Application et suivi de la politique d authentification et de contrôle des accès L exigence sur la définition d une politique de sécurité L une des premières exigences concerne la définition d une politique de sécurité. Celle-ci peut porter par exemple sur : les classifications des données, applications et processus métiers en fonction de leur importance dans l organisation les profils métiers de l entreprise auxquels sont associés des droits d accès et des privilèges les procédures d affectation des profils et privilèges les politiques d authentification des utilisateurs et notamment les mécanismes d authentification dite forte Cette politique de sécurité se définit et se met en place avec le concours des directions opérationnelles. 39 F2 18LT Rev00 7

L exigence sur la mise en œuvre de cette politique pour la gestion des droits La mise en œuvre des exigences pour la gestion des droits d accès se décline selon 3 dimensions. Processus de gestion des droits Archivage des droits Historisation des opérations La mise en place des processus de validation L affectation de droits et privilèges à un utilisateur dépend de son rôle et de sa position au sein de l organisation. Est-il un employé ou un sous-traitant? Quelle est sa position hiérarchique? Quel est son métier? Les réponses à ces questions (et à d autres) permettent de définir la liste des applications auxquelles il a le droit d accéder ainsi que les privilèges associés. Les réponses à ces questions doivent être fournies par les différentes directions telles que la Direction des Ressources Humaines, les directions opérationnelles ou encore les responsables du partenariat. En général, la déclaration des nouveaux utilisateurs ou leur changement d affectation est un processus qui se déroule tant bien que mal ; les gens sont présents pour exprimer leurs besoins en autorisation d accès. Par contre le processus de désincription lors du départ de l utilisateur est un processus beaucoup moins bien maîtrisé. Cette procédure est la plus porteuse de risque car elle concerne la suppression des droits des personnes qui quittent l organisation. L historisation des opérations de gestion des droits Comme pour tout processus critique, les opérations de gestion des droits d accès des utilisateurs doivent être historisées. Cette historisation permet de diagnostiquer les raisons qui ont pu conduire à une mauvaise affectation d un droit à un utilisateur : non application de la politique de sécurité par le processus, non application du processus ou encore erreur au niveau de la politique de sécurité. Cette historisation permet de fiabiliser et d optimiser le processus de gestion des droits. Elle facilite également les audits. 39 F2 18LT Rev00 8

L archivage des droits Une autre dimension concerne l archivage des droits d accès effectifs. Cet archivage doit fournir les éléments qui permettront, en cas de détection d incident dans le futur, d analyser les droits des différents utilisateurs pour, par exemple, savoir qui avait la possibilité de faire telle ou telle opération. L exigence sur la mise en œuvre de cette politique pour les accès Une fois la politique de sécurité définie et les droits d accès aux utilisateurs validés, il faut appliquer ces décisions sur le Système d Information. A quelles applications avez-vous le droit d accéder? Qu avez vous fait? Qui êtes vous? Le contrôle des accès aux applications Le contrôle des accès aux applications peut se faire à 3 niveaux : Par les applications elles-mêmes qui utilisent leur répertoire interne de contrôle des accès ou des mécanismes avancés de type SAML 1. Par un module sur le poste de travail qui, après avoir vérifié l identité de l utilisateur, contrôle ses droits et gère l accès aux applications autorisées. En environnement Web, par une passerelle de sécurité centralisée ou par des agents positionnés auprès des applications elles-mêmes. Historisation des accès aux applications Chaque système de contrôle des accès doit pouvoir historiser les accès des utilisateurs afin, en cas d incident, de faciliter l analyse, le diagnostic et la mise en œuvre de mesures de correction. 1 SAML est une norme pour la propagation de l identité et des privilèges des utilisateurs jusqu aux applications. Cette norme s applique principalement dans les environnements Java, J2EE et les Architectures Orientées Services. 39 F2 18LT Rev00 9

Parmi tous ces systèmes, le module sur le PC permet de générer un fichier unique d historisation quelle que soit l application cible, Web ou non Web. L authentification de l utilisateur L authentification de l utilisateur est bien entendu un autre domaine clef. Cette authentification peut se produire à différents moments : Authentification initiale lorsque l utilisateur lance son PC et qu il fournit pour la première fois son identifiant et son mot de passe. On parle alors d authentification, d identifiant et de mot de passe primaires. Re-authentification primaire, lorsque l utilisateur doit à nouveau fournir son identifiant et son mot de passe pour prouver son identité comme par exemple après l activation d un écran de veille. Authentification auprès des applications lorsque qu un utilisateur fournit son identifiant et son mot de passe pour se connecter à une application. On parle d authentification, d identifiant et de mot de passe secondaires. La politique de sécurité peut exiger de renforcer l authentification de l utilisateur. Ce renforcement peut s appliquer à l authentification primaire ou aux authentifications secondaires. Différentes méthodes de renforcement des authentifications sont alors disponibles comme par exemple : une politique de changement de mots de passe contraignante, la crypto-carte, le mot de passe OTP ou encore l identification biométrique. Appliquer de manière classique une méthode d authentification forte à un ensemble d applications peut s avérer très coûteux voir même impossible. En effet, dans ce cas, il faut modifier le code interne de chaque application afin de l adapter à la méthode 2 utilisée. Le module sur le PC permet de traiter toutes ces dimensions (authentification primaire et secondaire, authentification renforcée, historisation) de manière simple et efficace. Historisation des authentifications L historisation des différents évènements d authentification contribue aussi à l analyse et à l amélioration des processus contrôlant l accès aux applications. 2 Les méthodes d authentification forte utilisent en général des protocoles de communication sécurisée afin de pouvoir s assurer de l identité d une personne. Ainsi, par exemple, les crypto-cartes (ou smartcard) s appuient sur les protocoles PKCS de la famille «PKI» pour mettre à disposition des applications les éléments permettant de vérifier l identité de l utilisateur. 39 F2 18LT Rev00 10

Les particularités Chaque loi et réglementation décline à sa manière les exigences précédemment décrites, en insistant soit sur les moyens soit sur les résultats ou encore en définissant un domaine de couverture particulier. Loi sur la Sécurité Financière (LSF) Suite aux obligations de la LSF, le Président du Conseil d'administration ou du Conseil de Surveillance doit émettre un rapport sur les "procédures de contrôle interne mises en place par la société", joint au rapport d'activité. Même si la LSF n'impose pas de cadre méthodologique spécifique ni même de définition précise du contrôle interne, une majorité des très grandes entreprises françaises se réfère à l'approche du COSO 3 américain concernant le contrôle interne. D'autres définitions, moins détaillées, ont été émises par le MEDEF et l'afep. Les procédures de contrôle interne touchant à l'attribution des droits d'accès sont donc directement concernées par la LSF. Une défaillance significative du contrôle interne pouvant influer sur les résultats financiers doit être communiquée aux actionnaires. Parmi les conséquences possibles d'une telle défaillance, l'accès non autorisé à des processus informatiques critiques et la modification d'informations comptables informatisées sont particulièrement sensibles. Une solution d'attribution des droits d'accès et de surveillance de ces accès permet, d'une part de définir des procédures claires et partagées, d'autre part d'en permettre l'audit par les commissaires aux comptes. Sarbanes-Oxley (SOX) SOX s intéresse principalement aux processus de reporting comptable dans l entreprise. La fiabilisation de ces processus passe naturellement par une fiabilisation des processus liés à la gestion des identités et des accès : définition d une politique de sécurité, mise en place et historisation des processus de gestion des droits et d accès aux applications ou encore analyse, diagnostic et correction suite à la détection d incidents. SOX focalise les exigences sur la fiabilisation des processus de reporting comptable. La section 404 de SOX ne décrit aucune exigence particulière sur le Système d Information mais les autorités boursières font référence à des «frameworks 4» du marché comme COBIT ou ITIL. 3 «Committee of sponsoring organizations of the Treadway Commission», organisme privé indépendant créé en 1985 auprès d'une commission nationale de l'information financière, elle-même issue du secteur privé et présidée par M. James Treadway 4 Framework : ensemble de recommandations et spécifications ayant trait à la mise en place et la gestion d un Système d Information. 39 F2 18LT Rev00 11

Pour en savoir plus sur SOX et la gestion des identités et des accès, vous pouvez télécharger le livre blanc : http://www.evidian.com/p/am.php?d=wpsox&c=overview Nouvel Accord de Bâle (Bâle II) Bâle II s intéresse à la maîtrise des risques dans les institutions financières : risque sur les marchés, sur les clients, internes, Parmi ces risques se trouvent les risques opérationnels liés aux accès aux données : erreurs humaines ou malversations. La dimension informatique n est pas particulièrement au cœur des exigences de l accord. Cependant la mise en place des différents processus de gestion des identités et des accès, leur historisation à des fins d analyse et l alimentation de la base de suivi des risques avec des indicateurs pertinents permettent d améliorer le positionnement concurrentiel de la banque. Bâle II focalise les exigences sur la connaissance du niveau du risque et donc sur la maîtrise effective des processus de la gestion des identités et des accès. L historisation des données à des fins de suivi et de diagnostic est l un des points clefs de Bâle II. La commission bancaire française a émis un questionnaire permettant d évaluer la position d un organisme financier par rapport aux critères de Bâle II. Voici quelques extraits : (45) Votre dispositif de contrôle des systèmes d'information s'assure-t-il de la maintenance d accès sécurisés aux actifs et aux données ainsi que des procédures permettant leurs sauvegardes? (31) Votre établissement dispose-t-il d'une base de données historique recensant les pertes et incidents? (38) Ce reporting comporte-t-il des indicateurs d'alerte qui mettraient en évidence toute augmentation du risque ou toute possibilité de pertes futures? Pour plus d information sur Bâle II et la gestion des identités et des accès, vous pouvez télécharger le livre blanc : http://www.evidian.com/p/am.php?d=oprisk&c=wpoverview HIPAA HIPAA cible la protection des données informatisées du patient U.S. au sein de toutes les organisations qui peuvent à un moment ou à une autre les traiter : hôpital, laboratoire, caisse de sécurité sociale, mutuelle HIPAA, de manière classique, exige la mise en place d une politique de sécurité et des processus associés. 39 F2 18LT Rev00 12

HIPAA exige par exemple Une analyse régulière des historisations des évènements, accès, audit ou rapport d incident (45 CFR Paragraph164.308.a.1.ii.D). La mise en place de procédures pour supprimer tous les droits d accès d un employé qui quitte l organisation (45 CFR Paragraph164.308.a.3.ii.B). L utilisation d outils pour la gestion de mots de passe de manière sécurisée (45 CFR 164.308.a.5.ii.D). Pour plus d information sur HIPAA et la gestion des identités et des accès, vous pouvez télécharger le livre blanc : http://www.evidian.com/p/am.php?d=hipaa&c=wpoverview 21 CFR Part 11 21 CFR Part 11 a pour objectif la fiabilisation des processus de validation des médicaments en ce qui concerne les documents électroniques. Au-delà de la mise en œuvre des processus associés à une politique de sécurité, 21 CFR Part 11 définit des exigences particulières sur l authentification. Notamment l obligation lors de l accès à des ressources critiques d une ré-authentification afin de s assurer de l identité de l utilisateur. Ainsi, pour la partie de signature électronique, CFR 21 Part 11 Chapitre 11.200 précise les points suivants pour les signatures non biométriques : 11.200.a.1 11.200.a.1.i 11.200.a.1.ii 11.200.a.2 11.200.a.3 Une signature doit mettre en œuvre au moins deux éléments d identification tels qu un identifiant et un mot de passe. Lorsqu une personne effectue une série d authentifications durant une session continue pour accéder à des systèmes protégés, la première authentification doit utiliser tout les éléments d authentification ; les authentifications suivantes doivent être mises en œuvre avec au moins un élément connu seulement de la personne. Lorsqu une personne effectue une série d authentification durant plusieurs sessions différentes, chaque authentification devra mettre en œuvre la totalité des éléments d authentification Une signature ne doit être connue et utilisée que par son possesseur. Une signature électronique doit être administrée de manière à s assurer que sa divulgation ou son utilisation par un tiers autre que le propriétaire demande la collaboration d au moins 2 personnes. 39 F2 18LT Rev00 13

Le SSO Sécurisé, un outil central pour l application des lois et réglementations SSO Versus SSO Sécurisé Il y a deux grands principes de SSO. 1. Le SSO dit de synchronisation 5 qui recopie dans chaque système et application cible le même identifiant et mot de passe avec des mécanismes de réplication. Ce type de SSO simplifie la vie de l utilisateur et soulage l administration du help desk. Par contre, ce n est pas un SSO Sécurisé. En effet, il introduit une faille de sécurité car l'identifiant et le mot de passe décryptés sur un système faiblement protégé pourront être utilisés pour accéder à toutes les applications même les plus critiques. En raccourci, on peut dire que le SSO synchronisé augmente la productivité de vos utilisateurs et de vos hackers. 2. L'autre grand principe de SSO revient à différencier l'identité et le mot de passe, dits primaires, utilisés pour l'authentification initiale de l'utilisateur, de l'identité et du mot de passe, dits secondaires, qu'il utilise pour se connecter à une application. C est le SSO Sécurisé. Seul le primaire est nécessairement connu de l'utilisateur ; pour renforcer la sécurité, il peut être remplacé par une cryptocarte 6 ou un système à base de mot de passe OTP 7. Les identifiants et mots de passe secondaires peuvent être cachés aux utilisateurs. Cette différenciation entre identification primaire et secondaire permet de définir une politique de sécurité pour l'authentification et d en faire bénéficier toutes les applications quelle que soit leur spécificité. C'est pourquoi ce système de SSO est en général appelé «SSO Sécurisé 8». 5 Le SSO de synchronisation peut se trouver sous différentes dénominations comme le CSO (Common Single Sign-On) ou encore SSO de réplication. 6 Cryptocarte : carte à puce qui contient un certificat X.509 utilisé notamment pour l'authentification. 7 OTP : One-Time-Password, mot de passe à utilisation unique dont la période de validité est réduite à un temps très court. 8 En anglais "Secure SSO". 39 F2 18LT Rev00 14

Le SSO Sécurisé permet d appliquer la politique de sécurité Une console unique La console de gestion du SSO Sécurisé permet de définir à partir d un point unique les droits d accès aux applications. Afin de réduire au maximum les charges d administration supplémentaire induite, cette console doit s appuyer sur les définitions et organisations déjà définies dans les annuaires existants. La mise en place d un SSO Sécurisé oblige l organisation à mettre en place un processus qui aboutit à un point central de gestion des droits des utilisateurs au sein du SSO Sécurisé. Où l on définit qui peut accéder à quoi et quand Ce processus permet de définir de manière maîtrisée «qui a le droit d accéder à quoi» : quel utilisateur a le droit d accéder à quelle application. Où l on peut auditer les opérations de gestion des droits Ces opérations peuvent être historisées. Il devient alors possible d analyser après coup le processus qui a conduit un administrateur à fournir à un utilisateur, à une date, donnée les droits d accéder à telle application. L application de la politique de sécurité sur le poste de travail Cependant le point le plus important du SSO Sécurisé concerne la maîtrise et la fiabilisation des processus d authentification primaire et secondaire. Une politique de mots de passe forts Le SSO Sécurisé utilise l identification primaire pour authentifier l utilisateur. Il peut gérer ensuite de manière transparente pour l utilisateur les connexions aux applications en utilisant les identifiants et mots de passe secondaires. Les connexions aux applications cibles deviennent un processus purement informatique sans intervention manuelle de l utilisateur. Il suffit alors de mettre en place une politique de mots de passe forts uniquement pour l authentification primaire. Une ré-authentification pour les accès aux applications sensibles Le SSO Sécurisé doit aussi pouvoir appliquer différentes politiques d authentification en fonction des applications cibles. Ainsi, comme par exemple dans 21 CFR Part 11, le lancement d une application critique peut nécessiter de ré-authentifier l utilisateur. Dans ce cas, le SSO Sécurisé redemande l identifiant et le mot de passe primaire de l utilisateur. 39 F2 18LT Rev00 15

Une délégation des accès contrôlée et auditée L un des risques les plus importants relatifs à l utilisation des identifiants et des mots de passe est le prêt d un identifiant et d un mot de passe. En effet, à l occasion d une absence prolongée ou pour déléguer une tâche, un utilisateur peut être amené à dévoiler à un collègue ou à un collaborateur un identifiant et un mot de passe. Cette entorse aux procédures de sécurité les plus élémentaires est difficile à combattre car elle permet bien souvent d assurer une continuité des opérations de manière simple et efficace. Un SSO Sécurisé, sous contrôle de la politique de sécurité de l entreprise, doit permettre à un utilisateur de déléguer à un autre utilisateur l utilisation de son accès. Le SSO Sécurisé permet de gérer cette délégation : en la restreignant à une liste d applications autorisées en auditant les accès effectués sous délégation en cachant à l utilisateur délégué les identifiants et mots de passe primaires et secondaires de l utilisateur absent. Ce mécanisme permet de fournir simplement aux équipes opérationnelles les moyens d assurer la continuité des opérations même en cas d absence d un membre de l équipe. L application des règles de «qui peut accéder à quoi et quand» Le contrôle par l administrateur du SSO de l identifiant et du mot de passe secondaires des applications critiques lui permet de définir et d appliquer les règles d accès. Ainsi en cas de nécessité, il suffit de supprimer les droits d un utilisateur dans le système de SSO Sécurisé pour qu il ne puisse plus se connecter à ses applications critiques, même si ses comptes sont encore actifs. L adoption par les utilisateurs Le SSO Sécurisé simplifie aussi la vie des utilisateurs. Un seul mot de passe (y compris pour ses applications personnelles) Le SSO soulage l utilisateur de la gestion de l ensemble de ses mots de passe. En effet, face à une politique contraignante pour les mots de passe, l utilisateur met en général en place des stratégies de contournement qui sont autant de nouvelles brèches de sécurité et qui vont à l encontre des objectifs initiaux. Ainsi, il n est pas rare de voir la liste des mots de passe inscrits sur un cahier ou dans un calepin électronique (PDA) personnel. «Trop de mots de passe tuent les mots de passe». Une politique de mot de passe forte renforce encore cette problématique. 39 F2 18LT Rev00 16

Une solution de SSO Sécurisé permet de faciliter l adoption par les utilisateurs de la politique d authentification forte exigée par les différentes réglementations. Un ROI rapide pour financer le projet Sans solution de SSO, jusqu à 30% des requêtes du help-desk concernent des pertes de mots de passe. Cette charge de travail suit un pic particulièrement important juste après les congés. La mise en place d une solution de SSO Sécurisé permet de réduire cette charge de travail à quasiment zéro. Les économies ainsi réalisées sur l activité du help-desk participent au financement du projet de SSO. Utilisation dynamique du poste de travail La mise en place d un SSO a une conséquence inattendue sur la manière dont l utilisateur gère les applications sur son poste de travail. Libéré de l obligation d avoir à s authentifier à chaque lancement d application, l utilisateur peut prendre l habitude de fermer ses applications immédiatement après utilisation et de les ouvrir lorsqu il en a besoin. Cette utilisation dynamique permet de libérer les ressources nécessaires au fonctionnement du PC et donc d améliorer globalement la satisfaction et l efficacité des utilisateurs. 39 F2 18LT Rev00 17

Le SSO Sécurisé vous permet de répondre aux exigences liées aux lois et réglementations Les lois et réglementations couvrent en général un sous-ensemble du Système d Information : les applications de reporting comptable pour SOX, les systèmes métiers pour Bâle 2, HIPAA ou encore 21 CFR part 11. Un SSO Sécurisé et administré permet de se focaliser sur ces sous-ensembles pour en fiabiliser les processus d authentification et de contrôle des accès. Il permet aussi d y positionner un point de contrôle obligé pour les processus de gestion des droits. Un SSO Sécurisé permet donc à une organisation de répondre aux exigences concernant les identités et les accès : L authentification : L authentification forte initiale puis l accès sécurisé en fonction de la criticité des applications cibles. La gestion des droits : La déclaration des droits d accès des utilisateurs dans un annuaire. Cet annuaire peut aussi être utilisé comme source unique pour l archivage périodique des droits aux applications sensibles. La mise en œuvre : l adoption par les utilisateurs de la nouvelle politique de sécurité ainsi que le financement du projet par les économies réalisées sur le Help-Desk. Le SSO Sécurisé est en outre une première étape simple et efficace vers un projet global de gestion des identités et des accès. Ce projet permettra par la suite de fiabiliser et surtout d optimiser les opérations de gestion des utilisateurs et de leurs droits pour tout le système d information. 39 F2 18LT Rev00 18

Pour plus d'informations, consultez le site www.evidian.com/ Email: info@evidian.com