Un guide de gestion des clés API

Les identités non humaines (NHI) dépassent les utilisateurs humains dans un rapport de 144 pour 1 dans les environnements d'entreprise, selon The NHI & Secrets Risk Report H1 2025, en hausse de 56 % par rapport à 92:1 un an plus tôt. La gestion des clés API doit prendre en compte cette échelle car les comptes de service, les pipelines automatisés et les intégrations tierces contiennent tous des identifiants. Une grande partie de ces identifiants sont des clés API, chaînes statiques qui n'expirent souvent pas par défaut, se glissent dans le code source, et échappent aux revues d'accès.

Les comptes humains bénéficient de workflows joiner-mover-leaver et de certifications périodiques. Les développeurs créent généralement des clés API dans les consoles de développement et les collent dans les fichiers de configuration. Les clés restent en place jusqu’à ce qu’un problème survienne ou qu’un départ inapproprié expose la faille.

La gouvernance efficace des identifiants couvre les identifiants machine lors de leur génération, stockage, rotation, surveillance et révocation. Appliquer ces contrôles à chaque identité non humaine élimine le risque des clés à longue durée de vie et renforce la posture de sécurité, la visibilité opérationnelle et la résilience cybernétique.

Qu'est-ce que la gestion des clés API ?

La gestion des clés API est la discipline qui régit une identité machine depuis sa création jusqu'à sa révocation, couvrant le stockage, la distribution, la rotation et la surveillance. Une clé API est une chaîne statique et opaque qu'une application transmet avec une requête API, généralement dans un en-tête Hypertext Transfer Protocol (HTTP), pour identifier l'application, le service, le script ou le pipeline appelant. Elle fonctionne comme une identité de type porteur car sa possession seule suffit à l'utiliser.

Request for Comments (RFC) 6750 définit la même propriété pour les jetons porteurs OAuth 2.0 : toute personne en possession du jeton peut l’utiliser sans prouver la possession du matériel clé cryptographique. Cette propriété de type porteur est précisément la raison pour laquelle une clé API standard n’authentifie pas un principal. Elle ne prouve que la possession d’une valeur chaîne, pas l’identité.

Pourquoi les clés API sont une surface d’attaque en expansion

Les développeurs ont engagé 28 649 024 nouveaux secrets codés en dur dans des dépôts publics GitHub en 2025, selon The State of Secrets Sprawl 2026 de GitGuardian. Ce total représente une augmentation de 34 % d'une année sur l'autre et le plus grand bond annuel enregistré par le rapport. Plusieurs propriétés structurelles expliquent cette expansion. De nombreuses clés API n'expirent pas par défaut, donc l'exposition prolongée des clés peut persister pendant des années, et la même valeur en chaîne simple qui fonctionne dans un en-tête HTTP fonctionne tout aussi bien dans un fichier de configuration, une variable d'intégration et de livraison continues (CI/CD) ou un message de chat.

NHIs surprivilegiés reçoivent également des autorisations plus larges que celles requises par leurs tâches, et ces autorisations durent souvent plus longtemps que la tâche elle-même. Chaque nouveau service cloud, pipeline et intégration tierce augmente l'inventaire que les équipes de sécurité doivent gérer. Selon le Netwrix 2026 Data and Identity Security Report, 75 % des expositions de données liées à des incidents commencent par une identité compromise ou des autorisations mal configurées.

Un exemple historique montre l'impact opérationnel de contrôles faibles du cycle de vie. En novembre 2023, un acteur malveillant a accédé à l'environnement Atlassian auto-hébergé de Cloudflare via des identifiants valides exposés.

L'acteur a utilisé un jeton d'accès et trois identifiants de compte de service exposés lors de la compromission d'Okta en octobre 2023, que Cloudflare n'a jamais fait tourner par la suite. Cloudflare les a décrits comme « à tort considérés comme inutilisés ». La remédiation a nécessité une large rotation des identifiants de production et un reformatage des machines sur l'ensemble du réseau mondial de Cloudflare.

Cet attaquant s'est authentifié avec des identifiants valides tout au long de l'incident, et le Netwrix 2025 Cybersecurity Trends Report a constaté que 27 % des organisations ont estimé des dommages liés à une attaque de 50 001 $ ou plus, soulignant l'intérêt financier des contrôles du cycle de vie qui réduisent les travaux de réponse et de remédiation évitables. L'inventaire continu, la propriété et la rotation réduisent ce fardeau de récupération et améliorent la résilience cybernétique.

