Page d'accueil d'OpenText.
Thèmes techniques

Qu'est-ce que la gestion des identités pour les INSA ?

Illustration des éléments informatiques avec un point d'interrogation en point de mire

Présentation

Tête humaine d'IA futuriste avec des circuits numériques et des modèles de données lumineux

Les identités non humaines (INH) sont des entités programmatiques qui effectuent des opérations et ont accès à diverses informations, dont certaines peuvent être sensibles ou doivent être sécurisées.

Gestion de l'identité pour les INSA

Qu'est-ce qui différencie les identités non humaines des identités basées sur le carbone ?

L'identité non humaine ne se résume pas à l'internet des objets (IoT). Il s'agit d'une identité utilisée par n'importe quel logiciel ou matériel, c'est-à-dire une identité qui n'est pas une personne.

En ce qui concerne la gestion des identités et des accès, voici une comparaison générale entre les INSA et les comptes d'utilisateurs.

Caractéristiques Comptes d'utilisateurs INSA
Origine Embarquement des RH, portails en libre-service, magasins d'identités de partenaires de confiance, etc. Souvent attribué dynamiquement au moment de la création par les processus et les outils de développement.
Les types Employés, contractants, partenaires, clients, autres types de personnes, etc. Comptes de service, clés et jetons d'API, identités des machines, identités du nuage et des charges de travail, et de plus en plus d'agents d'automatisation et d'IA.
Volume Proportionnelle à la main-d'œuvre ou à la base de consommateurs. Les identités humaines sont beaucoup plus nombreuses que les identités humaines, dans une proportion de 50, 100 pour un, voire plus. Ces identités sont également beaucoup plus dynamiques, ce qui signifie qu'elles peuvent apparaître rapidement et avoir un cycle de vie relativement court.
Principales menaces pour la sécurité Particulièrement vulnérables à l'hameçonnage et au vol de données d'identification. Vulnérable à l'exposition, à l'utilisation abusive et à l'exploitation des informations d'identification. En raison de leur nature dynamique, les INSA sont susceptibles d'hériter de privilèges excessifs.
Gestion du cycle de vie Rationalisation via les systèmes RH et IAM. Les INSA sont souvent beaucoup plus dynamiques, ce qui signifie qu'elles peuvent avoir un cycle de vie relativement court. Souvent incohérent avec une visibilité limitée.
Contrôles d'accès Protégé par des contrôles tels que les clés d'accès et l'authentification multifactorielle (MFA). Manque de contrôles inhérents, reposant souvent sur des identifiants statiques tels que des clés API ou des certificats.

Comme ils sont liés à des applications, des services et d'autres types de ressources numériques, ils se comportent et ont probablement des exigences différentes en matière d'IAM :

  • La racine de la confiance n'est plus les RH et leurs processus, qui ont depuis longtemps prouvé les identités avant que les comptes ne soient créés. En revanche, de nouveaux processus de contrôle et de preuve de l'identité doivent être créés pour les identités programmatiques.
    • Facteur de forme et durée de vie des justificatifs : contrairement à l'authentification multifactorielle centrée sur l'être humain et aux clés d'accès, les INSA utilisent souvent des jetons à courte durée de vie, fournis par l'intermédiaire d'un courtier.
    • Les identifiants clients OAuth 2.0 sont couramment utilisés pour les flux machine-machine ainsi que pour d'autres identifiants/rôles cloud temporaires qui utilisent des jetons, qui expirent rapidement et ne peuvent pas être réutilisés.
  • Confiance zéro - Bien quele principe du moindre privilège demeure fondamental, sa mise en œuvre nécessite une charge de travail plutôt qu'une position de l'utilisateur ou de l'appareil.
    • Le principe du moindre privilège protège les ressources, et non les périmètres, ce qui implique de réévaluer en permanence chaque demande, y compris de service à service. Les plateformes d'informatique en nuage imposent désormais un accès conditionnel aux identités des charges de travail (et non plus seulement aux utilisateurs) et font apparaître les risques liés aux identités des charges de travail pour permettre des décisions stratégiques automatisées. Il s'agit de l'équivalent machine des mesures de risque utilisateur qui déterminent les niveaux d'authentification.
    • Obtenir le moindre privilège en utilisant des déclencheurs de cycle de vie - contrairement à la gestion du cycle de vie humain, le déprovisionnement et l'abandon de l'INSA sont pilotés par des pipelines et une infrastructure en tant que code avec un propriétaire explicite attaché à la création. La règle de base est de ne pas laisser les identités survivre aux charges de travail.
    • Réorienter la télémétrie et la détection de l'UEBA des personnes vers des analyses d'identité tenant compte des machines. Pour identifier les charges de travail à risque, traitez l'utilisation abusive des services comme un problème de détection de première classe avec des signaux qui modélisent les lignes de base de la charge de travail pour chaque surface. Les règles d'anomalie centrées sur l'homme et couvrant une journée ne permettent pas de détecter les abus cachés des machines.

