Approach

Hitachi ID Systems suggests the following approach for external access to on-premises systems (e.g., by vendors and similar users):

  1. Create either a separate directory or a container in the existing Active Directory, where accounts for vendor users will be kept.
  2. Create a sub-container and/or directory group to represent each vendor.
  3. Manage user accounts for vendor staff in each container. This can be done using Hitachi ID Identity Express: Partner Portal Edition, for example, where each vendor designates one or more people to manage just their own users.
  4. Authenticate vendor users individually, with a 2FA technology, such as Hitachi ID Mobile Access (scan a QR code via app followed by entering an AD password).
  5. Periodically invite someone within each vendor organization to review the list of their users with access to the hosting organization's systems (which is brokered by Hitachi ID Privileged Access Manager).
  6. Deploy a session proxy that vendor users will use to establish login sessions to managed systems. This could be either VDI (can be used to launch any admin tool) or an HTML web proxy (allows vendor users to access SSH and RDP sessions).
  7. Do not pre-authorize vendor users for any access. i.e., they can request access, but all requests must be manually approved.
  8. Record all activity in sessions initiated by vendor users -- keylogging, screen capture, etc. -- to create a detailed audit trail and strong accountability.
  9. Allow system/application owners to monitor vendor login sessions both in real time and after the fact. System/application owners should have the ability to terminate sessions in real time, if they see a vendor user doing something wrong.
  10. Notify vendors at login time that their sessions are being recorded and may be monitored.

Architecture

The HTTPS/HTML5 proxy approach to vendor access is illustrated in Figure [link].

Architecture for Remote Access using HTTPS/HTML5 Proxy

Architecture for Remote Access using HTTPS/HTML5 Proxy

In the figure:

  1. A user working for a vendor connects to Privileged Access Manager using a reverse web proxy, located in the DMZ. This proxy forwards HTTPS connections from the user's browser first to the on-premises Privileged Access Manager server and later, at session initiation time, to the on-premises session proxy.
  2. The user signs into the Privileged Access Manager web portal, typically by responding to a CAPTCHA and then providing two or more credentials.
  3. The vendor's user requests access to a managed endpoint. This is typically not pre-authorized, so a workflow request is created, inviting the Internal user to approve the access (SMTP - not shown), which he does (HTTPS - not shown).
  4. Once the internal user has approved access (to a specific account on a specific system during a specific time interval), the vendor's user can launch a login session. The actual session is from the proxy to the managed system, but it is displayed in the user's browser in a new tab, as an HTML canvas. No client software (other than the browser) is installed on the user's PC (or phone, or tablet).
  5. Both session metadata and video/keylog data are captured, archived and may be monitored by authorized users, typically on-premises or via VPN.