Limites des services de certificats Microsoft Active Directory

Auteur Uwe GradeneggerPublié le Catégories Active Directory, Haute disponibilité, Protocole de statut des certificats en ligne (OCSP), Service d'enregistrement des périphériques réseau (NDES), Sécurité, Système d'exploitation Windows, Services web d'enregistrement des certificats, Autorité de certification, Cluster d'organismes de certification, Base de données des organismes de certification, Enregistrement web des autorités de certification (CAWE)

Die Active Directory Certificate Services bestehen (wenn auch unter anderem Namen) in ihren Grundzügen seit Windows NT 4.0. Die heutzutage verwendete auf Active Directory basierende Architektur wurde mit Windows 2000 Server eingeführt. Die AD CS sind sehr gut in das Windows-Ökosystem integriert und erfreuen sich weiterhin weltweit großer Beliebtheit in Unternehmen und Behörden jeglicher Größenordnung.

On évoque volontiers les nombreuses possibilités offertes par les Active Directory Certificate Services. Mais on ne parle que rarement de ce qu'ils permettent de faire. pas est possible. En effet, le produit a atteint ses limites à de nombreux endroits.

Lesquels sont décrits plus en détail ci-dessous, afin de pouvoir mieux décider si les AD CS peuvent être la bonne solution pour les projets prévus.

Généralités

Le produit n'est pas open source, le développement (continu) se fait donc derrière des portes fermées et n'est pas transparent vers l'extérieur. La documentation du produit est en partie obsolète, incomplète et répartie sur de nombreux supports différents (entre autres des livres, des articles disponibles uniquement dans les archives, ainsi que des blogs isolés).

Aujourd'hui (2022), il n'y a plus de développement actif connu du produit par Microsoft (dans la version Windows Server 2022 récemment publiée, AD CS n'a exactement rien changé. Les mises à jour de sécurité ne sont intégrées qu'à moitié). Parfois, même pas bugs connus depuis des années corrigé.

De ce fait, de nombreuses restrictions et des solutions de contournement nécessaires sont désormais nécessaires, la sécurité future est donc pour le moins douteuse.

Aucun produit de remplacement ou de suivi n'est actuellement disponible ou annoncé par Microsoft en tant que service cloud dans Microsoft Azure.

Actuellement, il n'existe pas non plus de plan connu pour traiter le thème de la cryptographie post-quantique (certificats composites/hybrides) en relation avec les AD CS, la cryptoagilité est limitée en raison de la dépendance aux bibliothèques cryptographiques du système d'exploitation Windows. Les algorithmes modernes tels que EdDSA (particulièrement intéressant pour les cas d'application IoT, d'autres sont déjà allés plus loin) ne sont pas utilisables avec AD CS.

