Build a Security / Governance Control Matrix Mapping Threats and Compliance Requirements to Firestore / Google Cloud Controls

1. AtlasMart problem: a list of security products is not a governance architecture

AtlasMart’s audit package says “TLS, CMEK, VPC, IAM, Rules, backups, logs.” It looks impressive but does not say which threat each control addresses, who owns it, what evidence proves it works, how failure is detected, or what recovery action exists. This lesson turns the previous four lessons into a control matrix that can be reviewed and tested.

2. Control matrix anatomy

Each row needs at least: requirement/threat, protected asset, preventive control, detective evidence, recovery/response, owner, scope/mode, test cadence, and known residual risk. Avoid binary “compliant/not compliant” labels in engineering configuration; record measurable control facts.

3. Mode/edition columns prevent false equivalence

A governance row must say whether it applies to Standard Native, Enterprise Native Core/Pipeline, MongoDB compatibility, mobile/web client path, or trusted server path. For example, Firestore Security Rules govern supported Firebase client interfaces but Admin/server paths rely on IAM/application authorization. MongoDB compatibility uses a different protocol/connection model and dedicated Private Google Access guidance. Regional endpoints are available to server client libraries, not mobile/web.

controls:  - id: ENC-01    threat: data-at-rest-key-ownership    modes: [standard-native, enterprise-native, mongodb-compat]    control: CMEK-if-approved    owner: security-platform    evidence: database-encryption-metadata + kms-audit    failure_test: local-key-unavailable-simulation    residual: authorized-read-still-plaintext-to-caller  - id: NET-02    threat: managed-service-data-exfiltration    modes: [trusted-backend]    control: VPC-Service-Controls + restricted-api-path    owner: cloud-platform    evidence: perimeter-policy + violation-log    residual: compromised-allowed-workload  - id: PRIV-04    threat: subject-data-persists-after-delete    modes: [all]    control: deletion-scope-inventory    owner: privacy-platform    evidence: deletion-state + downstream-job-results    residual: policy-approved-retained-backups

4. Evidence beats screenshots

Prefer machine-readable evidence that can be diffed and tested: database metadata, KMS key/active-version metadata, IAM policy snapshots, Rules test reports, index definitions, backup schedules, Cloud Storage lifecycle policy, service-perimeter configuration, log-sink/redaction tests, and deletion workflow state. A screenshot can supplement a review but is weak as the only control evidence because it is hard to reproduce and may omit context.

5. Safe failure injection library

6. Mandatory CI lab: fail when governance drifts

import fs from "node:fs";const matrix = JSON.parse(fs.readFileSync("governance/control-matrix.json","utf8"));const required = ["owner","evidence","test","modes","residualRisk"];const errors = [];for (const c of matrix.controls) {  for (const k of required) if (!c[k] || (Array.isArray(c[k]) && !c[k].length)) errors.push(`${c.id}:missing:${k}`);  if (c.claim === "network-replaces-iam") errors.push(`${c.id}:unsafe-claim`);  if (c.claim === "cmek-is-client-encryption") errors.push(`${c.id}:unsafe-claim`);}if (errors.length) { console.error(errors.join("\n")); process.exit(1); }console.log(`GOVERNANCE_MATRIX_OK controls=${matrix.controls.length}`);

Now inject a regression: remove owner from the deletion control, or set claim to network-replaces-iam. CI must fail. Repair the matrix and verify green state. The mechanism is the important part: governance changes become reviewable code rather than institutional memory.

7. AtlasMart control review checklist

• Every protected dataset has an owner, location, classification, retention class, and deletion path.
• Client and server authorization paths are separately modeled.
• CMEK, if used, has service-agent IAM, rotation evidence, availability alerts, and a break-glass runbook.
• Network controls have explicit ingress/egress paths and do not weaken IAM/application authorization.
• Backup/restore/export/analytics copies appear in the data inventory.
• Logs redact tokens/secrets/PII according to policy before emission.
• Every critical control has a safe test and a known limitation of emulator/local simulation.
• Mode/edition/API/launch-stage dependencies are stated.

Production judgment

A mature Firestore governance architecture is layered: authentication, authorization, key ownership, network egress control, location, logging, recovery, retention, and deletion each address different failure modes. More controls can also create new dependencies and operational failure modes. Add a control when it addresses a documented threat/requirement and you can operate, observe, and recover it.

8. Bridge to Chapter 24

Chapter 23 made controls explicit. Chapter 24 makes their operational health observable with Query Explain, Query Insights, Key Visualizer, metrics, logs, and troubleshooting. Governance without observability becomes stale; observability without governance becomes a pile of signals with no decision owner.

Knowledge check

1. What extra fields should a control matrix have beyond “control enabled”?
2. Why is edition/mode/interface scope required?
3. What is a good local test for CMEK failure?
4. Why are screenshots weak as sole control evidence?
5. What should happen when a control introduces a new availability dependency?

Authoritative references

• Firebase: Server-side encryption — Google-managed encryption, CMEK, client-side encryption distinction, and TLS in transit.
• Google Cloud: Firestore Native CMEK — availability behavior, rotation, backup/restore interaction, and limitations.
• Google Cloud: Firestore Native VPC Service Controls — Firestore service perimeter behavior.
• Google Cloud: Firestore locations — regional/multi-region topology and immutable database location.
• Google Cloud: Firestore regional endpoints — server-library data-locality endpoint behavior.
• Google Cloud: Private Google Access for Firestore with MongoDB compatibility — firestore.goog and restricted.firestore.goog private routing.