Gestion des secrets des identités non humaines pour les audits 2026

L’alerte de 02:13 que personne ne savait attribuer

À 02:13 un mardi matin, le canal du centre des opérations de sécurité s’active. Un export d’une base de données de production vient de démarrer depuis un compte d’automatisation interne. Le chemin d’accès est légitime. Le jeton est valide. L’adresse IP source appartient à un agent d’exécution cloud utilisé par l’équipe d’ingénierie. Aucun logiciel malveillant n’est visible. Aucun signalement de phishing n’existe.

Le RSSI pose la première question évidente : « Qui est propriétaire de cette identité ? »

Silence.

Le responsable DevOps se souvient que le jeton a été créé lors d’une migration client deux ans auparavant. L’équipe plateforme indique qu’il pourrait être utilisé par une intégration de facturation. L’administrateur de base de données explique qu’il dispose d’un accès en lecture parce que sa suppression avait déjà interrompu une tâche nocturne. Le service juridique demande si des données à caractère personnel sont concernées. La fonction conformité demande s’il s’agit d’un incident à notifier au titre de NIS2, DORA ou GDPR. L’auditeur demande des éléments probants montrant que les comptes de service, clés API, certificats et secrets CI/CD sont inventoriés, revus, soumis à rotation, surveillés et révoqués.

À 09:00, le projet de constat d’audit prend déjà forme. Une clé API codée en dur, jamais soumise à rotation, a été découverte dans un microservice oublié. Elle accorde un accès étendu à une base de données de transactions clients en production. Le développeur qui l’a créée a quitté l’entreprise deux ans plus tôt. Le système n’a pas de propriétaire nommé, pas de finalité documentée, pas d’enregistrement de rotation et pas de règle de surveillance.

C’est le problème des identités non humaines en 2026.

La plupart des organisations ont amélioré le contrôle d’accès des utilisateurs humains. Elles disposent de l’authentification multifacteur, de processus d’entrée, de mobilité et de sortie, de revues des accès à privilèges et de journaux de fournisseurs d’identité. Mais les identités machine se sont multipliées plus vite que la gouvernance. Les comptes de service, identités de charge de travail, clés API, jetons OAuth, clés SSH, certificats, secrets Kubernetes, jetons d’intégration SaaS, comptes d’automatisation robotisée des processus et identifiants de déploiement CI/CD exécutent désormais des actions métier critiques sans être des « utilisateurs » au sens humain.

Pour les fournisseurs SaaS, fintechs, prestataires de services managés, opérateurs cloud et PME riches en données, les identités non humaines non maîtrisées ne relèvent plus seulement de l’hygiène technique. Elles constituent un risque de résilience et de conformité au niveau du conseil d’administration. NIS2 traite le contrôle d’accès, la gestion des actifs, la sécurité de la chaîne d’approvisionnement, la gestion des incidents et l’hygiène cyber comme des mesures fondamentales de gestion des risques de cybersécurité. DORA place le risque TIC, la résilience opérationnelle, la notification des incidents et le risque lié aux tiers TIC sous la responsabilité de l’organe de direction des entités financières. GDPR impose aux responsables du traitement et aux sous-traitants de protéger les données à caractère personnel et de démontrer leur responsabilité.

La difficulté n’est pas de prouver que des secrets existent. Elle est de prouver que chaque identité non humaine a un propriétaire, une finalité, un cycle de vie, une notation de risque, un accès approuvé, une méthode de stockage sécurisé, une règle de rotation, une couverture de surveillance et un chemin de révocation.

Pourquoi les identités non humaines sont devenues le nouveau problème d’accès à privilèges

Une identité non humaine, ou NHI, est toute identité numérique utilisée par un logiciel, une infrastructure ou des processus automatisés plutôt que par une personne. En pratique, cela inclut les comptes de service utilisés par les applications, les clés API utilisées par les intégrations SaaS, les jetons OAuth et jetons de rafraîchissement utilisés par des applications tierces, les clés SSH utilisées par l’automatisation, les certificats TLS et clés privées, les secrets CI/CD, les identités de charge de travail cloud, les chaînes de connexion aux bases de données, les identifiants embarqués, les comptes de robots RPA et les identifiants d’intégration gérés par des fournisseurs.

