Il est peut-être temps de remplacer votre autorité de certification Microsoft : 4 points essentiels à prendre en compte

PKI is not just another software for your organization. It’s critical infrastructure. It’s the foundation of digital trust that provides a reliable way to control access and securely connect devices, workloads, and people at scale. 

As a result, PKI requires serious investment and effort to build and maintain. And today, that investment is being tested more than ever as new use cases, vulnerability exploits, software end-of-life, and future risks posed by quantum technology are forcing organizations to rethink their strategies.

Specifically, Microsoft PKI, which is better known as Active Directory Certificate Services (ADCS), has been the de facto PKI solution for many organizations since it was first introduced in 2000. It makes sense: It’s baked into Windows Servers, it’s relatively easy to set up, and it’s pretty well integrated with the Microsoft ecosystem. 

But it’s 2024 now, and times have changed. The IT landscape is almost unrecognizable from 20 years ago; the number of use cases and the sheer volume of certificates has grown significantly. This situation has led many organizations to ask if it’s time to replace their ADCS. So what’s the answer? It’s not cut and dry, but here are important areas to consider as you evaluate your organization’s needs that can help you answer that question once and for all.

Comment le rôle de PKI a évolué depuis la publication de l'ADCS

Vous vous souvenez de l'an 2000 ? Les téléphones tournaient, les CD sautaient et il fallait 10 minutes pour démarrer un ordinateur. Nous sortions tout juste de l'ère des dotcoms, l'iPod venait de révolutionner la musique et l'internet commuté mourait à petit feu. C'est aussi l'année où Microsoft a officiellement introduit les services de certificats, comme on les appelait à l'origine.

Les services de certification reposaient sur des listes d'utilisateurs statiques et sur l'authentification NTLM. À l'époque, PKI était encore une infrastructure monolithique très onéreuse que les organisations dépensaient beaucoup d'argent pour installer et faire fonctionner. Mais au fur et à mesure que les entreprises se mettaient en ligne, le besoin de certificats augmentait, ce qui a ouvert la voie à une évolution très rapide de la technologie, en particulier PKI.

Au cours de la décennie suivante, les smartphones ont explosé, tout comme la gestion des appareils mobiles, car les entreprises avaient besoin de méthodes d'authentification pour s'assurer que ces appareils pouvaient être fiables et connectés en toute sécurité au réseau. Nous avons également découvert l'informatique en nuage, avec l'arrivée sur le marché d'AWS, de Google App Engine et de Microsoft Azure.

Dans ce contexte, Microsoft a apporté de modestes améliorations aux services de certification en 2003 et en 2008.

En 2003, les services de certification ont été intégrés à Active Directory et sont devenus officiellement ADCS. À ce stade, il ressemblait davantage à un site PKI qu'à sa précédente itération et répondait assez bien aux besoins de la plupart des organisations à l'époque. Il s'agissait de cas d'utilisation tels que l'ajout d'un certificat sur cet appareil mobile ou pour ce réseau Wi-Fi, ou l'activation d'une bonne authentification sur des postes de travail gérés à distance. Il est important de se rappeler que c'était avant le transfert des charges de travail vers le nuage. À l'époque, le nuage était un mécanisme de stockage plus qu'autre chose, car aucun travail significatif ne s'y déroulait encore. 

In 2008, ADCS matured again, with the addition of NDEs server, which is really just Simple Certificate Enrollment Protocol (SCEP) that had actually been around since 2000. SCEP was originally developed for getting certificates on Cisco routers, and as it was extended to a larger set of use cases, it pushed the boundaries of security.  The purpose of this change was to meet the needs of mobile phones, and it became the standard for getting certificates on phones and vulnerabilities in SCEP started to surface (VU#971035 – Simple Certificate Enrollment Protocol (SCEP) does not strongly authenticate certificate requests)

Dans les années 2010, les technologies hybrides et multi-cloud ont fait leur apparition et DevOps a commencé à s'imposer. Nous sommes entrés dans l'ère de l'automatisation et de la conteneurisation, ce qui signifie que les certificats étaient soudainement nécessaires pour authentifier toutes sortes d'appareils et de services, et pour protéger les communications de machine à machine.

Rapidement, une pléthore d'outils DevOps a été construite autour de cet écosystème - y compris la montée en puissance de Hashicorp, Terraform et Vault, ainsi que des émetteurs de certificats natifs du cloud, comme AWS Private CA, JetStack manager, et Google CA service. Toute cette croissance a rendu le paysage des certificats beaucoup plus complexe. 

This is really when we started to expand outside of corporate networks and data centers, progressing into the cloud as a new way of working. And that shift required authentication. We needed encryption, and that’s how protocols like EST and ACME came about – to help facilitate cloud deployments. This is an area with which Microsoft did not keep up. The Microsoft CA has been woefully underdeveloped to meet these new use cases. Instead, we saw iterative server additions and minor feature releases but no major uptick to stay current with what teams needed to be successful with PKI.

As a result, security teams have either had to face management challenges with certificates living in multiple different places, or they’ve had to make do with manual solutions that don’t work well at scale. The cloud era in which we now operate is all about scale. And while there are add-on products you can plug into various ADCS environments, teams are still very much constrained by the fact that ADCS was never designed to work in cloud environments.

Fortunately, better options now exist. We’ve seen the emergence of new CA technologies better suited for the cloud era – ones that were not only designed intentionally from the start for our modern environments, but that are also continually developed in that direction. All of this is especially important in the 2020s era of remote and hybrid workforces and the widespread use of IoT devices. For example, we’re seeing new standards like Matter, which is setting the pace for PKI usage to secure IoT devices and provide unique identities for them through efforts like firmware signing.

Mais en ce qui concerne Microsoft PKI, il ne s'est pas passé grand-chose dans la dernière version de 2022. Microsoft a toutefois annoncé récemment la prochaine version de Microsoft Cloud PKI, mais cette version semble encore très axée sur l'utilisation sur site. Cela dit, nous ne disposons pas d'une vue d'ensemble de la situation puisqu'elle n'a pas encore été publiée.

Now, we have more change on the horizon: the migration to post-quantum algorithms. There’s a new set of algorithms that are soon to be standardized, and organizations are already looking at what that means for them and starting to prepare to adopt them. Unfortunately, there has been no acknowledgment from an ADCS standpoint of what they are going to support against what timelines for these new algorithms.

4 scénarios courants qui poussent PKI à son point de rupture

À travers tous ces changements, des scénarios communs sont apparus qui poussent PKI à son point de rupture et obligent les entreprises à envisager un changement :

1) Expiration de la racine ou fin de vie

