Model Architecture

• 1: Overview
• 2: Model Architecture
• 2.1: Deployment with Default Audit Logging Flow to ESA
• 2.2: Deployment with Audit Logging Flow to External SIEM
• 2.3: Network Architecture Overview
• 2.4: Enterprise Security Administrator (ESA)
• 2.4.1: Infrastructure Requirements
• 2.4.2: Installing and Configuring ESA
• 2.4.3: ESA Upgrade Scenarios
• 2.4.3.1: Upgrading ESA
• 2.4.4: External Keystore Configuration
• 2.4.5: Scheduler Tasks
• 2.4.6: Backup and Restore
• 2.4.7: Insight
• 2.5: Recommended Traffic Manager
• 2.6: Disaster Recovery
• 2.6.1: Promoting Secondary ESA to Primary ESA
• 2.7: Fault Tolerance
• 2.8: Security
• 2.8.1: Open Ports
• 2.8.2: Certificate Requirements
• 2.8.3: FIPS Compliance Requirements
• 2.8.4: Users and Password Policy
• 2.8.5: File Integrity Monitoring
• 2.8.6: Delete Default System Certificates
• 2.8.7: Uninstall Consul
• 2.9: Data Security Gateway (DSG)
• 2.9.1: Installing and Configuring DSG
• 2.9.2: Upgrading ESA with DSG
• 2.10: Upgrading ESA with 9.1.0.0/10.x Protectors
• 2.11: Upgrading ESA with DSGs and 9.1.0.0/10.x Protectors
• 2.12: Standard Protectors
• 2.13: Forwarding Logs to External SIEM

1 - Overview

The Model Architecture for Protegrity Appliance consists of various components aimed at ensuring data security, high availability, fault tolerance, and effective disaster recovery. It includes an Enterprise Security Administrator (ESA), Data Security Gateway (DSG), standard protectors, and cloud protectors.

Purpose

Protegrity’s Model Architecture must support business continuity, agility, and scalability in production. It should be prescriptive but adaptable to user specific requirements for additional capacity, geo-proximity, and domain isolation by simply extending the deployment architecture in a cookie cutter manner. Adhering to the principles of such an architecture would increase the reliability of solutions while reducing QA and support costs.

Goals

• Provide a proven, standardized blueprint for building a Protegrity Appliance.

• Help to reduce risk and uncertainty in design and implementation.

• Allow for better consistency and collaboration among stakeholders and team members.

• Improve the overall efficiency and effectiveness of development and deployment.

• Enable users to leverage best practices and industry standards to achieve their goals.

• Serve as a baseline for future improvements and enhancements.

What is NOT the goal

• It is NOT a complete universal architecture for all user deployments.

  • Example: A user does not currently have the resources or infrastructure available to achieve the model architecture.

  • Example: A user cannot implement the changes needed in time for the next change window.

• It is NOT a mandated solution for the user to have support from Protegrity experts, not necessarily meaning just Protegrity Support.

When an architecture does not meet a modeled architecture, what to do?

• Ensure the user understands the limitations of not following a model architecture.

• This is not supposed to be a push for increased licensing but to get the user to a better architectural stance.

Audience

This document is intended for:

• Solution Architects, Solution Engineers, Technical Account Managers, Customer Success Managers, Support Engineers, Product Managers, Testers, and QA Engineers.

• Partners with corresponding technical roles.

Scope

The scope of this document includes:

• System Requirements: References to respective sections in documentation containing the detailed specifications of hardware and software prerequisites for deployment.

• Installation and Upgrade Procedures: References to respective sections in documentation containing the step-by-step instructions for installing the system and performing upgrades.

• Configuration Guidelines: Best practices and recommendations for configuring the system to meet operational needs.

• Best Practices for Maintaining and Operating the System: Guidelines on routine maintenance tasks and optimal operation strategies.

• Disaster Recovery Planning: Strategies and plans to recover and restore functionality in the event of a disaster. This includes failover and failback from Primary site to DR site and vice-versa.

• Fault Tolerance Strategies: Methods and techniques to ensure continuous operation and mitigate system failure risks.

• Security Measures: Security protocols and measures to protect the system from threats and vulnerabilities.

Key Concepts

The following key concepts are important to understand when reading the Model Architecture documentation.

GTM: Global Traffic Manager (GTM) is made available, configured, and controlled by the user. GTM is at a minimum required to achieve High Availability (HA) and Disaster Recovery (DR).

LTM: Local Traffic Manager (LTM) is made available, configured, and controlled by the user. LTM is required to achieve redundancy of ESAs in case of failover of primary ESA.

Replication Job: A manual replication job is required between the Primary ESA and all the Secondary ESAs.

Recovery Plan: A recovery plan is created and owned by the user.

For example, in an event of a failover, where Primary ESA is down, and Secondary ESA is up, and the load balancer points to Secondary ESA. It is the best practice to freeze policy changes during this period to avoid having to consider the role of Secondary ESA being altered. A recovery from this scenario is to resolve the reason the Primary ESA is down and let the load balance simply switch back to the primary ESA.

Keystore: It is made available, configured and controlled by the user. The Keystore is required when regulations standards such as PCI DSS, HIPAA or FIPS are required to be enforced.

Port and Connection: All ports and connection requirements must be met to ensure seamless operation and communication across system components.

2 - Model Architecture

2.1 - Deployment with Default Audit Logging Flow to ESA

The Model Architecture ensures comprehensive management of network resiliency through correctly configured traffic managers (GTM, LTM-1, and LTM-2) across both Primary and DR sites. Communication flows are meticulously routed to ensure high availability and redundancy.

The default logging flow from the protectors to the ESA is shown in the following image.

Legends

2.2 - Deployment with Audit Logging Flow to External SIEM

The architecture also supports forwarding logs from protectors to the External SIEM.

The logging flow from protectors to the ESA and the External SIEM is shown in the following image.

Legends

2.3 - Network Architecture Overview

This section lists the various sites and their components, supported protector versions, communication flows, and key measurements for the recommended model architecture across various dimensions.

Table 1. Sites and Components

Table 2. ESA Compatibility

Table 3. Communication Flows

The following table describes communication flows as depicted in diagrams in Deployment with Default Audit logging flow to ESA and Deployment with Audit logging flow to External SIEM.

Table 4. Key measurements for the recommended model architecture across various dimensions

The following table summarizes the key measurements for the recommended model architecture across various dimensions.

These measurements underscore the importance and effectiveness of adhering to a well-defined model architecture. Adherence ensures resiliency, fault tolerance, scalability, maintainability, and being adaptable to changes.

2.4 - Enterprise Security Administrator (ESA)

ESA handles the management of policies, keys, monitoring, auditing, and reporting of protected systems in the enterprise. ESA appliances have the Insight, and the td-agent service installed and are capable of hosting Docker containers.

The detailed Architecture diagram for ESA v10.2.0 is shown below.

2.4.1 - Infrastructure Requirements

• ESA: System Requirements
• DSG: Planning for Gateway Installation

2.4.2 - Installing and Configuring ESA

The ESA can be installed on-premise or a cloud platform such as AWS, GCP, or Azure. When upgrading from a previous version, the ESA installer is available as a patch.

Assumptions

• This section assumes that there is no prior installation of protegrity product and installation is happening from scratch.

• GTM and LTM are provisioned and installed.

  For more information about the prescribed configurations, refer to Recommended Traffic Manager.

This section explains about Installation and Configuration of ESAs as per Architecture Diagram in Deployment with Default Audit logging flow to ESA.

For more information about installing ESA on on-premise or cloud platforms, refer to Installation.

Prerequisites

Before proceeding with the installation, ensure the following prerequisites are met.

• Sites: Ensure that two sites are available — one designated for the Primary Site and another for the Disaster Recovery (DR) Site.

• Network Connectivity: Ensure there is reliable network connectivity between the Primary and DR sites.

Installing and Configuring ESA

1. Install ESA (ESA P1) in the Primary Site.

   For more information about detailed installation instructions for on-premise and cloud installation, refer to Installing ESA.

2. Initialize PIM in ESA P1.

   For more information about initializing PIM in ESA, refer to Initializing the Policy Information Management.

3. Initialize Analytics in the Insight in ESA P1.

   For more information about initializing Analytics, refer to Creating the Audit Store Cluster on the ESA.

4. Upload and apply Custom Certificates. Apply custom certificates for the following components:

   • Management Server/Client
   • Consul Server
   • Audit Store Server/Client
   • Audit Store REST Client
   • Insight Analytics Client
   • PLUG Client

   For more information about recommendations related to certificates for various components, refer to Certificate Requirements.

   For more information about steps to upload certificates in ESA, refer to Uploading Certificates.

   For more information about steps to apply certificates in ESA, refer to Changing Certificates.

5. Define policies for Data Security. On ESA P1, define the necessary data elements, policies and configure external member source.

   • For creating and managing External Member Source, refer to Working With Member Sources.

   • For Creating and Deploying Policies, refer to Creating and Deploying Policies

