Planning for Gateway Installation

• 1: LDAP and SSO Configurations
• 2: Mapping of Sensitive Data Primitives
• 3: Network Planning
• 4: HTTP URL Rewriting
• 5: Clustering and Load Balancing
• 6: SSL Certificates

1 - LDAP and SSO Configurations

The DSG is dependent on the ESA for user management. The users that are part of an organization AD are configured with the ESA internal LDAP.

If your organization plans to implement SSO authentication across all the Protegrity appliances, then you must enable SSO on the ESA and the DSG. The DSG depends on the ESA for user and access management and it is recommended that user management is performed on the ESA.

Before you can configure SSO with the DSG, you must complete the prerequisites on the ESA.

For more information about completing prerequisites on the ESA, refer to section Implementing SSO on DSG in the Protegrity Appliances Overview Guide 9.2.0.0.

After completing the prerequisites, ensure that the following order of SSO configuration on the DSG nodes is followed.

1. Enable SSO on the DSG node.
2. Configure the Web browser to add the site to trusted sites.
3. Login to the DSG appliance.

Enabling SSO on DSG

This section provides information about enabling SSO on the DSG nodes. It involves setting the ESA FQDN and enabling the SSO option.

Before SSO is enabled, ensure that the following prerequisite is completed.

• Ensure that the ESA FQDN is available.

To enable SSO on the DSG node:

1. Login to the DSG Web UI.

2. Navigate to Settings > Users.

3. Click the Advanced tab.

   

4. In the Authentication Server field, enter the ESA FQDN.

5. Click Update to save the server details.

6. Click the Enable toggle switch to enable the Kerberos SSO.

7. Repeat the step 1 to step 6 on all the DSG nodes in the cluster.

Configuring SPNEGO Authentication on the Web Browser

Before implementing Kerberos SSO for Protegrity appliances, you must ensure that the Web browsers are configured to perform SPNEGO authentication. The tasks in this section describe the configurations that must be performed on the Web Browsers. The recommended Web browsers and their versions are as follows:

• Google Chrome version 84.0.4147.135 (64-bit)
• Mozilla Firefox version 79.0 (64-bit) or higher
• Microsoft Edge version 84.0.522.63 (64-bit)

The following sections describe the configurations on the Web browsers.

Configuring SPNEGO Authentication on Firefox

The following steps describe the configurations on Mozilla Firefox.

To configure on the Firefox Web browser:

1. Open Firefox on the system.

2. Enter about:config in the URL.

3. Type negotiate in the Search bar.

4. Double click on network.negotiate-auth.trusted-uris parameter.

5. Enter the FQDN of the appliance and exit the browser.

Configuring SPNEGO Authentication on Internet Explorer

The following steps describe the configurations on Internet Explorer 11.

To configure on the Internet Explorer Web browser:

1. Open Internet Explorer on the machine

2. Navigate to Tools > Internet options > Security .

3. Select Local intranet.

4. Enter the FQDN of the appliance under sites that are included in the local intranet zone.

5. Select Ok.

Configuring SPNEGO Authentication on Chrome

With Google Chrome, you must set the white list servers that Chrome will negotiate with. If you are using a Windows machine to log in to the appliances, then the configurations entered in other browsers are shared with Chrome. You need not add a separate configuration.

Logging to the Appliance

After configuring the required SSO settings, you can login to the DSG using SSO.

To login to the DSG using SSO:

1. Open the Web browser and enter the FQDN of the DSG in the URL.

   The following screen appears.

   

2. Click Sign in with SSO.

   The Dashboard of the DSG appliance appears.

2 - Mapping of Sensitive Data Primitives

Corporate Governance will typically identify the data that is deemed sensitive to an organization. An example of this data can be PCI DSS data such as credit cards, Personally Identifiable Data (PII) and Protected Health Information (PHI). PII can include data elements such as First name, Last Name, Social Security Numbers, E-mail Addresses, or any data element that can identify an individual.

