Rapport. Modèle d'architecture Stabi3eGov B2.06 IAM. ech Groupe spécialisé IAM Projet E-Government B Avril 2011, projet no

Dimension: px
Commencer à balayer dès la page:

Download "Rapport. Modèle d'architecture Stabi3eGov B2.06 IAM. ech Groupe spécialisé IAM Projet E-Government B2.06. 8. Avril 2011, projet no 12.564.00."

Transcription

1 Rapport Modèle d'architecture Stabi3eGov B2.06 IAM ech Groupe spécialisé IAM Projet E-Government B Avril 2011, projet no

2 Informations sur le document Titre: Numéro de projet: Date: 8. Avril 2011 Fichier: Nombre de pages: Contrôlé par le cointervenant et respectivement le chef de projet: Modèle d architecture Stabi3eGov B2.06 IAM U:\12564_eCH\00_IAM_eGovernment\01_eCH_IAM_Modellarchitektur\Berichte\Ber_ _Stabi3eGov B2 06 IAM Lösungsarchitektur-120_FR.doc 104, annexes non comprises Version Date Modifications majeures Responsable V Première ébauche jusqu à et y compris l architecture de gestion Mem V Ajustements dans le métadomaine Mem V Mise à jour et élaboration du feedback Mart, Häni Mem V Mise à jour selon WS Communes Mem V Mise à jour selon Spec. Camp 2 Mem V Mise à jour de l architecture de l information et de l application Mem V Elaboration du feedback du groupe de travail Mem V Complément au services issus des processus Mem V Mise à jour des processus et élaboration du feedback des membres du projet V Consolidation des concepts et des définitions avec ech-0107 et remaniement des services V Corrections et remaniement selon feedback Wag V Mise à jour / review Mem V Version 1.0 en tant que base de discussion de Spec. Camp. III Mem V Feedback avant Spec. Camp III compris Mem V Remaniement selon feedback Spec.Camp III Mem V Elaboration feedback / assurance de qualité Mem/Wag V Elaboration de davantage de feedback Mem V Mise à jour après consultation avec Hans Häni: extension de l architecture de l information, des structures interdomaines ainsi que de l architecture technique du chapitre en référence aux PoCs tels que définis actuellement V Tournée de feedback AWK Mem/Wag V Intégration des derniers feedbacks du groupe de travail Mem V1.20f Traduction en français Wir Wag Wag Mem E-Government ffo B2.06 Le présent rapport est du domaine public. Les résultats des travaux qui y sont publiés peuvent sans autres être utilisés sous réserve de mention du titre et de l auteur du document. AWK Group AG Leutschenbachstrasse 45 CH-8050 Zürich Tél Fax /104

3 Références Titre Auteur / éditeur Date Lien / fichier [1] ech Modèle de référence IAM Whitepaper no: IAM [2] ech-0107 IAM Principes opérationnels formels [3] SuisseID Spécification 1.3 (anglais) [4] egov: Vision infrastructure IAM [5] National Strategy for Trusted Identities in Cyberspace [6] The National Strategy for Trusted Identities in Cyberspace: Cyperspace Policy Review Assuring a Trusted and Resilient Information and Communications Infrastructure [7] Cross Domain community Roadmap, V1.0 N. Haenni, M. Itin, V. Kulhavy, H. Rüger, C. Winteregg SEAC: W. Müller, H. Häni SECO E-Government (Hans Häni), AWK (Markus A. Meier) 23 avril 2007 Ebauche 10 juin unternehmen/technik/index.html?lang=de U.S. Department of Homeland Security ale.com/ The White House gov/blog/2010/06/25/na tional-strategy-trustedidentities-cyberspace Unified Cross Domain Management Office (UCDMO) CD%20Community%20 Roadmap%20Exec%20Over view%20v7.pdf [8] STORK: D4.2 Final report on eid process flows STORK-eID Consortium [9] Liberty Alliance Project Liberty Alliance [10] Identity Management The Open Group March > IdM Whitepaper [11] NSTAC Report to the President on Identity Management Strategy NSTAC May 21, c/reports/2009/nstac %20IDTF%20Report.pd f [12] Federal Identity, Credential, and Access Management (FICAM) Roadmap and Implementation Guidance ICAM November 10, s_events/privilegemanagementworkshop/presentations /Judy_Paul%20.pdf 3/104

4 Sommaire 1. Résumé Introduction Situation initiale Objectifs de l architecture de la solution E-Government IAM Motivation Procédure Concepts Sujet Ressource Identité numérique Identifiant Certificat numérique Domaine Espace de noms Attributs Claim, Claimset Function, rôle Autorisation Credential Claim Assertion Service, Claim Assertion Infrastructure, Identity Provider, Service Provider dans le contexte SuisseID Terminologie OASIS: Security Token Service STS, Relying Party RP IAM - Identity and Access Management Registre Trust (relation de confiance) Identification, authentification Autorisation (administration, durée) Access Control Règles d accès Exigences Architecture de gestion /104

5 6.1. Parties impliquées/rôles Processus au niveau législatif L1: Governance L2: Gestion du risque L3: Conformité (Compliance) Processus de gestion au niveau exécutif M1: identités numériques M2: règles d accès M3: Claims M4: Credentials Processus Runtime au niveau exécutif R1: Access Control Architecture de l information Métamodèle IAM Infrastructure IAM Répertoire IAM Le Service Provider IAM et ses services Administration IAM Domaines Codes et directives inhérents à un domaine Exigences relatives aux domaines fédérés Codes, standards et relations de confiance entre les domaines Mapping de l identité Identifiants Credentials Règles d accès Claims Modèles d Access Control Solutions possibles au niveau des structures interdomaines L IAM dans le cadre d un domaine L IAM dans le cadre d une fédération libre de domaines L IAM dans le cadre d un domaine Master L IAM avec métadomaine Les services du métadomaine Autres variantes possibles Assurance de la documentation et de la gestion de la documentation Single Sign-On fédéré /104

6 Pull / Push SSO Account Linking Where are you from (WAYF) Session Management, Logout, Cleanup Global Good-bye Account Delinking Architecture de la technologie Les standards technologiques importants dans le cadre de l Identity Management fédéré SSL/TLS SAML Security Assertion Markup Language Shibboleth Liberty Alliance Fédération Web Services Web Services-Trust Web Services Security L architecture en tant que support à la fédération dans l environnement IAM HTTP Point of Contact (Browser) SOAP/XML Point of Contact (WS Client) SSO Protocol Service Trust Services Key Services Identity Services Authorization Service Provisioning Service Management Service Audit Services A. Proof of Concept /104

7 1. Résumé Durant ces dernières années, l utilisation d Internet s est accrue de façon constante. Ainsi que le montre par exemple la toute dernière statistique de l OFS 1 à ce sujet, Internet est de plus en plus souvent utilisé non seulement en tant que source d informations mais également afin de réaliser des affaires. L architecture de la solution IAM a pour objectif de représenter clairement, à l aide de concepts standardisés et unifiés, les processus qui sont mis en œuvre dans le cadre d un E-Government et qui sont de ce fait d une importance capitale pour l IAM. Le thème de l identité numérique sera approfondi dans le cadre du chapitre Architecture du système d information au moyen du métamodèle ci-dessous: Sujet possède possède Ressource a Credential 0..n possède 1..n 1..n Identité numérique possède 0..n 0..n Claim utilise Règle d accès 0..n a un Identifiant 1 Domaine a confiance (Trust) 0..n Figure 1: métamodèle d information IAM pour une identité numérique Différentes approches de la façon d enregistrer et d administrer un identité numérique dans un environnement E-Government sont mentionnées. Une attention particulière est également portée à la fédération de domaines qui fait partie intégrante de la réalité quotidienne en Suisse. Certains aspects technologiques importants dans le domaine de la fédération d identités sont en outre approfondis au chapitre 9 (Architecture de la technologie). 1 Pour davantage de détails, voir: 7/104

8 Les approches de solutions évoquées sont présentées comme des modèles d utilisation qui sont actuellement vérifiés, au niveau technique, à l aide de divers Proof of Concept (PoC). Le résultat de ces PoCs doit sera documenté alors que les modèles de solutions de mise en œuvre technique figurent en annexe au présent document. 8/104

9 2. Introduction 2.1. Situation initiale La clé du succès de l utilisation des identités numériques repose sur une administration efficace et efficiente des sujets et des ressources (Identity Management) et de leurs Claims (Access Management). En mars 2004 déjà, «The Open Group» évoquait à ce propos, dans le document «Identity Management Report» (voir [10]) une série d arguments tels que, par exemple: «Enable a higher level of e-business by accelerating movement to a consistent set of identity management standards». Quant à l IAM, il est préconisé en tant que technologie clé permettant de réaliser des économies de coûts significatifs au niveau de l E-Government, recommandation qui se retrouve également et notamment dans le «NSTAC Report» adressé au président des Etats-Unis en mars 2009 (voir [11]). Nous savons tous que l utilisation d Internet est en augmentation constante ces dernières années, ainsi que l indique d ailleurs la statistique actuelle de l OFS 2. Dans cette statistique, on constate par ailleurs qu aujourd hui, environ 1/3 des utilisatrices et des utilisateurs d Internet développent également leurs affaires par l intermédiaire de ce média (voir Figure 2): Figure 2: statistique Internet 3 2 Pour davantage de détails, voir: 3 Source: Publicadata/IGEM: KommTech; 2009 OFS-BFS-UST / SUKO 9/104

10 On peut également constater que le «Homebanking» est employé par environ 40% des Suissesses et des Suisses et que l envoi et la réception de courriels arrive en tête du classement avec un taux d utilisation de 80%. Internet (le gouvernement US parle de Cyberspace [6]) est ainsi devenu la clé de voûte du développement de nombreuses affaires. Ainsi que nous pouvons le lire pratiquement tous les jours dans les médias, nous savons qu à ce niveau le développement extrêmement rapide du média Internet a engendré un retard au niveau de la sécurité et de la protection de la sphère privée. Nous fournissons parfois nos données sans exactement savoir dans quel but elles seront utilisées ou à qui elles seront retransmises. Internet ne représente ainsi donc pas seulement une opportunité mais constitue également l outil de base de nombreuses activités criminelles de tous genres qui dépassent parfois largement notre imagination. L expression «cyberguerre» n est donc pas uniquement un concept issu des films de science-fiction. C est en septembre 2009 déjà que le Parlement suisse a décidé de mettre en œuvre, par voie légale, un troisième train de mesures de stabilisation conjoncturelle (Stabi3eGov), dont une partie est destinée au développement de l E-Economy en Suisse. Les mesures TIC prévues dans ce contexte visent à favoriser le développement des transactions d affaires numériques, notamment en soutenant le développement et l introduction d un moyen d identification électronique sûr, qui a été introduit entretemps sous l appellation de SuisseID. Le communiqué de presse diffusé le 30 septembre 2010 par le DFE évalue les mesures décidées de la façon suivante 4 : Berne, La mise en œuvre du train de mesures, approuvé par le Conseil fédéral au titre de la troisième phase des mesures de stabilisation conjoncturelle, est en bonne voie. Les projets prioritaires soutenus se déroulent comme prévu et affichent de premiers résultats positifs. D'ici la fin de l'année, tous auront au moins achevé leur phase de conception. Le même communiqué officiel relève par ailleurs l importance accordée à l IAM: Parmi les priorités des projets de cyberadministration soutenus figure «Identity and Access Management (IAM)». IAM traite de la gestion des données des utilisateurs et des droits d'accès, opération importante notamment pour assurer la protection des données ainsi que pour rendre la cyberadministration plus conviviale. Les autorités pourront limiter l'accès aux données, par exemple lors d'une procédure d'autorisation de construire, au cercle des ayants droit. L IAM constitue un projet transversal typique, utile à de nombreuses prestations de cyberadministration, mais dont la réalisation efficace demande une solide coordination sur le plan national. Il existe par ailleurs un grand nombre d initiatives, prises également au niveau international, dont l objectif est de sécuriser l emploi d Internet pour ses utilisatrices et ses utilisateurs. L une de ces initiatives émane du gouvernement US et préconise, sur la base d une idée lancée sous l égide de Barack Obama, le développement d une «Strategy for Trusted Identities in Cyberspace» [5], stratégie placée sous la direction du «Department of Homeland Security». 4 Pour davantage de détails, voir: 10/104

11 Au niveau européen, le projet «STORK» (Secure Identity Across Borders Linked [8]) est destiné à mettre sur pied une plateforme permettant de sécuriser l utilisation de l identité numérique entre les différents Etats membres Objectifs de l architecture de la solution E-Government IAM L architecture de la solution E-Government IAM vise à atteindre les objectifs suivants: créer une unité conceptuelle (chapitre 4): l architecture de la solution E- Government IAM explique et définit les principaux concepts du domaine concerné. Les définitions s inspirent du document ech-0107 IAM Principes opérationnels formels [2]; démontrer les processus E-Government IAM (chapitre 6): l IAM est avant tout une exigence organisationnelle. L architecture de la solution visée doit représenter les processus métier pour l IAM. Les parties prenantes, les entités et leurs rôles/fonctions respectifs doivent être identifiés; démontrer l architecture du système d information (chapitre 7): il s agit ici d expliquer le métamodèle d information de l identité numérique ainsi que les exigences relatives à des identités numériques en interaction dans plusieurs environnements (domaines). Les divers modèles d utilisation possibles fournissent des approches de solutions; définir les mises en œuvre techniques possibles: l architecture de la solution E- Government est vérifiée à l aide de différents champs d application concrets (Proof of Concept). Les mises en œuvre techniques contrôlées au moyen de ces POCs induisent des modèles de mises en œuvre qui peuvent être extrapolés et documentés. Indication: les résultats techniques des mises en œuvre sont élaborés, durant la réalisation des POCs, sous forme de documents séparés qui pourront être insérés dans les annexes dans une phase ultérieure. Un autre objectif important de cette architecture de la solution est constitué par les discussions issues des approches présentées ici et par leur extension. Cet objectif pourra être atteint grâce à l ancrage d un vaste cercle de membres impliqués dans le groupe de travail: Nom Prénom Organisation Arnegger Armin Innosolv Baumgartner Martin VRSG Berger Adrian Ergon Dolf Christian Canton de Saint-Gall Dornbierer Christof AdNovum Eberhard René keyon AG Häni Hans AFI Canton de Thurgovie Hoffmann Enno Siemens Itin Markus Kitt ZH Kräuchi Martin BIT Kulhavy Vladimir Siemens Marti Adrian AWK Mayer Elias Abraxas Informatik AG 11/104

12 Access Control Meier Markus AWK Milde Oldrich GS EVD Müller Willy ISB Oexl Thomas indato GmbH Perroud Thierry BIT Petralia Andreas AdNovum Re Roberto Abraxas Informatik AG Reçi Mirushe E-Government Suisse, Programm Office Salzmann Andre Ruf Sameli Mischa Backslash Schnetzler Steff iweb Virtic Anton Clavid Wagner Rolf AWK Walser Konrad Haute école spécialisée bernoise Weber Simon Softec Zweiacker Marc Zweiacker IT Management Tableau 1: les membres du groupe de travail 2.3. Motivation De manière simplifiée, l environnement E-Government IAM doit permettre aux sujets (citoyens, organisations, entreprises, applications spécifiques) qui le souhaitent d exploiter les ressources de l E-Government (services communaux, cantonaux, fédéraux) ainsi que le montre la figure 3 ci-dessous: Domaine A Domaine B utilise Sujets Ressources Propriétés du sujet Règles d accès Qui est autorisé Quoi Figure 3: qui est autorisé à faire quoi? Les responsables des ressources définissent les critères (règles d accès) d utilisation des ressources (qui est autorisé à faire quoi). Les sujets qui souhaitent exploiter les ressources en question doivent être au bénéfice de certaines propriétés vérifiables permettant l accès à ces ressources. Pendant la durée d exécution, l Access Control compare les propriétés du sujet concerné avec les modalités prédéfinies autorisant l accès aux ressources et, en fonction du résultat de cette comparaison, autorise ou interdit l accès. 12/104

13 Interface L un des défis particulier lié au domaine de l E-Government ou de l E-Economy est que les ressources et les sujets peuvent se trouver dans des environnements totalement différents les uns des autres (domaine A et domaine B sur la figure 3). La facilité d accès au prestataire de services et la confiance réciproque qui doit s établir entre ce dernier et les sujets (utilisateurs) enregistrés de façon décentralisée, ainsi que le mapping des identités numériques lors de l accès aux services constituent autant d exigences auxquelles doit satisfaire l exploitation de services interdomaines. Cette représentation quelque peu abstraite est concrétisée ci-dessous par l illustration d un cas d utilisation réaliste (Figure 4). Hypothèses de départ: l habitant A est domicilié dans une commune (domaine B) et souhaite consulter les données du registre des habitants qui le concernent au moyen de son ordinateur portable; l environnement du citoyen A et de son ordinateur portable peut être considéré comme un petit domaine indépendant; selon la loi, chaque habitant d une commune a le droit de consulter les données du registre des habitants qui le concernent; l habitant A est en possession d une SuisseID; l habitant et sa SuisseID sont déjà connus (enregistrés) par la commune concernée (domaine B). Citoyen A Domaine A 2 1 SuisseID Internet 6 Portail communal Access Control Domaine B Commune 4 SuisseID Suisse CSP ID CA 3 Règles d accès (qui est autorisé à faire quoi?) 5 Registre des habitants Infrastructure CSP IdP CAS trust Figure 4: le citoyen exploite les services communaux 13/104

14 Voici chacune des étapes de l opération présentées de façon simplifiée: 1. l habitant utilise sa SuisseID sur son ordinateur portable (dans son domaine A); 2. il se connecte, via Internet, au portail de la commune; 3. la validité de son identité numérique (SuisseID) est contrôlée par l Identity Provider; 4. l Access Control vérifie si l identité numérique est enregistrée et définit, au moyen des règles d accès, les ressources auxquelles l habitant peut avoir accès, en l occurrence le registre des habitants et les données que celui-ci contient; 5. la fonction correspondante est alors activée; 6. le résultat de la requête est affiché sur l écran de l ordinateur de l habitant. Les questions suivantes se posent: comment peut-on détecter que l habitant A est effectivement domicilié dans la commune (domaine B)? comment un utilisateur authentifié qui est au bénéfice d une SuisseID et qui fait partie du domaine A peut-il être dirigé vers le sujet «Habitants de la commune» (domaine B) (mapping de l identité)? qui définit les règles d accès aux ressources «Registre des habitants»? comment peut-on s assurer, dans ce contexte, que l utilisation de la SuisseID est «fiable et digne de confiance»? 14/104

15 3. Procédure Le modèle d architecture du présent document a été développé selon la méthode d architecture ADM (Architecture Development Method) issue du TOGAF 5 (The Open Group Architecture Framework) prescrite par la Confédération. Prelim: Framework And Principles H Architecture Change Management A Architecture Vision B Business Architecture G Implementation Governance Requirements C Information System Arch. F Migration Planning E Opportunities and Solutions D Technology Arch. Figure 5: cycle TOGAF ADM Le document «e:gov: Vision infrastructure IAM» [4] couvre l ensemble de la phase de la vision d une architecture IAM possible. En fonction des objectifs définis, (voir 2.2), le présent document se concentre sur les phases B, C et D du TOGAF ADM. Dans l environnement IAM, l architecture de gestion (TOGAF ADM phase B) est documentée à l aide des processus qui sont représentés au moyen de la BPMN (Business Process Modeling Notation). 5 Pour davantage de détails, voir: 15/104

16 Au niveau de l architecture du système d information (TOGAF ADM phase C), l accent est avant tout porté sur les informations elles-mêmes, c est-à-dire sur l architecture de l information. Le métamodèle IAM est au cœur de ce processus. Les technologies clés de la mise en œuvre des identités fédérées sont, quant à elles, mentionnées dans l architecture de la technologie (TOGAF ADM phase D). L annexe A contient quelques variantes de mise en œuvre technologique qui ont démontré leur potentiel dans le cadre des projets de Proof of Concept (une annexe spéciale à ce document sera élaborée après conclusion des PoCs). 16/104

17 4. Concepts Dans le cadre de l IAM, de nombreux termes sont utilisés dans des contextes différents. Il est donc important d établir, dans un premier temps, une base de compréhension commune. Dans le présent document, les termes issus du document «Vision infrastructure egov IAM» [4] sont donc repris et, le cas échéant, complétés afin que l architecture de la solutionprésentée puisse constituer un document indépendant des autres. Le glossaire du «Modèle de référence ech IAM [1], le document «Principes opérationnels formels ech-0107 IAM» [2] ainsi que certains documents issus de l environnement SuisseID [3] constituent les sources de ce document. Il peut arriver que des termes utilisés soient formulés en anglais, langue qui est largement répandue et connue dans notre champ d activité. Là où cela s avère nécessaire, les termes sont illustrés et approfondis à l aide d exemples et de diagrammes. L OASIS (Organization for the Advancement of Structured Information Standards), une organisation internationale à but non lucratif active dans le développement de l E- Business et des standards Webservices constitue une autre source terminologique 6. Les documents OASIS suivants sont par exemple particulièrement intéressants en ce qui concerne le modèle d architecture E-Government IAM: Web Services Security (WS Security): décrit les protocoles de communication en tenant compte des aspects de la sécurité des Webservices; Web Services Security Policy (WS Security Policy): définit des «Policy Assertions basés sur la sécurité» destinés aux Webservices (assurances permettant de satisfaire aux aspects sécuritaires du trafic entre Webservices); Web Services Trust (WS Trust): décrit les mécanismes permettant d assurer la sécurité de certaines propriétés inhérentes aux sujets, aux domaines et entre les domaines. Ces différents concepts et standards approuvés par l OASIS sont par exemple utilisés par de grandes entreprises telles qu IBM, Oracle ou Microsoft. Il est toutefois à noter que ces termes ne correspondent pas toujours avec la terminologie adoptée en Suisse, notamment dans le domaine de la SuisseID (exemple: chez OASIS on parle d un STS - Security Token Service, ce qui, dans l environnement SuisseID, correspond au CAS Claim Assertion Service). Les termes propres à OASIS seront toutefois également évoqués ici afin de pouvoir établir des parallèles avec les «concepts suisses». Les termes mentionnés ne sont pas présentés par ordre alphabétique mais plutôt en fonction de la structure logique du document ainsi que des interdépendances existantes entre les différents termes /104

