PKI n'est pas une simple software pour votre organisation. Il s'agit d'une infrastructure critique. C'est le fondement de la confiance numérique qui offre un moyen fiable de contrôler l'accès et de connecter en toute sécurité des appareils, des charges de travail et des personnes à grande échelle.
Par conséquent, la création et la maintenance de PKI nécessitent des investissements et des efforts considérables. Aujourd'hui, cet investissement est plus que jamais mis à l'épreuve par les nouveaux cas d'utilisation, l'exploitation des vulnérabilités, la fin de vie de software et les risques futurs posés par les technologies quantiques. technologie quantique obligent les organisations à repenser leurs stratégies.
Spécifiquement, Microsoft PKI, mieux connu sous le nom d'Active Directory Certificate Services (ADCS), a été la solution de facto PKI pour de nombreuses organisations depuis son introduction en 2000. C'est logique : cette solution est intégrée aux serveurs Windows, elle est relativement facile à mettre en place et elle est assez bien intégrée à l'écosystème Microsoft.
Mais nous sommes en 2024 et les temps ont changé. Le paysage informatique est presque méconnaissable par rapport à celui d'il y a 20 ans ; le nombre de cas d'utilisation et le volume de certificats ont considérablement augmenté. Cette situation a conduit de nombreuses organisations à se demander s'il est temps de remplacer leur ADCS. Quelle est la réponse ? Ce n'est pas simple, mais voici quelques éléments importants à prendre en compte lors de l' évaluation des besoins de votre organisation, qui peuvent vous aider à répondre à cette question une fois pour toutes.
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.
En 2008, ADCS a de nouveau évolué, avec l'ajout du serveur NDE, qui n'est en fait que le Simple Certificate Enrollment Protocol (SCEP), qui existe depuis 2000. SCEP a été développé à l'origine pour obtenir des certificats sur les routeurs Cisco, et comme il a été étendu à un plus grand nombre de cas d'utilisation, il a repoussé les limites de la sécurité. L'objectif de ce changement était de répondre aux besoins des téléphones mobiles, et il est devenu la norme pour obtenir des certificats sur les téléphones et les vulnérabilités de SCEP ont commencé à faire 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.
C'est à ce moment-là que nous avons commencé à nous développer en dehors des réseaux d'entreprise et des centres de données, en progressant vers l'informatique dématérialisée comme nouvelle méthode de travail. Cette évolution nécessitait une authentification. Nous avions besoin de cryptage, et c'est ainsi que des protocoles comme EST et ACME ont vu le jour - pour faciliter les déploiements dans le nuage. C'est un domaine dans lequel Microsoft n'a pas été à la hauteur. Le site Microsoft CA n'a pas été suffisamment développé pour répondre à ces nouveaux cas d'utilisation. Au lieu de cela, nous avons assisté à des ajouts itératifs de serveurs et à des mises à jour mineures de fonctionnalités, mais pas d'amélioration majeure pour rester à jour avec ce dont les équipes avaient besoin pour être pour réussir avec PKI.
En conséquence, les équipes de sécurité ont dû soit faire face à des problèmes de gestion avec des certificats se trouvant à plusieurs endroits différents, soit se contenter de solutions manuelles qui ne fonctionnent pas bien à l'échelle. L'ère du cloud dans laquelle nous évoluons aujourd'hui est une question d'échelle. Et bien qu'il existe des produits complémentaires que vous pouvez brancher dans divers environnements ADCS, les équipes sont encore très limitées par le fait qu'ADCS n'a jamais été conçu pour fonctionner dans des environnements en nuage.
Heureusement, il existe aujourd'hui de meilleures options. Nous avons assisté à l'émergence de nouvelles technologies d'AC mieux adaptées à l'ère du cloud - des technologies qui ont non seulement été conçues intentionnellement dès le départ pour nos environnements modernes, mais qui sont également continuellement développées dans cette direction. Tout cela est particulièrement important à l'ère des années 2020, avec une main-d'œuvre distante et hybride et l'utilisation généralisée des appareils IoT . Par exemple, nous voyons apparaître de nouvelles normes telles que Matter, qui ouvre la voie à l'utilisation de PKI pour sécuriser les appareils IoT et de leur fournir des identités uniques grâce à des efforts tels que la signature du micrologiciel.
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.
Aujourd'hui, d'autres changements se profilent à l'horizon : la migration vers des algorithmes post-quantiques. migration vers des algorithmes post-quantiques. Un nouvel ensemble d'algorithmes sera bientôt normalisé, et les organisations examinent déjà ce que cela signifie pour elles et commencent à se préparer à les adopter. Malheureusement, l'ADCS n'a pas encore indiqué ce qu'il allait prendre en charge et dans quels délais pour ces nouveaux algorithmes.
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.
Cela commence donc à entraîner des certificats tronqués, ce qui crée la panique dans l'organisation, et il est très perturbant de devoir faire demi-tour et reconstruire PKI dans une contrainte de temps très spécifique. contrainte de temps très spécifique car c'est là que les erreurs ont tendance à se produire.
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.
Si certaines organisations disposent d'une équipe dédiée aux opérations PKI , dans de nombreux cas, il s'agit d'un travail à temps partiel pour un employé à temps plein. En général, nous constatons de grandes lacunes en matière de compétences PKILes opérations : on ne peut pas aller à l'école pour PKI, et il n'y a pas de grands livres qui traitent de la façon de s'occuper de son infrastructure au quotidien. Par conséquent, beaucoup d'organisations s'appuient sur des connaissances héritées pour savoir comment leur PKI est géré. Mais dans ce cas, lorsque des personnes quittent l'organisation et que les choses ne sont pas documentées correctement, des problèmes surviennent. Et chaque fois que vous faites quelque chose, vous ébranlez les fondations de la sécurité, ce qui laisse votre organisation dans une mauvaise position. Personne n'a l'intention de dégrader la sécurité, mais c'est ce qui arrive lorsque l'on continue à appliquer des pansements et à ajouter de nouveaux cas d'utilisation sur une base défaillante.
3) Difficultés de croissance
Avec l'augmentation du volume et de la vitesse d'émission des certificats, les équipes ont besoin de plus de protocoles, d'intégrations et d'infrastructures, les équipes ont besoin de plus de protocoles, d'intégrations et d'infrastructures pour les prendre en charge. Et dans de nombreux cas - en particulier récemment parmi les équipes qui s'appuient sur ADCS - le site PKI ne peut tout simplement pas prendre en charge ces cas d'utilisation.
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)
Il suffit d'une seule vulnérabilité pour que tout s'écroule. Selon un rapport récent de la NSA et de la CISAl'une des dix principales erreurs de configuration en matière de cybersécurité est le déploiement d'ADCS non sécurisés.
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? Inscrivez à 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.
