Security
Your database backups are as sensitive as the databases themselves. Here is exactly what we do to keep them that way.
Encryption
Backups are encrypted with AES-256-GCM on the machine that produces them, before leaving the customer's network. A random 12-byte nonce is generated per backup and incremented per chunk; the authentication tag is verified on restore, so a modified or truncated ciphertext fails to decrypt rather than producing silent garbage.
Keys are 256 bits in both product paths, but the derivation differs:
- Resistro Cloud agent: the customer generates a random key on their own host with
openssl rand -hex 32(or the dashboard's in-browser generator,crypto.getRandomValues) and stores it in/etc/resistro-agent/env. No passphrase, no KDF — the key starts with full 256-bit entropy and never leaves that host. - Self-hosted CLI (
resistro): the customer supplies a passphrase and the CLI derives the key with PBKDF2-HMAC-SHA-256 at 600 000 iterations (OWASP 2023) over a 32-byte random salt stored in the file header. The passphrase never leaves the customer's machine.
The threat model we defend against
- A compromised Resistro Cloud server: the server stores ciphertext only. Without the customer's key it cannot decrypt.
- A compromised storage backend (Hetzner Object Storage): same property — ciphertext only.
- Network eavesdropping: all transport is TLS 1.3 over nginx, HSTS enforced.
The threat model we do not
- Compromise of the agent host: if an attacker reads
/etc/resistro-agent/env, they have the key and the API token. Protect that file with filesystem permissions (0600 by default) and operating-system hardening. - Loss of the encryption key: without it, your backups are unrecoverable. We cannot recover it for you — by design.
Key management
The encryption key is generated once by the customer with openssl rand -hex 32 and placed in /etc/resistro-agent/env. It never leaves that host. Resistro Cloud stores only a SHA-256 fingerprint of the key per backup, to verify that restore attempts use the correct key. The key itself is not in our database, logs, metrics, or support channels.
If you lose the key, we cannot help you restore — this is the price of the guarantee that nobody but you can.
Data residency
- Compute: Hetzner Online GmbH, Falkenstein / Nuremberg, Germany.
- Backup storage: Hetzner Object Storage, Nuremberg (nbg1). EU-only data path.
- Database (metadata only): PostgreSQL, same region.
- No customer backup content ever leaves the EU.
Access control
- API Keys (agent auth) are randomly generated
rst_<64 hex>tokens, tenant-scoped, revocable from the dashboard. - JWT (dashboard auth) signed with HS256, short-lived, server-side password hashes use bcrypt.
- Agent endpoints are rate-limited per tenant (tier-dependent).
- Multi-tenant isolation is enforced at the SQL layer: every query is scoped by
tenant_id. Storage keys carry a tenant-prefixed shard so a bug in one handler cannot read another tenant's object path.
Operational security
- Backups and restores run against an immutable object-storage backend; there is no
DELETEpath for a tenant to mass-wipe their own history outside the documented retention policy. - Server logs (journald) redact API keys and bodies. We log method, path, status, duration, remote IP.
- Failed-login rate limit: 10/min per source IP on the authentication endpoints.
- HTTP security headers:
Strict-Transport-Security,X-Content-Type-Options,X-Frame-Options,Referrer-Policy.
What we are doing — and what we are not
We are transparent about where we are in building trust. Enterprise buyers need to know, not guess.
| Control | Status |
|---|---|
| Client-side AES-256-GCM encryption | Live |
| EU-only data path (Hetzner, DE) | Live |
| Tenant-prefixed storage sharding | Live |
| Per-tenant rate limits | Live |
| Offered: AVV (Auftragsverarbeitungsvertrag / DPA) | Live — full template · PDF |
| Independent penetration test | Planned Q3/2026 |
| SOC 2 Type II | Planned — no fixed date |
| ISO 27001 certification | Not planned currently |
| Bug-bounty programme | Planned Q3/2026 |
Responsible disclosure
If you find a security issue, please email security@…. We commit to acknowledging within 48h, a fix or mitigation timeline within 7 days, and public credit once the fix is shipped (unless you prefer anonymity).
Questions your procurement team will ask
We maintain a standard vendor-security questionnaire (BSI Grundschutz / VAIT / typical DACH-B2B format). Ask us and we'll send it within one business day.