18 4.1. Sujet Sujet Le sujet est une entité qui a accès ou qui souhaite accéder à une ressource électronique. Il peut s agir d une personne physique ou morale mais également d une machine. Le sujet est le détenteur de la clé privé relative aux certificats numériques (4.5) Ressource Ressource Une ressource est une application, un service, une fonction, un processus ou un ensemble de données auquel un sujet souhaite accéder. Les ressources peuvent également être des sujets ou respectivement être représentées par des sujets, par exemple lorsqu une ressource (p. ex. un service) exploite une autre ressource (p. ex. un autre service) Identité numérique Identité numérique L identité numérique possède un identifiant (nom univoque) et, souvent, un certain nombre d attributs supplémentaires qui peuvent être assignés clairement à un sujet dans un espace de noms (et de ce fait dans un domaine). Un sujet peut avoir plusieurs identités numériques Identifiant Identifiant L identifiant est une chaîne de caractères qui définit clairement un sujet dans un espace de noms. L identifiant univoque d un sujet est souvent un nom peu explicite qui peut être relativement complexe. Cet identifiant peut également être contenu dans un certificat numérique. L identifiant sert uniquement à identifier un sujet de façon univoque et sans ambiguïté possible. Les identifiants sont également appelés CUID (Common Unique Identifier). 18/104

19 Remarque: dans l environnement Suisse ID, l identifiant est un numéro SuisseID univoque qui se présente sous la forme Certificat numérique Certificat numérique Le certificat numérique accole une clé publique avec des données qui permettent d identifier un sujet ou une ressource (détermination du propriétaire du certificat). Dans ce but, le certificat comporte usuellement: le nom de l instance qui a émis le certificat; des informations concernant les modalités et les procédures selon lesquelles le certificat a été émis (p. ex. algorithme de cryptage); des informations sur la durée de validité du certificat; la clé publique à laquelle le certificat fait référence; le nom (ou une autre caractéristique d identification univoque) du propriétaire de la clé publique (c est-à-dire le sujet); d autres informations complémentaires sur le propriétaire de la clé publique; des indications sur le domaine d utilisation et de validité de la clé publique; une signature numérique permettant de vérifier l authenticité des informations contenues dans le certificat. Remarques: dans la suite du présent document, le terme «certificat» désignera toujours le «certificat numérique»; l identité numérique du sujet (l identifiant) n est pas automatiquement assimilable à son certificat; un sujet ou une ressource peut posséder plusieurs certificats; un certificat se réfère toujours à un seul sujet/à une seule ressource; il arrive souvent que deux sujets interagissent, p. ex. via un SSL-Handshake: dans ce cas, client et serveur se comportent tous deux comme des sujets qui assurent conjointement un échange sécurisé des données Domaine Le terme de domaine tire son origine du latin dominium (seigneurerie, propriété). En informatique, il décrit un ensemble d objets d information qui sont partagés et peut être utilisé dans différents contextes, p. ex. domaine d administration, domaine d application, domaine de donnée ou domaine de réseau. 19/104

20 La structure fédérative de la Suisse (Confédération, cantons et communes) fait qu il existe un grand nombre de domaines (au sens originel du terme). L organisation responsable du domaine ou la convention de collaboration dans le cas d une interconnexion fédérative définit les règles qui régissent le domaine (Policy). Domaine (IAM) Un domaine se compose d une certaine quantité d objets d information et d un ensemble commun de règles et de processus. Des domaines peuvent contenir d autres domaines. Chaque sujet possède une identité numérique univoque propre à chaque domaine. Les domaines peuvent établir entre eux des relations de confiance, formant ainsi un «Circle of Trust» (voir Liberty Alliance Standard), au sein duquel des règles et des processus supplémentaires peuvent être appliqués Espace de noms Espace de noms (IAM) L espace de noms est une représentation abstraite permettant d ordonnancer de façon logique les identifiants de domaines des sujets en fonction de règles sémantiques établies. Nous sommes tous familiarisés avec l espace de noms Internet et utilisons la notation www pour invoquer une ressource définie du web, comme p. ex. Avant l avènement d Internet, nous étions déjà habitués des espaces de noms tels que les noms de processus d un système d exploitation ou l espace de noms d un système de gestion de fichiers. Les espaces de noms et respectivement les domaines sont d une importance essentielle pour pouvoir identifier de façon univoque les sujets qui se trouvent dans l environnement IAM. Remarque concernant l unicité: le modèle de référence ech stipule qu une personne (un sujet) peut posséder plusieurs identités numériques. Au sein d un espace de noms (et d un domaine) donné, chaque ressource exige systématiquement une identité univoque. Pour résoudre cette ambiguïté, il s agit de mettre en relation les identités numériques externes avec les identités correspondantes à l intérieur de l espace de noms. Cette mise en relation (Mapping) peut être considérée comme une sorte d adressage indirect (voir Figure 6): 20/104

21 Espace de noms X Ext-ID A1 Nom ressource A Ext-ID A1 A B Ext-ID A2 Ext-ID A3 Ext-ID A3 Non ressource B Ext-ID B1 Ext-ID B2 C Ext-ID B3 Nom ressource C Ext-ID C1 Ext-ID C2 Ext-ID C2 Ext-ID C3 Nom ressource D Ext-ID D1 D Ext-ID D2 Ext-ID D3 Figure 6: espace de noms et mise en relation des identités Dans cette illustration, les identités externes (ID ext) sont mises en relation avec les ID cibles par le biais d un tableau. On constate p. ex. que les différentes identités numériques ID ext A1 et ID ext A2 se réfèrent à la même ressource «Nom ressource A». L identité externe ID ext C2 fait, quant à elle, référence à la ressource «Name Ressource C» Attributs Outre l identifiant univoque, les identités peuvent posséder d autres attributs qui décrivent des caractéristiques supplémentaires. Ainsi un sujet «Utilisateur» possède normalement des attributs supplémentaires tels que nom, prénom, numéro de téléphone, adresse de courriel, etc. Les attributs des ressources sont p. ex. constitués par les rôles d application, les privilèges, etc. Attribut L attribut est un champ d information (contenant) de type quelconque pouvant être associé à une identité numérique, Il sert à décrire les caractéristiques de l identité. Les identités numériques possèdent des attributs spécifiques qui sont exploités dans le cadre du processus d Access Control (voir 4.20). Les attributs sont souvent rassemblés par groupes (voir Figure 7), afin de pouvoir être gérés plus aisément, p. ex pour définir plus clairement les responsabilités en matière de gestion. Un exemple de regroupement d attributs IAM dans le cas d une gestion d utilisateurs est mentionné ci-dessous: attributs obligatoires tels que nom, prénom, adresse de courriel, etc.; 21/104

22 attributs de gestion des droits d accès (voir 4.20) p. ex. le sujet dispose des rôles office, internet, administrateur des impôts, membre de la commission de gestion, Les attributs non IAM sont p. ex.: les attributs spécifiques, tels que données concernant l unité organisationnelle interne à une entreprise ou le nom des supérieurs hiérarchiques; les attributs privés tels que p. ex. l adresse de domicile, la photo de l utilisateur, Ces attributs ne seront pas approfondis dans le cadre du présent document. Le regroupement des informations gérées par l IAM (une sorte d IAM Record ou de Container) pour un utilisateur IT donné (sujet) pourrait être structuré comme suit: Utilisateur informatique Identifiant Attributs obligatoires Attributs de droits d accès Attributs spécifiques Attributs privés Figure 7: exemple d administration IAM Record d utilisateur Remarque: dans lecontexte E-Government IAM, le certificat numérique comporte un nombre minimal d attributs. En effet, en Suisse, en raison des disposition relatives à la la protection des données, seuls des attributs non critiques tels que p. ex. nom, prénom peuvent être utilisés à cette fin. Dans cet exemple, les attributs privés sont du ressort de l utilisateur lui-même, qui en est de ce fait responsable (y compris de leur mise à jour). Par contre, l administration 22/104

23 et la gestion des attributs de la gestion de l Access Management Attribute sont du ressort des instances accréditées. Les attributs peuvent être mis à disposition depuis l extérieur du système par l intermédiaire d une interface, p. ex. en provenance d un serveur de Directories (voir chapitre 7.2) Claim, Claimset Définir les attributs nécessaires et pertinents pour une identité numérique est une tâche particulièrement exigeante. C est souvent seulement à l usage ou dans le contexte d implantation qu il est possible d identifier les attributs qui sont réellement utilisés, raison pour laquelle le principe des Claims et respectivement des Claimsets a été développé. Le Claim (de l anglais: affirmation) est un concept plutôtrécent dans l environnement IAM. Il décrit la manière dont il est possible de disposer d attributs fiables dans une identité numérique donnée. La certification est effectuée sur la base d un processus d appui avec fonction de traçabilité. Claim Le claim est une affirmation sur un sujet, certifiée conforme par un organisme officiel digne de confiance. Les Claims peuvent être les attributs d un sujet ou d une ressource, comme p. ex. «Le sujet est médecin». Les Claims peuvent par contre également être issus de leurs attributs, p. ex. «Le sujet a 18 ans révolus». Claimset Un Claimset est un ensemble de Claims certifiés par un organisme officiel et digne de confiance, à l instar d un Claim isolé. La Figure 8 illustre un exemple de Claimset un ensemble de Claims isolés qui est certifié dans sa totalité par une signature éloectronique (un Security Token correspond à un Claimset signé). 23/104

24 Claimset Security Token Claim 1 Claim 2 Nom, prénom Notaire Claim 3 Claim n Collaborateur de l entreprise xyz Age Signature Figure 8: Security Token avec Claimset et signature Un Claim se présente le plus souvent sous forme de: confirmation de l appartenance au rôle, p. ex. «est collaborateur de notre entreprise»; confirmation d une fonction, p. ex. «est médecin», «est notaire», «est géomètre officiel dans le canton de Berne». Remarque: contrairement aux attributs de l identité numérique qui sont gérés par leur propre IAM (voir 4.8) et qui peuvent être utilisés p. ex. par l intermédiaire d une interface LDAP, les Claims sont des attributs d identité numérique confirmés (signés) par le Claim Provider et qui peuvent être mis à disposition sur Internet de façon sécurisée, en tant que Security Token Function, rôle Rôle Le rôle est une propriété qui peut être assignée à une identité numérique (d un sujet) au sens du modèle RBAC 7. 7 RBAC: Role Based Access Control 24/104

25 Fonction La fonction est un rôle officiellement certifié, p. ex. médecin, avocat, policier, directeur, fondé de pouvoir, etc. Au niveau de l identité numérique, la fonction d un sujet peut être générée par le rôle ce celui-ci. Ce rôle peut être utilisé pour l attribution des droits d accès. Les fonctions et les rôles sont des attributs qui, pour pouvoir être utilisés dans l IAM, doivent être homologués par une instance digne de confiance. Dans le contexte IAM, ils doivent toutefois être traités comme des Claims Autorisation Par autorisation 8 (empowerment), on entend l espace de manœuvre (découlant de la nécessité d agir) attribué, dans un cas concret, à une personne ou à un système bien précis. Les autorisations ont la propriété d être clairement définies dans les limites du domaine et de représenter clairement quelles taches et quelles propriétés significatives sont attribuées à la personne requérante ou au système requérant. Les autorisations constituent la base d une reconnaissance réciproque des compétences opérationnelles entre différents domaines. Leur structure peut comporter plusieurs couches et un cadre commun de compréhension doit être institué entre tous les domaines concernés. Autorisation Habilitation temporaire dotée de rôles retraçables (fonction) pouvant être attribuée à une identité numérique. La Figure 9 illustre la systématique d une requête d autorisation: Tâche 1 A C Paquet 2 trust trust Tâche Autorisation 4 B 3 5 CAS pour autorisations Paquet Résultat 7 6 Autorisation Figure 9: autorisation 8 Dans le contexte de l E-Government, on parle également souvent d E-Autorisation 25/104

26 Condition préalable: A et C ont convenu de faire confiance au CAS (pour l obtention de l autorisation). Les différentes étapes: 1. A est chargé d une tâche. Il envisage de la déléguer à B; 2. il élabore une liste des tâches à effectuéer 3. ainsi qu une autorisation destinée à B; 4. il transmet cette liste des tâches à B; 5. B exécute les tâches. Le résultat de l opération est alors généré; 6. le résultat peut p. ex. être transféré à C; 7. C est en mesure de vérifier l autorisation. Le cas échéant, C peut contrôler d où provient la liste Credential Credential Certificat qui permet de vérifier la prétendue identité numérique d un sujet accédant à une ressources. Les Credentials peuvent p. ex. être constitués par des papiers d identité, des attestations, des mots de passe ou des certificats numériques qui permettent d identifier un sujet de façon univoque Claim Assertion Service, Claim Assertion Infrastructure, Identity Provider, Service Provider dans le contexte SuisseID Les termes suivants sont fréquemment utilisés dans le contexte de SuisseID: Claim Assertion Service CAS Terme spécifique au contexte SuisseID et qui correspond au terme «Security Token Service STS» (voir 4.14) d OASIS. Claim Assertion Infrastructure CAI Infrastructure utilisée pour mettre à disposition, avec le consentement explicite de l utilisateur et de façon sécurisée, des attributs (Claims) d utilisateurs contenus dans des répertoires et des registres. 26/104

27 Identity Provider IdP Service permettant de valider l émission d Identity Claims. Service Provider SP Correspond au terme RP d OASIS (voir 4.14). Les concepts de CAS, CAI, IdP et SP sont illustrés dans la Figure 10 ci-dessous: Infrastructure centrale Directory Service et Assertion Service Infrastructure CSP IdP CAS Other IdP Other CAS Interface Interface Interface Interface Claim Assertion Infrastructure CAI SuisseID Interface Browser Interface Service Provider (SP) Utilisateurs Applications Figure 10: Claim Assertion Infrastructure CAI La Claim Assertion Infrastructure CAI constitue le lien entre les différents partenaires et comprend, en fonction de la spécification technique de SuisseID (voir [3]), les éléments suivants: Infrastructure centrale: infrastructure CSP (Certification Service Provider) comprenant: IdP Identity Provider; CAS Claim Assertion Service. Directory Service et Assertion Service: IdP et CAS Service Provider supplémentaire (en option). Utilisateurs (disposant de SuisseID): utilisant les applications d un fournisseur de services (Service Provider SP). 27/104

28 Service Provider (SP): fournisseurs de services mentionné ci-dessus (voir 4.14), habituellement désignés sous le terme de Relying Party (RP) Terminologie OASIS: Security Token Service STS, Relying Party RP Dans la terminologie OASIS, les Claimsets sont générés par le Security Token Services STS (voir 4.9). Le concept de STS sera expliqué en relation avec les «Relying Parties RP». Security Token Service STS Le Security Token Service STS désigne l infrastructure qui est en mesure de générer les Security Tokens munis de leur signature électronique conformément aux standards internationaux en vigueur 9, respectivement qui met ce service à disposition. Remarque: dans le contexte SuisseID, les STS sont désignés sous le terme de CAS (Claim Assertion Service). Relying Party RP En tant que propriétaire d une ressource, le Relying Party fait confiance (angl. trusts), au sens juridique du terme, aux Claims émis par un Security Token Service STS digne de confiance. Le terme «Relying Party» est souvent utilisé en relation avec les Claims et le Security Token Service STS. Une «Relying Party» se fonde sur les informations contenue dans les Claims ou le STS pour élaborer le service. La Figure 11 ci-dessous illustre le principe du Security Token Service STS. Dans cet exemple, on utilise deux STS pour rassembler toutes les informations requises (fédération de Security Token Services). 9 OASIS 28/104

29 trust trust STS-A STS-B RP 6 Utilisateur Figure 11: Federated Security Token Service Condition préalable: le Relying Party RP fait confiance aux deux Security Token Service Providers STS-A et STS-B. Description du cas d application: 1. RP demande les attributs correspondants (Claim), p. ex. l appartenance à l entreprise; 2. l utilisateur consulte STS-A pour ses attributs (Claims) d appartenance à l entreprise; 3. ces informations lui sont fournies par STA-A dans un Security Token et sous forme d un Claimset; 4. l utilisateur envoie ce Security Token au STS-B afin d y rajouter sa fonction, p. ex. notaire (étant donné que le RP fait confiance aux deux instances, le STS-B ne doit pas impérativement faire confiance au STS-A); 5. le Security Token (Claimset) enrichi de la fonction est renvoyé à l utilisateur; 6. l utilisateur décide d envoyer ce Security Token (Claimset) au RP IAM - Identity and Access Management Les identités numériques des sujets sont gérées par l Identity Management, gestion qui englobe en outre souvent les attributs (voir 4.8) et les règles d accès (voir 4.21), ce qui explique la dénomination de IAM Identity and Access Management: 29/104

