Software as a Service (SaaS) has become a popular model for delivering software applications to users because it provides a convenient way to access software over the internet without the need for local installation or maintenance. However, one of the most difficult challenges for SaaS providers is ensuring that the data and resources of different tenants (or customers) are kept separate and secure from one another. This is where SaaS tenant isolation strategies come into play.

The technique of preventing other tenants on the same SaaS platform from accessing the data and resources of one tenant is known as tenant isolation. A breach of tenant isolation can lead to data leaks, privacy violations, and potentially legal repercussions, making it a crucial component of SaaS security.

‍

In order to achieve tenant isolation, SaaS providers can employ a number of techniques, such as network segregation, data encryption, access controls, and containerization. The choice of method depends on a number of variables, including the type of SaaS service, the amount of security needed, and the resources available. Each technique has merits and limitations of its own.

We will examine various SaaS tenant isolation solutions in-depth in this post, outlining their benefits and drawbacks while offering advice on how to pick the best approach for your SaaS platform. We’ll also examine some actual cases of SaaS companies using tenant isolation and the difficulties they encountered in the upcoming articles. You will have a better knowledge of the value of tenant isolation in SaaS and the methods available to achieve it by the end of this series.

‍

Every SaaS provider needs to create a set of high-level isolation requirements that will serve as a roadmap for their teams as they define the isolation footprint of their SaaS environments. The following are some fundamental principles that frequently influence the overall SaaS tenant isolation model:

‍

Isolation is not optional:

Isolation is a fundamental component of SaaS and is not optional. As such, every system that provides a solution in a multi-tenant model must ensure that its systems take steps to isolate each tenant’s resources.

‍

Authentication and authorization are not equal to isolation

Getting through the entrance points of a login screen or an API does not imply that you have achieved isolation, even if it is assumed that you will control access to your SaaS environments through authentication and authorization. This is just one component of the isolation puzzle and is insufficient by itself.

‍

Isolation enforcement should not be left to service developers

While it’s not reasonable to anticipate that developers will never unintentionally breach a tenant border, they are never expected to provide code that might violate isolation. To counteract this, a shared mechanism that enforces isolation constraints should be used to regulate the scope of access to resources (outside the view of developers).

‍

If there is no readily available solution for isolation, you might have to build it yourself.

The road to tenant isolation can be made easier by a number of security tools, like AWS Identity and Access Management (IAM). Isolation is frequently a rather seamless experience because of these tools and their interaction with a more comprehensive security framework. There might be circumstances, nevertheless, in which a similar product or technology does not immediately address your isolation model. Even if it involves creating something on your own, the lack of an obvious option shouldn’t be used as an excuse to reduce your isolation needs.

‍

Core Isolation Concepts

Following are the major models available for achieving tenant isolation.

• Silo Isolation Model
• Pool Isolation Model
• The Bridge Model
• Tier-Based Isolation Model

‍

Silo Isolation Model

Even while SaaS providers frequently emphasize the benefits of resource sharing, there are still situations where a SaaS provider may decide to deploy some (or all) of its tenants in a manner where each tenant is running a fully isolated stack of resources. A SaaS environment, according to some, is not accurately represented by this full-stack paradigm. But, if you have shared identification, onboarding, metering, metrics, deployment, analytics, and operations around these distinct stacks, we’d still argue this is an acceptable SaaS version that sacrifices operational efficiency and scale economies for compliance, business, or domain considerations. Using this method, isolation is a construct that spans the full customer stack from beginning to finish.

‍

The technologies that power these stacks are largely unimportant in this context. This might be a monolith, a serverless system, or some combination of the other application architectural types. The fundamental idea is that we will take whatever stack the tenant has and wrap it with some construct to contain all of its moving pieces. This establishes the limit of our seclusion. You’ve achieved the isolation as long as you can keep a tenant from leaving their completely enclosed area. In general, it is significantly easier to enforce this isolation approach.

‍

Merits:

