Cinq choses à savoir sur Microsoft PKI

Microsoft PKI, aka Active Directory Certificate Services (ADCS), has been a reliable tool for decades. But it’s time to say goodbye.

Pendant plusieurs années après sa sortie au début des années 2000, ADCS a été le "choix sûr" (ou, dans certains cas, le seul choix) pour les organisations qui cherchaient à mettre en œuvre PKI. Aujourd'hui, cependant, il est devenu l'une des vulnérabilités les plus importantes dans l'infrastructure des organisations qui l'utilisent.

Pourquoi cette solution est-elle si risquée ? Examinons les cinq principaux risques de sécurité et les limites de Microsoft ADCS, ainsi que les différentes options pour aller de l'avant.

Les 5 principaux obstacles à la prise en charge des besoins informatiques des entreprises modernes par Microsoft ADCS

Malheureusement, dans l'environnement actuel, Microsoft ADCS comporte des risques de sécurité potentiels qui peuvent donner à votre site PKI l'impression d'être un boulet plutôt qu'un composant essentiel de votre infrastructure de sécurité. Dans cette optique, voici les cinq principaux risques et limites que toute équipe utilisant ADCS devrait connaître :

1) L'ADCS a un don pour la mauvaise configuration

ADCS is not inherently insecure, but it is deceptively easy to misconfigure. Over the past few years, security researchers have found several exploits and vulnerabilities due to these widespread misconfigurations, to the point where it was actually listed as one of the top 10 cybersecurity misconfigurations in 2023 by the NSA and CISA.

Les erreurs de configuration les plus courantes sont les suivantes :

• Permissions excessives
• Modèles de certificats mal configurés
• Paramètres de contrôle d'accès non sécurisés
• Vulnérabilités dans le système d'exploitation Windows, NDES, etc.

Pour être clair, même en dehors d'ADCS, une mauvaise configuration est possible avec PKI lorsque vous émettez de nouveaux certificats. Cela dit, la manière dont ADCS est souvent mis en place et utilisé ouvre généralement la porte à davantage d'opportunités de mauvaise configuration. Cela s'explique en grande partie par le fait qu'il est très difficile de trouver de la documentation sur ADCS, de sorte que les administrateurs bien intentionnés qui tentent de trouver des conseils pour éviter certains de ces problèmes sont souvent dans l'incapacité de le faire.

Par exemple, il existe plusieurs moyens dans ADCS de permettre accidentellement à des personnes de demander des certificats avec le contenu qu'elles souhaitent - ce qui peut conduire à une attaque par élévation de privilèges, entre autres risques. Par exemple, cela signifie que des personnes peuvent obtenir un certificat qui les authentifie en tant que quelqu'un d'autre. De même, en ce qui concerne Microsoft NDES, il existe des produits tiers qui vous demandent de désactiver les mots de passe de défi sur votre point de terminaison NDES, ce qui signifie que toute personne sachant où se trouve ce point de terminaison peut demander des certificats avec toutes les informations qu'elle souhaite, y compris les identifiants d'autres personnes dans l'entreprise, comme votre directeur financier, votre directeur général ou l'un de vos administrateurs principaux. Il ne s'agit là que de deux exemples parmi tant d'autres qui permettent d'inclure dans les certificats un contenu non vérifié ou insuffisamment vérifié.

2) L'ADCS n'est pas prêt à quitter le nid

According to the 2023 State of Cloud survey by HashiCorp, 76% of companies have or plan to implement a multi-cloud strategy. Against this backdrop, Keyfactor and the Ponemon Institute found that flexible deployment is the most important feature for today’s organizations when evaluating PKI solutions.

Mais le problème est que plus de la moitié des organisations déclarent que leur site PKI existant n'est tout simplement pas capable de prendre en charge les nouvelles applications dont elles ont besoin lorsqu'elles migrent vers l'informatique en nuage. Pour de nombreuses organisations, ce site PKI existant est ADCS, qui ne fonctionne pas bien dans ces environnements en nuage. 

Plus précisément, parce qu'ADCS fonctionne sur Active Directory, cette connexion crée des défis majeurs lorsqu'il s'agit d'opérer dans un environnement en nuage. Ces défis sont les suivants :

• Difficulté à prendre en charge la conteneurisation et l'automatisation
• Pas d'options pour la haute disponibilité active-active (uniquement active-passive avec les serveurs Microsoft Cluster)
• Impossibilité de s'ouvrir aux ports DCOM/RDP et à d'autres exigences du réseau, étant donné que les communications dans le nuage nécessitent un éventail de ports beaucoup plus large que sur le site. 

3) L'ADCS ne parle pas l'informatique moderne

PKI prend en charge en moyenne entre 10 et 20 applications différentes dans l'ensemble de l'entreprise dans des environnements modernes. Cela va des machines IIS et Linux aux équilibreurs de charge et aux charges de travail en nuage. Et lorsqu'il est confronté à ces cas d'utilisation modernes, ADCS commence à montrer son âge et à présenter de sérieux défis. 

Les cas d'utilisation modernes dans lesquels l'ADCS pose les plus grands problèmes sont ceux où l'on travaille avec :

• Environnements multi-cloud et multi-OS
• Appareils non Windows
• Protocoles modernes tels que ACME, EST et CMPv2
• API REST

