One Identity Safeguard for Privileged Sessions 6.0.10 - Administration Guide

Disabling controlled traffic permanently

To disable controlled traffic permanently

1. Figure 87: <Protocol name> Control > Global Options — Disabling the controlled traffic persistently

   

   Navigate to the Global Options page of the traffic type you want to disable, for example to SSH Control > Global Options to disable SSH traffic.

2. Set the Traffic > Service field to disabled.

3. Click .

Managing Safeguard for Privileged Sessions (SPS) clusters

When you have a set of two or more Safeguard for Privileged Sessions (SPS instances in your deployment, you can join them into a cluster. This has several advantages. You can:

• Manage the nodes from one central location.

• Monitor their status and update their configuration centrally.

• Search all session data recorded by all nodes in the cluster on a single node.

• Scale the performance of the cluster by adding new nodes and joining them to the cluster easily.

• Extend auditing to other networks by adding new nodes to the cluster and joining them to the cluster.

This is achieved by assigning roles to the individual nodes in your cluster: you can set one of your Safeguard for Privileged Sessions nodes to be the Central Management node and the rest of the nodes are managed from this central node.

Nodes in the cluster connect to each other using IPsec.

Cluster roles

You can assign any of the following roles to your nodes:

• Central Management: There can be only one node with this role in the cluster.

  The purpose of having a Central Management node is to have a node with a central configuration, which can be synchronized to the other nodes of the cluster. Any changes that you make in the cluster's configuration on this node (for example, role changes, host address changes, and so on) are fetched by all the other nodes and merged into their configuration.

  The Central Management node also has status information about all the other nodes in the cluster, so you can check the health of the cluster on this node. Status information contains:

  • the result and time of the last attempt at configuration fetch and configuration update

  • errors and warnings that may have occurred during configuration fetch and configuration update

• Managed Host: There can be several nodes with this role.

  Nodes with the Managed Host role synchronize their entire configuration from the Central Management node, not only those elements of the configuration that are related to the cluster.

  Managed Host nodes send their status information to the Central Management node every 10 seconds.

• Search Master: There can be only one node with this role.

  The Search Master node is the one node in the cluster on which you can search all the session data recorded by other nodes in the cluster, provided that the other nodes have been assigned the Search Minion role.

  NOTE: A One Identity Safeguard for Privileged Sessions (SPS) node with the Search Master role cannot be used for monitoring network traffic, or for session recording and auditing purposes. Before assigning this role to a node, read the limitations that apply to Search Master nodes carefully: Searching session data on a central node in a cluster

  This role can only be assigned to nodes that either have the Managed Host or Central Management role. This is required so that the configuration of Search Minion nodes and the Search Master node are always in sync.

  If there is no configuration synchronization between the node acting as the Search Master and the Search Minion nodes, then session data may show up on the Search interface of the Search Master that come from connections that do not match the connection policies set up on the Search Master (because they come from session data recorded by the Search Minions).

• Search Minion: There can be several nodes with this role.

  Nodes with the Search Minion role send session data that they recorded to the Search Master for central search purposes. The session data recorded by a Search Minion node is not searchable on the node itself, only on the Search Master.

  This role can only be assigned to nodes that either have the Managed Host or Central Management role. This is required so that the configuration of Search Minion nodes and the Search Master node are always in sync.

  If there is no configuration synchronization between the node acting as the Search Master and the Search Minion nodes, then session data may show up on the Search interface of the Search Master that come from connections that do not match the connection policies set up on the Search Master (because they come from session data recorded by the Search Minions).

• Search Local: There can be several nodes with this role.

  Nodes with the Search Local role keep the session data that they recorded for local searching. The session data recorded by a Search Local node is searchable on the node itself, but not on the Search Master (if there is one).

• No role: Nodes without any role fetch only the cluster-related elements of the configuration from the Central Management node.

  Nodes with no roles send their status information to the Central Management node every 10 seconds.

Nodes keep their role in the cluster after a system restore.

For more information about configuration synchronization, see Configuration synchronization across nodes in a cluster.

For more information about central search, see Searching session data on a central node in a cluster.

Enabling cluster management

To enable cluster management, enable the cluster interface on all nodes that you want to be part of your Safeguard for Privileged Sessions (SPS) cluster. Complete the following steps on each and every node of the cluster.

To enable cluster management

1. Navigate to Basic Settings > Local Services > Cluster Interface.

2. Select Enabled.

   The Listening address field is displayed.

3. Select a cluster interface for the node to listen on.

   Figure 88: Basic Settings > Local Services > Cluster Interface — Enabling cluster management

   

4. Click .