SaaS Factory (The Series) — The Secrets of Identity and Access Control in SaaS

Tenant isolation is one of the foundational topics that every software as a service (SaaS) offering must address. As independent software vendors (ISVs) make the shift toward SaaS and adopt a shared infrastructure model to achieve cost and operational efficiency, they also have to take on the challenge of determining how their multi-tenant environments will ensure that tenants are prevented from accessing another tenant's resources. Crossing that boundary in any way would represent a significant and potentially unrecoverable event for a SaaS business.

Authentication and authorization are not the same as isolation — while you are expected to control access to your SaaS environments through authentication and authorization, getting past the entry points of a login screen or an API does not mean you have achieved isolation. This is just one piece of the isolation puzzle, and it isn't enough on its own.

Isolation enforcement should not be left to service developers — while developers are never expected to introduce code that could violate isolation, it's unrealistic to expect that they will never unintentionally cross a tenant boundary. To mitigate this, scoping of access to resources should be controlled through some shared mechanism that is responsible for applying isolation rules (outside of developers' view).

If there's no off-the-shelf isolation solution, you may need to build it yourself — there are a number of security mechanisms, such as AWS Identity and Access Management (IAM), that can simplify the path to tenant isolation. These tools and their integration with a broader security scheme often make isolation fairly seamless. However, there may be scenarios where your isolation model isn't directly addressed by a corresponding tool or technology. The absence of a clean solution should not be seen as an opportunity to lower your isolation requirements, even if that means building something of your own.

Isolation is not a resource-level construct — in the world of multi-tenancy and isolation, some will view isolation as a way to draw a hard boundary between concrete infrastructure resources. This often translates into an isolation model where you might have separate databases, compute instances, accounts or virtual private clouds (VPCs) for each tenant. While these are common forms of isolation, they are not the only way to isolate tenants. Even in scenarios where resources are shared — in fact, especially in environments where resources are shared — there are ways to achieve isolation. In this shared resource model, isolation can be a logical construct that is enforced by policies applied at runtime. The key point here is that isolation should not be equated with having isolated resources.

Domains may impose specific isolation requirements — while there are many approaches to achieving tenant isolation, the realities of a given domain may impose constraints that call for a specific flavor of isolation. Some high-compliance industries, for example, will require each tenant to have its own database. In these cases, shared, policy-based approaches to isolation may not be adequate.

Core Tenant Isolation Concepts

Silo Isolation

Although SaaS providers often focus on the value of resource sharing, there are still scenarios where a SaaS provider may choose to have some (or all) of its tenants deployed in a model where each tenant runs a fully isolated stack of resources. Some would say this full-stack model does not represent a SaaS environment. However, if you've surrounded these separate stacks with shared identity, onboarding, metering, metrics, deployment, analytics and operations, then we would still say this is a valid variant of SaaS that trades economies of scale and operational efficiency for compliance, business or domain considerations. With this approach, isolation is an end-to-end construct that spans an entire customer stack. The following diagram provides a conceptual view of this take on isolation.

*Full-stack isolation*

Pool Isolation

It's easy to see how the silo isolation model maps very well to many SaaS businesses. At the same time, many companies moving to SaaS are seeking the efficiency, agility and cost benefits of having their tenants share some or all of their underlying infrastructure. This shared infrastructure approach, referred to as a pool model, adds a level of complexity to the isolation story. The following diagram illustrates the challenge associated with implementing isolation in a pooled model.

*Pool Model*

Bridge Isolation

While silo and pool take very distinct approaches to isolation, the isolation landscape for many SaaS providers is less absolute. As you look at real-world application problems and decompose your systems into smaller services, you'll often find that your solution requires a mix of the silo and pool models. This mixed model is what we would refer to as a bridge model of isolation. The diagram in the following figure provides an example of how the bridge model can be realized in a SaaS solution.

*Bridge Model*

Tier-based Isolation

Although most of our discussion of isolation focuses on the mechanics of preventing cross-tenant access, there are also scenarios where the tier of your offering may influence your isolation strategy. In this case, it's less about how you isolate tenants and more about how you might package and offer different kinds of isolation to different tenants with different profiles. Still, this is another consideration that could determine which isolation models you'll need to support to address the full spectrum of customers you want to engage. The following diagram provides an example of how isolation might vary across tiers.

*Tier-based isolation*

Identity and Isolation

Although the scope of this discussion is limited to isolation, it's important to note how identity connects to the isolation model. The reality is that, if you're planning to isolate tenants, you must have some way to represent and identify the tenant that is accessing the resources of your SaaS environment. In many cases, identity will be used in combination with other constructs to acquire the scoping policies and rules that sit at the core of an isolation scheme. How these policies are defined and enforced will vary for each of the isolation models and services you're consuming.

*Connecting isolation and identity*

IAM policy-based isolation

Most of our attention so far has been on strategies for using IAM as the foundation of our pooled isolation model. And while IAM often represents a great option for isolating resources, there may also be scenarios where IAM can't support the kind of isolation your application requires. This is where you may have to step back and look at introducing other frameworks or tools to control access to your application's pooled resources.

Application-enforced isolation typically includes some model in which you express policies (just as you do with IAM). These same frameworks often include policy enforcement mechanisms that sit between you and your resources, authorizing your access to those resources. The diagram in Figure 19 provides a high-level conceptual view of the moving parts that might be part of an application-enforced policy model.

*Policy-based isolation*

In this diagram, you'll see that we have a microservice that needs to access some downstream resources (databases, S3 buckets, etc.). This microservice has been deployed in a pooled model, which means it will process requests from multiple tenants. This microservice's job is to ensure that, while processing those requests, it applies constraints that prevent tenants from crossing a boundary into another tenant's resources. In the diagram, you'll see that our microservice reaches out to the isolation manager to acquire a scoping context that is used to control interactions with, and the resources accessed by, the code running in this microservice.

*Scoping with IAM policies*

Conclusions

After reviewing the isolation concepts described here, you should have a good sense of the landscape of isolation options you'll need to consider when building a SaaS solution on AWS. We explored several key patterns here, highlighting different isolation implementation models that are directly influenced by the domain, compliance, operations and performance profile of your SaaS application. We focused much of this discussion on the silo and pool isolation models, exploring the nuances of how these models are realized across different SaaS models. We also saw how your isolation strategies can be influenced by the AWS services used to build your SaaS environment.

In the next post, we'll talk about how to implement the overall Identity and Access architecture in software as a service solutions on AWS.

SaaS Factory (The Series) — How to Build Software as a Service Solutions on AWS

See you then! =)