Rejoignez Keyfactor à la RSA Conference™ 2024 | du 6 au 9 mai | En savoir plus

Cinq choses à savoir sur Microsoft PKI

PKI

Microsoft PKI, alias Active Directory Certificate Services (ADCS), est un outil fiable depuis des décennies. Mais il est temps de lui dire au revoir.

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

L'ADCS n'est pas intrinsèquement peu sûr, mais il est faussement facile à mal configurer. Au cours des dernières années, les chercheurs en sécurité ont découvert plusieurs exploits et vulnérabilités dus à ces erreurs de configuration généralisées, au point que la NSA et la CISA l'ont classée parmi les 10 principales erreurs de configuration en matière de cybersécurité en 2023 par la NSA et la 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

Selon l'enquête 2023 State of Cloud de HashiCorp, 76 % des entreprises ont ou prévoient de mettre en œuvre une stratégie multi-cloud. Dans ce contexte, Keyfactor et l'Institut Ponemon ont constaté que la souplesse de déploiement est la caractéristique la plus importante pour les entreprises d'aujourd'hui lorsqu'elles évaluent les solutions PKI .

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 :

  • Statu quo : Une façon de combler les lacunes de l'ADCS est de l'associer à d'autres solutions pour des cas d'utilisation spécifiques (comme PKI intégré dans des outils de développement ou des services en nuage comme AWS Private CA et Google Cloud CA Service). Mais le fait d'avoir autant d'émetteurs différents peut également créer de la complexité, car vous vous retrouvez avec des outils fragmentés qui n'offrent pas de visibilité ou de contrôle cohérent.
  • Augmenter : Vous pouvez compléter votre ADCS avec ces autres solutions PKI avec la gestion des certificats, qui offre une interface standardisée et un lieu central pour obtenir la visibilité et le contrôle de tous vos différents émetteurs.
  • 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.
  • Migrer : Enfin, vous pouvez vous décharger de l'infrastructure et de la maintenance de PKI en migrant vers un service SaaS ou un service géré PKI . Cette approche ne convient pas à tout le monde, mais elle peut être intéressante pour les équipes qui n'ont plus les ressources ou la bande passante nécessaires pour gérer PKI en interne.

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.

Prêt à prendre en main votre PKI? Notre équipe est prête à aider votre PKI à entrer dans l'ère moderne. Connectez-vous.