Multi-Tenant Reporting Security: Workspace Isolation, RBAC, and No Data Leaks

Why multi tenant reporting leaks in real life

Most breaches in shared reporting systems come from routine mistakes, not clever attackers.

1. Someone runs the right report in the wrong tenant.
2. A template queries the right tables but misses a tenant filter in one subquery.
3. Support staff access a customer workspace to troubleshoot and see data they did not need.

If your default state is shared access and you rely on filters everywhere, one missed filter becomes a leak.

The goal is simple. Make isolation the default, then grant access only when you must.

The core threat: accidental cross tenant access

Shared architectures often put many tenants behind one platform, one template library, and sometimes one database. You then try to prevent leaks with rules like tenant_id filters or row level security.

This fails for predictable reasons.

1. Templates evolve. A new join or nested query slips through without a tenant condition.
2. Different teams use different query patterns, and enforcement becomes inconsistent.
3. Views and ORM layers do not cover every edge case.
4. Someone copies a template from Tenant A and runs it for Tenant B.

Even when row filtering works, templates can still leak. The template structure can reveal confidential fields, business logic, or even that a data set exists.

If you build one system and then add tenant restrictions, every component must be perfect forever. That is not realistic.

Workspace isolation: start with separation

A workspace is a full reporting environment for one tenant or one business unit.

Each workspace holds its own:

1. Templates
2. Data sources and database connections
3. Themes and branding
4. Users and roles
5. Parameters and configuration

Users inside Workspace A do not see Workspace B. They do not see its templates, its data sources, or its users. The safest state is that other tenants do not exist.

What you gain from this design:

1. A bad template stays contained. It can only affect its own workspace.
2. A compromised account has a smaller blast radius.
3. Operational mistakes stay local. A support session in one workspace cannot accidentally change another workspace.

For external customers, the usual model is one workspace per client.

For internal reporting across departments, use one workspace per business unit when data separation matters.

Admin: cross workspace operations with guardrails

Someone still needs to manage the platform. That user needs visibility across workspaces to:

1. Create new workspaces
2. Configure system level settings
3. Support troubleshooting when tenants hit issues

Per workspace roles: RBAC that matches real jobs

Isolation between tenants is not enough. Inside one workspace, you still need least privilege.

Role based access control lets you give users only what they need.

Typical permission areas:

1. Reports, view and run
2. Templates, create and edit
3. Themes, manage branding
4. Data sources, view and configure connections
5. Parameters, define and maintain inputs
6. Workspace settings, users, roles, and policies

A simple and effective permission scale:

1. No access, hide the section
2. Read, view only
3. Full, create, edit, delete

Example roles that work in practice:

Report operator

1. Full access to Reports
2. Read access to Parameters
3. No access to Templates, Themes, Data sources, Workspace settings

Designer

1. Full access to Templates and Themes
2. Read access to Data sources so they can see available data
3. No access to users, roles, or connection edits

Workspace admin

1. Full access inside the workspace
2. No visibility into other workspaces

Assign roles per workspace. The same person can be an admin in one workspace and a viewer in another.

Resource level access: restrict specific reports and data sources

Sometimes one workspace serves a whole department, but not every report is for everyone.

Use resource level controls to restrict:

1. Specific reports, for example HR or payroll
2. Specific data sources, for example a database with personal data

This adds another layer of least privilege.

It also helps you avoid creating too many workspaces. Keep the workspace as the tenant boundary, then use resource controls for sensitive items inside the tenant.

Data isolation: database per client beats tenant filters

Workspace isolation means little if every workspace queries the same database with shared tables.

The safest approach is database per client, or at least separate schemas with separate credentials.

You then configure each workspace with connections that only reach that tenant data.

Why this is safer than tenant_id filtering:

1. A missing WHERE clause cannot leak other tenants because the data is not reachable.
2. Credentials enforce boundaries at the infrastructure level, not in template logic.
3. A template designer cannot query another tenant database because the connection does not exist in the workspace.

This removes an entire class of errors, including row filter gaps in nested queries.

Limit query scope with preconfigured data sources

Not every template author should write arbitrary SQL.

Preconfigured data sources let you publish named datasets like:

1. monthly_revenue
2. customer_summary
3. inventory_levels

Designers select the dataset by name instead of writing queries.

This helps in three ways.

1. You reduce exposure. Templates cannot pull tables you did not publish.
2. You centralize maintenance. One change updates all templates that use the dataset.
3. You standardize business logic, so teams do not implement the same calculation five different ways.

For highly sensitive tables, publish only aggregated views or curated datasets.

Authentication: use SSO so accounts stay controlled

Separate reporting passwords create weak habits, reuse, and shared accounts.

Single sign on via OpenID Connect keeps identity control in your main provider, such as Google Workspace, Microsoft Entra ID, Okta, or Keycloak.

What you gain:

1. Central password policies and MFA
2. Fast offboarding, disable the user once and access ends everywhere
3. Cleaner audit trails tied to real identities

Per workspace secrets: keep credentials contained

A multi tenant platform accumulates credentials fast:

1. Database passwords
2. API keys
3. SMTP credentials
4. Storage access keys

Store secrets per workspace and encrypt them.

Important practice: mask secrets in the UI. Let admins replace a password, but do not show the existing value. This prevents accidental exposure during screen sharing and reduces copying secrets into tickets.

A practical checklist

Workspace setup

1. Create one workspace per tenant or per unit that requires isolation
2. Confirm users cannot see other workspaces
3. Use clear workspace naming and ownership

Admin control

1. Limit admin to platform operators
2. Log access and changes
3. Review admin access quarterly

Roles and users

1. Define roles that map to real jobs
2. Apply least privilege
3. Review user lists and role assignments regularly

Data sources

1. Prefer database per client or separate schema with separate credentials
2. Do not rely on tenant_id filters as your primary boundary
3. Use curated data sources for most template authors

Resource controls

1. Restrict sensitive reports
2. Restrict sensitive data sources
3. Recheck restrictions when teams change

Authentication

1. Use SSO
2. Block shared accounts
3. Enforce MFA at the identity provider

Secrets and hygiene

1. Scope secrets per workspace
2. Rotate credentials on a schedule
3. Keep deletion and access logs where compliance needs them

How to roll this out without pain

Start with one tenant.

1. Create a workspace, add a workspace admin, and set up roles.
2. Configure tenant specific database connections.
3. Publish curated data sources for designers.
4. Add a few test users with different roles and try to break the boundaries.
5. Repeat the pattern for the next tenants.

If you already run a shared database model, keep it running while you migrate tenant by tenant to separate databases or schemas with dedicated credentials. You do not need a big bang cutover.

The key principle stays the same. Isolation first, permissions second, and a clean audit trail for the small set of people who can cross boundaries.