One Identity Safeguard for Privileged Sessions 5.7.0 - Deployment in Single-Interface Router Mode

Overview

This short document is about a special implementation of the One Identity Safeguard for Privileged Sessions. This makes it possible to deploy the device without changing the network topology, but keeping all the advantages of the transparent mode of the Safeguard for Privileged Sessions.


Was this topic helpful?

[Select Rating]



Introduction

The One Identity Safeguard for Privileged Sessions connection policies can work in different network models to make it easy to integrate it into an existing network. These two modes are transparent, and non-transparent modes (for details on modes of operation, see "Modes of operation" in the Administration Guide). The aim is usually the transparent implementation. Although the non-transparent mode can provide some transparency, it is not the best to be used for that purpose.

For the easy-to-deploy and totally transparent solution the transparent mode would be the best. This mode requires integrating Safeguard for Privileged Sessions in the network level, so all the administrative traffic could pass the box to make it controllable and auditable (for details and illustrations on transparent mode, see "Transparent mode" in the Administration Guide).

Figure 1: Safeguard for Privileged Sessions in transparent mode

In most cases it is not possible, or not optimal to integrate Safeguard for Privileged Sessions into the network as in the abovementioned example, because it would require significant changes to the network topology, and Safeguard for Privileged Sessions could act as a single point of failure. However, it is possible to use Safeguard for Privileged Sessions in transparent mode transparently without changing the network layout, with a few additional configuration steps in some of the active network devices (firewalls or routers) and the Safeguard for Privileged Sessions itself. The following sections will describe this in detail.


Was this topic helpful?

[Select Rating]



Inline routing scenario in Safeguard for Privileged Sessions

Safeguard for Privileged Sessions has two physical network interfaces that are normally used for production (monitored) traffic: “External” and “Internal”. The function of these interfaces is interchangeable, the names are only used in this document for easier identification. Safeguard for Privileged Sessions is implemented as it is visible on Figure Safeguard for Privileged Sessions in transparent mode. In this case the connections are coming from the client's network (define it as 192.168.0.0/24) and heading towards the server's network (define it as 10.0.0.0/24). The routing on the client is configured so that it uses Safeguard for Privileged Sessions as a gateway, when the server network is accessed. The servers are configured so that they send the answers into the client network through Safeguard for Privileged Sessions. Also, all the networks and gateways are defined in the routing table of Safeguard for Privileged Sessions, to send the traffic out on the appropriate interface.

Safeguard for Privileged Sessions does not check whether the client is coming from the “External” interface or if the connections are going out on the “Internal” interface. Because of this, it is possible to create a topology, where both the clients and the servers are located on the “External” side.


Was this topic helpful?

[Select Rating]



Single-interface transparent mode

Single-interface transparent mode is similar to transparent mode, but both client-side and server-side traffic use the same interface. An external device \xe2\x80\x94 typically a firewall or a router (or a layer3 switch) \xe2\x80\x94 is required that actively redirects the audited traffic to Safeguard for Privileged Sessions. To accomplish this, the external device must support advanced routing (also called policy-based routing or PBR). For details on configuring an external devices to work with Safeguard for Privileged Sessions in single-interface transparent mode, see Configuring external devices.

Figure 2: Safeguard for Privileged Sessions in single-interface transparent mode

Advantages:

The advantages of using the single-interface transparent mode are:

  • Totally transparent for the clients, no need to modify their configuration

  • The network topology is not changed

  • Only the audited traffic is routed to Safeguard for Privileged Sessions, production traffic is not

Disadvantages:

The disadvantages of using the single-interface transparent mode are:

  • Safeguard for Privileged Sessions acts as a man-in-the-middle regarding the connection between the client and the target server. Instead of a single client-server connection, there are two separate connections: the first between the client and Safeguard for Privileged Sessions, and a second between Safeguard for Privileged Sessions and the server. Depending on how you configure Safeguard for Privileged Sessions, the source IP in the Safeguard for Privileged Sessions-server connection can be the IP address of Safeguard for Privileged Sessions, or the IP address of the client. In the latter case — when operating in transparent mode (including single-interface transparent mode) — Safeguard for Privileged Sessions performs IP spoofing. Consult the security policy of your organization to see if it permits IP spoofing on your network.

  • Traffic must be actively routed to Safeguard for Privileged Sessions using an external device, consequently a network administrator can disable Safeguard for Privileged Sessions by changing routing rules.

  • When adding a new port or subnet to the list of audited connections, the configuration of the external device must be modified as well.

  • A network administrator can (intentionally or unintentionally) easily disable monitoring of the servers, therefore additional measures have to be applied to detect such activities.


Was this topic helpful?

[Select Rating]



Self Service Tools
Knowledge Base
Notifications & Alerts
Product Support
Software Downloads
Technical Documentation
User Forums
Video Tutorials
Contact Us
Licensing Assistance
Technical Support
View All
Related Documents

Please note our Privacy Policy recently changed to support GDPR. You may read it here. Continuing to use our website indicates you have accepted the new policy.