Network Segmentation in TOS

Overview

SecureTrack and SecureChange/SecureApp have separate authorization mechanisms. Users that are authorized to use SecureTrack are not necessarily authorized to use SecureChange/SecureApp and vice versa.

In addition to this built-in authorization, you can segment your TOS deployment to create a network separation to avoid unauthorized access between:

  • SecureTrack and SecureChange/SecureApp users

  • Monitored devices and the TOS central cluster

If You Upgraded from TOS Classic

In TOS Classic, SecureTrack and SecureChange/SecureApp could be deployed on different servers and networks, something that is not possible with the TOS architecture. Maintaining that segregation in TOS requires the approach described below.

Segregation of SecureTrack and SecureChange/SecureApp Users

TOS can serve users with varying privileges. For example, in some organizations SecureTrack users are a few select security administrators. These users generally have higher privileges. SecureChange and SecureApp users, on the other hand, are mostly application owners. These users are more numerous and they generally have lower privileges. Given this, some customers prefer to restrict SecureChange and SecureApp users from accessing SecureTrack.

To segregate SecureChange and SecureApp users, do not allow them to connect directly to TOS. Instead, route their connection through an external VIP and reverse proxy or ADC (Application Delivery Controller, such as F5). The external VIP must be on a separate server that is not part of any TOS cluster.

The reverse proxy/ADC will route only the paths required for SecureChange and SecureApp users and will block any other paths.

External reverse proxy/ADC details

  1. Route the following paths to TOS​

    2. /tufinapps 
    /securechangeworkflow​

    When SSO is set, include the following two paths as well: 

    /auth
    /protected

  2. Reject any other paths

  3. Required HTTP Headers:​

    • Host = Reverse Proxy address
    • X-Forwarded-Host = Reverse Proxy address
    • X-Forwarded-For = Remote client address

  4. Access should be allowed between Reverse-Proxy / ADC address to TOS on TCP 443.

Example (based on NGINX reverse proxy):

server {
    listen 443 ssl;

    set $external_vip <SC_EXTERNAL_URL>;
    # The external vip for SC users

    set $cluster_vip <TOS_CLUSTER_VIP>;
    # TOS cluster VIP

    server_name $external_vip;                                               
       
    ssl_certificate /etc/nginx/cert.crt;       
    # The path to the public certificate file
       
    ssl_certificate_key /etc/nginx/cert.key;     
    # The path to the private key certificate file
       

    proxy_set_header Host $host;
    # Set Host header as Reverse Proxy host

    proxy_set_header X-Forwarded-Host $host;
    # Set X-Forwarded-Host header as Reverse Proxy host

    proxy_set_header X-Forwarded-For $remote_addr;
    # Set X-Forwarded-For header as remote client address

    location ~ ^/(tufinapps|securechangeworkflow|auth|protected) {
    # The paths that should be routed to TOS cluster in order to access SecureChange / SecureApp
        proxy_pass https://$cluster_vip;
    } 


    location / {
    # Access to any other paths should be blocked with 403
        default_type text/html;
        return 403 "<H1> Permission Denied <H1>";
    }

} 

​

Restricted Network Segmentation

TOS Central Cluster must be connected to the devices it monitors. To create enhanced segmentation between TOS users and firewall devices, you can set up a Remote Collector to monitor the devices. Then, you can connect TOS to the Remote Cluster instead of directly to the devices.

For more information, see Remote Collectors.