30 IAM L Identity and Access Management se consacre à la définition et à l émission des identités numériques, des Credentials et des Claims, à la définition des règles d accès et à la surveillance et au contrôle des accès aux ressources protégées. En principe, un système IAM se compose de deux parties distinctes: Administration: gestion des identités numériques et de leurs attributs/claims (élaboration, modifications, lecture, activation, désactivation, libération, etc.). Directory: un directory est une base de données optimisée pour la gestion des identités Registre Dans le langage administratif, les registres sont des répertoires (voir également chapitre 7.2.1), tels que p. ex. le registre des habitants, le registre des avocats, le registre d état civil, le registre des véhicules à moteur, etc. Ces registres sont en principe gérés par des organismes officiels (autorités). En plus de ces registres officiels, il existe toute une série de registres supplémentaires, p.ex. registres des diplômes universitaires, des diplômes EPF ainsi que des diverses écoles d ingénieurs, etc. Les répertoires contiennent des informations spécifiques concernant une personne ou une organisation. Ces informations sont en partie confidentielles. Registre Répertoire (banque de données) permettant de gérer des informations spécifiques concernant une personne, un groupe professionnel ou une organisation (mandataires commerciaux). Le grand nombre de répertoires différents pose des exigences particulières au niveau des registres. Ces exigences sont notamment décrites dans le document «Harmonisation des registres» élaboré par l Office fédéral de la statistique (voir: Les registres sont souvent subdivisés en: registres des fonctions: registres décrivant les fonctions, telles que p. ex. médecins, notaires, avocats; registres des autorisations: registres recensant les autorisations, p. ex. les droits de signature. Le contenu des registres peut p. ex. être mis à disposition sous forme de Claim Assertion Service (CAS). 30/104

31 4.17. Trust (relation de confiance) Dans le contexte IAM, la confiance entre les partenaires est d une importance majeure. Il s agit de savoir qui fait confiance à qui et sur la base de quels critères. Trust Relation de confiance définie formellement entre entités, p. ex. au moyen de la description formelle des conditions qui doivent être remplies pour que deux domaines puissent se faire mutuellement confiance Identification, authentification En français, nous opérons une distinction entre identification et authentification, et ceci contrairement à l anglais, langue dans laquelle ces deux notions sont désignées par «to authenticate». Fondamentalement, il est à noter que ces deux notions désignent toutefois deux aspects d une même procédure. Identification Authentification Preuve de l identité numérique d un sujet. Procédure de vérification d une identité numérique (sujet). E Il existe différentes méthodes d identification: identification de bas niveau (faible): en général, toute identification basée sur les paramètres «nom d utilisateur et mot de passe» est considérée comme étant de bas niveau. Les mots de passe peuvent être découverts relativement facilement, voire même transmis avec les droits qui leur correspondent; identification de haut niveau (forte): identification mettant en œuvre deux ou plusieurs critères. On entend par là la combinaison de plusieurs catégories de caractéristiques qui sont demandées à titre de preuve pour permettre d identifier l utilisateur avec succès. En règle générale, on distingue les catégories de caractéristiques suivantes: ce que l utilisateur possède (p. ex.: Smartcard, liste à biffer, Security Token); ce que l utilisateur sait (p. ex.: mot de passe ou code PIN); ce que l utilisateur est (caractéristiques biométriques telles qu empreintes digitales, empreinte veineuse, empreinte rétinienne, etc.) Autorisation (administration, durée) Le terme d autorisation est utilisé dans deux contextes différents: d une part dans le cadre de la procédure d attribution des droits d accès à une identité numérique (activité administrative selon les prescriptions du législatif), 31/104

32 d autre part dans le cadre de la procédure de vérification des droits d accès et de leur durée d exécution (Runtime). Autorisation (administration) Définition et attribution des règles d accès à une ressource. Synonyme: Access Management L attribution de l autorisation (administration) est souvent également appelée «Access Management». Autorisation (durée d exécution) Contrôle des droits d accès d une identité numérique (sujet, ressources) à une ressource et de leur durée d exécution. Synonyme: Access Control Le contrôle des droits d accès et de leur durée d exécution est également appelé «Access Control» Access Control Access Control L Access Control est le processus qui contrôle et qui garantit le respect des règles d accès d une identité numérique à une ressource. Synonyme: autorisation (durée de validité). Le processus d Access Control est décrit en détails au chapitre Règles d accès Les responsables des ressources définissent les règles d accès pour leurs propres ressources. Les droits sont assignés en tant que profils d accès aux ressources et peuvent être enregistrés p. ex. dans un Directory. Règles d accès Règles définissant les possibilités d accéder aux ressources. 32/104

33 Administration des exigences Spécification des exigences 5. Exigences Prelim: Framework And Principles A Architecture H Vision Architecture Change Management G Implementation Requirements Governance B Business Architecture C Information System Arch. Les exigences sont au cœur de l ensemble de la méthode TOGAF ADM. Dans un tel contexte, il n est pas possible de généraliser les exigences relatives à un environnement spécifique. Il s agit donc d introduire un processus de gestion ordonnée des exigences dans lequel chacune d entre elles peut être spécifiée et administrée. La Figure 12 illustre le processus sous forme BPMN: F Migration Planning E Opportunities and Solutions D Technology Arch. Début Recenser les exigences Saisir/ documenter les exigences Analyser lex exigences Analyser lex exigences Fin Libérer les exigences Ajourner les exigences Début Rejeter les exigences Modifier les exigences Fin Retracer les exigences Figure 12: processus de gestion des exigences Au-delà de la structure formelle de la gestion des exigences, il s agit également, dans ce contexte, de définir les acteurs et leurs rôles. Les rôles suivants sont usuellement attribués: Gestionnaire des exigences Bureau de gestion Tâches: initialisation de la gestion des exigences, réalisation du processus de gestion de exigences. Compétences: définition de la façon dont la gestion des exigences doit être réalisée dans son domaine de compétence; implication des postes nécessaires à l appui de la gestion des exigences. Administration des exigences dans le domaine de compétence correspondant (projet, organisation). Responsabilité: garantit que les processus de la gestion des exigences soient mis en place et soit réalisés de façon efficiente et efficace selon les conditions cadres du projet. Réalisation de l administration des exigences selon les prescriptions de la gestion des exigences. Maintenance et mise à jour des attributs administratifs dans les listes d exigences. Tâches: les membres du bureau de gestion des exigences ont pour tâche de veiller à ce que la gestion des exigences soit mise en œuvre, dans le 33/104

34 des exigences Développement des exigences Fournisseur d exigences domaine d activité correspondant, selon les directives définies dans le cadre de l initialisation de la gestion des exigences. Ils procèdent également à l évaluation finale des exigences. Compétences: ils dirigent le gestionnaire des exigences et le développement des exigences. Ils décident si des fournisseurs d exigences doivent être impliqués et, dans l affirmative, lesquels. Responsabilité: ils décident des tenants et des aboutissants de la gestion des exigences dans le cadre du domaine de responsabilité qui leur est assigné. Tâches: collecte des exigences implicites ou explicites déjà existantes et développement des exigences des partenaires. Compétences: développement des exigences en fonction du domaine de compétence (projet, organisation). Les partenaires nécessaires peuvent être impliqués dans la réalisation des tâches. Responsabilité: ce rôle est responsable du développement des exigences ainsi que de l exploitation des outils y relatifs (Tools). Il est également responsable de faire en sorte que les directives correspondantes, définies dans le cadre de l initialisation, soient respectées en tant qu objets d exigence. La tenue de la liste des exigences fait également partie de ses attributions. Tâches: formulation des exigences selon les directives du développement des exigences. Participation active au développement des exigences. Compétences: élaborer et formuler des exigences. Responsabilité: garantir que toutes les exigences existantes dans son domaine d intérêt soient intégrées au développement des exigences. Les exigences sont documentées sous une forme appropriée. Le tableau ci-dessous a été établi sur la base des exigences sommaires contenues dans le document «ech-0107 IAM» [2]. Les exigences qui y sont mentionnées servent d aide-mémoire/liste de contrôle pour l établissement d une liste d exigences concrètes dans le cadre d une gestion des exigences. Au niveau de la gestion des exigences, la pertinence et la priorité de chacune des exigences doivent être évaluées individuellement en fonction de la situation initiale. N o Titre Description Critères d acceptation Commentaire 1 Preuve de l identification seulement si nécessaire L identité numérique d un sujet ne doit faire l objet d une vérification que lorsque cela s avère nécessaire pour des raisons de sécurité. Preuve fournie par l analyse des cas d application correspondants. L acceptation croît en fonction de la protection des données (aucune donnée inutile ne doit être récoltée). 2 Vérification des Credentials Les Credentials d une identité numérique (sujet) ne seront vérifiés que lorsque cela s avère nécessaire pour des raisons de sécurité. Preuve fournie par l analyse des cas d application correspondants. L acceptation croît en fonction de la protection des données (aucune donnée inutile ne doit être récoltée). 34/104

35 N o Titre Description Critères d acceptation Commentaire 3 Accès aux ressources indépendant du lieu 4 Petit nombre d identités numériques 5 Petit nombre de Credentials à gérer 6 Prix des identités numériques 7 Acquisition simple de l identité numérique et des Credentials Le sujet peut accéder à une ressource indépendamment du lieu où il se trouve, à condition que cette dernière soit «visible» sur Internet et que le sujet soit au bénéfice des droits d accès requis. Pour des raisons de praticabilité, il est souhaitable de ne devoir gérer et tenir à jour que le plus petit nombre d identités numériques possible. Idéalement, un sujet n a besoin que d une seule identité numérique, utilisable en tous les cas. Pour des raisons pratiques, la quantité de Credentials à gérer devrait être la plus réduite possible. Idéalement, un sujet ne devrait disposer que d un seul Credential par identité numérique. Le prix de l établissement du support de l identité numérique doit être accessible (comparable au prix d une carte EC). Pour le consommateur final, le processus d acquisition des identités numériques doit être simple et facilement retraçable. 8 Suppléance Lors de l acquisition d une identité numérique, il doit être possible de désigner des suppléants qui pourront y avoir accès. 9 Clarté L identité numérique d un sujet est claire à l interne de ses domaines. Preuve fournie par l analyse des cas d application correspondants. Au niveau suisse, l idée est qu une personne physique ne dispose que d une seule identité numérique valable au niveau fédéral, cantonal et communal. Il est possible de disposer d autres identités numériques externes à E- Government. Il est possible de choisir le nombre de Credential par sujet. Au niveau suisse, il apparaît qu un seul et unique Credential suffit à chaque identité numérique pour établir tous les contacts E-Government, que ce soit au niveau fédéral, cantonal ou communal. Comparaison du prix du support de l identité numérique avec les cartes EC ou les cartes de crédit usuelles. Avant la mise en œuvre: analyse du processus d acquisition; Après la mise en œuvre: enquête auprès des utilisateurs. Vérification au moyen de l analyse des cas d application correspondants. Vérification au moyen de l analyse des cas d application correspondants. Cette exigence ne peut être satisfaite que lorsqu un série de conditions cadres est remplie. Ainsi, la ressource doit être visible par le sujet et le domaine de la ressource doit être en mesure, grâce à la relation de confiance correspondante, de conserver la connexion avec le Claim Provider. Pour le moment, le contexte de cette exigence se limite à E-Government. Le contexte de cette exigence se limite à E- Government. Le prix influence considérablement l acceptation de l identité numérique. Le processus d acquisition influence considérablement le taux d utilisation ultérieure. Correspond à l établissement d une procuration dans les affaires courantes. Cette exigence ne doit pas être confondue avec celle qui veut que les sujets puissent avoir plusieurs noms, p. ex. des synonymes. 35/104

36 N o Titre Description Critères d acceptation Commentaire 10 Accès aux ressources En fin de compte, le responsable des ressources définit qui (identité numérique) est autorisé à accéder à ses ressources et de quelle manière (autorisation). Les abus doivent pouvoir être exclus. 11 Fiabilité La solution E-Government est fiable et solide. 12 Disponibilité En principe, la solution E- Government est disponible 7 jours sur 7 et 24 heures sur 24. Les périodes consacrées à la maintenance doivent être indiquées clairement à l utilisateur (maximum 4 h par mois pour un total de 20 h par année). 13 Performance En principe, l infrastructure E-Government doit être conçue de manière à ce que toute interaction avec le système génère une réponse après un délai maximal de 3 secondes. Exceptionnellement, le temps de réponse peut atteindre un maximum de 30 secondes. Dans ce cas, l utilisateur doit être avisé de l augmentation du temps de réponse. 14 Charge minimale au niveau de l administration des identités numériques et de leur Credentials 15 Charge minimale au niveau de l administration des attributs (Claims) des identités numériques 16 Respect des directives légales La charge relative à l administration des identités et de leur Credentials doit être assumée de manière efficace et efficiente. La charge relative à l administration des attributs (Claims), p. ex. les droits d accès des identités numériques aux ressources, doit être assumée de manière efficace et efficiente. L infrastructure E- Government doit respecter les directives légales fédérales, cantonales et communales. Vérification au moyen de l analyse des cas d application correspondants. Un processus d Access Control doit être mis en œuvre qui prenne en compte cette fonction de manière retraçable. Contrôle par vérification, y compris au niveau du design (cas d application), tests intensifs du système, monitorage en cours d exploitation. Monitorage en cours d exploitation. Monitorage en cours d exploitation (évaluation par les utilisateurs). Monitorage de la charge administrative assumée par les fournisseurs d identité. Monitorage de la charge administrative relative aux Security Token Services (Claim Provider) Vérification du modèle d architecture par des auditeurs indépendants. En tous les cas, cette exigence doit encore être complétée par des décisions prises au niveau juridique. Dans ce cas, la mise en place d une gestion des attentes peut aider, p. ex. en réalisant une représentation transparente de la fiabilité destinée aux utilisateurs. En fonction de la nécessité, la disponibilité planifiée doit être la plus grande possible mais en aucun cas supérieure (pour des raisons de coûts). Les systèmes interactifs doivent fournir une quittance rapide à toute action effectuée, faute de quoi l utilisateur final renoncera à répéter sa requête. La charge administrative exerce une influence directe sur les coûts et doit de ce fait être maintenue au plus bas niveau possible. La charge administrative exerce une influence directe sur les coûts et doit de ce fait être maintenue au plus bas niveau possible. En particulier au niveau de la sécurité des informations: confidentialité, disponibilité et intégrité. 36/104

37 N o Titre Description Critères d acceptation Commentaire 17 Soumission aux audits Il doit être possible, dans le cadre de l infrastructure E-Government IAM et en s identifiant selon les directives appropriées, de configurer différentes actions permettant de procéder en tout temps à un audit du système (traçabilité). 18 Exploitabilité facilitée Au niveau client, les utilisateurs souhaitent pouvoir accéder aux ressources sans rencontrer de grands problèmes d installation et de compatibilité. 19 Facilité d entretien / modificabilité La solution E-Governmentdoit être conçue de façon à pouvoir mettre en œuvre rapidement et à bon marché les modifications des conditions cadres: modifications au niveau légal, adaptations relatives à la sécurité (actualisation de l état de la technique), etc. Contrôle par vérification, y compris au niveau du design (cas d application), tests intensifs du système, monitorage en cours d exploitation Contrôle par vérification de l ensemble du processus IAM du point de vue de l utilisateur (Usability). Vérification au moyen de l analyse des cas d application correspondants. Il doit être possible de procéder en tout temps à l établissement de la cohérence existant entre l identité numérique et ses Credentials. L accès aux ressources et les actions réalisées doivent pouvoir être retracées. Des processus simples et compréhensibles contribuent à accroître l acceptation de la part des utilisateurs. 37/104

38 6. Architecture de gestion Prelim: Framework And Principles L architecture cible est décrite, du point de vue de l entreprise, dans la phase B Architecture de gestion du cycle du TOGAF ADM. H Architecture Change Management A Architecture Vision B Business Architecture Dans le contexte E-Government IAM, les processus sont subdivisés, selon le «Modèle de référence ech» [1] en une partie législative (processus de pilotage) et une partie exécutive (processus d administration et d exploitation) 10. G Implementation Governance F Migration Planning Requirements E Opportunities and Solutions C Information System Arch. D Technology Arch. Législatif (pilotage) L1: Governance Détermination Policy Détermination organisation / collaboration Collaboration interdomaines Définition des rôles avec AKV L2: Riskmanagement Identification besoin de protection Analyse des risques Gestion des risques Concept ISDS L3: Compliance Review régulations IAM Audit processus IAM Garantie de respect des directives Processus de gestion Exécutif (administration, exploitation) Runtime M1: identités numériques M2: règles d accès R1: Access Control Authentification Autorisation M3: Claims M4: Credentials M5: identifiants Figure 13: cartographie du processus E-Government IAM Les services destinés à l infrastructure IAM peuvent émaner des processus exécutifs. Les services identifiés par les processus font partie intégrante de l architecture de l application décrite au chapitre 8. Indication: les processus BPMN illustrés ici représentent un déroulement sommaire possible. Dans la réalité, ces processus devront être ultérieurement détaillés, voire même modifiés, en fonction des exigences spécifiques qui se feront jour Parties impliquées/rôles Les processus seront réalisés par des entités auxquelles seront attribués un, voire éventuellement plusieurs rôles. Les principaux rôles sont énumérés ci-dessous, à titre d exemple, avec les tâches, les compétences et les responsabilités y relatives. L interaction de ces rôles est explicitée dans les processus BMPN. 10 Le document [5] «National Strategy for Trusted Identities in Cyberspace» distingue trois niveaux: Governance Layer: correspond au niveau législatif Management Layer: correspond aux processus de gestion de l exécutif Execution Layer: correspond au niveau runtime 38/104

39 Organisme responsable de l autorisation Chargé de sécurité (CISO Chief Information Security Officer) Auditeur / réviseur Guichet d identification Identity Provider Credential Provider Claim Provider Tâches: soutien à la gestion de la gouvernance, au management du risque et à la conformité (Compliance). Réception finale des directives IAM pour l entreprise. Acceptation formelle du concept IAM. Compétences: définition/réception des règles, définition/réception de l organisation; prise en charge des risques résiduels issus de l analyse des risques. Responsabilité: assurance de la gouvernance; assurance de la gestion des risques; assurance de la conformité. Tâches: conseils sur le concept IAM proposé et mise en œuvre de la gestion de la sécurité du point de vue IAM. Compétences: autorisé à édicter des directives en matière de sécurité au niveau de la solution IAM préconisée. Responsabilité: garantie de l identification, évaluation et adressage des risques liés à la sécurité, garantie de la conformité des règles de l architecture IAM. Tâches: conduite des audits. Compétences: définit ce qui doit être soumis à audit et de quelle manière. Responsabilité: réalisation des audits selon les règles définies (Policy). Tâches: contrôle les indications nécessaires et l identité du requérant (p. ex. à l aide du passeport ou de la carte d identité). Transmet de façon sécurisée la requête vérifiée, accompagnée des dossiers nécessaires, à l Identity Provider. Compétences: peut refuser la demande d identité numérique, p. ex. lorsque des indications concernant le requérant manquent ou que l identification du requérant ne peut pas être établie de façon probante. Responsabilité: connaissance et réalisation correcte du sous-processus d identification. Tâches: réalise le processus de gestion de l identité (dont, entre autres, l édition des identités numériques). Interne Identity Provider (p. ex. à l interne d une entreprise): service du personnel, service responsable des collaborateurs externes. Externe Identity Provider: Provider (p. ex. Post, Quovadis, Swisscom, BIT pour la SuisseID). Compétences: mise à disposition de l organisation et de l infrastructure nécessaires à la mise en œuvre des processus. Responsabilité: disponibilité des services d identité selon SLA (Service Level Agreement). Tâches: production des Credentials, p. ex. noms d utilisateur/mots de passe ou certificats d authentification. Compétences: définition des Credentials, p. ex. règles concernant les noms d utilisateurs, les mots de passe ou définition du type de certificat d authentification. Responsabilité: offrir un service approprié avec SLA (Service Level Agreement). Tâches: définition des Claims, définition du service Claim, exploitation du service Claim. Compétences: définit avec quels Credentials un Claim peut être interrogé. Responsabilité: mise à disposition du service correspondant (CAS Claim Assertion Service) avec SLA (Service Level Agreement). Des rôles de nature plutôt abstraites sont mentionnés ci-dessous. Ceux-ci ne doivent pas impérativement être définis en tant que rôles standards dans chaque IAM. Seuls ceux qui dépendent des étapes relatives aux représentations des processus d un IAM doivent être pris en considération. Exemple: le responsable (interne) de l identité d un 39/104

40 domaine IAM régule/contrôle la collaboration avec l Identity Provider externe et, le cas échéant, prend en charge, le cas échéant, les cas particuliers. Responsable de l identité Responsable des ressources Responsable de domaine Requérant d identité numérique Responsable de processus Tâches: administre les identités numériques appartenant à ses domaines. Compétence: en charge des Identity Providers (internes/externes). Responsabilité: administration des identités selon les directives établies. Tâches: connaît les ressources de son domaine de compétence. Définit les règles d accès applicables à «ses» ressources. Compétences: définition des rôles (en accord avec le responsable de la sécurité). Responsabilité: élaboration des règles d accès à «ses» ressources selon les directives établies. Tâches: élabore et communique le concept de domaine. Compétences: définit ce qui fait partie des domaines; définit les règles (Policy) inhérentes aux domaines. Responsabilité: s assure que les codes de domaines soient approuvés par le responsable de la sécurité; diffuse les règles inhérentes aux domaines dont il a la charge et les impose. Tâches: dépose la demande d identité numérique (p. ex. sujet, supérieur hiérarchique, responsable système, ressources humaines, etc.). Compétences: décide de déposer une demande d identité numérique. Responsabilité: prépare les documents nécessaires à l enregistrement et les présente pour enregistrement (p. ex. passeport ou carte d identité valable à titre de preuve d identité pour l obtention d une Suisse ID). Tâches: définit et administre les processus pour un domaine d activité donné. Compétences: définit les standards permettant de définir les processus. Responsabilité: vérifie la pertinence et la conformité des processus selon les directives. Remarque: les rôles réellement mis en œuvre dans un contexte IAM, un domaine ou une fédération de domaines données doivent être élaborés concrètement dans le cadre de la mise en place du concept IAM. En l occurrence, il s agit égalementde définir de façon plus précise les tâches, les compétences et la responsabilité Processus au niveau législatif En font partie les processus inhérents à l environnement GRC (Governance, Risk, Compliance) de pilotage de l E-Government IAM. Législatif (pilotage) L1: Governance Détermination Policy Détermination organisation / collaboration Collaboration interdomaines Définition des rôles avec AKV L2: Riskmanagement Identification besoin de protection Analyse des risques Gestion des risques Concept ISDS L3: Compliance Review régulations IAM Audit processus IAM Garantie de respect des directives Figure 14: processus au niveau législatif 40/104

41 Ils décrivent le déroulement de la définition des directives et des conditions cadres de l exploitation de l environnement IAM, p. ex. la définition de l offre, la définition des règles et des déroulements, la détermination des révisions, etc L1: Governance Elle définit l infrastructure et l organisation IAM, dont font partie: la détermination des codes IAM (Policy): les codes IAM définissent les conditions cadres et le Scope de la solution IAM visée. Dans ce contexte, il est particulièrement important d assurer la traçabilité de l ensemble du déroulement du processus (p. ex. le système d archivage des documents importants); la détermination de l organisation (acteurs) ainsi que les relations établies (collaboration): l organisation IAM décrit la manière dont les différents partenaires et les différents acteurs impliqués sont en relations, la façon d engager les ressources, etc. Les rôles appropriés peuvent ainsi être attribués aux acteurs adéquats; identification/détermination de la collaboration entre les domaines: dans l environnement E-Government, l IAM est généralement mis en œuvre entre plusieurs domaines. De ce fait, l organisation des domaines entre eux, ainsi que les déroulements, doivent être régis clairement; définition des rôles, des tâches, des compétences et de la responsabilité. Les processus sont mise en œuvre par les acteurs, qui peuvent être appelés à jouer un ou éventuellement plusieurs rôles (voir 6.1). 41/104

42 BPMN L1 «Governance» Processus visant à l assurance de la Governance par le biais de la définition/vérification des directives sur l organisation et l infrastructure IAM. Figure 15 : BPMN L1 «Governance» Parties impliquées: Chargé de sécurité: œuvre à l élaboration des directives IAM spécifiques au domaine législatif et les soumet à l organisme responsable de l autorisation. Organisme responsable de l autorisation: définition/réception des codes (Policy); définition/réception de l organisation; prise en charge des risques résiduels issus de l analyse des risques, décision finale concernant les directives d exploitation IAM. IAM au niveau exécutif: administre techniquement le système IAM; conseille le niveau IAM législatif (p. ex. le spécialiste IT), notamment en ce qui concerne l impact de la mise en œuvre des directives IAM. 42/104

43 L2: Gestion du risque Définit le déroulement du traitement du risque (évaluation et adressage) dans le cadre des processus IAM. Pour les projets fédéraux, la procédure est définie de manière précise dans le concept Hermes 11 : Stratégie Confédération en matière de TIC Planification stratégique Principe directeur sécurité TIC OIAF Ordonnance sur l informatique dans l administration fédérale de l administratioin fédérale DirSecInf OPrl Ordonnance concernant la protection des informations Directives du CI concernant la sécurité informatique dans l administration fédérale DirSecInf annexe 1 Exigences minimales en matière de sécurité DirSecInf annexes 2 et 3 Directives sécurité réseaux Exigences accrues en matière de sécurité / concepts de sécurité Elaboration controlling d étude (SCO) Lancement Contacter les chargé-e-s de sécurité P05.01 Lancement des procédures informatiques Analyse préalable Analyser et évaluer les besoins en termes de protection P05.02 Esquisse des propositions de solutions sommaires Concept Réalisation Introduction Conclusion Elaborer et évaluer les mesures de protection Elaboration concept ISDS P05.03 Projets de solutions Mise en œuvre des mesures de protection Mise en œuvre du concept ISDS P05.04 Réalisation de la solution Contrôle des mesures de protection Réception du concept ISDS P05.05 Introduction de la solution Conclusion de la sécurité des informations et de la protection des données P05.06 Fin du «développem ent des solutions» Architectures / standards / implémentations ABS Analyse des besoins en termes de sécurité ProtAn Analyse des risques ISDS Concept de sécurité ISDS Concept de sécurité ISDS Concept de sécurité ISDS Concept de sécurité Figure 16: directives et procédures applicables à des projets à haute exigence en matière de sécurité Il s agit d élaborer: une analyse des besoins en matière de sécurité «ABMS»; un analyse des risques «ProtAn»; un concept SIPD. L analyse des besoins en matière de sécurité permet de dégager les exigences appropriées en termes de sécurité (autant de sécurité que nécessaire mais aussi peu que possible). La gestion du risque peut également s appuyer, de façon alternative ou complémentaire, sur le système de gestion des risques de l information (ISMS) établi selon ISO Ce processus d amélioration définit par les normes ISO appropriées (27000, 9000, etc.) permet d assurer une amélioration constante de la gestion de la sécurité: ainsi, des mesures périodiques sont planifiées, mises en œuvre, vérifiées et optimisées en fonction de la situation actuelle. Ce processus d amélioration constante constitue une procédure éprouvée et efficiente et représente, à l heure actuelle, un élément centrale de toute Best Practice: 11 Pour davantage de détails, voir: Moyens auxiliaires concernant le projet: 43/104

44 Act Check Plan Do Figure 17 : processus d amélioration constante selon ISO.org BPMN L2 «Gestion du risque» Processus de garantie de la gestion des risques basé sur le déclenchement régulier du traitement des risques. Figure 18 : processus L2 «Riskmanagement» Parties impliquées: Chargé de sécurité / CISO - Chief Information Security Officer: réception du concept IAM et exploitation de la gestion de la sécurité du point de vue IAM; garantie de l identification, de l évaluation et de l adressage des risques liés à la sécurité; garantie d une architecture IAM conforme aux codes. Responsable de processus: analyse du Business Impact des processus; 44/104

45 appréciation des risques p. ex. selon ISO Organisme responsable de l autorisation: décide de la mise en œuvre des mesures demandées, respectivement assume les risques résiduels acceptables. Niveau exécutif IAM: administre techniquement le système IAM et élabore par exemple les règles d accès en fonction du mandat, p. ex. spécialiste IT L3: Conformité (Compliance) La solution IAM doit correspondre aux directives en vigueur. La conformité est réalisée au moyen de: l élaboration et l actualisation des directives pertinentes: identification des réglementations en vigueur (lois, ordonnances, Best Practices). Les modifications des directives doivent être prises en compte et les mesures éventuelles en résultant doivent être identifiées; l audit et le contrôle de la mise en œuvre des directives: la cartographie IAM (les processus, l organisation, la mise en œuvre technique) doit être régulièrement soumise à audit, ce qui permet de garantir que la mise en œuvre correspond aux directives édictées BPMN L3.1 «Review réglementation» Processus assurant le contrôle et l élaboration réguliers des réglementations. Figure 19 : processus L3.1 «Review réglementation» Parties impliquées: 45/104

46 Auditeur/réviseur: est mandaté par l organisme responsable de l autorisation; assure les modifications de la réglementation en vigueur; surveille la situation juridique de l IAM; propose, le cas échéant, les ajustements/mesures nécessaires. Chargé de sécurité / responsable de processus: analyse les effets des modifications légales du point de vue de l IAM; coordonne la mise en œuvre des mesures décidées/préconisées par l organisme responsable de l autorisation. Organisme responsable de l autorisation: décide des mesures à prendre, respectivement de l acceptabilité des risques résiduels. Niveau exécutif IAM: administre techniquement le système IAM; met en œuvre les mesures décidées, p. ex. spécialiste IT BPMN «Audit IAM» Processus assurant le contrôle régulier de l IAM au niveau de sa conformité avec les directives. Figure 20 : processus L3.2 «Audit IAM» Parties impliquées: Auditeur/réviseur: est mandaté par l organisme responsable de l autorisation; procède régulièrement à des audits internes. 46/104

47 Responsable de processus: est responsable de l exploitation des processus IAM selon les directives. Niveau exécutif IAM: est responsable de l exploitation du monitorage de l IAM selon les directives. 47/104

48 6.3. Processus de gestion au niveau exécutif Les processus de gestion au niveau exécutif décrivent les déroulements de l administration des objets IAM selon le métamodèle d information illustré dans la Figure 32. Processus de gestion M1: identités numériques M3: Claims M4: Credentials M2: règles d accès Figure 21: processus de gestion au niveau exécutif M1: identités numériques L identité numérique constitue l élément central de tout environnement IAM. Le métamodèle d information (voir Figure 32) illustre clairement le fait que, dans le cadre d un domaine, tout sujet dispose au minimum d une identité numérique Enregistrer et établir une identité numérique Dans l environnement E-Government IAM, le processus d enregistrement doit être mis en œuvre de façon à respecter les directives de la Loi fédérale sur les services de certification dans le domaine de la signature électronique (SCSE). Cela implique: enregistrement d un sujet dans son organisation (collaborateurs de la Confédération, des cantons et des communes): dans une organisation, l identité numérique est normalement établie, après signature du contrat de travail, par le service du personnel qui se base pour cela sur les dossiers personnels ainsi que sur l organisation de l établissement d une identité numérique. Les collaborateurs sont connu personnellement et les données fournies sont crédibles; enregistrement d un sujet externe à l organisation (citoyen, habitant, etc.): dans l environnement E-Government, l enregistrement d un sujet est établie, si nécessaire, par un Identity Provider respectant les directives en matière d enregistrement de la SCSE; enregistrement d une ressource représentée par un sujet: une identité numérique est assignée à la ressource (p. ex. un service particulier ou une application/service). Le responsable de la ressource récolte les informations nécessaires à l enregistrement. 48/104

49 Remarque sur l «identité numérique des ressources»: fondamentalement, seuls des sujets peuvent se voir attribuer une identité numérique. Toutefois, dès qu une ressource assume le rôle d un sujet, elle entre également en possession d une identité. Par définition: (1) (seul) un sujet possède une identité numérique; (2) un sujet est un acteur qui accède à une ressource; (3) une ressource est une application, un service, une fonction, un processus ou se compose de données auxquelles le sujet souhaite accéder; (4) une ressource possède une identité lorsqu elle assume également le rôle de sujet (c est-à-dire qu elle accède à une ressource). Conséquence: (5) une ressource qui n accède à aucune autre ressource ne peut pas se voir attribuer une identité. La Figure 22 indique, à titre d exemple, quand une ressource est susceptible d avoir une identité: le sujet A (personne) exploite la ressource R1 (service): en fonction de (1), (2) A est un sujet et possède une identité; les ressources 2 et 3 (p. ex. données, service) n accèdent à aucune autre ressource: en fonction de (5) les ressources (2) et (3) ne sont pas des sujets et ne possèdent aucune identité; la ressource 1 (p. ex. service) accède aux ressources 2 et 3: en fonction de (2), (4) la ressource (1) est un sujet et possède une identité. A une identité Sujet A (personne) N a pas d identité Ressource R2 (p. ex. données) Ressource R1 (p. ex. service) Ressource R3 (p. ex. service) Figure 22: exemple «la ressource a une identité numérique» 49/104

50 BPMN M1.1 «Enregistrement d une identité numérique» L objectif du processus est d enregistrer un sujet afin de lui fournir une identité numérique. Dans ce cas, il s agit de différencier le sujet selon qu il représente une personne ou un système (service, application, etc.). Si l identité est un système, il faut alors lancer un processus d évaluation des risques qui permette d adresser à l IAM ou au système tout risque ou inféodation potentiel (p. ex. au cas où le système contrôle l accès à une ressource). Indication: la gestion du Credential et de l identifiant peut constituer un processus autonome implanté chez les Providers indépendants. Ce sous-processus est illustré cidessous de façon simplifiée. Figure 23: processus M1.1 «Enregistrement d une identité numérique» Parties impliquées: Niveau législatif IAM: définit et actualise régulièrement les directives concernant l administration des identités. Ces directives peuvent comporter, entre autres, des exigences spécifiques ou techniques concernant la mise en œuvre du processus. Responsable de l identité: administre les identités numériques selon les directives édictées au niveau législatif, p. ex. responsable système (en présence d un système) ou RH (dans le cas de personnes) Requérant: 50/104

51 demande l établissement d une nouvelle identité numérique. Le requérant peut être le sujet lui-même ou p. ex. également son supérieur/le responsable système. Guichet d identification: identifie le sujet de façon univoque selon les directives édictées au niveau législatif, p. ex. sur la base de documents officiels/du système ID. Un rapport de confiance doit être instauré entre le guichet d identification et le responsable de l identité. Chargé de sécurité: traite les cas pour lesquels les directives édictées au niveau législatif ne sont pas claires ou ne sont pas définies. Identity Provider: élabore l identité; constitue l interface avec le fournisseur du Credential et de l identifiant. Change Management Board: décide de l intégration du système dans l IAM (interdomaines) BPMN M1.2 «Suppression d identités» L objectif du processus est d effacer les identités numériques. Indication: le Credential Management peut constituer un processus autonome implanté chez différents Providers. Ce sous-processus est illustré ci-dessous de façon simplifiée. 51/104

52 Figure 24: processus M1.2 «Suppression d une identité» Parties impliquées: Niveau législatif IAM: définit et actualise régulièrement les directives en matière d administration des identités. Ces directives peuvent comporter, entre autres, des exigences spécifiques ou techniques concernant la mise en œuvre du processus. Responsable de l identité: administre les identités numériques selon les prescriptions législatives, p. ex. responsable système (identité = système), RH (identité = personne). Identity Provider: efface l identité numérique; constitue l interface avec le Credential Provider. Initiateur: 52/104

53 lance la procédure d effacement; p. ex.: le sujet lui-même, le supérieur hiérarchique, le propriétaire du système, les autorités, le responsable IAM, etc M2: règles d accès Les règles d accès sont généralement gérées au niveau local en assignant un attribut à une ressource dans un Directoy IAM. En principe, les règles d accès ne sont rien d autre que des Claims (attributs d accès). Elles peuvent être gérées au moyen d un CAS (p. ex. via LDAP). Dans ce cas également, la définition des règles d accès doit être contrôlée par une instance d autorisation spécifique (libération des droits d accès) BPMN M2.1 «Assignation des règles d accès» L objectif du processus est la définition et/ou l assignation des droits d accès à une ou plusieurs ressources sur la base des règles d accès telles qu elles ont été définies. Il s agit ici d impliquer les Claim Providers concernés afin, p. ex., de définir les nouveaux Claims qui seront utilisés dans le cadre des droits d accès ou également d instaurer une relation de confiance entre le système IAM et le CAS. Figure 25: processus M2.1 «Assignation des règles d accès» 53/104

54 Parties impliquées: Niveau législatif IAM: définit et actualise régulièrement les directives concernant l administration des accès aux ressources; Ces directives peuvent comporter, entre autres, des exigences spécifiques ou techniques concernant la mise en œuvre du processus. Responsable des ressources: administre les ressources selon les directives édictées au niveau législatif. Requérant: demande l assignation ou la suppression de règles d accès à une ressource (p. ex. un sujet). Chief Information Security Officer (CISO): traite les cas pour lesquels les directives édictées au niveau législatif ne sont pas claires ou ne sont pas définies. Claim Provider: administre et exploite les Claim Assertion Services (il peut y en avoir plusieurs) BPMN M2.2 «Suppression de règles d accès» L objectif du processus est d effacer les droits d accès à une ressource (règles d accès). 54/104

55 Figure 26: processus M2.2 «Suppresion des règles d accès» Parties impliquées: Niveau législatif IAM: définit et actualise régulièrement les directives concernant l administration des accès; Ces directives peuvent comporter, entre autres, des exigences spécifiques ou techniques concernant la mise en œuvre du processus. Responsable des ressources: administre les ressources selon les directives édictées au niveau législatif. Requérant: Demande la suppression des règles d accès à une ressource. Claim Provider: administre et exploite les Claim Assertion Services (il peut y en avoir plusieurs). 55/104

56 M3: Claims Selon la définition du chapitre 4.9, les Claims sont des «affirmations» fondées concernant un sujet ou une ressource. Il s agit de décrire très précisément le processus permettant de contrôler ces affirmations (p. ex., dans le contexte SuisseID, au moyen de la présentation d un document officiel au guichet d enregistrement). Dans l environnement IAM, on parle souvent de flux d autorisations destinés, p. ex., à attribuer à un collaborateur les «droits» nécessaires à l accomplissement des tâches qui lui sont attribuées. Il s agit en fait d un processus d assignation de Claims. Dans cet exemple, un requérant présente ainsi une demande d attribution d un nouveau rôle à un sujet. La requête devra ensuite être transmise pour approbation à un organisme autorisé. Après autorisation, le rôle requis peut alors être attribué au collaborateur (sujet) concerné qui disposera dès lors du Claim correspondant. Les attributs demandés/proposés lors de l enregistrement peuvent être mémorisés dans l identité numérique. L Identity Provider peut également se transformer en Claim Provider dans la mesure où il met ces attributs à disposition par l intermédiaire d un Claim Assertion Service. Etant donné que selon les directives concernant le processus d enregistrement (SCSE) les indications doivent être contrôlées au moment de l enregistrement, elles sont considérées, lors l enregistrement, comme étant certifiées. Les Claims peuvent généralement également être administrés par un Claim Provider et être mis à disposition de l utilisateur au moyen d un Claim Assertion Service CAS (voir 4.13 pour ce qui concerne SuisseID ou 4.14 pour OASIS) BPMN M3 «Claim Management» Les catégories de processus du Claim Management sont représentées ci-dessous. Le Claim Provider doit en tous les cas être en mesure de pouvoir interroger l Identity Provider afin d obtenir des informations concernant l identité concernée (p. ex vérification de l identité numérique). Figure 27: processus M3 «Claim Management» 56/104

57 Parties impliquées: Claim Provider: constitue l interface/service au niveau de la définition/élaboration, modification, suppression ou interrogation de Claims. Niveau exécutif IAM: représente l IAM pour lequel le Claim Provider offre ses services, comme p. ex. l élaboration de nouveau Claims ou l interrogation de Claims existants. Voir également à ce propos M2.1 «Assignation des règles d accès» ou R1 «Access Control». Identity Provider: fournit au Claim Provider les informations nécessaires relatives à l identité numérique concernée M4: Credentials Dans l environnement E-Government IAM, on trouve les Credentials suivants: certificat d identification: sert à identifier les sujets de manière sûre; certificat de signature: la signature du sujet. Les certificats suivants sont utilisés dans le contexte E-Government IAM: pour les sujets de la Confédération, des cantons et des communes: certificats de l infrastructure à clé publique (ICP) de l administration (autrefois administration SuisseID 12 ); pour les autres sujets: certificats SuisseID. Les Credentials sont générés sur le support (p. ex. Smartcard) d identité (clé privée et clé publique). La clé officielle inhérente aux Credentials est enregistrée dans le Directory de l Identity Provider qui contient l identité numérique du sujet. Le support d identité est remis au sujet BPMN M4 «Credentials Management» Les liens de communication sommaires du Credential Managements sont représentés ci-dessous. La plupart du temps, il est fait appel aux services du Credential Managements dans le cadre des processus de la gestion de l identité. Ceux-ci sont réalisés par l Identity Provider. 12 Titre de travail actuel 57/104

58 Figure 28: processus M4 «Credential Management» Parties impliquées: Credential Provider: constitue l interface/service au niveau de l élaboration et de la suppression de Credentials. Identity Provider: utilisateur des services du Credential Provider. Le Credential Provider fournit les services nécessaires à l élaboration et, le cas échéant, à la révocation et à la suppression de Credentials Processus Runtime au niveau exécutif Le processus Access Control (y compris identification et autorisation) fait partie de cette catégorie. Runtime Processus exécutif R1: Access Control Authentification Autorisation Figure 29: processus Runtime au niveau exécutif R1: Access Control Le processus Access Control se compose de deux parties: identification; autorisation. 58/104

59 Cointrôle autorisation Contrôle Accès autorisé Il est représenté dans la Figure 30. ID 1 Intention d accès Access Control 8 Accès Ressource Sujet 2 7 Identity Provider 3 IdP Contrôle Identity Authentication Activités, erreurs, etc. Définis par propriétaire 4 Monitoring Claim Assertion Service CAS 5 Transmission Claims Autorisation Transmission règles d accès Accès autorisé si les Claims transmis correspondent aux règles d accès 6 Règles d accès Figure 30: processus Access Control 1. Le sujet annonce vouloir accéder à la ressource. 2. Le sujet est identifié au moyen de Credentials (Authentication Service: vérification des Credentials existants, p. ex. certificat numérique). 3. Pour autant que ce ne soit pas réalisable au niveau local, l identité numérique du sujet est vérifiée au moyen de l IdPs (Identity Providers). 4. L identification vérifie les autorisations accordées: 4a: les règles d accès à la ressources sont transmises et les Claims nécessaires sont générés; 4b: elles sont ensuite authentifiées par le CAS. 5. L accès est autorisé. 6. L accès a lieu. Remarques: les règles d accès à la ressource pourraient p. ex. être enregistrées dans un Directory; toute erreur survenant à chacune des étapes de la vérification (comme p. ex. des Credentials non valables ou des droits d accès non valables) entraîne une interruption immédiate du déroulement du processus. Les annonces d erreurs sont enregistrées dans un procès-verbal (Monitoring). 59/104

60 BPMN R1 «Access Control» L objectif du processus Access Control est de faire en sorte de contrôler et de garantir le respect des règles qui définissent les possibilités d accès d un sujet à une ressource donnée. Figure 31: processus R1 «Access-Control» Parties impliquées: Niveau législatif IAM: définit et actualise régulièrement les directives. Ces directives peuvent comporter, entre autres, des exigences spécifiques ou techniques concernant la mise en œuvre du processus. Access Control Service: coordonne la requête d accès aux ressources; garantit le respect des règles d accès à la ressource. Pour cela, l Access Control Service fait appel au service d identification et au service d autorisation. 60/104

61 Authentication Service: vérifie si le sujet est bien celui qu il prétend être. Pour la vérification de l identité numérique, il fait appel, le cas échéant, à l Identity Provider (au cas où la vérification n est pas réalisable au niveau local). Authorization Service: vérifie si le sujet a le droit d accéder à la ressource. Pour la vérification des Claims, il fait appel, le cas échéant, au Claim Provider (au cas où la vérification n est pas réalisable au niveau local). Sujet: le sujet est un acteur qui accède ou qui souhaite accéder à une ressource. Il peut s agir d une personne physique ou morale mais également d une machine/d un système. Identity Provider: en vérifiant l identité numérique, il apporte son soutien à l Authentication Service dans le cadre de l identification du sujet. Claim Provider: en vérifiant les Claims en cas de besoin, il apporte son soutien à l Authorization Service dans le cadre de l identification du sujet. 61/104

62 7. Architecture de l information H Architecture Change Management Prelim: Framework And Principles A Architecture Vision B Business Architecture Le présent chapitre correspond à la partie «Architecture de l information, phase Architecture du système d information» (ADM phase C) du TOGAF. La partie «Architecture de l application» sera traitée en tant que telle au chapitre «Approches de solutions» (voir chapitre 8). G Implementation Governance Requirements C Information System Arch. L attention est ici focalisée sur: F Migration Planning E Opportunities and Solutions D Technology Arch. le métamodèle IAM; l infrastructure IAM (administration, services); les domaines et leurs interconnexions; les modèles d Access Control. Ces différents points mettent en évidence les axes principaux de quelques-unes des techniques et des standards les plus importants de l environnement IAM, le but n étant toutefois pas de traiter ces thèmes de façon exhaustive. Il est à noter qu il sera souvent fait référence aux chapitres précédents, et notamment au chapitre 6 qui décrit les processus et les déroulements Métamodèle IAM La Figure 32 illustre le métamodèle d information (objets d information et leurs interconnexions) d une identité numérique: Sujet 0..n possède accède à titre de Ressource a Credential 0..n possède 1..n Identité numérique satisfait à0..n 0..n Claim utilise Règle d accès 0..n a un Identifiant 1 Domaine a confiance (Trust) 0..n Figure 32:métamodèle d information IAM d une identité numérique 62/104

63 Les sujets et les ressources constituent des objets réels situés à l extérieur d un domaine. L identité numérique du sujet existe à l intérieur du domaine. Une ressource peut correspondre exactement à un sujet. Les ressources ont 0..n règles d accès. Celles-ci peuvent être génériques ou se référer au domaine (raison pour laquelle l objet d information «Règle d accès» se situe à la limite du domaine). Remarque: les règles d accès sont souvent désignées par l acronyme ACL (Access Control List). Le domaine fait confiance à 0..n autres domaines et par conséquent aux identités numériques répertoriées dans ce(s) domaine(s). A l intérieur du domaine: un sujet possède 1..n identité (idéalement: une seule identité par domaine); l identité numérique possède un identifiant (nom univoque); une identité numérique possède 1..n Credential(s); une identité numérique satisfait à 0..n Claim(s); les règles d accès utilisent 0..n Claim(s). La définition formelle du métamodèle est élaborée dans le cadre du concept de mise en œuvre et ne fait pas partie du présent document Infrastructure IAM La clé du succès de l utilisation d identités numériques réside dans une structure IAM efficace et efficiente tant pour les sujets, pour les ressources (Identity Management) que pour leurs Claims (Claim Management 13, Attribut Management). Cette infrastructure se compose d une couche administrative, d un répertoire approprié et des services destinés à leur utilisation. L infrastructure met en œuvre le processus opérationnel décrit au chapitre 6. La plupart du temps, dans les environnements IT actuels, il manque une telle infrastructure IAM. L administration des sujets (utilisateurs) et de leur Claims (autorisation) est normalement réalisée de façon décentralisée et répartie entre différentes plateformes de systèmes et d applications. Cela signifie que les ressources doivent être administrées séparément, au moyen d un système de gestion de la configuration qui a rarement un lien avec l IAM Répertoire IAM En principe, les sujets ou les ressources ainsi que leurs attributs peuvent être enregistrés en tant qu objets dans n importe quelle base de données moderne pour être ensuite mis à disposition. Le Directory Service, également appelé service d indexation, est une structure largement répandue, qui permet d enregistre des données dans une structure 13 Claim Management quelquefois également appelé Access Management. 63/104

64 strictement hiérarchisée. Naguère, les implémentations étaient principalement basées sur le standard X.500 de l ITU-T 14. A l heure actuelle, l accès aux services d indexation a généralement lieu au moyen du protocole LDAPv3 15. Dans ce contexte, on parle également souvent de répertoires LDAP et de leur structure hiérarchisée des données, les DIT (Directory Information Tree). Quant aux registres, ce sont également des répertoires, ainsi que cela a déjà été expliqué au chapitre Dans un répertoire LDAP, l entrée d un sujet pourrait ressembler à la Figure 33: dn: uid=mam, ou=subject, ou=security, ou=section, c=ch, o=awk cn: Markus Meier givenname: Markus sn: Meier Telephonenumber: mail: Figure 33: représentation symbolique de l indexation d un sujet dans un répertoire La Figure 34 indique de façon schématisée la possible structure hiérarchique d un DIT: dn: c=ch, o=awk objectclass: top objectclass: organization o: AWK dn: ou=section, c=ch, o=awk objectclass: top objectclass: organizationalunit ou: section dn: ou=role, c=ch, o=awk objectclass: top objectclass: organizationalunit ou: role dn: ou=ressoure, c=ch, o=awk objectclass: top objectclass: organizationalunit ou: ressource dn: ou=subject, ou=section, c=ch, o=awk objectclass: top objectclass: organizationalunit ou: subject dn: uid=pcons, ou=role, c=ch, o=awk role: principal consultant dn: ou=services, ou=ressoure, c=ch, o=awk objectclass: top objectclass: organizationalunit ou: services dn: uid=mam, ou=subject, ou=section, c=ch, o=awk cn: Markus Meier givenname: Markus sn: Meier Telephonenumber: mail: dn: uid=servicex, ou=services, ou=ressource, c=ch, o=awk ACL: aaaccclll dn: uid=mam, ou=digid, ou=subject, ou=section, c=ch, o=awk identifikator: credentials: claim1: xxx claim2: uid=pcons Figure 34: Directory Information Tree (DIT) 14 X.500 correspond ISO/IEC , pour davantage de détails, voir: 15 LDAP: Lightweight Directory Access Protocol spécifié à l adresse (et autres sites) 64/104

65 Dans cet exemple, la racine du DIT est constituée par l entrée au registre de l entreprise AWK. Au deuxième niveau, on trouve les différentes catégories intégrées dans l arborescence du Directory: ou=section: tous les collaborateurs (sujets) avec leurs identités numériques se trouvent dans cette section d arborescence; ou=role: tous les rôles de l entreprise AWK (p. ex. Consultant, Principal Consultant, ) se trouvent dans cette section d arborescence; ou=ressource: les ressources (p. ex. les services et les règles d accès) se trouvent dans cette section d arborescence. Propriétés des répertoires LDAP: ils sont optimisés pour la lecture afin de disposer le plus rapidement et le plus efficacement possible des informations d identification et d authentification durant la connexion établie; ils peuvent être répartis relativement facilement sur différents sites, ce qui est également valable pour l administration déléguée, p. ex. d une section d arborescence; le large emploi qui en est fait au niveau informatique (il s agit de facto d un standard industriel) constitue un avantage. En effet, la plupart des produits qui sont actuellement sur le marché et qui permettent d administrer des utilisateurs peuvent être interconnectés via une interface LDAP; tout répertoire LDAP mis en place avec une banque de données relationnelles sous-jacente souffre de certaines limitations des fonctionnalités normalement existantes au niveau des banques de données relationnelles. Ainsi, p. ex., un protocole LDAP ne peut pas prendre en charge d interrogations de type «Join» (produit cartésien); le LDAP peut être utilisé dans un environnement Webservices, p. ex. par l intermédiaire du DSML (Directory Service Markup Language); les répertoires LDAP peuvent également être interrogés via des interfaces programmées, telles que p. ex.net ou Java (méthodes issues de la Class Library JNDI) Interconnexion de répertoires Les répertoires peuvent être interconnectés en fonction des besoins, ce qui permet de réaliser une approche centralisée de l administration à l intérieur d un domaine (voir la proposition formulée à ce sujet au chapitre 8.1). Il existe deux approches différentes permettant d interconnecter des répertoires: Metadirectory: dans cette approche, les entrées figurant dans différents répertoires interconnectés sont mises à disposition, au moyen de métadonnées, dans un répertoire unifié. L opération est généralement effectuée en copiant et en interconnectant de manière appropriée les répertoires intégrés. 65/104

66 Virtual Directory: il s agit d un tout nouveau concept qui s appuie sur le concept de métarépertoire mais qui n offre toutefois qu une vision unique sur différents répertoires. Dans ce cas, les répertoires intégrés ne sont pas copiés dans un métarépertoire. La Figure 35 illustre de façon schématique la fonction d interconnexion telle qu elle est disponible dans les métarépertoires ou dans les répertoires virtuels: Sujet AD Nom Prénom Tél Fax NoPerso Sujet SAP Nom Prénom DeuxièmePrénom Téléphone Fax NuméroPerso epost IAM Sujet IAM Nom Prénom Téléphone Fax NuméroPerso Figure 35: interconnexion de répertoires Les différents répertoires sont interconnectés, comme par exemple l AD et le SAP dans la Figure 35. Les règles d interconnexion sont en outre définies afin, p. ex. de reproduire la description d attribut «FirstName» SAP ou «Prename» AD d un sujet dans la description d attribut «Prénom» Répertoire Réplication Dans un environnement IAM, la disponibilité, la performance, la fiabilité et la redondance constituent d importantes exigences. Ces différentes propriétés peuvent être obtenues par une réplication appropriée des répertoires. A l heure actuelle, toutes les applications utilisées dans le contexte IAM comprennent des techniques de réplication efficientes. Par contre, il existe, dans ce domaine, une grande liberté en ce qui concerne le choix de la configuration la plus adéquate, qui peut de ce fait être définie dans le cadre du concept IAM détaillé. A ce niveau, il s agit de tenir compte, entre autres, de l endroit d où est effecutée la lecture des répertoires ou de l endroit d où il est principalement procédé aux mutations (écriture). Actuellement, on ne parle pratiquement plus de Master Directory mais plutôt de SupplierDirectorie,s dans la mesure où les produits sont maintenant prévus pour faire en sorte que les données puissent également être mises à jour à partir de plusieurs nœuds. Dans ce con- 66/104

67 texte, les répertoires dont l accès ne peut se faire qu en mode lecture sont désignés sous le terme de «Consumer» Le Service Provider IAM et ses services Comme expliqué au chapitre avec différentes méthodes et différents clients, en règle générale, l accès direct à un répertoire implanté dans un domaine est effectué par l intermédiaire de LDAP. Il s agirait, dans ce contexte, de recherche d autres méthodes permettant de mettre à disposition, en mode interdomaines, les informations des répertoires. Dans le monde numérique, tout sujet qui doit pouvoir être identifié doit être en possession d une identité numérique émise par un Identity Provider. L identité numérique contient des Credentials, qui permettent p. ex. aux sujets de s identifier. Comme décrit au chapitre 4.9, les sujets sont également en mesure d accéder à leurs Claims ou à leurs Claimsets grâce à leur identité numérique. Les Claims sont p. ex. mis à disposition par le CAS (Claim Assertion Service dans le contexte SuisseID voir chapitre 4.13) ou par le STS (Security Token Service selon la terminologie OASIS voir chapitre 4.14) Identity Provider L Identity Provider établit des identités numériques à l attention des sujets. L Identity Provider d une entreprise peut être, p. ex., l organisation de l entreprise. L Identity Provider enregistre les sujets, élabore et administre leurs identités numériques et les distribue en fonction des directives internes. Dans l environnement fédéré de l E-Government, les identités numériques peuvent typiquement être établies par différents Identity Providers. Par exemple, dans le contexte SuisseID, il existe les Identity Providers Quo Vadis Trustlink Schweiz AG et La Poste Suisse/SwissSign AG, qui sont des fournisseurs d identité tant pour des entreprises que pour des privés. Pour l instant, l Office fédéral de l informatique et de la télécommunication OFIT assure les besoins de l administration en matière de SuisseID. Les Identity Providers fonctionnent sur la base de directives précises qui doivent être formellement confirmées par un office de révision. Les Identity Providers basés sur des certificats fournissent les services suivants: service de répertoires centralisés: les certificats qui doivent être publiés sont rendus publics dans un répertoire centralisé et peuvent être consultés par LDAP; renseignements sur le statut des certificats: le statut des certificats doit pouvoir être consulté au moyen du protocole OCSP (Online Certificate Status Protocol); informations générales: les Identity Providers doivent avoir un site web sur lequel ils publient des informations générales sur leurs services de certification. 67/104

68 Credential Provider Selon la définition du chapitre 4.12, les Credentials sont des moyens auxiliaires qui permettent de vérifier l identité numérique d un sujet. Les Credential Providers émettent des Credentials qu ils transmettent de manière sécurisée au sujet concerné. Dans le cas le plus simple, un Credential est un mot de passe. Toutefois, le contexte E- Government IAM préconise une identification à double facteur, qui est actuellement réalisée au moyen d un certificat d identification. Aujourd hui, avec l AdminPKI de l OFIT, différents types de certificats sont utilisés dans l administration 16. Selon la décision que le Conseil fédéral a prise en été 2010, tous ces certificats devraient être regroupé sous l égide de l administration de SuisseID. Dans le contexte SuisseID, le certificat d identification est assigné au moyen d un Hardware Security Token (p. ex. Smartcard, clé USB). La paire de clés (privée et publique) est directement générée sur le HW Security Token. Normalement, la clé privée ne peut pas être lue par le Security Token, ce qui permet de faire en sorte que le Security Token soit impérativement considérée comme un facteur «propriétaire» pour pouvoir s identifier avec succès. La clé publique, quant à elle, est mémorisée chez le Credential Provider (il s agit généralement de l Identity Provider) en tant qu identité numérique. En principe, lors de la première utilisation, les Credentials doivent être «personnalisés». Dans le cas des mots de passe, cela signifie que, lors de la première utilisation, l utilisateur doit remplacer le mot de passe initialment fourni par un autre mot de passe, conforme à la règle établie. Pour les HW Security Token, le mot de passe initialement utilisé pour accéder au support ainsi que le mot de passe pour l utilisation du certificat d identification doivent être personnalisés selon les directives établies Claim Provider et Claim Assertion Service Selon la définition terminologique du chapitre 4.9, les Claims sont des attributs certifiés pour un sujet donné (p. ex. le sujet est médecin, il est âgé de 18 ans ou il fait partie des collaborateurs d une entreprise). Les Claim Providers sont des organisations qui sont en mesure de mettre à disposition, sous forme de Claim Assertion Service (voir 4.13), des Claims établis selon les règles d OASIS ou un Security Token Service (voir 4.14). Les informations destinées à établir une identité numérique peuvent être récoltées de différentes façons. Par exemple, dans l environnement SuisseID, les informations utilisées pour établir l identité d un sujet requérant sont les mêmes que celles qui sont enregistrées lors de l établissement des documents d identité personnels. Les informa- 16 Pour davantage de détails, voir: 68/104

69 tions concernant un sujet peuvent être consultées par les Claim Service Providers (les quatre mêmes entités que les Identity Providers) sous forme de Claims Claims dépendant du contexte Un sujet qui dispose d une seule identité numérique peut également, selon les circonstances, avoir plusieurs Claims différents en fonction du contexte. Les Claims des différents contextes doivent être administrés et consultés de manière totalement indépendante les uns des autres. Exemple: le sujet X dispose d une unique identité numérique dans l IAM de son entreprise; X est toutefois au bénéfice de deux contrats de travail différents (p. ex. 20% comme responsable de projet et 80% en tant que chargé de sécurité) en fonction desquels il possède différents Claims, respectivement des droits d accès différenciés; à la fin de son mandat de «responsable de projet», tous les Claims/droits d accès relatifs à ce mandat doivent être supprimés; oar contre, tous les Claims/droits d accès relatifs à sa fonction de «chargé de sécurité» doivent être conservés Administration IAM Les tâches suivantes font p. ex. partie de l administration IAM: installation/configuration du serveur sur lequel se trouve le répertoire IAM; installation/configuration du répertoire proprement dit; gestion du contenu du répertoire; implémentation des directives en matière de sécurité édictées dans le cadre de la politique de sécurité appliquée au répertoire concerné; gestion des réplications (copies du répertoire); gestion des Referrals (référence renvoyant à des répertoires annexes); gestion des répertoires virtuels (accès unifié à différents répertoires); gestion de l administration des accès/règles d accès des entrées; gestion des Claim Services (Security Token Services) pour les Providers considérés eux-mêmes comme étant des Identity Providers ou des Claim Provider; mise en œuvre de la politique d audit selon les directives en matière de sécurité (p. ex. réglage du Loglevel, détermination du Logfilecontainer); Performance Management et monitorage. Généralement, les applications IAM actuelles comprennent une interface de gestion permettant d activer ces fonctions de façon interactive et graphique. Il est à noter que 69/104

70 les fonctions de gestion peuvent également être pilotées par de simples interfaces (p. ex. saisie d une commande fonction décrite au chapitre 7.2.1) ou au moyen d interfaces de programmation (p. ex. avec les méthodes der Java Class Library JNDI) Domaines Le domaine, dont le terme a été expliqué au chapitre 4.6, contient un espace de noms défini. Le domaine comporte un niveau législatif qui, dans le contexte IAM, permet de définir les règles applicables (GRC Governance, Riskmanagement, Compliance, voir chapitre 6.1) et un niveau exécutif qui sert, quant à lui, à exploiter l IAM ainsi que ses processus administratifs (voir chapitre 6.3) et ses processus Run-time (voir chapitre 6.4) Codes et directives inhérents à un domaine Chaque domaine comporte des codes et des directives spécifiques qui ont été définis au niveau législatif de l IAM et dont l application doit être contrôlée (voir 6.2 Processus au niveau législatif). Dans le domaine, la signification et la gestion des identités numériques doivent être clairement réglées. L élaboration de l identités numérique et des identifiant d un sujet ou d une ressource doit également être claire; les processus nécessaires à la gestion des identités doivent être clairement définis; il s agit de régler clairement qui définit les règles d accès aux ressources et de quelle manière; il s agit de régler clairement qui définit les Claims et comment ceux-ci sont référencés. Dans le domaine, il faut également régler clairement la manière dont les sujets ou les ressources sont identifiés (savoir quels Credentials il faut utiliser) et comment ils sont identifiés (la manière dont les Credentials sont vérifiés). Dans le domaine, il faut également définir: la manière dont l identification peut être vérifiée avant tout accès aux ressources (savoir si les Claims présentés satisfont aux exigences d accès aux ressources). L exploitation du domaine doit permette de garantir la disponibilité de chacun des services. 70/104

71 Exigences relatives aux domaines fédérés Lorsque les sujets d un domaine accèdent aux ressources d autres domaines, on parle de domaines fédérés. Cette approche génère des exigences supplémentaires, comme l illustre l exemple de la Figure 36. Sujet Ressource Sujet Ressource Règle d accès f Règle d accès Credential Identifiant Identité numérique Domaine A Claim d c e b Credential Identifiant Identité numérique Domaine B Claim g a Figure 36: exigences relatives au trafic entre deux domaines a) Codes, standards et relations de confiance entre les domaines: quels sont les standards de sécurité et les codes valables entre les deux domaines (accord formel de confiance réciproque)? b) Mapping de l identité: comment le domaine B doit-il gérer les identités numériques du domaine A? c) Identifiant: dans le domaine B, quels sont les identifiants qui doivent être utilisés pour traiter les identités numériques du domaine? d) Credentials: comment les sujets ou les ressources de deux domaines étrangers peuvent-ils s identifier (quels Credentials utilisent-ils)? e) Contrôle des Credentials: comment l authentification peut-elle être vérifiée (comment les Credentials peuvent-ils être contrôlés)? f) Règles d accès: quelles sont les règles d accès applicables aux identités numériques provenant de domaines étrangers et où celles-ci sont-elles administrées? g) Claims: quels Claims (rôles) sont-ils échangés (utilisés) et respectivement comment le contrôle de l accès d identités numériques provenant de domaines étrangers a-t-il lieu (vérification des Claims nécessaire à l accès)? Lorsqu il s agit de mettre en œuvre des identités numériques accédant à des domaines étrangers, tous ces points doivent être clarifiés Codes, standards et relations de confiance entre les domaines En cas d interaction entre différents domaines, la confiance réciproque joue un rôle crucial. Cette confiance peut être instaurée si toutes les parties agissent avec une grande transparence. Les partenaires doivent comprendre quels sont les codes et les 71/104