L'expiration de la racine est tout simplement inévitable et peut prendre de nombreuses formes. Outre l'expiration de l'autorité de certification racine, l'autorité de certification émettrice peut expirer, ou les serveurs ou HSM derrière votre PKI peuvent arriver en fin de vie. Quelle que soit la situation, dans la plupart des cas, elle nécessite une reconstruction complète de votre PKI à partir de la base. 

Pour de nombreuses organisations, ce scénario se présente comme suit : L'autorité de certification émettrice commence à émettre de nouveaux certificats qui ne sont valables que pendant 13 mois alors que le modèle indique qu'ils devraient être valables pendant deux ans. Après une inspection plus approfondie, il s'avère qu'un élément de la chaîne expire dans 13 mois, et l'une des règles de PKI est qu'il n'est pas possible d'émettre un certificat dont la durée de validité est supérieure à la durée de vie de la chaîne.

So that starts to drive truncated certificates, which creates panic in the organization, and it is very disruptive to have to turn around and rebuild PKI under a very specific time constraint because that’s when mistakes tend to happen.

2) Rotation du personnel et déficit de compétences

PKI n'est pas seulement software, c'est une infrastructure critique dont la durée de vie est prédéterminée. Souvent, cette durée de vie dépasse celle de l'employé qui l'a créée. Lorsque cela se produit, PKI est souvent jeté comme une patate chaude sur les genoux de quelqu'un d'autre, et la situation continue ainsi.

While some organizations have a dedicated team behind PKI operations, in many cases it’s a part-time job for a full-time employee. Generally, we see big skills gaps around PKI: you can’t go to school for PKI, and there aren’t any really great books that address how to care for your infrastructure daily. As a result, a lot of organizations work on legacy knowledge to know how their PKI is run. But in those cases, when people leave organizations and things aren’t documented properly, problems ensue. And every time you do something, you chip away at the foundation of security, which leaves your organization in a bad place. It’s not anyone’s intention to degrade the security, but that’s what happens when you keep applying band-aids and adding new use cases on top of a failing foundation.

3) Difficultés de croissance

As the volume and velocity of certificate issuance grows, teams need more protocols, integrations, and infrastructure to support that. And in many cases – especially recently among teams relying on ADCS – the PKI simply can’t support those use cases.

Cela a conduit les organisations à mettre en œuvre des solutions ponctuelles en fonction des besoins, ce qui nous a amenés au point où les équipes ont aujourd'hui en moyenne neuf solutions PKI/CA. Si tout est correctement géré, ce nombre peut être acceptable, mais dans la plupart des organisations, il existe des points d'émission de certificats disparates qui sont apparus pour des besoins très spécifiques. Lorsqu'il n'existe pas de solution globale pour l'ensemble d'une organisation, les problèmes de croissance deviennent très fréquents et il est difficile de comprendre d'où viennent les choses et pourquoi elles prennent certaines mesures.

Idéalement, les organisations devraient avoir deux sources d'émission de certificats : une pour toutes les ressources internes et une pour celles qui doivent être publiquement enracinées, comme SSL/TLS. Si vous pouvez consolider cette infrastructure autant que possible, vous réduirez le risque, le coût et la maintenance de votre PKI.

4) Risque (connu et inconnu)

All it takes is one vulnerability for it all to fall apart. According to a recent report from the NSA and CISA, one of the top ten cybersecurity misconfigurations is insecure ADCS deployments. 

Malheureusement, il existe de nombreux points connus de mauvaise configuration qui peuvent rendre ADCS non sécurisé. D'une manière générale, il est très facile de commettre des erreurs, qu'elles soient dues à d'autres distractions ou à des erreurs innocentes telles que la configuration de l'inscription automatique pour un certain type de certificat qui donne accidentellement à tous les membres de l'organisation un certificat de signature de code. 

Ces cas se produisent trop souvent et créent de graves vulnérabilités dans l'infrastructure, obligeant les organisations à repenser l'ensemble de leur configuration.

Est-il temps de remplacer votre PKI?

La question de savoir s'il est temps ou non de remplacer votre site PKI est une question à laquelle chaque organisation doit répondre par elle-même, mais c'est quelque chose que vous pouvez idéalement déterminer avant d'atteindre un point de rupture qui vous force la main.

Par conséquent, si vous voyez votre organisation se diriger vers l'un des scénarios courants ci-dessus - ce qui est très probable si votre fondation est basée sur ADCS, qui n'a pas été conçu pour l'échelle, la vitesse ou les cas d'utilisation basés sur le cloud que l'environnement d'aujourd'hui exige - la réponse peut très bien être oui.

Prêt à prendre en charge votre PKI? Notez dans votre agenda la série de webinaires de Keyfactor, qui explore les risques et les limites de l'utilisation de Microsoft PKI aujourd'hui et la façon dont les organisations migrent vers des alternatives modernes.