B2B SaaS ERP platform, 2,000+ enterprise clients

A B2B SaaS platform providing ERP tools to 2,000 enterprise clients discovered during an internal architecture review that its multi-tenant AWS environment had potential data isolation vulnerabilities. Built on shared infrastructure, the platform processed sensitive business data, including financial records, employee information, supply chain details, and proprietary operational data, for clients across manufacturing, healthcare, finance, and professional services.

During the review, a senior engineer noticed that resource identifiers used in API calls were sequential and predictable, raising the possibility that one tenant could access another tenant's data by manipulating API parameters. The engineering team had also prioritized rapid feature development over security hardening, resulting in sprawling IAM configurations, inconsistent encryption practices, and undocumented infrastructure components. The CISO brought me in to conduct a comprehensive cloud security assessment before the next SOC 2 audit cycle.

I brought in a three-person cloud security team to assess five core domains: identity and access management, data storage and encryption, API security and tenant isolation, network architecture, and logging and monitoring, combining automated scanning with manual code review and architectural analysis to catch what automated tools alone would miss.

IAM Policy Review

I reviewed every IAM role, policy, and user across 47 AWS accounts managed through AWS Organizations, and found 14 roles with overly permissive wildcard permissions, 6 service accounts with unnecessary administrative privileges, and multiple instances of policies attached directly to users instead of groups: a practice that makes permission auditing extremely difficult. Lambda functions executing tenant-facing operations were assuming roles with permissions far exceeding their operational requirements, creating unnecessary blast radius if any function were compromised.

Data Storage and Encryption Analysis

Auditing S3 buckets, RDS instances, and DynamoDB tables revealed significant gaps in encryption practices: 12 S3 buckets containing customer data that weren't encrypted at rest, 3 RDS instances using default encryption keys instead of customer-managed KMS keys, and multiple database snapshots stored without encryption. Several S3 buckets had overly permissive bucket policies that could allow unauthorized access if IAM controls were bypassed.

The most critical finding involved cross-tenant data access through predictable resource identifiers. The API architecture used sequential integer IDs for tenant resources without adequate server-side authorization checks, so a malicious or compromised tenant could enumerate resource IDs belonging to other tenants and access their data simply by incrementing or decrementing ID parameters in API requests. This affected four core API endpoints and potentially exposed data across all 2,000 clients.

API Security and Tenant Isolation

Beyond the predictable identifier issue, I found several additional API security gaps: no rate limiting on authentication endpoints, enabling brute-force and credential-stuffing attacks; API authentication tokens valid for 24 hours without rotation requirements, meaning a compromised token provided a long window of unauthorized access; and inconsistent input validation across endpoints, creating potential for injection attacks and request smuggling.

Tenant isolation at the database layer relied on a tenant_id column filter applied at the application level. I identified three endpoints where that filter was either missing or could be bypassed through crafted SQL queries, allowing direct cross-tenant database queries: an architectural weakness meaning any application-layer vulnerability could immediately become a multi-tenant breach.

Network Architecture Review

I assessed VPC configurations, security group rules, and network access control lists across the production environment, and found that development, staging, and production VPCs were peered without adequate access controls, allowing traffic to flow between environments with minimal restriction. Several security groups allowed inbound traffic from 0.0.0.0/0 on non-standard ports that were never intended for public access.

The assessment identified 23 critical findings requiring immediate remediation:

• Cross-tenant data access via predictable IDs (Critical): sequential resource identifiers without server-side authorization allowed enumeration and access to other tenants' data across four API endpoints.
• Missing API rate limiting (High): authentication and data access endpoints had no rate limiting, enabling brute-force attacks and denial-of-service conditions.
• Overly permissive IAM roles (High): Lambda functions and service accounts operated with administrative privileges far exceeding operational requirements.
• Unencrypted customer data (High): 12 S3 buckets and 3 RDS instances contained unencrypted customer data, violating both security best practices and contractual obligations.
• Incomplete tenant isolation (Critical): three API endpoints had missing or bypassable tenant_id filters, enabling direct cross-tenant database queries.
• Cross-environment VPC peering (Medium): development, staging, and production networks were peered without adequate segmentation.
• Extended token lifetime (Medium): API authentication tokens remained valid for 24 hours without rotation, expanding the impact window of any credential compromise.

I worked alongside the SaaS company's engineering team over an eight-week remediation period to address all 23 critical findings: replacing sequential resource identifiers with UUIDs, implementing server-side authorization checks on every API endpoint, enforcing AES-256 encryption across all data stores, redesigning IAM policies around least-privilege, and deploying API rate limiting with automated blocking.

The most significant architectural change was a tenant isolation layer enforcing data access boundaries at the infrastructure level rather than relying solely on application-layer filters, so that even if an application vulnerability bypassed the tenant_id check, the underlying infrastructure would prevent cross-tenant data access.

Following remediation, the company passed its SOC 2 Type II audit with zero exceptions. In the 12 months since, they've had zero cross-tenant incidents and expanded their client base to 2,400 enterprise customers. The CISO credits the engagement with transforming their approach to cloud security from reactive to proactive.

Kishin didn't just find vulnerabilities: the engagement helped us fundamentally rethink how we approach tenant isolation in a multi-tenant world. The expertise in cloud architecture security was exactly what we needed.