Add To Vault

Die Add to Vault Automatisierung ermöglicht Hydden Discovery, entdeckte privilegierte Konten automatisch in Privileged Access Management (PAM)-Systeme aufzunehmen. Verwenden Sie klassifizierungsgesteuerte Workflows, um Konten in Vaults aufzunehmen, sobald sie entdeckt werden, wodurch der manuelle Verwaltungsaufwand reduziert und die Sicherheitslage verbessert wird.

Übersicht

Add to Vault Workflows erstellen oder erkennen automatisch Konten in PAM-Systemen, wenn Klassifizierungsregeln angewendet werden. Diese geschlossene Integration ermöglicht:

• Automatische Kontoaufnahme: Neu entdeckte privilegierte Konten ohne manuelles Eingreifen in Vaults aufnehmen
• Klassifizierungsbasiertes Vaulting: Vaulting basierend auf Kontoklassifizierungsregeln auslösen
• Multi-PAM-Unterstützung: Integration mit CyberArk Privilege Cloud, CyberArk Self-Hosted und BeyondTrust Password Safe
• Ratenbegrenzung: Kontrolliertes Konto-Erstellen (30 Konten pro Minute pro Collector), um PAM-Systeme nicht zu überlasten
• Vorlagenbasierte Konfiguration: Variablen verwenden, um Vault-Felder dynamisch aus entdeckten Kontodaten zu befüllen

Unterstützte PAM-Systeme

Hydden Discovery integriert sich mit den folgenden PAM-Plattformen:

CyberArk

• CyberArk Privilege Cloud (SaaS):

  • REST-API-Integration über /PasswordVault/API/Accounts
  • Discovered Accounts API über /api/discovered-accounts
  • Kontoabgleich und Passwortverwaltung
  • Plattform- und Safe-basierte Organisation

• CyberArk Self-Hosted (On-Premises):

  • REST-API-Integration (gleiche Endpunkte wie Cloud)
  • Credential Provider (CCP) Integration für Passwortabruf
  • Plattform- und Safe-basierte Organisation
  • Unterstützung benutzerdefinierter Plattformen

BeyondTrust

• BeyondTrust Password Safe:
  • REST-API-Integration über /BeyondTrust/api/public/v3/
  • Verwaltete Konten und verwaltete Systeme
  • Automatische Passwortverwaltung
  • Passwort-Checkout- und -Checkin-Workflows

Voraussetzungen

Vor der Konfiguration von Add to Vault Workflows:

• PAM-Systemintegration: CyberArk oder BeyondTrust Integration in Hydden Discovery konfigurieren (siehe CyberArk Integration oder BeyondTrust Integration)
• PAM-Anmeldeinformationen: Anmeldeinformationen für den PAM-API-Zugriff erstellen unter Configuration > Settings > Credentials
• Klassifizierungsregeln: Klassifizierungsregeln konfigurieren, um Konten zu identifizieren, die in Vaults aufgenommen werden sollen (siehe Klassifizierungsregeln)
• PAM-Plattformen: Sicherstellen, dass Zielplattformen (z. B. Windows Domain, Unix) und Safes/Vaults im PAM-System existieren
• Berechtigungen: Überprüfen, ob PAM-API-Anmeldeinformationen die Berechtigung haben, Konten zu erstellen und auf Ziel-Safes zuzugreifen

Add to Vault Provider-Konfiguration

So fügen Sie einen Add to Vault Provider hinzu:

1. Navigieren Sie in Hydden zu Configuration > Automate.
2. Klicken Sie auf der Registerkarte Providers auf + Add New.
3. Wählen Sie aus dem Drop-down Type den Eintrag Add To Vault.
4. Geben Sie unter Name einen beschreibenden Provider-Namen ein (z. B. "CyberArk Production Vault", "BeyondTrust PAM").
5. Geben Sie unter Description eine optionale Beschreibung des Provider-Zwecks an.
6. Wählen Sie aus dem Drop-down Credential die vorkonfigurierte PAM-Integrations-Anmeldeinformation:
   • Für CyberArk: CyberArk API-Anmeldeinformation auswählen
   • Für BeyondTrust: BeyondTrust API-Anmeldeinformation auswählen
   • Der Anmeldeinformationstyp bestimmt, welcher PAM-Provider verwendet wird