• Supporting challenging compliance models
  Some SaaS providers sell into regulated environments with stringent isolation requirements. The silo gives these Independent Software Vendors the ability to provide some or all of their tenants with the option of being deployed in a dedicated model.
• No noisy neighbor concerns
  While all SaaS providers ought to make an effort to mitigate the effects of noisy neighbors, certain clients may still have concerns about how the activities of other tenants utilizing the system can affect their workloads. By providing a separate environment without the possibility of noisy neighbor situations, Silo allays this worry.
• Tenant cost tracking
  SaaS suppliers frequently place a strong emphasis on comprehending how each tenant affects their infrastructure costs. It can be difficult to determine the cost per tenant in some SaaS arrangements. But, the silo model’s coarse-grained structure gives us a quick way to identify and link infrastructure expenses to each tenant.
• Limited blast radius
  The silo architecture typically lowers your risk when your SaaS solution may have an outage or other disaster. Any errors that occur within a certain tenant’s environment of a SaaS provider will probably be contained in that environment because each SaaS provider is running in its own environment. Even if one tenant can encounter a problem, the fault might not spread to the other tenants using your system.

Limitations:

• Scaling issues
  There are restrictions on how many accounts can be supplied. This restriction can prevent you from choosing the account-based model. However, there are general worries about how a quickly expanding customer base may degrade the management and operational efficiency of your SaaS infrastructure. For instance, if each of your tenants has 20 segregated accounts, that might be manageable. But, having a thousand tenants would probably start to affect operational agility and efficiency.
• Cost
  We’re missing out on a lot of the cost effectiveness that SaaS solutions are often known for because each tenant runs in its own environment. Even though these settings scale dynamically, there will probably be times of the day when you have idle resources that are not being used. This is a very fine strategy, but it makes it more difficult for your company to realize the economies of scale and margin advantages that are crucial to the SaaS model.
• Onboarding automation
  Automation of the onboarding of new tenants is valued in SaaS environments. You’ll require automated onboarding regardless of whether you’re employing a self-service model or an internally run provisioning process to onboard these tenants. And this frequently becomes a lot heavier procedure when you have distinct silos for each tenant.

‍

‍

Pool Isolation
It’s not difficult to understand how the silo paradigm of isolation fits in well with many SaaS businesses. The efficiency, agility, and cost advantages of allowing their tenants to share some or all of their underpinning infrastructure are also sought after by many businesses making the switch to SaaS. The isolation story becomes more complex as a result of this shared infrastructure strategy, known as a pool model.

‍

You’ll observe in this model that our tenants are using infrastructure that is available to all tenants. In direct proportion to the actual load imposed by the tenants, the resources can thereby scale. We’ve service compute to the right of the diagram to emphasize how tenants 1-N may all be operating concurrently on your shared compute at any given time. Also, you’ll observe that the storage in this illustration is also shared.

Although this paradigm is a fantastic fit for SaaS providers, it complicates the entire isolation tale, as you can see. Given the shared nature of the resources, it’s unclear what it would imply to create isolation in this case. We cannot rely on the standard networking and IAM frameworks to establish partitions across tenants.

The important thing to remember is that, despite the fact that this environment makes isolation more difficult, you cannot use this as justification for lowering the isolation standards in your environment. If anything, these common models enhance the likelihood of cross-tenant access, therefore you should take extra care to ensure that resources are separated in this area.

You will see as we delve deeper into the pool isolation model (above) how this architectural footprint offers a special mix of difficulties, each of which calls for a particular kind of isolation structures to properly isolate a tenant’s resources.

‍

‍

Merits:

• Agility
  The pool model’s main goal is to give SaaS providers the ability to expand, administer, and operate all of their tenants through a single interface.
  The cornerstone for enabling SaaS providers to easily manage and deploy changes to all tenants without having to carry out one-off actions on a tenant-by-tenant basis is centralizing and standardizing the experience. Its operational effectiveness is essential to your SaaS environment’s overall agility footprint.
