Security
Only you can read or manage your data
Isolation by tier is a hard boundary. Compliance is a property of the architecture, not a document written afterwards.
- everywhere, re-encrypted to the pod
- TLS 1.3
- can read your data; staff see metadata
- Only you
- on secure hosting, or bring your own
- Per-org keys
- tamper-evident audit log
- 6-year
Threats and controls
From our security architecture, section 9: customer data confidentiality.
| Threat | Control |
|---|---|
| Another customer reads my data | Namespace per instance, default-deny network policy, per-instance credentials, the gateway routes only to the owning service, a volume per instance and a backup prefix per instance with prefix-scoped credentials. Cross-tenant access is tested in CI with a hostile-neighbour suite. |
| Another org manages my instance via the API | Every request resolves the resource through the caller's org, never by bare id. Roles are enforced by a tested permission matrix: viewers cannot see credentials, developers cannot delete, billing sees no instances. |
| Databasezy staff read my data | Our operator and provisioner have no exec and no volume read path. Staff kubeconfigs do not exist outside break-glass, which needs a ticket, a second approver, is time-boxed, session-recorded and notifies you. Support tooling shows metadata only. |
| Staff need to look at my database to help me | You create a support access grant in the portal (metadata, read-only query or full; 1–72 hours). It issues a temporary credential to a named staff member, is logged, revocable and expires by itself. Without a grant, no path exists. |
| Credentials leak through your systems | Generated inside the cell by the operator; the control plane stores only a reference. Reveal is a one-time, signed, short-lived fetch straight from the cell. Rotation has a dual-valid window. API keys are hashed with argon2id. |
| Data at rest exposed by a disk or bucket leak | Per-tier KMS keys for volumes and backups. Per-org customer-managed key on secure hosting, or a customer-held key via KMS grant that we cannot use without your key policy. |
| Data in transit observed | TLS 1.2+/1.3 at the gateway, re-encrypted to the pod with a per-cell private CA. Optional mTLS. |
| My data lingers after I delete it | Delete keeps data for the plan's retention window (shown up front), then purges volumes, backups and secrets. Full erasure purges immediately, including the last backup, and writes an erasure certificate to the audit log. |
| My data is used by you | Never. No analytics on customer data; metering sees bytes and sizes only. Written into the terms and the BAA. |
Secure hosting: what changes
A per-instance placement for databases that hold PHI. Requires a signed BAA; available as an add-on on Team and Enterprise.
| Control | Shared (standard cell) | Secure (HIPAA cell) |
|---|---|---|
| Nodes | Shared node pool | Node pool dedicated to your org, dedicated hosts |
| Encryption at rest | Per-tier KMS key | Per-org CMK or customer-held key for volumes and backups |
| Backups | Per plan | Hourly + PITR, Object Lock (immutable), cross-region, 35 days |
| Logs | Engine logs in shared storage, statement logging off | Statement logging off; if enabled, only to your own bucket |
| Network | Default-deny network policy | Plus flow logs retained 6 years, optional required mTLS, optional PrivateLink |
| Access | Staff cannot read data | Plus break-glass needs a second approver and notifies you |
| Audit | Org audit log | Audit export / SIEM streaming, 6-year retention |
Shared responsibility
Published so HIPAA customers know exactly where the line is.
| Area | Databasezy | Customer |
|---|---|---|
| Physical and cloud infrastructure | ✔ | — |
| Kubernetes, operators, gateway, patching | ✔ | — |
| Encryption at rest and in transit | ✔ | Enable mTLS / CMK if required |
| Backups and restore tooling | ✔ | Choose policy within plan; test restores |
| Access control to instance | ✔ credentials, allow-lists, MFA | Manage members, rotate credentials, least privilege in DB roles |
| Application-level PHI handling, de-identification | — | ✔ |
| Audit log review | ✔ platform | ✔ your org's log via export |
| Breach notification | ✔ to you within 60 days, target 72 h | ✔ to individuals / HHS |
Three API planes, physically separated
Customer traffic, our own services and staff tooling never share a listener, a database role or a set of credentials.
| Plane | Who calls it | Where it lives | Identity |
|---|---|---|---|
| Public API (api.databasezy.com) | Customers, portals, CLI, MCP server | Only listener with an Ingress; behind a WAF, rate limiting and an API gateway; routes under /v1 only | Session or org-scoped API key (argon2id-hashed, scoped, optional expiry and IP allow-list) |
| Internal services | Our services calling each other | gRPC on the service mesh with mTLS and SPIFFE identities; network policy allows only named callers; no Ingress, no NodePort | Service identity (mesh certificate) plus per-route authorisation policy |
| Admin API | Databasezy staff via the admin portal | Separate binary, database role and deployment; reachable only through a zero-trust proxy; no public DNS | Staff OIDC with WebAuthn; a reason is recorded on every mutation |
| Cell control | Provisioner to each cell | Private link or VPC peering; cluster APIs are not on the internet | Per-cell IAM role with external id and namespaced RBAC |
The public binary does not link internal handlers, so internal paths do not exist on it. Distinct database roles per plane mean no service can read another's schema. Policy in the cluster blocks any ingress that points at an internal port or the admin API.
Edge protections on the public API
- WAF with OWASP core rules, bot management, body-size limits and JSON-only content types.
- Rate limits per API key and per IP (600 requests per minute per key, 60 unauthenticated, stricter on sign-in and credential reveal) with 429 and Retry-After.
- Schema validation from the published OpenAPI document; unknown fields are rejected.
- Idempotency keys on every POST, stored for 24 hours, so retries never double-create.
- Signed webhooks (HMAC-SHA256, rotating secrets, timestamps), signed images, SBOMs and digest-pinned deployments.
- TLS 1.3 only at the edge; mutual TLS between services; HSTS and a strict CSP on the portals.
- Every security-relevant event (failed logins, key misuse, cross-org lookups, rate-limit storms, credential reveals, admin actions) is emitted as a structured security event, correlated by our detection service and kept for 13 months hot and 7 years cold.
Security testing and certifications
What we test, how often, and where the results go. Penetration-test summaries are published on this page after remediation.
| Activity | Cadence | Status |
|---|---|---|
| Image and dependency scanning | Weekly, plus on every pull request | Running |
| Cloud configuration scanning | Monthly | Running |
| Fuzzing of wire parsers and request types | Continuous in CI | Running |
| External penetration test (public API, portals, gateway, one cell) | Before the HIPAA launch (Phase 3, May–July 2027) and yearly after | Scheduled; summary published here after remediation |
| SOC 2 Type I, then Type II | Type I with the HIPAA launch; Type II after a six-month window | Planned |
| Chaos and failure testing in staging | Every release train | Running |
No penetration test has been completed yet; the first is scheduled before the HIPAA launch. We will publish the tester, scope, dates, finding counts by severity and remediation status here, and share the full report with customers under NDA.
Responsible disclosure
If you find a vulnerability, we want to hear about it, and we will not take legal action against good-faith research.
How to report
Email [email protected] with the affected host or endpoint, steps to reproduce and the impact you observed. Our machine-readable contact details are at /.well-known/security.txt. Please use a test organisation on the free tier; never access, modify or exfiltrate data that is not yours, and stop as soon as you have demonstrated the issue.
What to expect
- Acknowledgement within 2 business days and a severity assessment within 5.
- A fix or mitigation within the window for the severity below, and a note when it ships.
- Credit on this page if you want it. We do not run a paid bounty programme yet.
In scope
databasezy.com, app.databasezy.com, api.databasezy.com, docs.databasezy.com, the gateway endpoints of your own instances, the CLI and the MCP server package. Out of scope: denial of service, social engineering of staff or customers, third-party services we embed (Stripe, the status provider) and findings that require a compromised device.
| Severity | Examples | Fix within |
|---|---|---|
| Critical | Cross-tenant data access, remote code execution, authentication bypass | 7 days |
| High | Privilege escalation within an org, credential exposure, significant denial of service | 30 days |
| Medium | Information disclosure without customer data, missing hardening | 90 days |
| Low | Best-practice deviations, informational findings | Next planned release |
Compliance roadmap
HIPAA Security Rule controls ship with secure hosting under a signed Business Associate Agreement. SOC 2 Type I follows within three months of that launch, Type II after a six-month observation window. Our GDPR data processing agreement and sub-processor list are published, as is our accessibility statement.