Multi-Business Unit Storage

Business Unit data must be separated to ensure that one business unit'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-business unit  
NoSQL DynamoDb, MongoDb, Elasticsearch Business Unit-based-attribute  
Object storage S3 Namespace and file-based Files can also be encrypted uniquely per business unit.

Business Unit Isolation Architecture Models

Business Unit isolation architecture models can be divided into a few categories. These categories include business unit isolation levels at rest and business unit isolation in transit. Business Unit 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 business unit will have a different database for maximum isolation.

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

All business unit'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 business unit's data is placed together. A unique Business Unit ID key separates data records for each business unit.

Tenant Isolation in Transit

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

Data Stores

You should maintain a separate schema per business unit on the data store. The service will maintain separate connection pools per business unit, where connection retrieval strictly requires the business unit 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 business unit. 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 business units by business unit 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 business unit isolation.

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

Services access the inCode database directly. They must provide a Business Unit 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.