Security Considerations When Building SaaS
This article briefly talks about the different models of providing tenant isolation and then delves into the security considerations of building a SaaS.
Join the DZone community and get the full member experience.
Join For FreeThere is no well-defined pattern or framework for building a managed SaaS. Building a well-managed SaaS involves solving a wide variety of problems. Some of these problems are common across different kinds of SaaS, and some are very specific to the SaaS. Examples of common problems are billing, analytics, metrics, and onboarding. Examples of problems that are different for every SaaS are provisioning (what resources should be provisioned when a new tenant onboards), data isolation, scaling, and performance needs. For the sake of this article, we will classify common problems as control plane problems, and different problems as data plane problems.
This article briefly talks about the different models of providing tenant isolation and then delves into the security considerations of building a SaaS.
Shared Model: Multi-Tenant
A SaaS is multi-tenant when all underlying resources of compute, network, and storage are shared across all tenants irrespective of the control plane or data plane. There is no resource creation happening to onboard a new tenant. For example: A single database that contains data for all tenants. A shared model provides the most cost-optimized way of creating a SaaS but comes with several problems that may or may not be important depending on the use case that SaaS is solving. Problems like — noisy neighbor problems where the load/usage from one tenant can impact the entire infra thus impacting all tenants, no data isolation, no good way to support custom needs, and no way to address scale or performance concerns per tenant.
Isolated Model: Single-Tenant
In a single-tenant model, the data plane resources are separate per tenant. Whenever a new tenant onboards, new data plane resources need to be provisioned dedicated to that tenant. This solves a lot of the problems that plague the multi-tenant model — no noisy neighbors, complete data isolation, and resources can be sized according to each tenant's needs. This model is however costly to implement. It is susceptible to underutilizing allocated resources per tenant. There is also significant setup required to ensure the compute, network/routing, and storage are all set up correctly when a new tenant onboards. There are also problems with managing changes across the entire data plane. In a purely multi-tenant model, upgrades happen to one service in one cluster, but in a Single Tenant model, upgrades need to happen to one service in 100s or 1000s of installations.
Hybrid Model: Some Multi and Some Single
In a hybrid model, some resources are shared across all tenants, and some are completely separate. The decision around what to share and what to keep separate is SaaS specific but to give an example, consider an analytics product that ingests data and makes it available for tenants to build dashboards, run analytics, or data science-related payloads. In this example, one possibility is to share ingestion and normalization-related resources and keep the data storage completely separate. Keeping the data storage layer completely separate helps with data isolation, customer-specific storage needs, and encryption needs. This model can also support both the multi-tenant model and the single-tenant model. A single-tenant model can be treated the same way as a multi-tenant model but with only one tenant.
Security Considerations
|
Security Consideration |
Shared Model (Multi-Tenant) |
Isolated Model (Single-Tenant) |
Hybrid Model (Multi+Single) |
|
Data Partitioning |
Pros: - Cost Effective - Simplified management with single data instance Cons: - Risk of data leakage - Complex logical partitioning and access control required |
Pros: - Physical data isolation - Simplifies compliance Cons: - High cost. - Resource underutilization potential |
Pros: - Balance between cost and isolation - Flexible partitioning strategies Cons: - Complexity in deciding what to share - Mixed compliance challenges |
|
Access Control |
Pros: - Centralized control Cons: - Complex policy management - Higher risk of unauthorized access |
Pros: - Easier to enforce strict access controls - Enhanced security Cons: - Management overhead for each tenant |
Pros: - Can leverage best practices of both models Cons: - Potential inconsistencies in access control policies |
|
Encryption |
Pros: - Simplified encryption management Cons: - All data is in the same environment, increasing risk in case of breach |
Pros: - Tenant-specific encryption keys - Enhanced data protection Cons: - Higher management complexity |
Pros: - Selective encryption per tenant needs Cons: - Complexity in managing multiple encryption policies |
|
Compliance |
Pros: - Easier to implement shared compliance policies Cons: - More difficult to meet stringent regulations requiring isolation |
Pros: - Easier to meet strict compliance requirements Cons: - High cost of maintaining compliance per tenant |
Pros: - Flexible compliance strategies Cons: - Complex regulatory landscape management |
|
Resource Isolation |
Pros: - Cost-effective resource sharing Cons: - Noisy neighbor problem - Unpredictable performance |
Pros: - No noisy neighbor issue - Predictable performance Cons: - Inefficient resource utilization |
Pros: - Better resource utilization - Mitigates noisy neighbor issues Cons: - Complexity in resource allocation and management |
|
Monitoring & Logging |
Pros: - Centralized logging Cons: - More difficult to attribute actions to specific tenants - Higher risk of misconfiguration |
Pros: - Easier to monitor and log tenant-specific actions Cons: - Higher logging and monitoring overhead per tenant |
Pros: - Can implement tenant-specific monitoring Cons: - Complex setup and maintenance |
Opinions expressed by DZone contributors are their own.
Comments