Deployment Architecture
The Amazon Athena Protector should be deployed in the customer’s AWS account. The product incorporates Protegrity’s vaultless tokenizationengine within an AWS Lambda Function. The data security policy from an ESA is provisioned periodically as a static, encrypted resource through an AWS Lambda Layer. The policy is decrypted in memory at runtime within the Lambda. This architecture allows Protegrity to be highly available and scale very quickly without direct dependency on other Protegrity services.
The product exposes a remote data protection service invoked from external User Defined Functions (UDFs), a native feature of Amazon Athena.The UDFs is invoked by users through SQL queries. The Amazon Athena execution engine makes remote calls to the Protegrity product to perform protect and unprotect data operations. Each network request includes a micro-batch of data to process and a secure payload including the federated user (if available) and the data element type. The product applies the ESA security policy including user authorization and returns a corresponding response.
When used with an Enterprise Security Administrator (ESA) application, 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 additional envelope encryption using Amazon KMS, and deploys the policy into the Lambda Layer used by the serverless product. This solution can be configured to automatically provision the static policy or the final step can be performed on-demand by an administrator. The policy takes effect immediately for all new requests. There is no downtime for users during this process.
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 Protegrity Policy Agent requires network access to an Enterprise Security Administrator (ESA). Most organizations install the ESA on-premise. Therefore, it is recommended that the Policy Agent is installed into 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 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 Guide.
Log Forwarding Architecture
Audit logs are by default sent to CloudWatch as long as the function’s execution role has the necessary permissions. 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 Amazon Kinesis data stream and the forwarder Lambda function. Amazon Kinesis stream is used to batch audit records before sending them 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 Amazon Kinesis. Due to specifics of the Lambda runtime lifecycle, audit logs may take up to 15 minutes before being sent to Amazon Kinesis. Protector function exposes configuration to minimize this time 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 Amazon Kinesis 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 in this document. Installation instructions can be found in 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.
Athena Connectivity
Amazon Athena is an interactive, serverless query service that makes it easy to analyze data in Amazo n S3 using standard SQL. Athena is serverless, so there is no infrastructure to manage, and you pay only for the queries that you run.
Athena’s external UDF makes remote invocations to the Protegrity protector, a serverless Lambda function incorporating Protegrity libraries and the Athena Query Federation SDK.
Access and authorization between various AWS services involved in this architecture is achieved throu gh Identity Access Management (IAM). For instance, the IAM principal running the query must be allowed to invoke the protect Lambda. Various IAM role configuration settings are shown in the appen dices of this document.
The following figure illustrates the Protegrity Athena Integration architecture.
