Web UI

• 1: Cluster
• 1.1: Monitoring
• 1.2: Log Viewer
• 2: Ruleset
• 2.1: Learn Mode
• 2.1.1: Learn Mode Scheduled Task
• 2.2: Ruleset Tab
• 2.2.1: Ruleset Versioning
• 3: Transport
• 3.1: Tunnels
• 3.1.1: Manage a Tunnel
• 3.1.2: Amazon S3 Tunnel
• 3.1.3: HTTP Tunnel
• 3.1.4: SFTP Tunnel
• 3.1.5: SMTP Tunnel
• 3.1.6: NFS/CIFS
• 3.1.6.1: NFS/CIFS
• 3.2: Certificates/Key Material
• 3.2.1: Certificates Tab
• 3.2.2: Delete Certificates and Keys
• 3.2.3: Keys Subtab
• 3.2.4: Other Files Subtab
• 3.2.5: Upload Certificate/Keys
• 4: Global Settings
• 4.1: Debug
• 4.2: Global Protocol Stack
• 4.3: Web UI
• 5: Tokenization Portal

1 - Cluster

The Cluster menu includes the following tabs: Monitoring and the Log Viewer tabs.

• Monitoring: The Monitoring tab displays information about the available nodes in a DSG cluster.

• Log Viewer: Unified view of the log messages across all the nodes in the cluster.

1.1 - Monitoring

The individual nodes in the cluster can be monitored and managed. The following actions are available on the monitoring screen:

• Add nodes to the cluster

• Deploy configurations to the nodes in the cluster

• Deploy configurations to specific node groups

• Change groups in the cluster

• Change groups on selected nodes

• Refresh nodes in the cluster

• Start, stop, or restart individual nodes

The following figure illustrates the Monitoring screen:

1 Cluster Health - Cluster health indicator in Green, Orange, or Red.

2 Hostname - Hostname of the DSG.

3 IP - IP address of the DSG.

4 PAP version - Build version of the DSG.

5 Health - Status of DSG.

6 Node Group - Node group assigned to the DSG node. If no node group is specified, the node group is assigned as default.

7 Config Version - The tag name provided while deploying the configuration to a particular node group.

8 DSG Version - Build version of DSG.

9 Uptime - Time that the DSG has been running.

10 Load Avg - Average load on a process in the last five, ten, and fifteen minutes.

11 Utilization - Number of DSG processes and CPU cores utilized.

12 Connections - Total number of active connections for the node.

13 Select for Patch Installation or Node Group Update - Select the option to updating the node group

14 Socket - Total number of open sockets for the node.

15 Config Version Description - The additional information about the configuration version. If the description is not provided while deploying the configurations to a particular node group, then this field will be empty.

Cluster and node health status color indication reference:

Color	Description
	Node is healthy and services are running.
	Warning. Some services related to a node need attention.
	Not running or unreachable.

The following figure illustrates the actions for the Cluster Monitoring screen.

The callouts in the figure are explained as follows.

1 Expand - Expand to view the other columns.

2 Refresh - Refresh all the nodes in the cluster. The Refresh drop down list provides the following options:

• Start: Starts all nodes.
• Stop: Stops all nodes.
• Refresh: Refreshes details related to all nodes.
• Restart: Restarts all nodes. The restart operation will not export the configurations, it will only restart all the nodes.
• Deploy: Deploys the configuration changes on all the DSG nodes in the cluster. The configurations are pushed and the node is restarted. For more information, refer here.
• Deploy to Node Groups: Deploy the configurations to the selected node groups in the cluster. The configurations are pushed and the node is restarted. For more information, refer here.

3 Actions - The Actions drop down list at the cluster level provides the following options:

• Apply Patch on Cluster: Applies a patch to all nodes in a cluster including the ESA.
• Apply Patch on Selected Nodes: Apply the same patch simultaneously on all selected nodes.
• Change Groups on Entire Cluster: Change the node group of all the DSG nodes in the cluster
• Change Groups on Selected nodes: Select the node and change the node group on that particular DSG node in the cluster
• Add Node: Adding a Node to the Cluster.

4 Order - Sort the nodes in ascending or descending order

5 Actions - The Actions drop down list at the individual node level provides the following options:

• Start: Start a node
• Stop: Stop a node
• Restart: Restart a node.
• Apply Patch: Applies a patch to a single node. Before applying a patch on a single DSG node, ensure that the same patch is applied on the ESA.
• Change Groups: Changes the node group on an individual DSG node
• Delete: Delete a node.

Deploying the Configurations to Entire Cluster

The configurations can be pushed to all the DSG nodes in the cluster. This action can be performed by clicking the Deploy option on the Cluster page or from the Ruleset page.

To deploy the configurations to entire cluster:

1. In the ESA Web UI, navigate to **Cloud Gateway > 3.3.0.0 {build number}**Cloud Gateway > 3.3.0.0 {build number}> Cluster.

2. Select the Refresh drop down menu and click Deploy.

   The following pop-up message occur on the Cluster screen.

   

3. Click YES to push the configurations to all the node groups and nodes.

   The configurations will be deployed to all the nodes in the entire cluster.

Deploying the Configurations to Node Groups

The configurations can be pushed to the selected node groups. The configuration will only be pushed to the DSG nodes associated with the node groups. This action can be performed by clicking the Deploy to Node Groups option on the cluster page or from the Ruleset page.

To deploy the configurations to the selected node groups:

1. In the ESA Web UI, navigate to **Cloud Gateway > 3.3.0.0 {build number}**Cloud Gateway > 3.3.0.0 {build number}> Cluster.

2. Select the Refresh drop down menu and click Deploy to Node Groups.

3. Perform the following steps to deploy the configurations to the node groups.

   1. Click Deploy to Node Groups.

      The Select node groups for deploy screen appears.

      

      The default and lob1 are the node groups associated with the DSG nodes. When you add a node to cluster, a node group is assigned to that node. For more information about adding a node and node group to the cluster, refer here.

   2. Enter the name for the configuration version in the Tag Name field.
      The tag name is the version name of a configuration that is deployed to a particular node group. The tag name must be alphanumeric separated by spaces or underscores. If the tag name is not provided, then it will automatically generate the name in the YYYY_mm_dd_HH_MM_SS format.

   3. Enter the description for the configuration in the Description field. The user can provide additional information about the configuration that is to be deployed.

   4. On the Deployment Node Groups option select the node group to which the configurations must be deployed.

   5. Click Submit.