Ces identités présentent souvent trois caractéristiques qui préoccupent les auditeurs.

Premièrement, elles ont une durée de vie longue. Un utilisateur humain peut changer ses identifiants, changer de rôle puis quitter l’organisation via un processus de sortie formalisé. Un jeton API créé pendant une fenêtre de mise en production peut rester actif pendant des années, car personne ne veut risquer d’interrompre la production.

Deuxièmement, elles sont puissantes. Un jeton de déploiement peut modifier l’infrastructure. Un principal de service cloud peut créer du stockage. Un compte de base de données peut exporter des enregistrements clients. Une clé de signature peut compromettre l’intégrité de la chaîne d’approvisionnement logicielle.

Troisièmement, elles sont difficilement attribuables. Les identités humaines sont rattachées à des enregistrements RH. Les identités non humaines sont souvent rattachées à des scripts, des pipelines, des fournisseurs, des projets oubliés ou des intégrations non documentées.

Le Zenith Blueprint: An Auditor’s 30-Step Roadmap de Clarysec Zenith Blueprint le signale directement dans la phase Controls in Action, étape 22 :

Et n’oubliez pas les identités non humaines. C’est là que les audits découvrent souvent une exposition silencieuse. Les jetons API sont-ils suivis ? Les comptes d’intégration sont-ils rattachés à des personnes, ou restent-ils dans un angle mort ? Quand la chaîne d’accès à la base de données, intégrée dans un script vieux de plusieurs décennies, a-t-elle été soumise à rotation pour la dernière fois ?

La gestion des identités n’est pas spectaculaire, mais elle est structurelle. Sans elle, votre SMSI n’est qu’une collection de portes verrouillées, sans moyen de savoir avec certitude qui détient les clés.

Cette dernière phrase résume l’enjeu. Une entreprise peut disposer d’une politique de contrôle d’accès soignée et tout de même échouer à un audit si les identités machine ne sont pas maîtrisées. Un SMSI incapable d’expliquer qui possède un secret, pourquoi il existe et quand il a été revu pour la dernière fois ne fonctionne pas encore comme un système maîtrisé.

ISO/IEC 27001:2022 transforme la gestion des secrets en éléments probants

ISO/IEC 27001:2022 est efficace parce qu’elle ne traite pas la gestion des secrets comme une tâche d’ingénierie isolée. Elle exige un SMSI fondé sur les risques, avec un domaine d’application défini, des exigences des parties intéressées, une responsabilité de la direction, une appréciation des risques, un traitement des risques, une sélection des mesures de sécurité, une Déclaration d’applicabilité et une amélioration continue.

Pour les identités non humaines, l’organisation ne doit pas commencer par l’achat d’un outil. Elle doit commencer par le périmètre et les obligations.

Au titre des articles 4.1 à 4.4 d’ISO/IEC 27001:2022, l’organisation détermine les enjeux internes et externes, les parties intéressées, les exigences légales, réglementaires et contractuelles, les interfaces et les dépendances. Dans le contexte des NHI, le domaine d’application du SMSI doit identifier les environnements cloud, plateformes SaaS, systèmes CI/CD, applications de production, intégrations clients, sous-traitants de traitement de données, prestataires de services managés et services cryptographiques dans lesquels existent des identifiants machine.

Les articles 5.1 à 5.3 rendent la direction responsable de la politique, des ressources, des rôles et du reporting de performance. C’est important, car la remédiation des NHI crée souvent des tensions opérationnelles. La rotation d’un identifiant de base de données de production, le remplacement d’un compte de service partagé hérité ou l’application de l’injection de secrets depuis un coffre-fort peuvent casser des workflows fragiles. Sans sponsor exécutif, les équipes reportent le nettoyage.

Les articles 6.1.1 à 6.1.3 et 6.2 fournissent le moteur de contrôle. L’organisation définit les critères de risque, identifie les risques portant sur la confidentialité, l’intégrité et la disponibilité, désigne des propriétaires du risque, évalue la vraisemblance et l’impact, choisit les options de traitement, sélectionne les mesures de sécurité, produit la Déclaration d’applicabilité et suit des objectifs mesurables.