Le cycle de vie de la clé API

Le guide des secrets d'Open Worldwide Application Security Project (OWASP) organise une gestion efficace des clés autour de cinq étapes : génération, stockage et distribution, rotation, surveillance et audit, et révocation.

Génération

Chaque clé doit provenir d'une source aléatoire cryptographiquement sécurisée et comporter des restrictions de portée dès sa création. Pour une clé qui fonctionne comme un National Institute of Standards and Technology (NIST) SP 800-63B-4 secret de consultation ou un justificatif directement analogue, utilisez une force de sécurité minimale de 112 bits comme référence d'entropie ; le NIST exige que les secrets de consultation proviennent d'un générateur de bits aléatoires approuvé avec cette force minimale, appliqué spécifiquement aux secrets de consultation et aux justificatifs directement analogues.

Appliquez des restrictions de clé lors de l’émission, en spécifiant quelles API la clé peut appeler et quelles applications peuvent la présenter. Attribuez à chaque clé les privilèges minimaux nécessaires à sa tâche et créez simultanément les enregistrements de propriété. Concernant les clés devant s’authentifier, la directive OWASP API est claire : les clés API doivent authentifier les clients API, pas les utilisateurs finaux.

Deux types d’identifiants liés diffèrent des clés API. La norme OAuth 2.0, un cadre d’autorisation, définit les jetons d’accès émis par les flux d’autorisation. Les exigences d’authentification client, les étendues et les durées dépendent du type de concession et de la configuration du fournisseur ; dans le flux d’identifiants client de Microsoft, les durées typiques des jetons sont souvent d’environ une heure.

Un justificatif basé sur un certificat utilisant mutual Transport Layer Security (mTLS) et X.509 utilise plutôt une preuve de possession. Le client prouve le contrôle d’une clé privée qui reste sur le client, donc selon RFC 8705, seule la partie en possession de la clé privée correspondant au certificat peut utiliser le jeton associé.

Stockage et distribution

Gardez les clés hors du code source et récupérez-les à l’exécution depuis un magasin de secrets dédié. Les identifiants codés en dur dans le code source sont dangereux ; la solution est un gestionnaire de secrets que les pipelines CI/CD et les applications peuvent utiliser pour récupérer les secrets en toute sécurité.

Les variables d'environnement qui restent en dehors de l'arborescence du code source de l'application sont la base ; un gestionnaire centralisé de secrets avec contrôles d'accès et journalisation d'audit est la norme. Distribuez les clés uniquement via Hypertext Transfer Protocol Secure (HTTPS) et ne les placez jamais dans les URL, car les chaînes de requête se retrouvent dans les journaux du serveur web.

Rotation

Les processus manuels de rotation introduisent des erreurs et laissent des identifiants obsolètes actifs, c'est pourquoi l'automatisation est importante. Pour les clés de compte de service Google Cloud à longue durée, les recommandations du fournisseur cloud recommandent une rotation au moins tous les 90 jours. Le benchmark du Center for Internet Security (CIS) pour Amazon Web Services (AWS) demande également de faire tourner les clés d'accès AWS Identity and Access Management (IAM) tous les 90 jours ou moins.

Pour une rotation sans interruption, utilisez la dual-credential rotation. Maintenez deux ensembles d’identifiants valides, basculez les applications vers les nouveaux, puis retirez les anciens. Déclenchez la event-driven rotation après une exposition suspectée, un changement de propriétaire ou la fin d’un projet. Le coût de sauter cette étape s’accumule. GitGuardian a constaté que 64% des secrets détectés quatre ans plus tôt restaient actifs et exploitables lors d’un nouveau test.

Surveillance et audit

Créez des journaux d’utilisation des clés pour chaque identifiant et examinez ces journaux pour les clés devenues silencieuses. CIS Controls v8 exige une conservation des journaux d’audit d’au moins 90 jours, et les référentiels CIS cloud demandent aux équipes de désactiver les identifiants après 45 jours d’inactivité. La dormance est un signal utile.

Auditez la création et l’utilisation des identifiants de service principal, et surveillez les usages inhabituels des applications, comme des applications dormantes soudainement réactivées. Masquez les valeurs secrètes dans les journaux ; les secrets ne doivent jamais apparaître en clair.

Révocation

