> ## Documentation Index
> Fetch the complete documentation index at: https://docs.wirespeed.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Idira (anciennement CyberArk)

> Ingérez les événements d’audit et synchronisez les utilisateurs depuis Idira (anciennement CyberArk) Privilege Cloud et Identity

## Présentation

Wirespeed se connecte à CyberArk Identity Security Platform Shared Services (ISPSS) pour :

* **Synchroniser les utilisateurs** depuis CyberArk Privilege Cloud (comptes du coffre) et depuis CyberArk Identity (utilisateurs de l’annuaire fédéré).
* **Ingérer les événements d’audit** des services PAM (Privilege Cloud), IDP (Identity) et ADM (Admin) sous forme de journaux ; Wirespeed y exécute ses détections gérées (échecs MFA, échecs de connexion au coffre, accès non autorisés aux safes et aux mots de passe).
* **Appliquer des remédiations aux utilisateurs** via Privilege Cloud (désactivation / activation / fin des sessions PSM) et Identity Administration (verrouillage / déverrouillage / fin des sessions SSO), avec un routage automatique selon la population d’origine de l’utilisateur.

> [!WARNING]
>
> Cette intégration est en **bêta**. Les actions de remédiation sont implémentées, mais désactivées jusqu’à ce que l’intégration passe en disponibilité générale (GA).

## Prérequis

Vous aurez besoin des éléments suivants :

* Un locataire **CyberArk Identity Security Platform Shared Services (ISPSS)** sur lequel les services Privilege Cloud, Identity et/ou Admin sont activés.
* L’autorisation de créer des applications web OAuth2 et des utilisateurs de service dans **Identity Administration**.
* L’autorisation de créer une **entrée d’intégration SIEM** dans l’espace d’administration de Privilege Cloud.

> [!NOTE]
>
> Les locataires CyberArk n’autorisent que **deux intégrations SIEM** à la fois. Wirespeed en utilise une.

## Configuration

La configuration nécessite quatre éléments dans votre locataire CyberArk :

1. Un utilisateur de service pour l’authentification.
2. Deux attributions de rôle pour cet utilisateur de service (une pour Privilege Cloud, une pour Identity Administration).
3. Une application web OAuth2 Server (utilisée uniquement pour le flux d’audit/SIEM).
4. Une entrée d’intégration SIEM pour générer une clé API.

Suivez les étapes ci-dessous dans l’ordre.

### Étape 1 — Créer l’utilisateur de service

1. Connectez-vous à **Identity Administration** en tant qu’administrateur.
2. Accédez à **Core Services → Users** et cliquez sur **Add User**.
3. Renseignez les informations de l’utilisateur. Choisissez un nom d’utilisateur facile à retenir, par exemple `wirespeed-svc@<your-tenant>`. Le suffixe `@<your-tenant>` est ajouté automatiquement.
4. Sous **Status**, cochez :
   * **Is Service User**
   * **Is OAuth confidential client**
   * **Password never expires**
5. Cliquez sur **Create User**. Notez le nom d’utilisateur et le mot de passe : vous en aurez besoin plus tard.

### Étape 2 — Attribuer des rôles à l’utilisateur de service

L’utilisateur de service a besoin de deux attributions de rôle : l’une pour gérer les opérations sur l’annuaire Identity, l’autre pour accéder aux API Privilege Cloud.

#### 2a. Rôle Identity Administration

1. Accédez à **Core Services → Roles** et cliquez sur **Add Role**.
2. Donnez-lui un nom (par exemple `Wirespeed Integration`).
3. Dans l’onglet **Administrative Rights**, ajoutez :
   * **User Management** — requis pour synchroniser et verrouiller les utilisateurs de l’annuaire Identity.
   * **Report Management** — requis pour la requête Redrock qui récupère les utilisateurs de l’annuaire fédéré (`DsUsers`).
4. Dans l’onglet **Members**, ajoutez l’utilisateur de service.
5. Cliquez sur **Save**.

#### 2b. Rôle d’administrateur Privilege Cloud