• Cost efficiency
  SaaS’s low cost appeals to plenty of businesses. This cost-effectiveness is frequently attributed in large part to the pool concept of isolation. Your system will scale in a pooled environment based on the real load and activity of all of your tenants. Your infrastructure costs should be low if all of the tenants are not online. The basic idea is that pooled environments may dynamically adjust to tenant demand, allowing you to better match resource usage with tenant activity.
• Simplified management and operations
  Isolation pool concept gives you a single view of all the tenants in my system. All of your tenants can be managed, updated, and deployed through a single interface that affects all of your system’s tenants. Most elements of the management and operational footprint are simplified as a result.

Limitations

• Noisy neighbor
  The likelihood that one tenant will have an impact on another tenant’s experience increases as more resources are shared. For instance, any activity by one tenant that places a significant demand on the system may have an effect on other tenants. Although a smart multi-tenant architecture and design will work to minimize these effects, there is always a potential that one or more of your tenants in a pooled isolation model will be impacted by a loud neighbor scenario.
• Tenant Cost Tracking
  Under a silo architecture, it is much simpler to link a tenant’s use of a resource to that tenant. The attribution of resource consumption, however, is more difficult under a pooled approach. As a result, each SaaS provider will have to put in more effort to instrument their systems and reveal the granular data required to accurately link consumption to specific tenants.
• Blast radius
  Also, there is some operational risk involved with sharing all of your resources. When one tenant failed in the silo model, its effects were probably only felt by that particular tenant. In contrast, if your system is pooled, an outage will probably affect every tenant. This can significantly affect the company. This frequently necessitates a stronger dedication to creating a robust environment that can detect, surface, and elegantly recover from problems.

‍

The Bridge Model
The isolation environment for many SaaS companies is less rigid even though silo and pool have very different approaches to isolation. As you examine actual application difficulties and break down our systems into smaller services, you’ll frequently find that the best solution calls for combining the silo and pool models. This mixed model is an example of an isolation bridge model.

‍

This monolithic architecture features traditional web and application levels. For this solution, the web tier is implemented using a pool model that is shared by all tenants. Although the web tier of our application is shared, the application’s storage and core business logic are actually deployed in a silo format, with each tenant having a separate application tier and storage.

Imagine dividing this monolith into smaller services. It is possible to envision how each of the several microservices in our system might use a combination of the silo and pool concepts. As we discuss the mechanics of using silo and pool with other AWS constructions, we’ll get deeper into it.

The main lesson to be learned from this is that your understanding of silo and pool will be considerably more precise for settings that are divided into a number of services with various levels of isolation requirements.

‍

‍

Tier-Based Isolation

There are situations where your isolation strategy might be influenced by the tiering of your product, even while the majority of our discussion on isolation focuses on the technical aspects of limiting cross-tenant access. In this situation, it’s less important how you isolate tenants and more important how you might bundle and provide various levels of isolation to various tenants with various profiles. To target the whole range of clients you wish to engage, you may need to support certain kinds of isolation. This is another factor to take into account.

The pooled environment is being used by tenants at the silver tier. These tenants fully anticipate that even though they are using a shared infrastructure model, no other tenants will be able to access their resources. You must provide the tenant on the right with a totally dedicated (silo) environment. To facilitate this, the SaaS provider developed a premium tier model that enables users to operate in this specific paradigm at what we presume to be a significantly higher cost.

Several SaaS firms have the idea of private pricing, where tenants choose to pay a premium to be deployed in this manner, even if SaaS providers often strive to limit supplying a silo model to their clients. In order to restrict the number of customers that choose this choice, SaaS businesses actually won’t advertise this as an option or designate it as a tier. You’ll start to revert to a fully segregated approach and inherit many of the issues we discussed above if too many of your tenants fit into this paradigm.

‍

SaaS providers frequently demand that these premium clients use the same version of the product as is delivered to the pooled environment in order to reduce the impact of these one-off environments. As a result, the Independent Software Vendor(ISV) may keep controlling and managing both environments from a single point of access. The pooled environment, which just so happens to be serving one tenant, is essentially duplicated in the silo environment.

‍