Ariovis
Conseil d'expert — RUN Netwrix Identity Manager

Une automatisation IAM doit aussi savoir s'arrêter

Seuils de sécurité, simulation, restauration et déploiements contrôlés dans le RUN de Netwrix Identity Manager. Retour d'expérience d'un architecte et responsable de RUN IAM senior Ariovis, à partir d'un incident majeur anonymisé et de plusieurs situations récurrentes rencontrées sur des plateformes en local comme en SaaS.

L'incident qui structure notre pratique du RUN

Nous exploitons Netwrix Identity Manager — anciennement Usercube — dans des environnements complexes. Les plateformes IGA que nous accompagnons alimentent Active Directory, Microsoft Entra ID, Exchange, ServiceNow, SAP S/4HANA, des SIRH, des applications métier, des scripts PowerShell, des batchs et des bases SQL, à travers plusieurs agents et des pipelines Azure DevOps ou équivalents. Elles calculent, provisionnent, réconcilient et supprimment des dizaines de milliers d'objets par jour. Une IGA n'est plus un outil administratif à côté du système d'information. C'est un composant de production.

Dans une grande organisation, une évolution de configuration est préparée puis transmise par le pipeline de déploiement. La recette ne reproduit pas suffisamment les conséquences du changement en production. Un mécanisme de suppression en cascade forcée interprète un grand nombre de groupes et de rôles comme devant être supprimés. La modification est propagée vers Active Directory. Plus de 33 000 groupes doivent ensuite être restaurés en urgence. Plusieurs applications critiques sont affectées, car leurs accès reposaient directement ou indirectement sur ces groupes.

Nous ne dramatisons pas cet épisode. Nous posons calmement la question centrale : comment une modification de cette ampleur a-t-elle pu atteindre Active Directory sans qu'une étape intermédiaire mesure son impact et suspende son application ? L'objectif n'est pas de désigner un responsable. L'objectif est de comprendre quelles protections auraient dû interrompre la chaîne.

Une automatisation sûre n'est pas une automatisation qui ne se trompe jamais. C'est une automatisation dont l'erreur peut être détectée, contenue et annulée.

Ce que l'incident révèle : un traitement qui réussit trop bien

Une chaîne de déploiement peut être techniquement correcte tout en restant insuffisamment protégée. Le code passe les contrôles de syntaxe, est intégré dans la branche principale, est déployé automatiquement, démarre sans erreur et exécute correctement la logique qui lui a été confiée. La logique elle-même peut pourtant produire une conséquence métier invraisemblable. Dans le cas décrit, la suppression en cascade fonctionne, le pipeline fonctionne, le provisioning fonctionne, Active Directory applique les demandes reçues. C'est précisément le problème.

Aucun composant n'a nécessairement rencontré une erreur technique. Le résultat global est néanmoins inacceptable. Les incidents les plus difficiles ne sont pas toujours provoqués par un traitement qui échoue. Ils peuvent être provoqués par un traitement qui réussit exactement ce qu'une mauvaise configuration lui demande.

Netwrix Identity Manager distingue les décisions calculées de leur matérialisation dans les systèmes cibles. Une règle peut déterminer qu'un groupe doit être retiré, qu'un compte doit être désactivé, qu'un rôle doit être ajouté, qu'un attribut doit être modifié. Le provisioning est l'étape qui applique ensuite cette décision dans Active Directory ou dans une autre cible. Cette séparation doit être utilisée comme un garde-fou : avant d'autoriser un nouveau traitement à écrire en production, nous cherchons à le faire fonctionner dans une configuration où il peut importer les données, calculer les règles, produire les écarts, compter les opérations attendues et afficher les objets concernés, sans modifier immédiatement la cible.

Selon le contexte, cela peut être réalisé par un mode bloqué, une simulation, un job duplicatif, une copie du traitement sans étape de provisioning, une connexion technique dépourvue de droits d'écriture ou un environnement d'acceptation alimenté par des données représentatives. Nous ne donnons pas immédiatement à une nouvelle règle le droit d'agir. Nous lui demandons d'abord de nous montrer ce qu'elle compte faire.

