Twitter Facebook Google Plus Linkedin email Imprimer Pdf

|||

Infrastructure de gestion des clés : créer les conditions de la confiance

Publié le 07 décembre 2009 par Pierre Picard

61-Pierre-Jean Aubourgpar Pierre-Jean Aubourg, responsable de l’entité Monétique et PKI de Bull

Après 5 ans passés chez SYSECA, filiale service du groupe Thomson (devenu Thales), Pierre-Jean Aubourg rejoint Bull Ingénierie pour prendre en charge des projets de messagerie électronique. Il participe à ses premiers projets de sécurité en 2001 et devient responsable de l’entité Monétique et PKI au sein de l’unité Sécurité de Bull. A ce titre, il est en charge du développement des activités de service dans ces domaines et du développement de MetaPKI, solution de PKI (ou d’IGC) de Bull. Pierre-Jean Aubourg a un DESS en électronique et informatique industrielle et est également diplômé de l’Ecole des Techniques du Génie Logiciel.

Dans un monde ouvert, où les échanges se multiplient avec des interlocuteurs distants et inconnus, et où la mobilité dilue les frontières du système d’information, la capacité à identifier de façon certaine l’auteur d’un message, d’une transaction ou d’un document devient fondamentale. Les infrastructures de gestion de clés (IGC ou PKI pour Public Key Infrastructure) présentent à cet effet un grand intérêt car elles sont à la fois souples et rigoureuses, reconnues par tous les acteurs et susceptibles d’être mises en œuvre à tous les niveaux de l’infrastructure. Avec l’IGC, on dispose ainsi d’une application unique permettant de mettre en œuvre une politique de sécurité centralisée et de gérer de manière cohérente l’ensemble des identités (clés et certificats) diffusé dans le système d’information étendu.

Fondée sur les principes de la cryptographique asymétrique à base de couples de clés publiques et privées (norme X.509), une IGC fabrique des certificats électroniques, véritables « cartes d’identité numériques », qui établissent un lien irréfutable entre un utilisateur du système d’information et une personne physique. Ces certificats, qui peuvent également être attribués à des éléments matériels (ordinateurs, routeurs…) ou logiciels (applications, applets…), permettent la mise en œuvre entre ces entités de fonctions de sécurité (chiffrement, authentification, signature électronique, intégrité, non répudiation…) dans une confiance mutuelle.

Un projet d’IGC est donc un projet sensible. De même qu’il existe dans la sphère publique des autorités chargées de protéger le respect des identités et des personnes, à l’image de la CNIL en France, une autorité de certification (AC) prend en charge l’IGC avec pour mission de garantir la sécurité des dispositions techniques et non techniques du dispositif, qui concerne potentiellement chaque « citoyen » de l’organisation. La capacité de cette autorité à prouver aux parties prenantes que la solution retenue est adaptée, documentée et appliquée est donc fondamentale. Lorsqu’on a confiance dans l’IGC, on a confiance dans les éléments du système d’information qu’elle est chargée de sécuriser.

Pour y parvenir, le projet d’IGC ne doit pas se résumer à son volet technique et prendre en compte plusieurs aspects complémentaires :

1.les aspects organisationnels
2.les aspects fonctionnels
3.les aspects documentaires spécifiques
4.les aspects d’accompagnement du changement et de formation
5.les aspects réglementaires et juridiques.

1. Les aspects organisationnels

Afin de produire des identités sûres, objectif premier de l’IGC, il convient de mettre en place une organisation cohérente et efficace, permettant de collecter et de contrôler les informations personnelles nécessaires. Pour cela, le projet doit s’appuyer sur l’organisation existante et tenir compte du rôle et des habitudes de chaque entité.

L’état de l’art stipule la nécessité d’un face-à-face avant de délivrer un certificat électronique. Ce recueil d’information est une opération simple, mais qui nécessite de la proximité. La meilleure solution est de passer par l’organisation en place, par exemple via le correspondant RH, le responsable des badges ou le correspondant informatique. Le choix du bon opérateur en fonction des données que l’on souhaite collecter apporte aussi l’assurance que l’éthique et la discrétion nécessaires seront respectées.

Un autre aspect organisationnel concerne la prise en compte des cas d’erreur et du support aux utilisateurs. Il est important de pouvoir garantir à ces derniers qu’ils auront à tout moment la possibilité d’accéder à leur environnement de travail, y compris, par exemple, en cas d’oubli ou de blocage de la carte à puce porteuse du certificat. Cette assurance est essentielle lorsque le certificat est utilisé pour des applications sensibles ou à usage fréquent (messagerie, authentification primaire sur le poste de travail…). En outre, il faut absolument prévoir l’organisation à mobiliser au cas où le porteur oublierait sa carte (ou sa clé USB cryptographique) ou la bloquerait suite à la saisie de plusieurs codes PIN erronés (cas fréquent lors des retours de vacances). Ce peut être une procédure automatisée, à réaliser par le porteur sur la base d’informations connues de lui seul, ou manuelle, avec l’intervention d’un correspondant sécurité.