When using the gateway to protect sensitive data, the data must be identified through techniques exposed in a CoP Profile. For example, if the requirement is to protect sensitive data in a public SaaS, the identified sensitive data will need to be mapped to the corresponding fields in web forms rendered by the SaaS. These web forms are typically part of SaaS web pages where end users input sensitive data in SaaS for adding new data or searching existing data. A later section on the gateway configuration describes how the form fields will be targeted for protection through configuration rules.

3 - Network Planning

Connecting the gateway to a network involves address allocation and network communication routing for the service consumers. Network planning also includes gateway cluster sizing and addition of Load Balancers (LB) in front of the gateway cluster.

To protect data in a SaaS application, you gather a list of public domain and host names through which the SaaS is accessed over the Internet.

In case of internal enterprise applications, this relates to identifying networking address (IP addresses or host names) of relevant applications.

Gateway network interfaces can be divided into two categories, administrative and service. Administrative interfaces, such as Web UI and command line (SSH), are used to control and manage its configuration and monitor its state while service interfaces are used to deliver the service it is set to do. It is important that two NICs are created before you install the DSG.

For network security reasons DSG isolates the administrative interfaces from the service ones by allocating each with a separate network address. This enables physical separation when more than one physical NIC is available, otherwise logical separation is achieved by designating two different IP Addresses for admin and service use. Production implementation may strive to achieve further isolation for the service interface by separating inbound and outbound channels, in which case three IP Address will be required.

Network firewalls situated between consumer’s gateway interfaces, admin or services, and between the gateway and the system it is expected to communicate with will require to adjust to allow it.

Note: The supported TLS versions are SSLv3, TLSv1.0, TLSv1.1, TLSv1.2, and TLSv1.3.

If you are utilizing the DSG appliance, the following ports must be configured in your environment.

The following are the list of ports that must be configured for communication between DSG and ESA.

The following are the list of ports that must also be configured when DSG is configured in a TAC.

Based on the firewall rules and network infrastructure of your organization, you must open ports for the services listed in the following table.

Note: N/A* - In DSG, service NICs are not assigned a specific port number. You can configure a port number as per your requirements.

NIC Bonding

The NIC is a device through which appliances, such as ESA or DSG, on a network connect to each other. If the NIC stops functioning or is under maintenance, the connection is interrupted, and the appliance is unreachable. To mitigate the issues caused by the failure of a single network card, Protegrity leverages the NIC bonding feature for network redundancy and fault tolerance.

In NIC bonding, multiple NICs are configured on a single appliance. You then bind the NICs to increase network redundancy. NIC bonding ensures that if one NIC fails, the requests are routed to the other bonded NICs. Thus, failure of a NIC does not affect the operation of the appliance.

You can bond the configured NICs using different bonding modes.

CAUTION:The NIC bonding feature is applicable only for the DSG nodes that are configured on the on-premise platform. The DSG nodes that are configured on the cloud platforms, such as, AWS, GCP, or Azure, do not support this feature.

Bonding Modes

The bonding modes determine how traffic is routed across the NICs. The MII monitoring (MIIMON) is a link monitoring feature that is used for inspecting the failure of NICs added to the appliance. The frequency of monitoring is 100 milliseconds. The following modes are available to bind NICs together:

• Mode 0/Balance Round Robin
• Mode 1/Active-backup
• Mode 2/Exclusive OR
• Mode 3/Broadcast
• Mode 4/Dynamic Link Aggregation
• Mode 5/Adaptive Transmit Load Balancing
• Mode 6/Adaptive Load Balancing

The following two bonding modes are supported for appliances:

• Mode 1/Active-backup policy: In this mode, multiple NICs, which are slaves, are configured on an appliance. However, only one slave is active at a time. The slave that accepts the requests is active and the other slaves are set as standby. When the active NIC stops functioning, the next available slave is set as active.
• Mode 6/Adaptive load balancing: In this mode, multiple NICs are configured on an appliance. All the NICs are active simultaneously. The traffic is distributed sequentially across all the NICs in a round-robin method. If a NIC is added or removed from the appliance, the traffic is redistributed accordingly among the available NICs. The incoming and outgoing traffic is load balanced and the MAC address of the actual NIC receives the request. The throughput achieved in this mode is high as compared to mode 1.

