At a high level, Privileged Access Management (PAM) means controlling who or what is allowed to access critical IT systems, applications, and workloads, when, and for how long. In regards application security, its an important difference worth noting that PAM focuses on administrative user (sysadmin, DB admin, user admin, etc.,) access to to IT applications, whereas the adjacent Identity as-a-Service (IDaaS) space focuses on regular end users’ access to business applications.
When initially deployed, computer systems and many business-critical applications and services create “superuser” accounts to help users manage them or allow one application or service to talk to another workload. These are highly privileged and in the wrong hands, facilitate data breaches. As a result of this power, they represent the “keys to the kingdom” and, not surprisingly, are the number one target for cyber-attackers.
PAM solutions help ensure that these privileged accounts are secured, and their access is tightly controlled. They permit only legitimate users to log in and run only approved commands and applications required for their job function, or workloads to access other workloads.
Analysts such as Gartner, Forrester, and KuppingerCole who review PAM vendor solutions and report annually on the PAM market, define the critical moving parts of PAM similarly:
Privileged Account and Session Management (PASM): Essentially, a secure vault to store and manage privileged account credentials (e.g., passwords and SSH keys) and generic secrets (e.g., IP addresses, API keys, AWS IAM credentials) and to facilitate user login to resources. The vault provides a GUI for human administrator access and a set of APIs for programmatic access by workloads in DevOps, as well as application-to-application password management (AAPM) scenarios.
For human users, the vault provides features such as password checkout and brokered login. The former reveals the password in situations where direct login is necessary for an emergency. The latter is more routine, where the vault creates a remote SSH or RDP session, injecting the vaulted credential without revealing it to the privileged user.
Management of static credentials can include rotation on a periodic schedule and out-of-sync reconciliation during specific events such as password check-in or remote session initiation. In addition to static credentials such as passwords, SSH keys, and arbitrary secrets, the vault can create ephemeral tokens such as OAuth2, to better secure AAPM scenarios where such tokens are obtained programmatically via API calls. In modern PAM deployments, a host-based client establishes a trust relationship with the vault to ensure only legitimate API-based access is permitted.
Privileged Access Compliance Auditing
This allows organizations to continuously report on who has access to what, and who did what. Privileged sessions can be monitored and recorded for subsequent visual audit or incident response investigation. This can be done at the vault proxy for all sessions initiated through the vault, or at the host level for more granular auditing and to ensure privileged sessions are audited even if the vault is circumvented.
Privilege Elevation and Delegation Management (PEDM)
PAM software (an agent or client) residing on the host system governs log in and authorization via privilege elevation. This relies on a “least privilege” model, whereby administrators are not given access to shared superuser accounts (these are vaulted or deleted during identity consolidation to contribute to a zero standing privileges posture). Instead, users log in with their low-privilege account, which provides full accountability and, if compromised, limits access, and lateral movement.
During login, the PAM client will validate the user-supplied login credentials against an enterprise directory (e.g., Active Directory or LDAP), optionally applying multi-factor authentication (MFA) to further assure the user’s identity. It then applies PAM roles and policies to determine whether the user is entitled to log in to that resource. Once logged in with minimum rights, the user can elevate privileges to run administrative commands and applications by requesting access. If this “just-in-time” access request is approved, only the rights necessary for the task are provisioned for a limited time, after which they are automatically deprovisioned to avoid standing privileges.
Privileged Identity and Access Management: This focuses on managing how users, applications, and services access systems, as well as other applications and services. Reducing the proliferation of static, privileged local accounts through identity consolidation will reduce an organization’s attack surface. This is not only a security best practice, but it’s also becoming routine in many regulations such as PCI-DSS and NIST SP 800-63. Such accounts are ideally eliminated or vaulted for emergency use only, presenting threat actors with a smaller target. Unique per-user identities (e.g., Active Directory IDs) coupled with privilege elevation (see definition on this page) now provide full accountability and enable a least-privilege access control model for better security and reduced risk.
As organizations engage in digital transformation projects (e.g., cloud migration), the number of applications and services is growing exponentially, as are local privileged accounts used for application-to-application and service-to-service interactions. These, too, can be consolidated, migrating them to — for example — Active Directory or better still, replacing them with short-lived tokens such as OAuth2 obtained programmatically from the vault.