Tenant isolation in multi-tenant systems: What you need to know

Imagine a big apartment building. Each apartment is a separate space where different families (or tenants) live. Even though the building is shared, each family has a locked door, privacy, and things that belong only to them.

A multi-tenant system is like that building, but instead of families, you have different businesses or users who all share the same system. Each business (tenant) can only see and use its own things, just like a family can only enter its own apartment.

Even though businesses use the same system, the system makes sure their "stuff" doesn’t mix up. This is called tenant isolation—it keeps each tenant's information safe and separate, just like each family’s apartment is private. In this article, we will see how tenant isolation works and which are the different options.

Tenant isolation comes in different levels

Tenant isolation is a spectrum. It can be:

• Fully isolated, where each tenant has separate resources, databases, and network infrastructure.
• Fully shared, where each tenant shares resources, databases, and network infrastructure.
• Everything in between (e.g., share resources and network infrastructure, but use a separate database).

Each company's needs and restrictions are different, and you can set up parts of your system to be more or less isolated based on your case.

Data isolation

In multi-tenant systems, tenants can share the same database or have separate databases. The common approaches are:

• Shared database, shared schema (table-level isolation): All tenants use the same database and share the same tables, but each tenant’s data is tagged with a unique identifier (e.g., tenant ID). Queries are designed to always filter by this tenant ID to ensure one tenant cannot access another's data. This approach is simpler and less resource-intensive because all tenants share the same schema. However, it can lead to challenges in terms of data security, data isolation, and customization because all tenants' data reside in the same tables. This is generally not as preferred when there are strict data isolation requirements.
• Shared database, separate schema (schema-level isolation): Tenants share the same database, but each tenant gets a separate schema (basically a set of tables and objects within the database). This creates a logical separation of data within the same physical database. This approach offers a good balance between isolation and resource efficiency. It provides better data isolation than shared schema, allowing for customization at the schema level, and is easier to scale compared to separate databases. This is the most common approach because it combines relatively simple management with the ability to isolate tenant data effectively.
• Separate databases (database-level isolation): Each tenant has its own database, completely isolated from other tenants' data. While this provides the highest data isolation and security level, it comes with significant overhead regarding resource management, maintenance, and scaling. This approach can be cost-prohibitive for larger SaaS applications with many tenants.

Data encryption

Data encryption in multi-tenant systems is essential for securing tenant data and ensuring privacy, especially when multiple customers share resources in the same infrastructure.

There are two main types of encryption used to secure data in multi-tenant systems:

• Encryption at rest: Encryption at rest protects data stored in databases, file systems, or other storage systems. Data is encrypted when stored, and only authorized users or systems with the proper decryption keys can read or write the data. Some approaches to encrypting data at rest are:
  
  • Row-level encryption: Data could be encrypted at the row level to ensure each tenant’s data is separately encrypted. This ensures that even if tenants' data resides in the same tables, each tenant’s data remains inaccessible to others.
  • Column-level encryption: Another option is to encrypt specific columns (such as sensitive customer data) within shared tables. Only authorized users or applications would have the decryption keys to view the encrypted columns.
• Encryption in transit: This type of encryption ensures that data is secure while being transmitted across networks, such as between clients and servers or between services. Transport Layer Security (TLS) or Secure Socket Layer (SSL) protocols are used to encrypt data during transmission, ensuring that data cannot be read or altered while in transit.

Another critical concern in multi-tenant systems is managing encryption keys, the gateway to accessing the encrypted data. Some of the approaches used are:

• Tenant-specific keys: One approach is to assign unique encryption keys for each tenant. This means that even if an attacker gains access to one tenant’s data, they won't be able to access other tenants' data.
• Shared key management: Alternatively, some systems use shared encryption keys for all tenants and rely on additional mechanisms, such as tenant identifiers, to separate data. While this simplifies key management, it can raise security concerns because one compromised key could potentially expose all tenant data.
• Hardware Security Modules (HSM): Some systems use HSMs to manage encryption keys securely. HSMs provide physical and logical protection against key theft or unauthorized use, adding an extra layer of security.

Resource isolation

Resource Isolation in multi-tenant systems refers to the mechanisms and techniques used to ensure that the computational, storage, and network resources assigned to one tenant are isolated from those of other tenants. Proper resource isolation ensures that one tenant’s usage of resources does not impact the performance, security, or availability of other tenants' resources while also maintaining efficient resource allocation and scalability.

There are several techniques that can be used to isolate resources in a multi-tenant environment. These can be applied at different layers, such as hardware, virtualization, containers, and application layers.