À la suite de l'incident, un job duplicatif est mis en place. Il reprend les mêmes données, les mêmes règles, les mêmes calculs, les mêmes classifications, les mêmes sélections d'objets, mais n'exécute pas les opérations destructives dans Active Directory. Il produit avant le déploiement le nombre de groupes concernés, le nombre de rôles retirés, la liste des populations touchées, les principales variations, les suppressions attendues et les éventuels objets partagés entre plusieurs applications. Le résultat est examiné avant d'autoriser le job d'écriture. Ce dispositif n'est pas parfait : une divergence entre les deux traitements peut créer une fausse confiance. Le RUN doit donc vérifier que les étapes de calcul sont communes ou comparables et que seule l'étape d'application diffère. Une simulation utile doit reproduire la décision de production sans disposer du pouvoir de l'exécuter.

Les garde-fous que nous ancrons dans le RUN

Séparer le calcul de l'exécution est le premier garde-fou. Il ne suffit pas seul. Voici les protections complémentaires que nous ajustons au fil des incidents, dans nos RUN Netwrix Identity Manager.

  1. 01

    Des seuils de sécurité qui expriment une hypothèse métier

    Netwrix Identity Manager peut appliquer des limites sur certains traitements. Un seuil n'est pas uniquement un réglage de performance ; c'est une hypothèse de sécurité. Un traitement habituel modifie quelques dizaines de groupes, une réorganisation importante peut légitimement en modifier plusieurs centaines, une suppression de plusieurs dizaines de milliers de groupes est invraisemblable dans le contexte courant. Le seuil peut bloquer l'exécution, forcer une validation, déclencher une alerte, demander une analyse complémentaire. Aucune valeur universelle n'existe : elle dépend du nombre d'identités, du nombre de groupes, de la fréquence des réorganisations, des traitements RH massifs, des pics connus, de la capacité de restauration et du risque lié à une exécution partielle. Un seuil n'exprime pas le volume maximal que la plateforme est capable de traiter. Il exprime le volume maximal que l'organisation accepte de laisser passer sans nouvelle vérification.

  2. 02

    Un seuil peut aussi être trop bas

    Un changement RH massif concerne plus d'un millier d'utilisateurs. La limite existante empêche le traitement complet. Certaines personnes sont mises à jour, d'autres restent dans l'ancien état, les droits dépendant du département deviennent incohérents, l'équipe fractionne manuellement les opérations. Le seuil est alors relevé à 1 000 après analyse et recette. Cette augmentation n'est pas un affaiblissement automatique de la sécurité : elle est accompagnée d'une simulation, d'un contrôle des volumes, d'une validation du cas métier, d'une surveillance après exécution et d'un mécanisme capable de bloquer une opération nettement supérieure. Un garde-fou mal calibré peut empêcher une erreur, mais il peut aussi provoquer une mise à jour partielle. Le RUN doit savoir distinguer un volume important d'un volume invraisemblable.

  3. 03

    La réconciliation, pour ne pas confondre décision et réalité

    Après l'écriture, Netwrix Identity Manager peut relire les systèmes cibles et comparer l'état constaté à l'état attendu. Le fait que la plateforme ait demandé une opération ne prouve pas que celle-ci a produit exactement le résultat attendu. Nous identifions ainsi un attribut différent de la valeur calculée, un rôle absent, un groupe encore présent, un compte non autorisé, une habilitation ajoutée directement dans la cible, un provisioning non réalisé ou un état partiellement appliqué. Un départ dont le workflow est terminé peut coexister avec un compte Entra ID encore actif, une session mobile encore utilisable, des groupes encore présents et une étape Exchange non exécutée. Le provisioning raconte ce que la plateforme a demandé. La réconciliation raconte ce que le système d'information contient réellement.

  4. 04

    Éviter les rejouements destructifs

    Un traitement de départ doit parfois être relancé après un incident. Il doit distinguer une personne jamais traitée, partiellement traitée, totalement traitée, ou dont une nouvelle situation justifie un nouveau traitement. Sur un script quotidien de départ qui reprend à chaque exécution des personnes déjà traitées, nous voyons se déclencher plusieurs fois désactivations, messages d'absence, notifications et mises à jour des systèmes associés, produisant des traces en double, des états incohérents et une réelle difficulté à comprendre ce qui s'est passé. Nous corrigeons alors les critères de sélection, l'état marquant la fin du traitement, les conditions de rejeu, les tests en environnement d'acceptation et les contrôles après mise en production. Un traitement relançable doit savoir reprendre ce qui manque sans répéter ce qui est déjà terminé.

  5. 05

    Surveiller les jobs qui ne démarrent pas

    Un traitement peut ne produire aucune erreur simplement parce qu'il n'a jamais été lancé. Une synchronisation doit démarrer toutes les heures, le déclenchement automatique s'arrête, aucun nouveau job n'apparaît dans l'historique, l'exécution manuelle fonctionne normalement. Le problème se situe dans le scheduler, son serveur ou son mécanisme de verrouillage, et non dans la synchronisation elle-même. Nous vérifions alors le serveur hébergeant le scheduler, l'état du service, les fichiers de verrouillage, les redémarrages récents, l'historique des exécutions et les traitements attendus mais absents. La supervision ne doit pas uniquement alerter sur les jobs rouges. Elle doit savoir qu'un job était attendu à une heure donnée et qu'il n'existe pas. Un traitement absent ne devient jamais rouge. Il faut surveiller son rendez-vous, pas seulement son résultat.

  6. 06

    Tester les différences entre les environnements

    Une fonctionnalité peut fonctionner en DEV et en ACC, puis échouer en production. Les causes tiennent aux permissions du compte de service, aux délégations Active Directory, à un secret ou un certificat différent, à un mode d'authentification, au volume réel, à la taille de lot, à un ticket Kerberos, au serveur d'exécution, à l'accès réseau, à la configuration du scheduler, à la version du script ou de l'agent. Un traitement doit envoyer les mots de passe aux nouveaux arrivants ; il fonctionne en ACC ; en production, certains arrivants ne reçoivent rien. Deux causes indépendantes produisent le même symptôme : le compte utilisé ne dispose pas de la bonne délégation de réinitialisation, et une limite de lot exclut silencieusement une partie des arrivants. Le RUN examine toute la chaîne : la personne est-elle sélectionnée, les données existent-elles, le mot de passe est-il réinitialisé, quelle identité technique exécute l'action, possède-t-elle réellement le droit, la personne disparaît-elle du traitement en raison d'une limite, le message est-il envoyé, l'état de succès n'est-il enregistré qu'après l'envoi effectif. Une recette fonctionnelle ne couvre pas les différences de production tant que les permissions, les volumes et les composants d'exécution ne sont pas représentés.

  7. 07

    Séparer clairement les scripts, les Pull Requests et les contrôles CI/CD

    Nous distinguons les scripts utilisés en production, les scripts ponctuels, les scripts de migration, les scripts de test et les outils de diagnostic. Un script de test ou de correction ponctuelle ne doit pas pouvoir être exécuté accidentellement comme un traitement de production. Chaque changement est relié à une user story, un incident ou une demande approuvée, un auteur, une revue et une preuve de recette. Le pipeline peut vérifier la structure de la configuration, les fichiers modifiés, la présence des informations attendues, l'approbation de la Pull Request, la branche cible, les étapes de déploiement et la réussite de contrôles techniques. Nous ne prétendons jamais que le CI/CD comprend automatiquement la conséquence métier d'une règle NIM. Le pipeline vérifie que le changement respecte le processus de livraison. La simulation vérifie ce que ce changement fera aux identités et aux droits.