1.2 - Log Viewer

The Log Viewer screen provides a unified view of all the logs. The logs are classified in the following levels:

• Debug: Debugging trace.

• Verbose: Additional information that can help a user with detailed troubleshooting

• Information: Log entry for information purposes

• Warning: Non-critical problem. Appears in orange.

• Error: Issue that requires user’s attention. Appears in red.

The following figure illustrates the column for the Log Viewer screen.

1 Host - Host name or IP address of the DSG node where the log message was generated.

2 PID - Captures the process identifier of the DSG daemons that generated the log message.

3 Timestamp (UTC) - Time recorded when an event for the log was generated. The time recorded is displayed in the Coordinated Universal Time (UTC) format.

4 Level - Severity level of the log message.

5 Module - Part of the program that generated the log.

6 Source - Procedure in the module that generated the log.

7 Message - A textual description of the event logged.

The following figure illustrates the actions for the Log Viewer screen.

Search logs

Click the search box to scan through the log archive that is collectively maintained across all the DSG nodes within the cluster. The search for logs is not limited to the records that appear on the screen. When a user clicks search, all the log records that are present on the screen as well as on the server are retrieved.

Clear records

Clearing the screen removes the entries that are currently displayed. You can view all the archived logs even after the records are cleared. Click Clear Screen to clear the logs. However, the logs are cleared on from the Log Viewer screen. It is not deleted from the appliance logs and avaialble for reference.

Retrieve archived logs

When the logs are cleared from the screen, the records are archived and can be viewed later. After clearing the records, click the Refresh icon. A link displaying the timestamp of the last updated record appears. Click Showing logs after > Show all. The latest 1000 logs are displayed.

Fetching records

Click the Refresh icon to view new logs generated.

2 - Ruleset

The RuleSet menu includes the RuleSet and the Learn Mode tabs.

• RuleSet tab
  The Ruleset tab provides you the capability to create a hierarchical rule pattern based on the service type. The changes made to the Ruleset tree require deployment of configuration to take effect.
• Learn Mode
  Learn Mode tab provides a consolidated view of all message recorded by the DSG cluster. It allows you to consider messages exchanged through the DSG nodes and study the payloads as they are seen by the DSG. Understanding how messages are structured enables you to set the appropriate rules which will transform the relevant parts in it before it is forwarded on.

2.1 - Learn Mode

Learn mode allows to consider messages exchanged through the DSG nodes and study the payloads as they are seen by the DSG. Understanding how messages are structured enables to set the appropriate rules which will transform the relevant parts in it before it is forwarded.

The Learn Mode tab is shown in the following figure.

The following table provides the description for each column available on the Web UI.

1 Received (UTC) - Time when the transaction is triggered. The time recorded is displayed in the Coordinated Universal Time (UTC) format.

2 PID - Process Identifier that has carried the request or response transaction on the gateway machine.

3 Source - Source IP address or hostname in the request.

4 Destination - Destination IP address or hostname in the request.

5 Service - Service name to which the transaction belongs.

6 Hostname - DSG node hostname where the request was received and processed.

7 Message - Provides information about the type of message.

8 Processing Time (ms) - Time required to complete the transaction.

9 Rules Filters - Filter the rules based on the selected option for a transaction.

10 Filter Summary - Summary of rule details, such as, Elapsed time, result, and Action Count.

11 Message Difference - Difference between the message received by the rule and the message processed by the rule.

12 Wrap lines - Select to break the text to fit in the readable view.

13 View in Binary - View message in hexadecimal format.Note: If you want to view a payload such as .zip, .pdf, or more, you can use the View in Binary option.

14 Download Payload - Click to download large payloads that cannot be completely displayed on the screen.

** Failed Transaction (in red color) - Any failed transaction is highlighted in the color red.

The following figure illustrates the actions on the Learn Mode screen.

The following table provides the description for each action available on the Web UI.

1 Search log - Search the learn mode content.

2 Column Filters - Apply column filters for each column to filter or search records based on the string and regex pattern match.

3 Refresh - Refresh the list.

4 Reset - Logs from the server are purged.

5 Collapse/Expand tree - Collapse or expand the rule tree.

You can select a record in the Learn Mode screen to view details regarding the matched and unmatched rules for that entry. If the size of the message exceeds the limit, then a message Contents of the selected record are too large to be displayed appears.

2.1.1 - Learn Mode Scheduled Task

Click System > Task Scheduler, select the Learn Mode Log Cleanup scheduled task, and then click Edit to modify the scheduled task that initiates the learnmodecleanup.sh file at regular intervals. The scheduled task can be set to n hours or days based on your preference. The default recommended frequency is Daily-Every Midnight.

In addition to setting the task, you can define the duration for which you want to archive the Learn Mode logs. The following image displays the Learn Mode Log Cleanup scheduled task.

The following table provides sample configurations:

Note: If a numeric value is set without the HOURS or DAYS qualifier, then DAYS is considered as the default.

2.2 - Ruleset Tab

The changes made to the Ruleset tree require deployment of configuration to take effect.

The RuleSet tab is shown in the following figure:

The following table provides the description for each of the available RuleSet options:

1 Search - Click to search for service, profile, or rules.

2 Search textbox - Provide service, profile, or rule name.

3 Add new service - Add a new service-level based on the service type used. Only one service can be created for every service type.

4 View Old Versions - Click to view archived Ruleset configuration backups.

5 Deploy - Deploy the configurations to all the DSG nodes in the cluster. The Deploy operation will export the configurations and restart all the nodes.

6 Deploy to Node groups - Deploy the configurations to the selected node groups in the cluster. This will export the configurations and restart the nodes associated with the node groups.

7 Import - Import the Ruleset tree to the Web UI. Files should be uploaded in .zip extension structure.