Concrètement, un plan de traitement des risques relatifs aux identités non humaines doit répondre aux questions suivantes :

• Quels systèmes et services métier dépendent des NHI ?
• Quels secrets peuvent accéder à des données à caractère personnel, à des services financiers réglementés, à l’infrastructure de production ou à des services clients critiques ?
• Quelles identités sont à privilèges, dormantes, partagées, gérées par un fournisseur ou non maîtrisées ?
• Quels contrôles réduisent le risque, par exemple le stockage en coffre-fort, la rotation, le moindre privilège, l’expiration, la gestion du cycle de vie des certificats, l’analyse de détection des secrets dans le CI/CD, la surveillance et la révocation d’urgence ?
• Quels risques résiduels nécessitent une approbation métier ?

ISO/IEC 27002:2022 fournit ensuite le catalogue de mesures de l’Annexe A. Les mesures les plus pertinentes incluent 5.9 Inventaire des informations et autres actifs associés, 5.15 Contrôle d’accès, 5.16 Gestion des identités, 5.17 Informations d’authentification, 5.18 Droits d’accès, 5.19 Sécurité de l’information dans les relations avec les fournisseurs, 5.20 Prise en compte de la sécurité de l’information dans les accords fournisseurs, 5.21 Gestion de la sécurité de l’information dans la chaîne d’approvisionnement TIC, 5.23 Sécurité de l’information pour l’utilisation de services cloud, 5.24 Planification et préparation de la gestion des incidents, 5.28 Collecte des éléments de preuve, 8.2 Droits d’accès privilégiés, 8.3 Restriction d’accès à l’information, 8.5 Authentification sécurisée, 8.15 Journalisation, 8.16 Activités de surveillance, 8.24 Utilisation de la cryptographie, 8.25 Cycle de vie du développement sécurisé, 8.26 Exigences de sécurité des applications, 8.28 Programmation sécurisée et 8.31 Séparation des environnements de développement, de test et de production.

Zenith Controls: The Cross-Compliance Guide de Clarysec Zenith Controls cartographie ces relations ISO/IEC 27002:2022 d’une manière exploitable par les auditeurs et les responsables de contrôle. Pour la mesure 5.16, Gestion des identités, Zenith Controls explique le lien entre identité et identifiants :

La gestion des identités fournit le « qui », tandis que les informations d’authentification fournissent le « comment », en vérifiant que la personne qui revendique une identité est légitime. 5.16 encadre la gestion du cycle de vie des identités, tandis que 5.17 veille à ce que les mots de passe, jetons, certificats et autres identifiants soient rattachés de manière sécurisée à ces identités et correctement gérés pour soutenir une authentification forte.

Cette relation est essentielle pour les NHI. Un jeton sans propriétaire d’identité n’est pas auditable. Un compte de service sans revue d’accès n’est pas conforme au principe du moindre privilège. Un certificat sans statut de cycle de vie ne constitue pas une cryptographie maîtrisée. Un identifiant d’intégration fournisseur sans clauses contractuelles ne constitue pas une gestion efficace des risques liés aux tiers.

Le modèle de contrôle Clarysec : identité, secret, privilège, éléments probants

Clarysec met en œuvre la gestion des identités non humaines et des secrets au moyen d’un modèle de contrôle reproductible. Nous ne traitons pas les « secrets » comme une préoccupation exclusivement DevOps, ni les « comptes de service » comme une préoccupation exclusivement IAM. Nous relions identité, secret, privilège et éléments probants.

C’est au niveau de la politique que ce modèle devient opposable.

Pour les PME, la Politique de gestion des comptes utilisateurs et des privilèges pour PME de Clarysec Politique de gestion des comptes utilisateurs et des privilèges pour PME indique :

Les comptes de service (utilisés par des systèmes ou des applications) doivent être documentés, limités à des systèmes spécifiques et ne jamais être utilisés pour des connexions interactives.

Cela évite l’anti-modèle classique dans lequel un compte de service devient un compte administrateur partagé. Cela donne aussi à l’auditeur un test clair : montrer l’inventaire des comptes de service, montrer la restriction aux systèmes et montrer que la connexion interactive est désactivée ou techniquement empêchée.