Quelle est la cause de l'augmentation rapide des INSA dans l'ensemble de l'organisation ?

La prolifération des identités non humaines est un sous-produit nécessaire de l'innovation moderne. Bien qu'elle soit essentielle à la mise en place de systèmes évolutifs et efficaces, cette nouvelle main-d'œuvre numérique exige une refonte complète de la sécurité et de la gouvernance afin de se protéger contre les risques uniques qu'elle présente. Il est fort probable qu'en observant votre propre organisation, vous constatiez l'apparition de tous les types d'automatisation numérique. Pour la plupart des organisations, cette nouvelle "main-d'œuvre numérique" croît beaucoup plus rapidement que la main-d'œuvre humaine. Pour chaque employé humain, il peut y avoir des dizaines, voire plus d'une centaine d'identités non humaines qui remplissent des fonctions critiques. Cette échelle représente un défi de taille pour les modèles traditionnels de gestion des identités et des accès (IAM), qui ont été conçus pour un monde centré sur l'homme.

Ce n'est un secret pour personne que la dernière frontière de cette prolifération est l'essor de l'IA et des agents autonomes. Les systèmes d'IA étant de plus en plus capables de prendre leurs propres décisions et d'agir, ils ont besoin de leurs propres identités pour interagir avec les applications et les données. Ces agents d'IA "" représentent une nouvelle catégorie d'INSA qui fonctionne en continu et dont le comportement peut être plus dynamique et moins prévisible que celui d'un compte de service traditionnel.

La prolifération des INSA dans les organisations est plus qu'une tendance ; il s'agit d'un changement fondamental motivé par la demande moderne de rapidité et d'échelle. Cette croissance exponentielle est le résultat direct de l'automatisation, de l'informatique en nuage et de l'essor des nouvelles technologies qui créent un volume massif de nouvelles identités qui doivent être sécurisées et gérées.

Si l'on prend un peu de recul, à un niveau plus élevé, les principaux moteurs de la prolifération de l'INSA sont la réduction des coûts, l'augmentation de l'efficacité et la mise en place d'une innovation rapide dans la mesure du possible. Voici une façon de les organiser :

  • L'informatique en nuage et les microservices : Le passage à l'informatique en nuage, en particulier avec les architectures multi-cloud et microservices, a fait exploser le nombre d'INSA. Chaque petit service, conteneur ou API a désormais besoin de sa propre identité pour communiquer en toute sécurité. Une simple demande d'un utilisateur peut déclencher une réaction en chaîne impliquant des dizaines d'interactions de machine à machine, chacune nécessitant une identité unique.
  • DevOps et CI/CD : le développement de logiciels modernes repose sur des flux de travail automatisés pour l'intégration et la livraison continues (CI/CD). Les identités non humaines sont les ouvriers de cette chaîne de montage. Les comptes de service et les jetons d'API permettent aux serveurs de construction et aux pipelines de déploiement d'accéder aux référentiels de code et de provisionner l'infrastructure sans intervention humaine. Cette automatisation est cruciale pour les cycles de publication rapides, mais elle crée également une surface d'attaque massive.
  • L'internet des objets (IdO) : La croissance des appareils connectés ajoute une autre couche d'INSA. Chaque capteur, appareil intelligent et équipement industriel a besoin d'une identité pour se connecter au réseau et transmettre des données. La sécurisation de ces milliers de points de terminaison distribués est un défi majeur, car ils fonctionnent souvent dans des environnements moins contrôlés.