Prerequisites

Ensure that you complete the following pre-requisites when binding interfaces:

• The IP address is assigned only to the NIC on which the bond is initiated. You must not assign an IP address to the other NICs.
• The NICs are on the same network.

Creating a Bond

This section describes the procedure to create a bond between NICs.

Note: Ensure that the IP address of the slave nodes are static.

Note: Ensure that you have added a default gateway for the Management NIC (ethMNG) and Service NIC (ethSRV0). For more information about adding a default gateway to the Management NIC and Service NIC, refer to the section Configuring Default Gateway for Network Interfaces.

Note: When a bond is created with any service NIC (ethSRVX) in the Web UI, its status indicator appears red - which may indicate it is not functioning properly - even though the service NIC (ethSRVX) is active. To change the service NIC (ethSRVX) status indicator to green, click Refresh.

To create a bond:

1. On the DSG Web UI, navigate to Settings > Network > Network Settings.

   The Network Settings screen appears.

2. Under the Network Interfaces area, click Create Bond corresponding to the interface on which you want to initiate the bond.

   The following screen appears.

   

   Note: Ensure that the IP address is assigned to the interface on which you want to initiate the bond.

3. Select the following modes from the drop down list:

   • Active-backup policy
   • Adaptive Load Balancing

4. Select the interfaces with which you want to create a bond.

5. Select Establish Network Bonding.

   A confirmation message appears.

6. Click OK.

   The bond is created and the list appears on the Web UI.

Removing a Bond

The following procedure describes the steps to remove a bond between NICs.

To remove a bond:

1. On the DSG Web UI, navigate to Settings > Network > Network Settings.

   The Network Settings screen appears with all the created bonds as shown in the following figure.

   

2. Under the Network Interfaces area, click Remove Bond corresponding to the interface on which the bonding is created.

   A confirmation screen appears.

3. Select OK.

   The bond is removed and the interfaces are visible on the IP/Network list.

Viewing a Bond

Using the DSG CLI Manager, you can view the bonds that are created between all the interfaces.

To view a bond:

1. On the DSG CLI Manager, navigate to Networking > Network Settings.

   The Network Configuration Information Settings screen appears.

2. Navigate to Interface Bonding and select Edit.

   The Network Teaming screen displaying all the bonded interfaces appears as shown in the following figure.

   

Resetting the Bond

You can reset all the bonds that are created for an appliance. When you reset the bonds, all the bonds created are disabled. The slave NICs are reset to their initial state, where you can configure the network settings for them separately.

To reset all the bonds:

1. On the DSG CLI Manager, navigate to Networking > Network Settings.

   The Network Configuration Information Settings screen appears.

2. Navigate to Interface Bonding and select Edit.

   The Network Teaming screen displaying all the bonded interfaces appears.

3. Select Reset.

   The following screen appears.

   

4. Select OK.

   The bonding for all the interfaces is removed.

4 - HTTP URL Rewriting

Operating in the in-band mode of data protection against SaaS applications, DSG is placed between the end-user’s client devices and the SaaS servers on the public Internet. For DSG to intercept the traffic between end-user devices and SaaS servers, the top level public Internet Fully Qualified Domain Names (FQDN) that are made accessible by the SaaS need to be identified. Once identified, these FQDNs shall be mapped to internal URLs pointed at DSG and the corresponding URL mappings shall be configured in DSG.

Like most websites on the public Internet, SaaS applications are accessed by their users through one or more Uniform Resource Locators (URL). These are typically HTTP(S) URLs that are made up of FQDNs, e.g. https://www.ffcrm.com, which are uniquely routable on the public Internet. A SaaS may be accessible on the public Internet through many public facing URLs. An identification of all such public URLs is essential for ensuring that all the traffic between the end users and the SaaS can be routed through DSG. A list of top level Internet facing FQDNs of a SaaS may be gathered from the following sources:

