正式環境資料變更

每一次變更都用一小時帳號，每一段 SQL 都留下紀錄 · 路線圖項目 12 · 負責團隊：SRE

有些正式環境的資料需要人工修正：卡在錯誤狀態的退款、不該套用的罰點、代碼表要多一筆。目前這些修改都經由阿諾 —— 一個直接連線到正式環境 Oracle 資料庫的內部工具。本頁記錄這個工具做了什麼、沒做什麼，取代它的 Superset＋Vault 設計，以及這個設計還沒涵蓋的部分。

這項工作是零信任安全里程碑上的 12.6（先控管阿諾）與 12.7（取代阿諾）。里程碑日期為初稿，之後會調整。

現況

只要能登入阿諾，就能對它連線的資料庫執行任何 SQL，包括寫入。執行前沒有核准步驟，也沒有任何 SQL 審查。唯一的控管是阿諾自己的執行紀錄：誰、在什麼時候、對哪個資料庫執行了哪段 SQL，以及一個可填可不填的申請單號。

依這份紀錄量測，截至 2026-10-08 的 12 個月：


執行次數	23,290，其中 19,949 次為寫入（85.7%） —— UPDATE 13,095 · INSERT 5,554 · DELETE 1,300
使用人數	73 人，分布在 7 個 Oracle 資料庫
未填申請單號的寫入	8,180（41%）
沒有 WHERE 的 UPDATE／DELETE	13
非上班時段的寫入（週末或 19:00–09:00）	2,609（13%）
一次執行含多個 statement	2,185（11%）
每月量	約 1,000–3,000 次；高峰是 2026 年 6 月的 3,064 次，在 618 之前

工具本身能用，使用量也說明需求是真的。缺的是從「我要改這一列」到「這一列被改掉」之間的一切：沒有人檢查這段 SQL，沒有人核准它，而資料庫永遠只看得到阿諾。

Superset＋Vault 的設計

取代方案是 Superset 搭配 Vault，核心部分已經可以運作（2026-09-30 驗證）：

工程師登入 Superset，選擇資料庫與讀或寫。Superset 向 Vault 取得一組一小時有效的動態 Oracle 帳號，代工程師連線。工程師從頭到尾不持有資料庫密碼。
一小時到期時，Vault 呼叫 DBA 提供的 function，結束該帳號的 session 並刪除帳號。DataGuard 備庫經 redo 同步取得同一批帳號，因此不需要自己的 Vault 連線；殘留的 session 在 15 分鐘內被斷開。
**讀與寫是不同的資料庫帳號。**工程師拿到哪一個，依他一開始申請的權限決定。

這個設計還沒做到的部分 —— 也就是 12.7 要處理的：

缺口	現況	在哪裡補上
追到個人	Superset 以 AppRole 存取 Vault，帳號不帶任何人的名字	以 OIDC 個人身分登入；帳號名稱帶有本人（12.7）
常駐憑證	這個 AppRole 的 secret_id 永不過期	同一個 OIDC 登入一併移除（12.7）
寫入防護	沒有 —— SQL Lab 送出什麼就執行什麼	拒絕沒有 WHERE 的 UPDATE／DELETE 與 DDL（12.7）
核准這一段 SQL	只有寫入權限在申請時核准一次	待決定：明確接受為風險，或在寫入前加一層審查工具（12.7）
寫入前備份	沒有	同上的待決定事項

因此 Superset 同時是資料平台（項目 27）的讀取入口，也是工程師修改 Oracle 資料的地方 —— 寫入路徑則受上述規則約束。

目標流程

工程師 ─OIDC─▶ Superset ─OIDC，個人身分─▶ Vault ─▶ 一小時有效的 Oracle 帳號
                 │                                   讀或寫，依所申請的權限
                 │  寫入路徑：拒絕無 WHERE 的 UPDATE／DELETE、拒絕 DDL
                 │  逐段核准＋備份：待決定（審查工具或明確接受風險）
                 ▼
             Oracle 主庫 ──redo──▶ DataGuard 備庫
                 │
稽核日誌：Superset 查詢紀錄 · Vault 稽核 · Oracle Unified Auditing（獨立檢查）

人員永遠不持有資料庫密碼，所使用的帳號一小時就失效。
**結構變更不是資料變更。**DDL 走 6.2 的 schema migration。
**緊急狀況有路可走，而且會被記錄。**緊急修正經 Warpgate（項目 13），以短效憑證連線並錄下過程，事後審查。

要改什麼、何時改

12.6 —— 先控管阿諾

不需要新工具；在現有工具上加控管，讓風險在替代方案上線前先縮小。

公布上方的基準，並每月以阿諾自身的紀錄重新量測。
每一次寫入都必須附申請單號。
寫入權限僅限各資料庫的具名人員，其餘一律唯讀；移除離職人員帳號。
拒絕沒有 WHERE 的 UPDATE 與 DELETE。
以 Oracle Unified Auditing 記錄阿諾資料庫帳號的操作，作為與工具紀錄無關的獨立檢查。
Superset 的唯讀帳號一開放給工程師，讀取需求就先移出阿諾。

12.7 —— 取代阿諾

等待動態資料庫憑證（12.2）—— 其中 Oracle 的部分已經上線。

Superset 成為 Oracle 讀寫的唯一入口，以 OIDC 登入。
讀寫帳號分開；寫入權限由具名核准者核准 —— 資料擁有者，高影響變更另加 DBA —— 並記錄理由。現在先留下紀錄，12.5 上線後改走 Backstage 流程。
以 OIDC 個人身分登入 Vault，取代 AppRole 與它永不過期的 secret。
寫入路徑的防護。
**寫下待決定事項的結論：**逐段 SQL 核准與執行前備份 —— 明確接受為風險，或在寫入前加一層審查工具（例如 Bytebase 或 Archery）。
Superset 查詢紀錄、Vault 稽核與 Oracle Unified Auditing 送入稽核日誌。
Warpgate 緊急路徑。
阿諾退場 —— 先關閉寫入路徑，再移除工具，執行紀錄保留為歷史資料。

與其他項目的關係

項目	關係
12.2 · 資料庫憑證動態核發	Superset 所用的一小時 Oracle 帳號 —— 已上線；讀寫拆分與合回 main 尚未完成。
12.5 · Backstage 申請與核准	寫入權限申請日後移入的流程。
13 · 零信任網路存取	Warpgate 承載有錄影的緊急路徑。
6.2 · Schema migration 程式碼化	DDL 改走這裡。
22.3 · Backstage 申請流程	12.5 的基礎。
30.5 · 不再核發新的直連授權	應用程式失去常駐的資料庫存取；人員則是在這裡失去。
27 · 資料平台	Superset 的另一個角色：讀取與分析入口。
稽核日誌	接收 SQL、它的核准與它的影響。

回到架構 · 方向見路線圖項目 12。

現況​

Superset＋Vault 的設計​

目標流程​

要改什麼、何時改​

12.6 —— 先控管阿諾​

12.7 —— 取代阿諾​

與其他項目的關係​

現況