II. Architecture▲
Tous les FQDN et noms de domaines utilisés ne sont pas réels et sont pris à titre d'exemple seulement.
Une PKI à deux niveaux requiert deux serveurs de certification. Le premier serveur sera la racine de notre infrastructure : il
va s'auto-certifier. On parle de racine puisque les certificats sont gérés sous forme d'arbre. Le deuxième serveur, approuvé par
la racine, va délivrer des certificats au réseau. L'autorité racine est complètement indépendante du réseau et du domaine Active
Directory. Cette autorité doit être éteinte et placée en sécurité pour éviter tout vol de sa clé privée. Si cette autorité est
compromise alors toutes les autorités inférieures ainsi que tous les certificats peuvent être compromis. Il faudra alors tout
révoquer pour régénérer de nouveaux certificats.
La deuxième autorité de certification est intégrée au domaine Active Directory. Cela va lui permettre de délivrer des certificats
aux utilisateurs ou serveurs connus dans l'Active Directory. Pour des raisons de sécurité, il est conseillé de placer l'autorité
de certification sur un serveur indépendant. Bien qu'il soit possible d'installer l'autorité sur un contrôleur de domaine, ce
n'est pas conseillé. Nous aurons donc trois serveurs : une autorité racine totalement indépendante et éteinte, un contrôleur de
domaine et une autorité de délivrance intégrée au domaine Active Directory.
Windows 2008 est utilisé pour le contrôleur de domaine. Le niveau fonctionnel du domaine n'a pas d'influence sur le fonctionnement de la PKI. Vous pouvez également utiliser Windows 2003, la méthode d'installation et de configuration est quasiment identique : seules les fenêtres de configuration ne sont pas identiques. Il n'y a que peu de différences avec Windows 2008 R2. Vous aurez également besoin d'un DNS fonctionnel. Afin de rendre vos certificat racine et liste de révocation disponibles sur votre réseau, vous devrez mettre en place un serveur web hébergeant ces fichiers. Il est nécessaire de fixer les chemins d'accès à ces fichiers au préalable et de s'y conformer. Si les fichiers ne sont pas accessibles via les chemins déterminés, votre PKI fonctionnera mal. Lorsque vous commencerez à installer la PKI, vous aurez le choix entre deux types d'autorité.
II-A. Autorité autonome ou entreprise ?▲
Le choix doit être réfléchi puisque vous n'aurez pas la possibilité de changer simplement le type de votre autorité. Si vous décidez de changer, vous devrez supprimer votre autorité pour la réinstaller. Cela n'est pas sans risque, notamment au niveau de la conservation des clés.
II-A-1. Autonome▲
Voici les scénarios d'utilisation d'une autorité autonome (standalone) :
- Utilisable pour une autorité éteinte racine ou intermédiaire
- Pas besoin de personnaliser les modèles de certificats
- Besoin d'une forte sécurité et politique d'approbation
- Peu de certificats à approuver et le travail requis pour l'approbation est acceptable
- Clients hétérogènes et ne pouvant pas bénéficier d'un accès à Active Directory
- Certification à travers le protocole SCEP pour les routeurs
Si votre PKI doit délivrer des certificats pour un nombre limité de clients (quelque soit leur type) et que vous souhaitez une approbation manuelle, l'autorité autonome sera sans doute le meilleur choix. Attention cependant à l'évolutivité de votre réseau. Si à plus ou moins long terme vous souhaitez augmenter le nombre de clients (serveurs, utilisateurs, routeurs), il sera sans doute plus intéressant de commencer dès maintenant avec une autorité entreprise.
II-A-2. Entreprise▲
Voici les scénarios d'utilisation d'une autorité entreprise :
- Un grand nombre de certificats devra être approuvé automatiquement
- La disponibilité et la redondance sont requises
- Les clients utilisent Active Directory
- L'approbation automatique doit être modifiée
- Les modèles de certificats doivent être modifiés, dupliqués ou créés
- L'archivage et la restauration des clés dans un dépôt spécifique
Si votre PKI doit délivrer un nombre important de certificats et que vous souhaitez avoir le choix entre une délivrance manuelle ou automatique des certificats, vous choisirez une autorité entreprise. Cette dernière s'intègre dans Active Directory ce qui permet de gérer des droits d'accès basés sur les objets Active Directory.
II-A-3. Recommandations de Microsoft▲
Voici un tableau résumant les recommandations de Microsoft quant au type d'autorité à utiliser selon le type de l'autorité (racine, intermédiaire, délivrance).
| Type de l'autorité | 3 niveaux | 2 niveaux | 1 niveau |
|---|---|---|---|
| Racine offline | Standalone | Standalone | Entreprise |
| Intermédiaire offline | Standalone | ||
| Délivrance online | Entreprise | Entreprise |
II-B. DNS : Point crucial de votre infrastructure▲
II-B-1. Nommage des serveurs▲
Le serveur rootca est totalement indépendant et ne devra pas être connecté au réseau. Il faudra cependant un média pour récupérer le certificat racine ainsi que la liste de révocation associée. Ce média servira également à transférer le certificat permettant l'activation de l'autorité de distribution. Nous avons trois serveurs : contrôleur de domaine, serveur web et autorité de certification. Le serveur web est un composant essentiel dans une PKI puisqu'il va permettre aux clients de récupérer les listes de révocation ainsi que le certificat racine permettant d'établir une confiance envers les serveurs de l'entreprise. Nous utiliserons les noms suivants pour les serveurs :
- Contrôleur de domaine : domain-controller.developpez.adds
- Autorité de certification : ca.developpez.adds
- Serveur web : services.developpez.com
II-B-2. Nom de domaine privé/public ?▲
Pourquoi utiliser developpez.adds et developpez.com ? developpez.adds est le nom de domaine Active Directory et n'est donc pas accessible sur Internet. developpez.com est un nom de domaine public donc accessible sur Internet. Une PKI peut être utile pour proposer des services sécurisés à des clients qui connaissent votre société. Il suffira que les clients téléchargent le certificat racine pour faire confiance à vos services sécurisés. Cela va s'avérer utile pour des solutions de portails client (basés sur Sharepoint par exemple) ou pour faire des téléconférences grâce à Office Communication Server. Il est donc conseillé de placer les certificats et les listes de révocation de votre autorité racine et de distribution sur un serveur accessible portant un nom public. Ce serveur pourra être publié ou non sur Internet selon votre utilisation. Il sera plus confortable d'utiliser dès le début un nom public pour ce serveur : vous n'aurez pas à modifier vos autorités de manière conséquente en cas de changement. Notre serveur web qui met à disposition les certificats des autorités et les listes de révocation devra être accessible depuis votre réseau interne comme depuis Internet. Afin d'éviter à vos postes internes d'aller sur Internet pour aller chercher un certificat racine ou la liste de révocation, nous utiliserons un "split-DNS".
II-B-3. Utilisation du split-dns▲
Le split-dns consiste en l'utilisation de deux serveurs DNS au lieu d'un pour desservir une zone particulière. Dans notre cas, nous allons utiliser deux serveurs DNS pour la zone developpez.com. Un des serveurs DNS sera utilisé pour les clients de votre réseau interne et le deuxième serveur sera utilisé pour les clients venant d'Internet. Typiquement, nous allons ajouter la zone developpez.com dans le DNS de l'Active Directory. Ce DNS étant connu uniquement des postes internes, les postes Internet n'y auront pas accès et utiliseront le DNS public. Votre DNS de l'Active Directory contiendra la zone publique developpez.com et contiendra des enregistrements pointant vers vos serveurs internes (avec des IP privées). Votre DNS étant inaccessible depuis Internet, les postes Internet ne sauront pas que votre serveur de publication de liste de révocation sera en 10.0.0.1 par exemple. Mais comment font les postes internes ? Vos postes internes sont configurés avec le DNS de l'Active Directory. Ce dernier étant autoritaire sur la zone developpez.com (interne), vos postes vont récupérer les IP privées. Nous allons créer les mêmes enregistrements dans la zone privée et la zone publique. Ces derniers porteront les mêmes noms mais pas les mêmes valeurs. D'une manière logique, la zone hébergée par Active Directory contiendra des enregistrements à IP privée alors que la zone publique (qu'elle soit gérée par vous ou votre fournisseur de domaine) contiendra les IP publiques de vos serveurs publiés.
II-C. Architecture suggérée▲
II-C-1. Schéma▲
L'architecture réseau est classique avec une DMZ et un LAN. Dans la DMZ, nous mettons le serveur web qui distribuera les listes de révocation et le certificat racine afin que les clients externes à notre entreprise puissent faire confiance à nos services sécurisés. Je n'ai pas inclus dans cet exemple de solution de type reverse-proxy mais le fonctionnement reste identique. Si votre entreprise a choisi d'héberger elle-même le DNS public gérant votre domaine, il se trouvera en DMZ. L'Active Directory, le DNS interne et votre serveur de certificats seront dans le LAN.
II-C-2. Fonctionnement▲
Pour valider les certificats émis par votre PKI, les clients internes vont utiliser le certificat racine stocké dans leur magasin de certificats d'autorités de certification racines de confiance. Le certificat racine de votre PKI sera distribué par Active Directory. Pour finaliser la validation des certificats émis par votre PKI, les clients internes iront demander l'IP du serveur de listes de révocation auprès du DNS hébergé sur l'Active Directory. Ce dernier va renvoyer l'IP privée du serveur web hébergé en DMZ. Les clients iront alors télécharger les listes de révocation sur ce serveur.
Pensez à contrôler que vos postes clients sont autorisés à communiquer avec la DMZ au niveau du firewall en HTTP ou HTTPS selon la configuration de votre serveur web.
Votre architecture Active Directory n'est pas disponible sur Internet. Qui plus est, les clients Internet ne seraient pas autorisés sur l'Active Directory. Les clients ne pourront pas récupérer automatiquement le certificat racine de votre PKI. Il faut donc mettre ce dernier à disposition sur votre serveur web pour que les clients puissent authentifier vos différents services web publics. Les clients demanderont alors la résolution de noms auprès de votre DNS public. Ils pourront alors télécharger et installer votre certificat racine et récupérer les listes de révocation afin de valider la confiance envers vos serveurs.