• Ensure that the service exists as part of the Ruleset before you import a configuration exported at Profile level.
• Ensure that the directory structure that the exported .zip maintains is replicated when you repackage the files for import. Also, the JSON files must be valid.
• If an older ruleset configuration .zip created using any older DSG version, that includes a GPG ruleset with key passphrase defined, is imported, then the DSG does not encrypt the key passphrase.

8 Export All - Export the Ruleset tree configuration. The rules are downloaded in a .zip format.

9 Edit - Edit the service, profile, or rule details as per requirement.

10 Expand Rule- Expand the rule tree and view child rules.

If you want to further work with rules, right-click any rule to view a set of sub menus. The sub menu options are seen in above figure. The options are described in the following table.

11 Duplicate - Duplicate a service, profile, or rule to create a copy of these Ruleset elements.

12 Export - Export the Ruleset tree configuration at Service or Profile level. All the child rules under the parent Service or Profile are exported. The rules are downloaded in the .zip format.

13 Create Rule - Add child rule under the parent rule.

14 Delete - Delete the selected rule.

15 Cut - Cut the selected rule from the parent rule.

16 Copy - Copy the selected rule under a parent.

17 View Configuration - View the configuration of the rule in the JSON format. You can copy the JSON format of the rule and pass it as parameter value in the header of the Dynamic CoP ruleset. This option is available only for the individual rules.

Instead of cut and copy a rule to change its hierarchy among siblings, you can also drag a sibling rule and change its positioning. When the drop is successful, a green tick icon ( ) is displayed as shown in the following figure.

When the drop is unsuccessful, a red cross icon ( ) is displayed as shown in the following figure.

A log is generated in the Forensics screen every time you cut, copy, delete, or reorder a rule from the Ruleset screen in the ESA.

The following figure shows a service with Warning indication.

The symbol is seen on the service when the child rule is not created or when Learn Mode is enabled.

Deploy configurations to the Cluster

1. In the ESA Web UI, navigate to Cloud Gateway > 3.3.0.0 {build number} > Ruleset.

2. Click Deploy. A confirmation message occurs.

3. Click Continue to push the configurations to all the node groups and nodes. The configurations will be deployed to the entire cluster.

Deploy configurations to node groups

1. In the ESA Web UI, navigate to Cloud Gateway > 3.3.0.0 {build number} > Ruleset.

2. Click Deploy > Deploy to Node Groups.

The Select node groups for deploy screen appears.

3. Enter the name for the configuration version in the Tag Name field. The tag name is the version name of a configuration that is deployed to a particular node group. The tag name must be alphanumeric, separated by spaces or underscores. If the tag name is not provided, then it will automatically generate the name in the YYYY_mm_dd_HH_MM_SS format.

4. Enter the description for the configuration in the Description field.

5. On the Deployment Node Groups option, select the node group to which the configurations must be deployed.

6. Click Submit.

   The configurations are deployed to the node groups.

2.2.1 - Ruleset Versioning

What is it

After deploying a configuration to particular node group or to entire cluster, a backup of these configurations are saved in View Older Versions on the Ruleset page. The most recent deployed configuration for a particular node group is shown as Deployed status on viewing the older versions There are tagged and untagged versions seen on viewing the older versions. You can create a tagged or untagged version.

The following figure shows the Ruleset versioning screen.

The following table provides the description for the deployed configurations.

1 The configuration is deployed to default node group and you can see Deployed status for this configuration version. This is the most recent deployed configuration version for the default node group with Deployed status. Each node group will have Deployed status for the most recent configuration version.

2 The configuration is deployed to lob1 node group and the configuration version is untagged. As the version is untagged, it will automatically generate the name with timestamp in the YYYY_mm_dd_HH_MM_SS format. Each node group will archive the three most recent untagged version. Refer to configuring the default value.

3 The configuration is deployed to lob1 node group and the configuration version is tagged. While deploying the configuration to default node group the lob1_fst_configuration tag name was provided to configuration version. Each node group will archive the ten most recent tagged version. Refer to configuring the default value

Working with ruleset versioning

Each time a configuration is changed and deployed, the DSG creates a backup configuration version. You can apply an earlier configuration version and make it active, in case you want to revert to the older configuration version.

1. On the DSG Web UI, navigate to **Cloud Gateway > 3.3.0.0 {build number}**Cloud Gateway > 3.3.0.0 {build number}> Ruleset.

   The following figure shows the Ruleset versioning screen.

   

2. Click View Old Versions.

3. Click the Viewing drop-down to view the available versions.

4. Select a version.

   The left pane displays the Services, Profiles, and Rules that are part of the selected version.

5. Click Apply Selected Version to make the version active or click Close Old Versions to exit the screen.

6. Click Deploy or Deploy to Node Groups to save changes.
   

   For more information about deploying the configurations to entire cluster or the node groups, refer Deploying the Configurations to Entire Cluster and Deploying the Configurations to Node Groups.
   

   It is recommended that any changes to the Ruleset configuration is made through the Cloud Gateway menu available on the ESA Web UI. Any changes made to the Ruleset configuration from the DSG Web UI of an individual node are overridden by the changes made to the ruleset configuration from the ESA Web UI. After overriding, the older Ruleset configuration on individual nodes is displayed as active and no backup for this configuration is maintained.

   Updating versions

   If you want to change the number of tagged or untagged versions that a node can store, then on the DSG node, login to the OS console. Navigate to the /opt/protegrity/alliance/version-1/config/webinterface directory. Edit the following parameter in the nodeGroupsConfig.json file.

   no_of_node_group_deployed_archives = <number_of_untagged_versions_to_be_stored>

   The default value for the untagged version is set at 3.

   no_of_node_group_deployed_tag_archives = <number_of_tagged_versions_to_be_stored>

   The default value for the tagged version is set at 10.

3 - Transport

The Transport Menu includes the Certificates and the Tunnels tabs.

• Certificates tab allow to configure TLS/SSL certificates for SSL Termination by DSG.

• Tunnels tab allows to define the DSG inbound communication channels.

3.1 - Tunnels

