Risque identité cross-stack sous contrôle
Pilotage du cycle de vie PAM sur CyberArk
Découvrez notre mission et nos valeurs
Notre impact sociétal et environnemental
Rejoignez-nous
Nos alliances stratégiques
Toutes nos actualités
Nos prochains rendez-vous
Découvrez nos success stories
La plupart des organisations qui gèrent CyberArk Idira ont déjà mis en place des automatisations : scripts internes, tâches planifiées, intégrations maison bâties au fil des besoins. Ces scripts fonctionnent, mais ils vieillissent mal. Fragiles, peu documentés, souvent compris par une seule personne, ils rendent l’onboarding et l’offboarding des comptes à privilèges difficiles à auditer et à faire évoluer.
Or, à mesure que le périmètre CyberArk grandit, ce sont justement ces flux d’entrée et de sortie de comptes qui déterminent la qualité de la gouvernance dans la durée. Un onboarding mal maîtrisé, c’est autant de comptes mal renseignés, de coffres créés hors convention, ou d’accès qui traînent après un offboarding incomplet.
La logique métier d’un onboarding ; quel coffre créer, quels groupes AD associer, quelles permissions accorder ; se retrouve souvent enfouie dans des centaines de lignes de code, sans documentation ni possibilité de revue simple. Chaque évolution (nouvelle convention de nommage, nouveau type de compte, nouvelle règle de conformité) demande une intervention technique, avec le risque de régression que cela implique.
Cette approche artisanale devient un frein dès que le volume de comptes ou la fréquence des demandes augmentent, et complique toute démarche d’audit ou de conformité réglementaire sur le périmètre PAM.
Ignimission Protec remplace ces scripts par des workflows configurables sans code, appelés boarding orders. Un même mécanisme couvre l’onboarding, l’offboarding et la remédiation : seule la logique du workflow change, la structure reste identique.
Une demande peut arriver de plusieurs façons, formulaire self-service, import Excel, ou API, par exemple depuis une RITM ServiceNow ou une instruction Terraform ou Ansible. Chaque ligne de la demande déclenche un workflow : pour onboarder 100 comptes Windows, il suffit de soumettre 100 lignes rattachées au workflow d’onboarding correspondant.
L’utilisateur qui soumet la demande n’a besoin de connaître ni les noms de coffres, ni les identifiants de plateforme CyberArk : il renseigne seulement quelques attributs métier, environnement, application, région, technologie et Protec traduit ces informations en actions techniques conformes à la convention de nommage définie par l’organisation. Sur un cas d’onboarding role-based access control, quatre attributs suffisent pour déclencher automatiquement une quinzaine d’actions : création du coffre selon la convention de nommage, création des groupes AD associés à chaque rôle, configuration des accès en tant que safe member.
Chaque workflow se configure dans le workflow builder de Protec, un système de glisser-déposer permettant d’enchaîner des actions : intégrations, appels API, conditions logiques. Les attributs demandés à l’utilisateur peuvent être des listes statiques, des listes dynamiques alimentées par une source externe (une CMDB pour récupérer une liste d’applications, par exemple), ou de simples champs texte.
Le workflow se décompose en scénarios : à chaque étape correspond une ou plusieurs actions, comme la création de coffre, de compte, de groupe AD, ou leur suppression. Des conditions peuvent aussi être ajoutées, par exemple, récupérer les utilisateurs via une requête LDAP, puis orienter le workflow selon le résultat : notifier un administrateur en cas d’anomalie, ou intégrer directement l’utilisateur dans CyberArk et le notifier une fois son compte créé dans le vault.
Pour les connecteurs non couverts nativement, Protec propose un Integration Builder, un outil proche d’un client API (type Postman) permettant de construire des requêtes vers n’importe quel endpoint accessible via API : SailPoint, Ansible, ServiceNow, Jira, ou toute autre source du système d’information ainsi que des requêtes Active Directory (LDAP). Une fois construites, ces intégrations s’utilisent directement dans le workflow builder, au même titre que les actions standards.
Les boarding orders sont eux-mêmes accessibles par API, ce qui permet d’intégrer Protec dans les processus ITSM ou IGA déjà en place, plutôt que de créer un outil isolé de plus. Un workflow peut être déclenché directement sur la cible (statut « ready for boarding »), ou passer par une étape d’approbation (statut « waiting for approval ») pour qu’un responsable valide la demande avant exécution, utile pour les onboardings ou offboardings soumis à un contrôle préalable.
Un onboarding et un offboarding fiables, tracés et conformes à une convention de nommage commune conditionnent la qualité des données que verra ensuite la discovery, et la capacité à répondre à un audit sans reconstruction manuelle.
Mais la vraie valeur est ailleurs : chaque onboarding automatisé, c’est du temps en moins sur une tâche répétitive, et du temps en plus pour les équipes sécurité sur des sujets qui demandent une vraie expertise.
C’est le rôle de la brique On/Off-boarding d’Ignimission Protec : des workflows no-code, auditables, connectés à votre SI, qui tournent en continu sans dépendre d’un script ou d’une personne clé.
Demandez une démo d’Ignimission Protec pour voir un workflow d’onboarding s’exécuter en direct sur votre propre périmètre.