1.1 CyberArk PAS Core Architecture & Component Topology

1.1 CyberArk PAS Core Architecture & Component Topology

Quick Answer: The CyberArk Privileged Access Security (PAS) solution is anchored by the Digital Vault (PrivateArk Server), an isolated, hardened repository listening on TCP port 1858. All core satellite components—Password Vault Web Access (PVWA), Central Policy Manager (CPM), Privileged Session Manager (PSM), PSM for SSH (PSMP), and Application Access Manager (AAM)—function as clients that initiate outbound, encrypted, mutually authenticated connections to the Vault. The Vault operates strictly as a passive server and never initiates outbound network connections to PAM components.

---

The Digital Vault: The Hardened Security Kernel

At the core of the CyberArk PAS suite is the Digital Vault (internally designated as the PrivateArk Server). Unlike general-purpose databases or directory servers, the Vault is engineered as an isolated, single-purpose security appliance designed to store, manage, and audit privileged credentials, encryption keys, and digital assets.

The Vault architecture separates responsibilities into two internal tiers:

1. Vault Database Engine: A customized, hardened embedded relational database (derived from MySQL/MariaDB) storing administrative metadata, access control lists (ACLs), user entitlements, policy parameters, and tamper-evident audit trails. The database engine is completely shielded from direct network exposure; external clients cannot connect directly to SQL ports.
2. Vault Storage (Safes): File-system repositories on NTFS storage volumes where encrypted object payloads (password objects, cryptographic keys, and session recording metadata) are persisted within logical partitions called Safes.

The PrivateArk Server Service runs in the background to arbitrate all read, write, and search requests. When a component requests an account credential, the service enforces granular Safe permissions, validates dual-control authorizations, retrieves the encrypted payload from disk, decrypts the object in volatile, non-pageable memory, and transmits the plaintext secret across the encrypted network session.

A foundational architectural principle tested on the PAM-DEF exam is the passive listener model: the Vault listens exclusively on TCP port 1858. It maintains no inbound listeners for HTTP, HTTPS, SSH, SMB, or RPC, and never initiates network connections to PAM components. All communication flows inbound to the Vault, shielding the central repository behind rigid perimeter firewall rules.

---

PAS Satellite Components Overview

The CyberArk PAS ecosystem deploys specialized satellite components to deliver web access, policy enforcement, session isolation, programmatic access, and behavioral analytics.

1. Password Vault Web Access (PVWA)

• Role: Primary administrative portal and end-user interface built on Microsoft Internet Information Services (IIS) and ASP.NET. Provides both a responsive web interface and a full REST API endpoint.
• Functionality: Used to manage Safes, onboard accounts, configure platform policies, review discovery results, check out one-time passwords, and launch privileged sessions.
• Vault Connectivity: Connects over TCP port 1858 using the Vault API. Utilizes dedicated service identities—PVWAAppUser (application queries) and PVWAGWUser (user authentication pass-through)—with secrets secured in machine-bound credential files (.cred).

2. Central Policy Manager (CPM)

• Role: Asynchronous automated credential lifecycle engine running as Windows services (CyberArk Password Manager and CyberArk Central Policy Manager Scanner).
• Functionality: Executes periodic credential verification (confirming Vault passwords match target endpoints), password changes (generating random passwords per policy and updating both target and Vault), and password reconciliation (using administrative accounts to reset out-of-sync credentials).
• Target Connectivity: Connects directly to targets via native protocols (Windows SMB/RPC ports 445/135, Unix SSH port 22, databases via SQL ports, and cloud APIs via HTTPS 443).
• Vault Connectivity: Queries the Vault over TCP port 1858 to identify scheduled tasks; maintains no inbound listening ports.

3. Privileged Session Manager (PSM)

• Role: Jump-server proxy installed on Windows Server with Remote Desktop Services (RDS), hardened by CyberArk scripts.
• Functionality: Isolates end-user workstations from target systems. Users establish an RDP connection (TCP 3389) to the PSM server. PSM retrieves the target credential from the Vault over TCP 1858, injects it directly into the target client process (mstsc.exe, putty.exe, web consoles) without revealing it to the user, and proxies the target session.
• Auditing: Records full GUI video, text keystrokes, process invocations, and SQL queries into the PSMRecordings Safe.

4. Privileged Session Manager for SSH (PSMP)

• Role: Hardened Linux proxy (RHEL/Rocky Linux) delivering native command-line session isolation for Unix environments.
• Functionality: Users connect via standard SSH (ssh vaultuser@targetuser#targethost@psmserver). PSMP authenticates the user, retrieves credentials from the Vault over TCP 1858, enforces command whitelisting/blacklisting, logs keystrokes, and proxies the SSH stream to the target.

5. Application Access Manager (AAM)

• Role: Programmatic secrets management eliminating hardcoded credentials in applications, scripts, and CI/CD pipelines.
• Deployment Models: Credential Provider (CP) installs on application servers with a local encrypted in-memory cache for sub-millisecond retrieval and offline resilience. Central Credential Provider (CCP) provides an agentless REST API on IIS. Both retrieve secrets from the Vault over TCP 1858.

6. Privileged Threat Analytics (PTA)

• Role: Specialized Linux appliance delivering behavioral anomaly detection.
• Functionality: Analyzes audit logs and network telemetry to detect credential theft (Golden Ticket, Overpass-the-Hash), abnormal access times, and risky session commands. Ingests Vault audit logs via Syslog (UDP/TCP 514 or TLS 6514).

---

Vault Communication Protocol & The Pull Architecture

Understanding component interaction with the Vault is essential for the PAM-DEF exam:

The Asynchronous Pull Model in Practice

To preserve Vault isolation, the PAS architecture uses a pull-based dispatch model rather than an event-driven push model:

1. CPM Task Polling: The CPM service wakes up at configured intervals (in platform and basic_ini settings, typically every 10–60 seconds) and queries the Vault over TCP 1858 for accounts flagged for Change, Verify, or Reconcile in its assigned Safes.
2. Task Execution: When tasks exist, CPM locks the accounts, executes the password operation on the remote target, updates the credential in the Vault over TCP 1858, and releases the lock.
3. Session Initiation: When a user initiates a PSM session via PVWA, PVWA creates an ephemeral session ticket in the Vault. The user launches an RDP session to PSM (TCP 3389). PSM contacts the Vault over TCP 1858 to validate the ticket and retrieve the injection credentials.

This pull topology ensures the Vault requires zero inbound network routes into application subnets or DMZs, minimizing the attack surface across the PAM environment.