Concevoir une PKI AD CS à deux niveaux : racine hors ligne, autorités émettrices de niveau 0 et modèles maîtrisés
Les services de certificats Active Directory sont souvent installés sur un seul serveur, au détour d'un projet Wi-Fi ou VPN, puis laissés en l'état pendant des années. Or une autorité de certification d'entreprise peut émettre des certificats permettant de s'authentifier comme n'importe quel compte du domaine. Sa conception mérite le même soin que celle des contrôleurs de domaine.
Pourquoi deux niveaux
Une PKI à un seul niveau place la clé de l'autorité racine sur un serveur en ligne, joint au domaine, qui traite les demandes au quotidien. Si ce serveur est compromis, toute la hiérarchie l'est, sans possibilité de révoquer proprement l'autorité. L'architecture à deux niveaux sépare les rôles :
- une autorité racine autonome, hors ligne, non jointe au domaine, qui ne sert qu'à signer les certificats des autorités émettrices et à publier sa liste de révocation ;
- une ou plusieurs autorités émettrices d'entreprise, jointes au domaine, qui délivrent les certificats aux utilisateurs, ordinateurs et services.
En cas de compromission d'une autorité émettrice, la racine peut la révoquer et en certifier une nouvelle, sans redistribuer la confiance racine à tout le parc. Un troisième niveau n'apporte généralement qu'une complexité supplémentaire, sauf besoins organisationnels particuliers.
L'autorité racine hors ligne
La racine reste éteinte et isolée la plupart du temps. On ne l'allume que pour signer un certificat d'autorité émettrice ou republier sa CRL. Points de conception :
- une durée de validité longue pour le certificat racine et une durée de publication de CRL adaptée, souvent plusieurs mois, pour limiter les cérémonies ;
- un calendrier de republication de la CRL, avec une alerte bien avant son expiration : une CRL racine expirée peut bloquer la validation de tous les certificats ;
- un stockage physique protégé, des sauvegardes de la clé et une procédure documentée, exécutée en présence de plusieurs personnes ;
- un fichier
CAPolicy.infpréparé avant l'installation pour fixer les paramètres de base.
Les autorités émettrices sont de niveau 0
Une autorité d'entreprise est publiée dans le magasin NTAuth de la forêt : les certificats qu'elle délivre peuvent servir à l'authentification par carte à puce ou PKINIT auprès des contrôleurs de domaine. Quiconque contrôle cette autorité, ou peut obtenir d'elle un certificat au nom d'un administrateur, contrôle le domaine. Elle doit donc être administrée exclusivement depuis le niveau 0 : comptes dédiés, postes d'administration sécurisés, sauvegardes protégées, aucun agent ou outil de gestion relevant d'un niveau inférieur.
Constat fréquent. Nous trouvons régulièrement des autorités émettrices administrées par l'équipe réseau ou système de niveau 1, ou dont les sauvegardes, contenant la clé privée, sont accessibles à un large groupe d'opérateurs. Dans les deux cas, le niveau 0 est de fait étendu à ces personnes.
L'hygiène des modèles
La majorité des chemins d'escalade connus sur AD CS proviennent des modèles de certificats et des droits associés. Règles de conception :
- Publier le strict nécessaire : retirer des autorités les modèles inutilisés.
- Interdire au demandeur de fournir le sujet sur les modèles permettant l'authentification, ou imposer une approbation par un gestionnaire.
- Restreindre les droits d'inscription aux groupes qui en ont réellement besoin, et éviter « Utilisateurs authentifiés » ou « Ordinateurs du domaine » sur les modèles sensibles.
- Limiter les usages de clé (EKU) au besoin réel ; proscrire les modèles « tout usage » ou sans EKU.
- Contrôler les droits de modification sur les modèles et sur l'autorité elle-même.
- Désactiver ou protéger l'inscription web en HTTP, exposée aux attaques par relais NTLM.
Publication CRL et AIA, et recours au HSM
Chaque certificat indique où trouver la liste de révocation (CDP) et le certificat de l'émetteur (AIA). Privilégiez des points de publication HTTP hautement disponibles, accessibles à tous les clients y compris hors domaine ; les emplacements LDAP posent problème aux systèmes non joints. Surveillez l'expiration des CRL de base et delta, car une CRL indisponible ou expirée provoque des échecs d'authentification difficiles à diagnostiquer.
Un module matériel de sécurité (HSM) protège les clés privées contre l'extraction, même par un administrateur du serveur. Il est fortement recommandé pour les autorités émettrices les plus sensibles, et sa pertinence pour la racine se discute selon le contexte. Il ajoute des contraintes : coût, sauvegarde des clés selon les mécanismes propres au fabricant, quorum d'administration, compatibilité avec la version de Windows. Ces éléments doivent être tranchés avant l'installation, car migrer une clé existante vers un HSM est délicat.
Ce qu'un audit vérifie
- La hiérarchie en place et l'état réellement hors ligne de la racine.
- Le calendrier et la surveillance de la publication des CRL.
- Le classement des autorités émettrices en niveau 0 et l'identité de leurs administrateurs.
- Les modèles publiés, leurs droits d'inscription, l'option de fourniture du sujet et les EKU.
- L'exposition de l'inscription web et sa protection contre le relais NTLM.
- La protection des clés privées et de leurs sauvegardes.