La détection massive de secrets sur GitHub en 2024 souligne la vulnérabilité persistante des identifiants en clair dans les dépôts de code. Ce phénomène est exacerbé par la prolifération des identités machines, dont les clés d’API représentent une part majeure, soulignant la nécessité de solutions robustes de gestion des secrets.
En 2024, avec plus de 12,8 millions de secrets détectés dans les dépôts publics de GitHub, il est clair que les identifiants en clair codés en dur constituent un problème sérieux. Pire encore, ce problème s’aggrave d’année en année, puisque 10 millions de secrets ont été découverts l’année précédente et 6 millions l’année d’avant. Il ne s’agit pas de résultats cumulatifs !
Lorsque l’on creuse un peu plus ces chiffres, un constat s’impose : les secrets spécifiques détectés, dont la grande majorité sont des clés d’API, sont beaucoup plus nombreux que les secrets génériques détectés. C’est logique quand on sait que les clés d’API sont utilisées pour authentifier des services, des appareils et des workloads spécifiques dans les applications et pipelines afin de permettre la communication de machine à machine. Cela correspond tout à fait à l’étude de CyberArk, selon laquelle les identités machines sont 45 fois plus nombreuses que les identités humaines. Cet écart ne fera que se creuser au fur et à mesure que nous intégrerons de plus en plus de services dans les bases de code, et ce à une vitesse toujours plus grande.
La prolifération des secrets est clairement un problème pour les identités humaines et les identités machines, alors pourquoi devrions-nous faire cette distinction ?
Le terme « identités machines » sert à distinguer ce domaine de la prolifération des secrets et ses défis uniques des identités humaines et des informations d’identification. Chacun de ces domaines est problématique, mais chacun appelle des approches différentes.
Dans son rapport IAM Technologies Hype Cycle, Gartner définit le terme comme suit : « Une identité machine est un justificatif utilisé par n’importe quel end point (qui peut être un appareil IoT, un serveur, un conteneur ou même un ordinateur portable) pour établir sa légitimité sur un réseau. »
Ce terme couvre toutes les clés d’accès aux API, les certificats, l’infrastructure à clé publique (PKI) et tout autre moyen possible d’authentifier les communications entre machines.
Résoudre le problème de la fuite d’identités humaines et machines
Commençons par les identités humaines. Les personnes doivent pouvoir s’authentifier pour accéder aux systèmes afin d’accomplir leur travail. L’utilisation d’un système d’authentification multifonctionnel résistant à l’hameçonnage, de préférence basé sur le matériel, à chaque fois qu’un humain utilise un mot de passe, est une approche solide. Même si un mot de passe est divulgué, il est beaucoup plus difficile à exploiter et l’utilisateur a le temps de changer de mot de passe. Bien qu’il ne s’agisse pas d’une solution miracle, Microsoft pense que cela pourrait arrêter jusqu’à 99,9 % des connexions frauduleuses. Mieux encore, s’il existe un moyen d’éliminer ce mot de passe, par exemple avec une clé d’accès utilisant FIDO2 ou des données biométriques basées sur le matériel pour l’authentification.
La gestion des ressources machines nécessite une approche différente, car nous ne pouvons pas simplement activer le MFA pour les machines. Il n’est pas non plus possible de perturber les identités de ces machines, car l’activité de l’entreprise en a besoin pour opérer, et les connexions doivent continuer à permettre aux systèmes de fonctionner et de satisfaire le volet disponibilité de la triade de la CIA. De même, il n’est pas recommandé de consacrer des ressources et des heures sans fin à cette question, car les nouvelles vulnérabilités sous forme de CVE, les mauvaises configurations et les problèmes de licence continuent d’être d’autres domaines auxquels les équipes de sécurité doivent s’attaquer.
Dans un monde idéal, il faudrait immédiatement faire évoluer tous les systèmes vers des certificats à courte durée de vie ou des JWT qui sont émis au moment de l’exécution lorsque c’est nécessaire et qui ne durent que le temps de la requête. Il existe en effet des cadres tels que SPIFFE et sa mise en œuvre, SPIRE, qui peuvent aider les organisations à atteindre cet objectif. Bien qu’il s’agisse d’une excellente approche, elle se heurte à des problèmes concrets d’adoption par les développeurs, de temps et d’efforts de développement, ainsi qu’aux frais généraux liés à l’exécution de ces services à grande échelle.
Rotation automatique des secrets plus fréquente
Bien que nous puissions rêver à de nombreux scénarios idéaux, nous devons nous attaquer de front à la situation actuelle. Les développeurs continueront à utiliser des identités machines, qui peuvent être découvertes et exploitées par des attaquants. En même temps, nous savons que si un acteur malveillant met la main sur un secret, il ne peut l’exploiter que s’il est encore valide. La meilleure solution pratique pour toute organisation est d’effectuer une rotation beaucoup plus fréquente des secrets.
Parmi tous les secrets valides découverts en public, plus de 90 % étaient toujours valides cinq jours plus tard (cf State of Secrets Sprawl de Gitguardian). Cela démontre que les équipes s’attendent à ce que les secrets aient une longue durée de vie et que l’approche manuelle actuelle de la rotation des secrets soit difficile.
____________________________
Par Dwayne MacDaniel, Developer & Cybersecurity Advocate chez Gitguardian
puis