Documentation

Compliance & Regulatory Guide

Absolute DB ships complete compliance automation for GDPR, HIPAA, PCI-DSS v4, SOC 2 Type II, and ISO 27001:2022 — plus post-quantum cryptography, column-level encryption, and OpenLineage data lineage. All in pure C11, zero external deps.

Access Control (RBAC / ABAC / RLS)

Absolute DB provides a layered access-control stack: role-based access control (RBAC), attribute-based access control (ABAC), row-level security (RLS), and dynamic data masking — all enforced inside the query executor before any data leaves the server.

RBAC — Role-Based Access Control

Standard SQL privilege model: GRANT / REVOKE on databases, schemas, tables, columns, functions, and sequences. Roles are hierarchical — a role can inherit privileges from parent roles.

sql
CREATE ROLE analyst;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO analyst;
GRANT analyst TO alice;          -- alice inherits analyst privileges

-- Column-level privilege
GRANT SELECT (id, name) ON customers TO reporting_role;
REVOKE SELECT (ssn) ON customers FROM reporting_role;

ABAC — Attribute-Based Access Control

Policy rules evaluated against session attributes (user, role, tenant, IP, time) and row attributes at query time. ABAC policies complement RBAC for fine-grained, context-sensitive access.

sql
-- Example: restrict access to business hours only
CREATE POLICY business_hours ON orders
  USING (EXTRACT(HOUR FROM now()) BETWEEN 8 AND 18);

RLS — Row-Level Security

Transparent row filtering applied to every query. Users only see rows that match their policy — no application-layer join or WHERE clause required.

sql
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON orders
  USING (tenant_id = current_setting('app.tenant_id')::int);

-- Each tenant's queries automatically filter to their own rows

Dynamic Data Masking

Sensitive columns (PII, PAN, PHI) can be masked at query time based on the caller's role — raw values are stored but returned as masked output to unprivileged roles.

sql
ALTER TABLE customers ALTER COLUMN email SET (mask = 'email');
-- Privileged role sees:  alice@example.com
-- Unprivileged role sees: a***@e***.com

SSO / JWT / LDAP / OAuth2

  • JWT (OIDC) — Auth0, Okta, Keycloak, Azure AD, Google; HS256/RS256/ES256; JWKS key cache.
  • LDAP / Active Directory — pure C11 LDAP v3 client; simple bind; group-to-role mapping (up to 16 rules); LDAPS on port 636.
  • OAuth2 bearer tokens — validated against configurable JWKS endpoint.

GDPR (EU 2016/679)

Absolute DB provides automated GDPR compliance tooling covering the right to erasure (Article 17), Subject Access Requests (Article 15), consent ledger, and data portability (Article 20).

Right to Erasure

SQL
-- Erase all data for a data subject across all tables
CALL absdb_gdpr_erase('users', 'email', 'alice@example.com');
-- Returns: { "tables_affected": 7, "rows_erased": 142, "audit_ref": "GDR-2026-04-001" }

Subject Access Request (SAR)

SQL
-- Generate a complete SAR report in JSON
SELECT * FROM absdb_gdpr_report('alice@example.com');
-- Returns all data held across all tables for the subject,
-- formatted as a portable JSON document (Article 15 / Article 20)

Consent Ledger

SQL
-- Record consent
INSERT INTO _absdb_consent_ledger (subject_id, purpose, granted, ts)
VALUES ('alice@example.com', 'marketing_emails', true, NOW());

-- Withdraw consent
UPDATE _absdb_consent_ledger
SET granted = false, withdrawn_at = NOW()
WHERE subject_id = 'alice@example.com' AND purpose = 'marketing_emails';
Article 17 guarantee: absdb_gdpr_erase() performs a cryptographic DEK rotation for the subject's encrypted columns, making previously encrypted data irrecoverable — even from backups — without physically deleting every backup shard.

HIPAA Technical Safeguards

Absolute DB implements HIPAA Technical Safeguards (45 CFR §164.312) through PHI column tagging, encrypted audit trails, and access reporting.

PHI Column Tagging

SQL
-- Tag PHI columns
ALTER TABLE patients ALTER COLUMN ssn      SET (hipaa_phi = true);
ALTER TABLE patients ALTER COLUMN dob      SET (hipaa_phi = true);
ALTER TABLE patients ALTER COLUMN diagnosis SET (hipaa_phi = true);

-- PHI columns are automatically:
--   - Encrypted with AES-256-GCM
--   - Audited on every SELECT, INSERT, UPDATE
--   - Masked in query logs and error messages

