Editions ENI Livres | Vidéos | e-Formations
Architectures PKI sécurisées
Introduction
Les architectures d’autorité de certification peuvent être composées d’un ou plusieurs niveaux de hiérarchies.
Les hiérarchies à un seul niveau ne comportent qu’une seule autorité de certification émettrice. Ce type de hiérarchie est simple à implémenter mais déconseillé en production, la compromission de l’unique autorité de certification compromettant la totalité des certificats émis dans l’entreprise.
Les hiérarchies sécurisées à plusieurs niveaux sont composées d’autorités de certification parent et enfant. Elles incluent une autorité de certification racine autonome hors connexion et des autorités de certification secondaire de niveau deux ou trois.
Réduisant considérablement le risque de compromission de l’autorité de certification racine (le serveur est hors connexion), ces architectures simplifient aussi, en cas de compromission, la révocation et le remplacement d’autorités de certification secondaires émettrices.
La sécurité et la montée en charge de l’infrastructure de PKI de l’entreprise sont ainsi très fortement renforcées.
Hiérarchie à plusieurs niveaux
Les hiérarchies de PKI à plusieurs niveaux peuvent comporter, selon les besoins, deux ou trois niveaux.
1. Hiérarchie à deux niveaux
Ce sont les hiérarchies les plus fréquemment implémentées en production, elles offrent le meilleur compromis entre sécurité et complexité.
Dans ce modèle, l’autorité de certification racine (autorité parent) est utilisée uniquement pour délivrer (signer) les certificats des autorités de certification secondaires. Ce sont ces autorités de certification secondaires entreprise qui délivrent les certificats aux utilisateurs et/ou aux ordinateurs du domaine.
Une infrastructure de PKI sécurisée à deux niveaux. L’autorité de certification racine est hors connexion. Le niveau deux correspond à des autorités de certification émettrice d’entreprise.
Sécurité accrue
La sécurité est garantie par une mise hors connexion du serveur hébergeant l’autorité de certification racine. Ce serveur étant arrêté (et donc déconnecté de tout réseau), il est très difficile de compromettre l’autorité de certification racine qu’il héberge.
En cas de compromission d’une autorité de certification...
Particularités d’implémentation
Dans le contexte d’implémentation de hiérarchies d’autorités de certification, certaines particularités d’implémentation doivent être assimilées afin de garantir une mise en production fonctionnelle et pérenne.
Cette section introduit rapidement chacune de ces particularités. Elles seront ensuite abordées de façon très détaillée dans les sections suivantes et mises en pratique dans l’atelier de ce chapitre.
Tâches de pré et postconfiguration
Ces tâches utilisent le fichier CaPolicy.inf pour appliquer des paramètres de préconfiguration et l’utilitaire Certutil pour appliquer les paramètres de post-configuration aux autorités de certification. Certains de ces paramètres ne sont configurables que par ce moyen. Ces tâches autorisent aussi l’automatisation du paramétrage des autorités de certification.
Publication manuelle dans Active Directory
L’autorité racine étant hors connexion il faut publier manuellement ses listes de révocation dans l’Active Directory. Cette tâche est effectuée avec l’utilitaire Certutil et doit être réalisée impérativement avant l’installation et la configuration de l’autorité de certification secondaire....
Fichier CAPolicy.inf
Il est possible d’utiliser un fichier de configuration, CAPolicy.inf, pour définir les paramètres spécifiques aux autorités de certification racines ainsi que les paramètres affectant toutes les autorités de certification secondaires.
Avec le fichier de configuration CAPolicy.inf, ces paramètres sont appliqués dès l’installation de l’autorité de certification.
Le fichier CaPolicy.inf est un simple fichier texte qui peut être créé ou édité avec le programme Bloc-Note (notepad.exe) de Windows.
Pour être pris en compte lors de l’installation ce fichier doit être stocké dans le dossier %windir% et ne pas comporter d’autre extension que .inf.
1. Avantages
Il y a plusieurs intérêts à l’utilisation d’un fichier CaPolicy.inf.
D’abord, cela permet la configuration de paramètres qui ne sont pas disponibles lors de la phase de configuration du rôle (ces paramètres ne sont pas présents dans l’assistant de configuration).
Ensuite, cela permet également d’automatiser les paramètres d’installation. Après validation de ces paramètres lors d’une phase de maquettage, le fichier CaPolicy.inf peut ensuite être réutilisé de façon sûre dans la phase de mise en production. On sécurise et automatise ainsi l’installation.
Le fichier CaPolicy.inf permet également d’avoir une trace documentée des paramètres appliqués et peut être réutilisé en cas de crash complet pour remonter rapidement l’infrastructure de PKI de production à l’identique.
2. Sections du fichier CAPolicy.inf
Plusieurs sections peuvent composer le fichier de configuration CAPolicy.inf.
La bonne compréhension de ces différentes sections étant fondamentale pour une configuration de vos autorités de certification adaptées à votre contexte, elles sont présentées ci-dessous avec leur rôle détaillé et des exemples de contenus.
a. Section Version
La section [Version] est obligatoire et doit absolument apparaître au début du fichier CaPolicy.inf.
Elle spécifie que le fichier INF utilise le format Microsoft Windows NT (qui est destiné...
Tâches de postconfiguration
L’utilitaire Certutil peut également être employé pour automatiser la configuration de certains paramètres qui n’auraient pas été définis dans le fichier de configuration CAPolicy.inf ou par l’assistant de configuration du rôle.
Il permet, en intégrant toutes les commandes dans un fichier de script (fichier Batch), d’automatiser les paramétrages et de garantir un déploiement plus sûr et plus rapide lors de la phase de mise en production.
Dans l’exemple ci-dessous, l’utilitaire Certutil est utilisé pour redéfinir les intervalles de publication des listes de révocation complètes et delta ainsi que la période de chevauchement. Il est ensuite utilisé pour publier une première liste de révocation.
Exemple de fichier commande Certutil pour la configuration de l’autorité de certification après installation.
certutil -setreg CA\CRLPeriodUnits 2
certutil -setreg CA\CRLPeriod "Weeks"
... Configure la publication automatique des listes de révocation
complètes toutes les deux semaines
certutil -setreg CA\CRLOverlapUnits 1
certutil -setreg CA\CRLOverlapPeriod "Weeks"
... Configure le chevauchement des listes de révocation à une semaine
certutil -setreg CA\CRLDeltaPeriodUnits...Publication manuelle dans Active Directory
Le serveur qui héberge l’autorité de certification racine est mis hors connexion (arrêté) dès que l’autorité a été correctement installée et configurée.
C’est cette mise hors connexion qui empêche toute attaque sur l’autorité de certification racine et en garantit la sécurité.
1. Publication manuelle
À cause de cet arrêt prolongé, le serveur de l’autorité de certification racine ne peut pas être intégré à l’Active Directory (cela provoquerait des problèmes au niveau du canal sécurisé établi entre les serveurs et les contrôleurs de domaine et l’intégration au domaine serait perdue).
Le serveur de l’autorité de certification racine ne faisant pas partie du domaine Active Directory, son service de certificat ne peut pas publier automatiquement ses listes de révocation et son certificat dans l’Active Directory.
Il faut donc exporter ces deux éléments sous forme de fichiers pour les publier manuellement dans l’Active Directory.
a. Publication manuelle des listes de révocation
Après avoir été exportées sous forme de fichiers, les listes de révocation de l’autorité de certification racine sont publiées...
Extensions AIA et CDP
La modification des extensions est un des points critiques de l’implémentation réussie d’une hiérarchie de PKI sécurisée.
L’extension de l’accès aux informations de l’autorité indique où trouver les certificats à jour de l’autorité de certification. Ces extensions sont aussi nommées extensions AIA (Authority Information Access - accès aux informations de l’autorité).
L’extension du point de distribution CRL indique où trouver les listes de révocation de certificats à jour signées par l’autorité de certification. Ces extensions sont aussi nommées extensions CDP (CRL Distribution Point - point de distribution des CRL).
Les extensions garantissent que ces informations sont bien incluses dans chaque certificat que l’autorité de certification émet afin qu’elles soient accessibles lors des processus de validation du certificat.
En cas d’impossibilité de récupérer les informations de ces emplacements, les certificats ne sont pas validés et les fonctionnalités/services/applicatifs les utilisant échouent. Il est donc capital de configurer correctement les extensions de l’autorité de certification.
Les extensions sont visibles dans l’onglet Extensions des propriétés de l’autorité de certification.
1. Ajout aux certificats émis
Ces extensions sont incluses dans tous les certificats émis par une autorité de certification.
-
Les extensions définies sur l’autorité de certification racine s’appliquent donc à tous les certificats d’autorité de certification secondaire émis (l’autorité de certification racine n’émet pas d’autres types de certificats).
-
Les extensions définies sur l’autorité de certification secondaire entreprise émettrice s’appliquent donc à tous les certificats émis dans l’entreprise (tout type de certificats utilisateurs et/ou ordinateurs).
2. Accès interne et externe
Les informations de validation AIA et CDP doivent être accessibles en interne et éventuellement en externe (depuis le réseau externe de l’entreprise).
-
Accès...
Méthodologie d’implémentation
La méthodologie d’implémentation d’une hiérarchie de PKI sécurisé multiniveau est la suivante :
-
Création des fichiers CaPolicy.inf
-
Installation de l’autorité de certification racine (hors connexion)
Cette étape installe, configure, et valide le rôle d’autorité de certification racine. Elle implique également la préparation du serveur qui hébergera l’autorité de certification racine. Étant donné que ce serveur sera hors connexion, il ne doit pas être intégré au domaine.
L’ordinateur racine étant un ordinateur à mettre hors connexion il sera très fréquemment installé en production sur un ordinateur virtuel (moins coûteux et plus facile à sécuriser).
-
Publications des listes de révocation et AIA dans l’Active Directory
Cette étape publie manuellement les listes de révocation de l’autorité racine hors connexion dans l’Active Directory.
-
Installation de l’autorité secondaire émettrice
Cette étape implique l’installation, la configuration et la validation de l’autorité de certification secondaire d’entreprise. Étant donné qu’il s’agit de l’autorité émettrice, le serveur...
Atelier : Architecture de PKI sécurisée
1. Objectif
La société Corp souhaite augmenter le niveau de sécurité et la capacité de montée en charge de son infrastructure de PKI en abandonnant l’ancien modèle à un seul niveau pour implémenter une hiérarchie de PKI sécurisé à deux niveaux.
Dans cet atelier pratique, nous allons implémenter une architecture de PKI sécurisé à deux niveaux avec une autorité de certification racine hors connexion et une autorité de certification secondaire émettrice.
Les ordinateurs virtuels utilisés dans cet atelier sont les suivants :
S1 : contrôleur de domaine (Corp.lan)
S2 : autorité de certification racine hors connexion (CorpRootCA)
S3 : autorité de certification secondaire entreprise émettrice (CorpSubEntCA)
Vous pouvez récupérer les ressources associées à cet atelier depuis la page Informations générales.
2. Restauration des points de contrôle
Dans cet atelier nous implémentons une toute nouvelle architecture qui servira aussi de base aux ateliers des chapitres suivants.
Afin de partir d’une configuration propre, nous allons restaurer les points de contrôle effectués dans les ateliers du module Plateforme de test.
Restaurer les serveurs s1 et s3 en domaine
Nous allons restaurer le point de contrôle nommé AD (créé à l’étape Créer un point de contrôle AD du chapitre Plateforme de test).
Dans le gestionnaire Hyper-V, sélectionnez l’ordinateur virtuel s1.
Dans la zone centrale Points de contrôle, faites un clic droit sur le point de contrôle AD et sélectionnez le menu Appliquer.
Si une boîte de dialogue de confirmation s’affiche, cochez la case à nouveau sur le bouton Appliquer.
Suivez la progression de restauration de l’ordinateur virtuel (colonne statut).
Après restauration complète, redémarrez le serveur.
Répétez les manipulations précédentes pour appliquer le même point de restauration AD au serveur s3.
Restaurer le serveur s2 en Workgroup
Nous allons restaurer le point de contrôle nommé Base (créé à l’étape...