6. Configure Proxy Authentication and External LDAP. On ESA P1, configure proxy authentication for configuration with External LDAP for managing ESA Administration.

   For more information, refer to

   • Working with External Groups

   • Working with Proxy Authentication

   • Importing users to internal LDAP

7. Configuring ESA with External Keystore.

   For more information about setting ESA to External Keystore, refer to Section Switching HSM Modules in the HSM Integration Guide for ESA.

8. Configure Rollover Index Insight Scheduler Parameters. Set the rollover index scheduler parameters according to specific requirements.

   For more information about recommended configurations, refer to Index Rollover.

9. Configure Information Lifecycle Management (ILM) Export Insight Scheduler Parameters. Adjust the ILM export scheduler settings based on the requirements.

   For more information about recommendation configurations for ILM Export, refer to ILM Export.

10. Configure ILM Multi Delete Insight Scheduler Parameters. Set the ILM Multi Delete insight scheduler parameters according to specific requirements.

For more information about recommendation configurations for ILM Multi Delete, refer to [ILM Delete](/docs/model_arch/model_arch/esa/insight.md#ilm-delete). <!-- fix link here -->

11. Configure Alerts. Set up the required alerts to monitor system health and events.

For more information about recommendations related to configuration of alerts, refer to [Alerting](/docs/model_arch/model_arch/esa/insight.md#alerting). <!-- fix link here -->

12. Install additional ESAs.

    1. In the Primary Site, install two additional ESAs: ESA S1 and ESA S2.

    2. In the DR Site, install three ESAs: ESA S3, ESA S4, and ESA S5.

13. Create Trusted Appliances Cluster (TAC) between all ESAs in Primary and DR site. Create a TAC between ESAs P1, S1,S2 in Primary and ESAs S3,S4,S5 in DR Site.

For more information about creating TAC, refer to [Creating a TAC using the Web UI](/docs/aog/trusted_appliances_cluster/aog_creating_tac_ui/).

14. Form an Insight Cluster: Join ESA S1 and ESA S2 to ESA P1 to form a robust and redundant Insight Cluster. Form Insight cluster in DR site between ESA S3,S4 and S5.

For more information about creating Insight cluster, refer to [Creating an Audit Store cluster](/docs/installation/upg_creating_audit_store_cluster/).

15. Create Replication Tasks. Establish a replication task on ESA P1 to replicate all ESA data—excluding SSH settings—to ESA S1, S2, S3, S4, and S5.

    For more information, refer to ESA Primary to Secondary Replication Job in the Scheduler Tasks.

    For more information about configuring scheduled task for cluster export, refer to Scheduling Configuration Export to Cluster Tasks.

16. Enable ILM Multi Export Scheduler task. By default, ILM Multi Export Scheduled task is disabled. So, it is necessary to enable this task and configure as per requirements.

    For more information about ILM Multi Export, refer to Exporting logs.

17. Create Scheduled Tasks for copying ILM Exported Files from Primary Site to DR Site. Create a scheduled task in each of the ESAs in the primary site, that is, ESA P1, ESA S1, ESA S2. This task must copy ILM exported files from ESA P1, ESA S1, and ESA S2 to ESAs in DR site, that is, ESA S3, ESA S4, and ESA S5 in the DR Site.

    For recommendations, refer to ESA Exported Indexes Purge in Scheduler Tasks.

    For more information, refer to Creating a scheduled task.

18. Create Scheduled task for taking backup of ESA P1 to a file.

    For recommendations, refer to Back up Primary ESA data to file in Scheduler Tasks.

Keep a detailed log and documentation of each step performed for future reference and troubleshooting.
Meticulously following these steps help establish a resilient and secure ESA infrastructure that aligns with the specified model architecture diagram.

2.4.3 - ESA Upgrade Scenarios

Overview

This section provides a comprehensive guidance for upgrading ESA deployments across different scenarios. The upgrade scenario you choose, depends on your current deployment architecture, including the presence of Protectors and DSGs.

Upgrade Scenarios

Select the appropriate upgrade scenario based on the current deployment configuration:

ESA with v9.1.0.0 or v10.x Protectors

This scenario addresses environments where ESA is deployed with Protector running version 9.1.0.0 or later.

• Upgrading ESA with v9.1.0.0 or v10.x Protectors

ESA with DSG

This scenario covers deployments utilizing DSGs.

• Upgrading ESA with DSG

ESA with DSGs and v9.1.0.0 or v10.x Protectors

This scenario applies to deployments incorporating both DSGs and Protectors.

• Upgrading ESA with DSGs and v9.1.0.0 or v10.x Protectors

2.4.3.1 - Upgrading ESA

This section describes steps to upgrade ESAs.

To ensure compatibility and leverage new features, security fixes, and enhancements, it is necessary to upgrade the ESA to the latest version. This section outlines the required steps for upgrading from a previous version, applicable to both on-premise and cloud platforms.

Before you begin

Before beginning the upgrade, be sure to adhere to the following guidelines.

1. Freeze Policy and Ruleset Changes

   Before upgrading the ESA, ensure all policy and ruleset changes are frozen.

   No changes to the policies and rulesets should be made until the completion of the ESA upgrade.

2. Freeze Configurations in ESA

   Prior to upgrading the ESA, freeze all configurations within the ESA. Ensure no configuration changes are made to any components in any of the ESAs until the upgrade is complete.

   This section elaborates on the upgrade and configuration process for ESAs as per the Deployment with Default Audit logging flow to ESA Architecture diagram.

   For more information about upgrading ESA, refer to Upgrading ESA to v10.

Upgrade Steps

1. Backup all ESAs.

   • On-Premise: Perform a full OS backup of all ESAs at both sites.

   • Cloud Premises: Take snapshots of each instance to ensure a restore point is available should any issues arise during the upgrade process.

     • For on-premise, refer to Working with OS Full Backup and Restore.

     • For AWS, refer to Backing up and Restoring Data on AWS.

     • For GCP, refer to Backing up and Restoring Data on GCP.

     • For Azure, refer to Backing up and Restoring VMs on Azure.

2. Disable the TAC replication job from Primary ESA P1.

   Follow these steps to disable the TAC replication scheduled task:

   1. On the Primary ESA P1 Web UI, navigate to System > Task Scheduler.
   2. Click on the TAC replication scheduled task.
   3. Click Edit.
   4. Uncheck the Enable checkbox to disable the task.
   5. Click Save to save the changes.
   6. Click Apply to apply the changes.

3. Ensure all the prerequisites are followed before proceeding with the upgrade of each ESA.

   For more information about the prerequisites, refer to Prerequisites.

4. Upgrade ESAs S3, S4, and S5 at the Disaster Recovery (DR) site in parallel.

   For more information on upgrading ESA, refer to:

   • Prerequisites
   • Upgrade Paths to ESA v10.2.0
   • Upgrading from v9.1.0.x
   • Upgrading from v9.2.0.x
   • Upgrading from v10.x
   • Verifying the ESA Patch Installation
   • Verifying the health of Trusted Appliance Cluster

5. Validate DR Site ESAs post upgrade.

   • Conduct a thorough validation of the upgraded ESAs at the DR site to confirm operational integrity and successful upgrade.

   • Perform the following validations in all the ESAs.

     1. Log in to ESA Web UI.

     2. Check for correctness of the version under About.

     3. Navigate to Key Management > Key Stores in ESA Web UI and ensure that External Keystore configurations are intact.

     4. Navigate to Settings > Users and check that External Groups settings are intact.

     5. Navigate to Audit Store > Cluster Management. Check if ESAs S3, S4, and S5 are visible under Nodes tab, and the Cluster Status is GREEN.

6. Upgrade ESAs P1, S1 and S2 at the Primary site in parallel.

   For more information on upgrading ESA, refer to:

   • Prerequisites
   • Upgrade Paths to ESA v10.2.0
   • Upgrading from v9.1.0.x
   • Upgrading from v9.2.0.x
   • Upgrading from v10.x
   • Verifying the ESA Patch Installation
   • Verifying the health of Trusted Appliance Cluster

7. Validate Primary Site ESAs post upgrade.

   Conduct a thorough validation of the upgraded ESAs at the primary site to confirm operational integrity and successful upgrade.

   Perform the following validations in all the ESAs:

   1. Log in to ESA Web UI.

   2. Navigate to Key Management > Key Stores in ESA Web UI and ensure that External Keystore configurations are intact.

   3. Navigate to Settings > Users and check that External Groups settings are intact.

   4. Navigate to Audit Store > Cluster Management. Check if ESA P1, S1, and S2 are visible under Nodes tab, and the Cluster Status is GREEN.

8. Enable Scheduler tasks in Primary ESA P1.

   Enable the TAC replication scheduler task in Primary ESA P1. For replicating scheduler tasks, refer to Scheduler Tasks.

9. Migrate Audit logs from DR site ESAs to Primary site ESAs.

   When the traffic from protectors is redirected to the DR site ESAs, audit logs are generated in these ESAs. These audit logs must be migrated to Primary site ESAs.

   Before proceeding with executing the steps, take a note of the following:

   1. Take a note of the time in hours/days that the protectors were pointed to DR site ESAs.

   2. Under Audit Store > Cluster Management, on the Indices tab, make note of the indices that were created during the time frame in the preceding step.

   3. Take a note of the ILM exported indexes that are created under the directory /opt/protegrity/insight/archive in each of the ESAs in DR site for that time frame.

   To migrate Audit logs from DR site ESAs to Primary site ESAs, perform the following steps:

   1. Log in to the web UI of ESA S3 in the DR site.

   2. Perform ILM Export of all the indexes noted at step 2.

   For more information about performing ILM Export, refer to Exporting logs.

   3. Log in to OS console of ESA S3. Navigate to the directory /opt/protegrity/insight/archive.

   4. Copy all the exported index files generated by ILM Export operation at step 2. Transfer these index files to ESA S2 in primary site under directory /opt/protegrity/insight/archive.

   5. Additionally, log in to all the ESAs containing ILM exported index files noted at step 3 above and copy them to ESA S2 under directory /opt/protegrity/insight/archive.

   6. Finally, perform ILM Import of all the index files copied from ESAs in DR site as per step 4 and step 5.

   For more information related to ILM Import, refer to Importing logs.

Additional Considerations

• Documentation: Maintain detailed records of the upgrade procedure for future reference.

• Troubleshooting: Have contingency plans in place to address potential issues arising during the upgrade. For more information on troubleshooting, refer to Troubleshooting.

• Support: Utilize Protegrity support services for guidance or troubleshooting assistance as needed. For assistance, contact Protegrity Support at support@protegrity.com.

By following these structured steps, the upgrade and configuration of ESAs will be executed effectively, ensuring minimal downtime, and maintaining system integrity.

2.4.4 - External Keystore Configuration

To enhance security, Protegrity products can be integrated with external Key Stores. For more information to configure ESA with External Key Store, refer section Configuring ESA Appliance or DSG Appliance to Communicate with Safenet HSM in the HSM Integration Guide on the My.Protegrity portal.

2.4.5 - Scheduler Tasks

To maintain the resiliency, efficiency, and reliability of the ESA, it is essential to set up scheduled tasks.

The recommended scheduled tasks to configure on the ESA is provided here.

Task Summary and Description

1. ESA Primary to Secondary Replication Job

• Description: This task must be configured in primary ESA P1. It performs replication of data from the Primary ESA P1 to all the secondary ESAs, that is, ESA S1, ESA2, ESA S3, ESA S4, ESA S5.

• Frequency: Recommended to run daily at midnight. It is important that this task must be executed immediately after a change in policy or rulesets. It must also be performed in case of changes made to any of the keys under Key Management menu in ESA Web UI.

Important: Ensure only the following items are selected as part of this Cluster Export task.

Appliance OS Configuration: Export OS configuration

• Web Settings
• Firewall Settings
• Appliance Authentication Settings
• Appliance JWT Configuration
• Appliance AZURE AD Configuration (If Azure AD is being used)
• Time-zone and NTP settings
• OS Services Status
• Appliance FIM Policies and Settings
• User custom list of files (If custom files are present)

Directory Server And Settings: Export directory services and related settings

• LDAP Server

Export Consul Configuration and Data

• Import Consul Certificates and keys

Cloud Utility AWS: Cloud Utility AWS CloudWatch configuration files

• Import Cloud Utility AWS CloudWatch configuration files

Backup Policy-Management for Trusted Appliances Cluster: Backup All Policy-Management Configs, Keys, Certs and Data for Trusted Appliance Cluster

• Import All Policy-Management Configs and Data for Trusted Appliance Cluster

Policy Manager Web UI Settings: Export policy manager web ui settings

• Import policy manager web ui settings

Export Gateway Configuration Files: Gateway Config Files Export

• Gateway Config Files Import

Do not select the below options as part of this cluster export task

• SSH settings
• Management and WebServices Certificates
• Certificates
• Import All Policy-Management Configs, Keys, Certs, Data but without Key Store files for Trusted Appliance Cluster

Important: Scheduled tasks are not replicated as part of cluster export.

2. ESA Exported Indexes Move

• Description: This task must be configured in all the ESAs in primary site, that is, ESA P1, ESA S1, and ESA2. It moves the ILM exported index files from respective ESAs, that is, ESA P1, ESA S1 and ESA S2 to ESA S5 in DR site.

• Frequency: Recommended to run weekly.

3. Back up Primary ESA data to file.

• Description: This task must be configured in primary ESA P1. It backs up data from Primary ESA to a file and moves it to a remote machine.

• Frequency: Recommended to run weekly.

  Important: Ensure only the following items are selected as part of this File Export task.

• Appliance OS Configuration

• Directory Server And Settings

• Export Consul Configuration and Data

• Cloud Utility AWS (if AWS Cloud Utility is configured and being used)

• Backup Policy-Management

• Policy Manager Web UI Settings

• Export Gateway Configuration Files

Do not select the below option as part of this file export task

• Backup Policy-Management for Trusted Appliances Cluster without Key Store.

Important: Scheduled tasks are not backed up as part of file backup.

2.4.6 - Backup and Restore

Effective backup and restore procedures are crucial for ensuring data integrity and system reliability.

Below are the key backup and restore strategies to implement in the ESA environment:

Full OS

• Description: Backup of the complete operating system including all configurations, applications, and user data in ESA. This is applicable only for on-prem environment.

• Frequency: Recommended weekly or before and after significant changes such as upgrade.

• Restore Steps: Boot into a System Restore Mode to restore to last backed up state.

For more information to perform full OS backup and restore, refer to Working with OS Full Backup and Restore.

Important: The Full OS Backup/Restore features of the Protegrity appliances is available only for the on-premise deployments. It is not available for virtual machines created using an OVA template and cloud-based virtual machines.

Cloud

• Description: Create snapshots of ESA instances for disaster recovery. This is applicable only for cloud environment.

• Frequency: Recommended weekly or before and after significant changes such as upgrade or changes to policy in ESA.

• Restore Steps: Restore the snapshot by following the cloud provider-specific restore procedure.

File

• Description: Ensure that ESA data is regularly backed up and stored securely. Automating the process using scheduled task in ESA will help maintain consistency and reduce manual intervention. The restore steps allow easy recovery of data, ensuring minimal disruption in case of failure.

• Frequency: Recommended weekly or before and after significant changes such as upgrade or changes to policy in ESA. It must also be performed in case of changes made to any of the keys under Key Management menu in ESA Web UI.

• Tools: Configure Scheduled task in ESA to use tools like rsync, scp to copy exported backup files from ESA to an external machine. Ensure backup files are created along with timestamp. For more information, refer to Back up Primary ESA data to file.

• Restore Steps: Upload the required backed up matching the required timestamp to the ESA and initiate import. For more information about importing the backup file, refer to Importing Data/Configurations from a File.

Important: Scheduled tasks are not backed up as part of file backup.

Custom Files

The following custom files should be backed up and included as part of customer.custom to ensure they are replicated to all ESAs in the cluster during replication jobs:

• Any custom files for td-agent.

• Any custom files related to External HSM configurations, shared library files.

• Any changes to rsyslog.

For more information about adding the required custom files as mentioned above, refer to Working with the custom files.

2.4.7 - Insight

Insight Analytics and Audit (Insight) leverages OpenSearch and OpenSearch Dashboard to perform analytics on audit events and log messages aggregated in the Audit Store. Both are distributed as Docker containers that can be hosted on ESAs.

ILM Export

This section outlines the ILM export configuration for various log and metric indices. The objective is to manage the lifecycle of these indices efficiently, ensuring data is archived or deleted as required.

ILM Export Configuration Considerations

• Maximum size: Defines the maximum size an index can reach before getting exported.

• Maximum doc count: Defines the maximum doc count an index can reach before getting exported.

• Maximum index age: Defines the maximum age an index can reach before getting exported.

• Conditions: ILM Export occurs when either of the above limits is reached where index entries from the index are removed and archived to a file.

For more information about configuring ILM Export, refer to ILM Multi Export.

ILM Delete

This section outlines the ILM export configuration for various log and metric indices. The objective is to manage the lifecycle of these indices efficiently, ensuring data is archived or deleted as required.

ILM Export Configuration Considerations

• Maximum size: Defines the maximum size an index can reach before getting deleted.

• Maximum doc count: Defines the maximum doc count an index can reach before getting deleted.

• Maximum age: Defines the maximum age an index can reach before getting deleted.

• Conditions: Deletion occurs when either of the above limits is reached.

For more information about configuring ILM Delete, refer to ILM Multi Export.

Index Rollover

This section details the index rollover settings for various log and metric indices. Efficient rollover policies ensure high performance and manageability of the indices.

Index Deletion Configuration Considerations

• Maximum size: Defines the maximum size an index can reach before rolling over.

• Maximum doc count: Defines the maximum doc count an index can reach before rolling over.

• Maximum age: Defines the maximum age an index can reach before rolling over.

• Conditions: Index Rollover occurs when either of the limits is reached.

For more information about configuring Audit Index Rollover, refer to Audit Index Rollover.

Alerting

Create a scheduled task in all the ESAs to monitor and log spikes in CPU, memory, or disk usage that exceed configured thresholds. These logs must be systematically forwarded to the Insight within the ESA.

For more information about configuring alerts, refer to Working with alerts.

Requirements

1. Monitoring Metrics: The task should observe the following system metrics:

   1. CPU Usage
   2. Memory Usage
   3. Disk Usage

2. Threshold Configuration

   1. Define specific thresholds for CPU, memory, and disk usage.
   2. Ensure these thresholds can be adjusted as needed.

3. Log Generation

   Generate detailed logs whenever a spike in CPU, memory, or disk usage exceeds the configured threshold.

4. Log Forwarding

   Implement mechanisms to forward these logs to the Insight within the ESA.

Implementation Steps

1. Script Development

   • Develop a script to monitor CPU, memory, and disk usage.
   • Incorporate threshold parameters into the script.

2. Schedule the task using Task Scheduler.

   For more information about creating scheduled task using task scheduler, refer to Creating a scheduled task.

3. Logging Mechanism

   Use logger library to write logs to syslog.

4. Test and Validate

   • Conduct thorough testing to ensure the script accurately detects and logs spikes.

   • Validate that logs are correctly forwarded to and received by the Insight.

By implementing this scheduled task, the ability to monitor system health and respond proactively to potential issues is enhanced, thereby improving overall system stability and security compliance.

Audit Store Dashboards

It is recommended that default dashboards in ESAs are not modified or deleted.

For more information on Protegrity provided dashboards, refer to Working with Protegrity dashboards.

2.5 - Recommended Traffic Manager

The Global and Local Traffic Manager should be a Layer-4 Proxy/Load Balancer. Alternatively, it could also be a DNS Switch.

Layer-4 Proxy/Load Balancer

A Layer-4 proxy/load balancer operates at the transport layer, which means it handles traffic based on IP address and TCP/UDP ports. This type of load balancer is efficient for distributing traffic evenly across servers without inspecting the actual application data.

Examples

HAProxy: A reliable, high-performance TCP/HTTP load balancer.

Nginx: Can be configured to operate as a Layer-4 load balancer.

Configuration Example (HAProxy)

frontend tcp_in
    bind *:8443
    mode tcp
    default_backend esa_servers

backend esa_servers
    mode tcp
    balance first
    server esa1 192.168.1.2:8443 check
    server esa2 192.168.1.3:8443 check backup
    server esa2 192.168.1.4:8443 check backup

DNS Switch

A DNS switch changes the DNS records to direct traffic to different servers based on predefined rules. It can be used for simple load balancing or failover scenarios.

Examples

• Amazon Route 53: AWS’s scalable DNS and domain name registration service.

Configuration Considerations for DNS Switch

• TTL Settings: Keep TTL low for quicker propagation of changes.

• Health Checks: Ensure the DNS provider supports health checks and automatic failover.

• Geo-routing: Use geographical routing to minimize latency for users.

Ports Eligible for Load Balancer/Proxy with Active and DR Flows

2.6 - Disaster Recovery

In the realm of Disaster Recovery, multiple ESA instances are organized into a TAC in different sites, that is, Primary site and DR site to ensure Disaster Recovery (DR). The following details outline how this system is configured and operates:

Cluster Configuration

1. Primary-Secondary Replication: Changes made on the Primary ESA P1 to files, configurations, and other data are replicated over a trusted channel to Secondary ESAs, ESA S1, S2, and S3 in the primary site. The same changes are also replicated to ESA S4, S5, and S6 in the DR site.

   For more information about replicating primary ESA to secondary, refer to ESA Primary to Secondary Replication Job.

2. Failover Mechanism: If the Primary becomes unavailable, a Secondary can be promoted to Primary to maintain operational continuity.

   For more information about promoting Secondary ESA to Primary ESA, refer to Promoting Secondary ESA to Primary ESA.

3. Back up Primary ESA P1 data to a file: Alternatively, backed up file from primary ESA P1 can also provide disaster recovery.

   For more information, refer to Back up Primary ESA data to file.

2.6.1 - Promoting Secondary ESA to Primary ESA

Promoting Secondary ESA to Primary ESA

If there is a failover from Primary ESA P1 to Secondary ESA S3 in the DR Site, refer to Architecture Diagram. If the downtime of Primary ESA P1 is going to be for more than an hour, then it is recommended to perform the following steps:

1. Make secondary ESA S3 as Primary. Create a replication task to replicate the Policy Management and other required data from Secondary ESA S3 to Primary ESA P1.

2. As soon as the Primary ESA P1 is online, ensure to disable the replication task that is already created.

Perform the following steps for performing failover from Primary to DR Site and failback, that is, from DR site to Primary site:

1. Failover to DR site

   Since ESA P1 in primary site is down, failover to DR site’s ESA, that is, ESA S3 happens.

2. Promote Secondary ESA to Primary in DR Site

   Secondary ESA S3 is now promoted to Primary by enabling the TAC replication job to replicate from ESA S3 to all other ESAs.

3. Bring up ESA P1 in Site A as Secondary

   1. Once ESA P1 in primary site is ready to be brought up, bring it up as secondary ESA.

   2. As ESA S3 is already elevated to Primary, ESA P1 would start getting the latest updates from ESA S3 through replication.

      This can be confirmed through the following steps:

      a. Log in to ESA P1 Web UI.

      b. Navigate to System > Task Scheduler.

      c. Select the replication task.

      d. Scroll down the page to view the details of the scheduled task.

      e. Ensure that Exportimport command in the Command line shows the updated command as per Step 2.

   3. Allow for replication tasks from ESA S3 to ESA P1 to happen for atleast 2 cycles.

4. Failback to Primary Site

   1. After the original primary ESA P1 is replicated from primary ESA S3, then follow these steps to disable the replication task in ESA S3 to other ESAs.

      a. Log in to web UI of ESA S3.

      b. Disable the replication task to replicate data from ESA s3 to other ESAs.

   2. Perform the following steps to enable replication task in ESA P1:

      a. Log in to web UI of original primary ESA P1.

      b. Enable the replication task to replicate data from ESA P1 to ESA S3.

      c. Restore GTM to point to primary site.

      d. Validate that all the pepserver node entry in the ESA P1 is GREEN.

2.7 - Fault Tolerance

The Fault Tolerance strategy encompasses measures to ensure that the ESA infrastructure remains robust against failures and continues to operate optimally under various failure conditions. The key aspects include the following.

ESA Redundancy

Achieve network redundancy by utilizing multiple network paths to prevent single points of failure in the network infrastructure for ESA, that is, having GTM/LTM architecture.

Load Balancing

Deploying load balancers not only aids in disaster recovery but also ensures balanced distribution of traffic specially for forwarding logs to prevent any single ESA from becoming a bottleneck.

Regular Testing

• Periodically test failover mechanisms to ensure that they work correctly when needed.

• Conduct regular DR drills to verify that the transition from primary to DR site occurs smoothly without service disruption.

Proactive Monitoring

Continuously monitor ESA performance and health metrics to detect issues early and take corrective actions before they escalate into major problems. This can be done by configuring alerts to monitor system monitoring metrics. For more information, refer to Alerting.

2.8 - Security

These guidelines are intended to enhance the overall security posture, safeguard sensitive information, and mitigate potential risks. By adhering to these recommendations, organizations can ensure a more secure and resilient environment for their operations.

2.8.1 - Open Ports

For information about the list of ports that needs to be configured to access the features and services on the Protegrity Products, refer to Open listening ports.

2.8.2 - Certificate Requirements

The following table outlines the certificate requirements for various components within the ESA infrastructure:

The following table provides an example of the recommended deployment architecture in the Model Architecture section.

2.8.3 - FIPS Compliance Requirements

It is recommended to enable FIPS mode in all the ESAs.

For more information about configuring FIPS mode in ESA, refer to FIPS Mode.

2.8.4 - Users and Password Policy

A robust users and password policy is essential to ensure the security of the system by controlling access and maintaining the integrity of user accounts.

The following guidelines outline the key requirements for managing users and passwords within the system:

Password Creation

1. Enforce strong password creation policies.

   • Minimum length: 8 characters
   • Complexity: Must include uppercase letters, lowercase letters, numbers, and special characters.

2. Prohibit the use of common passwords and passwords from known data breaches.

3. Employ mechanisms to prevent the reuse of previous passwords such as, history of 5 previous passwords.

Password Protection

Use multi-factor authentication (MFA) to provide an additional layer of security.

Password Change Requirements

1. Require users to change their passwords at regular intervals, for example, every 90 days.

2. Force password changes immediately if a compromise or suspicion of compromise is detected.

3. Provide mechanisms for users to securely reset their passwords.

Account Lockout Policies

1. ESA is configured with account lockout after 3 unsuccessful login attempts.

2. If an external account manager is used:

   • Implement account lockout after a specified number of failed login attempts, for example, locking out after 3 unsuccessful attempts.

   • Define a lockout duration or require administrative intervention to unlock accounts.

   For more information about password policy for appliance users, refer to Password Policy for all appliance users.

2.8.5 - File Integrity Monitoring

Ensure File Integrity Monitoring scheduled task is enabled in ESA.

For more information about the file integrity monitoring, refer to Working with File Integrity.

2.8.6 - Delete Default System Certificates

To enhance the security of your system, it is strongly recommended that all default system certificates must be deleted after the application of custom certificates. This is outlined in the Certificate Requirements. Implementing the custom certificates ensures that the encryption credentials are unique to your organization and align with your specific security protocols.

2.8.7 - Uninstall Consul

For enhanced security, it is advisable to uninstall Consul from the ESA. Consul necessitates the inclusion of ’localhost’ in the Subject Alternative Name (SAN) field of certificates, which can introduce potential vulnerabilities.

To maintain a secure environment and adhere to best practices, TAC can be configured without integrating with Consul.

For more information about configuring TAC without consul, refer to Configuring a Trusted Appliance Cluster (TAC) without Consul Integration.

2.9 - Data Security Gateway (DSG)

The DSG is a flexible platform that applies security operations on the network to protect sensitive data in various environments, including on-premises, virtualized, and cloud. It safeguards data across SaaS applications, web interfaces, APIs, and file transfers using Configuration over Programming (CoP) profiles.

Architecture diagram for DSG v4.0.0

Architecture diagram for ESA v10.2.0 with v4.0.0

Architecture diagram for DSG v4.0.0 in TAC

Communication Flow

DSG-1: DSG node configured during DSG patch installation in ESA.

DSG-2 to DSG-n: Other DSGs in TAC

The following table describes communication flows as depicted in diagrams above.

2.9.1 - Installing and Configuring DSG

Before you begin

Before you begin installing and configuring DSG, consider the following.

Assumptions

This section assumes that

• There is no prior installation of DSG. Installation of DSG is happening from the beginning..

• GTM and LTM are provisioned and installed. For information about prescribed configurations for GTM or LTM, refer to Recommended Traffic Manager.

Prerequisites

• Ensure there is good network connectivity between the machine where DSG is going to be installed and all the ESAs, and they can communicate with each other.

• Ensure ESAs in both the Primary site, ESA P1, S1, S2, and the DR site, ESA S3, S4, S5, are up and running.

• Ensure that ESAs in both sites are in a TAC.

• Ensure that PIM is initialized on all the ESAs.

• Ensure that ESAs in Primary site are in an Audit Store Cluster and ESAs in DR site are in a separate Audit Store Cluster.

• Ensure all ESAs and DSGs are in the cluster, and that they themselves are reachable using hostname or FQDN.

1. Installing and Configuring the DSGs.

   1. Install DSGs v4.0.0.

      For more information about installing DSG v4.0.0, refer to Installing the DSG.

   2. Create a TAC. Create a TAC in one of the DSGs installed in the previous step.

   3. Join DSGs to the TAC. Join the rest of the DSGs to the TAC created in the previous step.

   4. Upload and Install DSG Management Server Certificates. Upload and install DSG Management Server certificates in each of the DSGs individually. Ensure the SAN field in each of the certificates has the hostname and FQDN of the DSG node it is going to be installed in.

2. Perform ESA Communication.

   Perform ESA communication from all the DSGs. For all the options in ESA communication, provide GTM IP, hostname, or FQDN as applicable.

   For more information about performing set ESA communication, refer to Setting up ESA communication.

3. Install DSG patch on all the ESAs in the Primary and DR site.

   Install DSG v4.0.0 patch on all ESAs in both sites, that is, ESA P1, S1, S2 in the primary site and ESA S3, S4, S5 in the DR site.

4. Register DSG with ESA.

   During the prompt for DSG details during DSG registration, provide any of the DSG’s FQDN/hostname in TAC. Ensure the same DSG FQDN or hostname is provided during DSG registration in all other ESAs.

5. Upload and apply DSG Admin Tunnel Certificates.

   Upload and apply DSG Admin tunnel certificates from Web UI in ESA P1.

   For more information regarding uploading and applying DSG Admin tunnel certificates, refer to Upload Certificate/Keys.

6. Create and Deploy DSG Tunnels and Ruleset.

   1. Create Tunnels and Ruleset.

      Create tunnels and rulesets from the Web UI in ESA P1.

      For more information related to creating tunnels, refer to Tunnels.

      For more information related to creating rulesets, refer to Ruleset Reference.

   2. Deploy Rulesets.

   Click on the Deploy button from the DSG’s Cluster page in ESA P1 to deploy rulesets in all the DSGs present in the TAC.

   For more information related to deploying rulesets, refer to Deploying configurations to the cluster.

7. Check Health Status of DSGs under Cluster Page.

   After the deployment of rulesets is successful, check the health status of DSGs in TAC from the DSG’s Cluster page in ESA P1. All the DSGs should show health status as green.

8. Ensure TAC Replication Job includes DSG configuration.

   Ensure that the TAC replication job also includes the DSG configuration. This configuration must be replicated from the Primary ESA P1 to all Secondary ESAs, S1, S2, S3, S4, and S5.

Make sure to follow these steps meticulously to ensure a seamless installation and configuration process.

2.9.2 - Upgrading ESA with DSG

This section describes the steps to upgrade ESAs with DSG (Data Security Gateway) installed. To ensure compatibility and leverage new features, security fixes, and enhancements, both ESAs and DSGs must be upgraded to the latest version.

Prerequisites

Before proceeding with the upgrade, ensure the following requirements are met:

• All ESAs must be on v9.1.0.0 or above.
• All DSGs must be on v3.1.0.0 or above.
• Ensure network connectivity between the DSG installation machine and all ESAs.
• Ensure ESAs in both Primary site (ESA P1, S1, S2) and Disaster Recovery (DR) site (ESA S3, S4, S5) are operational.
• Ensure all ESAs and DSGs in the cluster are reachable using hostname or FQDN.
• Ensure all ESAs and DSGs are using common CA.
• Review the before you begin section.

Related Documentation

If DSGs are installed along with other v9.1.0.0 protectors, refer to Upgrading ESA with DSGs and Protectors.

Upgrade Approaches

There are two upgrade approaches available for DSG, a canary upgrade and an in-place upgrade.

• The canary upgrade reimages DSG instances to the newer version using ISO or cloud images. Refer to Canary Upgrade for instructions.

• The in-place upgrade is for upgrading existing instances using patches. Refer to In-place Upgrade for instructions.

Select the appropriate upgrade approach based on organizational requirements, infrastructure constraints, and operational considerations.

Important: Both upgrade approaches will incur DSG downtime during the upgrade process. Plan accordingly to minimize impact on production operations.

Canary Upgrade

The canary upgrade involves reimaging existing DSG instances to the newer version using ISO or cloud images. This can be performed by reusing the same instance or spawning a new instance for DSG and terminating the older version DSGs.

Important: DSG downtime will occur during upgrade. However, downtime can be minimized by spawning fresh DSGs v4.0.0 in parallel to upgrading ESAs.

Phase 1: DR Site Upgrade

1. Backup all ESAs.

   For backing up ESAs, refer to Backup all ESAs.

2. Disable TAC replication job from Primary ESA P1.

   For disabling TAC replication, refer to Disable TAC replication job from Primary ESA P1.

3. Ensure all the prerequisites are followed before proceeding with the upgrade of each ESA.

   For more information about the prerequisites, refer to Prerequisites.

4. Upgrade ESAs S3, S4 and S5 at the DR site parallely.

   For upgrading DR site ESAs, refer to Upgrade ESAs S3, S4 and S5 at the DR site.

5. Validate DR site ESAs post upgrade.

   For validating DR site ESAs, refer to Validate DR Site ESAs Post Upgrade.

6. Stop Application Traffic to DSGs.

   Ensure to stop the Application Traffic to any of the DSGs.

7. Pre-Upgrade Steps for DSG.

   1. Remove all existing DSGs from the TAC before proceeding with further upgrade steps.
   2. Stop all existing DSGs to minimize the downtime impact.

Phase 2: Primary Site Upgrade

8. Upgrade ESAs in Primary Site.

   Upgrade ESAs P1, S1 and S2 at the Primary site parallely.

   For upgrading primary site ESAs, refer to Upgrade ESAs P1, S1 and S2 at the Primary site.

9. Validate Primary Site ESAs post upgrade.

   For validating primary site ESAs, refer to Validate Primary Site ESAs post upgrade.

10. Install and configure DSGs.

    1. Create fresh DSGs v4.0.0. Perform this step in parallel to upgrading ESAs in Primary Site to minimize DSG downtime. Create DSGs v4.0.0 using ISO or cloud image as applicable.

       For more information, refer to Installing the DSG.

    2. Create a new TAC with reimaged DSGs. Starting with DSG v3.3.0.0, ESAs and DSGs should be in separate TACs. Create a new TAC with DSGs reimaged in the preceding step.

    3. Upload and install DSG Management Server certificates in each DSG individually. Ensure the SAN field in each certificate contains the hostname and FQDN of the DSG node where it will be installed.

11. Install DSG patch on all ESAs.

    Install DSG v4.0.0 patch on all ESAs in both Primary and DR sites, that is, ESA P1, S1, S2, S3, S4, and S5.

12. Configure ESA Communication.

    Perform ESA communication from all DSGs. For all options in ESA communication, provide GTM IP, hostname, or FQDN as applicable. For more information, refer to Setting up ESA communication.

13. Register DSG Node with ESA.

    During the prompt for DSG details, provide the FQDN or hostname of any running DSG in the TAC. Ensure the same DSG FQDN or hostname is provided during DSG node registration in all ESAs, that is, P1, S1, S2, S3, S4, and S5.

14. Verify DSG Cluster.

    Verify that all installed DSGs are listed under Cloud Gateway > Cluster page in ESA P1.

15. Deploy Rulesets.

    Click the Deploy button from the DSG Cluster page in ESA P1 to deploy rulesets to all DSGs present in the TAC. For more information, refer to Deploying configurations to the cluster.

16. Verify DSG Health Status.

    After successful deployment of rulesets, verify the health status of DSGs in the TAC from the DSG Cluster page in ESA P1. All DSGs should show health status as green.

17. Validate DSG operations.

    1. Confirm that DSGs can perform data security operations post-upgrade.
    2. Verify that audit events are being forwarded successfully to the ESAs.

Phase 3: Post-Upgrade Tasks

18. Enable Scheduler tasks in Primary site ESAs.

    For enabling scheduler tasks, refer to Enable Scheduler tasks in Primary site ESAs.

19. Migrate Audit logs from DR site ESAs to Primary site ESAs.

    When the traffic from protectors was redirected to the DR site ESAs, audit logs will be generated in those ESAs. Those audit logs need to be migrated to Primary site ESAs. For migrating audit logs, refer to Migrate Audit logs from DR site ESAs to Primary site ESAs.

20. Terminate older version DSGs.

    With successful upgrade of DSGs and validation of operations, terminate all older version DSGs that were stopped in Pre-Upgrade Steps for DSG to free up resources.

In-place Upgrade

The in-place upgrade involves upgrading existing DSG instances to the newer version sequentially using patches.

Phase 1: DR Site Upgrade

1. Backup all ESAs.

   For backing up ESAs, refer to Backup all ESAs.

2. Disable TAC replication job from Primary ESA P1.

   For disabling TAC replication, refer to Disable TAC replication job from Primary ESA P1.

3. Ensure all the pre-requisites are followed before proceeding with the upgrade of each ESA.

   For more information about the prerequisites, refer to Prerequisites.

4. Upgrade ESAs S3, S4 and S5 at the DR site parallely.

   For upgrading DR site ESAs, refer to Upgrade ESAs S3, S4 and S5 at the DR site.

5. Validate DR Site ESAs post upgrade.

   For validating DR site ESAs, refer to Validate DR Site ESAs Post Upgrade.

6. Stop Application Traffic to DSGs.

   Ensure to stop the Application Traffic to any of the DSGs.

7. Redirect GTM to LTM2.

   Adjust configurations to redirect the GTM to point to LTM2. This ensures that DSG nodes, after upgrade, communicate with the upgraded ESAs at the DR site.

   Important: At this stage, do not add any new DSG nodes. Also, do not make any changes to ESA or DSG configurations or rulesets. The validations mentioned in the following steps must be performed using existing DSG nodes.

8. Install DSG Patch on DR Site ESAs.

   Install DSG v4.0.0 patch on all ESAs in the DR site, that is, ESA S3, S4, and S5.

9. Upgrade DSG nodes.

   1. Upgrade the DSGs by applying the patch. For more information, refer to Upgrading to DSG 4.0.0.

      • For DSG v3.3.0.1 or later, DSGs can be upgraded in parallel.
      • For DSG versions prior to v3.3.0.1, upgrade DSGs one at a time.

   2. Perform post upgrade steps in DSG. For more information, refer to Post Upgrade Steps.

   3. Upload and install DSG Management Server certificates in each DSG individually. Ensure the SAN field in each certificate contains the hostname and FQDN of the DSG node where it will be installed.

10. Restore the DSG TAC.

    1. Choose one of the upgraded DSGs as a primary DSG.
    2. Restore DSG TACs from the designated primary DSG that were earlier a part of TAC.
    3. On the CLI Manager, navigate to Tools > Restore DSG-DSG TAC.
    4. Enter the appropriate user credentials and select OK.
    5. All the DSGs that were a part of a TAC and upgraded, are now restored.

11. Configure ESA Communication.

    Perform ESA communication from all DSGs. For all options in ESA communication, provide GTM IP, hostname or FQDN as applicable. For more information, refer to Setting up ESA communication.

12. Register DSG Node with ESA.

    During the prompt for DSG details, provide the FQDN or hostname of any running DSG in the TAC. Ensure the same DSG FQDN or hostname is provided during DSG node registration in all ESAs, that is, S3, S4, and S5.

13. Verify DSG Cluster.

    Verify that all installed DSGs are listed under Cloud Gateway > Cluster page in ESA S3.

14. Deploy Rulesets.

    Click the Deploy button from the DSG Cluster page in ESA S3 to deploy rulesets to all DSGs present in the TAC. For more information, refer to Deploying configurations to the cluster.

15. Verify DSG Health Status.

    After successful deployment of rulesets, verify the health status of DSGs in the TAC from the DSG Cluster page in ESA S3. All DSGs should show health status as green.

16. Validate DSG Operations.

    1. Confirm that DSGs can perform data security operations post upgrade.
    2. Verify that audit events are being forwarded successfully to the DR site ESAs.

Phase 2: Primary Site Upgrade

17. Upgrade ESAs in Primary Site.

    Upgrade ESAs P1, S1 and S2 at the Primary site parallely.

    For upgrading primary site ESAs, refer to Upgrade ESAs P1, S1 and S2 at the Primary site.

18. Validate Primary Site ESAs post upgrade.

    For validating primary site ESAs, refer to Validate Primary Site ESAs post upgrade.

19. Install DSG Patch on Primary Site ESAs.

    Install DSG v4.0.0 patch on all ESAs in the Primary site, that is, ESA P1, S1, and S2.

20. Register DSG Node with ESA.

    During the prompt for DSG details, provide the FQDN or hostname of any running DSG in the TAC. Ensure the same DSG FQDN or hostname is provided during DSG node registration in all ESAs, that is P1, S1, and S2.

21. Redirect GTM to LTM1.

    Adjust the configurations to redirect the GTM to point to LTM1. This ensures that DSG nodes communicate with the upgraded ESAs at the Primary site.

22. Verify DSG Cluster.

    Verify that all installed DSGs are listed under Cloud Gateway > Cluster page in ESA P1.

23. Deploy Rulesets.

    Click the Deploy button from the DSG Cluster page in ESA P1 to deploy rulesets to all DSGs present in the TAC. For more information, refer to Deploying configurations to the cluster.

24. Verify DSG Health Status.

    After successful deployment of rulesets, verify the health status of DSGs in the TAC from the DSG Cluster page in ESA P1. All DSGs should show health status as green.

25. Validate DSG Operations.

    1. Confirm that DSGs can perform data security operations.
    2. Verify that audit events are being forwarded successfully to the ESAs in the Primary site.

Phase 3: Post Upgrade Tasks

26. Enable Scheduler tasks in Primary site ESAs.

    For enabling scheduler tasks, refer to Enable Scheduler tasks in Primary site ESAs.

27. Migrate Audit logs from DR site ESAs to Primary site ESAs.

    When the traffic from protectors is redirected to the DR site ESAs, audit logs are generated in these ESAs. These audit logs must be migrated to Primary site ESAs.

    For migrating audit logs, refer to Migrate Audit logs from DR site ESAs to Primary site ESAs.

Additional Considerations

• Documentation: Maintain detailed records of the upgrade procedure for future reference.

• Troubleshooting: Have contingency plans in place to address potential issues during the upgrade. For more information on troubleshooting, refer to Troubleshooting.

• Support: Utilize Protegrity support services for guidance or troubleshooting assistance as needed. For assistance, contact Protegrity Support at support@protegrity.com.

2.10 - Upgrading ESA with 9.1.0.0/10.x Protectors

This section describes the steps to upgrade ESAs with 9.1.0.0/10.x protectors already installed (excluding DSGs). To ensure compatibility and leverage new features, security fixes, and enhancements, it is necessary to upgrade the ESA to the latest version. This section outlines the required steps for upgrading from a previous version, applicable to both on-premise and cloud platforms.

Prerequisites

Before proceeding with the upgrade, refer to Before you begin to ensure all prerequisites are met.

Related Documentation

• If DSGs are installed with other protectors, refer to Upgrading ESA with DSGs and Protectors
• If only DSGs are installed, refer to Upgrading ESA with DSG

Important: The steps in this section ensure zero downtime of protectors during ESA upgrade.

Upgrade Steps

Phase 1: Disaster Recovery (DR) Site Upgrade

1. Backup all ESAs

For backing up ESAs, refer to Backup all ESAs.

2. Disable TAC replication job from Primary ESA P1

For disabling TAC replication, refer to Disable TAC replication job from Primary ESA P1.

3. Ensure all the prerequisites are followed before proceeding with the upgrade of each ESA

For more information about the prerequisites, refer to Prerequisites.

4. Upgrade ESAs S3, S4 and S5 at the DR site parallely

For upgrading DR site ESAs, refer to Upgrade ESAs S3, S4 and S5 at the DR site.

5. Validate DR Site ESAs Post Upgrade

For validating DR site ESAs, refer to Validate DR Site ESAs Post Upgrade.

6. Redirect GTM to LTM2

Adjust configurations to redirect the GTM so that it points to LTM2. This ensures that protectors communicate with the upgraded ESAs at the DR site.

Important: At this stage, do not add any new protectors. The validations mentioned in the steps below must be performed using existing protectors.

7. Verify Protector Status

   For v9.1.0.0 Protectors:

   1. Log in to ESA S3 Web UI.
   2. Navigate to Policy Management and verify:
      • All protector registrations in Data Stores show as GREEN or Ok.
      • Policy Deploy Status shows as GREEN or Ok.

   For v10.x Protectors:

   1. Log in to ESA S3 Web UI.
   2. Navigate to Audit Store > Dashboard. Verify the protector status in Protector Status Dashboard is shown as GREEN or OK.

8. Validate Protector Operations

   1. Confirm that protectors can perform data security operations after upgrading the ESAs.
   2. Verify that audit events are being forwarded successfully to the ESAs.

Phase 2: Primary Site Upgrade

9. Upgrade ESAs P1, S1 and S2 at the Primary site parallely

For upgrading primary site ESAs, refer to Upgrade ESAs P1, S1 and S2 at the Primary site.

10. Validate Primary Site ESAs post upgrade

For validating primary site ESAs, refer to Validate Primary Site ESAs post upgrade.

11. Redirect GTM to LTM1

Reconfigure the GTM to point back to LTM1, allowing protectors to resume communication with the ESAs at the primary site.

12. Reset Node Status for only the v9.1.0.0 Protectors

At this point, Nodes Connectivity Status of some or all nodes may show as red (Error) or yellow (Warning) under Policy Management > Data Stores in ESA P1 Web UI.

To reset node status to green (OK), follow these steps:

1. Log in to ESA P1 Web UI.
2. Navigate to Policy Management > Data Stores.
3. Select nodes showing red (Error) or yellow (Warning) status and click the delete button to remove the entry.

Important: If there are many pepserver nodes registered, delete the nodes in batches of 200.

After deleting the registered nodes, pepserver nodes will re-register with ESA and the status will become green (OK).

13. Verify Protector Status

    For 9.1.0.0 Protectors: - Follow the same verification steps as in Phase 1, Step 3. Refer step 1 for steps.

    For 10.x Protectors: - Follow the same verification steps as in Phase 1, Step 3. Refer step 1 for steps.

14. Validate Protector Operations

    1. Confirm that protectors can perform data security operations post-upgrade.
    2. Verify that audit events are being forwarded successfully to the ESAs.

Phase 3: Post-Upgrade Tasks

15. Enable Scheduler tasks in Primary site ESAs

For enabling scheduler tasks, refer to Enable Scheduler tasks in Primary site ESAs.

16. Migrate Audit logs from DR site ESAs to Primary site ESAs

When the traffic from protectors was redirected to the DR site ESAs, audit logs will be generated in those ESAs. Those audit logs need to be migrated to Primary site ESAs. For migrating audit logs, refer to Migrate Audit logs from DR site ESAs to Primary site ESAs.

Additional Considerations

• Documentation: Maintain detailed records of the upgrade procedure for future reference.

• Troubleshooting: Have contingency plans in place to address potential issues arising during the upgrade. For more information on troubleshooting, refer to Troubleshooting.

• Support: Utilize Protegrity support services for guidance or troubleshooting assistance as needed. For assistance, contact Protegrity Support at support@protegrity.com.

2.11 - Upgrading ESA with DSGs and 9.1.0.0/10.x Protectors

This section describes the steps to upgrade ESAs and DSGs with running v9.1.0.0 protectors in backward compatibility mode or v10.x protectors.

Upgrade Approaches for DSG

Two upgrade approaches are available for the DSG upgrade process:

1. Canary Upgrade - Reimaging DSG instances to the newer version using ISO or cloud images.
2. In-place Upgrade - Upgrading existing DSG instances using patches.

Select the most appropriate upgrade approach based on organizational requirements, infrastructure constraints, and operational considerations.

Important Notes

• The steps in this section ensure zero downtime of v9.1.0.0 or v10.x Protectors during ESA upgrade.

• Both upgrade approaches will incur DSG downtime during the upgrade process. Plan accordingly to minimize impact on production operations.

Canary Upgrade

The canary upgrade involves reimaging existing DSG instances to the newer version using ISO or cloud images. This can be performed by reusing the same instance or spawning a new instance for DSG and terminating the older version DSGs.

Important: DSG downtime will occur during upgrade. However, downtime can be minimized by spawning fresh DSGs v4.0.0 in parallel to upgrading ESAs.

Phase 1: DR Site Upgrade

1. Backup all ESAs.

   For backing up ESAs, refer to Backup all ESAs.

2. Disable TAC replication job from Primary ESA P1.

   For disabling TAC replication, refer to Disable TAC replication job from Primary ESA P1.

3. Ensure all the prerequisites are followed before proceeding with the upgrade of each ESA.

   For more information about the prerequisites, refer to Prerequisites.

4. Upgrade ESAs S3, S4 and S5 at the Disaster Recovery (DR) site parallely.

   For upgrading DR site ESAs, refer to Upgrade ESAs S3, S4 and S5 at the DR site.

5. Validate DR Site ESAs Post upgrade.

   For validating DR site ESAs, refer to Validate DR Site ESAs Post Upgrade.

6. Stop Application Traffic to DSGs.

   Ensure to stop the Application Traffic to any of the DSGs.

7. Pre-upgrade steps for DSG.

   1. Remove all existing DSGs from the TAC before proceeding with further upgrade steps.
   2. Stop all existing DSGs to minimize downtime impact.

8. Redirect Protector Traffic to DR Site.

   Adjust configurations to redirect the GTM to point to LTM2. This ensures that protectors communicate with the upgraded ESAs at the DR site.

   Important: At this stage, do not add any new protectors. The validations mentioned in the following steps must be performed using existing protectors.

9. Verify Protector Status.

   For verifying protector status, refer to Verify Protector Status.

10. Validate v9.1.0.0 or v10.x Protector Operations.

    For protector validation, refer to Validate Protector Operations.

Phase 2: Primary Site Upgrade

11. Upgrade ESAs P1, S1 and S2 at the Primary site parallely.

    For upgrading primary site ESAs, refer to Upgrade ESAs P1, S1 and S2 at the Primary site.

12. Validate Primary Site ESAs post upgrade.

    For validating primary site ESAs, refer to Validate Primary Site ESAs post upgrade.

13. Installing and configuring the DSGs.

    For installing and configuring DSGs, refer to Install and Configure DSGs.

14. Install DSG Patch on All ESAs.

    Install DSG v4.0.0 patch on all ESAs in both Primary and DR sites, that is, ESA P1, S1, S2, S3, S4, and S5.

15. Redirect Protector Traffic to Primary Site.

    Adjust configurations to redirect the GTM to point to LTM1. This allows protectors to resume communication with the ESAs at the Primary site.

16. Reset Node Status for only the v9.1.0.0 Protectors.

    For resetting node status at primary site ESA P1, refer to Reset Node Status for 9.1.0.0 Protectors Only.

17. Verify Protector Status.

    For verifying protector status at primary site ESA P1, refer to Verify Protector Status.

18. Validate v9.1.0.0 or v10.x Protector Operations.

    For protector validation, refer to Validate Protector Operations.

19. Perform ESA Communication.

    Perform ESA communication from all DSGs. For all options in ESA communication, provide GTM IP, hostname or FQDN as applicable. For more information, refer to Setting up ESA communication.

20. Register DSG Node with ESA.

    During the prompt for DSG details, provide the FQDN or hostname of any running DSG in the TAC. Ensure the same DSG FQDN/hostname is provided during DSG node registration in all ESAs, that is, P1, S1, S2, S3, S4, and S5.

21. Verify DSG Cluster Page in ESA.

    Verify that all installed DSGs are listed under Cloud Gateway > Cluster page in ESA P1.

22. Deploy Rulesets.

    Click the Deploy button from the DSG Cluster page in ESA P1 to deploy rulesets to all DSGs present in the TAC. For more information, refer to Deploying configurations to the cluster.

23. Check Health Status of DSGs from Cluster Page.

    After successful deployment of rulesets, verify the health status of DSGs in the TAC from the DSG Cluster page in ESA P1. All DSGs should show health status as green.

24. Validate DSG Operations.

    For validating DSG operations, refer to Validate DSG Operations.

Phase 3: Post-Upgrade Tasks

25. Enable Scheduler Tasks.

    For enabling scheduler tasks, refer to Enable Scheduler tasks in Primary site ESAs.

26. Terminate older version DSGs.

    With successful upgrade of DSGs and validation of operations, terminate all older version DSGs that were stopped in Pre-Upgrade Steps for DSG to free up resources.

27. Migrate Audit Logs from DR Site ESAs to Primary Site ESAs.

    When the traffic from protectors is redirected to the DR site ESAs, audit logs are generated in these ESAs. These audit logs need to be migrated to Primary site ESAs. For migrating audit logs, refer to Migrate Audit logs from DR site ESAs to Primary site ESAs.

In-place Upgrade

The in-place upgrade involves upgrading existing DSG instances to the newer version sequentially using patches.

Phase 1: DR Site Upgrade

1. Backup all ESAs.

   For backing up ESAs, refer to Backup all ESAs.

2. Disable TAC replication job from Primary ESA P1.

   For disabling TAC replication, refer to Disable TAC replication job from Primary ESA P1.

3. Ensure all the prerequisites are followed before proceeding with the upgrade of each ESA.

   For more information about the prerequisites, refer to Prerequisites.

4. Upgrade ESAs S3, S4 and S5 at the DR site in parallel.

   For upgrading DR site ESAs, refer to Upgrade ESAs S3, S4 and S5 at the DR site.

5. Validate DR Site ESAs Post Upgrade.

   For validating DR site ESAs, refer to Validate DR Site ESAs Post Upgrade.

6. Stop Application Traffic to DSGs.

   Ensure to stop the Application Traffic to any of the DSGs.

7. Redirect Protector Traffic to the DR Site.

   Adjust configurations to redirect the GTM to point to LTM2. This ensures that protectors communicate with the upgraded ESAs at the DR site.

   Important: At this stage, do not add any new protectors. The validations mentioned in the following steps must be performed using existing protectors.

8. Verify Protector Status.

   For verifying protector status, refer to Verify Protector Status.

9. Validate Protector Operations.

   For validating protector operations, refer to Validate Protector Operations.

10. Install DSG Patch on ESAs.

    For installing DSG patch on DR site ESAs, refer to Install DSG Patch on DR Site ESAs.

11. Upgrade DSG Nodes.

    For upgrading DSG nodes, refer to Upgrade DSG Nodes.

12. Restore DSG TAC from the first DSG.

    For restore DSG TAC, refer to Restore DSG TAC.

13. Configure ESA Communication.

    For configuring ESA communication, refer to Configure ESA Communication.

14. Register DSG Node with ESA.

    For registering DSG nodes with DR ESAs, refer to Register DSG Node with ESA.

15. Verify DSG Cluster.

    For verifying DSG cluster at ESA S3, refer to Verify DSG Cluster.

16. Deploy Rulesets.

    For deploying rulesets from ESA S3, refer to Deploy Rulesets.

17. Verify DSG Health Status.

    For verifying DSG health status at ESA S3, refer to Verify DSG Health Status.

18. Validate DSG Operations.

    For validating DSG operations, refer to Validate DSG Operations.

Phase 2: Primary Site Upgrade

19. Upgrade ESAs P1, S1 and S2 at the Primary site in parallel.

    For upgrading primary site ESAs, refer to Upgrade ESAs P1, S1 and S2 at the Primary site.

20. Validate Primary Site ESAs post upgrade.

    For validating primary site ESAs, refer to Validate Primary Site ESAs post upgrade.

21. Install DSG Patch on ESAs.

    For installing DSG patch on primary site ESAs, refer to Install DSG Patch on Primary Site ESAs.

22. Register DSG Node with ESA.

    For registering DSG nodes with primary ESAs, refer to Register DSG Node with ESA.

23. Redirect Protector Traffic to Primary Site.

    Adjust configurations to redirect the GTM to point to LTM1. This allows protectors to resume communication with the ESAs at the Primary site.

24. Reset Node Status only on the v9.1.0.0 Protectors.

    For resetting node status at primary site ESA P1, refer to Reset Node Status (9.1.0.0 Protectors Only).

25. Verify Protector Status.

    For verifying protector status at primary site ESA P1, refer to Verify Protector Status.

26. Validate v9.1.0.0 or v10.x Protector Operations.

    For protector validation, refer to Validate Protector Operations.

27. Verify DSG Cluster Page in ESA.

    Verify that all installed DSGs are listed under Cloud Gateway > Cluster page in ESA P1.

28. Deploy Rulesets.

    Click the Deploy button from the DSG Cluster page in ESA P1 to deploy rulesets to all DSGs present in the TAC. For more information, refer to Deploying configurations to the cluster.

29. Check Health Status of DSGs from Cluster Page.

    After successful deployment of rulesets, verify the health status of DSGs in the TAC from the DSG Cluster page in ESA P1. All DSGs should show health status as green.

30. Validate DSG Operations.

    For validating DSG operations, refer to Validate DSG Operations.

Phase 3: Post-Upgrade Tasks

31. Enable Scheduler tasks in Primary site ESAs..

    For enabling scheduler tasks, refer to Enable Scheduler tasks in Primary site ESAs.

32. Migrate Audit logs from DR site ESAs to Primary site ESAs.

    When the traffic from protectors was redirected to the DR site ESAs, audit logs will be generated in those ESAs. Those audit logs need to be migrated to Primary site ESAs. For migrating audit logs, refer to Migrate Audit logs from DR site ESAs to Primary site ESAs.

Additional Considerations

• Documentation: Maintain detailed records of the upgrade procedure for future reference.

• Troubleshooting: Have contingency plans in place to address potential issues during the upgrade. For more information on troubleshooting, refer to Troubleshooting.

• Support: Utilize Protegrity support services for guidance or troubleshooting assistance as needed. For assistance, contact Protegrity Support at support@protegrity.com.

2.12 - Standard Protectors

The Standard Protectors are designed to provide robust data protection capabilities using APIs and User-Defined Functions (UDFs).

These Standard Protectors include:

1. SDK Protectors

2. Database Protectors

3. Datawarehouse Protectors

4. Bigdata Protectors

The following are the various package deployment approaches in v10.0.0:

1. Dynamic Package Deployment

2. DevOps Package Deployment

This document covers the primary package deployment approaches for Standard protectors. Dynamic Package Deployment is the primary package deployment for Standard protectors.

The architecture diagram for Standard Protectors v10.0.0 showing dynamic package deployment approach is shown below.

The architecture diagram for Standard Protectors v9.1.0.0 to help understand the architecture changes in v10.0.0 as compared to v9.1.0.0 is shown below.

Security Recommendations

Securing the Protector installation directory

The new certificate implementation removes scrambling of the password used to derive a key used to protect the client certificate key. Instead, the key is in clear text and stored in a file called secret.txt.

As part of the Protector installation process, a file named secrets.txt is generated. This file stores the passphrase essential for decrypting the Management Client certificate key. It is imperative to ensure that this file is adequately secured to maintain the integrity and security of the system.

Action Items

• File Permissions: Restrict access to the secrets.txt file to authorized personnel only. Apply appropriate file permissions to prevent unauthorized access or modifications. If the group-read bit is not necessary for the system to work properly, it is recommended that the user changes the file permission as mentioned below-

  chmod g-r <PROTECTOR_INSTALLATION_DIR>/rpagent/data/secret.txt
  

  If the group-read bit is necessary, review that the group contains appropriate users able to read the secret.txt. Note that when running the RPAgent or RPProxy, the secret.txt access can be isolated to the user running the RPAgent or RPProxy.

• Monitoring: Implement monitoring so that access logs can be regularly monitored to detect any unauthorized attempts to access the secrets.txt file.

By following these guidelines, significantly enhance the security posture of protector installation and ensure the confidentiality and integrity of critical security information.

ESA Communication Flow

• Package Traffic: Protector should be configured to download package from GTM to ensure high availability and disaster recovery.

  • Active Flow: Protector -> GTM -> LTM-1 -> ESA P1

  • Passive Flow: Protector -> GTM -> LTM-1 -> ESA S1 or ESA S2

  • DR Flow: Protector-> GTM -> LTM-2 -> ESA S3 or ESA S4 or ESA S5

• Log Forwarding Traffic: Protector should be configured to forward logs through GTM to maintain high availability and disaster recovery.

  • Active Flow: Protector -> GTM -> LTM-1 -> ESA P1, ESA S1, and ESA S2

  • DR Flow: Protector -> GTM -> LTM-2 -> ESA S3, ESA S4, and ESA S5

2.13 - Forwarding Logs to External SIEM

It is advised that if logs from the ESA and Protectors need to be forwarded to an External SIEM, they should first be directed to the ESA. Utilizing the td-agent within ESA, these logs can then be forwarded concurrently to both the Insight in ESA and the external SIEM. This approach ensures a unified and efficient log management process while maintaining comprehensive audit trails and enhancing security monitoring capabilities.

For more information related to forwarding logs to External SIEM, refer to Sending logs to an external security information and event management (SIEM).

For a comprehensive understanding of the communication flows, refer to the architecture diagram Deployment with Audit logging flow to External SIEM. This diagram explains how logs are forwarded between Protectors, ESA, and the External SIEM.