72 standards qui doivent être appliqués dans les différents domaines concernés. La confiance réciproque peut p. ex. être instaurée au moyen de l établissement d un classement indépendant ou librement choisi en différents niveaux définis de sécurité. Dans toute fédération, la garantie de la sécurité dépend toujours de la sécurité assurée par le maillon le plus faible de la chaîne. En matière de confiance au niveau de l identification et de l autorisation pour l accès d identités numériques à différents domaines, l approche européenne STORK (voir [8]) parle de QAA Quality Authentication Assurance). STORK prévoit quatre niveaux de sécurité: QAA Level Description 1 Aucune sécurité ou sécurité minimale 2 Sécurité faible 3 Sécurité importante 4 Sécurité élevé D un point de vue global, la confiance attribuée aux méthodes d identification et d authentification de l identité n est qu un aspect partiel de la confiance réciproque que peuvent s accorder des domaines, car elle ne prend aucunement en considération la sécurité IT fondamentale qui prévaut toujours dans ce domaine. De ce fait, l instauration de la confiance découle également d autres caractéristiques relatives à la sécurité (p. ex. de la façon dont les identités numériques sont autorisées) qui ne seront toutefois pas décrites dans le cade du présent document spécifiquement consacré à l IAM. Au niveau international, il existe différentes approches du sujet, comme p. ex. celles décrites dans le document «Cross Domain Community Roadmap» de l UCDMO [7]. Le Department of Defense 17 (DoD) a définit des critères qui sont surtout spécifiques aux codes, à la responsabilité, à la sécurité et à la documentation. Les systèmes sont répartis en quatre catégories allant de D (exigences minimales) à A (sécurité vérifiée) E-Government Suisse: esecurity Level résultant Dans le cadre d E-Government Suisse, l approche devrait se baser sur le modèle STORK déjà évoqué et qui comporte également quatre niveaux de sécurité définis dans le domaine de l identité numérique de sujets (E-Government- Security-Level): Level 1: Il s agit du niveau de sécurité le plus faible de l environnement E-Government Suisse. Les identités numériques n y sont pas vérifiées. Level 2: Ce niveau est conçu pour traiter les identités numériques dont l utilisation présente un potentiel de dégâts minimal. Il est appliqué par exemple dans le cas d achats de billets ou de commandes de /104

