Cet article est le premier d’une série visant à aider le lecteur en vue d’un projet de déploiement d’une Infrastructure à Clés Publiques (PKI)
Introduction et définitions
Depuis toujours il a été nécessaire de protéger des informations sensibles. Il peut s’agir d’informations confidentielles qui ne doivent être connues que par certaines personnes. Mais aussi il y a ce besoin de garantir la provenance et l’intégrité d’une information. Voici quelques exemples parmi tant d’autres : Données militaires, contrats d’affaires, actes authentiques (notaire, avocat)…
L’avènement de l’ère informatique a rendu possible la dématérialisation de l’information. Mais celle-ci a toujours besoin d’être protégée. Par ailleurs, ce « nouveau » média a permis l’émergence de nouveaux usages qui eux aussi ont besoin d’être sécurisés: Achats sur internet, démarches administratives, outils de communication, etc.
Les usages de la PKI
Suffit-il d’assurer la confidentialité des informations? Non, cela ne suffit pas. Des usages de plus en plus complexes rendent nécessaires des services sécurisés de plus en plus variés. On peut lister:
- Confidentialité: Elle permet de s’assurer que seules les personnes destinataires d’une information peuvent y avoir accès. Elle garantit aussi que les personnes non destinataires, bien que pouvant accéder au message chiffré, ne peuvent pas le lire .
- Intégrité: Le but est de garantir que le message n’a pas été altéré de manière volontaire ou involontaire
- Non répudiation: C’est l’assurance qu’aucune des deux parties de l’échange d’information ne pourra nier être à l’origine du message. Notons que ce n’est pas une protection contre un tiers .
- Authentification: Le but est de s’assurer que la personne à l’origine du message est bien celle qu’elle prétend être. Ainsi on valide son identité.
La cryptographie
La sécurisation de l’information se fait à l’aide d’outils cryptographiques. Ces outils se composent de fonctions mathématiques et d’algorithmes. Je ne m’attarderai pas sur se sujet, qui demanderait un article à lui seul (et même plusieurs articles). Mais on peut citer : les fonctions de hachage (MD5, SHA-1, SHA-256…), les algorithmes symétriques (DES, 3DES…), asymétriques (RSA…), l’échange de clés Diffie-Hellman, etc.
La PKI (Public Key Infrastructure) ou IGC en français (Infrastructure de Gestion de Clés) ou encore ICP (Infrastructure à Clés Publiques), a rendu le chiffrement, la signature et l’authentification transparentes pour les utilisateurs. Elle permet la gestion et la protection de certificats numériques. Pour parvenir à cet objectif, elle doit fournir les services suivants:
- Création de clés cryptographiques
- Authentification de clé publique
- Création de certificats
- Remise du certificat au porteur
- Publication de certificat sur un annuaire
- Vérification des certificats
- Révocation des certificats
Etapes d’un projet de PKI
Un projet de déploiement de PKI, comme tout projet informatique, comporte des phases, des personnes, des documents etc. Ces aspects sont très importants et doivent être soigneusement planifiés et conduits. On conduira ainsi le projet à son terme de manière satisfaisante. Il y a en tout 4 étapes: Analyse/Conception, Implémentation, Paramétrage et Audit. Dans ce premier article, nous allons voir et détailler la première étape.
Etape 1: Analyse et Conception
Choix déploiement interne vs prestataire
Tout d’abord, on fera le choix entre une déploiement interne ou par prestataire. Est-ce que la PKI fournira des services pour le grand public? Ou bien pour un usage interne? Est-ce que ce sera plutôt pour échanger avec des partenaires?
Il existe des prestataires de services PSCE* agréés ANSSI (https://lsti-certification.fr/index.php/fr/certification/psce). Les prestataires permettent de réduire les couts de déploiement et d’opération, fournir des certificats dont l’ancre de confiance est déjà présente dans les outils bureautiques ou encore de mutualiser l’utilisation d’un certificat dans plusieurs services (exemple: déclaration de TVA et réponse à appels d’offres).
Mise en place de l’organisation
Equipe projet: Comme pour tout projet, il faut mettre en place une équipe. Il faudra aussi prévoir une phase pilote avec un groupe d’utilisateurs restreint pour roder les procédures. Par ailleurs, on mettra au point un plan de communication, pour accompagner les utilisateurs au changement. Ne pas oublier le plan de formation des acteurs clés ainsi qu’une analyse d’impact sur les applications existantes avec éventuel plan de migration.
Direction de la CA: Elle comprend à minima le RSSI, un juriste, le chef de projet de déploiement. Son rôle est d’approuver PC (Politique de certification) et CPS (Certificate Policy Statement en anglais) ainsi que de les faire appliquer. En outre, elle commandera les audits.
Les ressources : Eh oui, il ne faut pas oublier qu’il faudra des collaborateurs pour opérer la PKI, délivrer et révoquer les certificats, administrer les serveurs, publier les CRL etc. Si le déploiement de la PKI inclut un support physique pour les certificats (carte à puce, token…), il faudra aussi accompagner les utilisateurs pour la gestion des cartes à puces perdues, endommagées, code PIN bloqués etc.
Quels usages
Pour définir les usages de la PKI, il faut lister les besoins:
Pour un certificat utilisateur, s’agira-t-il d’offrir uniquement la signature électronique (de documents, emails etc)? Devra-t-on aussi prévoir du chiffrement (emails, EFS…)? Est-il nécessaire d’authentifier les utilisateurs (ouverture de session Windows, connexion web, VPN, WIFI…)? Des cartes à puce seront-elles déployées pour stocker les certificats?
Quant aux certificats destinées aux serveurs, quels seront leurs usages? Authentification SSL? VPN? WIFI EAP-TLS? Serveur Exchange?
Définition du référentiel de documents
Il faudra définir le référentiel de documents indispensables qui vont servir à bâtir la confiance entre les parties prenantes de la PKI: CP, CPS, CGU (Certificate Policy, Certification Practices Statement, etc). Ces documents doivent être définis, rédigés, versionnés, revus régulièrement. Ils doivent en outre avoir un propriétaire et des contributeurs bien identifiés et stockés en adéquation avec leur niveau de confidentialité (public, privé…).
Coûts et sécurité
Il faudra aussi planifier les aspects « coûts et sécurité ». Les coûts se diviseront en 3 grandes catégories:
- Hardware (serveurs, HSM…)
- Software (licences, SaaS…)
- Setup (budget d’implémentation)
En ce qui concerne la sécurité, il conviendra de déterminer le niveau en fonction de:
- L’usage prévu de la PKI (authentification, chiffrement, signature)
- La sensibilité des informations qui seront protégées par la PKI
- Toute régulation (industrie, gouvernement…) à laquelle l’entreprise doit se conformer
Pensez aussi à définir la protection de la clé privée: Serveur root CA hors ligne? Disque dur dans un coffre? Utilisation d’un HSM?
Par ailleurs, n’oubliez pas de mener une réflexion sur la stratégie de journalisation des événements, d’audit, de cérémonies… Mais on reviendra sur ces points dans les articles suivants.
La PKI étant opérée et maintenue par des personnes ayant des rôles différents, il faut définir des profils types avec les droits associés. Voici un exemple non exhaustif des rôles utilisés dans une CA Microsoft:
- Administrateur CA ou Administrateur PKI : son rôle est de gérer la CA elle même.
- « Certificate Manager » qui délivre et révoque les certificats.
- « Enrollment Agent » souvent utilisé avec les cartes à puces: il va demander le certificat pour le compte d’un utilisateur.
- « Key Recovery Manager » si on utilise l’archivage de clé. Si oui, ce rôle sera responsable de restaurer les clés privées
En dernier lieu, mais tout aussi important, parlons de la sécurité physique. Il faudra certainement prévoir une armoire verrouillée en salle machine. Peut-être un coffre fort, un accès sécurisé, des badges d’authentification…
Choix d’architecture
Le dernier point de cet article concerne le choix d’architecture de votre PKI. Je conseille à mes clients de ne jamais s’en tenir à seulement une Autorité Racine. En effet, en cas de compromission de la clé privée (cela s’est malheureusement déjà produit dans l’industrie), tous les certificats émis par l’autorité devront être révoqués. Inutile d’expliquer les conséquences désastreuses pour l’entreprise concernée et ses clients.
Par conséquent, on prévoira des CA subordonnées sous la CA racine. Un seul niveau de subordination devrait être suffisant pour la majorité des PME. Pour les multinationales, il sera probablement nécessaire de définir un sous-niveau supplémentaire. Cela permet plus de flexibilité et d’autonomie en ce qui concerne les autorités d’enregistrement et la diffusion des CRL.
En tout dernier lieu, pensez à décider de la stratégie de délégation. Hiérarchique si l’on veut permettre à la CA racine (root CA, ancre de confiance) de déléguer son pouvoir de délivrer des certificats à une CA subordonnée (sub CA). Bien entendu on peut définir des restrictions au modèle de confiance: Longueur de chaine maxi, contraintes de nommage, politique de certification et contraintes d’usage.
Vous pourrez aussi opter pour le modèle pair-à-pair : Utile quand deux entités sont en relations d’affaires et que leurs utilisateurs respectifs peuvent se faire mutuellement confiance. Chaque CA va générer et signer un certificat pour l’autre CA. Cela permet à chaque partie de garder le contrôle de sa PKI. Ce modèle est en outre idéal entres organismes distincts et indépendants. Il est aussi souvent utilisé pour les migrations de PKI, ou lorsqu’une entreprise fusionne/rachète une autre.
Dans les prochains articles, nous verrons les autres étapes de déploiement d’une PKI. N’hésitez pas à lire les autres articles de notre blog! ACE MULTIPASS peut vous accompagner dans votre projet de PKI. Contactez-nous ici.
*PSCE: Prestataires de Services de Certification Électronique