Considérez toute clé exposée comme compromise dès que vous en prenez connaissance, et préparez le chemin de révocation avant d’en avoir besoin. Suivez une séquence de rotation sécurisée. Générez une clé de remplacement pour le même compte de service, transférez les charges de travail dessus, vérifiez la fonctionnalité après la migration, puis supprimez l’ancienne clé.

Supprimer le secret uniquement du code laisse l’identifiant actif ; suivez les instructions de nettoyage du dépôt en révoquant d’abord, puis en nettoyant les dépôts, la configuration et les journaux. Terminez par une revue du périmètre d’impact de l’historique d’utilisation de la clé. Qu’a-t-elle accédé pendant son exposition, et l’acteur l’a-t-il utilisée pour créer de nouvelles clés, rôles ou politiques ?

Ce qu’il faut rechercher dans une approche de gestion des clés API

Un programme de gouvernance efficace combine le déploiement de vault avec des contrôles opérationnels, il faut donc évaluer les approches selon des critères opérationnels.

• Inventaire et découverte centralisés : L'approche doit trouver les clés chez les fournisseurs cloud, dans les pipelines CI/CD, les dépôts, les fichiers de configuration et les plateformes Software as a Service (SaaS), et enregistrer qui en est le propriétaire. Un registre pratique pour les identifiants non humains doit capturer l'identité, l'équipe propriétaire, l'objectif commercial, les systèmes accessibles, la portée des privilèges et la date d'expiration ou de révision.
• Délimitation au moindre privilège et émission just-in-time : Recherchez une délimitation par clé et par charge de travail, ainsi que la capacité à émettre des identifiants temporaires à la demande et à les révoquer automatiquement après utilisation.
• Rotation automatisée sans interruption : Rotation planifiée et déclenchée par événement, avec prise en charge des doubles identifiants pour que les applications restent disponibles pendant la transition.
• Journalisation prête pour l’audit : Chaque récupération, rotation, révocation et action administrative doit créer des enregistrements prêts pour l’audit avec une identité attribuable et un horodatage pour l’exportation vers votre système de gestion des informations et des événements de sécurité (SIEM). Cet enregistrement fournit des preuves d’audit et la piste médico-légale dont les intervenants en cas d’incident ont besoin.
• Intégration avec la gouvernance des identités : Identity Governance and Administration (IGA), Privileged Access Management (PAM) et Cloud Infrastructure Entitlement Management (CIEM) doivent fonctionner ensemble pour gérer les identités et les droits de manière cohérente dans tous les environnements. Un coffre qui partage les données d'inventaire et de propriété avec votre IGA program peut inclure des clés dans le processus de certification. Le IGA buyer's guide décrit d'autres capacités de gouvernance pour évaluer les outils d'Identity Management.

Où la gestion des clés API s'intègre dans la gouvernance des identités non humaines

De nombreux programmes de gouvernance échouent au niveau de la propriété. Silverfort's Insecurity in the Shadows 2025 a révélé que 40 % des identités non humaines ont un propriétaire inconnu, et seulement 5,7 % des responsables de la sécurité déclarent une visibilité complète de leurs NHI.

Une enquête Gartner auprès de 335 responsables IAM, publiée dans Gartner Identifies the Top Cybersecurity Trends for 2025, a révélé que les équipes IAM sont responsables de seulement 44 % des identités machines d'une organisation ; le reste revient aux équipes de développement, de plateforme et commerciales. Une propriété claire de l'identité crée une responsabilité pour les examens, la rotation et la mise hors service.

Les cadres de conformité attendent déjà cette discipline. Payment Card Industry Data Security Standard (PCI DSS) les exigences de moindre privilège couvrent les comptes applicatifs et système (Req. 7.2.5). Les organisations doivent périodiquement revoir l’accès à ces comptes à une fréquence définie dans leur analyse des risques. PCI DSS Req. 7.2.5.1 est entré en vigueur le 31 mars 2025. PCI DSS établit également des contrôles de mot de passe codés en dur pour les scripts, fichiers de configuration et code source (Req. 8.6.2).

La règle de sécurité de la Health Insurance Portability and Accountability Act (HIPAA) limite les contrôles d'accès aux personnes ou programmes logiciels ayant des droits d'accès, de sorte que les identifiants machines manipulant des informations de santé protégées (PHI) en font clairement partie.

Pour la Sarbanes-Oxley Act (SOX), des populations d'accès complètes soutiennent des tests de contrôle fiables. La gouvernance des accès SOX doit inclure les comptes de service et les clés d'intégration dans les listes d'accès. Dans tous les cadres, les preuves d'audit cohérentes comprennent des rapports de découverte, des registres de propriété, des journaux de rotation, des registres de mise hors service et des revues datées avec signatures nommées.