73 formulaires pour lesquels l utilisateur, qui dispose d une adresse de courriel valable, doit s enregistrer au moyen de celle-ci avant de pouvoir conclure une transaction qui lui sera p. ex. facturée. Level 3: Ce niveau de sécurité est appliqué aux transactions effectuées avec des identités numériques dont l utilisation est susceptible de présenter un potentiel de dégâts plus important. Font p. ex. partie de cette catégorie les transactions effectuée par Internet au moyen des cartes de crédit usuelles, naturellement au moyen d une liaison SSL sécurisée. Level 4: A ce niveau de sécurité, qui est le plus élevé, seules des transactions effectuées au moyen d identités numériques formellement validées sont possibles, p. ex. par les sujets (utilisateurs) possédant une SuisseID. Remarque: que ce soit en Suisse ou dans l Union européenne, ces Security Level doivent encore être définis de façon précise et standardisée. Les critères de classification des différents niveaux de sécurité doivent, eux aussi, encore être précisément définis. Il est aussi nécessaire de désigner une instance de certification indépendante qui puisse catégoriser les domaines en fonction des directives édictées. Une telle catégorisation des Security Levels simplifie la prise des mesures nécessaires à assurer la sécurité du trafic interdomaines. Il serait ainsi envisageable, par exemple, que les sujets en possession d une identité numérique provenant d un domaine de niveau 4 puissent être identifiés comme étant sûrs dans d autres domaines également de niveau Mapping de l identité L un des défis particuliers qui se pose à toute fédération de domaines est le mapping de l identité numérique des sujets. En effet, en général, les mêmes sujets disposent de différentes identités numériques déjà valables dans différents domaines (développement historique, aucune approche concertée). A l heure actuelle, cette situation ne constitue pas une exception mais plutôt un état de fait Illustration de l exigence Ces exigences peuvent être illustrées au moyen de deux exemples concrets. Exemple 1: entreprise suisse active au niveau international: Situation: Entreprise suisse active au niveau international avec des organisations IT régionales et autonomes aux USA, en Grande-Bretagne et au Japon. Les différentes régions disposent déjà de leur propre IAM. 73/104

74 Objectif: Il s agit de mettre en place un IAM commun auprès duquel l ensemble des collaboratrices pourront bénéficier d une identité numérique unifiée. Exigences: Consolidation des identités numériques: Plusieurs collaborateurs travaillent avec leurs moyens informatiques dans les différentes régions. Ils disposent déjà, dans ces régions, de leur propre identité numérique locale, établie selon les prescriptions régionales. Comment est-il possible de consolider ces différentes identités numériques? Rôles/fonctions, identification, autorisation, Access Control: Etant donné l autonomie régionale en matière d élaboration des droits d accès, il n existe aucun concept global en matière d autorisation. Comment faire pour qu un directeur suisse puisse, lorsqu il est au Japon, se connecter localement au réseau de l entreprise et accéder à ses ressources, telles que courriel, Internet ou imprimante locale? Exemple 2: collaboration entre domaines administratifs: Situation: Dans un canton, on trouve différents domaines administratifs dont chacun dispose de sa propre infrastructure informatique IAM, p. ex. administration cantonale, communes, domaine de la santé santé (hôpitaux). Objectif visé: Les sujets devraient pouvoir être identifiés de façon sûre au moyen d une identité numérique et ceci indépendamment du rôle qui leur est attribué (p. ex. en tant qu employé de l administration cantonale, d une commune ou du système de la santé). De façon analogue, il devrait être possible de faire en sorte que, p. ex. un habitant du canton puisse être identifié de façon sûre en tant que patient d un hôpital appartenant au système de la santé. Ce citoyen pourrait par ailleurs être également employé dans l administration cantonale ou communale. Exigences: Consolidation des identités numériques: Les collaborateurs actifs dans différents secteurs disposent souvent déjà d une identité numérique enregistrée dans différents domaines, identité qui n est toutefois pas établie selon des critères unifiés. Il en va de même pour les citoyens ou les patients du système de la santé. Rôles/fonctions, identification, autorisation, Access Control: Il n existe aucune approche uniformisée des rôles/fonctions dans les différents domaines. Il en va de même pour les méthodes d identification ainsi que pour les processus d Access Control qui ne sont pas unifiés. 74/104