The changes made to Tunnels require cluster restart to take effect. You can either use the bundled default tunnels or create a tunnel based on your requirements.

The Tunnels tab is as seen in the following figure.

The following table provides the description of the columns available on the Web UI.

1 Name - Unique tunnel name.

2 Description - Unique description that describes port supported by the tunnel.

3 Protocol - Protocol type that the tunnel supports. The available Type values are HTTP, S3, SMTP, SFTP, NFS, and CIFS.

4 Enabled - Status of the tunnel. Displays status as true, if the tunnel is enabled.

5 Start without service - Select to start the tunnel if no service is configured or if no services are enabled.

6 Interface - IP address through which sensitive data enters the DSG. The available Listening Address options are as follows:

• ethMNG: The management interface on which the Web UI is accessible.
• ethSRV0: The service interface for communicating with an untrusted service.
• 127.0.0.1: The local loopback adapter.
• 0.0.0.0: The broadcast address for listening to all the available network interfaces over all IP addresses.
• Other: Manually add a listening address based on your requirements.

Note: The service interface, ethSRV0, listens on port 443. If you want to stop this interface from listening on this port, then edit the default_443 tunnel and disable it.

7 Port - Port linked to the listening address.

8 Certificate - Certificate applicable to a tunnel.

9 Deploy to All Nodes - Deploy the configurations to all the DSG nodes in the cluster.|Deploy can also be performed from the Cluster tab or Ruleset screen. In a scenario where an ESA and two DSG nodes are in a cluster, by using the Selective Tunnel Loading functionality, you can load specific tunnel configurations on specific DSG nodes.
Click Deploy to All Nodes to push specific tunnel configurations from an ESA to specific DSG nodes in a cluster.

The following figure illustrates the actions for the Tunnels screen.

The following table provides the available actions:

1 Create Tunnel - Create a tunnel configuration as per your requirements.

2 Edit - Edit an existing tunnel configuration.

3 Delete - Delete an existing tunnel configuration

3.1.1 - Manage a Tunnel

Create a tunnel

You can create tunnels for custom ports that are not predefined in the DSG using the Create Tunnel option in the Tunnels tab. The Create Tunnel screen is as seen in the following figure.

The following table provides the description for each option available on the UI.

The following types of tunnels can be created.

• HTTP
• SFTP
• SMTP
• Amazon S3
• CIFS/NFS

Edit a tunnel

Edit an existing tunnel configuration using the Edit option in the Tunnels tab. The Edit Tunnel screen is as seen in the following figure.

After editing the required field, click Update to save your changes.

Delete a tunnel

Delete an existing tunnel using the Delete option in the Tunnels tab. The Delete Tunnel screen is shown in the following figure.

The following table provides the description for each option available on the UI.

3.1.2 - Amazon S3 Tunnel

Amazon Simple Storage Service (S3) is an online file storage web service. It lets you manage files through browser-based access as well as web services APIs. In DSG, the S3 tunnel is used to communicate with Amazon S3 cloud storage over the Amazon S3 REST API. The higher-layer S3 Service object, which sits above the tunnel object, configured at the RuleSet level is used to process file contents retrieved from S3.

A sample S3 tunnel configuration is shown in the following figure.

Amazon S3 uses buckets to store data and data is classified as objects. Each object is identified with a unique key ID. Consider an example that john.doe is the bucket and incoming is a folder under john.doe bucket. Assuming the requirement is that files landing in the incoming folder should be picked up and processed by DSG nodes. The data pulled from the AWS online storage is available in the incoming folder under the source bucket. The Amazon S3 Service is used to perform data security operation on this data in the source bucket.

Note: The DSG supports four levels of nested folders in an Amazon S3 bucket.

After the rules are executed, the processed data may be stored in a separate bucket (e.g. the folder named outgoing under the same john.doe bucket), which is the target bucket. When the DSG nodes poll AWS for a file uploaded, whichever node accesses the file first places a lock on the file. You can specify if the lock files must be stored in a separate bucket or under the source bucket. If the file is locked, the other DSG nodes will stop trying to access the file.

If the data operation on a locked file fails, the lock file can be viewed for detailed log and error information. The lock files are automatically deleted if the processing completes successfully.

Consider the scenario where an incoming bucket contains two directories Folder1 and Folder2.

The DSG allows multiprocessing of files that are place in the bucket. The lock files are created for every file processed. In the scenario mentioned, the lock files are created as follows:

• If the abc.csv file of Folder1 is processed, the lock file is created as Folder1.abc.csv.<hostname>.<Process ID>.lock.
• If the pqr.csv file of Folder2 is processed, the lock file is created as Folder1.pqr.csv.<hostname>.<Process ID>.lock.

Consider the following figure where files are nested in the S3 bucket.

The lock files are created as follows:

• If the abc.csv file of Folder1 is processed, the lock file is created as Folder1.abc.csv.<hostname>.<Process ID>.lock.
• If the pqr.csv file of Folder2 is processed, the lock file is created as Folder1.Folder2.pqr.csv.<hostname>.<Process ID>.lock.
• If the abc.csv file of Folder3 is processed, the lock file is created as Folder1.Folder2.Folder3.abc.csv.<hostname>.<Process ID>.lock.

If the multiprocessing of files is to be discontinued, remove the enhanced-lock-filename flag from the features.json file available in the System > Files on the DSG Web UI.

The following image illustrates the options available for an S3 tunnel.

The options specific to the S3 Protocol type are described as follows:

Bucket list settings

1 Source Bucket Name: Bucket name as defined in AWS where the files that need to be processed are available.

2. Source File Name Pattern: Regex pattern for the filenames to be processed. For example, .csv.

Rename Processed Files: Regex logic for renaming processed file.

3. Match Pattern: Regex logic for renaming processed file.

4. Replace Value: Value to append or name that will be used to rename the original source file based on the pattern provided and grouping defined in regex logic.

5. Overwrite Target Object: Select to overwrite a file in the bucket with a newly processed file of the same name. Refer to Amazon S3 Object.

