apointoo.
Request access
HIPAA

Firestore Rules vs Admin SDK for Multi-Tenant Services

cmsapointoo··7 min read

Short answer: Firestore Security Rules govern supported client access paths, while a server-side Admin SDK path uses privileged credentials and still needs application membership and tenant authorization. As of 2026-08-15, Google Cloud documents Firestore locations and covered-product scope, and HHS describes cloud shared responsibility. Rules, a BAA, or a database location do not make an Admin SDK service safe by themselves.

Isolation model and threat boundary

Rules are not a universal boundary around Firestore data. Client SDK calls may be evaluated against Firestore Security Rules. A trusted server using Admin SDK operates through a privileged path and must enforce membership, tenant scope, role, region, and minimum necessary data in application code and server configuration.

Google Cloud’s Firestore Locations page informs location and regional design, while its HIPAA page describes covered products and shared responsibility. HHS Cloud Computing and HIPAA guidance explains that cloud configuration and customer use remain important. These sources support a bounded architecture review, not a statement that a Rules file or a BAA makes the service compliant.

Define the threat boundary: browser client, public API, server worker, Admin SDK, report job, export, support tool, backup, restore, and administrative console. For each path, identify identity, tenant resolution, query scope, write scope, log, key, region, and retention. A client-only proof covers one path.

Path Authority Required proof
Client SDK Authenticated user plus Rules Allowed and denied Rules tests
Public API Server membership and data policy Wrong-tenant request denial
Admin SDK Service identity and application checks Privileged-path matrix
Recovery Backup and restore operator Location, key, and tenant test

Compare Firestore database proof, PostgreSQL RLS, and authenticated jobs.

Enforcement path and bypasses

Server authorization begins before the Admin SDK call. Authenticate the caller or job, resolve membership and immutable home region from trusted records, validate operation and document scope, then perform the read or write. Do not use a browser-supplied tenant path as proof. A document path can be syntactically correct and still belong to another tenant.

Use one authorization helper for application paths, but review every caller: API route, scheduled job, queue consumer, report, export, support tool, migration, webhook, and background worker. An Admin SDK credential can be broader than a client role, so its access should be narrowed by service identity, project, collection, query, and explicit membership checks.

Keep data minimum necessary. An approved generic conversion record may use event type, time, currency, value, and an opaque reference. Do not send patient names, email addresses, phone numbers, hashed identifiers, service names, treatment details, or clinical text to advertising systems. Rules do not authorize any external disclosure.

request or job
  -> identity and membership lookup
  -> immutable tenant and home region
  -> scoped Admin SDK operation
  -> redacted audit event
  -> approved queue, backup, or export path

Audit, restore, support, and offboarding

Privileged paths need stronger evidence than client demos. Create two synthetic tenants and test client read, server read, Admin SDK read, write, update, delete, batch, report, export, backup, restore, support, and migration operations. Attempt wrong tenant, missing membership, expired identity, changed region, and broad collection access.

Audit service identity, tenant, operation, decision, timestamp, reason code, export, restore, support approval, and rule changes. Avoid full documents in logs. Review who can change Rules, service accounts, project IAM, keys, backup settings, and collection indexes. A Rules update can improve a client path while leaving an Admin SDK bypass unchanged.

Restore is a separate authorization environment. Recreate roles, membership, keys, region controls, and application policies before reading the restored data. Test a backup operator who cannot perform ordinary application reads, and an application role that cannot restore. Delete synthetic copies after the test and document required retained evidence.

Offboarding should find live documents, queues, exports, backups, logs, and test projects. Rules do not delete records, and Admin SDK permissions do not decide retention. Apply customer contract, risk, legal hold, and deletion policy through an approved workflow.

Runnable proof tests

The proof must make the Admin SDK path fail when membership is absent.

  1. Create synthetic data for tenant A and tenant B.
  2. Read each tenant’s data through the client path and test Rules denial.
  3. Read through the public server path and test membership denial.
  4. Call the Admin SDK worker as tenant A and attempt tenant B.
  5. Run report, export, batch, queue, backup, restore, support, and migration tests.
  6. Change Rules and IAM separately and confirm both paths remain covered.
  7. Inspect logs, keys, locations, and offboarding evidence.

Record which layer enforced every result. If the Admin SDK path remains application-enforced, say so. The accurate claim is that the path has named checks and passing negative tests, not that client Rules protect all server operations.

Build an authorization catalog beside the collection model. List client collection reads, public API routes, scheduled jobs, queue consumers, report queries, exports, support actions, migrations, backup, restore, and admin operations. For each path, identify identity, tenant source, region, document scope, fields returned, audit event, and denial test. A Rules file is only one row in this catalog.

Use two synthetic tenants and vary the caller. Test client Rules, server membership, Admin SDK service identity, missing membership, changed tenant path, changed region, broad collection query, batch operation, and report. Then remove a rule or narrow an IAM permission and verify that the other layer still behaves as expected. This catches false confidence from overlapping controls.

Protect recovery and support separately. Restore data into an isolated target, install membership and role controls before reading, and audit the operator. A support export should have a tenant scope, reason, expiration, approval, and deletion step. Offboarding should enumerate documents, queues, exports, backups, logs, and test copies. Rules do not perform those lifecycle actions.

Keep data minimization independent of Firestore authorization. An approved generic conversion event may use event type, time, currency, value, and opaque reference. Do not add patient name, email, phone, hashed identifier, service name, treatment detail, or clinical text to a server job or advertising payload. The Firestore location guide adds the geographic boundary that Rules do not provide.

Review cost and operations after the proof. Count reads, writes, indexes, storage, backups, logs, keys, exports, Admin SDK calls, support, and regional resources. Recheck current provider pages before a migration or quote. The final statement should say which path is protected by Rules, which is protected by application checks, and which remains privileged.

Frequently asked questions

Do Firestore Rules protect Admin SDK?

Do not assume that. Server-side Admin SDK calls are privileged application paths. They still need server-side membership, tenant, role, region, query, export, and support controls.

Is an Admin SDK service account always too broad?

Not necessarily, but its permissions and application checks must be deliberately scoped and tested. Separate ordinary service, report, export, support, migration, and restore identities.

Does a Firestore location solve authorization?

No. Location addresses geography. It does not prove membership, document scope, server roles, logging, backup, restore, or external disclosure.

What should be approved before production?

Engineering should prove client and server negative tests, privileged roles, export, restore, support, logging, and location. The customer and counsel should approve data, contract, transfer, and retention questions.

References

Related articles