Windows Server 2025 / Ce que fait AD CS et comment planifier une PKI interne

Les services de certificats Active Directory (AD CS) émettent et gèrent les certificats organisationnels. Avant de déployer ce rôle, concevez la hiérarchie de confiance, les autorisations d'inscription, la révocation, le renouvellement, la récupération et les responsabilités d’exploitation pour les utilisateurs, appareils et services prévus.

Décidez si une AC interne est nécessaire

AD CS peut faire fonctionner une autorité de certification (AC) au sein d'une infrastructure à clés publiques (Public Key Infrastructure, PKI). Une AC signe des certificats reliant une identité à une clé publique. Les clients doivent faire confiance à cette autorité et valider le certificat pour l'utilisation prévue.

Le renouvellement répété des certificats Web internes ou l'authentification des appareils gérés peut justifier une PKI organisationnelle. Une AC interne ne bénéficie pas automatiquement de la confiance de tous les navigateurs. Les certificats émis par une autorité publiquement reconnue peuvent mieux convenir aux services publics utilisés par des clients non gérés.

Commencez par consulter l'aperçu d'AD CS et dressez un inventaire des PKI organisationnelles existantes ou des services de délivrance gérés. Un site HTTPS unique ne nécessite pas automatiquement le déploiement d'une nouvelle AC.

Définissez la hiérarchie et les limites de confiance

Une AC racine hors ligne et une AC émettrice en ligne sont une conception à évaluer selon l'échelle, les menaces et la capacité de récupération. Plus de niveaux n'améliorent pas automatiquement la sécurité.

Utilisez les considérations de conception PKI pour décider des noms des AC et des serveurs, de la protection des clés, des durées de vie et des URL de publication avant l'installation. Ne considérez pas le renommage d'un serveur AC déjà installé comme un ajustement de routine. Envisagez la séparation de la gestion et la protection des clés avant de combiner une AC avec un contrôleur de domaine.

Limitez les droits sur les modèles et les demandes de certificats

Les modèles de certificats définissent l'usage, les règles de gestion des clés, la durée de validité et les conditions de demande. L'extension Extended Key Usage (EKU) indique des usages tels que l'authentification serveur ou client. La délivrance trop large de certificats pouvant prouver une identité peut permettre l'usurpation d'identité.

• Séparez les demandeurs des responsables de l'approbation et de l'émission.
• Décidez si les demandeurs peuvent choisir les noms inscrits dans les certificats et comment ces noms seront vérifiés.
• Limitez l'accès aux clés privées et n'autorisez leur exportation que si elle est nécessaire.
• Réservez l'inscription automatique aux usages et groupes approuvés, puis surveillez les échecs et les certificats délivrés.

Examinez le potentiel d'abus avant d'accorder des autorisations de modèle larges à des groupes tels que Utilisateurs authentifiés. Séparez l'administration de l’AC, des certificats et des serveurs ordinaires selon le cas. Consultez les directives sur la sécurité, la délégation et l'audit de l’AC.

Exploitez les chemins de révocation et de renouvellement

Planifiez la révocation des certificats pour les clés compromises, les utilisateurs partants et les serveurs retirés. Une liste de révocation de certificats (CRL) publie les certificats révoqués ; l'extension Authority Information Access (AIA) identifie les informations sur l'émetteur et les emplacements d'accès associés. Les chemins de validation requis doivent être accessibles par les clients réels.

La publication DNS ou LDAP réservée à un usage interne peut être inadaptée pour les clients externes. Une AC arrêtée n’invalide pas immédiatement tous les certificats émis, mais les interruptions dans l’émission, le renouvellement et la publication de révocation ont des effets distincts. La politique de l’application et du client influence également le comportement de validation.

Coordonnez le renouvellement des certificats de l’AC racine, de l’AC émettrice et des services. La demande d’une longue durée de vie pour un service ne remplace pas la validité restante et la politique de l’émetteur. Vérifiez le certificat présenté par un service, et non simplement la présence d’une nouvelle entrée dans le magasin.

Documentez la protection des clés et la reprise avant le déploiement

La compromission de la clé privée d’une AC peut toucher l'ensemble du périmètre de confiance. Envisagez un module de sécurité matériel (HSM), des accès d'administration restreints et des responsabilités séparées lorsque cela est approprié. Planifiez des sauvegardes prises en charge des clés, de la base de données, de la configuration, de la politique et des informations de publication avec un accès restreint et une procédure de reprise testée.

1. Recensez les systèmes qui utilisent des certificats, leurs usages et les besoins prévus.
2. Désignez un responsable et expliquez la réutilisation d'une PKI existante ou la nécessité d'en créer une nouvelle.
3. Concevez la structure des AC, la protection des clés, les modèles, les droits et la distribution de la confiance.
4. Définissez la publication de révocation, les alertes de renouvellement, les sauvegardes et la reprise dans un environnement isolé.
5. Validez l'émission, les noms, le renouvellement, la révocation et la reprise dans un environnement de test distinct.

Le livrable ici est une liste de contrôle de conception et de révision. N'installez pas d'AC sur le serveur de cours DC1 et ne distribuez pas de racine de test aux appareils réels dans le cadre de cet exercice de planification. Une décision de déploiement nécessite des procédures maintenables et un plan de suppression de confiance ou de transition de service.