IT Infrastructure Consolidation: Data Isolation Without License Duplication
When consolidating the IT infrastructure of several organisations, a dilemma arises: whether to build separate systems for each agency or to create a shared platform. Multi-tenancy eliminates the need for infrastructure duplication, but requires strict data isolation and flexible privilege configuration for local administrators without halting the entire system.
An attempt to merge the digital services of multiple agencies often ends either in the creation of dozens of isolated infrastructure copies, which burns budgets on licenses, or in a chaotic merger of databases where one user can see the documents of a neighbouring organisation. Choosing an architecture requires a balance between physical and logical isolation.
Three data storage models in multi-tenant architectures
Designing a shared platform for multiple organisations begins with choosing a data storage model. Architectural concepts distinguish three main approaches to database organisation: a separate database for each tenant (database-per-tenant), separate schemas within a shared database (schema-per-tenant), and a shared database with a shared schema (shared database, shared schema).
The model with separate databases provides the highest level of physical isolation. However, it is the most expensive in terms of resource utilisation and administration. The model with separate schemas within a single database is a compromise option that reduces licensing costs but maintains the logical separation of objects.
The most cost-effective model is a shared database with a shared schema. The logical separation of data belonging to different tenants in such a schema is ensured using Row-Level Security (RLS) technology. RLS at the DBMS level automatically filters table rows depending on the user's session context. However, RLS provides logical rather than physical data separation.
| Comparison criterion | Separate database (Database-per-tenant) | Separate schemas (Schema-per-tenant) | Shared database and schema with RLS (Shared database) |
|---|---|---|---|
| Isolation level | Maximum (physical) | Medium (logical at the schema level) | Minimum (logical at the row level) |
| Resource utilisation efficiency | Low (high license costs) | Medium (shared DBMS instance) | Maximum (optimal pool utilisation) |
| Data schema update complexity | High (requires sequential migration of all databases) | Medium (schema migration within a single database) | Low (one-time update of the shared schema) |
Applying the ISO/IEC 27017 standard for access control
When designing a multi-tenant architecture for the public or educational sector, the international standard ISO/IEC 27017 serves as a security benchmark. This standard provides recommendations on information security controls applicable to the provision and use of cloud services. It outlines methodological requirements and the separation of roles between the service provider and the customer.
The standard does not contain ready-made technical instructions or ready-made code to implement isolation. It provides a framework for the allocation of responsibilities. Technical implementation (RLS, RBAC) is the responsibility of the architect, who must reflect these requirements in the code, ensuring that the platform administrator does not have access to tenant data.
- Allocation of responsibilities Designing a clear boundary between platform administration and the data management of a specific tenant.
- Logical separation Applying RLS mechanisms to isolate data of different organisations in a shared repository.
- User action auditing Creating isolated audit logs for each tenant.
- Lifecycle management Ensuring a procedure for the secure deletion of an organisation's data upon exiting the platform.
Why Kubernetes Namespaces do not protect data at the code level
Modern shared platforms are often deployed in containerised environments managed by Kubernetes. The use of Namespaces and Role-Based Access Control (RBAC) is standard for resource isolation at the orchestration level. They separate the computing resources of different organisations within a single physical cluster.
However, Kubernetes Namespaces provide isolation only at the orchestration and management level (control plane). They cannot protect data from leakage if a vulnerability exists in the application code itself or if the application uses a shared database without proper access privilege configuration at the DBMS level.
Strategies for tackling the "noisy neighbour" problem
In multi-tenant environments, the "noisy neighbour" problem arises — a situation where one organisation, due to peak load, consumes an excessive amount of resources, leading to performance degradation for other platform users.
To prevent this phenomenon, architects use a combined approach. At the database level, they implement resource consumption limits and restrict the number of connections in the pool for each tenant. At the Kubernetes orchestration level, they apply resource quotas (ResourceQuotas) for each namespace, which limits the maximum consumption of CPU time and memory by individual containers.
- Connection pool limits Restricting the maximum number of concurrent connections to the DBMS for each tenant.
- CPU time quotas Configuring CPU limits in Kubernetes to prevent monopolisation of computing power.
- Memory limits Setting Memory limits for containers to avoid OOM errors in neighbouring services.
- Traffic prioritisation Using QoS mechanisms to guarantee the servicing of critical requests.
Dynamic configuration and adaptation of the Tagged Storage pattern for On-Premise
To ensure the flexibility of a shared platform, each organisation must be able to configure its own business processes without restarting the entire system. To solve this task, the Tagged Storage pattern is used, which dynamically stores and updates the configurations of different tenants in real time (zero-downtime).
In cloud environments, this pattern is implemented using specific services (for example, AWS Systems Manager Parameter Store). However, for the Ukrainian public sector, the use of public clouds is often restricted. When porting the Tagged Storage pattern to an on-premise infrastructure, architects are forced to develop their own analogues of cloud services for dynamic configuration distribution, using tools like Consul or Redis for the centralised storage of tenant parameters.
IQusion solves the infrastructure consolidation problem by implementing Megapolis.DocNet and Scriptum.DMS systems based on the domestic low-code platform UnityBase. Thanks to built-in support for Row-Level Security (RLS) and flexible access control (RBAC, ACL), UnityBase ensures the creation of unified high-performance platforms for multiple organisations with strict data isolation without the need for license duplication.
Frequently Asked Questions
When should one choose the schema-per-tenant model instead of a shared database?
The schema-per-tenant model is a compromise option when a higher level of logical isolation than RLS is required, but the budget does not allow for deploying separate databases. It is suitable for organisations that require separate backups of their data but are willing to share a common DBMS instance.
How can the "noisy neighbour" problem be practically resolved during system consolidation?
To resolve the "noisy neighbour" problem, resource consumption limits are implemented at the database level, and the number of connections in the pool is restricted for each tenant. At the Kubernetes orchestration level, resource quotas (ResourceQuotas) are used within individual namespaces (Namespaces).
Why is isolation at the Kubernetes Namespaces level insufficient for data protection?
Kubernetes Namespaces provide isolation solely at the orchestration and cluster resource management level (control plane). They do not protect data at the application code or database level, and therefore require additional configuration of RLS or other mechanisms at the DBMS level.
