Vision Aduneo en IAM : le référentiel au cœur des identités
Les premiers besoins de gérer les identités pour contrôler l’accès à un système d’information remontent probablement à l’apparition du premier mot de passe en 1961. On peut cependant dater le début de la gestion formelle des identités à la fin des années 90 quand les premiers méta-annuaires sont apparus avec pour objectif d’harmoniser les comptes des utilisateurs dans les différents composants d’un système d’information.
Ces premiers pas un peu malheureux ont mené au milieu des années 2000 aux solutions de gestions de identités qui ont atteint leur maturité au début la décennie suivante et qui sont maintenant largement déployées avec satisfaction.
Beaucoup de chemin a donc été parcouru pour cette brique indispensable au bon fonctionnement d’un système d’information.
Et beaucoup de chemin reste encore à parcourir. Nous sommes même à un moment charnière où la gestion des identités connaît progressivement un changement de paradigme en cessant d’être un acteur externe pour prendre place au cœur du système d’information.
Les évolutions les plus marquantes seront abordées dans les deux premières parties. On commence par réaffirmer l’importance du référentiel des identités au centre de tout dispositif.
Des identités pour le Zero Trust et au-delà
Le référentiel des identités s’est appelé annuaire d’entreprise dans le passé. Avec son nouveau nom, il conserve sa fonction principale, qui est de contenir des informations fiables sur ceux qui interagissent avec une organisation et son système d’information.
On se rend compte à ce stade de la difficulté de définir ce que recouvre ce terme d’identité. Sa définition est en effet consensuelle mais vague. C’est un ensemble d’informations qui caractérisent une entité dans un contexte particulier. Or cela n’indique pas directement quelles entités mettre dans le référentiel ni quelles informations leur associer.
La clé réside dans la notion de contexte. Une identité n’a d’existence qu’en fonction de sa finalité. Les identités qui nous intéressent, ce sont principalement celles des acteurs intervenant sur le système d’information (au sens large) et dont les droits doivent être vérifiés.
Le référentiel contient donc essentiellement des identités de personnes : les employés et assimilés, ainsi que les prestataires. Avec le développement des API, s’y ajoutent de plus en plus les systèmes et applications disposant de comptes de service. Et comme une identité est un ensemble d’informations, le référentiel doit souvent contenir des objets connexes enrichissant la connaissance des personnes : l’organigramme des services, les sites, les bâtiments, etc. Souvent ces informations ne se retrouvent pas ailleurs dans le SI et le référentiel des identités devient de facto référentiel pour ces objets.
On vient de s’intéresser aux identités internes à une organisation, mais la notion s’étend aux clients ou aux usagers qui accèdent aux services qui leur sont proposés. On préfère cependant constituer des référentiels distincts. Quant aux partenaires qui se connectent aussi à des systèmes internes (fournisseurs par exemple), on préfère ne pas les gérer et les interconnecter par des mécanismes de fédération.
Si le référentiel contient des identités de personnes, les concepts d’identité et de personne ne sont pas confondus. Il est possible pour une même personne de disposer de plusieurs identités, par exemple parce qu’elle joue des rôles très différents dans le SI (le directeur financier du groupe pourra être en même temps président d’une filiale).
Le périmètre du référentiel peut aussi s’élargir à des populations de personnes qui n’ont pas accès au SI. Bien que les deux notions ne coïncident pas exactement, le référentiel des identités sert souvent d’annuaire de personnes, moyennant un enrichissement des informations sur les identités et en intégrant les employés sans accès au SI.
Des informations fiables sur les identités
La raison d’être d’un référentiel, c’est de détenir des informations fiables à tout instant. Les identités en effet sont utilisées pour autoriser l’accès des systèmes sensibles. Il ne peut donc y avoir de flou sur la véracité des informations, au risque de laisser passer des personnes ayant perdu leurs habilitations.
Rien ne change sur ce plan : la fiabilité des informations continue à reposer sur une gestion rigoureuse du cycle de vie de chaque identité. Un projet d’IAM reste essentiellement un exercice mettant en jeu des compétences organisationnelles et fonctionnelles avec pour objectif de définir les processus et les règles de gestion gouvernant les identités.
Pour atteindre un niveau de fiabilité satisfaisant, il est important que le référentiel soit complet et recouvre l’ensemble des besoins. Il devra donc souvent intégrer les objets connexes cités plus haut que sont les différentes structurations (organisationnelle, opérationnelle, géographique ou financière) avec une modélisation réaliste des relations entre objets d’un même type (organigramme, responsables des personnes) ou de types différents (appartenance au service ou au site). Ce soucis du réalisme amène souvent à devoir gérer les valeurs et les appartenances multiples, dans un modèle qu’il est cependant important de conserver lisible.
Le référentiel des identités n’est pas un annuaire de comptes
Le glissement syntaxique qui s’est opéré d’annuaire vers référentiel est volontaire, afin de clarifier qu’une identité n’est pas un compte. De même qu’une personne peut avoir plusieurs identités, une identité peut se traduire en plusieurs comptes avec des finalités différentes. L’exemple le plus répandu est le compte d’administration. Longtemps générique (root ou administrator), il est désormais attaché à des individus pour assurer une bonne traçabilité des opérations. Il est aussi distinct du compte personnel pour éviter les mauvaises manipulations et limiter les dégâts d’une compromission.
Le référentiel des identités et l’annuaire de comptes diffèrent aussi sur leur principe. Le premier a pour rôle de modéliser la réalité d’une organisation. Le second est un service support aux systèmes et applications qui se doit de présenter les informations pour qu’elles soient exploitables directement.
En corollaire, un annuaire de comptes n’est pas adapté pour représenter le référentiel des identités. L’annuaire suit la norme LDAP pour authentifier des comptes et offrir une image globalisée de l’identité se trouvant derrière. Mais il n’est pas équipé techniquement pour modéliser les objets et leurs relations. La norme LDAP se sait en effet pas réellement gérer les liens, ni au niveau modélisation, ni dans les requêtes.
D’ailleurs ceux qui ont tenté de gérer des identités dans un annuaire (par exemple un Active Directory) sont conscients des difficultés rencontrées, ce serait-ce que pour faire le lien entre les différents comptes d’une même personne.
Le référentiel et l’annuaire sont en revanche complémentaires. Le rôle principal du premier est d’alimenter le second, que ce soit un Active Directory, un annuaire de sécurité LDAP, un annuaire de plateforme cloud comme Azure AD ou un service spécialisé comme Okta ou Auth0.
Lors de cette opération d’alimentation, on procède au doublement des différents comptes d’une même identité et on dénormalise le modèle de données pour présenter l’ensemble des informations pertinentes au sein du compte. Ainsi par exemple, le nom du service, qui est attaché à l’objet correspondant dans le référentiel, se retrouve comme attribut du compte dans l’annuaire.
Les identités dans le cloud ?
Les applications suivent un mouvement inexorable vers le cloud. Mais les réticences sont encore nombreuses pour externaliser les briques d’infrastructure dont fait partie le référentiel.
Et c’est vrai que pour l’instant, il existe encore une forte adhérence entre le système d’information et le logiciel de gestion des identités, au travers de connecteurs, synchronisations, exports, etc. Et il est aussi vrai que l’offre de service de gestion des identités dans le cloud est encore pauvre alors même que celle en gestion des accès est en pointe. Les éditeurs majeurs de l’IAM sont toutefois tous en train de préparer une offre SaaS digne de ce nom. Il est probable que comme pour la messagerie, on en passera par une phase hybride afin de gérer – temporairement – le patrimoine applicatif existant.
De nouvelles relations avec les applications
On a parlé en préambule de changement de paradigme. Pourtant tout ce qui a été évoqué ici n’a rien de révolutionnaire. C’est que le bouleversement commence avec la relation avec les applications, ce qui sera le thème de la seconde partie de cette trilogie.
Auteur : Marc (Directeur technique)
Related Posts
Vision Aduneo en IAM : le référentiel au cœur des identités
Les premiers besoins de gérer les identités pour contrôler l’accès à un système d’information remontent probablement à l’apparition du premier mot de passe en 1961. On peut cependant dater le début de la gestion formelle des identités à la fin des années 90 quand les premiers méta-annuaires sont apparus avec pour objectif d’harmoniser les comptes des utilisateurs dans les différents composants d’un système d’information.
Ces premiers pas un peu malheureux ont mené au milieu des années 2000 aux solutions de gestions de identités qui ont atteint leur maturité au début la décennie suivante et qui sont maintenant largement déployées avec satisfaction.
Beaucoup de chemin a donc été parcouru pour cette brique indispensable au bon fonctionnement d’un système d’information.
Et beaucoup de chemin reste encore à parcourir. Nous sommes même à un moment charnière où la gestion des identités connaît progressivement un changement de paradigme en cessant d’être un acteur externe pour prendre place au cœur du système d’information.
Les évolutions les plus marquantes seront abordées dans les deux premières parties. On commence par réaffirmer l’importance du référentiel des identités au centre de tout dispositif.
Des identités pour le Zero Trust et au-delà
Le référentiel des identités s’est appelé annuaire d’entreprise dans le passé. Avec son nouveau nom, il conserve sa fonction principale, qui est de contenir des informations fiables sur ceux qui interagissent avec une organisation et son système d’information.
On se rend compte à ce stade de la difficulté de définir ce que recouvre ce terme d’identité. Sa définition est en effet consensuelle mais vague. C’est un ensemble d’informations qui caractérisent une entité dans un contexte particulier. Or cela n’indique pas directement quelles entités mettre dans le référentiel ni quelles informations leur associer.
La clé réside dans la notion de contexte. Une identité n’a d’existence qu’en fonction de sa finalité. Les identités qui nous intéressent, ce sont principalement celles des acteurs intervenant sur le système d’information (au sens large) et dont les droits doivent être vérifiés.
Le référentiel contient donc essentiellement des identités de personnes : les employés et assimilés, ainsi que les prestataires. Avec le développement des API, s’y ajoutent de plus en plus les systèmes et applications disposant de comptes de service. Et comme une identité est un ensemble d’informations, le référentiel doit souvent contenir des objets connexes enrichissant la connaissance des personnes : l’organigramme des services, les sites, les bâtiments, etc. Souvent ces informations ne se retrouvent pas ailleurs dans le SI et le référentiel des identités devient de facto référentiel pour ces objets.
On vient de s’intéresser aux identités internes à une organisation, mais la notion s’étend aux clients ou aux usagers qui accèdent aux services qui leur sont proposés. On préfère cependant constituer des référentiels distincts. Quant aux partenaires qui se connectent aussi à des systèmes internes (fournisseurs par exemple), on préfère ne pas les gérer et les interconnecter par des mécanismes de fédération.
Si le référentiel contient des identités de personnes, les concepts d’identité et de personne ne sont pas confondus. Il est possible pour une même personne de disposer de plusieurs identités, par exemple parce qu’elle joue des rôles très différents dans le SI (le directeur financier du groupe pourra être en même temps président d’une filiale).
Le périmètre du référentiel peut aussi s’élargir à des populations de personnes qui n’ont pas accès au SI. Bien que les deux notions ne coïncident pas exactement, le référentiel des identités sert souvent d’annuaire de personnes, moyennant un enrichissement des informations sur les identités et en intégrant les employés sans accès au SI.
Des informations fiables sur les identités
La raison d’être d’un référentiel, c’est de détenir des informations fiables à tout instant. Les identités en effet sont utilisées pour autoriser l’accès des systèmes sensibles. Il ne peut donc y avoir de flou sur la véracité des informations, au risque de laisser passer des personnes ayant perdu leurs habilitations.
Rien ne change sur ce plan : la fiabilité des informations continue à reposer sur une gestion rigoureuse du cycle de vie de chaque identité. Un projet d’IAM reste essentiellement un exercice mettant en jeu des compétences organisationnelles et fonctionnelles avec pour objectif de définir les processus et les règles de gestion gouvernant les identités.
Pour atteindre un niveau de fiabilité satisfaisant, il est important que le référentiel soit complet et recouvre l’ensemble des besoins. Il devra donc souvent intégrer les objets connexes cités plus haut que sont les différentes structurations (organisationnelle, opérationnelle, géographique ou financière) avec une modélisation réaliste des relations entre objets d’un même type (organigramme, responsables des personnes) ou de types différents (appartenance au service ou au site). Ce soucis du réalisme amène souvent à devoir gérer les valeurs et les appartenances multiples, dans un modèle qu’il est cependant important de conserver lisible.
Le référentiel des identités n’est pas un annuaire de comptes
Le glissement syntaxique qui s’est opéré d’annuaire vers référentiel est volontaire, afin de clarifier qu’une identité n’est pas un compte. De même qu’une personne peut avoir plusieurs identités, une identité peut se traduire en plusieurs comptes avec des finalités différentes. L’exemple le plus répandu est le compte d’administration. Longtemps générique (root ou administrator), il est désormais attaché à des individus pour assurer une bonne traçabilité des opérations. Il est aussi distinct du compte personnel pour éviter les mauvaises manipulations et limiter les dégâts d’une compromission.
Le référentiel des identités et l’annuaire de comptes diffèrent aussi sur leur principe. Le premier a pour rôle de modéliser la réalité d’une organisation. Le second est un service support aux systèmes et applications qui se doit de présenter les informations pour qu’elles soient exploitables directement.
En corollaire, un annuaire de comptes n’est pas adapté pour représenter le référentiel des identités. L’annuaire suit la norme LDAP pour authentifier des comptes et offrir une image globalisée de l’identité se trouvant derrière. Mais il n’est pas équipé techniquement pour modéliser les objets et leurs relations. La norme LDAP se sait en effet pas réellement gérer les liens, ni au niveau modélisation, ni dans les requêtes.
D’ailleurs ceux qui ont tenté de gérer des identités dans un annuaire (par exemple un Active Directory) sont conscients des difficultés rencontrées, ce serait-ce que pour faire le lien entre les différents comptes d’une même personne.
Le référentiel et l’annuaire sont en revanche complémentaires. Le rôle principal du premier est d’alimenter le second, que ce soit un Active Directory, un annuaire de sécurité LDAP, un annuaire de plateforme cloud comme Azure AD ou un service spécialisé comme Okta ou Auth0.
Lors de cette opération d’alimentation, on procède au doublement des différents comptes d’une même identité et on dénormalise le modèle de données pour présenter l’ensemble des informations pertinentes au sein du compte. Ainsi par exemple, le nom du service, qui est attaché à l’objet correspondant dans le référentiel, se retrouve comme attribut du compte dans l’annuaire.
Les identités dans le cloud ?
Les applications suivent un mouvement inexorable vers le cloud. Mais les réticences sont encore nombreuses pour externaliser les briques d’infrastructure dont fait partie le référentiel.
Et c’est vrai que pour l’instant, il existe encore une forte adhérence entre le système d’information et le logiciel de gestion des identités, au travers de connecteurs, synchronisations, exports, etc. Et il est aussi vrai que l’offre de service de gestion des identités dans le cloud est encore pauvre alors même que celle en gestion des accès est en pointe. Les éditeurs majeurs de l’IAM sont toutefois tous en train de préparer une offre SaaS digne de ce nom. Il est probable que comme pour la messagerie, on en passera par une phase hybride afin de gérer – temporairement – le patrimoine applicatif existant.
De nouvelles relations avec les applications
On a parlé en préambule de changement de paradigme. Pourtant tout ce qui a été évoqué ici n’a rien de révolutionnaire. C’est que le bouleversement commence avec la relation avec les applications, ce qui sera le thème de la seconde partie de cette trilogie.
Auteur : Marc (Directeur technique)
Related Posts