• Systems may use virtual machines (VMs) or containers (like Docker) to separate tenant workloads. Each tenant's processes run in isolated environments (virtual machines or containers), which means that a crash or security breach in one tenant's environment doesn't affect others.
• Each tenant can be allocated a specific amount of resources (e.g., CPU, memory, storage). This helps ensure that one tenant's usage doesn't consume excessive resources and affect the performance of others. Quotas can be imposed on CPU, memory, storage, or network bandwidth. These quotas can be set on a per-tenant basis to ensure fair distribution of resources.

Network isolation

Network Isolation in multi-tenant systems refers to the practice of ensuring that the network resources, traffic, and communications between tenants are segregated in a way that prevents one tenant from accessing or interfering with another tenant’s data or operations. Network isolation is essential for protecting tenant data, maintaining compliance with regulatory standards, and ensuring that the system’s resources are used efficiently. It involves creating logical and/or physical boundaries between the tenants' network traffic to prevent unauthorized access, mitigate risks, and ensure fair and predictable performance.

Logical isolation is the most common form of network isolation in cloud-based or virtualized multi-tenant systems. It uses software-defined technologies to separate tenant traffic without requiring physical hardware separation. Common methods include:

• Virtual LANs (VLANs): A VLAN is a logical grouping of network devices that are isolated from other devices on different VLANs, even if they share the same physical network infrastructure. Each tenant can be assigned to its own VLAN, ensuring that their network traffic is isolated from other tenants. It’s scalable, flexible, and cost-effective, but more complex to manage as the number of tenants increases.
• Virtual Private Networks (VPNs): A VPN can be used to create a secure, encrypted tunnel for a tenant’s traffic over a shared network. Each tenant can have its own private virtual network within the shared infrastructure, with all traffic encrypted and isolated from other tenants. It provides strong security and privacy for tenant traffic but can introduce latency and potential scalability challenges if not managed properly.
• Software-Defined Networking (SDN): SDN allows for the dynamic, programmatic control of network traffic. Using SDN, tenants can have their network traffic isolated through software configurations that create virtualized, isolated networks within the same physical infrastructure. SDN is highly flexible and scalable but requires advanced software-defined network infrastructure and management.
• Network policies and micro-segmentation: With micro-segmentation, the network is divided into smaller, isolated segments. Tenants' networks and applications can be isolated at a granular level using policies that control traffic flow and enforce separation. This can be done using technologies such as network firewalls, access control lists (ACLs), and policy-driven routing. It provides very granular and fine-grained control over network access but is complex to manage in large-scale environments with many tenants.

Another option is physical isolation. It involves dedicating separate physical network resources (such as physical switches, routers, or even separate physical data centers) to each tenant. This approach provides the strongest isolation but can be more expensive and less scalable than logical isolation. Physical isolation can be achieved by assigning each tenant either its own physical networking infrastructure (like a separate network switch or router) or a completely isolated, dedicated private cloud or private data center environment. The latter is common in industries with strict compliance requirements.

Authentication and authorization

Multi-tenant systems often use an identity provider (like OAuth, OpenID Connect, or custom SSO) to authenticate users. Each tenant can have its own authentication mechanism or shared mechanism with tenant-specific configurations, ensuring users only access their own tenant’s data.

After authenticating a user, the system checks their roles and permissions to ensure that they can only access data within their tenant’s scope. Different roles (like admin, user, etc.) can be assigned to each tenant. Access control mechanisms, like RBAC, can ensure that users within a tenant only have permission to perform certain actions (e.g., reading data, updating data) that are scoped to their tenant's data.

Tenant context

When processing requests, the system needs to keep track of which tenant a user belongs to. This is often done by adding a tenant context in every request (e.g., passing a tenant ID in API calls or HTTP headers). This context helps to isolate data and ensure the right information is shown to the right user.

Tenant-specific information is also used to track and log who accessed what data and when. This allows for auditing and monitoring suspicious activities per tenant.

Compliance and legal isolation

Legal isolation refers to ensuring that each tenant’s data remains legally separate from others in a way that respects the privacy, security, and compliance requirements specific to each tenant. This is especially important when different tenants may have different legal or regulatory obligations regarding their data.

For some industries, like healthcare or finance, tenant isolation may need to meet certain regulatory requirements (e.g., GDPR, HIPAA). In such cases, ensuring proper data isolation, access control, and audit logging is necessary to comply with these regulations.

In multi-tenant systems, different tenants may have different legal agreements or terms of service. These agreements often specify how their data is handled, stored, processed, and protected, ensuring legal compliance for each individual tenant.

Conclusion

Tenant isolation in a multi-tenant system ensures that each tenant's data, resources, and processes are kept separate, even though the tenants share the same infrastructure. This is achieved through various methods like data separation (using separate databases or schemas), application-level isolation (with role-based access), resource isolation (using containers or virtual machines), and strong security measures (authentication, encryption, etc.).

By isolating tenants effectively, a multi-tenant system can provide both efficiency (by sharing resources) and security (by ensuring each tenant’s privacy and control).