Architecture

Deployment Architecture

The Protegrity product should be deployed in the customer’s Cloud account. The product incorporates Protegrity’s vaultless tokenization engine within Google Cloud Functions. The encrypted data security policy from an ESA is deployed periodically as a static resource together with Cloud Function binaries. The policy is decrypted in memory at runtime within the Cloud Function. This architecture allows Protegrity to be highly available and scale very quickly without direct dependency on any other Protegrity services.

The product exposes a remote data protection service. Each network REST request includes a micro-batch of data to process and parameters such as operation and data element. The product applies the ESA security policy including user authorization and returns a corresponding response. Security operations on sensitive data performed by protector can be audited. The product can be configured to send audit logs to ESA via optional component called Log Forwarder.

The security policy is synchronized through another serverless component called the Protegrity Policy Agent. The agent operates on a configurable schedule, fetches the policy from the ESA, performs envelope encryption using Google Key Management Service, and deploys new version of Cloud Function with updated policy. This solution can be configured to automatically provision the static policy or the final step can be performed on-demand by an administrator. There is no downtime for users during this process. Instances provisioned with the function’s previous policy version may continue running (and processing traffic) for several minutes after a deployment has finished.

The following diagram illustrates the high-level architecture.

The following diagram illustrates a reference architecture for synchronizing the security policy from the ESA to the product.

The Protegrity Policy Agent requires network access from GCP to your ESA. Most organizations install the ESA on-premise. Thus, it is recommended to install the Policy Agent in a private subnet with a Cloud VPC using a NAT Gateway to enable this communication through a corporate firewall.

The ESA is a soft appliance that must be installed on a separate server. It is used to create and manage security policies.

For more information about installing the ESA, and creating and managing policies, refer to the Policy Management Guide.

Audit Log Forwarding Architecture

Audit logs are by default sent to Cloud Logging. The Protegrity Product can also be configured to send audit logs to ESA. Such configuration requires deploying Log Forwarder component which is available as part of Protegrity Product deployment bundle. The diagram below shows additional resources deployed with Log Forwarder component.

The log forwarder component includes Pub/Sub service topic and the audit log forwarder function. Pub/Sub service is used to asynchronously send audit records to forwarder function, where similar audit logs are aggregated before sending to ESA. Aggregation rules are described in the Protegrity Log Forwarding guide. When the protector function is configured to send audit logs to log forwarder, audit logs are aggregated on the protector function before sending to Pub/Sub topic. Protector function exposes configuration to control the time it spends aggregating audit logs which is described in the protector function installation section.

The security of audit logs is ensured by using HTTPS connection on each link of the communication between protector function and ESA. Integrity and authenticity of audit logs is additionally checked on log forwarder which verifies individual logs signature. The signature verification is done upon arrival from Pub/Sub topic before applying aggregation. If signature cannot be verified, the log is forwarded as is to ESA where additional signature verification can be configured. Log forwarder function uses basic auth and optional certificate verification to authenticate calls to ESA. Basic auth credentials are stored securely in Secret Manager Service.

To learn more about individual audit log entry structure and purpose of audit logs, refer to Audit Logging section in this document. Installation instruction can be found in the Audit Log Forwarder installation.

The audit log forwarding requires network access from the cloud to the ESA. Most organizations install the ESA on-premise. Therefore, it is recommended that the Log Forwarder Function is installed into a private subnet with a Cloud VPC using a NAT Gateway to enable this communication through a corporate firewall.

Access Control

The Cloud API utilizes access controls provided by the Google Cloud Functions service. The following mechanisms are available for controlling and restricting access to the Cloud API data protection endpoint:

• Google Cloud Identity and Access Management (IAM) access control.
• Google Cloud Network-based access control.
• OpenID Connect. OpenID is a simple identity layer on top of the OAuth 2.0 protocol. Authorization is performed in the Protegrity Cloud Function code.

For more information on Google Cloud Functions security concepts, refer to Securing Cloud Functions

• REST API Authentication and Authorization

• REST API Policy Authorization

REST API Authentication and Authorization

The Rest API supports built-in authentication and authorization provided by Google Cloud Functions. More information is available in the following Google Cloud Functions documentation.

https://cloud.google.com/functions/docs/securing/authenticating

REST API Policy Authorization

Once the request is authenticated and authorized by the Cloud Function, the Protegrity Cloud API performs the requested security operation based on the policy data element from the payload and the authenticated user.