Getting started

(This topic addresses security administrators. For more information, see Roles-and-permissions.)

BMC AMI Security Privileged Access Manager is one of a suite of products that runs under the control of RSS.

Sometimes, application developers require elevated privileges, which are controlled by external security managers (ESM), like IBM Resource Access Control Facility (RACF), CA Access Control Facility 2 (ACF2), and CA Top Secret Security (TSS), to perform specific application or system changes. For certain critical or sensitive systems, having one or more users with permanent access privileges is a potential security risk.

Application developers who do not have system privileges on a permanent basis can use PAM to request a user ID that has elevated privileges when required. All PAM activity is fully audited and can be associated with change control requests.

You can configure multiple methods for accessing and grouping the temporary system privileges that application developers can request.

User IDs

You can create two types of user IDs in PAM:

  • Logon user ID—used to log on to PAM (two levels of users—users and managers)
  • Project user ID—user ID with elevated privileges to perform specific system changes

Application developers log on to PAM with their logon user IDs. To perform specific system changes, application developers must request and gain approval for a project user ID that is available in a PAM project to which they have access.

User levels

You can create logon user IDs that support the following levels of users:

  • User—permitted to receive and request permission to elevate their privileges to perform specific system actions.
  • Manager—permitted to authorize requests submitted by users.

User level is decided based on the privileges assigned to the logon user ID. These privileges are controlled by ESM security protections.

Important

By default, users can request and accept project user IDs only. Managers can approve and reject project user ID requests only.

Projects

You can add the user IDs that you create into a project, which are called project user IDs. Users can use these project user IDs with elevated privileges to perform system changes. You can create multiple projects in a single PAM instance for multiple requirements.

Access modes for both user ID pools and self-elevation are arranged in projects.

Example

You can define a project for a system programming activity, such as z/OS maintenance or CICS maintenance. You can associate multiple user IDs with the project and each ID can have different privileges.

You can then define another project with application-level maintenance activities and create a different set of user IDs and privileges for that project.

Users authorized to request access must also be authorized for the project. This allows for a high granularity in controlling the level of access users can request, and for what purpose.

Project modes

You can create the following modes of projects in PAM:

  • User ID pools
  • Self-elevation

You can use both modes in a single instance of PAM.

User ID pools

Users get access to a project user ID from a predefined pool. You create user IDs in the ESM database, each of which is assigned the necessary permissions to perform a specific system maintenance role.

IDs in the pool are kept in a revoked state, with an unknown password. When an authorized user wants to perform a controlled function, they receive access to the appropriate user ID from the pool and can set a temporary password. When the authorized user releases the ID or after a preconfigured time, the user ID permissions are revoked and the password is reset to an unknown value.

Self-elevation

Users and managers can have their logon user ID privileges temporarily elevated. You grant them membership to privileged resources (for example RACF groups), each having the necessary permissions to perform a specific system maintenance role.

After a preconfigured time, the privileges are revoked and the user ID is disconnected from the privileged resources.

Request modes

PAM operates in two request modes:

  • Automatic—users are automatically given access to the privileged user IDs without any further authorization.
  • Approval—users must wait until their request is approved by a manager.

Request mode is defined in the configuration parameters for each project. You can define a request mode according to the time, day, or week. For example, requests during office hours can be in Approval mode and requests outside of office hours can be in Automatic mode.

Self-managed projects

By default, managers cannot request project user IDs. But in certain cases, you might want to authorize managers to request project user IDs without allowing them to approve their own requests. You can authorize managers to request project user IDs by using one of the following methods:

Using the CSDATAField parameter

By using the CSDATAField parameter, you can link a project user ID to a manager-level logon user ID. A manager can thus request the project user ID linked to their logon user ID only. Managers requesting their linked project user ID cannot approve their own request (which must be approved by another manager who has access to the same project) but can approve all other user ID requests in the same project. This feature helps a project team manage its own project user ID requests. For more information, see CSDATAField.

To link a project user ID to a manager-level logon user ID, follow these steps:

  1. In the CSDATA segment of the user profile of manager-level logon user ID, create a CSDATA field and specify the project user ID that you want to link in the newly created CSDATA field.
  2. Specify the CSDATA field as the value for the CSDATAField parameter.
Example

Susan, an application developer in a team of programmers, wants to use a project user ID (available in a PAM project called System maintenance) that is linked to her manager-level logon user ID. To use her linked project user ID, she must request and gain approval from another manager who has access to the System maintenance project. Susan can use her logon user ID to approve the project user ID requests of other users in the System maintenance project, but not her own request.

Using the UniversalMode parameter

When you enable the UniversalMode parameter in a PAM project, you authorize managers with access to the project to request project user IDs. Managers with access to a UniversalMode enabled project cannot approve their own project user ID requests; another manager having access to the same project must accept the request.

Example

Emily is an application developer in a team of programmers, and has manager-level access to a PAM project called System configuration. To use a project user ID in the System configuration project, she must request and gain approval from another manager who has access to the same project. Emily can user her manager-level logon user ID to approve project user ID requests of other users in the System configuration project, but not her own request.

You can use the CSDATAField parameter in user pool mode projects only. You can use the UniversalMode parameter in both user pool and self-elevation mode projects. If you define CSDATAField and UniversalMode in the same user pool mode project, PAM considers CSDATAField only and ignores UniversalMode.

By using UniversalMode, managers can request any project user ID in a project that they have access. But by using CSDATAField, mangers can request the project user ID that is linked to their logon user ID only.

Where to go from here

If you are a system programmer and want to install and configure PAM, see the following topic branches:

To start using PAM to request and grant elevated privileges, see Using.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*