CyberArk PAM-DEF cheat sheet

The Vault stores privileged account credentials encrypted; safes are the container that holds accounts, and safe membership plus safe-level permissions determine who can retrieve or use a password.

A master policy governs platform behavior across all safes; an exception can override specific master policy settings for an individual safe.

Dual control (confirmation) requires a second authorized user to approve a retrieval or connection before the CPM releases the credential.

One-time passwords: a platform can be configured to change the password immediately after each retrieval, so the retrieved value expires after a single use.

CPM (Central Policy Manager) rotates passwords on a schedule defined per platform; the platform's 'change' and 'verify' settings determine rotation and validation behavior.

PSM (Privileged Session Manager) proxies connections so the user never sees the target credential; session recordings and keystroke logs are stored for audit.

PSM connection components map a client protocol (RDP, SSH, database) to the target; the PSM Gateway provides access without exposing target hosts directly.

Account onboarding: accounts can be added manually, discovered by an automatic discovery scan, or pushed from an external source; onboarding requires a platform and a safe.

Least privilege: safe permissions are granted per user or group; 'use' permission allows connecting through PSM, while 'retrieve' allows viewing the password.

Authentication to the Vault can use CyberArk passwords, LDAP/AD, RADIUS, SAML, or PKI certificates; each method is configured as an authentication method mapped to directory users.

Directory mapping links an LDAP/AD group to a Vault group; users in the mapped directory group inherit the Vault group's safe permissions.

Vault users are either local users or directory users; only local users have credentials stored in the Vault, directory users authenticate externally.

Authorization is enforced by safe membership plus permissions (use, retrieve, list, add, delete, manage) and by master policy; a user with no safe membership sees no accounts.

Roles separate duties: Vault Admin manages the system, Safe Admin manages safe contents, Auditor has read-only visibility, and CPM/PSM users are service accounts.

MFA can be layered on top of primary authentication; the second factor is required before the session token is issued.

Session tokens have a configurable idle timeout and maximum lifetime; exceeding either forces re-authentication.

The Vault audit log records every authentication, authorization decision, and privileged action; auditors can query it without access to credentials.

Groups are preferred over individual grants: permissions assigned to a group propagate to all members and simplify revocation.

EPM (Endpoint Privilege Manager) enforces least privilege on Windows and macOS endpoints by removing local admin rights and elevating only approved applications.

A policy targets endpoints via a computer group; the policy contains rules that match an application by hash, path, publisher certificate, or file name.

Elevation methods: 'elevate' runs the application with admin rights, 'block' denies execution, and 'deny' with a notification informs the user why.

Application matching by hash is the strongest rule; matching by path or file name is weaker and can be bypassed if the file is replaced.

Just-in-time elevation grants temporary admin rights for a defined window rather than permanent local admin membership.

EPM agents report to the EPM server; policy changes are distributed to agents on the next policy refresh interval.

Audit-only (monitor) mode records attempted elevations without enforcing them, allowing a baseline before enforcement.

File hash rules must be updated when the application is patched, because a new binary produces a new hash.

Endpoint policies can include application control (allow/deny lists) in addition to privilege elevation rules.

Secrets Management (Conjur/Secrets Manager) stores secrets such as API keys, tokens, and certificates, distinct from interactive privileged account passwords in the Vault.

Applications authenticate to Secrets Manager using a host identity (for example, an API key or a workload identity) rather than a human user.

Access to a secret is granted by a policy that defines a role and permits the role to read the variable; the policy is versioned and applied declaratively.

Secrets are referenced by a variable path; an application fetches the secret at runtime instead of embedding it in code or config files.

Secret rotation can be automated; rotating a secret updates the stored value and invalidates the previous value for consumers.

Dynamic secrets are generated on demand with a limited lifetime and are revoked automatically, reducing the window of exposure.

Layered policy: a policy can include other policies, and permissions cascade from the layer to its members.

The principle of least privilege applies to hosts as well as users: each application identity should read only the variables it needs.

Audit records every secret retrieval, identifying the requesting host identity and the variable path.