Access Report

SQL
-- Generate HIPAA access audit report for a date range
SELECT * FROM absdb_hipaa_access_report('2026-01-01', '2026-03-31');
-- user_id | action  | table     | column    | rows | timestamp
-- alice   | SELECT  | patients  | ssn       | 1    | 2026-01-15 09:22:11
-- bob     | UPDATE  | patients  | diagnosis | 3    | 2026-01-20 14:55:00

PCI-DSS v4.0

Absolute DB is architected for PCI-DSS v4.0 compliance with Format-Preserving Encryption (FF3-1) tokenisation, PAN masking, and annual DEK rotation — all using NIST-approved algorithms.

FF3-1 Tokenisation

SQL
-- Tokenise a PAN (returns format-preserving token)
SELECT absdb_pci_tokenise('4111111111111111');
-- Returns: '4xxx-xxxx-xxxx-6374' (format-preserving, not the real PAN)

-- De-tokenise (role-restricted: requires pci_detokenise privilege)
SELECT absdb_pci_detokenise('4xxx-xxxx-xxxx-6374');
-- Returns: '4111111111111111'  (restricted role only)

-- Masked display (always safe for logs, UI, support)
SELECT absdb_pci_mask_pan('4111111111111111');
-- Returns: '****-****-****-1111'

DEK Rotation

SQL
-- Annual DEK rotation (PCI-DSS Req 3.7.2)
-- Re-encrypts all PCI-tagged columns with a new DEK.
-- Zero downtime — rotation happens in a background transaction.
CALL absdb_pci_rotate_dek('pci_tenant', absdb_kms_generate_dek('pci_tenant'));

-- Verify rotation
SELECT last_rotation, next_rotation_due FROM absdb_pci_dek_status;

SOC 2 Type II

Absolute DB provides continuous evidence collection for SOC 2 Type II audits covering the Security, Availability, and Confidentiality trust service criteria.

SQL
-- Generate SOC 2 evidence package for audit period
SELECT * FROM absdb_soc2_evidence('2026-01-01', '2026-03-31');
-- Returns JSON with:
--   - DDL change log (_absdb_ddl_log)
--   - User access events
--   - Authentication successes/failures
--   - Encryption status per table
--   - Backup completion events
--   - High-availability events

-- DDL audit log (all schema changes, immutable)
SELECT * FROM _absdb_ddl_log
WHERE ts BETWEEN '2026-01-01' AND '2026-03-31'
ORDER BY ts;

ISO 27001:2022

Absolute DB maintains an asset register and control mapping for ISO 27001:2022 Annex A controls, with automated evidence generation.

SQL
-- View asset register (ISO 27001 Annex A.8 - Asset Management)
SELECT * FROM _absdb_assets;
-- asset_id | name         | owner       | classification | location
-- 1        | orders table | alice       | confidential   | primary DC
-- 2        | pki keys     | absdb-kms   | secret         | HSM

-- View implemented controls
SELECT * FROM absdb_iso27001_controls();
-- control_id | title                                    | status     | evidence
-- A.8.24     | Use of cryptography                      | implemented | adb_colencrypt, adb_tls_native
-- A.8.7      | Protection against malware                | implemented | input validation, WAF headers
-- A.8.15     | Logging                                  | implemented | _absdb_ddl_log, audit trail

Post-Quantum Cryptography (FIPS 203/204/205)

Absolute DB implements all three NIST post-quantum cryptography standards in pure C11 with no external library. FIPS KAT vectors pass at startup (make pqc-kat).

StandardAlgorithmUse in Absolute DB
FIPS 203ML-KEM-768 (Kyber-768)Hybrid TLS key encapsulation: X25519 ‖ ML-KEM-768 → HKDF-SHA-256
FIPS 204ML-DSA-65 (Dilithium-3)Node identity certs, WAL signing, cert rotation, audit log signing
FIPS 205SLH-DSA (SPHINCS+)CA root certificates, software release signing

Hybrid TLS 1.3 + PQC

absdb.conf
pqc_enabled       = true         # enable post-quantum hybrid TLS
pqc_kem           = ml-kem-768   # FIPS 203 key encapsulation
pqc_hybrid_mode   = x25519       # classical + PQC combined secret
tls_alpn          = absdb/1,h2,http/1.1
SQL
-- Verify PQC status on current connection
SELECT absdb_tls_info();
-- { "version": "TLSv1.3", "cipher": "AES-256-GCM",
--   "kem": "X25519+ML-KEM-768", "sig": "ML-DSA-65",
--   "pqc": true, "fips203_kat": "PASS", "fips204_kat": "PASS" }