La Politique de gestion des actifs pour PME de Clarysec Politique de gestion des actifs pour PME étend la définition des actifs pour inclure :

Identifiants et services numériques : noms de domaine, certificats numériques, clés API, comptes de messagerie, connexions cloud

C’est important, car beaucoup d’organisations n’inventorient que les serveurs, ordinateurs portables et applications. En 2026, une clé API peut être plus sensible qu’un ordinateur portable. La clé privée d’un certificat peut être un actif d’authentification en production. Une connexion cloud utilisée par l’automatisation peut créer une exposition à des données réglementées. Traiter les identifiants comme des actifs constitue le socle d’une gestion des secrets compatible avec les exigences d’audit.

Pour les environnements d’entreprise, la Politique de gestion des comptes utilisateurs et des privilèges de Clarysec Politique de gestion des comptes utilisateurs et des privilèges relève le niveau d’exigence probatoire :

L’organisation doit maintenir un inventaire détaillé de tous les identifiants actifs et dormants, comptes à privilèges et comptes de service au niveau système. Cet inventaire doit être mis à jour en continu et revu trimestriellement.

La revue trimestrielle est le moment où de nombreuses lacunes apparaissent. Les identifiants dormants, principaux de service orphelins, anciens utilisateurs d’intégration, comptes fournisseurs non maîtrisés et jetons d’urgence ne deviennent visibles que lorsque quelqu’un compare le registre aux enregistrements IAM, coffre-fort, CI/CD et cloud réels.

Les secrets sont des informations d’authentification, pas une commodité de développement

La formule la plus dangereuse dans la gestion des secrets est « clé temporaire ».

Les clés temporaires deviennent permanentes. Les identifiants de test atteignent la production. Le code source révèle des jetons. Les journaux de build exposent des mots de passe. Les équipes support partagent des certificats via des tickets. Les développeurs copient des fichiers d’environnement dans des conversations. Un contractant crée un principal de service cloud puis quitte la mission.

Le Zenith Blueprint, phase Controls in Action, étape 22, décrit largement les informations d’authentification :

Ce contrôle ne porte pas uniquement sur les mots de passe, même s’ils font évidemment partie du sujet. Il concerne tout identifiant utilisé pour affirmer une identité : mots de passe, codes PIN, clés cryptographiques, gabarits biométriques, cartes à puce, jetons, certificats, jetons OAuth, clés SSH, secrets API. Ce sont les clés du royaume, et la mesure 5.17 garantit que ces clés sont traitées avec le sérieux qu’elles méritent.

Soyons clairs : une mauvaise gestion de l’authentification demeure l’une des principales causes racines des violations. Mots de passe faibles ou partagés. Identifiants codés en dur dans le code source. Connexions par défaut non modifiées sur les portails d’administration. Certificats expirés ou sans propriétaire connu. Dans chacun de ces cas, ce n’est pas l’identité qui a échoué, mais l’incapacité à protéger et gouverner le mécanisme utilisé pour prouver cette identité.

Les politiques Clarysec traduisent cela en règles opérationnelles.

La Politique sur les contrôles cryptographiques pour PME Politique sur les contrôles cryptographiques pour PME indique :

Les clés ne doivent pas être stockées en clair ni intégrées dans le code source, des documents ou des courriels

La Politique de développement sécurisé pour PME Politique de développement sécurisé pour PME indique :

Aucun identifiant ou secret codé en dur dans le code source

Pour les équipes d’entreprise, la Politique de développement sécurisé Politique de développement sécurisé indique :

Les secrets ne doivent pas être codés en dur ni stockés en clair dans les référentiels.

Et la Politique relative aux exigences de sécurité des applications Politique relative aux exigences de sécurité des applications est encore plus directe :

Le stockage de mots de passe ou de clés cryptographiques en clair est strictement interdit.

