{ Tribune Expert } - Le rôle des RSSI dans la gestion des IAM et de la sécurité des identités machine

La gestion des identités et des accès (IAM) a commencé comme une fonction informatique, avec pour seul objectif de donner aux utilisateurs humains le bon accès aux bons systèmes. Mais aujourd'hui, l'identité est devenue la principale surface d'attaque, avec au moins 80 % de toutes les violations modernes impliquant des identités compromises ou volées par des adversaires qui exploitent une mauvaise gestion des identités.

Cette réalité a fait peser la responsabilité du risque sur l'équipe chargée de protéger l'organisation contre les attaques, à savoir la sécurité. Ce qui signifie en fin de compte le RSSI. Cependant, il y a un angle mort : les identités machines (Non-Human Identities - NHI). Il s'agit d'un oubli critique. Les identités machines sont au moins 45 fois plus nombreuses que les humains dans l'entreprise, certaines estimations allant jusqu'à 100 pour 1.

Alors que les entreprises s'efforcent de fournir plus de code plus rapidement que jamais, le nombre de ces identités machine, telles que les comptes de service, les API et les workloads automatisées, ne fera qu'accroître ce déséquilibre. Les LLM et l'adoption rapide de nouveaux assistants de codage et d'outils de productivité basés sur l'IA ne feront qu'accélérer cette tendance.

Si les RSSI ne se dotent pas de stratégies IAM pour couvrir les identités machines, ils laissent sans défense l'une de leurs plus grandes surfaces d'attaque.

IAM sans NHI La gouvernance est incomplète

Le modèle IAM traditionnel a longtemps tourné autour des identités humaines : intégration des employés, octroi d'un accès basé sur les rôles, surveillance des violations de politique et déprovisionnement des comptes si nécessaire. Cette approche centrée sur l'humain a considérablement évolué, avec des cadres de gouvernance solides, des mandats de conformité et des contrôles de sécurité tels que l'authentification multifactorielle (MFA) et les principes de confiance zéro. Le marché des outils a suivi le rythme des innovations de fournisseurs tels qu'Okta, OneLogin et Auth0.

Mais les NHI fonctionnent selon des hypothèses très différentes :

? Elles n'ont pas de mots de passe, mais s'appuient sur des clés API, des jetons et des identifiants cryptographiques pour s'authentifier.

? Elles ne suivent pas les processus traditionnels du cycle de vie : les comptes de service et les identités des machines persistent souvent indéfiniment, même après que leur objectif initial soit devenu obsolète.

? Elles n'ont pas de propriétaire clairement défini, ce qui signifie que leur sécurité est souvent négligée.

Les NHI sont également très susceptibles d'être utilisées à mauvais escient. L'éparpillement des secrets, c'est-à-dire la prolifération incontrôlée des identifiants, est devenu un risque majeur pour la sécurité. Les clés API et les jetons d'accès sont souvent codés en dur dans le code source, intégrés dans les fichiers de configuration ou exposés dans les journaux. Les identifiants à longue durée de vie, qui ne font l'objet

d'aucune véritable gouvernance ou automatisation des politiques de rotation, sont une cible de choix pour les pirates. Par défaut, de nombreux systèmes plus anciens n'expirent jamais, ce qui signifie que certaines clés API dans les environnements cloud n'ont pas été renouvelées depuis des années. De plus, les NHI sont généralement sur-autorisées. Les développeurs sont souvent pressés de faire fonctionner quelque chose et peuvent ne pas délimiter les secrets aussi strictement que nécessaire selon le principe du moindre privilège. L'absence de cadres de gouvernance clairs ajoute à leur confusion, ce qui conduit à accorder à de nombreuses identités machine des autorisations excessives juste pour « faire fonctionner » plutôt que pour être sécurisées. Le résultat ? Une faille de sécurité massive que les adversaires adorent exploiter.

Si la stratégie IAM vise réellement à protéger l'accès, elle doit inclure les identités de machine. Sinon, les entreprises ne résolvent que la moitié du problème.

Pourquoi les RSSI doivent-ils s'approprier la gouvernance des identités de machine ?

