Exemples d’architecture et choix
Sommaire
I. Présentation
Puisque les types d'autorité de certification n'ont plus de secrets pour vous, il est temps d'imaginer l'architecture à déployer selon le contexte. En effet, l'architecture de la PKI peut s'appuyer sur un ou plusieurs niveaux, comme nous le verrons dans la suite de ce chapitre.
II. Choix de l'architecture AD CS
A. Combien de niveaux ?
L'exigence en matière de sécurité n'est pas la même partout, que l'on soit une banque, une industrie ou encore un artisan. Aussi, un équilibre entre nombre de niveaux et niveau de sécurité est à trouver.
B. Combien de serveurs d'autorité ?
Plusieurs raisons vont vous conduire à déployer plusieurs autorités :
- L'isolation : stocker d'un côté les certificats utilisateurs/postes et de l'autre les certificats serveurs, ce qui évite de mélanger,
- La répartition de charge : elle évite qu'une seule autorité héberge tous les certificats délivrés et ainsi, que sa base de données soit d'une taille contenue,
- Réagir si compromission : si une autorité est compromise, il faut réémettre tous les certificats délivrés par cette autorité.
C. Ajouter le rôle AD CS sur un serveur existant, c'est possible ?
L'assistant d'ajout de rôle ne vous en empêchera certes pas, mais si la machine est un contrôleur de domaine Active Directory cela implique une vulnérabilité plus importante si le rôle est mal sécurisé. De plus, cela compliquera clairement une future montée de version Active Directory (changement de contrôleur de domaine vers une machine dont la version de système d'exploitation est supérieure).
Une recommandation forte : installer le rôle AD CS sur une machine dédiée !
III. Exemples d'architecture AD CS
A. Un seul niveau
Dans cette architecture, on trouvera un seul serveur jouant le rôle d'autorité délivrante. Il s'agira, habituellement, d'une autorité racine de type Enterprise, pour son intégration à l'Active Directory.
À réserver, à des organisations qui ont peu de besoins de certificats ou qui cherchent la simplicité d'installation et d'exploitation. Pour des structures atteignant 500 utilisateurs, il m'a été fréquent de voir ce type d'implémentation.
B. Autorité de certification à deux niveaux
Dans ce contexte, on trouvera un serveur d'autorité racine + une autorité intermédiaire. L'autorité racine est idéalement de type autonome (standalone, et donc en groupe de travail), mais parfois elle peut être de type Enterprise pour des raisons de simplification d'exploitation. Dans les deux cas, on préfèrera qu'elle soit éteinte pour ne pas l'exposer.
Quant à l'autorité intermédiaire, elle est de type Enterprise et en ligne.
L'avantage de cette architecture : son extensibilité. En effet, il sera simple d'ajouter un nouveau serveur d'autorité pour de nouveaux besoins. Fréquent pour des environnements autour de 1 000 utilisateurs.
C. Autorité de certification à deux niveaux étendus
Il s'agit d'une architecture plus généralement retenue pour des organisations de 2 000 utilisateurs ou plus.
On y trouve :
- Une autorité racine autonome éteinte
- Deux autorités intermédiaires de type Enterprise.
Le niveau de sécurité est optimum dans cette architecture, mais son exploitation est plus complexe.
D. Autorité de certification hybride
Architecture plus évoluée qui consiste à ne pas mettre tous ses œufs dans le même panier, en ayant recours à une technologie différente de celle de Microsoft pour établir l'autorité de certification racine.
Il m'a été donné de voir une autorité racine construite via HashiCorp Vault, elle-même émettrice de deux certificats d'autorités intermédiaires à destination de machines sous Windows Server. Ces dernières étant des autorités de type Enterprise, elles permettent l'accès à l'inscription automatique de certificats (auto-enrollment), grâce à l'intégration dans l'Active Directory.
L’avantage de cette solution est qu’elle évite de devoir gérer un serveur Windows supplémentaire pour y héberger le rôle d’autorité de certification racine. Même s’agissant d’une autorité éteinte, l’installation de mises à jour, le renouvellement du mot de passe administrateur local, ou encore la publication d’une nouvelle liste de révocation sont autant de charges d’exploitation.
En outre, l’autorité racine ne sera, de fait, pas vulnérable aux attaques qui tentent d’exploiter des failles de sécurité Microsoft.
Enfin, l’autorité racine peut être configurée en infrastructure-as-code avec Terraform, et accessible via des API.
E. Autorité de certification multi-forêts
Dernier exemple d'architecture qu'il m'a été amenée de déployer : une plateforme mutualisée d'autorités de certification.
Imaginez un groupe qui dispose de plusieurs entités. Chaque entité possède une forêt Active Directory. Pour éviter de devoir déployer une plateforme de PKI par forêt afin de répondre aux besoins locaux en termes de certificats, on peut opter pour l'installation d'autorités dans une forêt de ressources.
Une configuration spécifique dans chaque forêt permettra de consommer des certificats issus de cette forêt de ressources.
IV. Tableau comparatif
Architecture | Convient pour | Avantages | Inconvénients |
|---|---|---|---|
Un seul niveau | Des structures avec des besoins de sécurité limités | - Facile à administrer - Offre les modèles et l’intégration à l’AD | - L’autorité racine est allumée et plus susceptible d’être attaquée - Impossible de révoquer l’autorité si elle est compromise sans devoir réémettre tous les certificats - Évolution d’architecture (extension) plus difficile |
| À deux niveaux | Des organisations avec des besoins modérés de certificats pour un seul cas d’usage (utilisateur par exemple) | - Facilité d’évolution d’architecture | - Aucune possibilité de restreindre les autorités ou les Administrateurs - HSM recommandé, donc coût additionnel - Exploitation plus complexe |
À deux niveaux étendus | Des organisations avec des besoins fréquents de certificats pour plusieurs cas d’usage | - Facilité d’évolution d’architecture - En cas de compromission d’une autorité, possibilité de la reconstruire en ne réémettant que les certificats de cette autorité, et pas tous les certificats | - HSM recommandé, donc coût additionnel - Exploitation plus complexe |
Hybride | Les organisations avec un niveau avancé de sécurité | - Surface d’attaque réduite - Meilleure résistance en cas d’attaque - Pas de gaspillage de ressources avec une autorité racine éteinte - Infrastructure-as-code possible | - Niveau technique demandé très avancé |
Multi-Forêts | Les organisations multi-forêts ou multi-domaines qui souhaitent centraliser la plateforme de PKI. | - Meilleure utilisation des ressources - Contrôle centralisé et non distribué qui garantit un meilleur contrôle et donc une meilleure sécurité | - Implémentation plus complexe qu’une plateforme d’autorités par domaine/forêt - Exploitation plus complexe du fait des délégations inter-domaines/forêts |
V. Conclusion
Maintenant que vous disposez d'une vision plus claire des architectures possibles, vous avez probablement fait votre choix. Il nous faut regarder à présent qui peut faire quoi sur les autorités, au travers des rôles d'administration.