75 Solution possible Pour que les sujets d un domaine puissent s identifier de façon univoque, ils doivent justifier leur identité au domaine concerné. L identification ne peut avoir lieu qu à condition que l identité des sujets ait été enregistrée à titre d identité numérique dans un des répertoires de l Identity Provider. Ce n est qu ainsi qu il est possible de procéder à une identification au moyen de l identité numérique. Dans les exemples susmentionnés (chapitre ), les sujets possèdent déjà une identité numérique. Dans le premier cas (entreprise suisse active au niveau international), ces identités existent déjà dans les différents centres régionaux. Dans le deuxième cas (collaboration de domaines administratifs différents), ces identités existent dans les domaines locaux. Il existe différentes possibilités de satisfaire à ces exigences: établissement d une convention sur les identités numériques: les partenaires concernés se mettent d accord sur un concept d établissement commun de l identité numérique, ce qui requiert la désignation d un Identity Provider 18 (éventuellement propre à l un des deux partenaires). Dans ce cas, l ensemble des identités numériques de tous les environnements existants (de chaque répertoire) devraient être complétées avec la nouvelle identité numérique du nouveau Provider désigné. Pour les nouveaux sujets, seule la nouvelle identité numérique commune serait utilisée; identités numériques multiples: les partenaires concernés s accordent pour que les sujets issus d un domaine étranger puissent être en mesure d enregistrer leur identité numérique existante également au niveau du domaine partenaire, ce qui implique que le répertoire comportant l enregistrement du sujet doit être complété avec une autre identité numérique. Cela signifie également la plupart du temps (mais pas impérativement) que les deux domaines ont un Identity Provider différent. En fait, ces deux approches ne diffèrent pas tellement, puisque toutes deux requièrent la mise en œuvre d un processus d enregistrement et de consolidation au niveau des répertoires locaux de l administration des identités. Le processus d enregistrement constitue une exigence particulière pour les sujets qui sont déjà référencés avec différentes identités numériques dans les domaines concernés. Il n existe aucune recette miracle pour appliquer ce processus de synchronisation. En tous les cas, les services de consolidation peuvent contribuer à identifier les identités «similaires». Il est ainsi très probable de pouvoir identifier de façon univoque les sujets (citoyens suisses) au moyen de leur nom complet, de leur date de naissance et de leur lieu d origine. Un processus de consolidation exige toujours une libération vérifiable provenant des responsables de la consolidation des domaines concernés. Il existe toutefois encore une autre possibilité qui ne requiert aucun enregistrement local: 18 Théoriquement, il serait également possible d unifier plusieurs Identity Providers. 75/104

76 confiance accordée à des identités numériques définies: un domaine peut p. ex. décréter que les identités numériques d un Identity Provider donné sont fiables sans les enregistrer lui-même dans un IAM (aucun enregistrement local). Pour que l autorisation puisse être vérifiée, il est indispensable que les Claims du sujet concerné soient connus ou puissent être interrogés, comme c est le cas dans le cadre du processus Access Control expliqué de façon schématique au chapitre Dans ce cas, les approches suivantes peuvent être choisies: Claims Assertion Service (CAS) commun dans le cadre de la fédération: les partenaires s accordent sur un CAS qui soit indépendant des domaines et qui mettra à disposition les Claims des sujets sous la forme souhaitée. Le CAS pourrait être exploité par tous les partenaires de la fédération de domaines afin, p. ex., de pouvoir mettre en commun leur expérience des fonctions ou des rôles des sujets; entretien de Claims locaux: lors de l enregistrement, les attributs d autorisation seront p. ex. saisis dans l IAM local afin de pouvoir être consultés et évalués par le biais de requêtes IAM «locales». Remarque: l utilisation des identités des sujets dans différents domaines est également appelée «Account Linking» (voir chapitre 8.7.2) Identifiants Credentials Dans le domaine des identités numériques, les identifiants, introduits au chapitre 4.4, constituent des auxiliaires qui permettent, p. ex., de trouver plus facilement des identités numériques ou de les comparer entre elles. Selon les domaines, les identités numériques peuvent avoir différents identifiants, voire même ne pas en avoir du tout. Le numéro de sécurité sociale est souvent utilisé comme identifiant ce qui, du point de vue de la protection des données, constitue toutefois une utilisation non conforme et, de ce fait, interdite. Les identifiants font partie intégrante de l identité numérique, comme expliqué dans le cadre du chapitre 7.1 consacré au modèle d information. Ils ne sont jamais traités séparément. Comme expliqué au chapitre 7.3.4, leur intégration à d autres domaines a toujours lieu avec l identité numérique du sujet. Remarque: les identifiants constituent un important moyen auxiliaire dans le cas où les identités numériques des sujets sont utilisées dans différents domaines (voir également «Account Linking» au chapitre 8.7.2). Les Credentials de l identité numérique d un sujet permettent d identifier celle-ci de façon univoque (voir chapitre 4.12). L authentification est effectuée à l aide des Credentials émis par le Credential Provider (voir chapitre ). 76/104

77 Tous comme les identifiants, les Credentials font partie intégrante de l identité numérique (voir le chapitre 7.1 consacré au modèle d information). Ils ne sont jamais traités séparémment. Leur intégration à d autres domaines a toujours lieu avec l identité numérique du sujet Règles d accès Claims Les règles d accès aux ressources sont définies par les responsables des ressources concernées (voir terminologie au chapitre 4.21 et métamodèle IAM au chapitre 7.1). Etant donné que l administration des ressources n est pas régie de façon aussi uniformisée que celle des sujets, les règles d accès aux ressources peuvent également être réparties en différents endroits (p. ex. dans un répertoire IAM ou dans un répertoire de gestion de la configuration). A l heure actuelle, il arrive souvent que les règles d accès soient encore programmées directement dans les programmes d exploitation, ce qui constitue une violation des Good Practices en matière de programmation. La présente architecture de la solution propose d administrer les ressources (et les règles d accès y relatives) directement dans un répertoire IAM. Ce n est qu ainsi qu il est possible de garantir que les règles d accès soient mises à disposition de façon unifiée dans les domaines. Lorsqu une ressource constitue un sujet (voir Figure 22), comme c est le cas p. ex. lorsqu elle utilise une autre ressource, ce sont les règles d accès de la ressource cible qui sont appliquées. La ressource requérante dans ce cas considérée comme un sujet utilise ses propres Credentials pour s identifier et ses propres Claims pour son authentification. Aucune application des règles d accès n est nécessaire entre domaines. La responsabilité de la vérification de l autorisation est toujours du ressort des domaines cibles, respectivement des ressources et des propriétaires des ressources qui y sont enregistrées. Les Claims appartiennent à l identité numérique. Ils contiennent les propriétés certifiées du sujet (voir chapitre 4.9), telles que p. ex. son rôle ou sa fonction (voir chapitre 7.4). A l image des identifiants, les Claims font partie intégrante de l identité numérique, comme expliqué dans le cadre du chapitre 7.1 consacré au modèle d information. Ils ne sont jamais traités séparémment. Leur intégration à d autres domaines a toujours lieu avec l identité numérique du sujet concerné, comme expliqué au chapitre Modèles d Access Control Ainsi que l indique la lettre «A» de son acronyme, l IAM ne concerne pas seulement l Identity Management, mais également l Access Management. Il est donc approprié d aborder les différents modèles d Access Control de façon plus précise. 77/104

78 RBAC: Role Based Access Control: dans ce modèle, le contrôle de l autorisation d un sujet est basé sur son/ses rôle(s) ou sa/ses fonctions(s), c est-à-dire directement sur son identité. Le propriétaire de la ressource définit quels sont les rôles et quelles sont les fonctions inhérentes à ses ressources et de quelle façon il est possible d y avoir accès. ABAC: Attribute Based Access Control: l idée du contrôle d accès basé sur les attributs est de ne pas déterminer de façon statique les droits d accès des sujets aux ressources mais plutôt d exploiter de manière dynamique les propriétés ou attributs afin de définir les accès autorisés. En l occurrence, il peut s agir de propriétés générales telles que p. ex. la position de l utilisateur au sein de l entreprise mais également d attributs tels que l âge ou la solvabilité actuelle. Contrairement aux rôles définis de façon plutôt statique, les attributs peuvent être interrogés (et confirmés) par le Claim Assertion Provider de manière très dynamique et en temps réel. Le RBAC est une sorte de «Subset» de l ABAC. DAC: Discretionary Access Control: avec ce modèle, le contrôle de l autorisation du sujet est directement basé sur son identité, ce qui signifie que le propriétaire de la ressource définit individuellement pour chaque sujet, la façon dont celui-ci peut accéder à une ressource donnée. MAC: Mandatory Access Control: dans ce cas, le propriétaire de la ressource définit les propriétés nécessaires dont un sujet doit impérativement disposer pour pouvoir accéder à la ressource. On peut prendre pour exemple la classification de documents en catégories telles que «Public», «Confidentiel», «Secret» ce qui pourrait p. ex. signifier que seuls les sujets autorisés à lire les documents secrets ont accès à ces mêmes documents. Dans le contexte E-Government IAM, c est en principe le modèle RBAC ou le modèle ABAC qui sont appliqués. En cas de besoin, le modèle RBAC/ABAC peut être facilement complété avec n importe laquelle des propriétés du modèle MAC. Exemple: un portail dédié à la médecine offre des services auxquels tous les médecins peuvent accéder. Toutefois, certains de ces services sont spécialement protégés et seuls les administrateurs peuvent y accéder mais uniquement en mode local (c est-à-dire pas par Internet). La preuve qu un sujet est bel et bien médecin peut être établie via un Claim sur un registre confidentiel des médecins. Le fait de savoir si l accès au service a lieu par Internet ou par un utilisateur local est un filtre que le service doit développer par ses propres moyens (voir également à ce sujet WAYF au chapitre 8.7.3). Remarques: dans la présente architecture de la solution IAM, les rôles ainsi que les autres attributs d un sujet sont mis à disposition en tant que Claims (Claimsets) par un fournisseur de Claims; s il existe un IAM interne, les Claims d un sujet peuvent également être mis à disposition directement à partir du répertoire de cet IAM, p. ex. par l intermédiaire de LDAP. En principe, il ne s agit de rien d autre que d une requête identique à une demande de Claims effectuée auprès d un Claim Provider: 78/104

79 le développement de modèles de rôles systématiques pour un contexte donné constitue une exigence particulière qui est décisive en tant que telle mais également au niveau de la Governance requise. De manière empirique, on pourrait dire que «moins c est plus», ce qui signifie qu il faut se concentrer sur les axes principaux de la détermination des rôles. Pour pouvoir mettre en œuvre des modèles de rôles dans une entreprise ou dans une unité administrative, il faut souvent revoir les structures existantes afin de pouvoir en extrapoler les rôles (fonctions) appropriés. 79/104

80 8. Solutions possibles au niveau des structures interdomaines H Architecture Change Management Prelim: Framework And Principles A Architecture Vision B Business Architecture Dans le cadre de l E-Government IAM, il n existe aucune solution globale pouvant être appliquée à toutes les situations de façon identique. C est pourquoi, dans le présent document, les solutions IAM possibles évoquées sont principalement celles qui peuvent être appliquées à des fédérations, libres ou non, de domaines. G Implementation Governance F Migration Planning Requirements E Opportunities and Solutions C Information System Arch. D Technology Arch. Remarque sur la méthode utilisée: les solutions possibles proposées sont comprises comme étant une architecture possible de la solution au sens de la phase C du TOGAF ADM Architecture du système d information L IAM dans le cadre d un domaine Il s agit d implémenter, dans le domaine concerné et à l aide de l IAM, un Identity Management et un Access Management centralisés permettant d intégrer différents systèmes cibles, afin de permettre également de faire en sorte que les sujets (collaborateurs) ne doivent s identifier qu une seule fois (SSO Single Sign-On). Il s agit ici du cas le plus courant et d une situation qui prévaut actuellement dans de nombreuses entreprises ou dans de nombreux domaines administratifs. Avantages: Organisation, responsabilités et Governance claires Approche IAM centralisée et complète Efficacité et efficience élevées Inconvénients: Aucun soutien à la fédération Intégration exigeante pour les partenaires: les sujets d autres domaines doivent être p. ex. enregistrés séparément dans les IAM des domaines concernés Requiert une certaine flexibilité de la part des participants. Cela pourrait p. ex. signifier qu il faut attribuer de nouvelles identités numériques, de nouveaux noms d utilisateurs, etc. à tous les sujets. HR 5 Collaborateur Domaine SSO 1 Nouveau collab. ID Identity Provider Appl-1 Windows AD SAP andere Appl. 2 4 HR 3 IAM domaine Administration IAM IAM Directory 80/104

81 Figure 37: l IAM dans le cadre d un domaine Les différentes étapes de l enregistrement, de l établissement de l identité et de la répartition des identités numériques aux utilisateurs sont représentées à titre d exemple dans la Figure 37: 1. le service du personnel (RH) engage un nouveau collaborateur auquel est attribuée une fonction/rôle définie; 2. l identité numérique est générée par l Identity Provider; 3. le nouveau collaborateur est enregistré selon les règles en vigueur dans l IAM du domaine, qui se compose d une partie administration et d un Directory. Le collaborateur en question se voit attribuer une identité numérique par l Identity Provider. Ses Claims découlent de son rôle/fonction et sont enregistrés dans l IAM à titre d attribut de son identité numérique; 4. les informations concernant l utilisateur ainsi que ses Claims sont distribués par l IAM à l ensemble des systèmes cibles interconnectés, p. ex. à l Appl-1, Windows AD, SAP et autres applications; 5. le nouveau collaborateur reçoit, selon la procédure prévue, ses Credentials. Il est dès lors en mesure d utiliser ceux-ci pour s identifier (SSO - Single Sing-On). Son identité numérique (ID) est reconnue par le domaine. Cette forme d IAM est typique des petites entreprises ou des domaines administratifs individuels qui décident d implanter un IAM centralisé dans leur propre environnement afin de pouvoir administrer les sujets et les ressources. Cette forme d IAM permet également mettre en œuvre une solution Single Sign-On unifiée. Le système IAM, composé d une partie administration et d une partie répertoires, sert à intégrer les différents répertoires indépendants. Dans cette configuration, les différents répertoires utilisateurs, tels que p. ex. l Active Directory, le SAP Directory ou les répertoires utilisateurs individuels sont intégrés au moyen des Adapters correspondants. Les répertoires des ressources sont également intégrés (p. ex. la gestion de la configuration de la banque de données). On différencie généralement les systèmes sources (fournisseurs d identités numériques, p. ex. HR System) des systèmes cibles (p. ex. Active Directory, SAP Directory). Les Adapters des systèmes IAM actuels sont très intelligents et permettent également de procéder à une intégration bidirectionnelle, même si celle-ci ne devrait pas toujours être autorisée pour des raisons de processus (niveau législatif) (voir également chapitre ). Dans le cadre d un concept IAM, la mise en place de cette variante permet d élaborer en permanence, au niveau conceptuel, l ensemble des paramètres importants tels que Governance, processus nécessaires, identités numériques, Identity Providers, Claims, interconnexions des répertoires sources et des répertoires cibles, Single Sign-On, etc. La situation initiale (Baseline) qui n est souvent pas claire fait que la mise en œuvre de ce système dans un environnement existant n est pas toujours aisée et requiert de ce fait une analyse préalable de l état des lieux. L intégration des divers environnements cibles, tels que p. ex. Active Directory, SAP ou applications est comparable àla thématique des exigences IAM relatives à l interconnexion entre domaines 81/104

82 fédérés décrite de façon exhaustive au chapitre 7.3.2, dans laquelle les systèmes cibles/applications individuels existants sont interprétés comme des domaines séparés. De manière analogue, il existe également souvent différents Identity Providers dans un environnement limité, p. ex. les RH (service du personnel) pour les collaborateurs internes et des départements spécifiques aux collaborateurs externes. Si l intention est également d intégrer des sujets étrangers au domaine, ceux-ci doivent alors être enregistrés en mode local et être en possession d une identité numérique L IAM dans le cadre d une fédération libre de domaines Le fait de réaliser un IAM dans le cadre d une fédération libre de domaines implique l instauration d un dialogue approprié entre les domaines concernés. Dans ce contexte, Shibboleth 19 représente une solution possible. Avantages: Approche pragmatique. Les formes d organisation similaires permettent de définir et d établir rapidement les identités numériques et les rôles dans les domaines partenaires Approprié à une fédération de domaines simple, claire et structurée (p. ex. universités, écoles, hautes écoles, ) Relativement rapidement mis en œuvre Inconvénients: Non approprié pour des domaines aux formes d organisation très différenciées Non approprié pour des domaines à fortes exigences de sécurité, car la description et la garantie de la confiance mutuelle (Trust) ne peuvent pas être appliquées de façon efficace et efficiente. Utilisateur Domaine A Domaine B HR 5 SSO Accès aux ressources du domaine B 1 Nouveau collab. ID Appl-1 Windows AD SAP Autres Appl. Appl-B1 HR IAM domaine Administration IAM IAM Directory Trust IAM domaine B Trust Trust Identity Provider Répertoire des rôles au sein de la fédération Policies communes Figure 38: IAM entre plusieurs domaines ayant des Policies communes 19 Pour davantage de détails, voir: 82/104

83 Dans l architecture illustrée à la Figure 38, les différents domaines disposent d une identité numérique dont le format est unifié (représenté, dans l illustration, par un Identity Provider commun). Il en va de même pour les rôles, qui sont uniformisé en fonction d un Standardset commun. On peut donc parler ici d une relation de confiance clairement définie entre les domaines. Le principe veut que, dans chacun des domaines, un IAM interne soit déjà mis en œuvre, comme décrit au chapitre 8.1. Les étapes de l obtention de l identité numérique sont identiques à celles de l exemple qui y est mentionné dans le cas de domaines individuels. Lorsque l utilisateur du domaine A veut exploiter une ressource du domaine B, il peut utiliser son identité numérique selon le mode établi par la convention régissant les interconnexions entre les domaines. Il s identifie avec les Credentials de son domaine d origine. Ses Claims sont envoyés au domaine cible B où son autorisation est vérifiée (Standardset des rôles entre domaines et comparaison des règles d accès des ressources souhaitées). L accès est ensuite autorisé ou non L IAM dans le cadre d un domaine Master Les organisations de plus grandes dimensions disposent souvent d une structure de domaines hiérarchisée. La structure possible d un tel IAM est indiquée à la Figure 39. Avantages: Hiérarchies de l interconnexion IAM claires et simples à gérer (responsabilités) Architecture IAM uniformisée dans tous les domaines concernés Identity Provider et identité numériques identiques dans tous les domaines Grande autonomie des domaines malgré la fédération Le fait de disposer d un domaine Master permet une liaison efficiente et efficace entre les différents domaines Inconvénients: Les parties communes de l architecture requièrent une coordination adéquate Le regroupement de l architecture requiert des conditions conceptuelles préalables, surtout au niveau de la confiance mutuelle (Trust) Au cas où les mesures de sécurités décidées (p. ex. délégation du pouvoir administratif) ne sont pas mises en œuvre en permanence, le «lien» généré entre les Directories de l IAM Master accroît les risques en termes de sécurité 83/104

84 Collaborateur Domaine A Domaine B HR 5 SSO 1 Nouveau collab. ID Appl-1 Windows AD SAP autres Appl. HR IAM domaine Administration IAM IAM Directory Trust IAM domaine B Trust Trust Identity Provider IAM Domäne A IAM Domäne B IAM Domäne C Master IAM Domaine Master Figure 39: l IAM en fédération avec un domaine Master Malgré l idée d utiliser, à l aide d un domaine Master, des identités numériques uniformisées dans l ensemble de l organisation, cette forme d organisation est typiquement axée sur l indépendance de chacun des domaines. La façon dont les domaines fédérés se font confiance est formellement définie dans le cadre de conventions de confiance. Toutes les opérations qui ont lieu entre les différents domaines sont effectuées en fonction de ces accords de confiance. L approche indiquée à la Figure 39 illustre l exemple de l intégration d un collaborateur dans le domaine A: 1) le service du personnel (RH) du domaine A engage un nouveau collaborateur qui a un rôle/fonction bien défini (dans le domaine A); 2) l identité numérique est générée par l Identity Provider du domaine Master; 3) le collaborateur en question est intégré à l IAM du domaine A (composé d une partie administration et d un Directory) selon les règles en vigueur dans le domaine. Le collaborateur se voit attribuer son identité numérique par l Identity Provider. Ses Claims, issus de son rôle/fonction dans le domaine A, sont enregistrés en tant qu attributs de son identité numérique dans l IAM du domaine A; 4) les informations relatives à l utilisateur et ses Claims sont distribués par l IAM dans tous les systèmes cibles interconnectés au domaine A, p. ex. Appl-1, Windows AD, SAP et à d autres applications; 5) l identité numérique du nouveau collaborateur lui est fournie (de façon sécurisée). Remarques: 84/104

85 dans cet exemple, on trouve, dans le domaine Master, un répertoire regroupant tous les domaines IAM interconnectés. Ce répertoire Master permet de trouver, en disposant des autorisations appropriées, l ensemble des sujets et leurs identités numériques enregistrés dans tous les IAM interconnectés; le domaine Master pourrait p. ex. être complété avec les identités numériques de tous les sujets, ce qui signifie que les identités seraient non seulement enregistrées dans l IAM propre aux domaines locaux mais également dans le domaine Master (il s agirait alors uniquement des identités sans Claims supplémentaires). Dans cet exemple, on part du principe que chaque domaine possède un IAM, comme expliqué au chapitre 8.1. La transition opérée à partir d un éventuel environnement sans IAM de domaine n est pas spécifiquement explicitée ici. Dans ce cas et contrairement aux tâches de consolidation de chacun des domaines, l intégration de chaque système source et de chaque système cible nécessite l intégration de divers systèmes IAM. Dans ce cas, les exigences particulières qui doivent être remplies sont celles de l intégration fédérée, décrite en détail au chapitre Il reste toutefois possible de continuer d utiliser les identités locales et les identités des sujets au moyen du mapping d identités, décrite au chapitre L IAM avec métadomaine Dans l environnement E-Government, les domaines des identités numériques sont souvent administrés de façon fédérée. L une des approches possibles dans un tel cas est de faire en sorte que les domaines s organisent eux-mêmes entre eux, ce qui implique que les partenaires concernés doivent conclure des accords «bilatéraux» entre les différents domaines. Il est toutefois à noter dans ce cas que plus le nombre de domaines est important, plus la complexité augmente, ainsi que le montre de façon schméatique la Figure 40 illustrant le cas de quatre domaines et de quatre registres: Domaine A Domaine B Domaine C Domaine D SuisseID Service Provider Registre X Registre Y Registre Z Figure 40: exigences posées requises dans le cas de quatre domaines/registres 85/104

