Security

Storage is only useful if it is trustworthy.

This page describes what the platform does today. It is a technical summary, not a marketing claim, and it is kept in step with the control set we run in production.

Encryption

All traffic to the API and to signed links uses TLS 1.2 or 1.3 with modern cipher suites; HSTS is enabled with a one-year max-age. At rest, objects are encrypted with AES-256-GCM under per-region keys held in a KMS. Key material never leaves the KMS boundary in plaintext, and the storage nodes hold only wrapped data keys in memory.

For buckets that need their own key, upload the wrapped key during bucket creation and DataHarbor will use it for every object in that bucket. Destroying the key makes the objects unreadable in the same second — that is the intended use.

Access

• Access keys are scoped to a bucket and can be limited to a prefix or an operation set.
• Every key carries an optional source-IP allowlist and an expiry date; expired keys fail closed.
• Signed URLs are HMAC-SHA256 with an expiry, optional IP or referer pin, and a revocable nonce.
• Console access requires a second factor; TOTP and WebAuthn are both supported, and hardware keys can be enforced per organisation.

Audit and monitoring

Data-plane operations are logged with the key ID, source address, object key, and result. The log is append-only from the application account and can be streamed to a customer-controlled bucket or to a SIEM endpoint over TLS. Retention is 400 days by default.

Infrastructure changes are made through a reviewed pipeline with two-person approval for anything touching key management or network policy. Administrative access to production requires a hardware token and a session that is recorded.

Isolation

Each tenant's metadata lives in a logically separated schema, and object paths are namespaced by tenant ID at the storage layer. Bucket policies cannot reference another tenant's principals. The request path validates tenant identity before it resolves an object path, so a crafted key cannot traverse out of its namespace.

Independent testing

An external firm performs a grey-box penetration test once a year and a scoped retest after any change to the authentication path. The summary report is available under NDA. We run continuous dependency scanning and publish fixed versions of client tools within 72 hours of a relevant advisory.

Incident policy

Confirmed breaches affecting customer data are reported to affected customers within 24 hours of confirmation, with a written timeline and the remediation steps taken. The status page carries a public notice for incidents that degrade the service, even when no data is involved.

Data location

EU customers are placed in Frankfurt or Amsterdam by default; Warsaw is available on request. Replication stays inside the EU unless a customer explicitly enables a third region. Deletion is immediate from the index and the underlying blocks are overwritten within seven days.

Reporting a vulnerability

Send findings to security@dataharbor.example with a description and reproduction steps. We acknowledge within one business day, coordinate disclosure within 90 days, and do not pursue legal action against researchers who act in good faith and avoid privacy violations, data destruction, and service degradation. A PGP key is published in security.txt.