6. Lock Files Bucket: Name of the lock files folder, if you want the lock files to be stored in a separate bucket. If not defined, lock files are placed in the source bucket.

7. Interval: Time in secs when the DSG node will poll AWS for pulling files. You can also specify a cron job expression. Refer to Cron documentation. The default value is 5. If you use the cron job expression “* * * * *”, DSG will poll AWS at the minimum interval of one minute.
Cron job format is also supported to schedule jobs.

AWS Settings

8. AWS Access Key Id: Access key id used to make secure protocol request to an AWS service API. Refer to Amazon Web Service documentation.

9. AWS Secret Access Key: Secret access key related to the access key id. The access key id and secret access key work together to sign into AWS and provide access to resources. Refer to Amazon Web Service documentation.

10. AWS Endpoint URL: Specify the endpoint URL if it is other than the amazon S3 bucket. This parameter should only be configured if the user is using DSG to connect to other endpoint than amazon S3 bucket i.e. On-Premise S3, Google Cloud Bucket, and so on.If not defined, the DSG will connect to Amazon S3 bucket.

11. Path to CA Bundle: Specify the path to CA bundle if the endpoint is other than Amazon S3 bucket. If the user has installed the S3 on-premise using the self signed certificate, then specify that path to CA bundle in this parameter. If the endpoint URL is Amazon S3 bucket, then by default it uses SSL certificate to connect to S3 bucket.

Advanced Settings

12. Advanced settings: Set additional advanced options for tunnel configuration, if required, in the form of JSON in the following textbox. In a scenario where an ESA and two DSG nodes are in a cluster, by using the Selective Tunnel Loading functionality, you can load specific tunnel configurations on specific DSG nodes.

The advanced settings that can be configured for S3 Protocol.

Using S3 tunnel to access files on Google Cloud Storage

Similar to AWS buckets, data is also stored on the Google Cloud Storage can also be protected. You can use the S3 tunnel to access the files on the GCP storage. The incoming and processed file has to be placed in the same storage in separate folders. For example, a storage named john.doe bucket contains a folder incoming that contains files to be picked and processed by DSG nodes. This acts as the source bucket. After the rules are executed, the data is stored in the processed bucket. Ensure the following points are considered.

• AWS Endpoint URL contains the URL of the Google Cloud storage.
• AWS Access Key ID and AWS Secret Access Key contain the secret ID and HMAC keys.

Refer to Google docs for information about Access ID and HMAC keys.

3.1.3 - HTTP Tunnel

Based on the protocol selected, the dependent fields in the Tunnel screen vary. The following image illustrates the settings that are specific to the HTTP protocol.

The options for the Inbound Transport Settings field in the Tunnel Details screen specific to the HTTP Protocol type are described in the following table.

Network Settings

1 Listening Interface: IP address through which sensitive data enters the DSG. The following Listening Interface options are available:

• ethMNG: The management interface on which the DSG Web UI is accessible.
• ethSRV0: The service interface for communicating with an untrusted service.
• 127.0.0.1: The local loopback adapter.
• 0.0.0.0: The broadcast address for listening to all the available network interfaces.
• Other: Manually add a listening address based on your requirements.

2 Port:Port linked to the listening address.

TLS/SSL Security Settings

3 TLS Enabled: Select to enable TLS features.

4 Certificate: Certificate applicable for a tunnel.

5 Cipher Suites: Colon separated list of Ciphers.

6 TLS Mutual Authentication: CERT_NONE is selected as default. Use CERT_OPTIONAL to validate if a client certificate is provided or CERT_REQUIRED to process a request only if a client certificate is provided. If TLS mutual authentication is set to CERT_OPTIONAL or CERT_REQUIRED, then the CA certificate must be provided.

7 CA Certificates: A CA certificate chain. This option is applicable only if the value client certificate is set to 1 (optional) or 2 (required). Client certificates can be requested at the tunnel and the RuleSet level for authentication. On the Tunnels screen, you can configure the ca_reqs parameter in the Inbound Transport Settings field to request the client certificate. Similarly, on the Ruleset screen, you can toggle the Required Client Certificate checkbox to enable or disable client certificates. Based on the combination of the options in the tunnel and the RuleSet, the server executes the transaction. If the certificate is incorrect or not provided, then server returns a 401 error response.

The following table explains the combinations for the client certificate at the tunnel and the RuleSet level.

8 DH Parameters: The .pem filename that includes the DH parameters. Upload the .pem file from the Certificate/Key Material screen. The Diffie-Hellman (DH) parameters define the way OpenSSL performs the DH Key exchange.

9 ECDH Curve Name: Supported curve names for the ECDH key exchange.The Elliptic curve Diffie–Hellman (ECDH) protocol allows key agreement and leverages elliptic-curve cryptography (ECC) properties for enhanced security.

10 Certificate Revoke List: Path of the Certificate Revocation List (CRL) file. For more information about CRL error message that appears when a revoked certificate is sent, refer to the CRL error. The ca.crl.pem file includes a list of certificates that are revoked. Based on the flags that you provide in the verify_flags setting, SSL identifies certificate verification operations that need to performed. The CRL verification operations can be VERIFY_CRL_CHECK_LEAF or VERIFY_CRL_CHECK_CHAIN.

When you try to access the DSG through HTTPS using such a revoked certificate, the DSG returns the following error message.

11 Verify Flags Set to one of the following operations to verify the CRL:

• VERIFY_DEFAULT
• VERIFY_X509_TRUSTED_FIRST
• VERIFY_CRL_CHECK_LEAF
• VERIFY_CRL_CHECK_CHAIN

12 SSL Options|Set the required flags that reflect the TLS behavior at runtime. A single flag or multiple flags can be used.It is used to define the supported SSL options in the JSON format. The DSG supports TLS v1.2.|For example, in the following JSON, TLSv1 and TLSv1.1 are disabled.
{
“options”: [“OP_NO_SSLv2”,
“OP_NO_SSLv3”,
“OP_NO_TLSv1”,
“OP_NO_TLSv1_1”]
}|