86 Dans l exemple de la Figure 40, chacun des quatre domaines est en relation avec les autres, ce qui fait un total de six relations. En outre, chacun des domaines est également en relation avec chacun des registres (c est-à-dire quatre par domaine) pour un total de 16 relations. Il s agit donc de spécifier formellement 22 relations pour l ensemble des domaines et des registres. L approche de type métadomaines proposée ici permet de réduire le nombre de relations nécessaires. Les domaines individuels font appel à un domaine hiérarchiquement supérieur (métadomaine) avec lequel chaque domaine établit une relation de confiance. Le principe de ces interconnexions rapportées à un métadomaine est représenté dans la Figure 41 Avantages: Approche fédérative constituée au moyen d accords généraux instaurés au niveau de la fédération. Cette approche s apparente avec celle des domaines Master mais sa mise en œuvre n exige pas un couplage aussi étroit. Etant donné que cette solution ne requiert la définition que d un nombre réduit de relations de confiance, cette solution est optimale pour des IAM E-Government de grande importance/complexité. Inconvénients: Le métadomaine doit être développé de façon systématique pour un environnement concret en accord avec la fédération de domaines. La disponibilité du métadomaine doit être garantie. Le métadomaine a besoin d une entité exploitante. Sujet Ressource Sujet Ressource Règle d accès Rège d accès Credential Identité numérique Claim Credential Identité numérique Claim Identifiant Domaine A Identifiant Domaine B trust trust Interface de service Métadomaine Documents DMS pour stockage Accès Web Services de définition des formats règles de sémantique consolidation Services pour la gestion et l exploitation du métadomaine Domaine A Domaine B Domaine n Répertoire Id fédération Répertoire CAS Répertoire IdPs Documentation Services fédératifs Services de gestion Metadirectory Figure 41: métadomaine avec interfaces Services et Metadirectory Outre le répertoire de tous les domaines qui y sont interconnectés de façon confidentielle, le métadomaine nécessite également des règles (Policies) définissant les rapports instaurés au sein de l interconnexion. Les Policies spécifient p. ex.: 86/104

87 le niveau de sécurité des différents domaines interconnectés ainsi que la description formelle des rapports de confiance établis entre ceux-ci; quel Identity Provider (répertoire IdPs) fonctionne comme instance d établissement des identités; le répertoire des Claim Providers dignes de confiance (répertoire CAS); le format des identités numériques et de leurs attributs; le format de l identifiant; le format des règles d accès; quels sont les Credentials qui doivent être utilisés ainsi que leurs formats possibles, y compris la «Secure Propagation» entre les domaines; comment sont formés les Claims et comment ils peuvent être utilisés. Un ensemble de règles et de conventions minimales qui doivent impérativement être respectées par les domaines membres sont également définies pour le métadomaine. Ces règles sont également disponibles au format électronique approprié (gestion des documents, pages web). Le métadomaine offre également un ou plusieurs CAS (Claim Assertion Service), permettant de mettre à disposition (sous forme de Claims) certaines informations provenant du métadomaine. La Figure 42 montre la même situation que celle illustrée à la Figure 40, mais avec la structure d un métadomaine: Domaine A Domaine B Domaine C Domaine D SuisseID Service Provider trust trust trust trust Registre X Registre Y Registre Z trust trust trust trust Interface de service Metadirectory Domaine A SuisseID Domaine B Registre X Domaine C Registre Y Domaine D Registre Z Métadomaine Documentation Services fédératifs Services de gestion Figure 42: métadomaine avec 4 domaines et 4 registres Ainsi qu il est possible de s en rendre compte sur la Figure 42, dans ce cas, le nombre de relations de confiance (Trusts) se réduit à 8 (pour un nombre identique de domaines et de registres), comparé aux 22 d un environnement sans approche de type métadomaine. 87/104

88 Dans cet exemple, le fait que chacun des domaines ait un IAM local n entre pas en considération. Ce qui est au contraire intéressant, étant donné que l information doit être enregistrée dans le Metadirectory, c est de savoir p. ex. quel Identity Provider ces domaines utilisent pour l identité numérique des sujets et comment se présentent ces identités numériques et leurs Claims. Dans ce cas également, les exigences relatives à l intégration fédérée, décrite de façon détaillée au chapitre 7.3.2, doivent être satisfaites. Il serait envisageable de mettre p. ex. en œuvre, au niveau du Metadirectory, le mapping des identités décrit au chapitre Le cas échéant, cette possibilité présenterait l avantage de pouvoir toujours procéder au mapping de façon standardisée Les services du métadomaine Les informations relatives aux identités numériques ainsi que l interconnexion de répertoires des différents domaines sont enregistrées, au niveau du métadomaine, dans un Directory approprié, dans lequel il est p. ex. possible de saisir les domaines et de les administrer. Ce Metadirectory peut également contenir un répertoire des interconnexions entre les identités numériques (répertoire interconnexion ID) afin, p. ex. de faciliter la fédération d identités numériques dans différents domaines. Le Metadirectory est généralement un répertoire dont l organisation est strictement hiérarchisée (voir chapitre 7.2.1). Il peut être créé de différentes façons. L une des implémentations possibles est représentée de façon schématique à la Figure 43: root Répertoire IdPs Répertoire CAS ID fédération (ID-Mapping) ID X consolidée ID X in A ID X in B ID X in n ID Y consolidée ID Y in A ID Y in B ID Y in C Fédération Domaine A Domaine B Domaine n ID consolidée Figure 43: structure du Metadirectory Dans cet exemple, les répertoires relatifs aux Identity Providers (IdPs) dignes de confiance et aux Claim Assertion Services (CAS), le répertoire d interconnexion ID avec les ID consolidés au niveau de la fédération et le Directory d interconnexions avec le répertoire des partenaires enregistrés sont implantés au plus haut niveau hiérarchique. 88/104

89 8.5. Autres variantes possibles Différentes variantes IAM ont été mentionnées de façon schématique dans les chapitres précédents. Il est toutefois également possible de combiner ces différentes variantes, p. ex. l intégration de la variante métadomaine 8.1 L IAM dans un domaine ou même la combinaison de l approche domaine Master du chapitre 8.3 avec celle du métadomaine du chapitre Assurance de la documentation et de la gestion de la documentation Indépendamment de l architecture de la solution choisie, l ensemble des règles et des Policies d un environnement IAM doivent être disponibles dans un répertoire approprié (Repository). Cette documentation peut p. ex. être mise à disposition dans un système de fichiers accessibles à tous les sujets de la fédération de domaines par l intermédiaire d une interface web. Il est toutefois recommandé de mettre en place un système de gestion de la documentation qui réponde aux exigences minimales de la gestion des documents. Font partie d un tel système: la gestion automatique des versions; la production et la signature de documents; l élaboration de documents; la mise à disposition de la nouvelle version d un document; un système d échange de fichiers en cas d élaboration simultanée de documents; des opérations orientées vers les transactions avec Roll-Back sécurisé; des fonctions de recherches efficientes; l intégration possible de méta-informations dans un document; la possibilité de configurer le système de gestion, p. ex. les directives concernant l intégration de méta-informations; un système de gestion des documents permettant d assurer la traçabilité selon les directives édictées par le niveau législatif Single Sign-On fédéré Dans les exemples de ce chapitre, on trouve les composants «SSO» Single Sing-On qui, dans le contexte e-government, sont entendus au sens de Single Sign-On fédéré, représenté de façon schématique dans la Figure 44: 89/104

90 Interaction entre utilisateurs Interaction sur base Web Domaine A IdP Internet Utilisateur Domaine B Portail Web Domaine C Application Web C Figure 44: Single Sign-On fédéré L exemple illustré dans la Figure 44 comprend un Identity Provider IdP dans le domaine A, un Web Portal dans le domaine B et une application web dans le domaine C. L objectif est de faire en sorte que l utilisateur (sujet) à qui l IdP (domaine A) a attribué une identité numérique puisse accéder au Web Portal du domaine B et utiliser l application web C du domaine C sans s identifier à nouveau. Il est possible de mettre en œuvre un Single Sing-On au moyen de différents protocoles, tels que p. ex. SAML (voir 9.1.2), Liberty ID-FF (voir 9.1.4) ou fédération WS (voir 9.1.5). Dans cette section, les aspects principaux suivants de la thématique Single Sign-On SSO sont approfondis: protocoles Pull / Push SSO; Account linking; Where are you from (WAYF); Session Management; Logout; Credential clean-up; Global good-bye; Account de-linking Pull / Push SSO Pull SSO: l utilisateur veut accéder au Service Provider. Ce dernier interroge le Security Token de l utilisateur enregistré auprès de l Identity Provider. 90/104

Règlement pour les fournisseurs de SuisseID

Règlement pour les fournisseurs de SuisseID Règlement pour les fournisseurs de SuisseID Version 1.0c du 4 novembre 2010 Règlement pour fournisseurs de SuisselD Nom Numéro de standard Catégorie Degré de maturité Règlement pour les fournisseurs de

Plus en détail

CONVENTION D'UTILISATION FAS

CONVENTION D'UTILISATION FAS CONVENTION D'UTILISATION Objectif du document : Une convention d'utilisation est un contrat spécifique à un service qui stipule les conditions liées à l'utilisation d'un service spécifique de Fedict. Il

Plus en détail

Cyberadministration: adoption du plan d action 2015

Cyberadministration: adoption du plan d action 2015 Cyberadministration: adoption du plan d action 2015 Berne, 21.10.2014 - Lors de sa séance du 15 octobre 2014, le Comité de pilotage de la cyberadministration suisse a intégré six projets dans son plan

Plus en détail

ech-0167 Concept cadre SuisseTrustIAM

ech-0167 Concept cadre SuisseTrustIAM Normes en cyberadministration page 1 sur 29 ech-0167 Concept cadre SuisseTrustIAM Titre Code Type Stade Concept cadre SuisseTrustIAM ech-0167 Norme Défini Version 1.0 Statut Approuvé Validation 2014-06-04

Plus en détail

EXPOSE. La SuisseID, qu est ce que c est? Secrétariat d Etat à l Economie SECO Pierre Hemmer, Chef du développement egovernment

EXPOSE. La SuisseID, qu est ce que c est? Secrétariat d Etat à l Economie SECO Pierre Hemmer, Chef du développement egovernment EXPOSE La SuisseID, qu est ce que c est? Association Romande des Informaticiens ARI Vendredi 18 juin 2010 Secrétariat d Etat à l Economie SECO Pierre Hemmer, Chef du développement egovernment 1 Table des

Plus en détail

DESCRIPTION DU COMPOSANT

DESCRIPTION DU COMPOSANT Gestion des utilisateurs et des accès Composant pour un Egov intégré Qu'est-ce qu'un composant? C est un élément indispensable à l intégration des systèmes e-gov des différents niveaux politiques. Cet

Plus en détail

ENVOLE 1.5. Calendrier Envole

