Répondre aux Besoins de Stockage de la Gestion Moderne des Identités
« Nous ne savions absolument pas que cette infrastructure deviendrait internationale et publique ». – Vinton Cerf
Alors que l'Internet s'est développé pour héberger des milliards d'identités, le besoin de gérer systématiquement ces identités est devenu une problématique. Sans une manière organisée de stocker les données d'identité, une gestion moderne des identités et des accès serait impossible et l'accès aux ressources digitales un vrai chaos.
Les services d'annuaire qui nous ont servi dans le passé, ne nous permettront toutefois pas d'aller de l'avant. Actuellement, les services d'annuaire prenant la forme de Serveurs LDAP ou les méta-annuaires basés sur RMDBS constituent les répertoires principalement utilisés. (Je pourrais également parler des Annuaires virtuels / proxys LDAP, mais il s'agit de cas d'usage spéciaux.) Mais l'organisation des données d'identité a connu de nombreux changements au cours des quinze dernières années, en particulier concernant le caractère évolutif et le type d'identités ; aussi devons-nous revoir notre manière de les gérer au mieux au sein des annuaires.
Pour l'essentiel, nous devons prendre conscience du fait que lorsqu'il s'agit de gestion des accès et des identités client (CIAM), les services d'annuaire de l'entreprise ne sont pas forcément les plus adaptés aux cas d'usage n'impliquant pas les collaborateurs. Nous devons donc prévoir en fonction de cela.
Annuaires et services liés
Avant d'aborder le cœur de notre sujet, prenons un instant pour voir comment nous en sommes arrivés là.
Au tout début de la gestion des identités utiliser un annuaire professionnel tel que Microsoft Active Directory constituait la norme. Ce système était utilisé non seulement pour stocker des identités, mais aussi à des fins d'authentification et d'autorisation pour divers systèmes connectés. Le but était de connecter autant de systèmes que possible à cet annuaire, en ayant des branches distinctes pour les identités de ceux qui n'étaient pas collaborateurs, notamment les fournisseurs, les clients et les partenaires. Il était essentiellement utilisé pour créer un seul silo d'informations sur l'identité ou, si vous voulez, un magasin d'identité.
Cela a assez bien fonctionné du moment que le cas d'usage de l'annuaire était bien spécifié, et les administrateurs n'avaient pas grand chose à faire à part réaliser des sauvegardes et assurer des activités de réglage.
Mais au cours des dernières années, la gestion du magasin d'identités est devenue bien plus complexe. Le nombre d'identités non professionnelles stockées dans l'annuaire, en particulier les identités des clients, explose car de nouvelles applis sont créées, les acquisitions des entreprises amènent des annuaires supplémentaires et les utilisateurs s'engagent avec les marques par le biais d'un nombre croissant de canaux. Il en résulte un exemple d'annuaire qui est gonflé et profond, ce qui le rend moins performant.
Les méta-annuaires sont excellents pour agir en qualité de backend pour le provisioning de l'utilisateur et pour les campagnes de demande de conformité, mais ils ne fonctionnent pas vraiment avec les cas d'usage impliquant de gros volumes comme c'est le cas pour l'authentification et l'autorisation dans la gestion des accès et des identités client (CIAM). Les anciens annuaires n'ont pas été conçus pour des pics d'utilisation et ils luttent avec la flexibilité des attributs qui est nécessaire dans les environnements où les profils des clients sont complexes. De plus, ils n'offrent pas les caractéristiques de sécurité clés qui sont nécessaires pour protéger les données des consommateurs, notamment les journaux inviolables, les alertes administrateurs et les limitations d'accès aux données par les administrateurs.
Si l'on pousse un peu la question, il existe également un besoin croissant de gérer ces identités en termes de confidentialité et de contrôles de gouvernance. Quel que soit le type d'identité suivi, de nombreuses lois régissent la gestion de ces entrées. Souvenez-vous quand j'ai parlé tout à l'heure du fait que les administrateurs devaient seulement veiller à ce que l'annuaire soit bien réglé et sauvegardé. Cela n'est pas vraiment possible lorsqu'il faut résoudre en permanence les problèmes d'annuaires, comme la surveillance des performances, la modification des réglages du chiffrement des attributs, le droit à l'oubli et la connexion à un éventail croissant de systèmes sur site et basés sur le cloud.
Comment faire évoluer l'infrastructure de notre annuaire ?
Au vu de cette évolution, c'est le moment d'envisager une nouvelle architecture pour stocker et conserver les données d'identité d'une organisation. Au tout début de la gestion des identités, les services d'annuaires consistaient à localiser les personnes et les systèmes dans un seul réseau. Aujourd'hui, nous devons cependant développer cette infrastructure pour tenter d'obtenir un modèle comme celui-ci :
Nous devons commencer à inverser la tendance consistant à conserver toutes nos identités (clients, partenaires, employés, etc.) dans un seul répertoire. Les identités n'ont plus la même dimension qu'avant, et cela n'a plus de sens de tout conserver dans un seul conteneur.
Soyons clair, je ne parle pas de séparer les données d'identité des individus ; les profils unifiés sont essentiels pour fournir une expérience utilisateur fluide. Il est fondamental d'unifier la couche de données pour conserver une source unique de confiance concernant les identités, les attributs et les préférences de vos clients, qui soit accessible par toutes les applications. Mais votre ensemble de données sur les identités clients est très différent des ensembles de données d'identités sur vos employés, vos partenaires et autres. Les données complexes sur le profil des clients incluent des données non structurées, et le CIAM a des exigences en termes de sécurité et de caractère évolutif qui vont au-delà de celles de l'IAM.
Personnellement, je pense que la déconstruction du silo unique actuel en deux répertoires distincts de CIAM et d'IAM pour les collaborateurs présente les avantages suivants :
- Réactivité. Lorsque nous utilisons des magasins d'identité distincts, des applications connectées incluent moins d'entrées parmi lesquelles chercher, ce qui accroît la réactivité. Cela offre également l'option de dédier des ressources pour lutter contre la charge des applications sur les cas d'usage individuels (par ex. collaborateurs et CIAM) contrairement à la solution combinée. Je pense que nous pouvons avancer en toute sécurité que l'utilisation du CIAM nécessitera une configuration différente et de nombreuses ressources que nous trouvons dans les applications des entreprises.
- Une ségrégation basée sur la sécurité. Les annuaires d'entreprise sont le tout premier gateway vers le réseau. Lorsque nous séparons le service, il n'y a aucun risque de mélanger les identités qui sont de l'entreprise et celles qui ne le sont pas. Chaque entrée de client au sein de l'annuaire de l'entreprise est un autre vecteur de faille potentiel. Ceci s'applique également au service d'annuaire ne concernant pas l'entreprise, dans lequel chaque utilisateur professionnel ayant un accès constitue une fuite potentielle de données.
- Une meilleure organisation des données. Ces services doivent être aussi larges et profonds que les cas d'usage l'exigent. Mais personne n'aime avoir un annuaire trop large et trop profond. Ils sont difficiles à gérer et à administrer, c'est pourquoi le fait de distinguer les magasins d'identité nous aide à obtenir une arborescence de l'annuaire (DIT) simplifiée.
Lorsque nous réfléchissons à ce qu'il faut faire des divers types d'identités que les magasins informatiques gèrent actuellement, il est plus important que jamais de réfléchir à la manière donc ces identités sont gérées dans les infrastructures modernes. Nous devons faire évoluer notre réflexion sur la manière dont ces données sont stockées dans divers cas d'usage. Le fait de créer des annuaires de données organisés pour prévoir des accès dans les bonnes circonstances est fondamental pour satisfaire les besoins spécifiques aux cas d'usage, à la conformité et au fonctionnement. Il est plus important que jamais de réfléchir à la manière dont nous segmentons et stockons ces données, en particulier pour ce qui est du CIAM.
Pour en savoir plus sur les exigences spécifiques au CIAM, lire notre Guide complet sur l'IAM destinée au clients.