Security Directory Integrator : l’outil IBM discret qui garde vos identités cohérentes et plus sûres

Le Security Directory Integrator, souvent appelé SDI ou encore IBM Security Verify Directory Integrator en version 10, reste un peu le secret bien gardé des équipes IAM dans les grandes organisations. Ce n’est pas un annuaire en soi. Ce n’est pas non plus une solution cloud flashy. C’est un moteur de synchronisation et de transformation de données, particulièrement taillé pour les identités, et il fait un boulot de dingue quand on veut éviter que les comptes utilisateurs se dispersent dans tous les sens entre Active Directory, LDAP legacy, bases de données RH et applications métier.

Et franchement, dans un contexte cybersécurité, c’est exactement le genre d’outil qui mérite qu’on s’y arrête. Parce que les incohérences d’identité, les comptes orphelins et les provisioning faits à la main restent encore aujourd’hui des portes d’entrée classiques pour les attaquants.

D’où vient-il et qu’est-ce qu’il fait vraiment ?

À l’origine, c’était Tivoli Directory Integrator, un composant de la gamme Tivoli d’IBM. Il a ensuite migré dans la branche Security parce que son usage principal s’est retrouvé du côté de la gestion d’identités et de la gouvernance. Aujourd’hui, on le trouve sous le nom IBM Security Verify Directory Integrator (version 10), et il continue de tourner dans pas mal d’environnements enterprise qui ont besoin de faire circuler des données d’identité de façon fiable entre systèmes hétérogènes.

Le principe est simple : il lit des données quelque part, les transforme selon des règles que vous définissez, et les pousse ailleurs. En temps réel ou par batch, peu importe. Ce qui compte, c’est qu’il le fait de manière traçable, scriptable et relativement robuste.

Comment ça marche sous le capot ?

Le cœur du système, ce sont les AssemblyLines. Imaginez un pipeline de données : vous définissez une série d’étapes qui vont chercher des entrées (users, groupes, attributs), les mapper, les enrichir, les filtrer, et les écrire dans une ou plusieurs destinations. Chaque AssemblyLine peut être déboguée pas à pas, ce qui change tout quand on debugge une synchro un peu tordue un vendredi soir.

Les Connecteurs sont les pièces qui parlent aux systèmes extérieurs. Il y en a des prêts à l’emploi pour LDAP, JDBC (donc presque toutes les bases de données), fichiers plats, HTTP, Active Directory, et plein d’autres. Vous choisissez le mode : Iterator pour lire, AddOnly pour créer, Update pour modifier ou créer si besoin, Delete, etc. Et si le connecteur standard ne suffit pas, vous pouvez en écrire un custom en JavaScript… avec la possibilité d’appeler directement des classes Java. C’est ce mélange JS + Java qui donne toute sa puissance au truc : vous restez dans un langage accessible tout en ayant accès à la puissance de l’écosystème Java quand il faut.

Les configurations sensibles peuvent être stockées dans des fichiers de propriétés chiffrés. Ce n’est pas parfait, mais c’est déjà mieux que de laisser des mots de passe en clair dans des scripts.

Pourquoi ça intéresse la cybersécurité

Parce que la plupart des incidents graves impliquent, à un moment ou à un autre, une identité mal gérée. Un compte qui n’a pas été désactivé après un départ, un droit qui traîne sur un ancien système, une incohérence entre l’annuaire RH et l’Active Directory qui permet à quelqu’un d’accéder à des ressources qu’il ne devrait plus voir.

Le Security Directory Integrator permet d’automatiser le cycle de vie des identités (joiner-mover-leaver) de façon centralisée. Au lieu d’avoir cinq équipes qui font du provisioning manuel dans cinq outils différents, vous avez un point de contrôle unique qui pousse les changements là où il faut, quand il faut. Résultat : moins d’erreurs humaines, moins de comptes fantômes, et une surface d’attaque un peu plus propre.