13 Advanced Settings Set additional advanced options for tunnel configuration, if required, in the form of JSON.|In a scenario where an ESA and two DSG nodes are in a cluster, by using the Selective Tunnel Loading functionality, you can load specific tunnel configurations on specific DSG nodes.

Generating ECDSA certificate and key

The dh_params parameter points to a .pem file. The .pem file includes the DH parameters that are required to enable DH key exchange for improved protection without compromising computational resources required at each end. The value accepted by this field is the file name with the extension (.pem). The DSG supports both RSA certificates and Elliptic Curve Digital Signature Algorithm (ECDSA) certificates for the ECDHE protocol. The RSA certificates are available as default when the DSG is installed, while to use ECDSA certificates in the DSG, you must generate an ECDSA certificate and the related key. The following procedure explains how to generate the ECDSA certificate and key.

To generate dhparam.pem file:

1. Set the SSL options in the Inbound Transport settings as given in the following example.

   • DH Parameters: /opt/protegrity/alliance/config/dhparam/dhparam.pem
   • ECDH Curve Name: prime256v1
   • SSL Options: OP_NO_COMPRESSION

2. From the ESA CLI Manager, navigate to Administration > OS Console.

3. Execute the following command to generate the dhparam.pem file.

   openssl dhparam -out /opt/protegrity/alliance/config/dhparam/dhparam.pem 2048
   

Note: Ensure that you create the dhparam directory in the given path. The path /opt/protegrity/alliance/config/dhparam is the location where you want to save the .pem file. The value 2048 is the key size.

4. Execute the following command to generate the key.

openssl genpkey -paramfile dhparam.pem -out dhkey.pem

The ecdh_curve_name parameter is the curve type that is required for the key exchange. The OpenSSL curves that are supported by DSG are listed in Supported OpenSSL Curve Names.

You can configure additional inbound settings that apply to HTTP from the Global Settings page on the DSG Web UI.

3.1.4 - SFTP Tunnel

Based on the protocol selected, the dependent fields in the Tunnel screen vary. The following image illustrates that settings specific to SFTP protocol.

The options specific to the SFTP Protocol type are described in the following table.

**-The advanced settings that can be configured for SFTP Protocol.

The following snippet describes the example format for the SFTP Advanced settings:

{
   "idle_connection_timeout": 30,
   "default_window_size": 2097152,
   "default_max_packet_size": 32768,
   "use_compression": true,
   "ciphers": [
      "aes128-ctr",
      "aes256-ctr",
      "3des-cbc"
   ],
   "kex": [
      "diffie-hellman-group14-sha1",
      "diffie-hellman-group-exchange-sha1"
   ],
   "digests": [
      "hmac-sha1"
   ]
}

3.1.5 - SMTP Tunnel

The DSG can perform data security operations on the sensitive data sent by an Simple Mail Transfer Protocol (SMTP) client before the data reaches the destination SMTP server.

Over the internet, SMTP is an Internet standard for sending emails. When an email is sent to anyone, the email is sent using an SMTP client to the SMTP server. For example, if an email is sent from john.doe@xyz.com to jane.smith@abc.com, the email first reaches the xyz’s SMTP server, then reaches abc’s SMTP server, before it finally reaches the recipient, jane.smith@abc.com.

The DSG intercepts the communication between the SMTP client and server and performs data security operations on sensitive data. The sensitive data residing in the email elements, such as subject of an email, body of an email, attachments, filename, and so on, are supported for the SMTP protocol:

When the DSG is used as an SMTP gateway, the Rulesets must use the SMTP service and the first child Extract rule must be SMTP Message.

The following image illustrates how the SMTP protocol is handled in the DSG. Consider an example where, john.doe@xyz.com is sending an email to jane.smith@xyz.com. The xyz SMTP server is the same for the sender and the recipient.

1. The sender, john.doe@xyz.com, sends an email to the recipient, jane.smith@xyz.com. The Subject of the email contains sensitive data that must be protected before it reaches the recipient.

2. The DSG is configured with an SMTP tunnel such that it listens for incoming requests on the listening ports. The DSG is also configured with Rulesets such that an Extract rule extracts the Subject from the request. The Extract rule also defines a regex that extracts the sensitive data and passes it to the Transform rule. The Transform rule performs data security operations on the sensitive data.

   The DSG forwards the email with the protected data in the Subject to the SMTP server.

3. The recipient SMTP client polls the SMTP server for any emails. The email is received and the sensitive data in the Subject appears protected.

The following image illustrates the settings specific to the SMTP protocol.

The options specific to the SMTP Tunnel are described in the following table.

The ssl_options supported for the SMTP Tunnel are described in the following table.

* The following Listening Interface options are available:

• ethMNG: The management interface on which the DSG Web UI is accessible.
• ethSRV0: The service interface where the DSG listens for the incoming SMTP requests.
• 127.0.0.1: The local loopback adapter.
• 0.0.0.0: The broadcast address for listening to all the available network interfaces.
• Other: Manually add a listening address based on your requirements.

**-The advanced settings that can be configured for SMTP Protocol.

3.1.6 - NFS/CIFS

Though the files are accessed remotely, the behavior is same as when files are accessed locally. The NFS file system follows a client/server model, where the server is responsible for authentication and permissions, while the client accesses data through the local disk systems.

A sample NFS/CIFS tunnel configuration is shown in the following figure.

Note: The Address format for an NFS tunnel is <ip address/hostname>:<mount_path> and for a CIFS tunnel is \\<ip address or hostname>\<share_path>.

Consider an example NFS/CIFS server with folder structure that includes folders namely, /input, /output, and /lock. When a client accesses the NFS/CIFS server, the files are stored in the input folder. The Mounted File System Out-of-Band Service is used to perform data security operation on the files in the /input folder. A source file is processed only when a corresponding trigger file is created and found in the /input folder.

Note: Ensure that the trigger file time stamp is greater than or equal to the source file time stamp.

After the rules are executed, the processed files can be stored in a separate folder, such as in this example, /output. When DSG nodes poll NFS/CIFS server for a file uploaded, whichever node accesses the file first places a lock on the file. You can specify if the lock files must be stored in a separate bucket, such as /lock or under the source folder. If the file is locked, the other DSG nodes will stop trying to access the file.

