Pre-authorized Access

The simplest form of access control in Hitachi ID Privileged Access Manager is based on managed system policies (MSPs). MSPs link collections of managed systems and managed accounts to groups of users and operational policies.

Individual systems may either be attached to a policy explicitly (e.g., "attach system SYS0123 to policy MSP-A") or implicitly, using an expression such as "all systems of type Linux at 10.0.1.0/24 are attached to MSP-B". Expressions may be based on the operating system type, IP address, MAC address, system name or other metadata acquired from an inventory source.

Managed system policies are configured with operational and access control rules, including:

  1. Which accounts' passwords to randomize on attached systems, and how often.
  2. Which groups' membership may be temporarily granted to authorized users.
  3. How to compose random passwords (e.g., length, complexity, etc.).
  4. What actions to take after successful or failed attempts to disclose access.
  5. What access disclosure methods to offer authorized users -- e.g., launch a given type of client program with ID/password from the credential vault, display a password, copy buffer integration, temporary group membership or SSH trust, etc.

Privileged Access Manager users are likewise grouped, either explicitly or implicitly. Most commonly, users are assigned to Privileged Access Manager user classes through their membership in Active Directory or LDAP groups. User classes are then assigned specific rights with respect to specific managed system policies. For example, "every user in group A may launch RDP sessions to privileged accounts on systems in policy B."

Business rules, such as segregation of duties between different sets of users, can also be enforced. This is done by examining, managing and limiting group membership on reference systems, such as Active Directory or LDAP.

One-Time Access

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 access to privileged account PA on system S be made available to user UB at some later time T. UA may be the same person as UB (a self-service request).
  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, UA or UB's manager. 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 PA.
  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 still don't respond, Privileged Access Manager runs business logic to find replacements for them, effectively escalating the request. Privileged Access Manager will invite replacement authorizers next.
  7. Authorizers receive invitation e-mails, click on a URL embedded in the e-mail invitation, authenticate themselves to the Privileged Access Manager web portal, review the request and approve or deny it.
  8. If any authorizers deny the request, e-mails are sent to all participants (UA, UB and LA) and the request is terminated.
  9. If M authorizers approve the request, thank-you e-mails are sent to all participants. The e-mail sent to the recipient includes a URL to an access disclosure page.
  10. UB clicks on the e-mail URL and authenticates to Privileged Access Manager.
  11. UB clicks on a button in the web portal 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 (rarely allowed).
    2. Place a copy of the password in the operating system copy buffer (sometimes allowed).
    3. Launch an RDP, SSH, vSphere, SQL Studio or similar login session to PA on S (most common).

Flexible Workflow

The Privileged Access Manager workflow process is very customizable:

  1. Input fields can be specified via policy (reason, ticket number, etc.).
  2. The UI can be rebranded.
  3. Whether a given request is auto-approved is a matter of policy.
  4. Whether to auto-approve a given request may be defined within the Privileged Access Manager web UI at the managed system policy table (i.e,. "users matching these parameters are auto-approved to check out groups or accounts on systems attached to this MSP").
  5. Alternately, whether to auto-approve a given request may be a data-driven decision. For example, when checking out an AD account, look up its 'controlGroup' attribute (schema extension in this example) and see if the intended user is a member of that AD group. The same concept can be implemented without schema extensions -- for example, when checking out a given Linux account, search for that system/account in a policy table (a web UI is provided to edit such tables) until a match is found for that system/account (with wildcards).
  6. When someone's approval is required for a check-out, the process for selecting authorizers can similarly be defined either at the MSP level or via policy tables.
  7. The same pattern applies to data filters (i.e., which accounts/systems a given requester can see/select), access disclosure mechanisms (can passwords be displayed? Is only RDP/SSH/vSphere/etc. allowed?) and more.

Generally no organization-specific code is required for any of the above. Where policy decisions are needed, they are normally based on data lookups.


Read More: