Hitachi ID Privileged Access Manager offers multiple options for connecting authorized users to login sessions on managed systems, using managed accounts. Organizations should carefully consider which options suit them best and combine policy with infrastructure to provide the most appropriate methods to each user, in each context.
Privileged Access Manager supports five basic methods to disclose access:
- Password disclosure: Give the authorized user the password for a managed account, either through display or copy buffer integration.
- Direct connection: Launch the desired administration program on the user's PC and inject credentials into that program, so that it automatically signs into the managed account on the managed system.
- Proxy connection: Connect the user through an intermediate, proxy server, which in turn runs an administration program and signs into the managed system and account.
- Privilege elevation: Do not sign the user into the managed system at all. Instead, elevate the security rights of the user's personal, non-privileged account so that it can temporarily perform privileged functions on the managed system.
- Run commands: Privileged Access Manager signs into managed systems using managed credentials and executes commands on behalf of the user. It collects and displays results to the user.
Combinations of these methods are also possible, such as temporarily elevating the privileges of a personal, administrative (non-business) account.
Wherever possible, Hitachi ID Systems recommends:
- Do not disclose passwords. Other than when physically signing into the consoles of laptops, desktops and servers, there should be no reason to give a plaintext password to a human user.
- Connect users directly from their PC to managed accounts on managed systems, rather than using a proxy. This improves session performance for users and reduces bottlenecks. Direct connections also lower the total cost of the privileged access management infrastructure, as fewer proxies are required.
- Where launching administrative programs on behalf of users, support both IE/ActiveX and FF or Chrome with browser extensions. There is no material difference in the security posture of either approach -- both are just ways to launch programs on the user's desktop and (optionally) monitor user activity during the life of the session. Let users choose the method (and browser) that suits them best.
- Use proxies where there are connectivity problems or users connect from untrusted endpoints or locations. For example, use proxies to connect off-site vendors to on-premise systems or to connect on-premise or VPN-attached users to managed systems on isolated network segments. Where a proxy is used, leverage the HTML5 type of proxy where the connection is RDP or SSH, as it is less costly (no Windows OS license required) and makes fewer assumptions about the user's type of endpoint (just a browser). Use the Windows RDS proxy where other administrative programs are required -- SQL Management Studio, vSphere console, TOAD, etc.
- Use proxies to support users whose endpoint runs an OS other than Windows.
- Use privilege elevation only where user convenience demands it and where session monitoring is not required. Users can always bypass session monitoring if they are given a password or if the privileges of their own account are elevated.
Watch a Movie
Launch one-time session to a privileged account
- Once a session has been approved, the request's recipient can launch a login session to the privileged account.
- As with routine administrator access, Privileged Access Manager is normally configured to launch SSH, RDP and similar sessions rather than displaying a password value.
- Passwords are normally re-randomized when a session completes and access is "checked in."
- Checkout/checkin controls can limit the number of people connected to the same administrator ID at one time.
- Late users are shown the names of people already connected to the same account.