7. Klicken Sie auf Save.

Der Provider verweist auf die konfigurierte PAM-Integration (CyberArk oder BeyondTrust) über den Anmeldeinformationstyp. Alle Vault-Verbindungsdetails (Endpunkte, Authentifizierung) werden in den PAM-Integrationseinstellungen konfiguriert.

Add to Vault Workflow-Konfiguration

Add to Vault Workflows werden typischerweise durch Klassifizierungsregeln ausgelöst. Wenn eine Klassifizierung auf ein Konto angewendet wird, nimmt der Workflow das Konto automatisch in den Vault auf.

So erstellen Sie einen Add to Vault Workflow:

1. Navigieren Sie in Hydden zu Configuration > Automate.
2. Klicken Sie auf der Registerkarte Workflows auf + Add New.
3. Geben Sie unter Name einen beschreibenden Workflow-Namen ein (z. B. "Auto-Vault Linux Root Accounts", "Vault Windows Admins to CyberArk").
4. Geben Sie unter Description eine optionale Beschreibung des Workflow-Zwecks an.
5. Wählen Sie aus dem Drop-down Trigger den Eintrag Classification Added.
6. Wählen Sie aus dem Drop-down Classification Rule die Klassifizierung, die das Vaulting auslösen soll:
   • Add to Vault: Standardklassifizierung für allgemeines Vaulting
   • Auto Add to CyberArk: Standardklassifizierung für CyberArk-spezifisches Vaulting
   • Benutzerdefinierte Klassifizierungsregeln, die Sie erstellt haben
   • Siehe Klassifizierungsregeln zum Erstellen benutzerdefinierter Regeln
7. Wählen Sie aus dem Drop-down Action Ihren konfigurierten Add to Vault Provider (z. B. "Add to CyberArk Production").
8. Wählen Sie aus dem Drop-down Select Vault Connection Ihre konfigurierte PAM-Integration:
   • Listet verfügbare CyberArk- und BeyondTrust-Integrationen auf
   • Integration muss mit dem Anmeldeinformationstyp des Providers übereinstimmen
9. Konfigurieren Sie die Workflow-Felder basierend auf Ihrem PAM-System (siehe plattformspezifische Abschnitte unten).
10. Klicken Sie auf Save.
11. Schalten Sie den Workflow-Schalter auf on, um ihn zu aktivieren.

NOTE

Überprüfen Sie unter Configuration > Identify > Classification Rules, ob die Klassifizierungsregel die Option Allow Workflow Trigger aktiviert hat. Ohne diese wird der Workflow nicht ausgeführt, wenn die Klassifizierung angewendet wird.

Gemeinsame Workflow-Felder

Die folgenden Felder sind plattformübergreifend für alle PAM-Plattformen:

Feld	Beschreibung	Erforderlich	Vorlagenunterstützung
Username	Konto-Benutzername	Ja	Ja (typischerweise {Principal.Name} oder {Name})
Account Name	Anzeigename für das Konto im PAM	Nein	Ja (vorab mit Vorlage befüllt)
System	Betriebssystemtyp	Ja	Nein (Auswahl aus Drop-down)
Platform	PAM-Plattformkennung	Ja	Nein (Auswahl aus Drop-down)
Safe / Vault	Ziel-Safe- oder -Vault-Name	Ja	Ja (kann Variable für dynamische Safe-Zuweisung verwenden)
Address	Zielsystem-Adresse (Hostname, IP, Domäne)	Ja	Ja (typischerweise {Address} oder Domänenname)
Password	Kontopasswort (optional)	Nein	Ja
Automatic Password Management	CPM/automatische Passwortrotation aktivieren	Nein	N/A (Kontrollkästchen)

