Hitachi ID Systems makes available to all customers and partners a series of "reference implementations" of Hitachi ID Privileged Access Manager. Among these is a reference implementation of Privileged Access Manager designed to automate the basic processes of controlling access to privileged accounts across a variety of systems.
The Privileged Access Manager reference implementation uses policy tables to answer a series of access control questions:
- Should a user be able to see a managed account on a managed system in search results?
- Should a request for check-out be flagged as high risk or unusual?
- If a user requests access to a managed account, should this request be automatically approved or should it depend on approval by others? If approval is required, by whom?
- Once a user has checked out a managed account, what disclosure mechanisms should be made available? Launch RDP? SSH? Another command-line program? Inject credentials into an HTML login form? Display the password? Place it in the copy buffer?
- If an administrative tool is launched on behalf of a user, should the login session be recorded? If so, what data streams should be enabled (keylogging, screen capture, etc.)?
Each of these decisions is made by comparing search results or an access request to a series of policy rules. A distinct policy table is used to make each decision. The policy tables are system wide, eliminating much duplication in policy definitions.
In general, all policies match requests against the same criteria:
- The type of request -- single account, group set or account set.
- The login ID of the account being requested, if any.
- The hostname or IP address of the managed system.
- The type of managed system (which connector is used).
- The primary managed system policy to which the managed system and account, group set or account set belong.
- The requester and recipient -- via membership in user classes or membership in groups on a reference directory.
- The value of a request attribute, which may be compared to attributes of the requested system or account.
- IP address of the recipient's point of origin, via CIDR subnet matching.
- The time of the request, as compared to a defined interval.
Once a request matches a rule, how to respond to it is determined by policy-table-specific settings, regarding visibility, approval, disclosure mechanisms, recordings, risk scores, etc.
Figure (_label_fig:screenshot-pam-refbuild-authmod-rule) shows a sample policy rule. This one is from the authorization table and essentially states that users in the UNIXADMINS user class are auto-approved for access to systems where integration is via SSH and the system in question is attached to the UNIX policy.
Separately from this, the Privileged Access Manager reference implementation incorporates a standard process to review discovered Windows services and service accounts and, for each, indicate:
- Whether the service should be managed.
- When service account passwords should be randomized (daily, weekly, ...).
- Whether services should be restarted after a password change.
- Whether new passwords should be injected into services before and/or after a password change.
- Who to notify of password changes and faults (i.e., app owners).
The Privileged Access Manager reference implementation is very much a work in progress,
with significant evolution from release to release. That said, it has
already been used successfully in significant production implementations
of Privileged Access Manager, primarily in large financial institutions.