Étant donné que l'IAM devrait désormais être une fonction de sécurité, il s'ensuit que les identités de machine, qui constituent la catégorie d'identités la plus vulnérable et dont la croissance est la plus rapide, doivent être régies par le RSSI. Voici pourquoi.

Les identités de machine sont un vecteur d'attaque majeur

Les identités numériques représentent l'une des surfaces d'attaque les plus importantes et les moins surveillées dans l'entreprise moderne. Les pirates ciblent de plus en plus les clés API divulguées, les comptes de service compromis et les identités de machine mal configurées pour obtenir un accès non autorisé.

Quelques exemples de violations très médiatisées ont démontré ce risque :

? Le département du Trésor américain a été violé par une clé API compromise, permettant aux pirates d'accéder aux postes de travail et aux documents non classifiés.

? Le groupe Toyota a publiquement révélé une clé d'accès à un serveur de données interne qui a permis un accès non autorisé aux données réelles des clients pendant 5 ans.

? Le New York Times a révélé un jeton GitHub, ce qui a entraîné la fuite en ligne de 5600 de ses dépôts de code.

La conformité et la gestion des risques l'exigent Les cadres réglementaires tels que PCI DSS, RGPD et ISO 27001, ainsi que les recommandations du National Institute of Standards and Technology (NIST), incluent tous des exigences strictes en matière de contrôle d'accès et de privilèges minimums, mais ils se concentrent souvent sur les identités humaines.

À mesure que les régulateurs se rendront compte que les identités non humaines présentent des risques identiques (voire supérieurs), les entreprises seront tenues responsables de la sécurisation de toutes les identités. Cela implique d'appliquer le principe du moindre privilège aux identités non humaines, comme pour les utilisateurs humains. Cela implique également de suivre le cycle de vie complet des identités des

machines, de leur création à leur mise hors service, ainsi que d'auditer et de surveiller les clés API, les jetons et les comptes de service avec la même rigueur que les identifiants des employés.

Attendre la pression réglementaire après une violation est trop tard. Les RSSI doivent agir de manière proactive pour prendre de l'avance sur ces changements à venir.

La stratégie Zero Trust nécessite une gouvernance des identités numériques

Les stratégies Zero Trust se concentrent sur l'identité comme nouveau périmètre, mais si les identités numériques ne sont pas incluses, la majorité du périmètre d'identité reste grande ouverte.

Une approche Zero Trust des identités numériques signifie :

? Une vérification continue - les identités numériques doivent être continuellement authentifiées et autorisées, et non pas se voir accorder un accès permanent.

? Application du principe du moindre privilège : les identités non humaines doivent disposer d'autorisations minimales et être régulièrement examinées.

? Segmentation et isolement : les identités non humaines doivent être limitées aux workloads spécifiques qu'elles servent.

Le modèle ZT n'est pas complet si les identités non humaines ne sont pas gérées aussi rigoureusement que les identités humaines.

Élaborer une stratégie IAM complète

Une stratégie IAM moderne doit commencer par une découverte et une cartographie complète de toutes les identités au sein de l'entreprise. Il s'agit notamment de comprendre non seulement où les secrets associés sont stockés, mais aussi leurs origines, leurs autorisations et leurs relations avec d'autres systèmes. Les organisations doivent mettre en oeuvre des plateformes de gestion des secrets robustes qui peuvent servir de source unique de vérité, garantissant que toutes les informations d'identification sont cryptées et surveillées.

La gestion du cycle de vie des identités machines nécessite une attention particulière. Contrairement aux identités humaines, qui suivent des schémas prévisibles d'emploi et de modes de vie, les identités des machines nécessitent des processus automatisés pour leur création, leur rotation et leur mise hors service. Les équipes de sécurité doivent mettre en place des systèmes capables de suivre la date de création des secrets, leur créateur et, surtout, la date à laquelle ils doivent être remplacés ou retirés.

Comment étendre l'IAM aux identités machines

L'extension de l'IAM aux NHI nécessite un cadre de gouvernance adapté qui tienne compte de leurs défis uniques. Voici les prochaines étapes recommandées pour aligner la gouvernance des identités machine sur les objectifs de sécurité

Découvrir toutes les NHI

