How we address confidentiality
Encryption in transit and encryption at rest
Databunker Pro enforces full encryption in transit and at rest by default. All network requests are secured using SSL encryption protocols.Record encryption
Customer personal information records are encrypted using AES-256 keys or securely hashed in the product internal database. AES-256 encryption is FIPS 140-2 compliant and meets federal cryptographic standards.Encryption of audit events
Personally Identifiable Information (PII) in audit events is fully encrypted.Secure hash-based search index
Databunker Pro extracts emails, phone numbers, and login names from user records to build a hashed-based search index. This method allows secure lookups of original user records.Backend database connectivity
Databunker Pro supports PostgreSQL, MySQL, and Oracle as backend databases, connecting through a secure SSL channel. Multi-tenancy is supported on all three; on PostgreSQL it is enforced with native row-level security (RLS).Database-level tenant isolation
On PostgreSQL, tenant isolation is enforced by the database rather than by the correctness of application queries. Two dedicated roles are created at setup, bothNOSUPERUSER NOLOGIN so neither can be used to log into the database directly:
Ordinary requests run as
mtenant with the tenant fixed for the session, so a query that omits or mistakes its tenant condition still cannot return another tenant’s rows — isolation does not depend on every query being written correctly. Roughly two dozen tables are covered.
Cross-tenant reads are the narrow exception. They are restricted to the main-tenant administrator, additionally gated by a short-lived unlock UUID, and audited on every call. Because madmin is granted read-only access to a single table, even that bypass path cannot write anything or reach audit records, sessions, or files.
On MySQL and Oracle, tenant scoping is applied in the queries Databunker Pro issues rather than by the database, so this second line of defence is specific to PostgreSQL.
For the policy definitions, the covered tables, and the cross-tenant endpoints, see Database-level tenant isolation.
FIPS compliance
Databunker Pro uses FIPS 140-2 compliant cryptographic algorithms for core security operations:- Certificate generation: When deploying via Helm, certificates are generated using RSA 2048-bit key length, which is FIPS compliant.
- Record encryption: All customer records are encrypted using AES-256, a FIPS-approved symmetric encryption algorithm.
- Go runtime: The Go programming language runtime does not enforce FIPS mode internally, allowing Databunker Pro to operate in FIPS-enabled environments while maintaining compatibility.
- As a distributed lock mechanism in the
usersanduserappstables to prevent concurrent modifications - As part of a double-hash (SHA256 + MD5) for duplicate detection in format-preserving tokenization engine
- As salt material (MD5 of master key) for SHA256-based indexing of user records (e.g., email, phone numbers)
Secure session storage
Session data, including PII such as email addresses, IP addresses, and browser details, is securely stored in Databunker’s encrypted store via a dedicated API.Secure bulk data export/dump
We have introduced a specialized secure API to control and limit bulk data exports. Learn more here.Wrapping keys and Shamir key shares
Databunker Pro uses a master key to encrypt all records. The master key is never exposed — not to users, not to administrators, and not through any API. It is itself encrypted by a wrapping key, which is the only key you handle. The master key is stored under two independent wrappings: one by the operational wrapping key your deployment reads at boot, and one by a recovery key reconstructable from any three of five Shamir key shares issued at setup. Rotating the wrapping key re-wraps the master key without re-encrypting any stored record, so rotation costs the same on a vault of 1,000 records as on one of 100 million, and previously issued shares stay valid. Databunker holds no copy of your keys and operates no escrow. This is why a compromise of Databunker’s own systems cannot expose your data — and equally why key custody is your responsibility: if the wrapping key is lost and fewer than three shares remain, the data cannot be decrypted by anyone. See Wrapping key rotation for the procedure and What is recoverable for the full failure matrix.Optional user scheme validation
Databunker Pro supports user schema validation to enforce mandatory fields in user records. It returns error messages for objects missing required fields.How we address integrity
Record update
Databunker employs encrypted JSON objects for storing user profiles. During updates, Databunker ensures the presence of the original record in the database by verifying its checksum before executing SQL UPDATE queries.Multi-tenancy
Databunker Pro implements multi-tenancy on PostgreSQL, MySQL, and Oracle. Queries executed by specific tenants are restricted to their own records. On PostgreSQL, isolation is enforced with the database’s native row-level security (RLS) mechanism — see Database-level tenant isolation for the role model and the cross-tenant exceptions.Token-based API Access
All API requests require a user token and tenant name. Databunker identifies user roles, verifies permissions, and blocks unauthorized requests within the tenant’s scope.How we address availability
Containers
Databunker Pro is distributed as Docker container, which can be easily deployed in cloud environments. Example scripts for running these containers using Docker Compose and Kubernetes are provided.Stateless application server
Databunker Pro is a stateless application server, enabling multiple instances to run concurrently. The primary bottleneck is the backend database. To address this, Databunker Pro integrates with AWS Aurora PostgreSQL Auto-Scaling databases. PostgreSQL, MySQL, and Oracle are supported as backend databases.Scalability in Kubernetes
Databunker Pro can be seamlessly scaled in Kubernetes using horizontal scaling. This ensures high availability and performance under increasing workloads. Kubernetes facilitates effortless scaling by dynamically adjusting the number of running instances based on resource utilization, ensuring that Databunker can meet growing demands efficiently.Encryption service availability
The sections above cover capacity. Availability of the encryption service itself depends on one credential: the vault cannot start without its wrapping key. Key custody is therefore an availability control, not only a confidentiality one. Treat the wrapping key with the same operational care as the database itself:- Back up the database and the wrapping key. Either one alone is insufficient to restore service.
- Store the wrapping key in a secret manager, and keep the five Shamir shares somewhere separate from it.
- Verify at least three shares remain reachable on a schedule — a shortfall is invisible until the moment you need them.