Skip to main content
Defense in depth. Every layer has independent controls so no single failure can expose customer data.

​
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

  • 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
  • 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
  • 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
  • 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
  • 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
  • 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

​
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:
ThreatPrimary controls
Spoofing (identity)MFA/passkeys, account lockout, audit logging, rate limiting
Tampering (data)Write-once audit tables, database role isolation, backups with versioning
RepudiationHIPAA audit logs with 7-year retention, immutable Cloud Logging archive
Information disclosureColumn encryption, CMEK, PHI scrubbing before egress, Pundit authorization
Denial of serviceCloud Armor rate limiting, DDoS absorption, Rack::Attack
Elevation of privilegeRole hierarchy, Pundit, least-privilege IAM, segregation of duties

​
What’s not in the architecture yet

See SOC 2 & ISO 27001 readiness 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).