La définition des responsabilités pour la validation des demandes de certificats ou, plus sensible encore, pour le contrôle des clés de l’AC constitue également un enjeu organisationnel important.

2. Les aspects fonctionnels

Par fonctionnalités de l’IGC, on entend l’ensemble des caractéristiques du processus de gestion du cycle de vie des certificats : création, émission, utilisation, modification, renouvellement, révocation… Un des points cruciaux à ce stade est de conduire une étude approfondie destinée à envisager tous les cas d’utilisation possibles de l’IGC. Celle-ci est en effet généralement déployée pour sécuriser une application ou un système particulier, mais sa souplesse et son universalité la prédisposent à être étendue à d’autres éléments du SI. Cependant, ces évolutions seront d’autant plus aisées qu’elles auront été envisagées en amont car les étapes du cycle de vie sont interdépendantes et, en fonction du niveau de sécurité attendu, la création ou la modification d’un usage peut remettre en cause tout l’équilibre de l’édifice. Or la robustesse et la clarté du système sont des gages essentiels de confiance pour les utilisateurs.

Plusieurs points méritent une attention particulière :

  • l’usage des certificats ;
  • l’organisation retenue ;
  • le système d’information.

On distingue deux grandes familles de certificats aux traitements très différents : les certificats d’authentification et de signature, qui doivent rester sous le contrôle exclusif de leur propriétaire, et les certificats de chiffrement, qui nécessitent pour l’organisme qui les produit la mise en place d’une capacité de sauvegarde et de restitution, notamment pour pouvoir répondre à des obligations légales de déchiffrement. La génération des certificats d’authentification et de signature devra donc se faire au plus près du porteur, dans sa carte à puce ou dans le navigateur de son poste de travail, de manière à éliminer tout risque de copie et garantir la privauté de la clé, garante de sa signature ! Les certificats de chiffrement, au contraire, doivent être générés au niveau central pour qu’une copie puisse être réalisée de façon sûre (fonction de séquestre). Cette copie permettra à l’utilisateur qui perd sa clé privée de la retrouver et surtout de récupérer les données qu’elle aura servi à chiffrer (fonction de recouvrement). Bien que la plupart des solutions techniques d’IGC supporte ces deux fonctions, leur niveau de sécurité ainsi que leur facilité de mise en œuvre varie fortement. L’identification des profils de certificats à produire et des usages autorisés permet donc de spécifier correctement l’IGC et d’éviter bien des écueils : méfiance des utilisateurs, pertes de données, impossibilité de répondre aux enquêtes…

L’organisation retenue a également des impacts directs sur les fonctionnalités de l’IGC. Par exemple, si on choisit un système automatisé pour le déblocage des cartes à puce, il faut sécuriser cette fonction pour s’assurer que seul le porteur pourra activer ce processus. La solution devra donc prévoir une méthode d’authentification secondaire. Il en découle d’autres conséquences fonctionnelles, notamment au niveau de l’enregistrement initial (il faudra des informations personnelles complémentaires) et/ou du processus de délivrance du certificat (il faudra accompagner la production du certificat de l’envoi d’un code de déblocage).

La disponibilité des services de l’IGC est un autre sujet à la frontière de l’organisationnel et du fonctionnel. Alors qu’il est communément admis que la disponibilité de la fonction de production des certificats n’est pas critique – à modérer en fonction des usages – la disponibilité de la fonction de révocation est fondamentale car elle conditionne la sécurité des applications utilisatrices. Un porteur doit pouvoir demander la révocation de son certificat à tout instant afin d’en interdire immédiatement l’usage (mise sur « liste noire », ou liste de révocation). Dans le RGS, le référentiel général de sécurité édité par l’Administration française, la disponibilité de la fonction de révocation est ainsi un critère de qualité important pour classifier le niveau d’un certificat, d’une à trois étoiles.

Enfin, la réflexion sur les fonctionnalités de l’IGC doit impérativement prendre en compte l’environnement SI existant
. En particulier, l’existence et l’utilisation du référentiel d’entreprise (annuaire) est une préoccupation constante des projets d’IGC. En entrée, on s’appuiera dans certains cas sur l’annuaire d’entreprise pour alimenter le processus d’enregistrement des porteurs et éviter ainsi la ressaisie d’informations. En sortie, l’IGC pourra publier dans l’annuaire les certificats qu’elle produit et les listes de révocation.

3. Les aspects documentaires