1. Dans Identity Administration, recherchez le rôle intégré **Privilege Cloud Administrators** (ou tout rôle accordant des droits équivalents — consultez la [documentation des rôles Privilege Cloud](https://docs.cyberark.com/identity-administration/latest/en/content/coreservices/getstarted/ispss-user-roles.htm) de CyberArk).
2. Dans l’onglet **Members**, ajoutez l’utilisateur de service.
3. Cliquez sur **Save**.

> [!WARNING]
>
> L’attribution du rôle Privilege Cloud est **obligatoire** pour que l’intégration puisse appeler les API PasswordVault. Sans elle, le jeton de plateforme généré par Wirespeed sera rejeté avec une erreur 401 par les points de terminaison PasswordVault.

### Étape 3 — Créer l’application web OAuth2 d’audit (modèle Server)

Cette application sert uniquement à la SIEM Audit API. Tous les autres appels d’API de Wirespeed utilisent un jeton de plateforme générique, qui ne nécessite pas d’application web personnalisée.

1. Accédez à **Apps & Widgets → Web Apps** et cliquez sur **Add Web Apps**.
2. Dans l’onglet **Custom**, recherchez **OAuth2 Server**, cliquez sur **Add** et confirmez.
3. Dans l’onglet **Settings**, définissez :
   * **Application ID** : `WirespeedAudit` (ou tout identifiant compatible avec une URL — notez-le pour plus tard).
   * **Application Name** : `Wirespeed Audit`.
4. Dans l’onglet **General Usage**, définissez **Client ID Type** sur **Confidential**.
5. Dans l’onglet **Tokens**, définissez :
   * **Token Type** : **JwtRS256**.
   * **Auth Methods** : activez **Client Creds**.
   * **Token Lifetime** : au moins 15 minutes.
6. Dans l’onglet **Scope**, cliquez sur **Add** et créez un scope :
   * **Name** : `isp.audit.events:read`
7. Dans l’onglet **Advanced**, collez ce script, puis cliquez sur **Save** :
   ```js theme={null}
   setClaim('tenant_id', TenantData.Get("CybrTenantID"));
   setClaim('aud', 'cyberark.isp.audit');
   ```
8. Dans l’onglet **Permissions**, ajoutez l’utilisateur de service de l’étape 1 avec les autorisations **Run**, **View**, **Grant** et **Automatically Deploy**.
9. Cliquez sur **Save** en haut de la page.

### Étape 4 — Créer l’entrée d’intégration SIEM

1. Basculez vers l’espace **Administration** (le portail d’administration au niveau du locataire).
2. Accédez à **My environment → Integrations → Export to SIEM**.
3. Cliquez sur **Create → Create SIEM integration**.
4. Donnez-lui un nom (par exemple `Wirespeed`) et cliquez sur **Apply**.
5. Notez la **clé API** générée : elle n’est affichée qu’une seule fois. La page affiche également une **API base URL** ; en général, vous n’avez pas besoin de la copier (Wirespeed la déduit du jeton de plateforme), mais gardez-la à portée de main au cas où la déduction automatique ne fonctionnerait pas pour votre locataire.

### Étape 5 — Connecter Wirespeed

1. Dans Wirespeed, accédez à **Intégrations → Ajouter une intégration → Idira (anciennement CyberArk)**.

2. Prenez connaissance de l’avertissement relatif à la bêta.

3. Fournissez :

   | Champ | Valeur |
   | - | - |
   | **URL Identity** | L’URL d’administration Identity, par exemple `https://aab1234.id.cyberark.cloud` (copiez-la depuis la barre d’adresse du portail d’administration Identity). |
   | **ID de l’application OAuth2 Server d’audit** | L’Application ID de l’étape 3 (par exemple `WirespeedAudit`). |
   | **Identifiant de l’utilisateur de service** | L’identifiant complet de l’étape 1, y compris le suffixe du locataire (par exemple `wirespeed-svc@aab1234`). |
   | **Mot de passe de l’utilisateur de service** | Le mot de passe de l’étape 1. |
   | **Clé API SIEM** | La clé API de l’étape 4. |

4. Cliquez sur **Ajouter**. Wirespeed génère un jeton de plateforme, en déduit votre sous-domaine Privilege Cloud et lance la première synchronisation de l’audit et des utilisateurs.

> [!NOTE]
>
> Le **sous-domaine Privilege Cloud** est déduit automatiquement du jeton de plateforme lors de la première connexion ; il sert à construire à la fois l’URL PasswordVault (`<sub>.privilegecloud.cyberark.cloud`) et l’URL d’audit (`<sub>.audit.cyberark.cloud`). Si votre locataire utilise une URL d’audit non standard (par exemple des hôtes partagés par région comme `eu.audit.cyberark.cloud`), définissez manuellement la valeur de remplacement **URL de base de l’API d’audit** dans les options avancées de l’intégration.

## Ce qui est ingéré

### Utilisateurs (tous les jours à 14:00 UTC, et immédiatement lors de la connexion)

Wirespeed synchronise les **deux** populations d’utilisateurs CyberArk, car il s’agit d’ensembles distincts avec des chemins de remédiation différents :

| Source | Population | Surface de remédiation |
| - | - | - |
| **PasswordVault** (préfixe `pcloud:`) | Comptes du coffre pouvant détenir des identifiants à privilèges, récupérer des mots de passe et démarrer des sessions PSM. | API PasswordVault (désactivation/activation dans le coffre, fin des sessions PSM en direct). |
| **Annuaire Identity** (préfixe `ds:`) | Utilisateurs AD/LDAP/AzureAD fédérés qui s’authentifient auprès du locataire via SSO. Ils peuvent être ou non des utilisateurs du coffre. | API Identity Administration (verrouillage/déverrouillage UserMgmt, fin des sessions SSO). |

Le `directoryId` de chaque utilisateur est préfixé par sa source (`pcloud:17`, `ds:a41ca4c8-…`) afin que les actions de remédiation sachent quelle API appeler. Une même personne peut apparaître une fois sous chaque préfixe si elle existe dans les deux populations.

Les utilisateurs de composants (CPM, PSM, ENE, etc.) sont exclus de la synchronisation PCloud : seuls les comptes humains réels et les comptes de service sont remontés.

### Journaux d’audit (toutes les minutes)

Wirespeed interroge la SIEM Audit API pour récupérer les événements de trois codes d’application :

* **PAM** — Privilege Cloud (authentification au coffre, accès aux identifiants, sessions à privilèges, rotation des identifiants, gestion des safes).
* **IDP** — Identity (authentification, MFA, déconnexion, SAML, contrôles de risque).
* **ADM** — Admin (contrôle d’accès, gestion des utilisateurs, modifications de configuration).

Lors de la première connexion, Wirespeed récupère rétroactivement les événements des **7 derniers jours** (la période de rétention du flux d’audit). Ensuite, chaque interrogation ouvre une nouvelle fenêtre temporelle `createQuery`, depuis un repère de début enregistré jusqu’à maintenant, et n’utilise `cursorRef` que pour paginer au sein de cette fenêtre.

### Détections gérées

CyberArk ne génère pas de détections propres. Wirespeed évalue les événements d’audit collectés pour :

| Détection | Condition |
| - | - |
| Verrouillage MFA CyberArk Identity | Un défi MFA Identity ou Admin échoue parce que le compte est verrouillé |
| MFA CyberArk Identity refusée | Un défi MFA Identity ou Admin échoue, reste sans réponse ou reçoit une réponse incorrecte |
| Échec de connexion au Vault CyberArk | Une authentification ou une connexion au coffre échoue (PAM00004, PAM00102-104) |
| Opération non autorisée sur un coffre CyberArk | Une opération sur un safe est refusée (PAM00017, PAM00025-026, PAM00040-047) |
| Utilisation non autorisée d’un mot de passe CyberArk | La récupération ou l’utilisation d’un mot de passe est refusée (PAM00306-307) |

Les détections du coffre ignorent les comptes de composants CyberArk (connecteur, PVWA, CPM, PSM et autres utilisateurs de service similaires). Chaque détection peut être désactivée par équipe dans **Paramètres > Règles de détection > Gérées par Wirespeed**.

## Remédiation

Tant que l’intégration est en bêta, toutes les actions de remédiation renvoient une erreur indiquant que la remédiation n’est pas encore activée. Une fois l’intégration passée en GA, les actions suivantes deviennent disponibles :

| Action | Utilisateur du coffre (`pcloud:`) | Utilisateur de l’annuaire (`ds:`) |
| - | - | - |
| **Désactiver l’utilisateur** | `POST /PasswordVault/API/Users/{id}/disable/` | `POST /UserMgmt/ChangeUserAttributes` avec `LockedByAdmin: true` |
| **Activer l’utilisateur** | `POST /PasswordVault/API/Users/{id}/enable/` | `POST /UserMgmt/ChangeUserAttributes` avec `LockedByAdmin: false` |
| **Révoquer les sessions de l’utilisateur** | Recherche du nom d’utilisateur, recherche dans `LiveSessions`, puis `POST .../Terminate/` pour chaque session PSM | `POST /Security/EndUserSessions` (met fin aux sessions SSO) |

> [!WARNING]
>
> L’action **Révoquer les sessions de l’utilisateur** nécessite une configuration supplémentaire de Privilege Cloud :
>
> * `AllowPSMNotifications` doit être défini sur **Yes** dans la configuration PVWA.
> * L’utilisateur de service doit être membre du groupe **Terminating Live Sessions Users and Groups** dans PVWA.

## Limites et mises en garde

* **Rétention du flux d’audit** : 7 jours. Si Wirespeed ne peut pas interroger le flux pendant une durée supérieure (par exemple en cas de panne prolongée), les événements manquants sont irrécupérables.
* **Limite de débit du flux d’audit** : 1 appel d’API par minute et par intégration. Wirespeed interroge le flux via un cron d’une minute et respecte cette limite.
* **Liste des utilisateurs PasswordVault** : limitée à 6 000 utilisateurs par réponse. Pour les locataires dont le coffre est plus volumineux, la liste est actuellement tronquée.
* **Intégrations SIEM par locataire** : 2. Wirespeed en utilise une.
* **Identifiants de l’utilisateur de service** : effectuez la rotation du mot de passe de l’utilisateur de service dans Identity Administration, puis mettez-le à jour dans les paramètres de l’intégration Wirespeed.
* **La fin des sessions PSM en direct** nécessite `AllowPSMNotifications=Yes` dans PVWA et la présence de l’utilisateur de service dans le groupe de configuration du coffre **Terminating Live Sessions Users and Groups**. Sans cela, seule la fin des sessions côté SSO fonctionne (ce qui reste efficace pour bloquer de nouvelles sessions à privilèges).

## Dépannage

Si vous rencontrez des erreurs d’authentification après la configuration, les causes les plus fréquentes sont les suivantes :

| Symptôme | Cause probable |
| - | - |
| `invalid_scope` lors de la génération du jeton d’audit | Le scope `isp.audit.events:read` dans l’onglet Scope de l’application OAuth d’audit ne correspond pas exactement (sensible à la casse et à la ponctuation). |
| Le jeton d’audit est généré, mais les appels à l’API d’audit renvoient 401 | Le script de claims `aud` / `tenant_id` (étape 3.7) n’a pas été enregistré, ou l’utilisateur de service ne dispose pas de l’autorisation **Run** sur l’application OAuth d’audit. |
| Les appels d’audit renvoient 401 même avec le bon jeton | L’en-tête `x-api-key` est absent ou incorrect. |
| La synchronisation des utilisateurs ne renvoie aucun utilisateur / renvoie 401 | L’utilisateur de service n’est pas affecté à un rôle d’administrateur Privilege Cloud (étape 2b), ou le sous-domaine déduit automatiquement est incorrect — définissez `pcloudSubdomain` manuellement dans les options avancées de l’intégration. |
| Les appels d’audit échouent avec des erreurs DNS / 404 | L’URL d’audit déduite automatiquement `<sub>.audit.cyberark.cloud` est incorrecte pour votre locataire. Définissez manuellement `auditApiBaseUrl` dans les options avancées avec l’URL affichée sur la page de l’intégration SIEM. |
| Les actions de remédiation renvoient « not yet enabled » | L’intégration est toujours en bêta. Contactez l’équipe chargée de votre compte Wirespeed pour la faire passer en GA. |
| Révoquer les sessions renvoie 403 | L’utilisateur de service n’est pas membre du groupe **Terminating Live Sessions Users and Groups**, ou `AllowPSMNotifications` n’est pas activé. |


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.