If the data operation on a locked file fails, the lock file can be viewed for detailed log and error information. The lock files are automatically deleted if the processing completes successfully.

3.1.6.1 - NFS/CIFS

The options for the NFS tunnel as illustrated in the following figure

Mount settings

1 Mount Point - The Address format for an NFS tunnel is <IP address/hostname>:<mount_path>

2 Input Directory - The mount tunnel forwards the files present in this directory for further processing. This directory structure will be defined in the NFS/CIFS share.

3 Source File Name Pattern - Regex logic for identifying the source files that must be processed.

4 Overwrite Target File - Select to overwrite a file in the bucket with the newly processed file with the same name.

Rename processed files

Regex logic for renaming original source files after processed files are generated

5 Match Pattern - Exact pattern to match and filter the file.

6 Replace Value - Value to append or name that will be used to rename the original source file based on the pattern provided and grouping defined in regex logic.

Trigger File

File that triggers the rule. The rule will be triggered, only if this file is found to exist in the input directory. Files in the NFS/CIFS Share directory are not processed until the trigger criteria is met. Ensure that the trigger file is sent only after the files that need to be processed are placed in the source directory. After the trigger file is placed, you must touch the trigger file.

7 Trigger File Name Pattern - Identifier that will be appended to each source file to create a trigger control file. Consider a source file abc.csv, if you define the identifier as %.ctl, you must create a trigger file abc.csv.ctl to ensure that the source file is processed.

It is mandatory to provide a trigger file for each source file to ensure that it is processed. Files without a corresponding trigger file will not be processed.

The *, [, and ] characters are not accepted as part of the trigger file pattern.

8 Delete Trigger File - Enable to delete the trigger file after the source file is processed.

9 Lock Files Directory - Directory where the lock files will be stored. If this value is not provided as per the directory structure in the NFS/CIFS share, then the lock files will be stored in the mount point. Ensure that the lock directory name does not include spaces. The DSG will not process files under the lock directory that includes spaces.

10 Error Files directory - Files that fail to process are moved to this directory. The lock files generated for such files are also moved to this directory. For example, the file is moved from the /input directory to the /error directory.

11 Error Files Extension - Extension that will be appended to each error file. If you do not specify an extension, then the .err extension will be used.

Mount Options

Parameters that will be used to mount the share.

12 Mount Type - Specify Soft if you want the mount point to report an error, if the server is unreachable after wait time crosses the Mount Timeout value. If you select Hard, ensure that the Interrupt Timeout checkbox is selected.

13 Mount Timeout - Number in seconds after which an error is reported. Default value is 60.

14 Options - Additional NFS options that can be provided as inbound settings. If the lock directory is not defined, then the lock files are automatically placed in the /input directory. For example, {"port":1234, "nolock" "nfsvers": 3}. To enable enhanced security for the mounted share, it is recommended that the following options are set:

noexec,nosuid,nodev

where:

• noexec: Disallow execution of executable binaries on the mounted file system.
• nosuid: Disallow creation of set user id files on the file system.
• nodev: Disallow mounting of special devices, such as, USB, printers, etc.

15 Advanced Settings - Set additional advanced options for tunnel configuration, if required, in the form of JSON in the Advanced Settings textbox. For example, {"interval":5, "fileChunkSize": 4096}. In a scenario where an ESA and two DSG nodes are in a cluster, by using the Selective Tunnel Loading functionality, you can load specific tunnel configurations on specific DSG nodes.

Note: Ensure that the NFS share options are configured in the exports configuration file for each mount that the DSG will access. The all_squash option must be set to specify the anonuid and anongid with the user ID and group ID of the non-root user respectively.

This prevents the DSG from changing user and group permissions of the mount directories on the NFS server.

3.2 - Certificates/Key Material

This tab displays key material and other files in three different subtabs.

The Certificates/Key Material tab and subtabs are illustrated in the following figure.

The following table describes the available subtabs:

The following subtabs are available:

• Certificates

• Keys

• Other Files

3.2.1 - Certificates Tab

The certificates uploaded to DSG are displayed in this section. Other information such as paired key, validity, and last modified date is also displayed.

A certificate and key that is paired displays a ( ) icon indicating that the certificate is ready to use. A certificate or key without any pairing is indicated with a ( ) icon. If a certificate or key has expired, it is indicated with a ( ) icon. Files available in the Other Files subtab will always be marked with a ( ) icon.

The Cloud Gateway Certificate Expiration Check scheduled task is created by default to alert about certificates that are due to expire in the next 30 days.

Before you regenerate any default expired certificates, ensure that the best practices for certificates and keys are noted.

The Certificates subtab is shown in the following figure.

The following table describes the available options:

Callout	Icon (if any)	Column/Textbox	Description
1		Information	View Certificate details.
2		Download	Download a certificate.
3		Delete	Delete a Certificate.

3.2.2 - Delete Certificates and Keys

Clikc the Delete option in the Certificates/Key Material tab.

The Delete Certificate screen is shown in the following figure:

The following tables describes the available options:

3.2.3 - Keys Subtab

Keys cannot be downloaded, but the information can be viewed () or a key can be deleted ().

A certificate and key that is paired displays a ( ) icon indicating that the certificate is ready to use. A certificate or key without any pairing is indicated with a ( ) icon. If a certificate or key has expired, then it is indicated with a ( ) icon. Files available in the Other Files subtab will always be marked with a ( ) icon.

The supported key formats that can be uploaded are .crt, .csr, .key, .gpg, .pub, and .pem. For any private key without an extension, when you click Deploy to All Nodes, the permissions for the key changes to 755 making it world readable. To restrict the permissions, ensure that you generate the key with the .key extension.

The keys uploaded to the DSG can either be a non-encrypted private key or an encrypted private key. For either of the key types uploaded, the DSG ensures that the keys in the DSG ecosystem are always present in an encrypted format. When a non-encrypted private key is uploaded to the DSG, you are presented with an option to encrypt the key. If you choose to encrypt the key, DSG requests for a password for encrypting the key before it is stored on the DSG.

