Security Policy

Security is fundamental to running a database platform. This page describes how we protect your data in transit, at rest, and across our systems — and what we commit to doing when things go wrong.

This page is a living document. When the underlying controls change in a way that affects your data, we update the “Last updated” date.

All client traffic to the Luceris Cloud control plane and database proxies is encrypted using TLS 1.3. We require modern cipher suites and disable legacy protocols. Connection URIs returned by the Service include sslmode=require (or the engine-equivalent) so client drivers negotiate TLS by default.

Data at rest is encrypted with AES-256 on the underlying storage layer. Tenant database credentials are stored in our credential cache as bcrypt hashes; the proxy validates against the bcrypt-hashed entry on every connection. Plaintext credentials are never written to logs.

Access to your data is gated by role-based access control on the Luceris side and by your database’s native authentication on the tenant side. Roles within an organization are owner, admin, and member; only owners and admins can rotate database passwords or manage membership.

Internally, employee access to production systems follows the principle of least privilege. Standing access is limited to the operations team. All access is logged via our audit-log dual-sink (a write to CloudWatch as the authoritative record, plus an awaited Postgres audit_log INSERT for query-time access).

Each tenant database is provisioned with a unique credential pair. Redis tenants run as dedicated redis-server processes on private ports behind the proxy. Cross-organization access is rejected at the proxy and at the underlying engine — there is no shared schema or shared connection pool that grants ambient access to another tenant’s data.

Tenant databases are backed up on a schedule appropriate to the engine and plan. Postgres clusters support point-in-time recovery within the retention window of your tier. Specific recovery-time and recovery-point objectives for the Contact-us tier are documented in your service agreement.

We run continuous monitoring on infrastructure metrics, error rates, and authentication anomalies via CloudWatch alarms and the audit-log dual-sink. Per-IP rate limiting at the API edge (backed by DynamoDB) protects against credential-stuffing and brute-force attempts.

We maintain an incident-response runbook covering detection, triage, containment, recovery, and post-incident review.

Where a security incident materially affects your personal data, we will notify the CNIL within 72 hours of becoming aware, as required by Article 33 GDPR, and notify affected users in line with Article 34. Communications are handled by email and, where available, through an in-product notice.

We welcome reports of security vulnerabilities. Please email [email protected] with a description, reproduction steps, and your contact information. We acknowledge reports promptly and target a coordinated-disclosure window of 90 days from acknowledgement.

We do not operate a paid bug bounty today. We do not pursue legal action against researchers acting in good faith and in accordance with this policy.

We rely on a small number of trusted sub-processors to operate the Service. The current list (and a short description of what each provides) lives on our GDPR page.

When our security controls change in a way that materially affects your data, we update this page and notify customers on the Contact-us tier directly.

Security questions, vulnerability reports, and compliance requests can be sent to [email protected].