Multi-Tenant SaaS: Data and Access Isolation
· PoolByte Technology
Offering a single software to serve multiple companies is not complete with each customer having a separate account. In a multi-tenant SaaS structure, boundaries between organizations' data, transactions and resource usage must be maintained throughout the entire application. Tenant ID is not just a company name selected on the screen.
There is no single model for data separation
Tenant data can share tables in one database, use separate schemas, or reside in separate databases. Each approach has different operating, cost and isolation features. Microsoft multi-tenant data architecture guide describes the evaluation areas for these options. It is not enough to choose a single model based on the number of customers alone.
A customer may have a need to restore from a separate backup, data region, or specific performance. If the design does not meet these requirements, subsequent decoupling may become costly. In the first instance, it should also be defined what the tenant is: company, dealer or sub-unit of the company may require different boundaries.
Don't blindly trust the tenant value from the request
The company ID in the URL or form does not prove that the user has access to that organization. The server must determine the scope via authenticated user and membership. A forgotten filter in a single query could reveal another customer's record. OWASP multi-tenant security guide discusses protecting this boundary at different layers.
File downloads, exports, and search endpoints should follow the same rule. Don't assume that the detail screen is safe just because the main list is filtered correctly. Background jobs, notifications, and cache keys must maintain the tenant context. When context is lost in a job queue, the error may not occur in the page view alone.
Customers should also be separated in terms of resources
If one organization produces too large a report, it may slow down the service for others. Quotas, job queues, and appropriate resource limits help manage this impact. You don't have to give every customer the same limit; but plan conditions and actual implementation behavior must be consistent. Show a clear wait or reject status instead of losing data when the limit is exceeded.
Administrator support access is also a special case. When reviewing a customer's account, the scope of authority, duration and transaction record should be determined. A general administrator authority should not be used in all day-to-day affairs. Test how the open screen and local data of the previous organization are cleared during tenant switching.
How do you verify tenant isolation?
- Try the same record IDs with users from two different organizations.
- Compare search, download and export results.
- Verify the tenant context in background jobs.
- Search for cross-tenant data exposure in cache and browser data.
- Measure the impact of one tenant's busy work on others.
- Test current session behavior after membership is removed.
In custom software project multi-tenancy should be a separate architecture deliverable. Changing the customer logo is personalization; Tenant isolation is the basic system behavior that ensures that data and access remain at the correct boundaries.