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