Sans savoir que des identités existent déjà dans une organisation, il est impossible de les sécuriser. Espérons que cela a été bien documenté au fur et à mesure de leur création, mais ce ne sera probablement pas le cas. Toute cartographie doit au minimum indiquer où les secrets NHI sont stockés, quand ils ont été créés et par qui. Il faut également pouvoir voir quand ils ont été créés, s'ils ont été remplacés et, surtout, s'ils sont toujours utilisés.

Centraliser la gestion des NHI

Les entreprises gèrent en moyenne 6 instances distinctes de secrets managers. Cette prolifération de secrets managers entraîne un manque de visibilité dans l'ensemble de l'entreprise, même si un service, une équipe DevOps ou une équipe d'application dispose d'une vue sur les secrets de son équipe. Il est nécessaire de trouver un moyen de s'assurer que chaque secret est stocké et géré à partir du seul endroit le plus approprié. L'expansion des secrets managers implique également un risque de duplication des clés dans l'ensemble des systèmes. Cela ajoute de la complexité au processus de rotation, en particulier en cas d'incident. Les équipes de sécurité doivent disposer d'un moyen de s'assurer que lorsqu'un secret est soumis à rotation, cela est appliqué partout.

Appliquer les politiques de rotation et de privilège minimum

Obtenir toutes les combinaisons possibles d'autorisations correctement attribuées pour accorder à une application juste assez de privilèges pour faire le travail est long et délicat. Il est fort probable qu'au moins certaines de les NHI aient plus d'accès que nécessaire, y compris la possibilité d'écrire ou de supprimer des objets ou d'autres données. Sans comprendre quelles sont les autorisations des NHI, il est impossible de les auditer pour supprimer les autorisations excessives. Il ne s'agit pas d'un exercice ponctuel, car chaque rotation de justificatifs d'identité introduit le risque que de nouveaux privilèges inutiles soient introduits.

Ce qu'il faut, c'est une analyse continue pour vérifier que toute modification des NHI a respecté le principe du moindre privilège. Une fois que tous les privilèges des NHI sont compris, les organisations peuvent mettre en oeuvre une rotation mieux automatisée et une politique de gouvernance des NHI à grande échelle, en s'assurant que le nouveau secret suit le modèle de gouvernance que vous avez établi.

Intégrer les NHI dans le Zero Trust

Aucune NHI ne devrait être autorisée à agir sans authentification appropriée. Actuellement, les NHI reposent, pour la plupart, sur des identifiants à long terme. Par défaut, la plupart des clés API, mots de passe et autres jetons d'authentification sont valables à vie. Dans un monde idéal, une organisation serait en mesure de fournir une authentification qui ne dure que le temps de la demande du workload ou des cadres d'identité robustes tels que SPIFFE/SPIRE.

La plupart des organisations ne peuvent pas mettre en oeuvre ces approches pour les applications et infrastructures existantes en raison du manque de visibilité sur leur inventaire NHI existant et de l'obstacle technique que représente la refonte du code pour adopter une nouvelle méthodologie. Mais en transférant les secrets NHI vers une gestion centralisée des secrets d'entreprise, vous pouvez atteindre cet objectif beaucoup plus rapidement. Bien que cela ne fasse que s'inscrire dans le cadre d'une stratégie de confiance zéro, telle que définie par le NIST, il est impossible d'y parvenir sans pouvoir garantir que les identifiants ne sont utilisés que par l'entité prévue. La cartographie de ces identités non humaines est une étape obligatoire.

Une stratégie IAM unifiée pour les humains et les machines

Dans un monde où l'identité est devenue le nouveau périmètre de sécurité, les RSSI doivent adopter une vision holistique englobant à la fois les identités humaines et machine. En intégrant la sécurité des identités machine à leur stratégie IAM globale, les RSSI peuvent non seulement réduire les risques mais aussi faciliter l'innovation et la transformation numérique de leur organisation.

La route peut sembler longue, mais chaque étape franchie renforce la posture de sécurité globale. En fin de compte, une gestion efficace des identités n'est pas seulement une question de conformité ou de sécurité, c'est un véritable avantage compétitif dans l'économie numérique d'aujourd'hui.

* Dwayne McDaniel est Developer & Cybersecurity Advocate chez Gitguardia