• SaaS Support Documentation: SaaS providers typically provide publicly available documentation where they publish their externally visible FQDNs. This information typically exists for the IT teams of customer enterprises such that they can allow - allowed list - access to these FQDNs through their corporate firewalls.
• Using Browser Tools or Network Sniffers: As an alternative or in addition, the IT team at Biloxi Corp may attempt to find the public FQDNs of ffcrm.com themselves. This can be achieved by making use of network sniffers - possibly an embedded function within Biloxi Corp’s corporate firewall or a forward proxy.

An alternative is to use ‘developer tools’ in the user’s web browser. Browser developer tools show a complete trace of HTTP messaging between the browser and the SaaS. If all relevant sections of ffcrm.com SaaS have been accessed, this trace will reveal the relevant public FQDNs made visible by ffcrm.com.

As a result of performing the above steps, let’s consider that the IT team at Biloxi Corp has identified the following top level public FQDNs exposed by ffcrm.com.

• www.ffcrm.com
• login.ffcrm.com
• crm.ffcrm.com
• analytics.ffcrm.com

For DSG to interwork traffic between its two sides (end users and SaaS), DSG relies on FQDN translation. The following figure shows FQDN translation performed by DSG.

The above domain names will be mapped to internal domain names pointed at DSG. For instance, DSG will be configured with following URL mappings.

This domain name mapping can be generalized by configuring a Domain Name Service (DNS) with a global mapping of *.ffrcm.biloxi.com to DSG which will apply to any of the sub domain www, login, crm, analytics or any other that might be added by ffcrm.com in the future.

Ultimately, end users will be consuming the service through the internal host names. Techniques like Single Sign On (SSO) using Security Assertion Markup Language (SAML) can be used to force users to use internal host names even if direct access to the external ones is attempted.

5 - Clustering and Load Balancing

DSG deployed as a cluster of appliance nodes provides the necessary the overall system capacity as well as high availability through redundancy. Nodes within a DSG cluster operate autonomously in an active/active arrangement.

Dependent on capabilities of underlying server hardware, traffic patterns and a few other factors, a single DSG node can process a certain amount of traffic. The size of a DSG cluster is determined by comparing the capacity of single node against customer’s performance requirements. For more information about the specific metrics collected in a controlled performance test environment, contact Protegrity Support for DSG Performance Report.

Let’s consider that the IT team at Biloxi Corp has established that they need three DSG nodes to meet their capacity and availability requirements. To hide DSG cluster topology from the end-users, the cluster is fronted by an off-the-shelf Load Balancer.

While considering load-balancing of HTTP traffic, since DSG nodes are stateless in and of themselves and across HTTP transactions, DSG places minimum requirements on Load Balancers (LBs). For instance, LBs fronting DSG cluster are not required maintain session stickiness or affinity. In fact, these LBs may be configured to operate at the lowest layers of TCP/IP protocol stack such as the networking or transport while being unaware of the application layer (HTTP).

Note: When available, DSG logging will leverage X-Real-IP HTTP Header added by Load Balancers to represent the actual client address.

The following figure shows a DSG cluster comprised of three gateway nodes fronted by a Load Balancer.

6 - SSL Certificates

The use of secured socket layer (aka SSL) prevents a man-in-the-middle from tampering or eavesdropping the communication between two parties. Though it may not be a requirement it is certainly a best practice to secure all communication channels that may be used to transmit sensitive data. DSG function is to transform data transmitted through it. To achieve that over a secured communication channel it is necessary for DSG to terminate the inbound TLS/SSL communication. This step may be skipped when no inbound SSL is used, otherwise, SSL Server Certificate and Keys are needed for DSG to properly terminate inbound SSL connections.

During the install process of DSG, a series of self-signed SSL Certificates are generated for your convenience. You may use it in non-production environment. It is recommended however to use your own certificate for production use.

No further action is required if you choose to use the service certificate generated during install time.

Certificate and keys can be uploaded for use with DSG cluster after the installation. Should you choose to use certificates generated elsewhere, be prepared to upload both the certificate and the associated key in such case. Supported certificate file formats are .crt and .pem.

You may need to generate your own self-signed certificate of specific attributes such as hostname, key strength or expiration date.