Understanding the Architecture

This page describes the architecture, the individual components, and the workflow of the Protegrity Application Protector (AP) solution.

Architecture and Workflow

The following figure illustrates the deployment architecture of the Application Protector (AP).

The following table describes the components of the AP deployment architecture.

The following steps describe the workflow of a sample AP deployment in the production environment.

1. The customer application initializes the SDK.
2. The required configuration parameters are passed to the protector using the config.ini file.
   The configurations can be set through environment variables. ENV overrides values in the config.ini file, except for cadence and session timeout which must be set in the config file.
   For more information about environment variables configuration, refer to Configuration Parameters for Protector.
3. The RP Agent regularly syncs with the RP Proxy or ESA to check for policy updates. If a change is detected, the updated policy package is securely downloaded over a TLS channel and stored in shared memory.
4. The protector synchronizes with shared memory based on the cadence value defined in config.ini file. If a new package is available, it is fetched into process memory. This updated package is then used to perform data protection operations such as, protect, unprotect, and reprotect.
5. The audit logs generated during protection operations are forwarded to the Audit Store:
   • Logs from the application are sent through the Log Forwarder.
   • Logs from the RP Agent are also forwarded using the Log Forwarder.

Components of the Application Protector

The Protegrity Application Protector (AP) solution comprises several key components that work together to enforce data protection policies and ensure secure operations.

Application Protector

The core engine that integrates with customer applications to perform data protection operations:

• Protect
• Unprotect
• Reprotect

AP is available in multiple language-specific variants. One of which is:

• AP Java: For applications developed in Java

Resilient Package (RP) Agent

A standalone process responsible for policy synchronization:

• To sync with the RP Proxy or ESA at regular intervals of 60 seconds
• To detect policy changes and download updated packages over a secure TLS channel
• To store the packages in shared memory for use by the protector

Log Forwarder

A log processing tool that handles audit and protection logs:

• Collects logs generated by AP and RP Agent
• Forwards logs to the Audit Store within ESA

Ports used to transport the protection and audit logs to the ESA:

• 15780: Configurable
• 15781: Non-configurable

Package Deployment

The different approaches for package deployment during the initialization process of the Application Protector are described in this section.

Dynamic Package Deployment

Use this approach when the protector needs to continuously check for policy updates after initialization.

• Set the cadence parameter to a non-zero value in the config.ini file.
• This value defines the interval in seconds at which the protector synchronizes with the RP Agent.
• If a policy change is detected, the protector automatically fetches the updated package and applies it during protection operations.

  Note: This method ensures that the protector always operates with the latest policy.

Immutable Package Deployment

Use this approach when the protector does not need to check for policy changes after initialization.

• Add the [devops] parameter in the config.ini file before initializing the protector.
• A REST API call is used to download an envelope-encrypted package from the ESA.
• The protector uses this static package for all operations without further synchronization.
  For more information about the DevOps approach, refer to DevOps Approach for Application Protector.