Pourquoi les équipes de sécurité doivent-elles adopter une approche différente pour sécuriser les INH ?

Malheureusement, pour de nombreux organismes de cybersécurité, la gestion des identités et des accès (IAM) aux INSA n'est qu'une réflexion après coup, couramment mise en œuvre par le biais d'une adoption et de processus ad hoc. Voici quelques raisons pour lesquelles la gestion intégrée des INSA peut être difficile et doit être traitée avec autant de soin que les identités basées sur le carbone.

Découverte et inventaire

La réalité de l'INSA, c'est qu'ils prolifèrent à une vitesse et à une échelle telles qu'il est impossible de les suivre manuellement. Cela représente un défi pour les organisations qui ont complété leur infrastructure IAM actuelle par des processus d'ajustement de l'identité. Vous ne pouvez pas sécuriser ce que vous ne pouvez pas voir, et c'est le défi fondamental des INSA. Le plus souvent, cela signifie que vous devez obtenir un inventaire complet et en temps réel de chaque identité non humaine dans votre environnement pour une gestion efficace. Plus qu'une simple liste, le processus de découverte doit être automatisé pour trouver une clé API, un compte de service et un jeton, que ce soit dans le nuage, sur site ou dans un pipeline DevOps. En plus de les trouver, vous devez contextualiser chaque identité, comprendre son objectif, son propriétaire et les ressources auxquelles elle peut accéder. Il s'agit d'une base de référence essentielle, qui transforme un paysage chaotique en un système structuré et gérable.

Gestion du cycle de vie

Contrairement aux identités humaines dont les dates d'embauche et d'expiration sont clairement définies, les INSA ont un cycle de vie dynamique qui exige l'automatisation. Une gestion efficace nécessite une approche "du début à la fin". Cela signifie qu'il faut doter les INSA des bonnes autorisations dès le départ, souvent directement dans les flux de travail de développement. Cette exigence pose souvent un défi majeur aux organisations qui concentrent leur gestion sur les identités résidant dans Microsoft Active Directory, laissant les autres magasins d'identité de leur organisation subir une dérive de l'intégrité de l'identité. À ce titre, deux questions essentielles se posent. Les INSA disposent souvent de leurs propres magasins d'identité, ce qui signifie que les organisations qui ont axé l'automatisation de la gestion des identités d'entreprise sur Active Directory devront intégrer un certain type d'automatisation supplémentaire. Cela signifie également que toute solution adoptée n'offre pas une gestion continue de l'identité, ce qui introduit des vulnérabilités en matière d'accès.

Il s'agit également d'établir un calendrier de rotation strict, en mettant automatiquement à jour les informations d'identification afin de minimiser le risque qu'un secret compromis soit utilisé pendant une période prolongée. Tout aussi important est le déclassement automatisé des identités lorsqu'elles ne sont plus nécessaires. Cela permet d'éviter que des informations d'identification orphelines ou oubliées ne deviennent des portes dérobées persistantes pour les attaquants.

Contrôle d'accès et gouvernance

Le contrôle d'accès aux INSA consiste à appliquer des règles à la vitesse d'une machine. Nous connaissons l'importance des principes de sécurité "zéro confiance" et des pratiques efficaces de "moindre privilège", qui consistent à n'accorder à une identité que les autorisations dont elle a besoin pour effectuer une tâche spécifique, et rien de plus. Si ce principe constitue une défense efficace contre tous les types de violations, il est particulièrement précieux pour les INSA en raison de leur nature programmatique. Un autre élément essentiel de la gouvernance est la capacité à centraliser l'application des politiques, ce qui garantit que des règles d'accès cohérentes sont en place et appliquées dans tous vos systèmes, qu'ils se trouvent dans différents nuages ou sur place.