Le corpus documentaire qui accompagne l’IGC est fondamental pour instaurer la confiance. Il décrit l’ensemble des dispositions de l’IGC. Il s’adresse à toutes les populations concernées par l’IGC : utilisateurs, exploitants, auditeurs… En charge de l’IGC, l’AC est responsable de l’établissement, de la maintenance et de l’exécution de cet ensemble documentaire, qui comprend quatre documents principaux.

  • La politique de certification (PC) est le document fondateur de l’IGC. La PC explicite la gouvernance de l’infrastructure ainsi que l’ensemble des exigences organisationnelles, techniques et non techniques permettant de garantir la sécurité de l’IGC et l’exactitude des identités. L’état de l’art préconise une PC pour chaque type de certificat.
  • La déclaration des pratiques de certification (DPC) rassemble toutes les procédures et les actions visant à garantir les conditions d’exploitation de l’infrastructure. De toutes natures, les sujets abordés concernent les procédures d’habilitation du personnel, les conditions d’accès physique aux bâtiments, les procédures de sauvegarde des données, la sécurité des réseaux… La DPC permet de garantir globalement la sécurité de l’IGC.
  • Le document de cérémonie des clés détaille les conditions et précise les actions à réaliser lors de la cérémonie des clés. Cette cérémonie correspond à la mise en production de l’IGC, c’est-à-dire la génération de la bi-clé de l’autorité de certification (AC) et sa mise en service pour permettre la production des certificats. Désormais, l’AC est identifiée par son propre certificat, dont la clé privée lui sert à signer électroniquement les certificats qu’elle produit.
  • Les conditions générales d’utilisation (CGU) est un document destiné aux utilisateurs de l’IGC, c’est-à-dire les porteurs de certificat. Il précise les modalités d’utilisation des certificats. Ce document sensibilise aussi le porteur à l’indispensable protection du dispositif de stockage du certificat et détaille les modes opératoires ou les contacts en cas de problème.

4. L’accompagnement du changement et la formation

C’est l’un des points cruciaux des projets d’IGC. Idéalement, une formation doit être dispensée à toutes les populations concernées. Les administrateurs et exploitants de la solution seront formés à l’outil informatique et aux conditions d’exploitation décrites dans la DPC. Les opérateurs (chargés du recueil des informations, du support de premier niveau…) constituent la cible prioritaire car ils sont les garants de l’exactitude des informations recueillies et le visage de l’IGC : pour les utilisateurs, avoir confiance dans le dispositif, c’est d’abord avoir confiance en eux. Et de leur formation découlera leur efficacité et leur légitimité. Enfin, les utilisateurs doivent être sensibilisés aux bénéfices mais aussi aux exigences de l’IGC au moyen d’une communication adéquate, adaptée à la culture et aux usages de l’organisation. En l’absence d’accompagnement, le risque est grand de voir se multiplier les mauvaises manipulations et s’installer une défiance envers un « flicage » ou une « dérive sécuritaire ».

Par exemple, lorsqu’on souhaite activer la fonction « smart card login » de Windows pour sécuriser la connexion au poste de travail, l’usage du certificat électronique devient obligatoire pour tous les utilisateurs du SI. Un tel déploiement nécessite un large plan de communication afin de préparer et former les collaborateurs aux changements. On insistera sur les apports individuels et collectifs de cette technologie : souligner que le poste de travail ne pourra plus être utilisé à l’insu de son propriétaire, qu’un code PIN à quatre chiffres remplacera un mot de passe compliqué qu’il faut de plus changer fréquemment…

5. Les aspects réglementaires et juridiques

La dimension réglementaire et juridique doit être prise en compte en fonction du contexte de mise en œuvre de l’IGC.

L’utilisation de moyens cryptographiques est soumise à des contraintes juridiques particulières. Cette préoccupation est renforcée lorsqu’interviennent des opérations de chiffrement. Si la vente de certificats électroniques est envisagée, l’autorité de certification délimitera clairement sa responsabilité. Enfin, le respect de l’identité devra également être considéré et, le cas échéant, un dossier sera déposé auprès des autorités (la CNIL en France).

Pour les projets dans le secteur public en France, l’aspect réglementaire sera notamment abordé au travers des normes édictées par le RGS (référentiel général de sécurité). La conformité de l’IGC au RGS doit être validée par un audit externe. Si l’organisation souhaite être rattachée à l’IGC Racine de l’Administration française (IGC/A), et qu’elle entre dans son champ d’application, il lui faudra se rapprocher de l’ANSSI (ex-DCSSI) pour s’assurer que la PC de son IGC est compatible avec celle de l’IGC/A.

Untitled-1

Durée de vie des certificats

Conclusion

L’examen des divers points à traiter lors de la mise en œuvre d’une IGC montre la diversité des compétences nécessaires, au-delà des seuls aspects techniques. Identifier l’organisation à mettre en place, conduire le changement et tenir compte des impacts juridiques sont des facteurs-clés du succès du projet et de l’acceptation de la solution par l’ensemble des parties prenantes : porteurs, mais aussi direction, opérateurs, chargés d’exploitation…

Grâce à une vingtaine de projets conduits ces dernières années dans des contextes très variés, Bull bénéficie d’une réelle expérience sur chacun de ces points et sur la façon de les aborder de manière globale, cohérente et méthodique. Bull est ainsi en mesure d’accompagner de bout en bout les organisations afin de mettre en place une infrastructure de gestion de clés et d’en faire une infrastructure de confiance.

 

 

 

Comments are closed.