04 · 零信任安全與自動化治理
此主題 roadmap 項目的里程碑
截至 2026-10-22 · 今天
甘特圖
里程碑
| # | 里程碑 | 開始日 | 目標日 | 狀態 | 等待 | 團隊 | Epic | 推導 |
|---|---|---|---|---|---|---|---|---|
| 12 · 動態密鑰引擎(Vault) | ||||||||
| 12.1 | Vault 具備高可用與稽核輸出，且不留長效 root token | 2026-08-03 | 2026-11-27 | 進行中 | — | SRE | — | — |
| 12.2 | 資料庫憑證改為動態核發 | 2026-09-24 | 2027-01-29 | 進行中 | 12.1 | SRE | — | 等待 12.1 |
| 12.3 | 應用程式 secrets 自設定檔收攏至 Vault | — | 2027-09-10 | 規劃中 | 12.2 | SRE | — | 等待 12.2 |
| 12.4 | SSH 憑證短效化，逐次連線核發 | — | 2028-01-14 | 規劃中 | 12.3 | SRE | — | 等待 12.3 |
| 12.5 | Backstage 承載申請與核准，Vault 授予但不顯示內容 | — | 2028-05-19 | 規劃中 | 12.3, 22.3 | SRE | — | 等待 12.3, 22.3 |
| 12.6 | 阿諾先行控管 —— 在現有工具上的暫時措施 | 2026-10-12 | 2027-03-21 | 規劃中 | — | SRE | — | — |
| 12.7 | Oracle 變更改走 Superset 與個人 Vault 帳號；阿諾退場 | — | 2027-09-10 | 規劃中 | 12.2 | SRE | — | 等待 12.2 |
| 13 · 零信任網路存取(NetBird) | ||||||||
| 13.1 | NetBird 控制平面自建、高可用，且由程式碼建置 | 2026-09-01 | 2026-12-18 | 進行中 | — | SRE | — | — |
| 13.2 | 可達性由政策群組與裝置狀態決定，而非所處網段 | — | 2027-07-16 | 規劃中 | 13.1 | SRE | — | 等待 13.1 |
| 13.3 | 所有存取皆須經 NetBird;需要中介的服務再由 Warpgate 承接 | — | 2028-03-10 | 規劃中 | 12.4, 13.2 | SRE | — | 等待 12.4, 13.2 |
| 13.4 | 站點、伺服器與人員接入 NetBird overlay | — | 2028-07-14 | 規劃中 | 13.3 | SRE | — | 等待 13.3 |
細節
12.1Vault 具備高可用與稽核輸出，且不留長效 root token2026-11-27進行中 · 1/4
- Vault 已部署並服務首批應用程式負責人 · Charles這是起點,不是里程碑 — 後面幾項才是讓「把其他所有憑證都放到它後面」這件事安全的原因。
- 封存、解封與復原經實際演練，而非僅完成設定負責人 · TBD這個項目裡的每一個憑證最後都在 Vault 後面,所以一個沒人演練過的解封,就是一次沒有回頭路的故障。
- 登入走 Zitadel OIDC;不留長效 root token負責人 · TBD壽命長過一次連線的 root token,正是這個項目要消滅的那種憑證 — 而且要從守著引擎本身的那一個開始。
- 稽核日誌架構已把 Vault(ssh / db)列為事件來源;這裡是讓那件事從圖上變成事實的地方。
12.2資料庫憑證改為動態核發2027-01-29進行中 · 2/8
- 各資料庫接上 secrets engine，TTL 短到有意義負責人 · TBD一年的 TTL 只是多繞幾步的靜態密碼;長度才決定外洩的憑證是一次事故,還是什麼都沒發生。
- 應用程式的靜態資料庫密碼確實退場，而非僅輪換負責人 · TBD輪換保留了原有機制,只換來一個週期。讓靜態路徑退場,動態的那條才會是唯一的一條。
- 項目 06 佈建的資料庫自始即經由 Vault 核發負責人 · TBD一個帶著靜態密碼誕生的資料庫,之後還要再清一次;在佈建當下就接起來,比事後再掃一遍便宜。
- 可依身分撤銷存取，且撤銷經實際測試負責人 · TBD
- Oracle 經由 Vault 的 database plugin 核發 —— Instant Client 內建於 Vault 映像，plugin 完成註冊負責人 · TBDOracle 的 plugin 並未內建在 Vault 中，且需要 Oracle client 函式庫一起部署，所以 Vault 的映像必須帶上它們。12.7 的每一次正式環境變更，都使用經由這條路徑核發的憑證。
- 主庫與其 DataGuard 備庫皆已涵蓋負責人 · TBD帳號只在主庫建立與刪除；備庫經由 redo 同步取得，殘留的 session 由 profile 在 15 分鐘內斷開。已於 2026-09-30 連同核發、到期與回收連線中帳號一併驗證。
- 依 DBA 提供的 RO 與 RW role 拆成讀、寫兩種 Oracle 帳號，TTL 一小時且不可續約負責人 · TBD
- Vault 的 Oracle 設定合併回 IaC repo 的 main，讓 main 恢復可套用負責人 · TBD在那之前，線上設定只存在於分支上，main 是舊版；從 main 套用會把它還原掉。
12.3應用程式 secrets 自設定檔收攏至 Vault2027-09-10規劃中 · 0/4
- 盤點 secrets 目前的所在:設定檔、映像、CI 變數負責人 · TBD
- 應用程式於執行期讀取 secrets，而非建置時寫入負責人 · TBD寫進映像的 secret,會隨著那個映像散布到每一個 registry,而且要換它就得重新建置。
- CI 取得短效 token，而非持有常設憑證負責人 · TBD
- 以項目 21 的密鑰掃描器作為獨立驗證負責人 · TBD自己宣稱 secrets 清乾淨了,比不上一個本來就在找它們的掃描器從此找不到。
12.4SSH 憑證短效化，逐次連線核發2028-01-14規劃中 · 0/4
- Vault 內建 SSH CA，核發主機與使用者憑證負責人 · TBD
- 憑證承載連線後，自主機移除靜態金鑰負責人 · TBD1.2 把共用金鑰換成個人金鑰,但它們的壽命仍然長過一次連線;這一步才終結這件事。
- 記錄以此為目標的里程碑，以及為何未建立依賴負責人 · TBD1.2(2027-03-12)與 5.2(2027-01-01)都寫明最終由 Vault 核發,但兩者的期限都遠早於本里程碑 — 議定的順序把 SSH 排在第三。那樣的邊會指向未來,因此在那兩條里程碑裡,這個目標維持為文字。
12.5Backstage 承載申請與核准，Vault 授予但不顯示內容2028-05-19規劃中 · 0/5
- 申請與核准是 Backstage 上的流程，而非工單或聊天訊息負責人 · TBD申請必須先是一筆有結構的紀錄,才談得上一致地核准,或根本能被稽核。22.3 負責建立那個流程,本里程碑相依於它;項目 12 則決定核准可以交出什麼。
- 核准者具名，並記錄核准理由負責人 · TBD沒有具名的核准就是橡皮圖章;那個名字才讓這筆紀錄有保存的價值。
- 核准是將 Vault policy 綁定至申請者身分並設定到期，而非複製一份 secret負責人 · TBD沿用 12.1 建立的同一個 Zitadel 身分。若核准交出的是複製的值,那不論原意如何,每一次核准都是永久的,因為複製品沒有到期這回事 — 這正是「核准一段期間」與「核准到永遠」的分界。
- Backstage 顯示 secret 的位置，絕不顯示其內容負責人 · TBD在入口網站上顯示過的值,就存在於瀏覽器歷史、截圖,以及讀者把它貼過去的任何地方。這是「授權存取」與「直接發放」的分界,不寫下來就會被當成使用便利性讓步掉。
- 稽核日誌架構已把 Backstage 與 Vault 並列為 M2M 來源;一次申請與它所觸發的核發,應該能被當成同一件事讀出來,而不是事後人工拼接。
12.6阿諾先行控管 —— 在現有工具上的暫時措施2027-03-21規劃中 · 0/6
- 以阿諾自身的執行紀錄公布基準，並每月重新量測負責人 · TBD截至 2026-10-08 的 12 個月：23,290 次執行，其中 85.7% 為寫入，由 73 人在 7 個 Oracle 資料庫上執行；41% 的寫入沒有申請單號，13 筆 UPDATE／DELETE 沒有 WHERE。每月重新量測，才看得出下列措施是否真的有效。
- 每一次寫入都必須附申請單號 —— 沒有單號的寫入由阿諾拒絕負責人 · TBD
- 寫入權限僅限各資料庫具名人員，其餘一律唯讀；離職人員帳號移除負責人 · TBD
- 拒絕沒有 WHERE 的 UPDATE 與 DELETE負責人 · TBD
- 以 Oracle Unified Auditing 記錄阿諾資料庫帳號的 DML負責人 · TBD這是與工具自身紀錄無關的獨立檢查：工具自己寫的紀錄，看不出它漏記了什麼。
- Superset 的唯讀帳號一開放給工程師，讀取需求就先移出阿諾負責人 · TBD
12.7Oracle 變更改走 Superset 與個人 Vault 帳號；阿諾退場2027-09-10規劃中 · 0/8
- Superset 成為 Oracle 讀寫的唯一入口，以 OIDC 登入負責人 · TBD
- 讀與寫為不同的資料庫帳號；工程師依所申請的權限取得對應帳號，寫入權限由具名核准者核准並記錄理由負責人 · TBD核准者為資料擁有者，高影響變更另加 DBA。申請現在就留下紀錄，12.5 上線後改走 Backstage 流程。
- Superset 以個人身分經 OIDC 登入 Vault，取代 secret_id 永不過期的 AppRole；帳號名稱帶有本人身分負責人 · TBD永不過期的 secret_id 就是工具手上的一組常駐憑證 —— 正是項目 12 要消除的東西。改成個人登入後，Oracle 自己的稽核記下的是工程師本人，而不是一個亂數帳號。
- 寫入路徑的防護 —— 拒絕沒有 WHERE 的 UPDATE／DELETE 與 DDL負責人 · TBDDDL 走 6.2 的 schema migration。
- 記錄逐段 SQL 核准與執行前備份的決定 —— 明確接受為風險，或在寫入前加一層審查工具負責人 · TBDSuperset 兩者都不提供。不寫明這個缺口，改用 Superset 就會被讀成已經補上；接受風險或加工具都可以，沒有記錄的決定則不行。
- 緊急變更經 Warpgate（13）並錄下連線過程，事後審查負責人 · TBD
- 阿諾退場 —— 先關閉寫入路徑，再移除工具；執行紀錄保留為歷史資料負責人 · TBD
13.1NetBird 控制平面自建、高可用，且由程式碼建置2026-12-18進行中 · 1/4
- 於 develop 環境完成 NetBird 試行負責人 · Charles
- 控制平面自建並具高可用性負責人 · TBD自建把「依賴別人的可用性」換成「依賴自己的」;高可用性才讓這是一次獲得,而不只是換一個對象。
- 每個 peer 帶有來自 Zitadel SSO 的身分負責人 · TBD
- 控制平面本身由程式碼佈建，而非手工建置負責人 · TBD它會變成通往其他一切的入口 — 手工建的那一台,正是你最需要重建它時進不去的那一台。
13.2可達性由政策群組與裝置狀態決定，而非所處網段2027-07-16規劃中 · 0/4
- 政策群組以程式碼表達，並比照一般變更審閱負責人 · TBD
- 連線時檢查裝置狀態負責人 · TBD
- 身處辦公室網段本身不再授予任何權限負責人 · TBD這句話才是零信任與 VPN 的分界。在所處位置本身什麼都不給之前,這個 overlay 只是一條比較長的網路線。
- 例外是具名且訂有複查日期的條目負責人 · TBD
13.3所有存取皆須經 NetBird;需要中介的服務再由 Warpgate 承接2028-03-10規劃中 · 0/5
- 除 1.3 封存的 break-glass 外，沒有任何入口不是從 NetBird 開始負責人 · TBD這才是讓本里程碑成立的性質,而且它屬於 NetBird。1.2 建立了堡壘路徑;這裡是把 NetBird 擺到它前面,而不是移除它 — 而這個主張要到其他進入方式都關上才成立。
- 明訂哪些服務需要經中介負責人 · TBD「某些服務」不是規格。沒有寫下來的規則,這個集合就會變成每個服務上線當下方便什麼就是什麼,而且例外無法複查 — 因為沒有東西可以拿來對照。
- 為那些服務建置 Warpgate，且僅能經由 NetBird 抵達負責人 · TBD多數服務在接上 NetBird 之後就直接連。Warpgate 是加給那些「連線本身必須被記錄」或「憑證不該落到客戶端」的服務的額外一層。
- 經中介的連線由 12.4 的 SSH 憑證承載負責人 · TBD這一層與穿過它的短效憑證要一起到 — 這正是 12.4 排在本里程碑之前而非之後的原因。
13.4站點、伺服器與人員接入 NetBird overlay2028-07-14規劃中 · 0/4
- 站點間與伺服器連線由 NetBird 承載負責人 · TBD這些流量目前不在任何 overlay 上,所以並沒有東西要遷移 — 而是這些路徑第一次帶有身分,而不只是位址。
- 人員存取走 NetBird，套用相同的身分與裝置狀態規則負責人 · TBD
- 兩個 overlay 從來沒有重疊,所以 NetBird 既不併入 Tailscale,也不使它失效。每個站點都是經由它把 corp.internal 轉送到自己的 Route 53 inbound endpoint — 把它當成順手清理掉,三個站點的內部解析會一起斷。
- 讓下一個發現 Tailscale 相依的人讀到它為什麼在那裡,而不是把它拆掉。