Security Practices for Designing AWS Multi-Tenant SaaS Environment

Introduction

The multi-tenant architecture enables multiple users to share a single instance of a software application and the AWS resources. A tenant can be an individual user, but most frequently, it is a group of users – such as a customer organization. The customers will share the common access and privileges within the application instance. Each user’s data is isolated and invisible to other users sharing the application instance, data security, and privacy for all the users.

Tenants are associated with the customized policies for the shared resources, liking controlling which user must access the resources.

Advantages of Multi-tenancy Applications

1. Scalable: Resources are added and removed by the users when required. It is very flexible with the requirement.
2. Cost-effective: It is cost-effective because the multiple tenants use the shared resources. Users are billed only for their use. Cloud hosts take care of staff and maintenance and onboard new users.
3. Secure: Multitenancy is good at threat detection, and tenant data is isolated. Customized policies are applied to the shared resources.
4. Better use of resources: Multitenancy use the infrastructure in a better way. Multiple users access a single instance instead of limiting it to a single user.
5. Maintenance free: The host will handle the maintenance, updates, and upgrades related to the infrastructure.

SaaS Application Security Considerations

Security is one of the major concerns for all types of applications. It is one of the significant considerations while deploying the SaaS application. Securing SaaS applications in an environment where multiple tenants share is challenging. Multi-tenant application has unique security considerations when compared to single-tenant applications. Multi-tenant applications must concentrate on an additional layer of security.

• Identity:

Single tenant accesses SaaS application through a web application or API. Each user is uniquely identified and associated with the authentication information such as email address, name, and role. The tenants are also defined as a group of one or more users with the same privileges to access the application. Roles assigned to the tenants may differ from other tenants.

When a user tries to access the application, the user must provide the tenant details alone with the authentication details. The application will verify the information and makes the authorization decision.

There are two techniques in a SaaS application: Using an identity provider (IdP) and Authorization in a token.

Using an Identity Provider:

Some web applications will store the user data in a relation DB, post the user authentication is successful, the application will issue a session ID. For the frequent request from the user, the user will pass the Session ID to the application and the application will make the authorization decision based on the session ID. 

Each request usually results in at least one database cache look-up, creating a bottleneck on the data store handling the user or session information. 

The identity provider issues a standardized token when the user authenticates with an identity provider.

Representing Identity with tokens

The signed token usually represents identity. JSON web signature is often called JSON Web Tokens (JWT). The token contains several key-value pairs called claims. The identity provider issues the tokens. It also contains user and tenant information.

Sample Access Token Claims

The user and the tenant the user is associated with are represented by this token. The token contains the user identification details and the tenant ID in the Cognito: groups claim. SaaS application receives a JWT as request, the application will validate the token and unpacks the data to make the authorization. Tenant context is the claims within the token set.

• Tenant Isolation

Tenant isolation will ensure that the data is isolated for all the SaaS applications. One tenant must not access the data or resources of another tenant access.

SaaS applications use three types of isolation models: Silo, Pool, and Bridge. Let us look at each one of them in detail.

1. Silo Deployment model:
   In this model, the customer will deploy one set of infrastructure per tenant. There are some shared infrastructures for cross-tenant usage.
   Example: VPC per tenant, a set of containers per tenant, or the RDS per tenant.
   
   
2. Pool Deployment Model:
   In this model, the infrastructure is shared with all the users. Tenant isolation is implemented logically in this model at the application level.
   
   In the above example, the lambda retrieves an item from DynamoDB. DynamoDB is shared with all the tenants, and the tenants will need the temporary credentials to access the DB table. The credentials are shared by AWS Security token service. The certificates only allow the users to access the data in the DB that belongs to the tenant making the request.
3. Bridge Deployment Model: This model is a combination of both models (Silo and Pool). In this model, some resources are shared, and some are isolated. Choosing the isolation model depends on the customer’s requirements, industry, and compliance needs.
   
   The above diagram shows how the silo pool model is integrated, and the bridge model is formed. The web tier is deployed in the pool model, and the App tier is deployed in the silo model. All the tenants access the web tier as a pool model, and the tenants use their app tier as a silo model.

Conclusion

In Multi-tenant SaaS applications, security is one of the significant concerns. As per the best practice, it is recommended to follow one of the security considerations for the application to be safe. Based on the requirement of the customers, the security considerations can opt.

About CloudThat

CloudThat is the official AWS (Amazon Web Services) Advanced Consulting Partner, Microsoft Gold Partner, Google Cloud Partner, and Training Partner helping people develop knowledge of the cloud and help their businesses aim for higher goals using best-in-industry cloud computing practices and expertise. We are on a mission to build a robust cloud computing ecosystem by disseminating knowledge on technological intricacies within the cloud space. Explore our consulting here.

If you have any queries regarding AWS multi-tenant SaaS environment,  security best practices, or any other AWS service, drop a line below the comments section. I will get back to you at the earliest. 

FAQs

1. How to decide on the tenancy model?

The tenancy model does not make any changes to the application’s functionality. We must consider the application layer to decide on the tenancy model. The tenancy model may differ if the application layer is divided into components. Some application components must be treated differently regarding both tenancy and the storage technology/platform used.

2. What are the criteria for choosing the tenancy model?

Following are the criteria to be considered: Scalability, Pre-Tenant cost, Development complexity, Operational complexity, and Customizability.

WRITTEN BY Sindhu H