Ces clauses de politique créent une piste d’audit claire. Les équipes sécurité peuvent tester les référentiels, variables CI/CD, images de conteneurs, magasins de configuration, outils de suivi des tickets, plateformes documentaires et journaux au regard d’exigences explicites. Elles soutiennent également la sécurité du traitement prévue à l’Article 32 de GDPR, car l’exposition de secrets peut conduire directement à un accès non autorisé aux données à caractère personnel.

La gouvernance cryptographique d’entreprise nécessite également une propriété définie. La Politique sur les contrôles cryptographiques de Clarysec Politique sur les contrôles cryptographiques exige :

Un registre de gestion des clés centralisé doit être tenu pour consigner toutes les clés cryptographiques, leur statut de cycle de vie, les dépositaires désignés et leurs contextes d’utilisation.

Pour les identités non humaines, ce registre doit relier les clés de certificats, clés de signature, clés API et clés gérées dans le cloud au registre NHI plus large. L’auditeur doit pouvoir retracer un certificat de production depuis le service métier jusqu’au propriétaire, au dépositaire, à l’expiration, aux éléments probants de rotation et à la procédure de réponse aux incidents.

NIS2, DORA et GDPR : un modèle d’éléments probants, plusieurs régulateurs

La gouvernance des identités non humaines est un sujet de conformité croisée, car la même défaillance peut déclencher plusieurs obligations.

Un jeton API divulgué chez un fournisseur SaaS peut entraîner une interruption de service au titre de NIS2, une exposition de données à caractère personnel au titre de GDPR et une notification contractuelle d’incident à des clients financiers dans le cadre des attentes de chaîne d’approvisionnement DORA. Un secret CI/CD compromis chez un prestataire de services TIC peut affecter la résilience des clients, l’intégrité logicielle et la continuité opérationnelle. Un compte d’intégration fournisseur oublié peut créer un accès à des systèmes réglementés sans diligence raisonnable ni contrôles contractuels appropriés.

NIS2 Article 21 exige des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées. Les domaines minimaux incluent l’analyse des risques, les politiques de sécurité des systèmes d’information, la gestion des incidents, la continuité d’activité, la sécurité de la chaîne d’approvisionnement, l’acquisition, le développement et la maintenance sécurisés, le traitement des vulnérabilités, l’évaluation de l’efficacité, l’hygiène cyber, la cryptographie, la sécurité RH, le contrôle d’accès et la gestion des actifs, ainsi que, le cas échéant, l’authentification multifacteur ou l’authentification continue. Les identités non humaines traversent presque tous ces domaines. NIS2 Article 23 instaure également une notification échelonnée des incidents significatifs, comprenant une alerte précoce dans les 24 heures, une notification d’incident dans les 72 heures et un rapport final au plus tard un mois après la notification de l’incident.

DORA s’applique depuis le 17 janvier 2025 et couvre la gestion des risques liés aux TIC, la notification des incidents majeurs liés aux TIC, les tests de résilience opérationnelle, le partage d’informations et le risque lié aux tiers TIC. Les Articles 5 et 6 exigent une gouvernance, une responsabilité de l’organe de direction et un cadre documenté de gestion des risques liés aux TIC. L’Article 8 exige l’identification des fonctions métier soutenues par les TIC, des actifs informationnels et des dépendances. Les Articles 17 à 19 exigent la gestion des incidents, leur classification et leur notification. Les Articles 28 à 30 exigent la gestion des risques liés aux tiers TIC, des registres contractuels, une diligence raisonnable, des normes de sécurité, des droits d’audit, un support en cas d’incident, des contrôles de sous-traitance et des stratégies de sortie.

GDPR s’applique dès lors que des données à caractère personnel sont traitées dans son champ territorial. L’Article 5 exige l’intégrité, la confidentialité et la responsabilité. L’Article 32 exige des mesures techniques et organisationnelles appropriées pour la sécurité du traitement. Si un compte de service ou une clé API peut accéder à des données à caractère personnel, des secrets non maîtrisés deviennent une défaillance de contrôle de protection des données, et non seulement un problème informatique.

Les mêmes éléments probants peuvent soutenir la certification ISO/IEC 27001:2022, la supervision NIS2, les examens DORA et la responsabilité GDPR lorsqu’ils sont correctement structurés.

