Multi-Tenant Storage

Tenant data must be separated to ensure that one tenant's data cannot be accessed by another. The recommended approach for data separation depends upon the type of data store involved. Here are a few examples:

Data Storage Example Separation Method Comments
Relational database MySQL Schema-per-tenant  
NoSQL DynamoDb, MongoDb, Elasticsearch Tenant-based-attribute  
Object storage S3 Namespace and file-based Files can also be encrypted uniquely per tenant.

Tenant Isolation Architecture Models

Tenant isolation architecture models can be divided into a few categories. These categories include tenant isolation levels at rest and tenant isolation in transit. Tenant isolation should be as restrictive as possible based on the limitations of the technology used.

Tenant Isolation Levels at Rest (from the most strict to the most permissive)

  • Each tenant will have a different database for maximum isolation.

  • To enable the application layers to pick up the right database upon the tenant's request, you will need to maintain metadata in a separate store (such as Amazon DynamoDB) where mapping of a tenant to its database is managed.

All tenant's data resides in the same database. The data is tied to different schemas or tables to provide a level of isolation.

In this model, all tenant's data is placed together. A unique Tenant ID key separates data records for each tenant.

Tenant Isolation in Transit

In transit, every request has to have tenant context, unless it serves a cross tenant job. For example, the cross tenant load report.

Data Stores

You should maintain a separate schema per tenant on the data store. The service will maintain separate connection pools per tenant, where connection retrieval strictly requires the tenant in the JWT.

A diagram that shows how CMC Work Items Service interacts with separate tenant schemas.

For document stores like DynamoDB, there is not a concept of separate schemas like that in an RDBMS. Instead, you should name-space the tables for each tenant. This ensures a table-level separation and aligns with other AWS constructs.

A diagram that shows how CMC Work Items Service interacts with separate tenant workitems tables.

ACD Data Stores with Logical Separation

Some databases logically separate tenants by tenant index key. In these databases, services are not allowed to directly access the inData database. The inData database holds the persistent data tables or views. Another database (inCode) is paired with the inData database to do the following:

  • Hide underlying structures.

  • Enforce tenant isolation.

  • Provide audit information for any data operations about the information life cycle.

Services access the inCode database directly. They must provide a Tenant ID in the inCode database to access the inData database.

A diagram that shows how services interact with the MSSQL Server and how InCode and InData interact within that server.