With security a top focus of every enterprise, more organizations are employing Privileged Access Management (PAM) solutions. PAM solutions eliminate the need for hard-coded application credentials embedded in applications, scripts, or configuration files, and allow highly sensitive passwords to be centrally stored, logged, and managed within the Vault. This unique approach enables organizations to comply with internal and regulatory compliance requirements of periodic password replacement, and monitor and audit privileged access across all systems, databases, and applications. PAM solutions help provide secure privileged access to critical assets like database and hosts by centrally managing account passwords and provide access rules for both privileged and non-privileged accounts to control who can use those accounts to log on to your assets. For Enterprise Manager (EM) customers that use PAM providers like CyberArk, Centrify, HashiCorp, Oracle Key Vault, etc... we have an extensible EM credential framework that is integrated with them. The integration enables database management, database patching, and running host commands in accordance with security compliance policies.
This blog details EM integration with PAM providers so customers can use it to automate and further secure databases within their enterprise. Many features of EM are available with secure password access from PAM and protect against compromised credentials and breaches.
A PAM solution is used to mitigate the risk of privileged access. In other words, privileged access includes accounts, credentials, and operations that require an elevated level of access. PAM solutions are used by people who administer or configure IT Infrastructure. A PAM solution can be deployed as on-premises software, Software-as-a-Service, or a hardware appliance.
There are multiple PAM providers available in the market for customers. Popular providers include CyberArk, Delinea, Arcon, BeyondTrust, HashiCorp, and Wallix.
Let’s look at the goals for EM to integrate with different PAM providers in the market.
There are multiple PAM providers in the market that provide flexibility for multiple PAM solutions and versions. EM PAM integration aims to accomplish the following:
The PAM integration with EM13.5 is part of Release Update14 (RU14). For PAM integration with EM13.5 version, apply RU14 or up on OMS and start with the integration process.
The diagram below depicts how EM interacts with PAM to retrieve the credentials for the database or host from an external store to carry out functionalities in EM such as executing jobs on the host or database and database patching using Fleet Maintenance.
We have an EM setup (OMS and Repository) that is monitoring and managing targets and there is a central PAM solution like CyberArk or HashiCorp etc. that are managing the password lifecycle for databases and hosts. The PAM solution manages the password rotations and maintains privileged access to databases and host credentials.
When using the PAM integration, EM retrieves database and host credentials that are now stored in the external PAM store. To accomplish this, the user writes the integration script that will be registered in EM with all the PAM attributes. When EM requires the database or hosts credentials for use in workflows like database patching or running jobs, the credential framework interacts with the external PAM provider and retrieves the password for the database or hosts, and passes that credential object to the underlying workflows.
PAM integration with EM consists of three simple steps for all PAM providers.
Before we get into the PAM integration procedure with EM, there are some pre-requisite steps that are expected from the users to successfully register the PAM solution with EM. In this integration process, defining the administrator’s roles and responsibilities is very important. We have two types of administrators:
As part of the initial pre-requisite step, a PAM integration script is required. To write a script, work with your Security PAM administrator to develop a script for the PAM solution. Scripts can be written in Shell or Perl language. MOS note for sample reference PAM script 2907588.1
The shared ownership of the PAM integration solution with EM is depicted below.
Let’s review the procedure steps in detail.
This is an important step in integrating PAM with EM since the customer needs to write the script based on the PAM provider in their organization. The script accesses the PAM using the API or CLI calls of their PAM provider to fetch the credentials for databases or hosts at runtime that it internally manages.
Register the PAM provider with EM: There is a new emcli verb to register the PAM script in EM. The emcli verb is ‘emcli config_cred_provider’. This verb allows the credential provider to be configured with the required attributes.
Once the script is registered the next step is to map credentials with EM credentials attributes. The attributes of the credential provider information may not match the names in the credential type. For example, the DBCredType has attributes called DBUserName, DBPassword. However, the PAM solution may provide these attributes as named user and password. Map the attributes received from the credential provider to the attributes required by the credential type.
Credentials mappings map the keys in the script output (user and password in this example) to credential attributes like HostUserName and HostPassword. Store an attribute mapping to convert stored attributes to those required by credential type.
Below is the new emcli verb to store the credential mapping.
Reference the example below for Host and Database credential mapping.
This is the final step in the PAM integration process. Creating or modifying named credentials workflow specifies that the credential contents are stored externally (PAM) and should be accessed through a credential provider. At this point, the user can create new named credentials for PAM in EM or they can modify existing named credentials for the host or database to use the external PAM store instead of fetching it from the EM repository. Let’s review the emcli options to create named credentials and modify named credentials.
Create Named Credentials:
Modify Named Credentials
Like create_named_cred verb the modify_named_credential verb also takes the additional parameters: alt_cred_storage, cred_provider, cred_key, cred_mapping.
The following example modifies the named credential ‘FinHost’ based on the SSH key named credentials for host ‘myhost.example.com’. The command indicates that the credential attributes are stored in the PAM solutions like (CyberArk or HashiCorp etc.) at the location emssh1 and that the mapping named ‘PAMHCreds’ can map the attributes required for the ‘HostSSHCreds’ credential type.
At the completion of these steps, the PAM solution is registered with EM and either a new credential or a modified existing named credential is set up to use the external storage type for performing activities in EM such as Database Patching and Jobs execution.
PAM integration with EM provides a key benefit for Database Lifecycle Management capabilities, in particular, database patching with Fleet Maintenance. This integration enables the use of secure credentials stored in PAM to be used during database patching workflow.
Privileged accounts are one of the most important assets for organizations to protect. Without a comprehensive Privileged Access Management program, the risk of misuse from internal or external bad actors is significantly increased. Integrating the PAM solutions with EM sets the organizations on the right track to fully manage their privileged accounts for databases, hosts, or applications in a manner compliant with their security and compliance policies.