Production Data Changes

Every change on a one-hour account, every statement logged · roadmap item 12 · owner: SRE

Some production data is corrected by hand: a refund stuck in the wrong state, a penalty that should not have applied, a code table that needs one more row. Today those changes go through 阿諾, an in-house tool that connects directly to the production Oracle databases. This page records what that tool does and does not do, the Superset + Vault design that replaces it, and what that design does not cover yet.

The work is milestones 12.6 (contain 阿諾 now) and 12.7 (replace it) on the Zero-Trust Security milestones. Their dates are a first draft and will be adjusted.

Today

Anyone who can log in to 阿諾 can run any SQL against the databases it is connected to, writes included. There is no approval step and no review of the SQL before it runs. The only control is 阿諾's own execution log: who ran which statement, when, against which database, and an optional request number.

Measured from that log, the 12 months to 2026-10-08:

Executions	23,290, of which 19,949 are writes (85.7 %) — UPDATE 13,095 · INSERT 5,554 · DELETE 1,300
People	73, across 7 Oracle databases
Writes without a request number	8,180 (41 %)
UPDATE / DELETE without WHERE	13
Writes outside working hours (weekend or 19:00–09:00)	2,609 (13 %)
Several statements in one execution	2,185 (11 %)
Monthly volume	roughly 1,000–3,000 executions; the peak, 3,064, was June 2026, before 618

The tool works, and the volume says the need is real. What is missing is everything between "I want to change this row" and the row changing: nobody checks the statement, nobody approves it, and the database only ever sees 阿諾.

The Superset + Vault design

The replacement is Superset in front of Vault, and its core already works (verified 2026-09-30):

• An engineer logs in to Superset and picks a database and read or write. Superset obtains a dynamic Oracle account valid for one hour from Vault and connects with it on the engineer's behalf. The engineer never holds a database password.
• When the hour is up, Vault calls a DBA-owned function that ends the account's sessions and drops it. The DataGuard standby receives the same accounts through redo, so it needs no Vault connection of its own; sessions left there are closed within 15 minutes.
• Read and write are separate database accounts. Which one an engineer gets follows the permission they applied for at the start.

What the design does not do yet — and what 12.7 has to settle:

Gap	Today	Where it is closed
Attribution	Superset reaches Vault with an AppRole, so accounts carry no person's name	per-person login over OIDC; account names carry the person (12.7)
A standing credential	that AppRole's secret_id never expires	removed by the same OIDC login (12.7)
Guardrails on writes	none — SQL Lab runs what is submitted	UPDATE / DELETE without WHERE and DDL refused (12.7)
Approval of the statement	only the write permission is approved, once	open decision: accept as a stated risk, or put a review tool in front of writes (12.7)
Backup before a write	none	same open decision

Superset therefore stays both the read front door of the data platform (item 27) and, for Oracle, the place engineers make changes — with the write path held to the rules above.

Target flow

engineer ─OIDC─▶ Superset ─OIDC, per person─▶ Vault ─▶ one-hour Oracle account
                   │                                    read or write, per the permission applied for
                   │  write path: no WHERE-less UPDATE / DELETE, no DDL
                   │  per-statement approval + backup: open decision (review tool or stated risk)
                   ▼
               Oracle primary ──redo──▶ DataGuard standby
                   │
audit log: Superset query log · Vault audit · Oracle Unified Auditing (independent)

• People never hold the database password, and the account they act through lasts an hour.
• Schema changes are not data changes. DDL goes through the schema migrations of 6.2.
• Emergencies have a path, and it is recorded. Urgent fixes go through Warpgate (item 13) on a short-lived credential with the session recorded, and are reviewed afterwards.

What changes, and when

12.6 — contain 阿諾 now

No new tool; controls on the one that exists, so the risk shrinks before the replacement lands.

1. The baseline above published and re-measured monthly from 阿諾's own log.
2. A request number mandatory for every write.
3. Write permission limited to named people per database; everyone else read-only; leavers removed.
4. UPDATE and DELETE without WHERE refused.
5. Oracle Unified Auditing on 阿諾's database account, as a check independent of the tool's log.
6. Reads move off 阿諾 to Superset's read account as soon as it is open to engineers.

12.7 — replace 阿諾

Waits for dynamic database credentials (12.2), whose Oracle part is already live.

1. Superset as the one entry for Oracle, reading and writing, with OIDC login.
2. Separate read and write accounts; write permission approved by a named approver — the data owner, plus a DBA for high-impact changes — with the reason recorded. Recorded now, on the Backstage flow once 12.5 lands.
3. Per-person Vault login over OIDC, replacing the AppRole and its never-expiring secret.
4. Guardrails on the write path.
5. The open decision written down: per-statement approval and backup before execution — a stated, accepted risk, or a review tool (for example Bytebase or Archery) in front of writes.
6. Superset's query log, Vault's audit and Oracle Unified Auditing in the audit log.
7. The Warpgate emergency path.
8. 阿諾 retired — its write path closed first, the tool removed after, its log kept as history.

Where it connects

Item	Relationship
12.2 · Dynamic database credentials	The one-hour Oracle accounts Superset uses — already live; read / write split and merge to main still open.
12.5 · Backstage request and approval	Where the write-permission application moves once it exists.
13 · Zero-Trust Network Access	Warpgate carries the recorded emergency path.
6.2 · Schema migrations as code	Where DDL goes instead.
22.3 · Backstage request flow	What 12.5 builds on.
30.5 · No new direct grants	Applications lose standing database access; people lose it here.
27 · Data Platform	Superset's other role: the read and analysis front door.
Audit log	Receives the statement, its approval and its effect.

Back to Architecture · the direction is roadmap item 12.