Architecture

Protector Deployment Architecture

The product will be deployed in the Customer’s AWS account. The product incorporates Protegrity’s vaultless tokenization engine within an AWS Lambda Function. The encrypted data security policy from an ESA is deployed as a static resource through an Amazon Lambda Layer. The policy is decrypted in memory at runtime within the Lambda. This architecture allows Protegrity Serverless 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 REST request includes a micro-batch of data to process and the data element type. The function applies the data 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 ESA.

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.

Access Control

The following mechanisms are available for controlling and restricting access to the endpoint:

• IAM policy: The IAM resource policy controls which IAM users or services may invoke Protect operations. IAM policies can be applied to the API Gateway and/or the Lambda directly depending on allowable access patterns and the client.
• JWT tokens: The Lambda can be configured to use JSON Web Tokens (JWT) with optional verification. JSON Web Tokens (JWT) are an open, industry-standard RFC 7519 method for representing claims securely between two parties. JWT provides a mechanism for implementing custom authentication or integrating with AWS Cognito.

AWS Resources

Access and authorization between various AWS services involved in this architecture are achieved through IAM resource policies. For instance, the Amazon Lambda resource-based policy can restrict requests to the Amazon API Gateway or optionally allow direct invocation to the Lambda function itself. The installation steps provide a default recommended configuration. Alternative IAM role configurations are shown in the appendices in this document.

REST API Authentication

AWS API Gateway supports multiple mechanisms for controlling and managing access to the product.

In standard solutions, AWS API Gateway will authorize access tokens generated in the identity provider. When setting up an AWS API Gateway method to require an authorization, customers can leverage AWS Signature Version 4 or Lambda authorizers to support their organization’s bearer token auth strategy.

https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-to-api.html

REST API Authorization

Once the request is authenticated and authorized in the API Gateway, Protegrity Lambda Protector validates the user received in the authorization header of JWT, and the data element and security operations (protect or unprotect) from the payload with Protegrity Security Policy.

If the API Gateway is not used or configured to verify JWT tokens, the product can be configured to perform the JWT verification in the Lambda function itself.