ENVOLE 1.5. Calendrier Envole ENVOLE 1.5 Calendrier Envole RSA FIM 1 avril 2008 V 1.13 sur EOLE V 2.0 1 septembre 2008 EOLE V 2.1 10 octobre 2008 V 1.15 RC sur EOLE V 2.0 Modification du SSO EOLE 2.2 (PAM-CAS, CT EOLE V 2.2 RC Prise

Plus en détail

Explications sur l évolution de la maquette. Version : 1.0 Nombre de pages : 9. Projet cplm-admin

Explications sur l évolution de la maquette. Version : 1.0 Nombre de pages : 9. Projet cplm-admin Explications sur l évolution de la maquette Version : 1.0 Nombre de pages : 9 Rédacteur : David Elias 22/07/2008 STATUT DU DOCUMENT Statut Date Intervenant(s) / Fonction Provisoire 20/07/2008 David Elias

Plus en détail

Rapport de certification

Rapport de certification Rapport de certification Évaluation EAL 2 + du produit Data Loss Prevention Version 11.1.1 Préparé par : Le Centre de la sécurité des télécommunications Canada à titre d organisme de certification dans

Plus en détail

ech-0168 Architecture technique et processus SuisseTrustIAM

ech-0168 Architecture technique et processus SuisseTrustIAM Normes en cyberadministration page 1 sur 77 ech-0168 Architecture technique et processus SuisseTrustIAM Titre Code Type Stade Architecture technique et processus SuisseTrustIAM ech-0168 Norme Expérimental

Plus en détail

Rapport de certification

Rapport de certification Rapport de certification Security Intelligence Platform 4.0.5 Préparé par : Le Centre de la sécurité des télécommunications à titre d organisme de certification dans le cadre du Schéma canadien d évaluation

Plus en détail

3 mai 2013, Delémont

3 mai 2013, Delémont 3 mai 2013, Delémont Le Canton du Jura profite du registre de la Poste pour identifier ses utilisateurs grâce à la SuisseID 3 Mai 2013, Delémont MATTHIEU LACHAT, Chef du Service de l informatique du Canton

Plus en détail

Rapport de certification

Rapport de certification Rapport de certification Préparé par : Le Centre de la sécurité des télécommunications à titre d organisme de certification dans le cadre du Schéma canadien d évaluation et de certification selon les critères

Plus en détail

HERMES 5.1. Méthode de gestion pour tous les projets MANUEL POUR MANAGER

HERMES 5.1. Méthode de gestion pour tous les projets MANUEL POUR MANAGER HERMES 5.1 Méthode de gestion pour tous les projets MANUEL POUR MANAGER ManagerHERMES_FR.indd 1 20.05.15 12:05 ManagerHERMES_FR.indd 2 20.05.15 12:05 «Ce qui dure, c est le changement» (Michael Richter,

Plus en détail

Rapport de certification

Rapport de certification Rapport de certification Évaluation EAL 2 + du produit RSA Archer egrc Platform v5.0 Préparé par : Le Centre de la sécurité des télécommunications Canada à titre d organisme de certification dans le cadre

Plus en détail

Rapport de certification

Rapport de certification Rapport de certification Symantec Security Information Manager 4.8.1 Préparé par : Le Centre de la sécurité des télécommunications à titre d organisme de certification dans le cadre du Schéma canadien

Plus en détail

Rapport de certification

Rapport de certification Rapport de certification NetApp Data ONTAP, version 8.2.1 7-Mode Préparé par le Centre de la sécurité des télécommunications à titre d organisme de certification dans le cadre du Schéma canadien d évaluation

Plus en détail

Rapport de certification

Rapport de certification Rapport de certification Symantec Network Access Control Version 12.1.2 Préparé par : Le Centre de la sécurité des télécommunications Canada à titre d organisme de certification dans le cadre du Schéma

Plus en détail

Rapport de certification

Rapport de certification Rapport de certification NetScout ngeniusone Unified Performance Management Platform V5.2.1 and ngenius InfiniStream V5.2.1 Préparé par : Le Centre de la sécurité des télécommunications à titre d organisme

Plus en détail

Application des Spécifications détaillées pour la Retraite, architecture portail à portail

Application des Spécifications détaillées pour la Retraite, architecture portail à portail Pour Application des Spécifications détaillées pour la Retraite, architecture portail à portail Version 1.0 ON-X S.A. est une société du Groupe ON-X 15, quai Dion Bouton 92816 PUTEAUX cedex. Tél : 01 40

Plus en détail

Application des Spécifications détaillées pour le RNIAM, architecture portail à portail

Application des Spécifications détaillées pour le RNIAM, architecture portail à portail Pour Application des Spécifications détaillées pour le RNIAM, architecture portail à portail Version 1.0 ON-X S.A. est une société du Groupe ON-X 15, quai Dion Bouton 92816 PUTEAUX cedex. Tél : 01 40 99

Plus en détail

Rapport de certification

Rapport de certification Rapport de certification HP préparé par le Centre de la sécurité des télécommunications à titre d organisme de certification dans le cadre du Schéma canadien d évaluation et de certification selon les

Plus en détail

Accès réseau Banque-Carrefour par l Internet Version 3.2. 06/06/2005

Accès réseau Banque-Carrefour par l Internet Version 3.2. 06/06/2005 ISMS (Information Security Management System) Utilisation de l Internet comme moyen d accès au réseau de la Banque-Carrefour de la sécurité dans le cadre du traitement de données à caractère personnel

Plus en détail

Tour d horizon des différents SSO disponibles

Tour d horizon des différents SSO disponibles Tour d horizon des différents SSO disponibles L. Facq, P. Depouilly, B. Métrot, R. Ferrere ANF Les systèmes d authentification dans la communauté ESR : étude, mise en oeuvre et interfaçage dans un laboratoire

Plus en détail

Introduction pratique au Développement orienté Modèle Pierre Parrend, Mars 2005

Introduction pratique au Développement orienté Modèle Pierre Parrend, Mars 2005 MDA : Un Tutoriel Introduction pratique au Développement orienté Modèle Pierre Parrend, Mars 2005 1 Sommaire Table des matières 1 Sommaire 1 2 Introduction 2 2.1 A qui s adresse ce tutoriel......................

Plus en détail

Conseil économique et social

Conseil économique et social NATIONS UNIES E Conseil économique et social Distr. GÉNÉRALE ECE/TRANS/WP.30/AC.2/2008/2 21 novembre 2007 FRANÇAIS Original: ANGLAIS COMMISSION ÉCONOMIQUE POUR L EUROPE Comité de gestion de la Convention

Plus en détail

Rapport de certification

Rapport de certification Rapport de certification Memory Arrays avec Memory Gateways Version 5.5.2 Préparé par : Le Centre de la sécurité des télécommunications à titre d organisme de certification dans le cadre du Schéma canadien

Plus en détail

Créer et partager des fichiers

Créer et partager des fichiers Créer et partager des fichiers Le rôle Services de fichiers... 246 Les autorisations de fichiers NTFS... 255 Recherche de comptes d utilisateurs et d ordinateurs dans Active Directory... 262 Délégation

Plus en détail

Rapport de certification

Rapport de certification Rapport de certification Trustwave AppDetectivePRO Version 8.3.1 préparé par le Centre de la sécurité des télécommunications à titre d organisme de certification dans le cadre du Schéma canadien d évaluation

Plus en détail

Stratégie de la Confédération en matière de TIC 2012 à 2015 Annexe B: Plan directeur

Stratégie de la Confédération en matière de TIC 2012 à 2015 Annexe B: Plan directeur Département fédéral des finances DFF Unité de pilotage informatique de la Confédération Stratégie de la Confédération en matière Annexe B: Plan directeur Etat de la planification mars 2013 Stratégie de

Plus en détail

Mieux comprendre les certificats SSL THAWTE EST L UN DES PRINCIPAUX FOURNISSEURS DE CERTIFICATS SSL DANS LE MONDE

Mieux comprendre les certificats SSL THAWTE EST L UN DES PRINCIPAUX FOURNISSEURS DE CERTIFICATS SSL DANS LE MONDE Mieux comprendre les certificats SSL THAWTE EST L UN DES PRINCIPAUX FOURNISSEURS DE CERTIFICATS SSL DANS LE MONDE sommaire MIEUX COMPRENDRE LES CERTIFICATS SSL...1 SSL et certificats SSL : définition...1

Plus en détail

Ministère de l éducation nationale, de l enseignement supérieur et de la recherche 07/11/2006

Ministère de l éducation nationale, de l enseignement supérieur et de la recherche 07/11/2006 Schéma directeur des espaces numériques de travail Annexe AAS Authentification-Autorisation-SSO Version 2.0 SOMMAIRE 1. Introduction... 3 1.1 Contexte... 3 1.2 Objectifs et contenu du document... 4 1.3

Plus en détail

LA CARTE D IDENTITE ELECTRONIQUE

LA CARTE D IDENTITE ELECTRONIQUE LA CARTE D IDENTITE ELECTRONIQUE HISTORIQUE Le Conseil des Ministres du 22 novembre 2000 a approuvé une note concernant une infrastructure PKI (Public Key Infrastructure) et l utilisation d une carte d

Plus en détail

PASS v2.0 : solution d authentification unique basée sur les composants Shibboleth Service Provider v2.5.1 et Identity Provider v2.3.

PASS v2.0 : solution d authentification unique basée sur les composants Shibboleth Service Provider v2.5.1 et Identity Provider v2.3. PREM IE R M IN IS T R E Secrétariat général de la défense et de la sécurité nationale Agence nationale de la sécurité des systèmes d information PASS v2.0 : solution d authentification unique basée sur

Plus en détail

SÉCURISER EMC VSPEX END-USER COMPUTING AVEC RSA SECURID

SÉCURISER EMC VSPEX END-USER COMPUTING AVEC RSA SECURID GUIDE DE CONCEPTION SÉCURISER EMC VSPEX END-USER COMPUTING AVEC RSA SECURID VMware Horizon View 5.2 et VMware vsphere 5.1 - Jusqu à 2 000 bureaux virtuels EMC VSPEX Résumé Le présent guide décrit les composants

Plus en détail

Gestion des Identités et des Autorisations: Modèle générique

Gestion des Identités et des Autorisations: Modèle générique Département : Concerne : Exploitation Projet CERBERE, Analyse fonctionnelle Nos ref. : Vos ref. : CERBERE Version: Description Ecrit par Revu par Date 00.92G Version draft Albert Bruffaerts Comité de travail

Plus en détail

La construction d un référentiel d identité est au cœur des approches de gestion des identités et des accès.

La construction d un référentiel d identité est au cœur des approches de gestion des identités et des accès. Etat de l art Synchronisation des identités pour un référentiel d identités multi-annuaires La construction d un référentiel d identité est au cœur des approches de gestion des identités et des accès.

Plus en détail

Annexe 1 Annexe technique de la convention d habilitation «société d assurance»

Annexe 1 Annexe technique de la convention d habilitation «société d assurance» Annexe 1 Annexe technique de la convention d habilitation «société d assurance» «professionnel indépendant» (Convention complète) 1 Notice explicative... 2 1.1 Préambule... 2 1.2 Référencement du concentrateur...

Plus en détail

Rapport de certification

Rapport de certification Rapport de certification Forum Sentry v8.1.641 Préparé par : Le Centre de la sécurité des télécommunications à titre d organisme de certification dans le cadre du Schéma canadien d évaluation et de certification

Plus en détail

Sécurisation des architectures traditionnelles et des SOA

Sécurisation des architectures traditionnelles et des SOA Sécurisation des architectures traditionnelles et des SOA Un livre blanc de Bull Evidian Gestion SAML des accès SSO aux applications classiques et J2EE. Max Vallot Sommaire Émergence des architectures

Plus en détail

Rapport de certification

Rapport de certification Rapport de certification NetIQ Secure Configuration Manager 5.9.1 Préparé par : Le Centre de la sécurité des télécommunications à titre d organisme de certification dans le cadre du Schéma canadien d évaluation

Plus en détail

Programme qualité. de l association suisse des services d aide et de soins à domicile. Projet 02 Octobre 2001

Programme qualité. de l association suisse des services d aide et de soins à domicile. Projet 02 Octobre 2001 Programme qualité de l association suisse des services d aide et de soins à domicile Projet 02 Octobre 2001 A propos de la consultation auprès des associations cantonales 24.10.2001-21.11.2001 1. Situation

Plus en détail

Dématérialisation des documents Quelques éléments pour analyser et choisir une solution Illustration avec EdelSafe

Dématérialisation des documents Quelques éléments pour analyser et choisir une solution Illustration avec EdelSafe Dématérialisation des documents Quelques éléments pour analyser et choisir une solution Illustration avec EdelSafe Peter Sylvester / Paul-André Pays EdelWeb http://www.edelweb.fr/ ps@edelweb.fr / pays@edelweb.fr

Plus en détail

Rapport de certification

Rapport de certification Rapport de certification McAfee Enterprise Mobility Management 12.0 Préparé par : Le Centre de la sécurité des télécommunications Canada à titre d organisme de certification dans le cadre du Schéma canadien

Plus en détail

Conformité PCI DSS. Réduire les risques en gérant les identités et les accès. white paper

Conformité PCI DSS. Réduire les risques en gérant les identités et les accès. white paper Conformité PCI DSS Réduire les risques en gérant les identités et les accès Ce livre blanc explique comment la suite IAM d Evidian peut vous aider à vous conformer aux exigences PCI DSS. white paper 39

Plus en détail

CA SIC Directives de certification Certificate Practice Statement (CPS) du SIC Customer ID CA 1024 Level 2

CA SIC Directives de certification Certificate Practice Statement (CPS) du SIC Customer ID CA 1024 Level 2 CA SIC Directives de certification Certificate Practice Statement (CPS) du SIC Customer ID CA 1024 Level 2 Version 2.2 / Decembre 2012 1 Notes Les informations de ce document vous sont fournies sans garantie

Plus en détail

Sélectionner la bonne base de données de gestion de configurations pour mettre en place une plate-forme efficace de gestion de services.

Sélectionner la bonne base de données de gestion de configurations pour mettre en place une plate-forme efficace de gestion de services. Solutions de Service Management Guide d achat Sélectionner la bonne base de données de gestion de configurations pour mettre en place une plate-forme efficace de gestion de services. Aujourd hui, toutes

Plus en détail

Passer de l ISO 9001:2008 à l ISO 9001:2015

Passer de l ISO 9001:2008 à l ISO 9001:2015 ISO 9001 Guide de transition Révisions ISO Passer de l ISO 9001:2008 à l ISO 9001:2015 La nouvelle norme internationale pour les systèmes de management de la qualité ISO 9001 - Système de Management de

Plus en détail

Intégration d un poste Linux dans un domaine W2K

Intégration d un poste Linux dans un domaine W2K Intégration d un poste Linux dans un domaine W2K Pascal Gachet EIVD pascal.gachet@eivd.ch mai 2003 Intégration d un poste Linux dans un domaine W2K 2 Table des matières Introduction... 2 Terminologie...

Plus en détail

Rapport de certification

Rapport de certification Rapport de certification Series Appliances with HYPERMAX OS 5977 Préparé par : le Centre de la sécurité des télécommunications à titre d organisme de certification dans le cadre du Schéma canadien d évaluation

Plus en détail

Rapport de certification

Rapport de certification Rapport de certification Évaluation EAL 2 + du produit EMC Symmetrix VMAX Series with Enginuity Operating Environment 5875, Solutions Enabler 7.2.0 and Symmetrix Management Console 7.2.0 Préparé par :

Plus en détail

Rapport de certification

Rapport de certification Rapport de certification US Federal Protect Standard v9.1 Préparé par : Centre de la sécurité des télécommunications à titre d organisme de certification dans le cadre du Schéma canadien d évaluation et

Plus en détail

Rapport de certification

Rapport de certification Rapport de certification Commutateur de services photonique 1830 Photonic Service Switch (PSS) R7.0 Préparé par le Centre de la sécurité des télécommunications à titre d organisme de certification dans

Plus en détail

Documentation de presse recensement 2000

Documentation de presse recensement 2000 Documentation de presse recensement 2000 Pour tous renseignements: Werner HAUG tél. 032 / 713 66 85 fax 032 / 713 63 86 e-mail werner.haug@bfs.admin.ch Accueil médias Jean-Daniel MEIER tél. 032 / 713 69

Plus en détail

Rapport de certification

Rapport de certification Rapport de certification BMC Real End User Experience Monitoring and Analytics 2.5 Préparé par le Centre de la sécurité des télécommunications à titre d organisme de certification dans le cadre du Schéma

Plus en détail

Guide Travail pratique (certificat de module diplôme fédéral d informaticien)

Guide Travail pratique (certificat de module diplôme fédéral d informaticien) Guide Travail pratique (certificat de module diplôme fédéral d informaticien) 1 2 3 4 5 6 7 8 9 10 Conditions d admission à l examen final 2 Travail pratique 2 But 2 Choix du module / des compétences 3

Plus en détail

Directives du Conseil fédéral concernant les projets informatiques de l administration fédérale et le portefeuille informatique de la Confédération

Directives du Conseil fédéral concernant les projets informatiques de l administration fédérale et le portefeuille informatique de la Confédération Directives du Conseil fédéral concernant les projets informatiques de l administration du 1 er juillet 2015 Le Conseil fédéral suisse édicte les directives suivantes: 1 Dispositions générales 1.1 Objet

Plus en détail

Directive du DFJP sur la mise en place de liaisons en ligne et l octroi d autorisations d accès à des applications informatiques du DFJP

Directive du DFJP sur la mise en place de liaisons en ligne et l octroi d autorisations d accès à des applications informatiques du DFJP Directive du DFJP sur la mise en place de liaisons en ligne et l octroi d autorisations d accès à des applications informatiques du DFJP (Directive du DFJP sur les liaisons en ligne) du 30 septembre 2004

Plus en détail

CIBLE DE SECURITE CSPN DU PRODUIT PASS. (Product for Advanced SSO)

CIBLE DE SECURITE CSPN DU PRODUIT PASS. (Product for Advanced SSO) CIBLE DE SECURITE CSPN DU PRODUIT PASS (Product for Advanced SSO) Préparé pour : ANSSI Préparé par: Thales Communications & Security S.A. 4 Avenue des Louvresses 92622 GENNEVILLIERS CEDEX France This document

Plus en détail

SuisseID Mon «moi numérique»

SuisseID Mon «moi numérique» Mon «moi numérique» Si vous pouvez lire ce texte, vous devez réinsérer le transparent du modèle d'origine à l'aide de la fonction "insérer transparent" dans le menu de la Poste.. Sinon, il est impossible

Plus en détail

Rapport de certification

Rapport de certification Rapport de certification with Premium Encryption Security v8.1 Préparé par : le Centre de la sécurité des télécommunications à titre d organisme de certification dans le cadre du Schéma canadien d évaluation

Plus en détail

Cible de sécurité CSPN

Cible de sécurité CSPN Cible de sécurité CSPN ClearBUS Application cliente pour la communication sécurisée Version 1.12 Le 25/11/2011 Identifiant : CBUS-CS-1.12-20111125 contact@clearbus.fr tel : +33(0)485.029.634 Version 1.12

Plus en détail

Rapport de certification

Rapport de certification Rapport de certification Évaluation du Standard Protection Profile for Enterprise Security Management Access Control Version 2.0 Préparé par : Le Centre de la sécurité des télécommunications Canada à titre

Plus en détail

Portail de Processus. Services Publics & e-government

Portail de Processus. Services Publics & e-government , Stöckackerstrasse 30, CH-4142 Münchenstein Ph:++41 (0) 61 413 15 00, Fax:++41 (0) 61 413 15 01 http://www.e-serve.ch, crm@e-serve.ch Portail de Processus pour les Services Publics & e-government Solution:

Plus en détail

NOTE CIRCULAIRE. (3 septembre 2012)

NOTE CIRCULAIRE. (3 septembre 2012) Direction Protocole Service P1.1 NOTE CIRCULAIRE LE STATUT PRIVILEGIE DES CONJOINT(E)S ET DES PARTENAIRES LEGAUX (LEGALES) NON-MARIE(E)S DES MEMBRES DU PERSONNEL DES POSTES CONSULAIRES (3 septembre 2012)

Plus en détail

Vu la loi du 15 janvier 1990 relative à l institution et à l organisation d une Banque- Carrefour de la sécurité sociale, notamment l article 15 ;

Vu la loi du 15 janvier 1990 relative à l institution et à l organisation d une Banque- Carrefour de la sécurité sociale, notamment l article 15 ; CSSS/07/045 DÉLIBÉRATION N 07/018 DU 24 AVRIL 2007 RELATIVE À LA COMMUNICATION DE DONNÉES À CARACTÈRE PERSONNEL À LA SOCIÉTÉ FLAMANDE DES TRANSPORTS DE LIJN EN VUE DE LA DISTRIBUTION D ABONNEMENTS À CERTAINES

Plus en détail

Conception d Applications Réparties

Conception d Applications Réparties Jean-François Roos LIFL - équipe GOAL- bâtiment M3 Extension - bureau 206 -Jean-Francois.Roos@lifl.fr 1 Objectifs du Cours Appréhender la conception d applications réparties motivations et concepts architectures

Plus en détail

Description des prestations

Description des prestations Description des prestations Envoi, réception et archivage d e-factures Valable à partir du 01. 01.2015 Table des matières 1. Principes 3 1.1 Définitions 3 1.2 Canaux de communication 3 1.3 Moyens d identification

Plus en détail

Traduire dans l aide sociale

Traduire dans l aide sociale Traduire dans l aide sociale Droits des personnes de langue étrangère et obligations de l état Résumé Jörg Künzli, docteur en droit et professeur, LL.M., avocat, Berne Alberto Achermann, docteur en droit,

Plus en détail

- Couches - Éléments - Domaines - ArchiMate et les techniques du BABOK

- Couches - Éléments - Domaines - ArchiMate et les techniques du BABOK ArchiMate et l architecture d entreprise Par Julien Allaire Ordre du jour Présentation du langage ArchiMate - Couches - Éléments - Domaines - ArchiMate et les techniques du BABOK Présentation du modèle

Plus en détail

ech-0022 Normes en géoinformation

ech-0022 Normes en géoinformation Normes en cyberadministration Page 1 de 13 ech-0022 Normes en géoinformation Titre Code Type Stade Version 1.10 Statut Normes en géoinformation ech-0022 norme de procédure déployée approuvée Validation

Plus en détail

2008 : Diplômé Master 2 ASR (Architecture Système et Réseaux) Université d Evry (Evry - 91)

2008 : Diplômé Master 2 ASR (Architecture Système et Réseaux) Université d Evry (Evry - 91) Connaissances techniques Serveurs d application Langages et frameworks techniques Systèmes Réseaux et Sécurité IBM Tivoli Identity Manager (4.5, 4.6, 5.0, 5.1), IBM Tivoli Directory Server, IBM Tivoli

Plus en détail

FEDERATION DES IDENTITES

FEDERATION DES IDENTITES 1 FEDERATION DES IDENTITES Quel protocole de fédération pour quel usage? OAUTH & SAML Fabrice VAZQUEZ Consultant Sécurité du SI +331 73 54 3000 Cabinet de conseil et d expertise technique en sécurité du

Plus en détail

CERBERE V2: Guide pour l intégration

CERBERE V2: Guide pour l intégration Département : Concerne : Exploitation Projet CERBERE, Analyse détaillée Nos ref. : Vos ref. : Version: Description Ecrit par Revu par Date 00.90 Requis par le comité de pilotage du 6 avril 2011 Albert

Plus en détail

Mensuration officielle Plan de conservation et d archivage de données et de documents (PCA)

Mensuration officielle Plan de conservation et d archivage de données et de documents (PCA) Directive du 23 juin 2014 (état au 29 janvier 2015) Mensuration officielle Plan de conservation et d archivage de données et de documents (PCA) Editeur Groupe de travail «Archivage de données de la MO»

Plus en détail

Comité sectoriel de la Sécurité sociale et de la Santé Section «Sécurité sociale»

Comité sectoriel de la Sécurité sociale et de la Santé Section «Sécurité sociale» Comité sectoriel de la Sécurité sociale et de la Santé Section «Sécurité sociale» SCSZ/09/042 DELIBERATION N 09/030 DU 5 MAI 2009 RELATIVE A LA COMMUNICATION DE DONNEES A CARACTERE PERSONNEL PAR LA BANQUE

Plus en détail

ech-0148 Motifs d annonce Entreprises - taxes de domaine

ech-0148 Motifs d annonce Entreprises - taxes de domaine Normes en cyberadministration Page 1 de 36 ech-0148 Motifs d annonce Entreprises - taxes de domaine Titre Code Type Stade Motifs d annonce Entreprises - taxes de domaine ech-0148 norme de procédure Définie

Plus en détail

Comment assurer la gestion des identités et des accès sous forme d un service Cloud?

Comment assurer la gestion des identités et des accès sous forme d un service Cloud? FICHE DE PRÉSENTATION DE SOLUTION CA CloudMinder Comment assurer la gestion des identités et des accès sous forme d un service Cloud? agility made possible Grâce à CA CloudMinder, vous bénéficiez de fonctionnalités

Plus en détail

L Ag ence esanté en route...

L Ag ence esanté en route... L Ag ence esanté en route... Le Luxembourg souhaite se doter d un dossier électronique national d échange et de partage de données de santé, entre et pour les professionnels de santé intervenant auprès

Plus en détail

La sécurité dans les grilles

La sécurité dans les grilles La sécurité dans les grilles Yves Denneulin Laboratoire ID/IMAG Plan Introduction les dangers dont il faut se protéger Les propriétés à assurer Les bases de la sécurité Protocoles cryptographiques Utilisation

Plus en détail

REAUMUR-ACO-PRES. Wifi : Point et perspectives

REAUMUR-ACO-PRES. Wifi : Point et perspectives REAUMUR-ACO-PRES Wifi : Point et perspectives 26 Octobre 2005 www.reaumur.net REseau Aquitain des Utilisateurs des Milieux Universitaire et de Recherche Version du 11/06/2006 09:03:32 1 26/10/2005 REAUMUR-ACO

Plus en détail

Déclaration de protection des données

Déclaration de protection des données Déclaration de protection des données Valable à partir du 9 juillet 2015 1 Traitement des données personnelles 3 2 Pas d enregistrement d informations concernant les paiements 3 3 Définition des données

Plus en détail

Rédacteur : Cadre Cours de recherche «Grille de données» Lionel BRUNIE et Jean Marc PIERSON Date de Création : Janvier 2005

Rédacteur : Cadre Cours de recherche «Grille de données» Lionel BRUNIE et Jean Marc PIERSON Date de Création : Janvier 2005 Anallyse de ll arttiiclle e :: Experiience wiitth tthe KeyNotte o Trustt u Managementt Systtem:: Applliicattiions and Futture Diirecttiions Matt Blaze *, John Ioannidis and Angelos * D. Keromytis ** *

Plus en détail

ECVET GUIDE POUR LA MOBILITÉ

ECVET GUIDE POUR LA MOBILITÉ ECVET GUIDE POUR LA MOBILITÉ 2 GUIDE POUR LA MOBILITÉ ECVET «Le système européen de crédits d apprentissage pour l enseignement et la formation professionnels (ECVET) est un cadre technique pour le transfert,

Plus en détail

Rapport de certification

Rapport de certification Rapport de certification Préparé par : le Centre de la sécurité des télécommunications à titre d organisme de certification dans le cadre du Schéma canadien d évaluation et de certification selon les Critères

Plus en détail

PerSal Manuel d installation

PerSal Manuel d installation PerSal Manuel d installation Version 1.0 hostagest sàrl Grand Rue 14 CH 1083 Mézières Tél : +41 21 635 31 02 Fax : +41 21 635 31 04 Email : info@hostagest.ch Homepage : www.hostagest.ch Configuration minimale

Plus en détail

La gestion des identités à l École polytechnique Fédérale de Lausanne. Claude Lecommandeur École Polytechnique Fédérale de Lausanne Novembre 2007

La gestion des identités à l École polytechnique Fédérale de Lausanne. Claude Lecommandeur École Polytechnique Fédérale de Lausanne Novembre 2007 La gestion des identités à l École polytechnique Fédérale de Lausanne Claude Lecommandeur École Polytechnique Fédérale de Lausanne Novembre 2007 Plan Gestion des identités. Beaucoup (trop) d intervenants.

Plus en détail

Architecture Orientée Services d Entreprise (esoa)

Architecture Orientée Services d Entreprise (esoa) Architecture Orientée Services d Entreprise (esoa) SAPNW SOA100 SOA110 SOA200 5 jours SOA400 4 jours Introduction à SAP NetWeaver Architecture orientée services d entreprise SAP: les fondamentaux SAP Enterprise

Plus en détail

D une part, elles ne peuvent faire table rase de la richesse contenue dans leur système d information.

D une part, elles ne peuvent faire table rase de la richesse contenue dans leur système d information. PACBASE «Interrogez le passé, il répondra présent.». Le Module e-business Les entreprises doivent aujourd hui relever un triple défi. D une part, elles ne peuvent faire table rase de la richesse contenue

Plus en détail

BUSINESSOBJECTS EDGE PREMIUM

BUSINESSOBJECTS EDGE PREMIUM PRODUITS BUSINESSOBJECTS EDGE PREMIUM Avantages de la Business Intelligence Assurer une visibilité intégrale des activités Identifier de nouvelles opportunités Détecter et résoudre les problèmes Remplacer

Plus en détail

Qu'est ce qu'une Fédération d'identités? Définitions Fonctionnement de base Fonctionnement détaillé Les principaux composants

Qu'est ce qu'une Fédération d'identités? Définitions Fonctionnement de base Fonctionnement détaillé Les principaux composants Qu'est ce qu'une Fédération d'identités? Définitions Fonctionnement de base Fonctionnement détaillé Les principaux composants Fédération Définit un cercle de confiance constitué de Fournisseurs d'identités

Plus en détail

Solutions de gestion de la sécurité Livre blanc

Solutions de gestion de la sécurité Livre blanc Solutions de gestion de la sécurité Livre blanc L intégration de la gestion des identités et des accès avec l authentification unique Objectif : Renforcer la politique de sécurité et améliorer la productivité

Plus en détail

Rapport de certification

Rapport de certification Rapport de certification Évaluation EAL 2+ du produit Verdasys Préparé par le Centre de la sécurité des télécommunications Canada à titre d organisme de certification dans le cadre du Schéma canadien d

Plus en détail

La fédération d identités, pourquoi et comment? Olivier Salaün, RENATER ANF Mathrice 2014

La fédération d identités, pourquoi et comment? Olivier Salaün, RENATER ANF Mathrice 2014 La fédération d identités, pourquoi et comment? Olivier Salaün, RENATER ANF Mathrice 2014 25/09/2014 1 RENATER Opérateur du réseau enseignement et recherche Sécurité Le CERT RENATER Animation réseau des

Plus en détail

Spring IDE. Mise en œuvre. Eclipse

Spring IDE. Mise en œuvre. Eclipse A Spring IDE Bien que Spring mette à disposition d intéressants mécanismes afin d améliorer l architecture des applications Java EE en se fondant sur l injection de dépendances et la programmation orientée

Plus en détail

Stratégie suisse de cyberadministration («E-Government»)

Stratégie suisse de cyberadministration («E-Government») Stratégie suisse de cyberadministration («E-Government») Adoptée par le Conseil fédéral le 24 janvier 2007 Table des matières Préface... 2 1. Le potentiel de la cyberadministration... 4 1.1 La cyberadministration

Plus en détail

Directives pour l assurance qualité des organisations de formation aux premiers secours. Niveaux 1 3

Directives pour l assurance qualité des organisations de formation aux premiers secours. Niveaux 1 3 Directives pour l assurance qualité des organisations de formation aux premiers secours Niveaux 1 3 Directives 2015 L interassociation de Sauvetage (IAS) est l organisation faîtière des services qui s

Plus en détail

euthanasie Manuel Version Commune service public fédéral sante publique, securite de la chaine alimentaire et environnement Smals

euthanasie Manuel Version Commune service public fédéral sante publique, securite de la chaine alimentaire et environnement Smals Version Commune Manuel euthanasie Version 1.0/août 2008 - Bureau de communication - Smals service public fédéral sante publique, securite de la chaine alimentaire et environnement index 2 Introduire un

Plus en détail

MEGA Administration-Supervisor. Guide de l administrateur

MEGA Administration-Supervisor. Guide de l administrateur MEGA Administration-Supervisor Guide de l administrateur MEGA 2009 SP4 1ère édition (juin 2010) Les informations contenues dans ce document pourront faire l objet de modifications sans préavis et ne sauraient

Plus en détail