In any IT environment, access control is a fundamental security principle that defines who can access privileged resources, under what conditions, and to what extent, ensuring only authorized users can access, modify, or manage critical resources while restricting unconditional access. The absence of a well-defined password access control workflow creates significant vulnerabilities, including unlimited access to privileged accounts, leading to system compromises and financial loss.
PAM360's Access Control Workflow mechanism mitigates these risks by implementing a approval mechanism to grant access to privileged accounts to the users. This mechanism ensures that only authorized users can access privileged credentials through a structured workflow, reducing the risks of unauthorized access, insider threats, and credential misuse. This structured approach safeguards access to privileged resources and minimizes security vulnerabilities, ensuring access is granted only when necessary and under defined conditions.
This document covers the following topics in detail:
The table below outlines the various terminologies used to represent the different stages in the password access control workflow, along with a brief description of each stage, helping the users accurately interpret the status of password access requests. These stages reflect the status and progression of password access requests as they move through the approval, usage, and completion phases.
| User | Keywords/Actions | Description |
|---|---|---|
Administrator | Approve | To approve the user's request to access the password |
Reject | To deny the user's request to access the password | |
Yet To Use | Indicates that the user has received approval from the authorized administrators but has not yet checked out the password from the vault | |
In Use | Indicates that the user has checked out the password and Is currently using it | |
Modify | To update the password access request raised by the user | |
Check In | To revoke user's access to the password | |
End-User | Request | To request exclusive access to the password |
Waiting for Approval | The request to access the password is awaiting approval from the administrators | |
Check Out | To check out the password from the vault | |
Check In | To check-in the password back into the vault | |
Cancel | To cancel the raised password access request |
By default, users with the Privileged Administrator, Administrator, Password Administrator and Cloud Administrator user roles can configure and manage the access control workflow by defining the scope and limitations of password access. Apart from these predefined roles, you can also create a custom role with the following privileges enabled to configure or manage access control workflow in PAM360:
Once the access control workflow is configured for the privileged resource/account, the end users requiring access to the privileged password should follow the access control workflow to gain exclusive access. The access control workflow in PAM360 ensures that access to privileged passwords is controlled and granted only through an approval-based process as follows:
Additional Detail
Starting from build 8400, access requests follow a time-bound model with defined approval windows. Earlier, granted access for Now case remained open indefinitely until the user manually checked in the password or an administrator force-checked it in.
This workflow ensures secure, time-bound access while preventing unauthorized use of privileged passwords.
Caution
The access control workflow does not override the password ownership and sharing mechanism of PAM360. It is an enhanced mechanism that improves security. Users can directly view shared passwords and initiate remote sessions from the PAM360 interface when access control is not configured. With the password access control mechanism, the user should follow the request-release workflow to access the password, even if it is shared with them.
In PAM360, the access control workflow can be configured at both the account and resource levels, offering the flexibility to configure different access control mechanisms for user accounts within the same resource. Let us understand how precedence works when the access control workflow is configured at the account and resource level.
Consider PAM-Win10, a privileged resource within an organization with multiple accounts. When access control is enforced at the resource level, all the accounts within PAM-Win10 will inherit the same access control policies by default. However, if specific accounts require stricter security measures, access control can be enforced at the account level.
For instance, if the Administrator account within PAM-Win10 requires a higher level of security, such as approval from at least four administrators before granting access, the access control configuration can be enforced at the account level. This configuration will override the access control enforced at the resource level only for the Administrator account. However, all other accounts within PAM-Win10 will continue to follow the access control policies configured at the resource level.
The access control workflow in PAM360 currently presents a compatibility issue when operating on High Availability (HA) secondary servers. If the primary server goes offline, users cannot utilize the access control workflow to request password access. To solve this issue, administrators can use a temporary workaround to enable access control workflow on the secondary server. However, this requires careful tracking of approved requests during the downtime. Follow the steps detailed below to implement the workaround solution:
Once the primary server is restored, the automated password check-in process will not function efficiently for the passwords checked out from the secondary server during the downtime. To maintain security and compliance, administrators must manually review and check in any passwords checked out during downtime, ensuring all access requests are accounted for and preventing any unauthorized access. By following this workaround, administrators can maintain access control functionality on the secondary server when the primary server is down.