Architecture

Deployment Architecture

Protegrity Protector for Snowflake should be deployed in Customer’s Cloud account within the same Azure region as the Snowflake cluster. The product incorporates Protegrity’s vaultless tokenization engine within an Azure Function App. The encrypted data security policy from an ESA is deployed periodically as a static resources through an Azure blob storage. The policy is decrypted in memory at runtime within the Function App. This architecture allows Protegrity Serverless to be highly available and scale very quickly without direct dependency on any other Protegrity services.

Protegrity’s Protector for Snowflake exposes a remote data protection service invoked from external User Defined Functions (UDF), a native feature of particular Cloud databases. UDFs can be invoked via direct SQL queries, database views, or features such as Snowflake table masking. The external UDF makes parallel API calls to Protegrity Serverless for protect and unprotect data operations. Each network REST request includes a micro-batch of data to process and a secure context header generated by the database with the username and a Protegrity context header with the data element type, and operation to perform. It 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 for reporting and alerting purposes via optional component called Log Forwarder explained in details in the next section of this guide.

The security policy is synchronized via another serverless component called the Protegrity Policy Agent . The agent operates on a configurable schedule, fetches policy from ESA, performs additional envelope encryption using Azure Key Vault, and deploys the policy into the Azure blob storage container which is accessed by Protector Function App. This solution can be configured to automatically provision the static policy or the final step can be performed on-demand by an administrator.

The following diagram shows the high-level architecture described above.

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

The ESA is a soft appliance that must be pre-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 the Policy Management Section.

Audit Log Forwarding Architecture

Audit logs are by default sent to Azure Blob Storage and Application Insights. The Cloud Protect product can also be configured to send audit logs to ESA. Such configuration requires deploying audit Log Forwarder component which is available as part of Cloud Protect deployment bundle. The diagram below shows additional resources deployed with Log Forwarder component.

The audit log forwarding solution includes Azure Event Hubs data-streaming service and an Azure Function App deployment called Log Forwarder. Protect function delivers audit logs to Azure Event Hub instance, Event Hub instance batches audit logs and delivers them to Log Forwarder function. Log Forwarder function then delivers audit logs to ESA. Audit log aggregation occurs on both Protect and Log Forwarder functions. Aggregation rules are described in the Understanding the log aggregation section. If Log Forwarder cannot deliver audit logs to ESA due to temporary ESA connection loss, it will send undelivered audit logs to a dead-letter queue Event Hub. Audit logs in dead-letter queue Event Hub can be re-delivered to ESA using another instance of Log Forwarder, which can be configured to run either manually or on schedule.

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 function which verifies individual logs signature. The signature verification is done upon arrival from Azure Event Hub 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 client certificate to authenticate calls to ESA.

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

Snowflake Connectivity

Snowflake’s API Integration Object

The Snowflake API Integration Object provides a connection between your Snowflake Azure account and your Azure account where the Protegrity product is hosted. Creating this connection requires setting up the API Management and appropriate access policies. These steps are provided in the installation.