It is recommended that any non-encrypted private key is encrypted before it is uploaded to the DSG. Also,

It is recommended that any key uploaded to the DSG is of RSA type and a minimum of 3072-bits for optimum security.

3.2.4 - Other Files Subtab

A certificate and key that is paired displays a ( ) icon indicating that the certificate is ready to use. A certificate or key without any pairing is indicated with a ( ) icon. If a certificate or key has expired, it is indicated with a ( ) icon. Files available in the Other Files subtab will always be marked with a ( ) icon.

The following table describes the available subtabs:

Callout	Icon (if any)	Column/Textbox	Description
1		Information	View Certificate details.
2		Download	Download a certificate.
3		Delete	Delete a Certificate.

3.2.5 - Upload Certificate/Keys

Click Upload option in the Certificates tab to upload the certificate.

After clicking Upload Certificate, you can either upload a key or a certificate. When you upload a certificate, the password field does not appear.

After you click Choose File to select the key file, you must click Upload Certificate. Enter the password, and then click Upload Certificate again.

It is recommended that upload of any certificate or key is performed on the ESA. If the certificate is uploaded to a DSG node and configurations is deployed from ESA, then the changes made on the DSG node are overwritten by the configuration pushed by the ESA.

Note: Ensure that the passphrase for any key that is uploaded to the DSG Web UI is of minimum 8 character length.

If the key you uploaded is an encrypted private key, then you must enter the password for the key.

If the key you uploaded is a non-encrypted private key, an option is presented to encrypt the private key. If you select the option, you must provide a password that the DSG uses to encrypt the non-encrypted private key before it is stored internally.

The following figure illustrates the Upload Cerficate/Key screen

The following table describes the available options:

4 - Global Settings

The Global Settings allows to configure debug options, global protocol settings, and Web UI settings that impact the DSG.

The following image illustrates the UI options on the Global Settings tab.

The following table provides the description for each of the available RuleSet options:

Callout	Icon	Column/Textbox/Button	Description	Notes
1		Deploy to All Nodes	Deploy the configurations to all the DSG nodes in the cluster. Note: Deploy can also be performed from the Cluster tab.	In a scenario where an ESA and two DSG nodes are in a cluster, by using the Selective Tunnel Loading functionality, you can load specific tunnel configurations on specific DSG nodes. Click Deploy to All Nodes to push specific tunnel configurations from an ESA to specific DSG nodes in a cluster.
2		Expand	Expand the subtab and view available options.
		Collapse	Collapse the subtab to hide the available options.
3		Edit	Edit the available options in the subtab.

4.1 - Debug

The following figure illustrates the Debug tab.

The following table provides information about fields in the Debug tab.

* - Settings provided in these fields can be overwritten by the settings provided at Service/Ruleset level.

4.2 - Global Protocol Stack

The following figure illustrates the Global Protocol Stack tab.

The following table provides information about the fields in the Global Protocol Stack tab.

4.3 - Web UI

The following figure illustrates the Web UI tab.

The following table provides information about fields in the Web UI tab.

5 - Tokenization Portal

After you set up a cluster between the ESA and multiple DSG nodes, the policies are deployed on respective DSG nodes. Each policy has related data elements, data stores, and roles. You can use the Tokenization Portal menu to examine protection or unprotection of data when a protection data element is used.

The Tokenization Portal provides an interface where you can select the data security operation you want to perform, along with the DSG node, data elements available in the policies deployed at that node, and an external IV value. Every protection operation performed through the Tokenization Portal is recorded as an event in Forensics.

To access the test utilities, in the browser, enter (https://ESA/DSG_IP_Address/TokenizationPortal).

Before you access the Tokenization Portal, ensure that the following pre-requisites are met:

• Ensure that any user who wants to access the test utilities must be granted the Cloud Gateway User and Policy User permissions.
• Ensure that the ESA where you are accessing Tokenization Portal is a part of the cluster.
• Ensure that the policy on the ESA is deployed to all the DSG nodes in the cluster.
• Ensure that the policy is synchronized across all the ESAs in the cluster.

The following image illustrates the UI options on the Tokenization Portal tab.

The following table provides the description for each of the available Tokenization tab options:

Callout	Column/Textbox/Button	Sub-Columns	Description	Notes
1	Input Text		Enter the data you want to protect or unprotect.
2	Output Text		Transformed data, either protected or unprotected based on operation selected.
3	Output Encoding*		Select the type of encoding you want to use. Though the Output Encoding option is part of the Input Text area, remember that encoding is applied to Input data during protection and reprotection, and output data during unprotection.
4	Clear		Clear the text in the Input Text or Output Text box.
5	Unprotect/Protect/Reprotect		Click to perform security operation on the Input Text. You can either Protect, Unprotect, or Reprotect Data.	This option changes to Protect, Unprotect, or Reprotect based on the Action selected for data security operation.
6	Clear		Clear the text in the Input Text or Output Text box.
	Action Logs		Logs related to the data protection or unprotection are displayed under this area. These logs are cached in the browser session and are not persisted in the system.
7		Status	Displays if data security operation was successful.
8		DateTime	Date and time when the data security operation was performed.
9		External IV	External IV value that was used for the data security operation.
10		Data Element	Data element used.
11		DSG Node	The DSG node where the data security operation was performed.
12		Output	Transformed data.
13		Input	Input data.
14		Action	Data security operation performed.
15	New External IV		New external IV value that will be used along with the protect or unprotect algorithm to create more secure encrypted data.	This field applies to the Reprotect option only.
16	New Data Element		New data element that will be used to perform data security operation.	This field applies to Rthe eprotect option only.
17	External IV		External IV value that will be used along with the protect or unprotect algorithm to create more secure encrypted data.
18	Data Element		Data element that will be used to perform data security operation.
19	DSG Node		The DSG node where the data security operation will be performed.
20	Action		Data security operation, Protect, Unprotect, or Reprotect that you want to perform.

* - The available encoding options are as follows:

• Output Encoding: The field appears when action selected is either Protect or Reprotect.
• Input Encoding: The field appears when action selected is Unprotect.