Pour lutter contre le problème courant des secrets codés en dur, cela signifie également que vous disposez d'une plateforme de gestion des secrets dédiée qui peut être utilisée par vos développeurs pour stocker et injecter en toute sécurité des informations d'identification au moment de l'exécution. Cela devra être mis en place avant que vous puissiez adopter une politique visant à ce que les développeurs gardent les secrets d'identification en dehors du code source.

L'accès juste à temps (JIT), un concept avancé de gouvernance des accès, peut fournir des autorisations temporaires à haut niveau de privilège qui sont automatiquement révoquées une fois le travail effectué, ce qui réduit considérablement la fenêtre d'opportunité pour les attaquants. Compte tenu de la nature dynamique des INSA, les organisations trouveront probablement une valeur ajoutée à l'accès à l'ECE pour les INSA qu'elles n'auraient peut-être pas jugée nécessaire pour les utilisateurs traditionnels.

Surveillance continue et détection des menaces

Les INSA fonctionnent 24 heures sur 24, 7 jours sur 7, et votre sécurité doit en faire autant. La surveillance continue est essentielle pour détecter les anomalies et répondre aux menaces en temps réel. Cela implique d'établir une base de référence du comportement normal pour chaque identité et d'utiliser l'analyse comportementale pour repérer les écarts. Par exemple, si une identité qui accède normalement à une base de données spécifique tente soudainement de se connecter à une application RH, une alerte immédiate doit être déclenchée. Le maintien de pistes d'audit détaillées de toutes les activités liées à l'INSA est également essentiel pour la conformité et l'analyse médico-légale. Grâce à ce niveau de surveillance, votre vaste réseau d'identités de machines, qui représentait un risque pour la sécurité, devient une composante bien gérée et transparente de vos opérations numériques.


Avec l'expansion des INSA, comment puis-je respecter mes engagements en matière de conformité et d'audit ?

Les INSA posent de nouveaux défis en matière de conformité et de préparation à l'audit, car elles fonctionnent en dehors des cadres traditionnels conçus pour les utilisateurs humains. Les normes réglementaires telles que GDPR, HIPAA et SOX exigent que les organisations démontrent qu'elles contrôlent qui a accès aux données sensibles, quand et pourquoi. Les INSA - telles que les comptes de service, les jetons d'API et les agents d'automatisation - manquent souvent de propriété claire, de visibilité sur le cycle de vie et de gouvernance cohérente, ce qui rend difficile le respect de ces exigences.

L'un des principaux problèmes est la facilité de découverte. Les INSA peuvent être créées dynamiquement par des pipelines de développement ou des services en nuage, et sans outils d'inventaire automatisés, nombre d'entre elles passent inaperçues. Ce manque de visibilité nuit aux efforts d'audit, car les organisations ne peuvent pas sécuriser les identités dont elles ignorent l'existence, ni en rendre compte. En outre, les INSA utilisent souvent des identifiants statiques ou des secrets codés en dur, qui sont difficiles à faire tourner et à contrôler, ce qui augmente le risque de non-conformité.

Les pistes d'audit doivent également évoluer. Les INSA effectuent des tâches critiques, parfois avec des privilèges élevés, et leurs actions doivent être enregistrées avec la même rigueur que les utilisateurs humains. Il s'agit notamment de suivre les schémas d'accès, l'utilisation des identifiants et les modifications apportées aux autorisations. Sans cela, les organisations risquent d'échouer aux audits ou de négliger les violations.

Pour rester en conformité, les organisations doivent étendre la gouvernance des identités aux INSA - en automatisant la découverte, en appliquant le principe du moindre privilège, en effectuant une rotation des identifiants et en conservant des journaux détaillés. Il est essentiel de traiter les INSA comme des citoyens de premier ordre dans les programmes de gestion des actifs intellectuels pour respecter les engagements modernes en matière de conformité et d'audit.


Quelles sont les meilleures pratiques en matière d'intégration et de désintoxication des INSA ?

