Data Partitioning in SaaS Architecture: An Essential Guide to Dynamic Isolation Policies

Data Partitioning in SaaS Architecture: An Essential Guide to Dynamic Isolation Policies

When it comes to designing a SaaS architecture, data partitioning plays a crucial role in ensuring scalability, security, and efficiency. Two common approaches to data partitioning are siloed and pooled models. In a siloed model, each tenant has their own separate storage construct with no shared data. On the other hand, in a pooled model, data is co-mingled and partitioned based on a tenant identifier. Amazon DynamoDB, for example, uses a siloed model with separate tables for each tenant.

To effectively implement data partitioning and isolation in a SaaS environment, dynamically generated isolation policies can be applied. These policies ensure that each microservice within the architecture can only access data associated with a specific tenant. Let's dive deeper into the key components and steps involved in applying dynamically generated isolation policies.

The SaaS environment typically consists of multiple microservices, each responsible for specific tasks or functionalities. Figure 1 illustrates a simplified example of a SaaS application with a single serverless product microservice running in Lambda, which is accessed by multiple tenants. Although this example showcases a single microservice, the same isolation mechanism can be applied to a collection of microservices within your own system.

In this example, the microservice stores and retrieves tenant-scoped data from a DynamoDB table. When a request is made, the microservice needs to acquire separate credentials scoped to the specific tenant's data. This is where the Token Vending Machine (TVM) comes into play. The TVM is a library included in an AWS Lambda layer, which helps acquire tenant-scoped credentials based on the request context.

The tenant request flow starts with a tenant sending a request to the Amazon API Gateway. Each request includes a token, such as a JSON Web Token (JWT), containing custom claims like tenant_id and tenant_name. These claims provide the necessary context for scoping the access to the tenant's data. Once the authorized request is processed and routed by the API Gateway, it invokes the microservice (Lambda function) responsible for handling the request.

Before accessing the data in the DynamoDB table, the microservice needs to acquire tenant-scoped credentials using the TVM. The TVM is instantiated within the microservice and utilizes the request headers, including the tenant context, to generate the scoped credentials. This process involves constructing an instance of the TVM and making a call to acquire the credentials. By encapsulating this logic in a Lambda layer, the amount of code required for acquiring the tenant-scoped credentials is minimized.

The TVM layer also performs a lookup of dynamic policies. These policies are template-based and specify the access rights and permissions for each tenant's data. The TVM checks if the correct version of the policy templates is available locally and downloads them from Amazon S3 if not found. The policy version is managed through environment variables, allowing easy control and updates of the templates.

Once the TVM has the necessary policies and tenant context, it calls the Security Token Service (STS) to assume the predefined role with the dynamically generated policy as an inline policy. This ensures that the microservice can only access the tenant's specific data. The TVM then returns the scoped AWS credentials to the microservice, which can be used to make authorized calls to DynamoDB.

With the scoped credentials, the microservice can now access the DynamoDB table and retrieve the data associated with the requesting tenant. Any operation performed on the table will be constrained to the specific tenant, ensuring data isolation and security.

Implementing the TVM and dynamic policies in your SaaS architecture requires careful consideration and adherence to best practices. Here are three actionable advice to guide you in the implementation:

1. Reduce request latency by caching TVM-generated tokens: To enhance performance, consider caching the TVM-generated tokens for each tenant to their respective resources. These tokens can be used until they expire, reducing the need for frequent token generation.

2. Use Git tag version numbers for policies: Instead of relying on commit hashes, use Git tag version numbers for the policies. This provides a more readable value indicating the current version of policies being used. In case of a rollback, you can easily change the version number to revert to a previous set of policies.

3. Optimize policy loading from S3: Currently, the solution loads the entire policies folder from Amazon S3. This can result in increased loading time if there are a large number of templates. To optimize this, consider loading only the necessary policy templates needed at any given moment, reducing unnecessary overhead.

In conclusion, data partitioning and dynamically generated isolation policies are essential components of a robust SaaS architecture. By implementing these practices, you can ensure data security, scalability, and efficiency while providing a seamless experience for your tenants. With the right approach and adherence to best practices, you can effectively manage data isolation in your SaaS environment.