Multi-Tenant Security

How the Enterprise SaaS edition keeps every tenant's data provably separate — and why that separation holds even when something goes wrong.

The strongest isolation boundary is a different database

Shared-schema multi-tenancy — everyone's rows in one table, separated by a tenant_id column — is one forgotten WHERE clause away from a cross-tenant data breach. SysManage refuses that risk by construction: every tenant gets its own physically separate database. There is no shared table to filter, no tenant_id to forget, and no connection from one tenant's silo to another. Isolation is the default state, not something the application has to remember to enforce on every query.

Defense in depth, by design

Tenant isolation in SysManage is not one feature — it is a stack of independent layers, each of which would contain a breach on its own. An attacker has to defeat all of them, simultaneously, to cross a tenant boundary.

1Physical database isolation

Each tenant's operational data lives in its own PostgreSQL database. A SQL injection or a missing tenant filter in one tenant's request can, at worst, reach that tenant's own data — the other tenants' data is in databases the request holds no connection to.

2Per-tenant dynamic credentials

Database credentials are issued on demand by OpenBAO: short-lived, automatically expiring, and scoped to a single tenant. There is no long-lived, shared database password to steal. A leaked credential is useless to reach any other tenant and stops working on its own.

3Least-privilege provisioning

Tenants are created by a dedicated, least-privilege provisioner identity — not by a database superuser. The running server never holds the keys to the whole cluster, so compromising the server does not hand an attacker every tenant's database.

4Fail-loud routing

The routing seam that maps a request to a tenant database never guesses. If it cannot resolve a tenant, it logs with full context and refuses the operation rather than silently falling back to a default database. A misroute is treated as a correctness bug, not a soft failure.

5No cross-partition foreign keys

Because partitions can live in separate databases, no foreign key crosses a tenant boundary. Cross-partition references are stored as soft references (a GUID, no enforced constraint), so each database is self-contained — there is no schema-level path from one tenant's data into another's.

6The identity boundary

Authentication, users, and roles are server-global; managed data is per-tenant. A person authenticates once, but every action on managed data is served from their active tenant's database. Authorization is evaluated on the control plane, independently of which tenant database is in play.

Why it is hard to attack

The clearest way to judge an isolation model is to walk the attacks against it.

“I'll inject SQL or drop a tenant filter to read another customer's hosts.”

Your request is bound to your tenant's database connection. The other tenants' data is in other databases. There is no query — malicious or accidental — that can reach across, because the connection simply isn't there. Contained to your own data.

“I'll steal the database password from config or memory.”

There is no shared, long-lived password to steal. Credentials are leased per tenant from OpenBAO, expire automatically, and are scoped to a single tenant's database. A captured credential is narrow and short-lived by construction. Blast radius is one tenant, briefly.

“I'll compromise the SysManage server process itself.”

The server does not hold superuser rights to the database cluster, and it does not cache every tenant's credentials. It leases narrowly scoped credentials as needed. Server compromise is serious, but it does not hand over the whole estate at once. No master key to seize.

“I'll point my agent at a tenant I don't belong to.”

A host is bound to exactly one tenant at registration via a tenant-scoped enrollment token that is validated and consumed server-side. The agent never chooses a database; the server routes its reports to the bound tenant's silo. Binding is server-enforced.

Shared-schema vs SysManage

Concern	Typical shared-schema SaaS	SysManage Enterprise SaaS
Isolation mechanism	A `tenant_id` column; correctness depends on every query.	A separate database per tenant; isolation is the default.
Impact of a query bug	Potential cross-tenant data exposure.	Limited to the tenant whose request it is.
Database credentials	Often one shared, long-lived password.	Short-lived, per-tenant, OpenBAO-brokered.
“Noisy neighbor” / data residency	All tenants share one database and location.	Each tenant database can be placed independently — by host, region, or jurisdiction.
Per-tenant backup / export / delete	Surgery on shared tables.	Operate on a single, self-contained database.

Compliance and data residency

Per-tenant databases are not just a security property — they are an operational and regulatory one. Because a tenant's data is a single self-contained database, you can place it where it must live (a specific region or jurisdiction for data-residency rules), back it up and restore it independently, export it on request, and delete it completely when a customer leaves — all without touching, or risking, any other tenant. Right-to-be-forgotten and data-residency obligations become a per-database operation instead of a careful surgery on shared tables.

Part of a larger security posture

Multi-tenant isolation sits on top of the security SysManage already brings to every deployment. The same protections apply per tenant:

Mutual TLS for agent communication, with certificate-based identity. See mTLS.
Role-based access control evaluated on the control plane for every operation. See RBAC.
OpenBAO secrets management — the same vault that brokers tenant credentials manages certificates and SSH keys. See Secrets Management.
JWT authentication with token rotation. See Authentication.
Database security hardening that applies to every tenant database. See Database Security.