NIST CSF 2.0 peut être utilisé comme couche de communication pour les mêmes éléments probants. Sa fonction GOVERN couvre les attentes des parties prenantes, les obligations légales et contractuelles, l’appétence au risque, la responsabilité de la direction, la politique et la supervision. Ses résultats opérationnels couvrent les inventaires d’actifs, les services fournis par des fournisseurs, la gestion des identités et des identifiants, le moindre privilège, la sécurité des données, la journalisation, la surveillance, la réponse aux incidents et le rétablissement.

COBIT 2019 et les équipes d’assurance de type ISACA examineront généralement la gouvernance et la capacité des processus. Elles demanderont si la responsabilité est attribuée, si les contrôles sont intégrés aux processus opérationnels, si les exceptions sont approuvées, si les indicateurs sont communiqués à la direction et si les éléments probants démontrent une répétabilité plutôt qu’un nettoyage ponctuel.

Un sprint pratique pour constituer un registre des identités non humaines

Une intervention Clarysec pratique commence souvent par un sprint ciblé, et non par un programme d’outillage de six mois. L’objectif est de produire un registre NHI défendable, une hiérarchisation des risques et un plan de remédiation pouvant alimenter le plan de traitement des risques ISO/IEC 27001:2022 et la Déclaration d’applicabilité.

Commencez par un service métier, par exemple une plateforme de facturation client, une application de trading, un portail patient ou un système de gestion des tenants SaaS. Incluez la production, la préproduction, le CI/CD, l’infrastructure cloud, les outils de surveillance, les bases de données, les intégrations SaaS et les services gérés par des fournisseurs.

Rattachez cela au Zenith Blueprint, phase Risk Management, étape 14, dans laquelle Clarysec aligne les politiques de traitement avec les renvois réglementaires. À cette étape, les contrôles de développement sécurisé et de pipeline incluent l’absence de secrets codés en dur, la revue par les pairs, l’analyse statique automatisée, l’analyse des dépendances, la séparation du développement, des tests et de la production, l’authentification multifacteur pour l’accès aux pipelines, l’intégrité des artefacts de build et la journalisation CI/CD.

Collectez les identités et secrets depuis le fournisseur d’identité, l’IAM cloud, le coffre-fort de secrets, Kubernetes, les variables CI/CD, les paramètres de référentiels, les utilisateurs de bases de données, les consoles d’administration SaaS, les outils de gestion des certificats et la documentation fournisseur.

Évaluez le risque des identités qui disposent d’un accès à l’environnement de production, de droits à privilèges, d’un accès aux données à caractère personnel, d’une dépendance à une fonction critique ou importante, d’un contrôle fournisseur, de jetons à longue durée de vie, sans propriétaire, sans rotation, sans surveillance ou avec stockage codé en dur. Utilisez les critères de risque ISO/IEC 27001:2022 pour noter la vraisemblance et l’impact. Utilisez l’analyse des fonctions critiques ou importantes DORA le cas échéant. Utilisez les considérations d’impact GDPR lorsque des données à caractère personnel sont accessibles. Utilisez l’impact de service NIS2 lorsqu’une interruption ou un préjudice client est plausible.

Pour chaque NHI à risque élevé, appliquez des actions de traitement. Déplacez les secrets depuis le code source, les documents et les variables CI/CD en clair vers un coffre-fort ou un magasin de secrets géré. Remplacez les comptes de service partagés par des identités de charge de travail uniques. Désactivez la connexion interactive pour les comptes de service. Appliquez le moindre privilège et des identifiants propres à chaque environnement. Configurez la rotation, l’expiration et la révocation d’urgence. Rattachez les secrets à des propriétaires et à des dépositaires. Ajoutez la journalisation de l’authentification, de l’utilisation des jetons et des actions sensibles. Ajoutez des alertes sur la géographie anormale, les horaires inhabituels, les volumes inhabituels ou l’accès à de nouvelles ressources. Mettez à jour les contrats fournisseurs pour le traitement des identifiants, le support en cas d’incident et les droits d’audit. Documentez les exceptions avec l’approbation du propriétaire du risque et une date d’expiration.