Column Encryption

Individual columns can be encrypted with AES-256-GCM using KMS-managed Data Encryption Keys (DEKs). Keys are never stored in the data files — only DEK references (key IDs) are stored alongside the ciphertext.

SQL
-- Generate a DEK for a tenant
SELECT absdb_kms_generate_dek('tenant_acme');

-- Encrypt a column at rest
ALTER TABLE users ALTER COLUMN ssn
  SET (encrypted = true, kms_key_id = 'tenant_acme_dek_v1');

-- Transparent decryption on SELECT (authorised roles only)
SELECT ssn FROM users WHERE id = 42;
-- '123-45-6789'   (decrypted transparently)

-- Unauthorised role sees ciphertext reference
-- ERROR: column ssn: insufficient privilege for decryption

-- Key rotation (re-encrypt with new DEK, background, zero downtime)
CALL absdb_kms_rotate_dek('tenant_acme_dek_v1', absdb_kms_generate_dek('tenant_acme'));
ComponentDetail
Encryption algorithmAES-256-GCM (authenticated encryption)
Key derivationArgon2id KDF
MACHMAC-SHA384
Key managementBuilt-in KMS or PKCS#11 HSM
Key rotationOnline, zero-downtime background re-encryption
StorageOnly DEK key-ID stored with ciphertext; plaintext DEK never written to disk

Audit Log

All security-relevant events are written to a SHA-256 hash-chained, append-only audit log with Merkle tree validation. WORM mode prevents any modification or deletion of audit records.

SQL
-- View recent audit events
SELECT ts, user_id, event_type, table_name, row_count, hash
FROM _absdb_audit_log
ORDER BY ts DESC LIMIT 20;

-- Verify chain integrity (detects tampering)
SELECT absdb_audit_verify_chain();
-- { "status": "OK", "records": 182441, "root_hash": "a3f7c..." }

-- Export audit log for external SIEM
COPY (SELECT * FROM _absdb_audit_log WHERE ts > NOW() - INTERVAL '1 day')
TO '/tmp/audit_export.jsonl' WITH (FORMAT jsonl);

Data Lineage (OpenLineage v1)

Column-level data provenance is tracked automatically by the executor. Lineage is stored in _absdb_lineage and exported in OpenLineage v1 format for integration with data catalogs (Amundsen, DataHub, Apache Atlas).

SQL
-- Trace lineage of a column
SELECT * FROM absdb_lineage_of('orders', 'customer_id');
-- src_table   | src_col     | dst_table | dst_col     | query_id | ts
-- customers   | id          | orders    | customer_id | q-4821   | 2026-03-01
-- raw_events  | user_id     | customers | id          | q-1203   | 2026-02-15

-- GDPR impact analysis: which columns depend on a user's data?
SELECT * FROM absdb_impact_of('users', 'email');
-- Returns all downstream columns derived from users.email

-- Export OpenLineage v1 JSON for DataHub / Amundsen
SELECT absdb_lineage_export_openlineage('orders');

-- View raw lineage table
SELECT * FROM _absdb_lineage LIMIT 10;

Standards Compliance Matrix

StandardCoverageEvidence Mechanism
GDPR (EU 2016/679)Fullabsdb_gdpr_erase(), absdb_gdpr_report(), consent ledger
HIPAA Technical SafeguardsFullPHI tagging, absdb_hipaa_access_report()
PCI-DSS v4.0FullFF3-1 tokenisation, DEK rotation, PAN masking
SOC 2 Type IIFullabsdb_soc2_evidence(), _absdb_ddl_log
ISO 27001:2022Full_absdb_assets, absdb_iso27001_controls()
FIPS 203 ML-KEM-768FullKAT vectors PASS (make pqc-kat)
FIPS 204 ML-DSA-65FullKAT vectors PASS
FIPS 205 SLH-DSAFullKAT vectors PASS
ANSI SQL:2023100%150/150 conformance tests
OpenLineage v1FullColumn-level provenance export
CISA Memory-SafeFullASan/UBSan/TSan CI green (0 violations)

Continue Reading

Security Overview Enterprise Scale Admin Guide

Ready to run Absolute DB?

~154 KB binary  ·  zero external dependencies  ·  2,737 tests passing  ·  SQL:2023 100%

Download Free → View Pricing All Docs