A SaaS company's tenant isolation and secrets rotation program: row-level security, per-tenant keys and automated rotation

A software-as-a-service company wanted to prove that one customer can never read another customer's data, and to stop treating passwords and keys as things that never change. The client is not named on this page, and this is an illustrative engagement that describes the kind of work our team does; details are composite. Work started with a written scope covering the application, the database and the build pipeline.

The design review began with a simple question: where does a tenant identifier get checked? In the existing code the answer was "in each query, if the developer remembers." That is how cross-tenant leaks happen, and the OWASP API Security Top 10 lists the pattern as broken object level authorization. The team moved the check into the database with row-level security in PostgreSQL. Each connection sets the current tenant, a policy on every tenant table compares it to the row, and the application's own database role is not allowed to bypass the policy. A query that forgets its filter now returns no rows.

Isolation of data at rest was the second layer. Each tenant got its own data key, wrapped by a master key in AWS KMS, with key policies that name only the services that must use them. Disabling one tenant's key makes that tenant's encrypted data unreadable, which gives the company a clean answer for offboarding and for a suspected exposure. Encryption does not replace the access checks, and the page does not claim it does: the two controls cover different failures.

Secrets were the third layer. Database credentials and third-party API keys moved into AWS Secrets Manager or Google Secret Manager, depending on where each workload ran, and the application fetches them at runtime instead of reading files or environment variables baked into images. Rotation runs on a schedule and can be triggered at once if a key is exposed. A secrets scanner in the build pipeline checks every commit and pull request, and a one-time scan of repository history found old credentials that were revoked the same day. Revocation, not history rewriting, is what protects the account.

The program ended with proof. Automated tests log in as two test tenants and try to read, update and delete each other's objects through every endpoint and background job, and they run on every build. The retest and the design document went into an evidence pack for prospects' security teams. This is the kind of work our team offers under cybersecurity and cloud management; it is a technical program, not a certification, and it does not replace an independent assessment.