Le consensus des analystes s’est déplacé au même endroit. Le vaulting des secrets soutient la gouvernance, mais la gouvernance va au-delà du vaulting. Les organisations attendent de plus en plus des plateformes IGA qu’elles gouvernent de manière cohérente les humains et les NHIs via des politiques de cycle de vie flexibles, une réconciliation continue et des modèles de propriété clairs.

En pratique, chaque clé API nécessite le même traitement de cycle de vie qu’un compte humain. Cela signifie la créer avec un propriétaire et un objectif documenté, la certifier régulièrement, et la désactiver lorsque sa tâche est terminée. La désactivation reste la plus grande lacune ; le Top 10 NHI du Open Worldwide Application Security Project (OWASP) inclut une désactivation inappropriée parmi les modes d’échec courants et rapporte que 51 % des organisations n’ont pas de processus formel pour désactiver ou révoquer les clés API à longue durée de vie. Comme les équipes créent et abandonnent continuellement des clés, le modèle de gouvernance nécessite une réconciliation continue pour maintenir la visibilité et la posture à mesure que la population change.

Bonnes pratiques pour gérer de grands inventaires de clés API

Un programme évolutif transforme la politique de cycle de vie en contrôles techniques et de gouvernance répétables :

• Modèles de politiques de moindre privilège : Définissez les portées approuvées des API, ressources et opérations pour les charges de travail courantes, appliquez une politique de refus par défaut et détectez les écarts par rapport à ces modèles.
• Migration des clés statiques : Lorsque les plateformes prennent en charge workload identity federation, managed identities ou des identifiants de session temporaires, utilisez-les à la place. Les recommandations du National Cyber Security Centre (NCSC) conseillent d’éviter les clés d’accès à long terme qui pourraient accorder un accès indéfini en cas de compromission.
• Orchestration de la rotation : Connectez l'émission des identifiants, la bascule d'application, la validation et la mise hors service pour que les équipes puissent automatiser la rotation des identifiants, comme le recommande la directive NCSC.
• Rapprochement Vault-to-discovery : GitGuardian a constaté que 5,1 % des dépôts utilisant des secrets managers ont encore fuité des secrets en 2024 ; comparez les identifiants stockés avec les inventaires de dépôts, pipelines, cloud et SaaS pour détecter les écarts.
• Interrupteur d’urgence pour réponse aux incidents : Maintenez la capacité de révoquer n’importe quelle clé en quelques minutes, avec un chemin de remplacement pré-testé. Le SANS Internet Storm Center (SANS ISC) a observé des acteurs malveillants passant de la validation de secrets volés à des opérations de découverte active dans des environnements cloud compromis en moins de 24 heures.
• Examens avec propriétaire nommé : CIS Safeguard 5.5 exige un inventaire des comptes de service avec propriétaire de département, date d’examen et objectif, revu au moins trimestriellement ; inclure les clés API dans le même examen.

Comment Netwrix vous aide à gérer les clés API et les identifiants des machines

Les clés API sont un type d’identifiants dans un défi plus large de gouvernance des identités non humaines, et la plupart des organisations manquent de visibilité complète sur cette population. Netwrix prend en charge les contrôles PAM et IGA adjacents dans le cadre de son approche de sécurité centrée sur l’identité pour les organisations de taille moyenne exploitant des environnements hybrides fortement basés sur Microsoft.

Pour les workflows d'accès privilégié, Netwrix Privilege Secure applique un modèle sans privilèges permanents qui crée des comptes éphémères pour une seule session et les détruit à sa fin. Eastern Carver County Schools a éliminé l'accès privilégié permanent sur les commutateurs réseau, VMware et caméras de sécurité protégeant les données de 9 300 élèves, le remplaçant par un accès just-in-time et complétant le déploiement en quelques jours au lieu de plusieurs mois. Netwrix Identity Manager prend en charge la certification des accès et la désactivation automatisée pour les identités associées à ces identifiants.

Plus de 14 000 clients, dont environ 25 % des entreprises du Fortune 500, font confiance à Netwrix pour gérer conjointement la sécurité des identités et des données.

Demandez une démo pour voir comment Netwrix Privilege Secure élimine l’accès privilégié permanent grâce à des identifiants limités à la tâche et expirant automatiquement.