Aucun de ces garde-fous ne suffit seul. Un seuil ne remplace pas la recette. Une Pull Request ne prouve pas que la conséquence métier est acceptable. La sécurité vient de leur combinaison.

Sauvegarder, restaurer, revenir en arrière — y compris sur le SaaS

À la suite de l'incident, une sauvegarde est préparée avant chaque déploiement sensible et un plan de retour arrière est écrit avant, pas après. En architecture SaaS, cette discipline prend une forme particulière, parce que le client ou l'intégrateur ne maîtrise pas directement l'ensemble de l'infrastructure hébergée ni les sauvegardes de la plateforme. Cela ne signifie pas qu'aucun retour arrière n'est possible.

Ce qui doit être sauvegardé, et pourquoi ce n'est pas un seul objet
Une sauvegarde peut concerner la base Netwrix Identity Manager, la configuration, les scripts, les agents, les fichiers de paramètres, les secrets et certificats, Active Directory, ainsi que les groupes et rôles modifiés dans les systèmes cibles. Une sauvegarde de NIM ne suffit pas nécessairement à restaurer Active Directory si les suppressions y ont déjà été appliquées. Inversement, restaurer Active Directory sans réaligner NIM peut conduire la plateforme à redemander les mêmes suppressions lors du traitement suivant. Le plan de reprise précise ce qui doit être arrêté, quel composant constitue le point de restauration, dans quel ordre restaurer, comment empêcher le provisioning de recommencer, comment relire les systèmes cibles, comment traiter les événements métier survenus entre-temps et comment vérifier que la cohérence est revenue. Restaurer un annuaire sans neutraliser la décision qui l'a modifié prépare parfois la répétition du même incident.
Le retour arrière sur Netwrix Identity Manager SaaS
Lorsqu'un fichier, une synchronisation ou une action provoque une modification grave de l'état de la plateforme SaaS, nous pouvons solliciter Netwrix, en tant que partenaire, afin d'étudier une restauration de l'instance SaaS à un état antérieur à l'opération. Ce mécanisme n'est pas un bouton disponible en libre-service, toutes les actions ne sont pas toujours réversibles, aucun point de restauration n'existe nécessairement à n'importe quelle seconde, et la restauration de l'instance NIM ne restaure pas automatiquement Active Directory ou les applications cibles. Nous présentons cette possibilité comme une procédure d'exploitation coordonnée : nous identifions l'heure du fichier, du job ou du déploiement en cause, arrêtons les traitements susceptibles d'aggraver la situation, rassemblons les éléments utiles (instance concernée, heure précise, job, fichier, configuration déployée, premières conséquences observées), ouvrons et pilotons la demande auprès de Netwrix, confirmons avec l'éditeur le point de restauration disponible et son périmètre, évaluons l'impact des données créées ou modifiées après ce point, puis la restauration SaaS est réalisée par Netwrix selon la procédure convenue. Sur le SaaS Netwrix, revenir en arrière ne consiste pas à cliquer sur « Annuler ». Cela consiste à identifier le bon point de reprise, coordonner la restauration avec l'éditeur et reconstruire ensuite une cohérence avec les systèmes cibles.
Trois états à distinguer lorsque l'on revient en arrière
Un fichier RH incorrect est importé à 10 h 00. Il modifie dans NIM plusieurs structures, des rattachements hiérarchiques, des états de présence et les droits calculés pour une population. Certaines opérations ont ensuite été provisionnées. L'objectif est de revenir à la situation de 9 h 59. Trois états doivent être distingués. L'état de la plateforme NIM : les identités, relations, décisions et workflows présents dans la base SaaS ; une restauration opérée par Netwrix peut permettre de revenir à un point antérieur selon les possibilités confirmées avec l'éditeur. L'état des sources : le SIRH ou le fichier source doit être corrigé ou neutralisé, sans quoi la prochaine synchronisation peut réintroduire la même situation. L'état des systèmes cibles : Active Directory, Entra ID et les applications peuvent avoir déjà reçu certaines opérations ; restaurer NIM ne les ramène pas nécessairement à leur état précédent. Il faut donc arrêter les écritures, restaurer ou corriger les cibles, relire leur état, réconcilier et rejouer uniquement les événements légitimes. Revenir à l'état antérieur de NIM ne suffit pas si le fichier erroné reste disponible ou si les systèmes cibles ont déjà matérialisé ses conséquences.
Le rôle du partenaire dans la restauration SaaS
Ariovis n'est pas un simple intermédiaire administratif. Nous qualifions l'incident, stoppons les traitements, déterminons l'heure de référence, évaluons l'impact métier, expliquons à Netwrix ce qui doit être restauré, confirmons avec le client la perte potentielle des changements postérieurs, coordonnons les systèmes tiers, préparons la réconciliation, suivons les traitements après reprise et documentons la chronologie et les actions réalisées. Le partenaire connaît la configuration du client, ses jobs, ses sources, ses systèmes cibles, ses règles de provisioning et ses priorités métier. Netwrix maîtrise l'infrastructure SaaS et les mécanismes de restauration disponibles. L'éditeur peut restaurer l'instance ; le partenaire doit savoir quel état retrouver et comment raccorder cet état au reste du système d'information.
Le plan de retour arrière doit précéder le déploiement
Avant une évolution sensible, nous définissons quel événement déclenchera l'arrêt du déploiement, quelle volumétrie sera considérée comme anormale, quels traitements seront suspendus, quelle sauvegarde existe, quel point SaaS pourrait être demandé, qui contacte Netwrix, quelles cibles devront être restaurées séparément, quelles données produites après le point de reprise risquent d'être perdues, comment les événements légitimes seront rejoués et qui autorisera la reprise des traitements. Pour une plateforme SaaS, nous confirmons également en amont avec le partenaire et l'éditeur le périmètre de la restauration possible, la granularité temporelle disponible, les délais d'intervention, les données incluses, les éléments exclus et les informations nécessaires à l'ouverture de l'incident. Un rollback qui n'existe que dans l'esprit de l'équipe projet n'est pas encore un plan de reprise.
Déployer en soirée ne suffit pas
Les déploiements sensibles sont planifiés en soirée afin de réduire l'exposition des utilisateurs et de permettre une observation immédiate. Nous évitons de présenter l'horaire comme un garde-fou suffisant. Une soirée permet de réduire l'activité simultanée, de disposer d'une équipe concentrée sur le changement, de conserver du temps pour restaurer et de contrôler les premiers traitements avant la reprise. Elle ne remplace pas la simulation, les seuils, la sauvegarde, le contrôle d'impact, le plan de retour arrière, la présence des personnes habilitées à décider et la possibilité réelle de contacter l'éditeur. La soirée donne du temps pour réagir. Elle n'empêche pas une mauvaise décision d'être exécutée.
Les contrôles après déploiement
Le déploiement n'est pas terminé lorsque le pipeline devient vert. Nous exécutons un contrôle de santé portant sur le nombre d'objets ajoutés, modifiés et supprimés, les groupes AD affectés, les erreurs et avertissements, les jobs attendus, les opérations bloquées par les seuils, les écarts entre NIM et les cibles, les principales populations, les arrivées et départs du jour, les applications critiques, les scripts planifiés, le scheduler, les comptes de service et la fraîcheur des sources. Le contrôle inclut quelques scénarios fonctionnels précis : un arrivant représentatif, un départ, une mobilité, une réintégration, un utilisateur possédant plusieurs postes, un externe avec date de fin, un droit applicatif critique. Le pipeline confirme que le déploiement s'est exécuté. Le contrôle de santé confirme que le service IAM produit encore les bonnes décisions.
Architecture locale et architecture SaaS : mêmes principes, responsabilités différentes
En local, le client maîtrise directement le serveur, la base, les agents, les sauvegardes, les scripts, l'ordonnancement et les procédures de restauration ; il doit être capable de restaurer ces éléments dans le bon ordre. En SaaS, Netwrix maîtrise l'infrastructure hébergée et les mécanismes de sauvegarde de l'instance ; le client et Ariovis maîtrisent les agents locaux, les fichiers, les sources, les configurations exportées, les scripts, les cibles, le pipeline et la chronologie de l'incident, et coordonnent avec Netwrix une éventuelle restauration de l'instance à un point antérieur. Dans les deux cas, la restauration de NIM doit être suivie d'une réconciliation avec Active Directory, Entra ID et les applications. La différence entre local et SaaS modifie celui qui exécute la restauration. Elle ne supprime pas le besoin de comprendre ce qui doit être restauré et ce qui doit être réconcilié.