L'intégration et le retrait efficaces des identités non humaines (INH) sont essentiels au maintien de la sécurité et de l'intégrité opérationnelle dans les environnements modernes. Contrairement aux utilisateurs humains, les INSA - tels que les comptes de service, les jetons API et les agents d'automatisation - sont souvent créés et détruits de manière programmatique, ce qui rend les processus manuels insuffisants et risqués. Les meilleures pratiques commencent par le provisionnement automatisé. Les INSA devraient être créées dans le cadre de processus de développement sécurisés, avec des métadonnées permettant d'identifier leur objectif, leur propriétaire et la charge de travail qui leur est associée. Cela garantit la responsabilité et permet l'application de la politique dès le moment de la création.

L'accès doit être accordé selon les principes du moindre privilège, avec des informations d'identification de courte durée et des autorisations adaptées à la tâche. Les identifiants statiques et les secrets codés en dur doivent être évités au profit de secrets dynamiques injectés au moment de l'exécution par l'intermédiaire de coffres-forts sécurisés. Cela permet de réduire l'exposition et de répondre aux exigences de conformité.

L'intégration est tout aussi importante. Les INSA doivent être mises hors service dès que les charges de travail qui leur sont associées sont supprimées. Ce processus devrait être automatisé et déclenché par des événements de l'infrastructure en tant que code ou du pipeline CI/CD. Les identités orphelines, c'est-à-dire celles qui restent après la suppression d'une charge de travail, présentent de graves risques pour la sécurité et sont souvent exploitées dans le cadre de violations.

Les politiques de rotation et d'expiration des justificatifs doivent être appliquées tout au long du cycle de vie. Des audits réguliers des inventaires de l'INSA permettent d'identifier les identités inutilisées ou surprivilégiées. En intégrant ces pratiques dans votre stratégie de gouvernance des identités, vous pouvez vous assurer que les INSA sont gérées en toute sécurité, de leur création à leur retrait, en réduisant les risques et en soutenant la conformité dans des environnements dynamiques et " cloud-native ".


Comment la gouvernance des accès JAT peut-elle contribuer à satisfaire aux obligations de conformité en matière de sécurité ?

La gouvernance des accès JIT joue un rôle essentiel en aidant les organisations à respecter leurs obligations en matière de sécurité, en particulier lorsque les identités non humaines (NHI) deviennent de plus en plus courantes. Les modèles d'accès traditionnels accordent souvent des autorisations permanentes, ce qui peut conduire à des comptes surprivilégiés et à des risques accrus. L'accès JIT inverse ce modèle en accordant des autorisations temporaires, spécifiques à une tâche, uniquement en cas de besoin, et en les révoquant automatiquement par la suite, ce qui réduit considérablement la surface d'attaque.

En ce qui concerne la conformité, cela signifie un contrôle plus strict de qui - ou de quoi - a accès aux systèmes et aux données sensibles. L'accès à l'ECE garantit que les INSA, tels que les comptes de service et les agents d'automatisation, opèrent dans des limites clairement définies. Il prend en charge le principe du moindre privilège par défaut, conformément aux exigences réglementaires qui imposent un accès minimal et des contrôles d'accès stricts.

La JAT améliore également l'auditabilité. Chaque demande d'accès est limitée dans le temps et motivée, ce qui facilite le suivi, la justification et l'établissement de rapports lors des audits. Ce niveau de granularité aide à démontrer la conformité avec des normes telles que GDPR, HIPAA et SOX, qui exigent des enregistrements détaillés du comportement de l'identité et des événements d'accès.

Dans des environnements dynamiques tels que le cloud et DevOps, l'accès JIT s'intègre de manière transparente aux flux de travail automatisés, permettant des opérations sécurisées et conformes sans ralentir l'innovation. En intégrant l'ECE dans votre stratégie de gouvernance des identités, vous ne renforcez pas seulement la sécurité, mais vous construisez également une position de conformité défendable dans un paysage numérique de plus en plus complexe.

Comment pouvons-nous vous aider ?

Notes de bas de page