Pour un DSI, considérer les certificats et les identités des machines comme de simples rouages est tentant : on parle certes de fonctions critiques, mais purement techniques et laissées entre les mains des praticiens. « Les infrastructures à clefs publiques (PKI) et la cryptographie ont toujours été vues comme des technologies de bas niveau, de l'ombre. Même si elles sont fondamentales pour la sécurité, les DSI n'y ont probablement pas prêté beaucoup d'attention », résume Christian Simko, vice-président du marketing produit chez AppViewX, plateforme d'automatisation Low Code. « Aujourd'hui, elles sont beaucoup plus sous les feux de la rampe, car la gestion des identités des machines, la gestion des identités non humaines et la cryptographie post-quantique sont autant de questions d'actualité qui vont avoir un impact sur la sécurité et la conformité des organisations. Or, lorsque la conformité commence à s'impliquer sur un sujet, le DSI commence lui aussi à s'en préoccuper un peu plus. »

Des normes encore ignorées dans le courriel

Or, en la matière, la plupart des entreprises accusent un retard flagrant. Vous avez peut-être remarqué que les courriels de votre boîte de réception sont étiquetés comme provenant non seulement de l'extérieur de votre organisation, mais aussi d'expéditeurs non vérifiés. Cela fait partie d'un effort visant à améliorer l'adoption de normes sur la réputation des courriels, qui reposent sur des certificats pour l'authentification. Des normes que la majorité des organisations ont tout simplement ignorées, même si les menaces liées au courrier électronique sont en augmentation rapide. « Il devrait s'agir d'une bonne pratique, mais vous seriez surpris de voir le nombre d'organisations qui sont à la traîne et qui ne l'ont pas encore mise en oeuvre de manière complète et efficace », dit Christian Simko.

En début d'année, Google et Yahoo, bientôt rejoints par Microsoft, ont commencé à exiger de toute organisation ayant envoyé 5 000 messages ou plus en une seule journée qu'elle utilise l'authentification SPF, DKIM et DMARC, ce qui affecte les réinitialisations des mots de passe, les notifications d'expédition, les courriels de reçu d'achat envoyés aux consommateurs et les newsletters et autres messages marketing envoyés directement ou par l'intermédiaire de fournisseurs de messagerie électronique comme Mailchimp.

Les entreprises doivent non seulement s'assurer que DMARC est correctement mis en oeuvre sur tous leurs domaines et sous-domaines - même si elles ne les utilisent pas pour envoyer des courriels, elles doivent se protéger contre un pirate qui les usurperait -, mais elles doivent également surveiller les rapports de courriels rejetés en raison d'échecs DMARC. Les DSI devront consacrer du temps et des ressources à ce sujet, soit en interne, soit par l'intermédiaire d'un fournisseur de services de sécurité pour le mail. Ils devraient également envisager de marquer et de rejeter les courriels entrants ne répondant pas à ces normes de réputation.

Cette mesure va réduire considérablement le nombre de courriels d'hameçonnage, mais elle risque aussi d'avoir un impact sur les communications légitimes provenant d'autres organisations qui n'ont pas encore adopté les normes de réputation en question. Ce qui en fait une décision stratégique plutôt que technique.

L'explosion des identités des machines

Mais, en réalité, les certificats pour le courrier électronique ne représentent que la partie émergée de l'iceberg. Grâce à l'adoption d'infrastructures complexes telles que l'IoT, les tokens JSON et Kubernetes, entre autres, les organisations utilisent déjà des centaines de milliers d'identités de machines sécurisées par des certificats SSL/TLS, avec des durées de vie allant de plusieurs années à quelques minutes. Une seule machine physique peut exécuter des centaines de workloads éphémères.