CyberArk Workflow-Konfiguration

CyberArk-spezifische Felder

Feld	Beschreibung	Beispielwert	Vorlagenvariable
Username	Konto-Benutzername	root, admin	{Principal.Name} oder {Name}
Account Name	Anzeigename in CyberArk	root@prod-server-01	Vorab befüllte Vorlage
System	Betriebssystem	Windows, Unix, Linux	Auswahl aus Drop-down
Platform	CyberArk Platform ID	UnixSSH, WinDomain	Auswahl aus Drop-down
Safe	CyberArk Safe-Name	Linux-Servers, Windows-Admins	{classification} oder fester Wert
Address	Zielsystem-Adresse	prod-server-01.corp.local	{Address} oder Domäne
Allow Automatic Password Management	CPM aktivieren	Aktiviert/Deaktiviert	N/A

CyberArk Plattformauswahl

CyberArk-Workflows erfordern die Auswahl einer Platform ID, die definiert, wie CyberArk das Konto verwaltet. Häufige Plattformen:

• Unix/Linux:

  • UnixSSH: SSH-basierte Unix/Linux-Konten
  • UnixSSHKeys: Unix-Konten mit SSH-Schlüssel-Authentifizierung
  • UnixViaSSHTunnel: Unix-Konten, die über SSH-Tunnel zugänglich sind

• Windows:

  • WinDomain: Windows-Domänenkonten
  • WinServerLocal: Lokale Windows-Serverkonten
  • WinDesktopLocal: Lokale Windows-Desktopkonten

• Datenbank:

  • Oracle: Oracle-Datenbankkonten
  • MSSQLServer: Microsoft SQL Server-Konten
  • MySQL: MySQL-Datenbankkonten

• Cloud:

  • AWS: AWS IAM-Konten
  • Azure: Azure Service Principals
  • GCP: Google Cloud-Servicekonten

TIP

Wenn Ihre benötigte Plattform nicht aufgelistet ist, erstellen Sie sie zuerst in CyberArk, dann erscheint sie im Drop-down.

CyberArk Safe-Zuweisung

Sie können Vorlagenvariablen verwenden, um Konten dynamisch Safes zuzuweisen:

• Fester Safe: Einen Safe-Namen direkt eingeben (z. B. Linux-Privileged-Accounts)
• Dynamischer Safe: Klassifizierungsvariable verwenden (z. B. {classification} wird zum Klassifizierungsnamen aufgelöst)
• Benutzerdefinierte Logik: Andere Variablen verwenden (z. B. {Platform}-Accounts erstellt plattformspezifische Safes)

CyberArk Unix/Linux Zusatzoptionen

Für Unix- und Linux-Plattformen stehen zusätzliche Optionen zur Verfügung:

• Use SUDO on Reconcile: Aktivieren, wenn das Konto sudo für Passwortänderungen benötigt
• Fetch SSH Keys: Aktivieren, um SSH-Schlüssel für das Konto abzurufen

Beispiel CyberArk Workflow

Auto-Vault Linux Root-Konten:

Name: Auto-Vault Linux Root Accounts
Trigger: Classification Added
Classification Rule: Linux Privileged
Action: Add to CyberArk Vault
Vault Connection: CyberArk Production
Username: {Principal.Name}
System: Unix
Platform: UnixSSH
Safe: Linux-Privileged-Accounts
Address: {Address}
Allow Automatic Password Management: Checked

BeyondTrust Workflow-Konfiguration

BeyondTrust-spezifische Felder