Ce que nos clients reconnaissent, et notre position

Un responsable IAM ou un responsable de production qui exploite Netwrix Identity Manager reconnaît souvent au moins plusieurs de ces situations : un fichier RH a été traité mais contenait une donnée incorrecte ; une règle a produit beaucoup plus de changements que prévu ; un job ne s'est jamais déclenché ; un départ a été rejoué ; une opération n'a fonctionné qu'en ACC ; un compte de service n'avait pas la bonne délégation en PROD ; une limite de lot a silencieusement exclu des personnes ; une synchronisation a réussi mais la cible est restée différente ; une modification directe dans l'AD a créé un écart ; une restauration de NIM risque de provoquer un nouveau provisioning ; personne n'avait défini à l'avance comment demander un retour arrière SaaS ; la sauvegarde existe mais la procédure complète n'a jamais été testée.

Ces situations ne signifient pas nécessairement que la plateforme est mal conçue. Elles montrent qu'une IGA devient un composant de production à part entière et qu'elle nécessite des pratiques d'exploitation proportionnées à son pouvoir d'action. Nous mettons en valeur avec précision les capacités natives de Netwrix Identity Manager — calcul des droits attendus, distinction entre synchronisation et provisioning, jobs configurables, états de workflow, limites de volumétrie, historique des traitements, visibilité sur les erreurs, corrélation, classification des ressources, réconciliation des propriétés et des rôles, vérification de l'approvisionnement, identification des comptes non autorisés, comparaison entre état théorique et état constaté — et nous complétons ces capacités par des environnements séparés, des simulations, des jobs sans écriture, des seuils adaptés, des sauvegardes, des procédures de restauration, des Pull Requests, des contrôles CI/CD, une recette représentative, des plans de retour arrière, des contrôles après déploiement et une supervision portant également sur les traitements qui ne se sont jamais déclenchés.

