Security built in,
not bolted on.

Every security feature in Maree-DB is a first-class engine primitive — not a plugin, not a wrapper, not an afterthought. From kernel-level integrity monitoring to post-quantum cryptography.

AES-256-GCM at rest TLS 1.3 in transit Cryptographic integrity chain Ed25519 signatures ML-KEM post-quantum ML-DSA post-quantum Kernel-level monitoring X25519 key exchange ChaCha20-Poly1305 Autonomous ransomware detection
TamperLock

Cryptographic tamper evidence on every transaction.

TamperLock anchors every committed transaction to an append-only cryptographic hash chain with inclusion proofs. The chain is signed by the server's Ed25519 key. Any attempt to modify, delete, or reorder historical data causes chain verification to fail — making tampering mathematically detectable without a central authority.

Cryptographic Hash Chain

Each block contains the hash of the previous block. The entire audit history is verifiable in a single pass with 256-bit security — faster than SHA-256 with equivalent collision resistance.

Inclusion Proofs

Individual transactions can be proven to be part of the chain without revealing other transactions. Ideal for compliance audits where only a specific subject's data needs to be verified.

Ed25519 Signatures

Forensic audit reports are signed by the server's Ed25519 private key. Recipients can verify the report was generated by the genuine server and has not been modified in transit.

TamperLock verification
maree> SELECT * FROM tamperlock_verify_chain();
block_height │ hash │ valid
─────────────┼──────────────────────────────────┼───────
1842 │ 3f7a9c2d…e41b0f88 │ true
1843 │ a18bc504…22d97c31 │ true
1844 │ 7e2f3a91…b08d4c55 │ true
Chain intact. 1,844 blocks verified. 0 integrity failures.
Fortress Lock

Kernel-level defence. Zero trust from the ground up.

Fortress Lock attaches monitoring probes directly to kernel operations. SQL injection patterns, unusual access rates, and privilege escalation attempts are detected at the kernel level — before any parsing occurs. Autonomous ransomware detection identifies mass-encryption patterns and triggers immediate protective lockdown.

Kernel-Level Monitoring

Monitoring programs attach to kernel operations at startup and observe network I/O, file access, and process activity. No additional agent required — fully integrated with verified safety properties.

Autonomous Ransomware Detection

Rate-based anomaly detection flags unusual query patterns, mass data extraction, mass-encryption activity, and credential stuffing. Configurable sensitivity thresholds per role and per table.

Lockdown Mode

When Fortress Lock triggers, the database enters a cryptographically sealed lockdown: all writes are rejected, a forensic snapshot is captured, and the DBA is notified via syslog and webhook.

Encryption

Data at rest, in transit, and post-quantum.

Data at Rest — AES-256-GCM

All data pages on disk are encrypted with AES-256-GCM. The master key is stored in the OS keyring (libsecret / macOS Keychain / Windows DPAPI) and never written to disk in plaintext. Key rotation is a live operation with zero downtime.

Data in Transit — TLS 1.3

All wire protocol connections (MySQL, PostgreSQL, SQL Server, Redis, REST) are encrypted with TLS 1.3 using rustls — a memory-safe, pure-Rust TLS implementation. TLS 1.0 and 1.1 are permanently disabled. TLS 1.2 is configurable for legacy client compatibility.

Secure Memory — Zeroization

All cryptographic key material, plaintext PANs, and PHI values are stored in zeroized memory regions. Memory is securely overwritten before deallocation, preventing cold-boot and memory-dump attacks.

Post-Quantum — ML-KEM (CRYSTALS-Kyber)

Enterprise and OEM editions support ML-KEM 768 (FIPS 203) for key encapsulation. This protects encrypted data against harvest-now-decrypt-later attacks from future quantum computers.

Post-Quantum — ML-DSA (CRYSTALS-Dilithium)