Feld	Beschreibung	Beispielwert	Vorlagenvariable
Username	Konto-Benutzername	root, administrator	{Principal.Name} oder {Name}
Account Name	Anzeigename in BeyondTrust	root@server-01	Vorab befüllte Vorlage
System	Managed System-Kennung	System-ID aus BeyondTrust	Auswahl aus Drop-down
Platform	Kontotyp	Password, SSH Key	Auswahl aus Drop-down
Address	Zielsystem-Adresse	prod-server-01.corp.local	{Address}
AutoManagementFlag	Automatische Passwortverwaltung aktivieren	True/False	Kontrollkästchen

BeyondTrust Systemauswahl

BeyondTrust-Workflows erfordern die Auswahl eines Managed Systems, das den Zielserver oder das Gerät repräsentiert. Managed Systems müssen vor der Erscheinung im Drop-down in BeyondTrust Password Safe vorkonfiguriert sein.

So bereiten Sie BeyondTrust für Auto-Vaulting vor:

1. In BeyondTrust Password Safe Managed Systems für Zielserver erstellen
2. Systemdetails konfigurieren (Hostname, IP-Adresse, Plattformtyp)
3. Auto-Management-Richtlinien einrichten
4. Überprüfen, ob Managed Systems im Hydden Workflow-Drop-down erscheinen

BeyondTrust Passwortverwaltung

BeyondTrust unterstützt automatische Passwortverwaltung:

• AutoManagementFlag: Aktivieren, um BeyondTrust die automatische Passwortrotation zu erlauben
• Änderungsfrequenz: In BeyondTrust konfiguriert (Standard: Erster des Monats um 23:30)
• Freigabedauer: 10 Minuten Standard
• Maximale Freigabedauer: 60 Minuten Standard

Beispiel BeyondTrust Workflow

Auto-Vault Windows Administrator-Konten:

Name: Auto-Vault Windows Admins
Trigger: Classification Added
Classification Rule: Windows Privileged
Action: Add to BeyondTrust Vault
Vault Connection: BeyondTrust Password Safe
Username: {Principal.Name}
System: [Select Managed System]
Platform: Password
Address: {Address}
AutoManagementFlag: Checked

Vorlagenvariablen für Vaulting

Add to Vault Workflows unterstützen Vorlagenvariablen aus dem Trigger Classification Added. Häufige Variablen:

Variable	Beschreibung	Beispielwert
{Name}	Kontoname	root, administrator
{Principal.Name}	Hauptbenutzer-Benutzername	jsmith, admin_prod
{Address}	Systemadresse	prod-server-01.corp.local
{Platform}	Quellplattform	Linux, Windows, ActiveDirectory
{Site}	Standortkennung	prod-datacenter-01
{classification}	Klassifizierungsname	Add to Vault, Linux Privileged
{classification_id}	Klassifizierungsregel-ID	auto-vault-linux
{Collector.name}	Collector-Name	Linux Prod Collector

Siehe Trigger für vollständige Variablenlisten.

Variablenverwendungsbeispiele

Dynamische Safe-Zuweisung:

Safe: {Platform}-{classification}
Result: Linux-Privileged-Accounts

Kontonamen-Vorlage:

Account Name: {Principal.Name}@{Address}
Result: root@prod-server-01.corp.local

Adresse mit Domäne:

Address: {Address}.corp.example.com
Result: server01.corp.example.com

Ratenbegrenzung

Add to Vault Workflows beinhalten eine Ratenbegrenzung, um PAM-Systeme nicht mit Kontoerstellungsanfragen zu überlasten:

• Standardrate: 30 Konten pro Minute pro Collector
• Geltungsbereich: Ratenbegrenzung gilt pro Collector (mehrere Collectors können parallel in Vaults aufnehmen)
• Implementierung: Token-Bucket-Algorithmus mit konfigurierbarer Rate
• Gegendruck: Workflows warten, wenn die Ratenbegrenzung erreicht ist, und setzen dann fort

Ratenbegrenzungsverhalten

Wenn die Ratenbegrenzung erreicht ist:

1. Workflow pausiert: Add to Vault Workflow wartet auf verfügbare Token
2. Warteschlange: Ausstehende Vault-Anfragen werden der Reihe nach in die Warteschlange gestellt
3. Fortsetzung: Workflow setzt fort, wenn Token verfügbar sind
4. Keine Fehler: Ratenbegrenzung verursacht keine Workflow-Fehler

Ratenbegrenzungskonfiguration

Ratenbegrenzungen werden auf Systemebene konfiguriert und können nicht pro Workflow geändert werden. Wenden Sie sich an Ihren Hydden-Administrator, wenn Ratenbegrenzungen angepasst werden müssen.

Klassifizierungsgesteuertes Auto-Vaulting

Auto-Vaulting wird durch Klassifizierungsregeln ausgelöst. Wenn ein Konto einer Klassifizierungsregel mit aktiviertem Allow Workflow Trigger entspricht, wird der Workflow ausgeführt.

Anforderungen an Klassifizierungsregeln

Damit Auto-Vaulting funktioniert:

1. Klassifizierungsregel existiert: Klassifizierungsregel erstellen unter Configuration > Identify > Classification Rules
2. Allow Workflow Trigger: Kontrollkästchen Allow Workflow Trigger auf der Klassifizierungsregel aktivieren
3. Workflow konfiguriert: Add to Vault Workflow mit der Klassifizierung als Trigger erstellen
4. Workflow aktiviert: Workflow in den Status "on" umschalten

Häufige Klassifizierungsmuster

Linux Root-Konten:

Classification Name: Linux Privileged
Pattern: Name = "root" AND Platform = "Linux"
Allow Workflow Trigger: Checked

Windows Lokale Administratoren:

Classification Name: Windows Admin
Pattern: Name CONTAINS "admin" AND Platform = "Windows"
Allow Workflow Trigger: Checked

Servicekonten:

Classification Name: Service Accounts
Pattern: Name STARTS WITH "svc_" OR Name CONTAINS "service"
Allow Workflow Trigger: Checked

SQL SA-Konten:

Classification Name: SQL SA
Pattern: Name = "sa" AND Platform = "MSSQL"
Allow Workflow Trigger: Checked

Manuelles vs. Auto-Vaulting

Auto-Vaulting (klassifizierungsgesteuert)

Konten werden automatisch in Vaults aufgenommen, wenn Klassifizierungsregeln übereinstimmen:

• Trigger: Classification Added
• Ausführung: Automatisch, wenn Klassifizierung angewendet wird
• Benutzerinteraktion: Nicht erforderlich
• Anwendungsfall: Kontinuierliche Erkennung und Vaulting privilegierter Konten

Manuelles Vaulting (benutzerinitiiert)

Benutzer nehmen Konten manuell über die Hydden Discovery Benutzeroberfläche in Vaults auf:

• Trigger: Benutzeraktion in der Benutzeroberfläche
• Ausführung: Benutzer wählt Konten aus und initiiert das Vaulting
• Benutzerinteraktion: Erforderlich
• Anwendungsfall: Ad-hoc-Vaulting oder Ausnahmen von Auto-Vaulting-Regeln

Workflow-Ausführung und -Überwachung

Ausführungsablauf

1. Konto entdeckt: Datenquellenerfassung entdeckt Konto
2. Klassifizierung angewendet: Konto entspricht Klassifizierungsregel
3. Workflow ausgelöst: Add to Vault Workflow wird initiiert
4. Ratenbegrenzungsprüfung: Workflow prüft verfügbare Token-Kapazität
5. Vorverarbeitung: Kontodaten werden mit Collector- und Entitätsmetadaten angereichert
6. Vorlagenrendering: Workflow-Felder werden mit Variablensubstitution gerendert
7. API-Aufruf: PAM-System-API wird aufgerufen, um Konto zu erstellen/erkennen
8. Ergebnisprotokollierung: Erfolg oder Fehler wird protokolliert

Erfolgskriterien