Nous ne cherchons pas à ralentir chaque évolution par un processus excessif. Tous les changements ne nécessitent pas une restauration préparée avec l'éditeur, un déploiement en soirée, une simulation complète ou une validation de crise. Le niveau de contrôle dépend du caractère destructif du changement, du nombre d'objets concernés, de la criticité des applications, de la réversibilité, de la qualité de la recette, de la capacité de restauration et de l'exposition des utilisateurs. Une modification d'un template d'e-mail n'est pas traitée comme une nouvelle règle de suppression de groupes. Nous ne sécurisons pas tous les changements de la même manière. Nous renforçons le contrôle lorsque l'automatisation reçoit le pouvoir de modifier beaucoup d'objets ou de supprimer des accès.

Ce que nous retenons

Dans l'incident initial, la plateforme avait reçu une configuration lui demandant de supprimer un très grand nombre de groupes. Le provisioning a appliqué cette décision. Le RUN a ensuite restauré les objets et renforcé la chaîne : sauvegarde avant déploiement, job duplicatif, calcul sans écriture, contrôle des volumes, seuils adaptés, recette améliorée, déploiement en soirée, contrôle de santé, plan de retour arrière. Dans un environnement SaaS, nous pouvons également coordonner avec Netwrix une restauration de l'instance à un état antérieur au fichier ou à l'action en cause, sous réserve du point de reprise disponible et du périmètre confirmé avec l'éditeur. Cette restauration n'est qu'une étape. Il faut ensuite neutraliser la cause, réconcilier les systèmes cibles, rejouer les événements légitimes, vérifier les décisions et reprendre progressivement les traitements.

Une plateforme IGA ne devient pas sûre parce qu'elle automatise correctement les changements. Elle devient exploitable lorsque nous pouvons voir ce qu'elle va faire, l'empêcher d'aller trop loin et revenir à un état maîtrisé lorsque la réalité ne correspond pas à la décision attendue.