Segmentation and segregation are crucial concepts in cloud security that ensure different tenants and their resources are logically separated and access is tightly controlled. By designing, deploying and configuring applications and infrastructure with proper segmentation and segregation, cloud service providers and their customers can reduce the risk of unauthorized access and data leakage between tenants. Effective implementation involves following established best practices, monitoring for any violations, and maintaining clear separation of duties between the provider and customer.

Where did this come from?

This control comes from the CSA Cloud Controls Matrix v4.0.10 released on 2023-09-26. You can download the full matrix here. The CCM provides a comprehensive set of security controls specifically designed for cloud computing environments. It is aligned with many industry-accepted security standards, regulations, and control frameworks such as ISO 27001/27002, ISACA COBIT, PCI DSS, NIST SP 800-53, HIPAA, and HITRUST.

For more background on segmentation and segregation in AWS specifically, check out the AWS documentation on network segmentation and tenant isolation in Amazon EC2.

Who should care?

A few roles that should pay particular attention to this control:

• Cloud architects designing multi-tenant applications and shared infrastructure
• DevOps engineers responsible for deploying and configuring cloud workloads
• Security analysts monitoring cloud environments for any cross-tenant access
• Compliance officers ensuring all regulatory obligations around data separation are met

What is the risk?

Poor segmentation and segregation controls can enable some serious threats:

• Malicious tenants exploiting misconfiguration to access other tenants' resources and data
• Vulnerabilities in shared infrastructure components exposing all tenants if exploited
• Accidental human errors granting unintended cross-tenant permissions
• Inability to meet compliance requirements around isolating regulated data

While relatively rare, a cross-tenant breach can be catastrophic - letting an attacker hop between all customer environments. Segmentation and segregation controls are highly effective at preventing this lateral movement.

What's the care factor?

For any multi-tenant cloud service or shared infrastructure, implementing strong logical separation between different users and workloads should be a critical priority. Even a single incident can erode customer trust and result in significant financial and reputational damage.

The stakes are especially high for:

• SaaS providers serving business customers that expect total data confidentiality
• Highly-regulated industries like healthcare and finance with explicit mandates around tenant isolation
• Large enterprises with many different internal lines-of-business operating on shared cloud infrastructure

When is it relevant?

Segmentation and segregation controls should be applied whenever multiple different untrusted parties are accessing the same underlying physical infrastructure, such as:

• SaaS applications with many different authenticated users
• PaaS offerings like DBaaS and serverless platforms
• IaaS environments with shared VPCs, subnets, security groups, etc
• Containerized microservices deployments on shared Kubernetes clusters

However, they may be less relevant for:

• Single-tenant dedicated environments where the hardware is not shared
• Client-side applications that run fully on end user devices
• Proof-of-concept deployments focused just on functional testing

What are the trade offs?

Implementing tenant segmentation and segregation is not without costs:

• Increased complexity in both the application architecture and infrastructure configuration
• Additional resources required to deploy separate isolated environments for each tenant
• Potential performance impacts from traffic filtering and policy enforcement between segments
• Reduced flexibility to integrate data and services across tenant boundaries

There is a balance to be struck between security and usability. Overly restrictive controls can impede business agility. Start with logical separation at the application layer where possible before resorting to network-level segmentation.

How to make it happen?

Here are some key steps to implement tenant segmentation and segregation in practice:

1. Clearly define trust boundaries and isolation requirements between different types of tenants, users and datasets. Document these in a formal data classification policy.
2. Architect applications to be multi-tenant aware:
   • Implement tenant-aware authentication and authorization checks in all APIs
   • Partition data stores to keep each tenant's records logically separated
   • Never share secrets like API keys and database credentials between tenants
3. Use cloud provider constructs to enforce network segmentation:
   • Deploy each tenant in a separate account, VPC, and/or subnet
   • Configure security groups and NACLs to restrict cross-tenant traffic
   • Route outbound tenant traffic through separate NAT Gateways
4. Leverage identity and access management to scope permissions:
   • Define IAM roles and policies aligned to each tenant's entitlements
   • Use resource tags to differentiate tenant resources in IAM conditions
   • Enforce a least-privilege access model for all cross-tenant operations
5. Monitor for any segmentation violations:
   • Alert on any suspicious traffic observed between tenant boundaries
   • Perform regular audits of IAM permissions and resource configurations

What are some gotchas?

A few things to watch out for when implementing tenant isolation:

• Elastic IPs are not VPC-specific, so don't rely on them alone for network segmentation
• Some AWS services like S3 are region-scoped and don't support VPC restrictions directly
• IAM resource tags are case-sensitive - use distinct formats like TenantXYZ
• Service-linked roles can allow cross-tenant access if overly permissive - audit them carefully

Key permissions to tightly scope:

• ec2:DescribeInstances
• ec2:DescribeNetworkInterfaces
• vpc:DescribeRouteTables
• rds:DescribeDBInstances

What are the alternatives?

Some other strategies to supplement or replace full logical tenant separation:

• Use resource-level permissions to restrict tenant access to specific AWS resources
• Implement attribute-based access control (ABAC) policies based on resource tags
• Deploy dedicated EC2 Nitro instances with hardware-level memory and CPU isolation
• Consider third-party tools that provide an abstraction layer for tenant management

Explore further

• CIS AWS Foundations Benchmark includes many specific recommendations for tenant isolation
• AWS re:Inforce 2019: Securing Multi-Tenant SaaS Applications
• Salesforce Architect Multi-Tenant Isolation
• Control ID: IAM-09 - CSA Cloud Control Matrix related to AWS EC2 instance roles

‍