Eine Vault-Operation gilt als erfolgreich, wenn:

• PAM-API HTTP 200/201 Statuscode zurückgibt
• Konto im PAM-System erstellt oder erkannt wird
• Keine API-Fehler auftreten

Fehlerbehandlung

Wenn eine Vault-Operation fehlschlägt:

• Protokolliert: Fehler wird mit Fehlerdetails protokolliert
• Keine Wiederholung: Vault-Operationen werden nicht automatisch wiederholt (um doppelte Konten zu vermeiden)
• Manuelle Wiederholung: Benutzer können die Klassifizierung manuell erneut anwenden, um es zu wiederholen
• Untersuchung: Protokolle auf Fehlerdetails prüfen (Authentifizierung, Berechtigungen usw.)

Workflows überwachen

Vault-Workflow-Ausführung überwachen über:

• Hydden Discovery Protokolle: Anwendungsprotokolle auf Vault-API-Aufrufe und -Antworten prüfen
• PAM-Systemprotokolle: PAM-Auditprotokolle auf Kontoerstellungsereignisse prüfen
• Workflow-Status: Überprüfen, ob Workflows aktiviert sind und ausgeführt werden
• Klassifizierungsanwendung: Bestätigen, dass Klassifizierungen auf Konten angewendet werden

Häufige Anwendungsfälle

Kontinuierliche Erkennung privilegierter Konten

Szenario: Alle neu entdeckten privilegierten Konten automatisch in Vaults aufnehmen

Konfiguration:

• Klassifizierung: "Privileged Account"-Regel, die Admin-Muster abgleicht
• Workflow: Auto-Vault in CyberArk Safe "Discovered-Privileged"
• Plattform: Mehrere Plattformen (Linux, Windows, SQL)

Vorteil: Sofortiges Vaulting privilegierter Konten, sobald sie entdeckt werden

Plattformspezifisches Vaulting

Szenario: Konten basierend auf Plattform in verschiedene Safes aufnehmen

Konfiguration:

• Klassifizierung: Plattformspezifische Regeln (Linux Privileged, Windows Privileged)
• Workflows: Separate Workflows für jede Plattform
• Safe-Zuweisung: Dynamisch mit {Platform}-Privileged-Variable

Vorteil: Organisierte Kontoverwaltung nach Plattformtyp

Compliance-gesteuertes Vaulting

Szenario: Konten, die Compliance-Kontrollen erfordern, in Vaults aufnehmen

Konfiguration:

• Klassifizierung: "Requires Compliance"-Regel basierend auf Geschäftskriterien
• Workflow: Auto-Vault mit aktivierter automatischer Passwortverwaltung
• PAM-Richtlinie: Erzwungene Passwortrotation und Zugriffprotokollierung

Vorteil: Automatisierte Anwendung von Compliance-Kontrollen

Servicekontenverwaltung

Szenario: Entdeckte Servicekonten für Passwortrotation in Vaults aufnehmen

Konfiguration:

• Klassifizierung: "Service Account"-Regel, die Benennungsmuster abgleicht (svc_, app_ usw.)
• Workflow: Auto-Vault in Safe "Service-Accounts"
• Plattform: Anwendungsspezifische Plattformen

Vorteil: Zentralisierte Verwaltung von Servicekonto-Anmeldeinformationen

Fehlerbehebung