La Politique relative aux données de test et aux environnements de test Politique relative aux données de test et aux environnements de test soutient la séparation des environnements :

L’intégration avec les pipelines CI/CD doit imposer la séparation des environnements et des identifiants d’authentification.

Cette clause est fréquemment décisive. Si le développement, le test et la production partagent des secrets, un environnement à faible risque peut devenir un chemin de violation vers la production.

Le sprint doit se terminer par un dossier d’éléments probants, et pas seulement par une liste de constats. Incluez l’export du registre NHI, les entrées d’appréciation des risques, le plan de traitement, la cartographie de la Déclaration d’applicabilité, les références de politiques, les captures d’écran du coffre-fort, les journaux de rotation, les approbations de revue d’accès, les résultats d’analyse de détection des secrets CI/CD, les définitions de règles de surveillance, la matrice de responsabilité des identifiants fournisseurs, la procédure opérationnelle de réponse aux incidents et les exceptions avec propriétaires et dates d’expiration.

Journalisation et détection : prouver que l’usage des identités machine est visible

Une identité machine bien inventoriée mais invisible dans les journaux reste dangereuse. La détection fait partie du récit de contrôle.

La Politique de journalisation et de surveillance pour PME de Clarysec Politique de journalisation et de surveillance pour PME inclut les éléments probants d’authentification :

Journaux d’authentification : tentatives de connexion réussies et échouées, durée de session, utilisation de l’authentification multifacteur

Pour les NHI, adaptez cette exigence à l’authentification machine. Vous n’aurez peut-être pas d’utilisation de l’authentification multifacteur pour une identité de charge de travail, mais vous devez disposer d’événements d’authentification, d’utilisation de jetons, d’utilisation de certificats, de métadonnées d’appels API, de la charge de travail source, du service de destination, de la durée de vie des jetons, des événements d’échec et des actions à privilèges.

Dans Zenith Controls, la mesure ISO/IEC 27002:2022 8.2, Droits d’accès privilégiés, est liée à la journalisation et à la surveillance, car les comptes à privilèges exigent des enregistrements détaillés et une supervision. Zenith Controls relie également 8.2 à la gestion des identités, aux droits d’accès, à la restriction d’accès à l’information et à l’authentification sécurisée. Pour les auditeurs, cela signifie que les identités non humaines à privilèges doivent être revues et surveillées avec le même sérieux que les administrateurs humains, parfois davantage.

Les bonnes questions de surveillance incluent :

• Un compte de service s’est-il authentifié depuis une charge de travail ou une plage d’adresses IP inattendue ?
• Une clé API a-t-elle accédé à un nouvel endpoint ou à un nouveau jeu de données ?
• Un certificat a-t-il été utilisé après son remplacement ?
• Un jeton CI/CD a-t-il déployé en dehors d’un pipeline approuvé ?
• Un compte en lecture seule a-t-il tenté des opérations d’écriture ?
• Un identifiant dormant est-il redevenu actif ?
• Une intégration fournisseur a-t-elle accédé à des données en dehors des horaires ou volumes convenus ?

Lorsque l’alerte de 02:13 se produit, vous devez pouvoir répondre : quelle identité a été utilisée, quel secret l’a authentifiée, quels droits d’accès ont été exercés, quelles données ou quels systèmes ont été affectés, si l’activité était attendue, quel propriétaire peut la valider et si les seuils de notification des incidents sont atteints.

Le regard de l’auditeur : même processus, questions différentes

La position d’audit la plus solide n’est pas « nous sommes conformes à tout ». Elle est : « nous exploitons un processus maîtrisé unique qui produit des éléments probants pour plusieurs obligations ». Les différents auditeurs inspecteront ce processus différemment.

Dans toutes ces perspectives, les constats récurrents sont prévisibles : absence d’inventaire NHI unique, absence de propriétaire pour les identités machine, secrets stockés dans le code ou la documentation, identifiants partagés entre environnements, absence de rotation ou d’expiration, identifiants gérés par des fournisseurs en dehors des revues d’accès, surveillance couvrant les humains mais pas les machines, et procédures de réponse aux incidents ignorant la fuite de secrets.

