Governance
Security posture
Security in a data platform is mostly about boundaries: who can reach which columns, where secrets live, what gets tokenised before it is written, and what evidence exists afterwards. The catalogue below states honestly which controls are implemented in this lab, which are designed, and which are only planned.
No credentials anywhere
This repository contains no passwords, keys or connection strings. Connection details in the examples are placeholders.
Synthetic data only
Every customer, order and device record is fabricated. No production or customer data was used to build this lab.
No live integration claimed
There is no Oracle client, driver or network connection in this application. Screens are UI models of real practice.
Control catalogue
4 of 7 controls are implemented within the demo scope.
| ID | Control | Area | Status | Evidence / note |
|---|---|---|---|---|
| C-01 | Least-privilege database roles with separation of duties | Access control | implemented | Role matrix documented; no shared accounts in the reference design. |
| C-02 | Secrets held in a managed vault, never in source or config files | Secrets management | implemented | This repository contains zero credentials; connection details are placeholders. |
| C-03 | Tokenisation of sensitive attributes before persistence | Data protection | implemented | Customer conformance pipeline tokenises restricted fields in-flight. |
| C-04 | Column-level classification drives masking in non-production | Data protection | designed | Classification labels are attached to every column in the schema catalogue. |
| C-05 | Immutable audit trail for privileged operations | Auditing | designed | Unified audit policy defined in the runbook; write-once sink specified. |
| C-06 | Retention enforcement with provable purge | Data lifecycle | implemented | Archive & purge pipeline requires checksum proof before purge commit. |
| C-07 | Quarterly access recertification | Governance | planned | Process drafted; owner assigned, first cycle not yet run in this lab. |
Production architecture (not built here)
What would change if this lab were promoted to a real environment.
- Database access via a private network path and a managed connection pool, never from the browser.
- Credentials issued from a vault with short-lived rotation; no static passwords in any config.
- Row- and column-level policies enforced in the database, with masking for non-production copies.
- Unified auditing streamed to a write-once sink outside the database administrator's control.
- Change management through reviewed migrations, with rollback rehearsed before release.