Previous PDF

swipe to navigate

What business problems does Hitachi ID Privileged Access Manager address?

It can be difficult to securely manage access to thousands of privileged accounts. Consequently, in many organizations, the passwords to privileged accounts are:

  • known to many people, possibly including former staff,
  • often the same on many systems,
  • rarely if ever changed and
  • stored in plaintext, by people and by applications.

There are serious consequences to these password management practices, including:

  • There is no accountability for use of shared, privileged accounts. This is both a security / regulatory compliance problem and a problem with diagnosing operational problems.
  • Former staff may retain sensitive access.
  • Attackers have an easier time compromising these dangerous accounts.
  • If one system is compromised (e.g., an IT user's PC or an application server), the attacker can leverage passwords stored or typed on that system to compromise additional systems.

How does Privileged Access Manager work?

There are several technological approaches to more securely managing privileged passwords:




Eliminate shared passwords entirely and assign personal administrator-level accounts to each IT user, on each asset.

Individual accountability for configuration changes.

Too many administrator-level accounts on each system.

Create and delete personal administrator-level accounts for users on demand.

Individual accountability for configuration changes.

Complex integration between many systems and the corporate directory.

Modify operating systems and applications to check whether users are allowed to perform privileged actions, in real time. Manage access control policies centrally.

Fine-grained control over user access.

Too many administrator-level accounts on each system plus complex change control on each system.

Use software installed on each device to periodically change local passwords. Send a copy of these passwords to a secure vault, shared by many systems.

Works even in complex, segmented networks.

Requires software on each managed system.

Software on a central system periodically pushes new passwords to each device and keeps copies in a secure vault.

Minimal footprint on managed systems.

Requires connectivity from a central application to managed systems.

How often does Privileged Access Manager change passwords?

This is configurable, with the default being every 24 hours.

Privileged Access Manager secures sensitive passwords by periodically setting them to new, random values:

  1. On systems integrated via "push mode:"
    1. Periodically -- for example, every night between 3AM and 4AM.
    2. When users check accounts back in, after they are finished using them.
    3. When users request a specific password value.
    4. In the event of an urgent termination of a system administrator (randomize all passwords that person may have known).
    Note that "push mode" normally means that no software is deployed to the managed endpoint system.

  2. On systems integrated via "pull mode:"
    1. Periodically -- for example, every day.
    2. At a random time-of-day, to even out workload on the Privileged Access Manager service.
    3. Opportunistically, whenever network connectivity happens to be available from the managed endpoint to the central privileged access system.
    Note that "pull mode" implies a local agent on the managed endpoint system. This approach is useful on laptops, on rapidly provisioned/deprovisioned VMs in a cloud environment and in some isolated network segments.

How do we control who can sign into which privileged accounts?

The simplest form of access control in 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 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.

How do we grant someone temporary or one-time access to a privileged account?

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).

Can we configure a "two keys to launch" scenario for super-sensitive systems?

Privileged Access Manager supports approval of change requests by multiple business stake-holders and/or by multiple groups of business stake-holders. This allows for typical scenarios such as "approve this request by recipient's manager plus departmental IT contact plus application owner."

Since individuals may be unavailable to respond to a request, authorization can substitute groups for single approvers. Thus, the above example may be reformulated as "approve this request by recipient's manager or any of the manager's peers; plus either of two departmental IT contacts; plus any of three designated security contacts for the indicated application."

Change authorization is normally conducted by sending invitations to all authorizers at the same time. This "parallel" invitation process yields faster approval turn-around times but has no impact on security, since all requisite approvers must respond before a request is completed. Sequential invitations are also possible but are not recommended by Hitachi ID Systems due to the longer total time elapsed before all participants will approve or deny a request.

Previous Next PDF