Chaque constat se cartographie naturellement aux contrôles, politiques et modèles de remédiation Clarysec. Plus important encore, chacun peut être converti en éléments probants mesurables dans le SMSI.

Comment Clarysec vous aide à répondre aux exigences d’audit

L’approche de Clarysec est pratique, car elle part des éléments probants que les auditeurs demanderont et remonte vers les contrôles, politiques et routines opérationnelles.

Dans le Zenith Blueprint, phase Controls in Action, étape 19, Clarysec fournit des orientations directes pour l’authentification machine à machine :

Pour l’authentification machine à machine, par exemple les comptes de service ou les appels API, les clés, certificats et jetons doivent être protégés avec la même rigueur. Évitez d’intégrer des identifiants dans le code. Utilisez des systèmes de gestion des secrets ou des coffres-forts pour les stocker et les soumettre à rotation en toute sécurité.

Un flux de travail Clarysec type pour les identités non humaines inclut la découverte des NHI dans le cloud, les environnements SaaS, le CI/CD, les référentiels, les coffres-forts et les bases de données, l’évaluation des écarts de politique par rapport aux jeux de politiques Clarysec PME ou entreprise, l’appréciation des risques ISO/IEC 27001:2022 et la cartographie du traitement, les mises à jour de la Déclaration d’applicabilité, la cartographie des éléments probants NIS2, DORA, GDPR et NIST CSF, la conception du registre NHI, l’alignement du registre de gestion des clés, l’analyse de détection des secrets, les processus de revue d’accès, les matrices de responsabilité des identifiants fournisseurs, les procédures opérationnelles de réponse aux incidents et les dossiers d’audit avec captures d’écran, exports, journaux, approbations et enregistrements d’exceptions.

Pour les PME, l’approche est proportionnée. Un fournisseur SaaS de 70 personnes n’a pas besoin du même dispositif d’outillage qu’une banque mondiale, mais il a besoin de propriété, de politique, de traitement des risques et d’éléments probants. Pour les entités financières réglementées et les prestataires TIC, le même modèle s’étend à la cartographie des fonctions critiques DORA, à la gouvernance des risques liés aux tiers et aux tests de résilience.

Si votre prochain audit est prévu en 2026, n’attendez pas que l’auditeur découvre les identités non humaines pour vous. Commencez par un service critique et posez cinq questions :

1. Connaissons-nous chaque compte de service, clé API, jeton, certificat et secret CI/CD utilisé par ce service ?
2. Chaque NHI dispose-t-elle d’un propriétaire nommé, d’un dépositaire, d’une finalité et d’une notation de risque ?
3. Les secrets sont-ils placés dans un coffre-fort, soumis à rotation et protégés contre le code source, les documents, les courriels et le stockage en clair ?
4. Les identités machine à privilèges sont-elles revues, surveillées et interdites d’usage interactif ?
5. Pouvons-nous produire des éléments probants pour ISO/IEC 27001:2022, NIS2, DORA et GDPR à partir d’un processus maîtrisé unique ?

Utilisez Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint pour structurer votre parcours de mise en œuvre du SMSI. Utilisez Zenith Controls: The Cross-Compliance Guide Zenith Controls pour relier les mesures ISO/IEC 27002:2022 relatives à l’identité, à l’authentification, aux privilèges, à la journalisation, à la cryptographie, au développement sécurisé et aux fournisseurs aux éléments probants réglementaires. Utilisez la bibliothèque de politiques PME et entreprise de Clarysec, notamment la Politique de gestion des comptes utilisateurs et des privilèges pour PME Politique de gestion des comptes utilisateurs et des privilèges pour PME, la Politique sur les contrôles cryptographiques Politique sur les contrôles cryptographiques, la Politique de développement sécurisé Politique de développement sécurisé et la Politique relative aux exigences de sécurité des applications Politique relative aux exigences de sécurité des applications, afin de transformer de bonnes intentions en exigences opposables.

L’alerte de 02:13 se produira quelque part. La question est de savoir si votre organisation peut répondre, éléments probants à l’appui, qui détenait la clé, ce qu’elle ouvrait, pourquoi elle existait et à quelle vitesse vous pouvez la sécuriser.