Workflow Requests and Approvals
In many organizations, there are many IT workers who have the
right skills to manage a wide range of systems, but whose normal
responsibility is narrow. These people should not and normally
do not have administrative access to systems outside their normal scope
Using Hitachi ID Privileged Access Manager, this pool of talent can be leveraged when needed --
during periods of high workload or in emergencies -- without having
to grant large numbers of users permanent access to systems.
- Privileged Access Manager ensures that every administrator account
has a unique, frequently changing password:
- Sensitive passwords cannot be shared, since they are always
- It is possible to give out passwords for a limited time,
since administrative access will naturally expire.
- Privileged Access Manager controls access disclosure using a variety
of mechanisms, including a workflow engine that supports granting
temporary or exceptional access:
- Business logic restricts which passwords can be requested.
- Authorization logic routes requests to application owners.
- Business users can authorize one-time access disclosure to
Some examples of this flexibility are common in specific industries:
- Universities and Colleges: computer science students can
be asked to help with IT tasks.
- IT Outsourcers: one customer's support team can be asked
to help with another customer's systems.
- In general: developers can provide assistance with
Workflow Engine to Authorize Privileged 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:
- 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).
- Privileged Access Manager looks up authorizers associated with LA on S.
- 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.
- Privileged Access Manager sends e-mail invitations to authorizers LA.
- If authorizers fail to respond, they get automatic reminder e-mails.
- 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.
- 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.
- If any authorizers deny the request, e-mails are sent
to all participants (UA, UB and LA) and the request is terminated.
- 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.
- UB clicks on the e-mail URL and authenticates to Privileged Access Manager.
- UB clicks on a button in the web portal to check-out privileged access.
- UB then may click on a button to do one of the following (the options
available will vary based on policy):
- Display the password (rarely allowed).
- Place a copy of the password in the operating system copy buffer (sometimes allowed).
- Launch an RDP, SSH, vSphere, SQL Studio or similar login session to
PA on S (most common).
- Network Architecture:
How user PCs, servers, network devices, multiple, replicated Privileged Access Manager nodes and other elements interact on the network.
- Replicated Credential Vault:
Replicated storage of passwords to privileged accounts in multiple, physically distant, encrypted vaults.
- Included Connectors:
Systems on which Privileged Access Manager can discover accounts, randomize passwords and launch login sessions.
- Infrastructure Auto-discovery:
Automatically finding and classifying workstations, servers, applications and network devices as well as privileged accounts and services on each one.
- Non-target integrations:
Integrations between Privileged Access Manager and IT infrastructure where it may not be managing passwords or privileged access -- such as e-mail systems, incident management applications and more.
- Workflow Requests and Approvals:
Enabling users to request and approve one-off access to sensitive accounts.
- Concurrent Access to Accounts:
Limiting how many administrators can simultaneously manage a system and keeping administrators informed of one-anothers activity.
- Single Sign-on Mechanisms:
Options for connecting users to privileged accounts, through credential injection, trust manipulation and temporary group membership, all without displaying passwords from the vault.
- Server requirements:
Sizing, configuration and number of servers on which to deploy Privileged Access Manager.
Scaling to manage passwords across millions of devices.
- Emergency access:
Access to Privileged Accounts During Emergencies.
- Language Support:
A list of languages supported in the web portal.