Il s’intègre particulièrement bien avec les solutions IBM Verify Identity Governance. Beaucoup d’équipes l’utilisent pour alimenter ces outils en données propres et à jour, ou pour créer des adaptateurs qui parlent à des systèmes legacy que les solutions modernes ne gèrent pas nativement.

Et dans les environnements hybrides ou avec beaucoup de legacy, c’est souvent la solution la plus pragmatique pour éviter de tout réécrire.

Quelques cas d’usage concrets qu’on voit sur le terrain

Une entreprise veut synchroniser son Active Directory avec un annuaire LDAP utilisé par une application critique vieille de quinze ans. Au lieu de développer un batch maison fragile, elle monte une AssemblyLine qui lit les users modifiés depuis la dernière synchro (mode delta) et les pousse dans le LDAP cible. Résultat : les droits sont cohérents des deux côtés sans intervention manuelle.

Autre exemple classique : pendant un projet de migration vers le cloud ou vers une nouvelle solution IAM, on doit faire migrer des milliers de comptes avec leurs attributs, leurs appartenances aux groupes, et leurs historiques. SDI gère les transformations de schémas, les mappings complexes et les scripts de nettoyage sans qu’on ait à tout coder from scratch.

On l’utilise aussi pour alimenter des bases de profils (type HCL Connections) ou pour faire des exports/imports réguliers vers des outils de gouvernance et de conformité.

La version 10, ce qui a changé

La version 10 (IBM Security Verify Directory Integrator) est essentiellement une containerisation de la base 7.2, avec des mises à jour de plateforme : Java 17, Eclipse plus récent, support élargi dont macOS, et une installation simplifiée. La logique et les AssemblyLines restent très proches de ce qu’on connaissait sur 7.2, ce qui explique pourquoi la documentation et les tutoriels des versions précédentes restent largement utilisables.

La communauté (tdi-users.org notamment) le confirme : la v10 est la version actuelle, mais les exemples et les vidéos des 7.x continuent de servir. C’est rassurant pour les équipes qui ont déjà des AssemblyLines en production.

Par où commencer si vous voulez regarder de plus près

La documentation officielle IBM reste la référence. Pour les mains dans le cambouis, le site tdi-users.org est une mine : guides de démarrage, playlists YouTube, et une communauté (Discord inclus) qui reste active même si le produit n’est pas le plus hype du moment. Eddie Hartman, qui a longtemps porté le produit, continue de partager du contenu très concret.

Côté formation, il existe des parcours en ligne et des certifications IBM SDI si vous voulez monter en compétence de façon structurée. Mais beaucoup d’équipes apprennent en faisant : on monte une petite AssemblyLine de test en quelques heures, et on itère.

Quelques points de vigilance quand même

Comme tout outil qui touche aux identités, il faut le maintenir à jour. Des vulnérabilités ont été publiées ces dernières années (erreurs techniques qui pouvaient exposer des infos sensibles, par exemple). Rien d’inhabituel, mais ça rappelle qu’on ne laisse pas un composant IAM tourner sans correctifs.

Il demande aussi un certain niveau de compétence : comprendre les annuaires, savoir mapper des attributs, debugger des flux de données. Ce n’est pas un outil no-code pour tout le monde. Et il s’intègre dans une stratégie plus large : il ne remplace pas une gouvernance d’identité solide ni une approche Zero Trust, il en est un des rouages techniques.

Au bout du compte, le Security Directory Integrator n’est peut-être pas l’outil le plus visible ni le plus vendu ces dernières années. Mais dans pas mal d’organisations qui ont un patrimoine applicatif hétérogène et qui veulent garder un vrai contrôle sur leurs identités, il reste une solution éprouvée, flexible et étonnamment puissante. Et en cybersécurité, c’est souvent ce genre de pièce discrète qui fait la différence entre un environnement à peu près maîtrisé et un environnement où les identités partent un peu dans tous les sens.