> ## 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 (ehemals CyberArk) > Audit-Ereignisse erfassen und Benutzer aus Idira (ehemals CyberArk) Privilege Cloud und Identity synchronisieren ## Überblick Wirespeed verbindet sich mit CyberArk Identity Security Platform Shared Services (ISPSS), um: * **Benutzer zu synchronisieren** – sowohl aus CyberArk Privilege Cloud (Vault-Konten) als auch aus CyberArk Identity (Benutzer aus föderierten Verzeichnissen). * **Audit-Ereignisse zu erfassen** – aus den Diensten PAM (Privilege Cloud), IDP (Identity) und ADM (Admin) als Protokolle, ausgewertet durch von Wirespeed verwaltete Detektionen (fehlgeschlagene MFA, fehlgeschlagene Vault-Anmeldungen, unbefugte Safe- und Passwortzugriffe). * **Benutzerbezogene Behebungsmaßnahmen auszuführen** – über Privilege Cloud (Deaktivieren / Aktivieren / Beenden von PSM-Sitzungen) und Identity Administration (Sperren / Entsperren / Beenden von SSO-Sitzungen), automatisch weitergeleitet, je nachdem, aus welchem Benutzerbestand der Benutzer stammt. > [!WARNING] > > Diese Integration befindet sich in der **Beta**. Behebungsmaßnahmen sind implementiert, aber deaktiviert, bis die Integration auf GA hochgestuft wird. ## Voraussetzungen Sie benötigen: * Einen Mandanten der **CyberArk Identity Security Platform Shared Services (ISPSS)** mit aktivierten Diensten Privilege Cloud, Identity und/oder Admin. * Die Berechtigung, in **Identity Administration** OAuth2-Web-Apps und Dienstbenutzer zu erstellen. * Die Berechtigung, im Bereich Privilege Cloud Administration einen **SIEM-Integrationseintrag** zu erstellen. > [!NOTE] > > CyberArk-Mandanten erlauben gleichzeitig höchstens **zwei SIEM-Integrationen**. Wirespeed belegt einen dieser Plätze. ## Einrichtung Die Einrichtung umfasst vier Elemente in Ihrem CyberArk-Mandanten: 1. Einen Dienstbenutzer, als der sich Wirespeed authentifiziert. 2. Zwei Rollenzuweisungen für diesen Dienstbenutzer (eine für Privilege Cloud, eine für Identity Administration). 3. Eine Web-App vom Typ OAuth2 Server (wird nur für den Audit-/SIEM-Stream verwendet). 4. Einen SIEM-Integrationseintrag, um einen API-Schlüssel zu erzeugen. Führen Sie die folgenden Schritte der Reihe nach aus. ### Schritt 1 – Dienstbenutzer erstellen 1. Melden Sie sich als Administrator bei **Identity Administration** an. 2. Gehen Sie zu **Core Services → Users** und klicken Sie auf **Add User**. 3. Geben Sie die Daten des Benutzers ein. Wählen Sie einen leicht zu merkenden Benutzernamen, z. B. `wirespeed-svc@`. Das Suffix `@` wird automatisch angehängt. 4. Aktivieren Sie unter **Status**: * **Is Service User** * **Is OAuth confidential client** * **Password never expires** 5. Klicken Sie auf **Create User**. Notieren Sie sich Benutzername und Passwort – Sie benötigen sie später. ### Schritt 2 – Dem Dienstbenutzer Rollen zuweisen Der Dienstbenutzer benötigt zwei Rollenzuweisungen – eine für Vorgänge im Identity-Verzeichnis und eine für den Zugriff auf die Privilege-Cloud-APIs. #### 2a. Rolle in Identity Administration 1. Gehen Sie zu **Core Services → Roles** und klicken Sie auf **Add Role**. 2. Geben Sie ihr einen Namen (z. B. `Wirespeed Integration`). 3. Fügen Sie auf der Registerkarte **Administrative Rights** Folgendes hinzu: * **User Management** – erforderlich für das Synchronisieren und Sperren von Benutzern im Identity-Verzeichnis. * **Report Management** – erforderlich für die Redrock-Abfrage, die Benutzer aus föderierten Verzeichnissen abruft (`DsUsers`). 4. Fügen Sie auf der Registerkarte **Members** den Dienstbenutzer hinzu. 5. Klicken Sie auf **Save**. #### 2b. Administratorrolle in Privilege Cloud 1. Suchen Sie in Identity Administration die integrierte Rolle **Privilege Cloud Administrators** (oder eine andere Rolle mit gleichwertigen Rechten – siehe CyberArks [Dokumentation zu Privilege-Cloud-Rollen](https://docs.cyberark.com/identity-administration/latest/en/content/coreservices/getstarted/ispss-user-roles.htm)). 2. Fügen Sie auf der Registerkarte **Members** den Dienstbenutzer hinzu. 3. Klicken Sie auf **Save**. > [!WARNING] > > Die Rollenzuweisung in Privilege Cloud ist **erforderlich**, damit die Integration die PasswordVault-APIs aufrufen kann. Ohne sie lehnen die PasswordVault-Endpunkte das von Wirespeed erzeugte Plattform-Token mit 401 ab. ### Schritt 3 – Audit-OAuth2-Web-App erstellen (Vorlage „Server“) Diese App wird nur für die SIEM Audit API verwendet. Alle anderen API-Aufrufe von Wirespeed verwenden ein generisches Plattform-Token, für das keine benutzerdefinierte Web-App erforderlich ist. 1. Gehen Sie zu **Apps & Widgets → Web Apps** und klicken Sie auf **Add Web Apps**. 2. Suchen Sie auf der Registerkarte **Custom** nach **OAuth2 Server**, klicken Sie auf **Add** und bestätigen Sie. 3. Legen Sie auf der Registerkarte **Settings** Folgendes fest: * **Application ID**: `WirespeedAudit` (oder ein anderer URL-sicherer Bezeichner – notieren Sie ihn für später). * **Application Name**: `Wirespeed Audit`. 4. Setzen Sie auf der Registerkarte **General Usage** den **Client ID Type** auf **Confidential**. 5. Legen Sie auf der Registerkarte **Tokens** Folgendes fest: * **Token Type**: **JwtRS256**. * **Auth Methods**: Aktivieren Sie **Client Creds**. * **Token Lifetime**: mindestens 15 Minuten. 6. Klicken Sie auf der Registerkarte **Scope** auf **Add** und erstellen Sie einen Scope: * **Name**: `isp.audit.events:read` 7. Fügen Sie auf der Registerkarte **Advanced** dieses Skript ein und klicken Sie auf **Save**: ```js theme={null} setClaim('tenant_id', TenantData.Get("CybrTenantID")); setClaim('aud', 'cyberark.isp.audit'); ``` 8. Fügen Sie auf der Registerkarte **Permissions** den Dienstbenutzer aus Schritt 1 mit den Berechtigungen **Run**, **View**, **Grant** und **Automatically Deploy** hinzu. 9. Klicken Sie oben auf **Save**. ### Schritt 4 – SIEM-Integrationseintrag erstellen 1. Wechseln Sie in den Bereich **Administration** (das Admin-Portal auf Mandantenebene). 2. Gehen Sie zu **My environment → Integrations → Export to SIEM**. 3. Klicken Sie auf **Create → Create SIEM integration**. 4. Geben Sie einen Namen ein (z. B. `Wirespeed`) und klicken Sie auf **Apply**. 5. Notieren Sie sich den generierten **API key** – er wird nur einmal angezeigt. Die Seite zeigt außerdem eine **API base URL** an. Diese müssen Sie in der Regel nicht kopieren (Wirespeed leitet sie aus dem Plattform-Token ab), halten Sie sie aber bereit, falls die automatische Ableitung für Ihren Mandanten nicht funktioniert. ### Schritt 5 – Wirespeed verbinden 1. Gehen Sie in Wirespeed zu **Integrationen → Integration hinzufügen → Idira (formerly CyberArk)**. 2. Bestätigen Sie den Beta-Hinweis. 3. Geben Sie Folgendes an: | Feld | Wert | | - | - | | **Identity-URL** | Ihre Identity-Admin-URL, z. B. `https://aab1234.id.cyberark.cloud` (aus der Adressleiste des Identity-Admin-Portals kopieren). | | **App-ID des Audit-OAuth2-Servers** | Die Application ID aus Schritt 3 (z. B. `WirespeedAudit`). | | **Anmeldename des Dienstbenutzers** | Der vollständige Anmeldename aus Schritt 1 einschließlich des Mandantensuffixes (z. B. `wirespeed-svc@aab1234`). | | **Passwort des Dienstbenutzers** | Das Passwort aus Schritt 1. | | **SIEM-API-Schlüssel** | Der API-Schlüssel aus Schritt 4. | 4. Klicken Sie auf **Hinzufügen**. Wirespeed erzeugt ein Plattform-Token, leitet daraus Ihre Privilege-Cloud-Subdomain ab und startet die erste Audit- und Benutzersynchronisierung. > [!NOTE] > > Die **Privilege-Cloud-Subdomain** wird bei der ersten Verbindung automatisch aus dem Plattform-Token abgeleitet und dient zum Aufbau sowohl der PasswordVault-URL (`.privilegecloud.cyberark.cloud`) als auch der Audit-URL (`.audit.cyberark.cloud`). Wenn Ihr Mandant eine nicht standardmäßige Audit-URL verwendet (z. B. regional gemeinsam genutzte Hosts wie `eu.audit.cyberark.cloud`), legen Sie die Überschreibung **Audit-API-Basis-URL** in den erweiterten Optionen der Integration manuell fest. ## Was wird erfasst? ### Benutzer (täglich um 14:00 UTC sowie sofort beim Verbinden) Wirespeed synchronisiert aus **beiden** CyberArk-Benutzerbeständen, da es sich um getrennte Mengen mit unterschiedlichen Behebungswegen handelt: | Quelle | Benutzerbestand | Behebungsschnittstelle | | - | - | - | | **PasswordVault** (Präfix `pcloud:`) | Vault-Konten, die privilegierte Zugangsdaten enthalten, Passwörter abrufen und PSM-Sitzungen starten können. | PasswordVault-APIs (Vault-Konto deaktivieren/aktivieren, Beenden laufender PSM-Sitzungen). | | **Identity-Verzeichnis** (Präfix `ds:`) | Föderierte AD-/LDAP-/AzureAD-Benutzer, die sich per SSO beim Mandanten authentifizieren. Sie können, müssen aber keine Vault-Benutzer sein. | Identity-Administration-APIs (UserMgmt sperren/entsperren, Beenden von SSO-Sitzungen). | Die `directoryId` jedes Benutzers erhält die Quelle als Präfix (`pcloud:17`, `ds:a41ca4c8-…`), damit die Behebungsmaßnahmen wissen, welche API sie aufrufen müssen. Eine Person kann unter jedem Präfix einmal erscheinen, wenn sie in beiden Benutzerbeständen existiert. Komponentenbenutzer (CPM, PSM, ENE usw.) werden aus der PCloud-Synchronisierung herausgefiltert – nur echte Personen- und Dienstkonten werden angezeigt. ### Audit-Protokolle (jede Minute) Wirespeed fragt die SIEM Audit API nach Ereignissen unter drei Anwendungscodes ab: * **PAM** – Privilege Cloud (Vault-Authentifizierung, Zugriff auf Zugangsdaten, privilegierte Sitzungen, Rotation von Zugangsdaten, Safe-Verwaltung). * **IDP** – Identity (Authentifizierung, MFA, Abmeldung, SAML, Risikoprüfungen). * **ADM** – Admin (Zugriffskontrolle, Benutzerverwaltung, Konfigurationsänderungen). Bei der ersten Verbindung lädt Wirespeed die Ereignisse der **letzten 7 Tage** nach (das Aufbewahrungsfenster des Audit-Streams). Danach öffnet jede Abfrage ein neues `createQuery`-Zeitfenster von einem gespeicherten Start-Wasserzeichen bis jetzt und verwendet `cursorRef` nur zum Blättern innerhalb dieses Fensters. ### Verwaltete Detektionen CyberArk erzeugt keine eigenen Detektionen. Wirespeed prüft die erfassten Audit-Ereignisse auf: | Detektion | Bedingung | | - | - | | CyberArk Identity MFA-Sperre | Eine Identity- oder Admin-MFA-Abfrage schlägt fehl, weil das Konto gesperrt ist | | CyberArk Identity MFA abgelehnt | Eine Identity- oder Admin-MFA-Abfrage schlägt fehl, bleibt unbeantwortet oder wird falsch beantwortet | | CyberArk-Vault-Anmeldung fehlgeschlagen | Eine Vault-Authentifizierung oder -Anmeldung schlägt fehl (PAM00004, PAM00102-104) | | Nicht autorisierter CyberArk-Safe-Vorgang | Ein Safe-Vorgang wird verweigert (PAM00017, PAM00025-026, PAM00040-047) | | Nicht autorisierte Verwendung eines CyberArk-Passworts | Das Abrufen oder Verwenden eines Passworts wird verweigert (PAM00306-307) | Vault-Detektionen ignorieren CyberArk-Komponentenkonten (Connector, PVWA, CPM, PSM und ähnliche Dienstbenutzer). Jede Detektion kann pro Team unter **Einstellungen > Detektionsregeln > Von Wirespeed verwaltet** deaktiviert werden. ## Behebung Solange sich die Integration in der Beta befindet, geben alle Behebungsmaßnahmen einen Fehler zurück, der darauf hinweist, dass die Behebung noch nicht aktiviert ist. Nach der Hochstufung auf GA stehen die folgenden Aktionen zur Verfügung: | Aktion | Vault-Benutzer (`pcloud:`) | Verzeichnisbenutzer (`ds:`) | | - | - | - | | **Benutzer deaktivieren** | `POST /PasswordVault/API/Users/{id}/disable/` | `POST /UserMgmt/ChangeUserAttributes` mit `LockedByAdmin: true` | | **Benutzer aktivieren** | `POST /PasswordVault/API/Users/{id}/enable/` | `POST /UserMgmt/ChangeUserAttributes` mit `LockedByAdmin: false` | | **Benutzersitzungen widerrufen** | Benutzername nachschlagen, `LiveSessions` durchsuchen, `POST .../Terminate/` für jede PSM-Sitzung | `POST /Security/EndUserSessions` (beendet SSO-Sitzungen) | > [!WARNING] > > Die Aktion **Benutzersitzungen widerrufen** erfordert zusätzliche Konfiguration in Privilege Cloud: > > * `AllowPSMNotifications` muss in der PVWA-Konfiguration auf **Yes** gesetzt sein. > * Der Dienstbenutzer muss in PVWA Mitglied der Gruppe **Terminating Live Sessions Users and Groups** sein. ## Grenzen und Einschränkungen * **Aufbewahrung des Audit-Streams**: 7 Tage. Wenn Wirespeed länger nicht abfragen kann (z. B. bei einem längeren Ausfall), lässt sich die Lücke nicht schließen. * **Ratenbegrenzung des Audit-Streams**: 1 API-Aufruf pro Minute und Integration. Wirespeed fragt im 1-Minuten-Takt ab und hält diese Grenze ein. * **PasswordVault-Benutzerliste**: auf 6.000 Benutzer pro Antwort begrenzt. Größere Vault-Mandanten würden derzeit abgeschnitten. * **SIEM-Integrationen pro Mandant**: 2. Wirespeed belegt eine davon. * **Zugangsdaten des Dienstbenutzers**: Rotieren Sie das Passwort des Dienstbenutzers in Identity Administration und aktualisieren Sie es anschließend in den Einstellungen der Wirespeed-Integration. * **Das Beenden laufender PSM-Sitzungen** erfordert `AllowPSMNotifications=Yes` in PVWA und dass der Dienstbenutzer Mitglied der Vault-Konfigurationsgruppe **Terminating Live Sessions Users and Groups** ist. Andernfalls funktioniert nur das Beenden von Sitzungen auf SSO-Seite (was weiterhin wirksam neue privilegierte Sitzungen verhindert). ## Fehlerbehebung Wenn nach der Einrichtung Authentifizierungsfehler auftreten, sind dies die häufigsten Ursachen: | Symptom | Wahrscheinliche Ursache | | - | - | | `invalid_scope` beim Erzeugen des Audit-Tokens | Der Scope `isp.audit.events:read` auf der Registerkarte „Scope“ der Audit-OAuth-App stimmt nicht exakt überein (Groß-/Kleinschreibung und Satzzeichen werden unterschieden). | | Audit-Token wird erzeugt, aber Audit-API-Aufrufe liefern 401 | Das Claims-Skript für `aud` / `tenant_id` (Schritt 3.7) wurde nicht gespeichert, oder dem Dienstbenutzer fehlt die Berechtigung **Run** für die Audit-OAuth-App. | | Audit-Aufrufe liefern trotz korrektem Token 401 | Der Header `x-api-key` fehlt oder ist falsch. | | Benutzersynchronisierung liefert keine Benutzer / 401 | Der Dienstbenutzer ist keiner Privilege-Cloud-Administratorrolle zugewiesen (Schritt 2b), oder die automatisch abgeleitete Subdomain ist falsch – legen Sie `pcloudSubdomain` in den erweiterten Optionen der Integration manuell fest. | | Audit-Aufrufe schlagen mit DNS-Fehlern / 404 fehl | Die automatisch abgeleitete Audit-URL `.audit.cyberark.cloud` ist für Ihren Mandanten falsch. Legen Sie `auditApiBaseUrl` in den erweiterten Optionen manuell auf die URL fest, die auf der Seite der SIEM-Integration angezeigt wird. | | Behebungsmaßnahmen liefern „not yet enabled“ | Die Integration befindet sich noch in der Beta. Wenden Sie sich an Ihr Wirespeed-Account-Team, um die Hochstufung auf GA zu veranlassen. | | „Sitzungen widerrufen“ liefert 403 | Der Dienstbenutzer ist nicht Mitglied der Gruppe **Terminating Live Sessions Users and Groups**, oder `AllowPSMNotifications` ist nicht aktiviert. | This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.