Or, ces certificats sont souvent mal gérés et mal sécurisés, même par des organisations dans des secteurs réglementés comme la finance. Erik Wahlstrom, vice-président et analyste au sein du cabinet Gartner, estime que le nombre d'identités de machines dépasse déjà celui des identités des humains d'un ordre de grandeur. Et ce total ne cesse de croître, en particulier avec l'adoption d'outils d'IA qui nécessitent des identifiants à la fois pour les systèmes auxquels ils accèdent et pour les humains au nom desquels ils agissent. Une étude de Coleman Parkes pour le fournisseur d'automatisation Venafi prévoit que les organisations de plus de 10 000 employés devront gérer jusqu'à 1,3 million d'identités et de certificats de machines d'ici à 2025.

Avec de tels chiffres, les scripts manuels, les tableaux Excel et les automatismes maison ne sont plus adaptés, d'autant plus que la plupart des entreprises n'ont qu'une faible visibilité sur le nombre de certificats et d'identités de machines qu'elles utilisent déjà. « Lorsque les gens feront un inventaire complet sur ce sujet, ils seront choqués par la rapidité avec laquelle ce nombre augmente », souligne Geoff Cairns, analyste principal chez Forrester Research. Le fait que ces workloads soient exploités dans des environnements hybrides ou multicloud ne fait que complexifier les choses.

Les frontières organisationnelles bousculées

Le domaine manque de maturité, abonde Matt Caulfield, vice-président produits chez Duo, filiale de sécurité de Cisco. « Aucun répertoire d'identités machines standard n'existe » souligne-t-il, relevant que les équipes IT font face à un ensemble confus de protocoles d'authentification et d'autorisations machine à machine (M2M).

Autre problème : ces questions dépassent les frontières organisationnelles de la gestion d'identité traditionnelle. Les équipes en charge de l'infrastructure à clé publique existante, comme Active Directory, ne sont souvent pas impliquées dans les initiatives qui nécessitent des certificats et des identités dédiés aux machines - ni même dans les discussions sur la manière d'aborder le problème.

« Le cloud a aggravé ce problème de manière exponentielle, prévient Murali Palanisamy, responsable des solutions chez AppViewX. « La PKI est généralement mise en place et gérée par l'équipe interne de Microsoft, qui n'a pas grand-chose à dire sur les décisions relatives au cloud et à la transformation numérique. Les équipes DevOps sont plus axées sur la vitesse et l'agilité : elles font ce qui est bon pour accélérer les projets, pas nécessairement ce qui est le plus indiquée ou le plus stratégique en matière de sécurité. »

Et même lorsque les organisations décident d'établir des politiques et de normaliser la sécurité pour les nouveaux déploiements, la reprise de l'existant représente un effort considérable. Sans oublier le fait que dans les architectures modernes, les équipes d'exploitation sont réduites à la portion congrue.

Il est donc d'autant plus important que les DSI s'approprient le problème, souligne Geoff Cairns. « En particulier dans les organisations les plus grandes, les plus complexes et les plus globales, on sous-estime souvent l'ampleur de la tâche consistant à faire passer ces messages dans l'organisation. Il s'agit en partie de bien maîtriser la culture interne et la manière d'aborder ces questions. »

Multiplication des incidents liés aux certificats

Même en dehors de ce phénomène d'explosion des identités de machines, les problèmes de certificats provoquent déjà régulièrement des pannes et des problèmes de sécurité au sein des organisations, souvent parce que les notifications d'expiration passent inaperçues, même au sein de fournisseurs majeurs comme Microsoft. Ces difficultés dans la gestion des informations d'identification permettent également à, des assaillants d'accéder à l'infrastructure cloud, aux workloads des entreprises ou à leur supply chain logicielle. Un certificat expiré rompant l'inspection du trafic TLS chez Equifax a ainsi conduit à la violation massive de données qu'a connue cet acteur en 2017.

« Les complexités engendrées par l'adoption du cloud et du DevOps - qui entraînent par ailleurs une croissance exponentielle des identités machine - conduisent à une incroyable prolifération d'identités et à une vulnérabilité accrue aux attaquants cherchant se déplacer latéralement au sein d'une organisation », explique Geoff Cairns.

