Security One-off Access Requests
Hitachi ID Facebook Page Hitachi ID Twitter Page Find us on Google+ Hitachi ID YouTube Page

One-off Access Requests - Hitachi ID Privileged Access Manager

Overview of workflow in Hitachi ID Privileged Access Manager

Privileged Access Manager includes the same authorization workflow engine as is used in Hitachi ID Identity Manager. Workflow enables users to request access to a privileged account that was not previously or permanently authorized. When this happens, one or more additional users are invited (via e-mail or SMS) to review and approve the request. Approved requests trigger a message to the request's recipient, including a URL to Privileged Access Manager where he or she can re-authenticate and "check out" access.

The workflow process is illustrated by the following series of steps:

  1. User UA signs in and requests that the then-current password to login account LA on system S be made available to user UB at some later time T. UA may or may not be the same person as UB.
  2. Privileged Access Manager looks up authorizers associated with LA on S.
  3. Privileged Access Manager may run business logic to supplement this authorizer list, for example with someone in the management chain for UA or UB. The final list of authorizers is LA. There are N authorizers but approval by just M (M <= N) is sufficient to disclose the password to AZ.
  4. Privileged Access Manager sends e-mail invitations to authorizers LA.
  5. If authorizers fail to respond, they get automatic reminder e-mails.
  6. If authorizers continue to fail to respond, Privileged Access Manager runs business logic to find replacements for them, effectively escalating the request and invites the replacement authorizers as well.
  7. Authorizers receive invitation e-mails, click on a URL embedded in the e-mail invitation, authenticate themselves to the Privileged Access Manager web login page, review the request and approve or reject it.
  8. If any authorizers reject the request, e-mails are sent to all participants (UA, UB and AZ) and the request is terminated.
  9. If M authorizers approve the request, thank-you e-mails are sent to all participants. A special e-mail is sent to the recipient -- UB with a URL to an access disclosure page.
  10. UB clicks on the e-mail URL and authenticates to Privileged Access Manager and displays the password.
  11. UB clicks on a button to "check-out privileged access."
  12. UB then may click on a button to do one of the following (the options available will vary based on policy):
    1. Display the password.
    2. Place a copy of the password in the operating system copy buffer.
    3. Launch an RDP, SSH, vSphere or similar remote control session to the server in question.

    In other words, display of a sensitive password is not a mandatory or even recommended part of the solution.

Turning human authorizers into reliable participants

The built-in workflow engine is designed to get quick and reliable feedback from groups of business users, who may be individually unreliable. It supports:

Scenarios for use of workflow

In a typical Privileged Access Manager deployment, two different kinds of workflow requests are used. To understand why, one first has to consider that there are two styles of access disclosure:

  1. Some users are pre-authorized to gain access to a set of privileged accounts. This is typically done by placing users into Active Directory or LDAP groups and configuring Privileged Access Manager such that users who are members of specific AD or LDAP groups are automatically granted the right to access privileged accounts on managed systems attached to a given managed system policy.

    When these users need to access a privileged account, they just sign into Privileged Access Manager and checkout a session into the account they need -- no further authorization is required.

    An illustrative example: users in the AD group NYC_WINDOWS_SERVER_ADMINS can sign into Privileged Access Manager with their AD ID and password and launch an RDP session as Administrator on any of the Windows servers in the New York data center without waiting for approvals.

  2. Other users have no pre-assigned rights to access privileged accounts, but may require occasional access, subject to one-off approval.

    An illustrative example: a developer who will assist with a production migration can request access to root on a Linux server LAX_ECOM_A tomorrow between 11PM and 3AM. Since he is not pre-authorized, the developer must wait for this request to be approved by the e-Commerce server's owner before he can start a session and in any case the session must start on or after 11PM and will be terminated on or before 3AM.

The scenarios above raise the question: how did users get placed in pre-authorized groups in the first place? This question leads to two types of workflow requests:

  1. The first type of workflow request is to place users into pre-authorized groups, typically on AD or LDAP. These requests are handled by complementary Hitachi ID Systems modules, included with Privileged Access Manager at no cost:

    1. Hitachi ID Group Manager allows users to request membership in pre-authorized AD or LDAP groups, subject to validation and authorization business processes.
    2. Hitachi ID Access Certifier can be configured to periodically invite group owners to review lists of pre-authorized users and remove those who no longer have a legitimate business need for that access.

  2. The second type of workflow request is to authorize a single session to use a privileged account. This is handled directly by the Privileged Access Manager workflow process.

Both types of workflow request are accessed using the same web portal, login credentials, etc. Both support multiple authorizers, automated reminders, escalation, delegation, etc.