C'est inquiétant, car des éléments tels que EST et ACME sont très largement utilisés dans les environnements web actuels. Les API REST sont également très courantes, et bien que Microsoft ait introduit certaines API basées sur le web à partir de Server 2012, elles ne couvrent pas tous les besoins des organisations et sont plus encombrantes dans les scénarios multiplateformes. En général, l'incapacité de mettre quelque chose derrière un équilibreur de charge basé sur le web pour traiter les demandes de certificats, qui offre une approche plus moderne pour appeler des services et des fonctions basés sur le cloud, est l'un des principaux obstacles à l'utilisation d'ADCS dans un environnement multi-cloud ou hybride-cloud. C'est d'ailleurs de là que provient une grande partie de la prolifération de PKI , car si votre PKI actuel ne peut pas prendre en charge des cas d'utilisation clés, les équipes iront chercher quelque chose d'autre qui peut le faire.

4) L'ADCS peut devenir complexe (et coûteux)

ADCS peut devenir très complexe et coûteux à grande échelle, principalement parce que Microsoft CA n'est pas multi-locataire. Lorsque vous atteignez une certaine échelle, vous avez besoin de plusieurs serveurs et bases de données, dans certains cas jusqu'à 70 ou 80 serveurs supportant le site PKI. 

En effet, ADCS vous limite à une autorité de certification par machine, ce qui signifie que si vous avez besoin d'installer plus d'autorités de certification - soit pour gérer l'échelle, soit pour différents cas d'utilisation, segments de réseau, limites de confiance ou autres - vous avez besoin d'au moins une autre machine virtuelle, ce qui représente une autre licence Windows Server et un autre système que vous devez sauvegarder, patcher et mettre à jour. Il s'agit d'une limitation qui n'existe pas dans la plupart des autres options de services de certificats, qui offrent de nombreuses possibilités de créer des autorités de certification supplémentaires qui ne sont pas aussi coûteuses du point de vue de l'encombrement informatique.

Tout cela conduit à un autre défi : les équipes commencent à maintenir un grand nombre de solutions de contournement pour faire fonctionner ADCS, mais le coût du support de ces solutions de contournement et de leur maintenance au fil du temps devient plus élevé à mesure que le reste de l'écosystème évolue et n'est plus compatible avec ADCS. De plus, ADCS devient une sorte de "homebrew" d'entreprise qui n'est connu que d'une très petite poignée d'informaticiens. Et au fur et à mesure des départs, la connaissance de ces solutions de contournement se dégrade à un point tel qu'il devient potentiellement risqué de les maintenir en service.

5) L'ADCS n'a pas beaucoup changé

En fin de compte, ADCS n'a pas beaucoup changé au fil des ans. En fait, il n'a pas connu de mises à jour majeures depuis Server 2012. Cela signifie que lorsque de nouvelles normes et de nouveaux cas d'utilisation apparaissent, les utilisateurs d'ADCS ne sont pas pris en charge et sont contraints de trouver des solutions de contournement ou d'opter pour d'autres options.

ADCS n'a jamais été un élément stratégique de software pour Microsoft ; il a plutôt été un moyen de résoudre certains cas d'utilisation, comme les déploiements sur site, l'émission de certificats pour des choses comme SCCM ou SCOM, et la prise en charge de l'authentification Wi-Fi et VPN. Et il résout toujours très bien ces cas d'utilisation. Mais comme il n'est pas stratégique pour Microsoft, il n'a jamais été mis à jour de la même manière qu'Office, Windows OS et Azure.

Microsoft a actuellement une capacité d'émission de certificats basée sur le cloud qui sera intégrée à Intune, mais pour l'instant, elle ne sert qu'à émettre des certificats pour Intune, et ne remplace donc pas ADCS. Et comme Microsoft continue d'investir dans Azure, il est moins probable que nous assistions à des investissements dans tout ce qui est sur site, comme ADCS. 

La seule exception pourrait concerner les algorithmes post-quantiques, car l'ensemble du secteur devra prendre en charge les algorithmes post-quantiques une fois que les normes du NIST auront été renforcées. Actuellement, cependant, l'ADCS ne prend pas en charge certains des protocoles et formats de certificats les plus récents, tels que Matter, SSH et V2X.

Quelle est la suite des événements ?

ADCS convenait parfaitement aux cas d'utilisation traditionnels sur site, mais dans notre monde moderne et multicloud, il présente de sérieuses limites. Quelle est donc la voie à suivre pour les organisations qui utilisent ADCS ? Plusieurs options s'offrent à elles :

• Status quo: One way to fill the gaps of ADCS is to pair it with other solutions for specific use cases (such as PKI built into developer tools or cloud services like AWS Private CA and Google Cloud CA Service). But having so many different issuers can also create complexity, as you wind up with fragmented tools that don’t offer consistent visibility or control.
• Augment: You can augment your ADCS alongside those other PKI solutions with certificate management, which offers a standardized interface and central place to gain visibility and control across all your different issuers.

• Modernize: Taking it one step further, you can simplify and consolidate onto a modern PKI alternative. A modern solution (like Keyfactor’s EJBCA) can support the diversity of current environments, including use cases, platforms, and cloud services found in enterprises today. These important capabilities allow for a smooth migration to a multi-cloud environment and support more modern protocols. If you’re ready to learn more about modernizing, contact Keyfactor here.
• Migrate: Finally, you can offload the infrastructure and maintenance of PKI by migrating to a SaaS-based or managed PKI service. This approach isn’t for everyone, but it can be a good fit for teams who don’t have the resources or bandwidth to run PKI in-house anymore.

Dans l'ensemble, quelle que soit l'approche adoptée par les équipes, nous assistons à un vaste mouvement vers PKI dans le nuage. Pour réussir ce changement, les équipes doivent adopter une approche plus moderne de PKI, et heureusement, de nombreuses options existent.

Ready to take charge of your PKI? Our team is ready to help your PKI enter the modern age. Let’s connect.