L'auteur Roger A. Grimes, proche de Microsoft, écrit dans son livre "Apocalypse de la cryptographie"Microsoft a au moins testé avec succès l'AD CS avec des algorithmes (expérimentaux) résistants aux quanta, de sorte que ceux-ci pourraient être utilisés (c'est-à-dire, probablement, intégrés dans une nouvelle version du produit) dès que cela sera nécessaire (et que le processus de normalisation sera terminé).

Autorité de certification

Connaissez-vous TameMyCerts? TameMyCerts est un add-on pour l'autorité de certification Microsoft (Active Directory Certificate Services). Il étend la fonction de l'autorité de certification et permet de Application de la réglementationIl s'agit d'un logiciel de gestion des certificats qui permet d'automatiser l'émission de certificats en toute sécurité. TameMyCerts est unique dans l'écosystème Microsoft, a déjà fait ses preuves dans d'innombrables entreprises du monde entier et est disponible sous une licence libre. Il peut téléchargé via GitHub et être utilisé gratuitement. Une maintenance professionnelle est également proposée.

Design

Du point de vue de la technologie PKI, il est possible d'exploiter sans problème plusieurs autorités de certification sur le même serveur. Des fabricants comme MTG, Nexus ou PrimeKey le font déjà avec succès, de même que des projets open source comme OpenSSL ou OpenXPKI.

En raison du lien avec l'identité Kerberos du serveur d'autorité de certification, il est toutefois nécessaire, avec les Active Directory Certificate Services, d'exploiter une instance Windows Server complète par autorité de certification logique.

De même, il faut au moins une autorité de certification par structure globale (forêt) Active Directory (remarque : pour répondre à ce problème, il existe des Solutions de tiers).

Par la suite, il en va de même pour différentes combinaisons de Procédures de hachage (par ex. SHA-1 pour les applications patrimoniales en parallèle avec une hiérarchie utilisant des algorithmes modernes) et types de clés (RSA, ECC).

Dans les grandes entreprises, il est courant que Les autorités de certification peuvent être réparties et limitées par utilisation.Cela conduit inévitablement à un nombre inutilement élevé de serveurs d'autorités de certification, qui doivent tous être gérés, renforcés, mis à jour, maintenus et, en fin de compte, payés.

C'est très ennuyeux, non seulement pour les autorités de certification hors ligne, mais surtout pour celles qui ont besoin de leur propre serveur et qui, malgré le faible volume de certificats, génèrent une charge de travail relative particulièrement élevée en raison de l'absence de gestion centrale.

Mais même la configuration des autorités de certification en ligne ne peut être effectuée de manière centralisée (lorsque c'est judicieux) qu'au prix d'efforts considérables (par exemple avec PowerShell Desired State Configuration (DSC)). Il existe certes projets correspondants(les logiciels de gestion de l'information, qui ne représentent jusqu'à présent que partiellement la fonctionnalité requise).

Un changement de génération entre plusieurs hiérarchies est également soumis à la même restriction et génère un nombre inutilement élevé de serveurs pendant la transition.

L'exploitation de serveurs Windows ne devrait pas être l'activité principale des exploitants d'ICP. Les frais généraux générés par l'architecture obsolète (système d'exploitation, composants de gestion, antivirus, scripts) augmentent rapidement de manière considérable et génèrent, outre une charge système élevée, des coûts correspondants et une empreinte écologique négative qui pourrait être évitée.

La "Fournisseur de stockage de clés"L'interface n'est pas conçue pour être utilisée avec des appliances de réseau. Par exemple, si l'on utilise un module de sécurité matériel réseau (HSM) et que la connexion à celui-ci est interrompue brièvement, le service d'autorité de certification n'est plus en mesure d'utiliser la clé privée de l'autorité de certification, Les demandes de certificat échouent en conséquence et Les listes de blocage ne peuvent plus être délivréesjusqu'à ce que le service d'autorité de certification soit redémarré.

Séparation de l'autorité de certification (AC) et de l'autorité d'enregistrement (RA)

Il n'y a pas de séparation nette entre l'autorité de certification et l'autorité d'enregistrement :

  • Le site Demande de certificat via RPC/DCOM n'est possible que directement contre l'autorité de certification, ce qui signifie qu'une autorité de certification en ligne doit être exposée à tous les clients du réseau, ce qui peut représenter un risque de sécurité accru.
  • La décision de délivrer ou non un certificat est prise directement par l'autorité de certification, et non par une autorité d'enregistrement en amont.
  • Le site Service d'enregistrement des périphériques réseau (Network Device Enrollment Service, NDES) est volontiers désigné comme autorité d'enregistrement, mais ne remplit pas les critères d'une telle autorité. Elle n'est pas en mesure de vérifier et de préfiltrer suffisamment les demandes de certificats. NDES est plus une conversion de protocole qu'une véritable RA. De telles demandes de certificat pourraient toutefois être traitées par un système de certification développé en interne. Module de politique comme TameMyCerts être interceptés du côté de l'autorité de certification (principalement).
  • Il en va de même pour les Enregistrement web des autorités de certification (CAWE).
  • Le site Services web d'enregistrement des certificats (CEP et CES) ne remplissent pas non plus les critères d'une autorité d'enregistrement, car les demandes de certificats sont transmises sans être vérifiées et ne sont évaluées que par le module Policy de l'autorité de certification, c'est-à-dire directement par cette dernière, ce qui signifie qu'il s'agit là aussi plutôt d'une transformation de protocole que d'une véritable autorité d'enregistrement.

Il n'y a pas de support pour l'implémentation d'une véritable haute disponibilité (voir la section Base de données des autorités de certification). Ainsi, le produit n'est en fait pas "adapté aux entreprises".

Routine d'installation

Les paramètres par défaut codés en dur pendant l'installation ou la configuration des rôles...

  • ...nécessitent des autorisations Enterprise Administrator pour l'installation de l'autorité de certification (voir ici aussi la section sur les modèles de certificats). Dans le cas de l'autorité de certification, l'autorisation peut être déléguée, pour NDES, il existe une solution de contournement non officielleDans le cas de la CEP/CES, il n'y a aucune chance que cela se produise, c'est pourquoi l'utilisation dans un environnement d'entreprise conscient de la sécurité n'est possible que de manière limitée, voire pas du tout.
  • ...permettent à chaque autorité de certification installée d'émettre des certificats de connexion à Active Directory en inscrivant le certificat de l'autorité de certification dans le NTAuthCertificates l'objet en question. Cela peut certes être modifié après coup, mais cela va à l'encontre du principe Secure by Design, Secure by Default.
  • ...lient les Modèles de certificats standard pour l'exposition directement après l'installation, si pendant l'installation pas explicitement empêchéIl existe donc un grand risque que des certificats non souhaités/non gérés soient émis directement après l'installation (à ce moment-là, aucune configuration, par exemple de CDP/AIA, ni aucun test de fonctionnement n'ont encore eu lieu).
  • ...le pare-feu Windows donne aussi par défaut pour les Interfaces d'administration à distance de l'autorité de certification libresLes attaques par déni de service ne sont pas autorisées, ce qui augmente inutilement la surface d'attaque.

Intégration Active Directory et modèles de certificats

Les modèles de certificats sont stockés dans l'Active Directory. Dans les grands environnements, ils doivent souvent être créés par une autre équipe via une demande manuelle, ce qui empêche l'automatisation et ralentit les processus.

Il n'existe pas de méthode officiellement soutenue par Microsoft pour scripter, c'est-à-dire automatiser, la création et l'édition de modèles de certificats. Même s'il existe des voies non officielles, même par des (anciens) employés de Microsoft eux-mêmes Microsoft estime que cette approche n'a pas été testée et ne peut donc pas bénéficier d'une assistance produit.

Es können keine individuellen AIA/CDP Adressen über Einstellungen der Zertifikatvorlagen definiert werden. Die Konfiguration gilt immer global für alle ausgestellten Zertifikate einer Zertifizierungsstelle, obwohl dies technisch auf die jeweiligen Zertifikattypen heruntergebrochen werden könnte. Wird hier eine Unterscheidung benötigt, muss eine weitere Zertifizierungsstelle etabliert werden (siehe Abschnitt „Design“).

Les autorités de certification non intégrées dans Active Directory ("standalone") n'ont absolument aucune possibilité de définir des profils de certificats analogues aux modèles de certificats enregistrés dans Active Directory.

Les listes de blocage LDAP peuvent avoir une taille maximale de 10 Mo (en raison d'une limitation dans Active Directory).

L'administration des autorités de certification est liée aux comptes Active Directory de la structure globale correspondante. Dans les grands environnements d'entreprise qui disposent de plusieurs structures globales Active Directory (ne serait-ce que parce qu'il y a aussi un environnement de test et de staging), les administrateurs de la PKI sont donc contraints d'utiliser plusieurs comptes d'utilisateurs pour différents environnements (si aucune position de confiance n'est établie entre les environnements) et les autorités de certification ne peuvent pas être administrées de manière centralisée (c'est-à-dire au-delà des limites de plusieurs structures globales Active Directory) (si - comme c'est généralement le cas - aucune position de confiance n'est établie).

Pour l'authentification et la demande de certificat au-delà d'une position de confiance, celle-ci doit être réciproque.

Comme les serveurs d'autorité de certification sont membres d'Active Directory, ils peuvent également être compromis par ce dernier de multiples façons (stratégies de groupe, connexion de comptes non autorisés avec des droits d'administrateur, comptes de service compromis).

Il en va de même pour la publication de listes de blocage et la demande de OCSP-certificats de signature de réponse. Ceux-ci sont authentifiés à l'aide des mécanismes d'Active Directory, de sorte que les serveurs de listes de révocation/OCSP (souvent connectés à Internet), dont la sécurité est critique, se trouvent généralement dans la même structure globale d'Active Directory que les autorités de certification et sont souvent aussi administrés avec les mêmes comptes. Le risque qu'une compromission d'un serveur de listes de blocage/OCSP se répercute sur les autorités de certification est donc accru.

En outre, pour le répondeur OCSP (si l'on souhaite utiliser la demande et le renouvellement automatiques du certificat de signature de réponse OCSP), il faut implémenter dans chaque structure globale Active Directory une instance propre (de préférence à haute disponibilité) du répondeur en ligne.

Le site Demande de certificat par RPC/DCOM avec et sans auto-enrollment, l'identification du demandeur se résume à son identité Kerberos (sa connexion Windows). Comme celle-ci ne s'effectue en général que par la saisie du nom d'utilisateur et du mot de passe, l'identification du demandeur d'un certificat par l'autorité de certification n'est finalement pas plus forte que la connaissance d'une combinaison nom d'utilisateur/mot de passe.

L'intégration élevée et le marketing correspondant par le nom du produit, qui contient également "Active Directory", amènent de nombreux administrateurs à penser que PKI est égale à Active Directory.

Base de données des organismes de certification

Le nombre de Subject Alternative Names pouvant être émis est limité : Les extensions de certificat peuvent avoir une taille maximale de 4 Ko. (en raison de la limitation de la base de données des autorités de certification)

La base de données des autorités de certification peut gérer au maximum 2 147 483 647 certificats (32 bits ou 4 octets entiers signés, limite du schéma de la base de données). En réalité, la base de données des autorités de certification devient de plus en plus lente lors des interrogations à mesure que sa taille augmente, de sorte qu'elle ne convient guère (si tant est qu'elle le fasse) pour plus de quelques millions de certificats.

En ce qui concerne la protection des données, il convient de noter qu'il n'existe pas non plus d'entretien automatique des certificats expirés (pour répondre à l'exigence de suppression des données à caractère personnel lorsque la finalité de la collecte a disparu). Un tel projet ne peut être mis en œuvre que par script.

La base de données des organismes de certification (Moteur bleu Microsoft JET) est implémentée de manière monolithique par serveur, elle ne peut pas être consolidée sur plusieurs autorités de certification et doit être exploitée directement sur les serveurs respectifs des autorités de certification.

La base de données des autorités de certification permet Interrogation de la base de données uniquement avec les interfaces propriétaires mises à disposition et ce, même de manière limitée, mais ceux-ci ne s'adaptent pas bien aux grandes quantités de données et nécessitent des Workaroundspour pouvoir être utilisé de manière judicieuse. Trop de requêtes simultanées sur la base de données des autorités de certification peuvent même bloquer l'émission de certificats et de listes de révocation.

Elle ne permet pas de rechercher des champs vides (p. ex. un nom commun vide). La seule possibilité est ici d'extraire tous les enregistrements et de rechercher de telles entrées, par exemple avec Windows PowerShell. Avec la taille croissante de la base de données, de telles exportations sont de plus en plus lentes et prennent du temps, de sorte qu'elles ne peuvent parfois même plus être réalisées avec les moyens du bord.

Noms relatifs distigués non définis (RDN)Les noms de domaine, s'ils sont autorisés et utilisés, ne sont pas indexés dans la base de données des autorités de certification.

Elle ne stocke/indexe pas non plus les identités contenues dans les Subject Alternative Names, celles-ci sont uniquement définies par lecture de la base de données des autorités de certification et évaluation programmatique des données brutes de certificat ainsi obtenues possible. Il en va de même pour la nouvelle extension de certificat propriétaire ajoutée en mai 2022La plupart du temps, il s'agit d'une solution de sécurité qui est censée augmenter la sécurité, mais qui passe inaperçue dans les modèles de certificats hors ligne.

La base de données de l'autorité de certification ne permet pas d'effectuer des requêtes avancées dans la base de données comme ce serait le cas avec un système de base de données relationnelle tel qu'un serveur SQL.

Die Zertifizierungsstellen-Datenbank erlaubt keine Speicherung oder Verknüpfung von Metainformationen (z.B. eine E-Mail Adresse des Zertifikatinhabers oder für eine Abrechnung der Leistung erforderlichen Daten) bei manueller Zertifikatbeantragung oder generell die Erweiterung des Datenbankschemas.

La base de données de l'autorité de certification ne permet pas la réplication de la base de données pour un véritable clustering (dans l'implémentation de cluster existante, un seul nœud de cluster peut et doit accéder aux fichiers de la base de données via le système de fichiers, sinon une corruption des données se produit très rapidement, ce qui est diamétralement opposé à la haute disponibilité visée).

Service des autorités de certification

Les modifications de la configuration d'une autorité de certification nécessitent un redémarrage du service avec une interruption correspondante de la disponibilité (voir aussi le thème du clustering).

Module de politique

Le logiciel Windows Default fourni Module politique erlaubt keine Definition von Regeln für manuelle Zertifikatanforderungen. Dadurch entstehen sehr häufig Fehler bei der Ausstellung von Zertifikaten (vergessene Attribute, Syntaxfehler werden nicht erkannt, mehrere CN sind möglich, Falschausstellungen mit sicherheitsrelevanten Auswirkungen etc…).

L'étendue des fonctions du module Policy de l'autorité de certification n'est pas directement extensible. Il existe tout de même Exemples de code pour développer ses propres modules de politique.

Avec TameMyCerts est désormais disponible sous licence open source. Il étend considérablement les fonctionnalités du module Windows Default Policy tout en conservant les fonctionnalités de base fournies par le module original.

Interfaces

A ce jour, les services de certificats Active Directory n'offrent pas de support pour les interfaces suivantes :

Ainsi, la seule interface raisonnablement utilisable pour la demande de certificat est, dans la plupart des cas, la suivante RPC/DCOM bzw. MS-WCCE übrig – eine proprietäre Schnittstelle, die vor über 20 Jahren für On-Premises Infrastrukturen entworfen wurde und nicht annähernd für eine Cloud-native Welt optimiert ist. Die Schnittstelle ist zudem auf Active Directory Authentisierungsverfahren beschränkt und zwingt die Zertifizierungsstellen in das Active Directory Ökosystem.

Les interfaces existantes pour la conversion des protocoles souffrent également d'un nombre non négligeable de restrictions.

Service d'enregistrement des périphériques réseau (NDES)

Les mesures décrites comme Service d'inscription des périphériques réseau (Network Device Enrollment Service, NDES) implémentation connue du protocole SCEP (Simple Certificate Enrollment Protocol) souffre des limitations suivantes :

  • Il n'est pas possible de définir des directives pour la demande de certificat (par exemple, le contenu autorisé du certificat) (mais il est possible de définir des directives pour la demande de certificat). une API pour la propre implémentation d'un module de politique pour lesquels aucun exemple de code ou stub de Microsoft n'est disponible).
  • Pour chaque combinaison d'autorité de certification, de modèle de certificat et de politique de mot de passe (NDES), l'installation d'une instance de serveur Windows autonome est nécessaire. Dans les grands environnements, le nombre de serveurs à exploiter augmentera donc inutilement, tout comme pour les autorités de certification. Il est très irritant de constater qu'avec Intune se soumette également, ainsi que ses clients, à cette restriction.
  • En général, NDES ne peut pas être configuré de manière judicieuse pour la haute disponibilité, car il n'existe pas de mécanisme de réplication pour les mots de passe à usage unique émis.
  • NDES est encore en cours de développement en ce qui concerne les interfaces pour les certificats d'autorité d'enregistrement utilisés. Fournisseur de services cryptographiques (CSP) Les enfants ne voyagent pas dans le monde entier, ils n'ont donc pas droit à une aide financière. courbes elliptiques soutenu.
  • NDES exige inutilement que l'installation soit effectuée avec des droits d'administrateur d'entreprise. Dans les environnements d'entreprise soucieux de la sécurité, cette autorisation n'est pas donnée (à juste titre), et le rôle ne peut donc pas être utilisé (ou seulement via un Solution de contournementLe programme d'aide à l'achat d'un produit peut être utilisé dans le cadre d'un programme d'aide à l'achat d'un produit (qui perd officiellement le soutien du produit).
  • Les certificats d'autorité d'enregistrement nécessaires à l'exploitation sont disponibles dans la base de données fournie par Microsoft. Documentation produit pas du tout utilisé.

Services web d'enregistrement des certificats (CEP/CES)

Les services web d'enregistrement des certificats (CEP/CES) souffrent des limitations suivantes :

Enregistrement web des autorités de certification (CAWE)

Il n'existe pas non plus de self-service utilisateur utilisable sur le web. Le site Enregistrement Web de l'autorité de certification (CAWE) souffre des limitations suivantes :

  • Sie ist hoffnungslos veraltet und wird seit nunmehr fast 20 Jahren nicht mehr aktiv weiterentwickelt.
  • Elle ne prend pas en charge Version 3 (ou plus récente) Modèles.
  • Elle ne prend pas en charge la définition de politiques pour le contenu des certificats (mais peut être utilisée avec le Module de politique de TameMyCerts être mitigé).
  • Une installation directement sur l'autorité de certification n'est pas recommandée pour des raisons de sécurité, une installation sur un serveur séparé nécessite la mise en place de la délégation Kerberos, ce qui Danger par Kerberoasting peut augmenter drastiquement.

Autorité de validation

Le site Répondant en ligne (OCSP) recourt à nouveau aux listes de blocage et non directement à la base de données des autorités de certification. Il existe cependant WorkaroundsLes coûts d'entretien sont plus élevés en raison de l'augmentation des coûts de production.

Ce n'est pas un soutien pour Protocole de validation de certificat basé sur serveur (SCVP) est disponible.

Gestion des certificats

Microsoft commercialise encore le produit FIM/MIM Certificate Management, qui appartient toutefois encore au monde des fournisseurs de services cryptographiques (CSP) et qui, selon les connaissances actuelles, ne recevra plus de nouvelles fonctions. La nouvelle adoption de FIM/MIM CM en 2021 est donc une voie à sens unique.

Liens complémentaires :

Sources externes

Les commentaires sont fermés.

fr_FRFrançais
de_DEDeutsch en_USEnglish fr_FRFrançais