One Identity Safeguard for Privileged Sessions 6.9.3 - Administration Guide

The concepts of One Identity Safeguard for Privileged Sessions (SPS)

This section discusses the technical concepts of One Identity Safeguard for Privileged Sessions (SPS).

Topics:

The philosophy of One Identity Safeguard for Privileged Sessions (SPS)

One Identity Safeguard for Privileged Sessions (SPS) is a device that examines network traffic at the application level, that is, Layer 7 or the application layer of the OSI model. All communication must conform to the standards of the respective protocol. SPS examines Secure Shell (SSH, including forwarded X11 traffic), Secure Copy (SCP), SSH File Transfer Protocol (SFTP), Remote Desktop (RDP), HTTP, Independent Computing Architecture (Citrix ICA), Telnet, VMware Horizon View, and VNC connections, ignoring and simply forwarding all other types of traffic. SPS uses man-in-the-middle techniques to decrypt and terminate (when necessary) the inspected connections. It separates the connections into two parts (client — SPS, SPS — server) and inspects all traffic, so that no data can be directly transferred between the server and the client.

Figure 1: Inspecting SSH traffic with SPS

SPS has full control over the initial negotiation phase of the connection, when the client and the server decide the parameters of the encryption to be used in the communication. SPS can restrict the use of the various algorithms, forbidding the use of weak ones — an effective shield against downgrade attacks.

Since SPS isolates the client-server connection into two separate connections, the permitted algorithms can be different on the client and the server side.

SPS controls the connections right from the beginning — including user authentication. That way it is easy to mandate strong authentication for protocols where user information is available (for example, SSH), because SPS can limit the allowed authentication methods and also the users permitted to access the servers.

SPS uses various policies to restrict who, when, and how can access a connection or a specific channel of the protocol. These policies (based on username, authentication method used, and so on) can be applied to connections between particular clients and servers, or also to specific channels of a connection (for example, only to terminal-sessions in SSH, or desktop-sharing in RDP).

Figure 2: Controlling protocol channels

SPS is configured by an administrator or auditor using a web browser.

Policies

One Identity Safeguard for Privileged Sessions (SPS) controls access to connections through a set of policies. Policies let you specify various parameters of a connection, and so define the types of connections that SPS should monitor and restrict access to. When a connection request reaches SPS, SPS compares the connection policies to the parameters of the connection request one-by-one, starting with the first policy in the policy list. The first connection policy completely matching the connection request is applied to the connection.

Figure 3: Processing policies

This section provides a brief definition of each policy type and also explains the hierarchy between them.

A connection policy allows you to specify details of the connection between a particular client and server that you want to restrict in any way. In addition to setting basic details (such as the source and destination addresses), or more advanced ones (such as authentication to SPS or the server), the connection policy also references other policies that allow you to define further specifics of the connections you wish to control.

Depending on the protocol, the connection policy may also allow you to configure:

• A Credential Store that allows users auto logon to the target server.

  For information on Credential Stores, see Credential Stores.

• A plugin that allows integration with external systems, which users can be optionally authenticated to (before authenticating to the target server).

  For information on plugins, see Plugin framework.

For details on configuring connection policies, see Configuring connections.

A channel policy serves to control channel usage (for example, terminal session and Secure Copy in SSH, or drawing and clipboard in RDP) within a given connection. It lists channels that are allowed within a connection, and it also lets you specify restriction rules based on user lists, user groups, or the IP address of the client or server. You can also reference a content policy and a time policy within the channel policy, and it is also within the channel policy that you enable auditing for a specific channel.

For details on configuring channel policies, see Creating and editing channel policies.

A content policy lets you log an event, send an alert, or terminate a connection if a particular command or text (that you specify in the policy) appears in the command line or on the screen.

For details on creating a content policy, see Creating a new content policy.

A time policy specifies the timeframe when users are permitted to access a particular channel and so restricts the availability of that channel.

For details on configuring time policies, see Configuring time policies.

An audit policy enables you to prevent the manipulation of audit trails files that store the recorded activities of privileged users by providing you with options to encrypt, timestamp, and sign these files.

For details on creating audit policies, see Audit policies.

An authentication policy defines those client-side and server-side authentication methods that can be used in a connection.

For details on creating authentication policies, see Authentication Policies.

An LDAP policy lets you set details of the LDAP server to which you wish to authenticate users of the connections you are controlling.

For details on creating an LDAP policy, see Authenticating users to an LDAP server.

A usermapping policy specifies the usernames that are allowed access to the remote server and the user groups that are allowed to use the specified username.

For details on configuring usermapping policies, see Configuring usermapping policies.

An archiving policy lets you configure details of the archiving process that enables you to archive connection-related data and audit trails. You can configure, for example, the target server where archived files are to be stored, or the directory structure in which to organize your archived files.

For details on creating archiving policies, see Archiving and cleanup.

A backup policy defines the address of the backup server where you can back up connection data, the protocol to use to access it, details of authenticating to the backup server, and so on.

For details on creating backup policies, see Data and configuration backups.

An analytics policy lets you specify the analytics that you wish to run for specific sessions, and also determine the weight that scores given by the selected analytics should have in the final aggregated score.

For details on configuring analytics policies, see "Configure analytics" in the Safeguard for Privileged Analytics Configuration Guide.

Figure 4: Policies of SPS

Credential Stores

Credential Stores are repositories of user credentials (for example, passwords, private keys, certificates). They are used for authenticating a user to the target server that the user wishes to access, without the user actually having access to those credentials. Credentials are retrieved transparently from One Identity Safeguard for Privileged Sessions's (SPS's) local Credential Store or an external, third-party password management system by SPS impersonating the authenticated user. This automatic password retrieval is crucial, as this method protects the confidentiality of passwords since users can never access them.

Users accessing connections that use Credential Stores must authenticate on SPS using gateway authentication. They only have to use their gateway password to log in to SPS, and if they are allowed to access the target server, SPS automatically logs in using the Credential Store. For details on gateway authentication, see The gateway authentication process.

Figure 5: Authenticating using Credential Stores

Credential Stores can be stored locally on SPS, or on a remote device. For remote Credential Stores, SPS integrates with external authentication and authorization systems using plugins.

For further information on Credential Stores including configuration details, see Using credential stores for server-side authentication.