Problem	Lösung
Workflow wird nicht ausgelöst	Überprüfen, ob Klassifizierungsregel "Allow Workflow Trigger" aktiviert hat, prüfen, ob Workflow aktiviert ist, bestätigen, ob Klassifizierung angewendet wird
Authentifizierungsfehler	PAM-Anmeldeinformationen auf Gültigkeit prüfen, API-Endpunkt auf Erreichbarkeit prüfen, Anmeldeinformationstyp auf Übereinstimmung mit PAM-System bestätigen
Plattform nicht gefunden	Überprüfen, ob Plattform im PAM-System existiert, Platform ID-Schreibweise prüfen, Plattform im PAM erstellen falls fehlend
Safe nicht gefunden	Überprüfen, ob Safe/Vault im PAM-System existiert, Safe-Name-Schreibweise prüfen, Safe im PAM erstellen falls fehlend
Zugriff verweigert	Überprüfen, ob PAM-Benutzer Berechtigung hat, Konten im Ziel-Safe zu erstellen, PAM-ACLs und -Richtlinien prüfen
Ratenbegrenzungsverzögerungen	Dies ist normales Verhalten — Workflow setzt fort, wenn Kapazität verfügbar ist, Ratenbegrenzungen bei Bedarf anpassen
Doppelte Konten	Prüfen, ob Workflow mehrfach ausgelöst wurde, Klassifizierungsregel-Logik überprüfen, Deduplizierung im PAM implementieren
Variablen werden nicht ersetzt	Variablennamen auf Übereinstimmung mit Triggertyp prüfen (siehe Trigger), Syntax auf {Variable}-Format prüfen
Falscher Safe/Vault zugewiesen	Überprüfen, ob Vorlagenvariable korrekt aufgelöst wird, Safe-Name-Vorlagensyntax prüfen, zuerst mit festem Safe-Namen testen

Best Practices

Workflow-Design

• Plattformspezifische Workflows: Separate Workflows für jeden Plattformtyp erstellen (Linux, Windows, SQL usw.)
• Safe-Organisation: Logische Safe-Namen verwenden, die Kontokategorien widerspiegeln
• Benennungskonventionen: Konsistente Kontonamenvorlagen über Workflows hinweg verwenden
• Zuerst testen: Workflows mit einer kleinen Menge an Konten testen, bevor sie breit eingesetzt werden

Klassifizierungsstrategie

• Spezifische Regeln: Gezielte Klassifizierungsregeln erstellen, die bestimmte Kontotypen abgleichen
• Über-Klassifizierung vermeiden: Keine Regeln erstellen, die zu viele Konten auf einmal abgleichen
• Schrittweiser Rollout: Auto-Vaulting für einen Kontotyp nach dem anderen aktivieren
• Regelmäßig überprüfen: Klassifizierungsregeln regelmäßig auf Genauigkeit überprüfen

PAM-Systemvorbereitung

• Safes vorab erstellen: Ziel-Safes/Vaults im PAM erstellen, bevor Workflows aktiviert werden
• Plattformkonfiguration: Alle erforderlichen Plattformen im PAM konfigurieren
• Konnektivität testen: Überprüfen, ob Hydden sich mit PAM-APIs verbinden kann
• Kapazität überwachen: Sicherstellen, dass das PAM-System die Kontoerstellungsrate verarbeiten kann

Betriebsverwaltung

• Workflows überwachen: Workflow-Ausführungsprotokolle regelmäßig prüfen
• In Vaults aufgenommene Konten überprüfen: Durch Automatisierung in Vaults aufgenommene Konten regelmäßig auditieren
• Ausnahmen behandeln: Einen Prozess für Konten haben, die nicht automatisch in Vaults aufgenommen werden sollten
• Konfiguration dokumentieren: Dokumentation von Workflows und Klassifizierungsregeln pflegen

Verwandte Themen

• Übersicht - Automatisierungsarchitektur und -konzepte
• Workflows - Workflows erstellen und verwalten
• Trigger - Verfügbare Triggertypen und Variablen
• Klassifizierungsregeln - Kontoklassifizierungskonfiguration
• CyberArk Integration - CyberArk PAM-Integrationseinrichtung
• BeyondTrust Integration - BeyondTrust PAM-Integrationseinrichtung
• Anmeldeinformationen - Anmeldeinformationen für PAM-Systeme verwalten
• Webhooks verwenden - Alternativer Integrationsansatz für benutzerdefinierte PAM-Systeme