La combinaison d'une surveillance accrue - par les éditeurs de navigateurs en particulier -, de la banalisation des autorités de certification par les fournisseurs de cloud et de l'apparition de nouveaux acteurs comme Let's Encrypt va accroître la pression sur les entreprises, rendant les mauvaises pratiques insoutenables. « Le marché des certificats TLS est devenu, comme d'autres, un marché centré sur l'approvisionnement et le coût, mais certains des incidents récents poussent les entreprises à une plus grande attention sur les questions de confiance et de sécurité sous-jacentes », ajoute l'analyste.

Se préparer aux incidents et à leurs impacts

De nombreuses grandes organisations devront ainsi bientôt révoquer leurs certificats TLS et en provisionner de nouveaux, à grande échelle. Une entreprise sur cinq du classement Fortune 1000 utilise en effet Entrust comme autorité de certification et, à partir du 1er novembre 2024, Chrome, suivant l'exemple de Firefox, ne fera plus confiance aux certificats TLS de ce fournisseur en raison d'une série de défaillances de conformité, qui, selon l'autorité de certification, ont parfois été causées par des entreprises clientes qui demandaient plus de temps pour gérer la révocation de leurs certificats. Les navigateurs afficheront des avertissements de sécurité plutôt que de bloquer complètement l'accès aux sites utilisant des certificats Entrust émis après le 31 octobre 2024, mais de nombreuses organisations voudront changer d'autorité de certification pour éviter la perte de confiance des utilisateurs que risquent d'entraîner ces messages.

Cette décision crée également un précédent pour une application plus stricte des politiques de sécurité sur les certificats au sein des navigateurs, après des années de tension entre leurs éditeurs et les autorités de certification. Même sans ce tour de vis, les clients de DigiCert, y compris ceux qui exploitent des infrastructures critiques comme les systèmes de santé et les réseaux de télécommunications, ont récemment dû remplacer plus de 83 000 certificats TLS, la plupart du temps avec un préavis de 24 heures seulement, parce que depuis cinq ans, son portail client en libre-service ne créait pas correctement les enregistrements pour la vérification DNS. Ces notifications sont arrivées par courrier électronique un lundi matin, mettant de nombreuses organisations dans l'embarras face à l'ampleur de la tâche.

Car, à l'heure actuelle, peu d'organisations sont en mesure de traiter ce type d'urgence de manière efficace. Il s'agit d'une expertise que les organisations doivent développer, car ces problèmes vont continuer à se poser, assure Murali Palanisamy. Cela va devenir la norme, et nous devons donc nous y préparer. » Selon lui, une partie du problème réside dans le fait que les autorités de certification doivent conserver des certificats racine valables pendant des décennies pour la génération de clés. « Dans un monde numérique, il s'agit presque d'un retour à l'ère des dinosaures. Il faut maintenir la clé en vie pendant 30 ans ! »

Faire face à une rotation accélérée des certificats

D'où la proposition de Google de réduire la validité des certificats TLS à seulement 90 jours, afin d'alléger le fardeau des autorités, car les exigences de validité de la racine tomberaient alors à cinq ou sept ans. Mais si cette proposition se concrétise, les entreprises devront procéder à une rotation des certificats si fréquente que le recours à l'automatisation deviendra indispensable.

