> ## Documentation Index
> Fetch the complete documentation index at: https://trust.denialbase.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Security architecture

> How Denialbase is architected for defense in depth — from edge to database.

<Info>
  Defense in depth. Every layer has independent controls so no single failure can expose customer data.
</Info>

## High-level data flow

```
User browser / EHR system
      │
      ▼  TLS 1.2+ (Cloud Armor + OWASP CRS v3.3)
Google Cloud Load Balancer
      │
      ▼  Private VPC ingress
Cloud Run (Rails API)
      │
      ├─► Cloud SQL (Postgres, private IP, CMEK)       — column-level PHI encryption
      ├─► Memorystore Redis (private IP, TLS, CMEK)    — sessions, rate limits, 2FA
      ├─► Cloud Storage (CMEK, versioned)              — documents (EOBs, appeals)
      ├─► Secret Manager                               — runtime secrets
      ├─► Anthropic API                                — PHI-scrubbed prompts
      └─► SES / DocuSeal                               — email, signatures
```

## Layers of defense

<AccordionGroup>
  <Accordion title="Edge" icon="shield">
    * Google Cloud Load Balancer (global)
    * TLS 1.2+ only; HSTS preload
    * Cloud Armor WAF with full OWASP CRS v3.3
    * Per-IP rate limiting (500–1000 req/min with 5-min ban)
    * DDoS absorption at Google edge
  </Accordion>

  <Accordion title="Application" icon="server">
    * Cloud Run serverless runtime with VPC connector
    * Global Pundit authorization (`after_action :verify_authorized`) — 48 policy files
    * Rack::Attack application-level rate limiting backed by Redis
    * Account lockout, MFA enforcement on PHI accounts
    * HIPAA audit log write on every PHI read/write
  </Accordion>

  <Accordion title="Data" icon="database">
    * Cloud SQL with CMEK at rest (AES-256, 90-day key rotation)
    * Column-level encryption on PHI fields via Active Record Encryption
    * Private IP only — no public ingress
    * Automated daily backups + continuous WAL for PITR
  </Accordion>

  <Accordion title="Secrets" icon="key">
    * GCP Secret Manager for all runtime secrets
    * No secrets in source code, `.env`, or CI/CD variables
    * gitleaks on every commit
    * Workload Identity Federation means zero long-lived service account keys
  </Accordion>

  <Accordion title="Supply chain" icon="box-archive">
    * Dependabot auto-PRs for patches; auto-merge on passing CI
    * bundler-audit + npm audit + license\_finder in every CI run
    * Brakeman SAST on every commit
    * Trivy on every Terraform change
    * Artifact Registry for signed container images
  </Accordion>

  <Accordion title="Observability" icon="chart-line">
    * Sentry for error monitoring (PHI-scrubbed)
    * Cloud Monitoring + alerting on security-relevant events
    * Cloud Logging with structured logs and 7-year retention
    * Status page at `status.denialbase.com`
  </Accordion>
</AccordionGroup>

## Tenancy model

Denialbase is a multi-tenant platform with **logical isolation** per organization:

* Every PHI-bearing row carries an `organization_id`.
* Pundit policies scope queries to the caller's organization by default.
* 48 policy files enforce object-level authorization — no cross-tenant read without explicit policy approval.
* Super-admin actions (cross-tenant access by Denialbase staff for support) are audit-logged with elevated visibility.

## Threat model

We use STRIDE as a baseline threat model for every new feature:

| Threat                     | Primary controls                                                           |
| -------------------------- | -------------------------------------------------------------------------- |
| **S**poofing (identity)    | MFA/passkeys, account lockout, audit logging, rate limiting                |
| **T**ampering (data)       | Write-once audit tables, database role isolation, backups with versioning  |
| **R**epudiation            | HIPAA audit logs with 7-year retention, immutable Cloud Logging archive    |
| **I**nformation disclosure | Column encryption, CMEK, PHI scrubbing before egress, Pundit authorization |
| **D**enial of service      | Cloud Armor rate limiting, DDoS absorption, Rack::Attack                   |
| **E**levation of privilege | Role hierarchy, Pundit, least-privilege IAM, segregation of duties         |

## What's not in the architecture yet

<Warning>
  See [SOC 2 & ISO 27001 readiness](/trust/soc2-iso27001) for the authoritative list, but notably: no third-party pentest has been run yet (target Q3 2026); column-level PHI encryption is partially migrated (target Q2 2026); JWT rotation dual-secret validation is in progress (target Q2 2026).
</Warning>