TamperLock forensic reports and certificate signatures can be signed with ML-DSA (FIPS 204) for quantum-resistant non-repudiation. Compatible with hybrid X25519 + ML-KEM key exchange.

Passwords — PBKDF2-SHA-256

User passwords are hashed with PBKDF2-SHA-256 (310,000 iterations, NIST SP 800-132 compliant). MySQL wire auth uses SHA-1 challenge-response for compatibility; TLS ensures the channel is encrypted first.

Access Control

Fine-grained RBAC. Row and column level.

Maree-DB implements full Role-Based Access Control (RBAC) with Row-Level Security (RLS) policies and column masking. All access decisions are enforced at the kernel level — RBAC cannot be bypassed by direct file access.

Role Hierarchy

Roles can inherit from other roles. Built-in compliance roles: gdpr_admin, hipaa_admin, pci_admin, payment_processor, auditor, privacy_officer, dpo.

Row-Level Security

RLS policies filter rows based on the current user's attributes. A SELECT * FROM orders can return only rows owned by the calling user — without application code changes.

Column Masking

PII columns can be dynamically masked for non-privileged roles. email becomes jo*****@example.com and PAN becomes 411111******1111 — automatically, at the query layer.

Compliance SQL Functions

Compliance as SQL. Nine built-in functions.

All compliance operations are expressed as standard SQL function calls. No separate compliance tools, no ETL pipelines, no custom scripts. Run directly from any SQL client.

mareedb_gdpr_erase(table, column, value)
Delete all rows matching the subject identifier. Implements GDPR Article 17 right to erasure. Returns count of erased rows.
Required role: gdpr_admin
mareedb_gdpr_report(identifier)
Return all data associated with the subject. Implements GDPR Article 15 right of access.
Required role: gdpr_admin
mareedb_gdpr_pii_map()
Return inventory of all PII-tagged columns. Implements GDPR Article 30 records of processing activities.
Required role: dpo
mareedb_hipaa_access_report(start_date, end_date)
Return all PHI access events in the date range. Implements HIPAA Security Rule §164.312(b) Audit Controls.
Required role: hipaa_admin
mareedb_pci_tokenise(pan)
Replace a PAN with a keyed surrogate token. PCI-DSS v4.0 §3.5.1 compliant. Luhn-verified input. Token format: BIN(6)-TOK-{12 hex chars}.
Required role: payment_processor
mareedb_pci_detokenise(token)
Recover the original PAN from a token. Restricted to pci_admin, payment_processor, and refund_agent roles.
Required role: pci_admin
mareedb_soc2_evidence(start_date, end_date)
Return a SOC 2 Type II evidence package covering the specified period. AICPA Trust Services Criteria 2017.
Required role: auditor
mareedb_iso27001_controls()
Return the ISO/IEC 27001:2022 Annex A control inventory mapped to Maree-DB components and implementation status.
Required role: auditor
mareedb_privacy_au_residency_check()
Return data residency information per Australian Privacy Principle 8 (APP 8), Privacy Act 1988 (Cth).
Required role: privacy_officer

Responsible Disclosure

If you discover a security vulnerability in Maree-DB or our infrastructure, please report it to our security team before public disclosure. We treat every report seriously and respond fast.

24h Acknowledgement
72h Initial triage
30 days Target fix (critical)
  • We will not pursue legal action against good-faith researchers.
  • We will acknowledge your report publicly in our Hall of Fame (with your permission).
  • We will keep you informed of progress from triage to patch release.
  • We will not publicly disclose the vulnerability until a fix is available, unless you request otherwise.
  • We will credit you in the security advisory unless you prefer anonymity.

Please include: affected version, steps to reproduce, proof-of-concept (if available), and your assessment of impact. PGP encryption for sensitive reports is available on request.

Security Hall of Fame

Researchers who have responsibly disclosed vulnerabilities in Maree-DB.

Be the first — Maree-DB launched 27 May 2026. We look forward to our first responsible disclosure.