Les certificats TLS destinés au public étaient auparavant valables jusqu'à trois ans. Leur durée de validité a d'abord été réduite à 825 jours (deux ans plus les 30 jours précédant l'expiration, au cours desquels ils doivent être renouvelés), puis à 398 jours (un an plus 30 jours). Google a récemment proposé de réduire cette durée à 90 jours seulement. Il n'est pas certain que le CA/Browser Forum soutienne cette proposition, mais si Google décide de mettre en oeuvre cette mesure sur Chrome unilatéralement, son importante part de marché pourrait inciter les autorités de certification à ramener à 90 jours la durée par défaut de leurs certificats. Ce qui multiplierait par six le nombre de renouvellements !

Une marche bien haute pour la plupart des organisations. Pour Murali Palanisamy, « il n'est en pratique pas possible de faire cela manuellement, pour chaque appareil et chaque certificat de l'organisation ». La révocation et le remplacement manuels des certificats impliquent l'utilisation de plusieurs systèmes pour générer et distribuer les clés, ce qui prend généralement une ou deux heures par certificat ; des automatisations maison peuvent ramener cette durée entre 15 et 30 minutes. Ce qui reste insuffisant.

Une telle vitesse de rotation devait donc pousser les entreprises à considérer des systèmes automatisés intégrés à une gamme d'autorités de certification, ce qui signifie travailler avec une gamme d'API, de SDK, d'agents et avec le protocole ACME, ainsi qu'avec des systèmes et des outils DevOps à l'état de l'art. De quoi générer de nouvelles clés en quelques secondes ou, au pire, en quelques minutes si le certificat génère un coût qui doit être approuvé dans le cadre d'un workflow.

Planifier la cryptographie post-quantique

Même sans certificats à 90 jours, les entreprises doivent encore s'intéresser aux changements de normes de cryptographie du fait de l'arrivée annoncée des ordinateurs quantiques. Et planifier l'adoption de la nouvelle série de normes de chiffrement post-quantique, comme celles approuvées par le NIST (l'agence américaine en charge des standards technologiques). Les autorités de certification ne seront probablement pas prêtes à émettre des certificats à ces normes avant 2026... ce qui laisse un peu de temps pour se préparer à leur complexité supplémentaire.

Pour éviter aux entreprises d'avoir à installer des certificats TLS en double - l'un pour les clients qui intègrent les nouveaux algorithmes, l'autre pour ceux qui ne le font pas encore - une normalisation de suites de chiffrement hybrides est en cours. Objectif : simplifier la transition, mais aussi de tenir compte du fait que, même s'ils peuvent être plus rapides, de nombreux algorithmes post-quantiques sont nouveaux et n'ont pas fait l'objet d'un examen aussi approfondi que les approches actuelles de la cryptographie, de sorte qu'un retour arrière pourrait s'avérer nécessaire si des vulnérabilités sont découvertes ultérieurement.

Des problèmes lors de la mise en oeuvre sont également probables. Lorsque Chrome et Edge 124 ont activé par défaut l'échange de clés TLS hybride post-quantique de Google en début d'année, les serveurs web qui n'implémentaient pas TLS correctement ont commencé à rejeter les connexions. De même, des problèmes de compatibilité détectés lors de tests antérieurs, effectués par Google et Cloudflare, avaient déjà retardé de plusieurs années le déploiement des clés post-quantiques dans les navigateurs.

Les DSI doivent être prêts non seulement à tester la compatibilité de leurs systèmes aux normes post-quantiques, mais aussi à faire face à la charge supplémentaire que représente la gestion des certificats et des identités des machines dédiées. Et ce, bien avant que les ordinateurs quantiques capables de briser le chiffrement traditionnel ne soient eux-mêmes disponibles, car les informations récoltées aujourd'hui pourraient encore être sensibles lorsque ces machines seront prêtes à les déchiffrer.

Travailler sa crypto-agilité

Cette capacité à remplacer les algorithmes cryptographiques ne se limite d'ailleurs pas à la révolution quantique. « Le jour viendra où les technologies de gestion des secrets et des certificats en entreprise subiront une transformation inévitable et massive qui les rendra obsolètes, prévient Erik Wahlstrom du Gartner. Ce n'est qu'une question de temps. La crypto-agilité dépend de la rapidité avec laquelle vous pouvez vous relever de ce type d'événements. »

Selon l'analyste, les entreprises commencent à s'intéresser à la question. L'année dernière, l'équipe IAM de Gartner a reçu deux fois plus d'appels sur la gestion des identités des machines que sur l'authentification multifactorielle (MFA). « Ce n'est pas parce que la MFA perd en importance, mais parce que la gestion des identités des machines a pris un caractère d'urgence pour les organisations », explique-t-il. Pour reprendre le contrôle, il conseille aux DSI d'établir une stratégie pour la gestion des certificats et des identités de machines, en commençant par définir leur champ d'application, et d'ancrer cette stratégie dans les besoins techniques de l'organisation pour éviter d'être trop influencé par le marketing des fournisseurs.