團隊機密治理（Secrets Governance）概念 PRD

這是一份概念型 PRD，不含實作與畫面。 目的是把「問題、範圍、必要能力門檻、驗收標準、營運流程」定清楚， 讓 RD 在不被預設答案綁架的前提下構思技術方案。 工具選型、部署拓撲與存取通道全數由 RD 評估後拍板；本文件只提供問題定義、必要能力門檻與比較框架。 PM 的個人傾向收斂在 §8.3 一個明確標示的「PM 觀點（非決議）」框內，RD 可逕行忽略。

1. 文件資訊

• 文件類型：概念需求規格書（Concept PRD／不含畫面與實作）
• 適用對象：RD（主要收件人）、CEO/PM、行政、未來的資安稽核
• 最後更新：2026/09/01
• 版本：1.2.0
• 對應 Storybook：不適用（本 PRD 不產畫面，見 ADR-010）
• 建立日期：2026/09/01
• PM 單號：pm_55
• 狀態：待 RD 評估選型；§13.3 問題清單中的待決項需回填後才進入實作

1.1 修訂紀錄

2. 開發進度與設計來源

開發進度

• RD 評估報告：[TBD — 見 §14 交付清單]
• 選型拍板：[TBD]
• 導入 PR／設定變更：[TBD]

設計來源

• Figma 連結：不適用（無畫面）
• 既有畫面：不適用

事實基礎（實查證據台帳）

本表是本 PRD 的證據台帳（gen-prd Rule 33）。 凡斷言「既有狀態如何」的句子，都必須在此有一列；沒有列的斷言，該句自帶 （推論，未實查）。

Repo 基準（Rule 34 preflight）：

本 PRD 未讀取 W101-Web／W101-TalentSearchHub／W101-Admin-Web／W101-AMS／wport-cli。 因此所有關於「後端／前端 repo 內機密如何存放」的敘述，一律標記 （推論，未實查）， 並列為 RD 評估作業第一項（§14 D-1 盤點）。這是刻意的：盤點應由掌握部署的人做，不該由 PRD 猜。

斷言 → 證據：

⚠️ 上表第 1–4 列合起來說明的事：這不是「將來可能發生」的風險，是已經發生、且持續了 5 個月的事實。 private repo 把嚴重度從「災難」降到「中度」，但沒有降到零——見 §3.1 的爆炸半徑分析。

3. 摘要

3.1 問題陳述

現況：公司的憑證（API key、資料庫連線、SaaS 帳密、共用帳號、憑證檔）散落在至少五種載體：

核心痛點（依嚴重度排序）：

1. 無法撤銷——成員離職或裝置遺失時，公司不知道他看過哪些憑證，因此不知道該輪替什麼。這是最致命的：沒有清冊，就沒有事故應變。
2. 無稽核軌跡——沒有「誰在何時讀了哪一筆」的紀錄。事故發生時無法界定影響範圍。
3. 明文靜態儲存——Google Sheet／Obsidian 的內容一旦被讀到就是可直接使用的憑證，沒有第二道防線。
4. 爆炸半徑外溢——單一 Google 帳號被接管，等於整份憑證表外洩；單一 laptop 遺失，等於 Obsidian vault 外洩。
5. 無輪替節奏——沒人知道哪一把 key 用了多久、還有沒有在用、能不能砍。

一個重要的對照：同一個 repo 裡，prd-web 的 Cloudflare 部署憑證是正確存放於 GitHub Actions Secrets 的（§2 台帳）。 也就是說團隊並非不會做，而是沒有一致的預設路徑——有現成機制的地方就做對了，沒有的地方就落回 .env 與試算表。 本案要提供的正是那條「預設就對」的路徑。

爆炸半徑範例（§2 台帳第 1 列的實例）：prd repo 的 CODA_API_TOKEN 是 Coda 的 user-scoped token——它以「該使用者」的身分行動，可存取該使用者能存取的所有 doc，而非僅限本 repo 用到的那一份。它現在存在於：每一台 clone 過 prd 的機器、每一份 git 備份、每一個讀過該 repo 的 AI agent context、以及 GitHub 的伺服器。private repo 保護的是「外部陌生人讀不到」，不保護「內部任一成員的 GitHub 帳號被接管」，也不保護「離職者的舊 clone」。

3.2 為什麼現在做（策略理由）

不是資安潔癖，有三條具體理由：

1. 我們是個資的受託人，不只是自己的。W101 平台上有僑外生的護照、居留證、工作許可、學歷等高敏感個資。一枚外洩的後端憑證＝個資法層級的資料外洩事件，不是「重設密碼」等級的麻煩。這條風險與公司規模無關，與資料性質有關。
2. 企業客戶會問。年費 94,080 TWD 的企業方案，客戶端（Wistron／Compal／Delta 這類）採購流程常帶資安問卷：憑證管理、存取控制、稽核保留期、離職流程。現在沒有答案；有了之後這是成交加速器，不只是成本。與 BR-039（API 通道寫入須標記來源，供稽核）是同一套治理邏輯的兩端——BR-039 管「客戶動我們的資料要留痕」，本案管「我們自己的鑰匙要留痕」。
3. AI agent 已經是團隊成員。團隊日常用 Claude Code／MCP／CLI 讀 repo 與 Obsidian。明文機密放在 agent 讀得到的地方，等於每天都在把憑證送進外部模型的 context。這是傳統資安清單沒有的新風險面，而我們的工作流剛好把它放大到最大。這一條讓「以後再說」不成立。

3.3 SaaS Benchmark（候選方案概覽）

定價為 2026 年 9 月網路公開資訊，採購前必須複查官方定價頁（各家 2026 年初普遍調價）。 本表用途是「界定選項空間」，不是選型結論。選型見 §8 與 ADR-003。

Tier H — 人用憑證（Password Manager）

Tier M — 機器用機密（Secrets Manager）

部署與存取控制

3.3.1 費用結構比較（供 RD 權衡，非約束）

預算不設限（ADR-017）。本節只是把「免費」這個詞拆開——因為它在這個領域特別容易誤導。 成本與方案由 RD 於 §14 D-4 一併提出。

「免費」有三種，只有兩種是真的：

第三類是最容易踩到的——特別是 GitHub push protection，常被誤以為全面免費，實際上只有公開 repo 免費。

7 人團隊年費試算（依 §3.3 定價概算，匯率約 32 TWD/USD；採購前須複查官方定價頁）：

兩個值得注意的數字：

1. 1Password Teams Starter 的定額結構讓 7 人的付費門檻遠低於直覺（約 NT$7,700／年， 對照公司月 burn 470,000 TWD 約為 0.14%）。「付費 vs 免費」在這個規模下的差距， 可能小於「維運工時」的差距——這正是 RD 該權衡的地方。
2. Infisical 以 identity 計價，而機器身分會隨 CI 與服務數量成長。 Tier M 若走這條，成本曲線與 Tier H 完全不同，需分開估。

3.4 範圍界定### 3.4 範圍界定

包含範圍（本 PRD 要定義的）

1. 機密的分類與分級架構（哪些算 P0／P1／P2）
2. 不論選哪個工具都必須滿足的必要能力門檻（§7）
3. 部署拓撲選項與各自的誠實風險（§8.2）
4. 生命週期營運流程：入職、離職、輪替、事故應變、破窗（§10）
5. 遷移與舊副本銷毀策略（§13.0）——這是本案的重心，不是附錄
6. 防回歸機制（避免半年後又回到 Google Sheet）
7. 驗收標準與成功指標（§3.6）

排除範圍（明確不做）

1. ❌ 不指定最終工具——選型是 RD 的評估產出（ADR-005）
2. ❌ 不含任何畫面／Storybook／mockup（ADR-010）
3. ❌ 不含實作細節：不定義部署腳本、網路拓撲圖、防火牆規則、DB schema
4. ❌ 不自行開發保管庫（ADR-011）
5. ❌ 不涵蓋 W101 平台發給客戶的 Enterprise API 金鑰——那是 pm_37 的產品功能，兩者是「我們保管自己的鑰匙」vs「我們發鑰匙給客戶」，治理紀律相通但系統不同。本案僅要求：pm_37 用來簽發／驗證金鑰的主密鑰（signing key）本身屬於本案的 P0 資產
6. ❌ 不涵蓋端點防護（EDR／磁碟加密／MDM）——相鄰但另案
7. ❌ 不涵蓋個人私人帳號——公司只管公司資產（ADR-012）
8. ❌ 不做 SOC 2／ISO 27001 正式認證——本案是打底，不是送審

3.5 明確的非目標（避免 RD 誤解方向）

• 本案不是「裝一套保管庫就結束」。工具是最容易的一段；難的是 §13.0 的清查與輪替。
• 本案不是要求 RD 蓋一座 Vault 叢集。過度工程會導致沒人用，而沒人用的保管庫比沒有保管庫更危險（會產生「我們已經處理了」的錯覺）。
• 本案不追求零風險，追求的是「風險可見、可撤銷、可稽核」。

3.6 成功條件

指標 5 是最容易被忽略、也最能預測失敗的一項。若日常取用比複製 Google Sheet 麻煩，人一定會繞道，而繞道發生時不會有人回報。因此 §7 把「CLI／自動注入」列為必要能力，不是加分項。

4. 商業規則對齊

4.1 本功能使用到的業務規則

4.2 新規則提案

不提案新增 BR。 理由：business-rules.md 的定位是產品商業規則（平台上的使用者行為與資料約束），本案是內部營運治理，寫進去會稀釋該文件的定位。內部政策應以獨立的資安政策文件承載，由本 PRD 拍板後另行產出（§14 D-6）。

4.3 衝突檢查

已比對 business-rules.md（BR-001–BR-041）：無衝突。本案不改動任何產品行為、資料模型或使用者流程。

5. 資料實體與語意（What，非 How）

本節描述「必須被追蹤的資訊」與「為什麼」，不規定欄位名、schema 或儲存方式（Rule 31）。 多數工具會自帶其中大部分；缺什麼、怎麼補，是 RD 選型時的評估項。

5.1 實體列表

5.2 各實體必須被追蹤的資訊（語意層）

SecretRecord

• 機密本體（必須加密靜態儲存，且伺服器管理者不可讀明文——見 §7 C-1）
• 分級：P0 / P1 / P2（定義見 §5.3）
• 擁有者：必須是具名的人，不得為「RD 部門」這類集合。無主的機密不會被輪替
• 用途說明：這把鑰匙開什麼、砍掉會壞掉什麼（輪替時的第一個問題）
• 生效範圍：正式／測試／開發
• 建立時間、最後輪替時間、下次應輪替時間
• 曾外洩註記：是否曾存在於 Google Sheet／git／聊天軟體。這一欄決定它在遷移時是「搬」還是「換」
• 消費端清單：哪些服務／CI job 正在用它（輪替時要同步更新的對象；漏掉一個就是服務中斷）

SecretInventory

• 需能回答三個問題：(a) 我們總共有幾把鑰匙？(b) 某人能看到哪些？(c) 某把鑰匙誰在用？
• 必須涵蓋不在保管庫裡的機密（例如託管在雲端平台原生 secret store 的）。清冊的價值在完整，不在集中

AccessGrant

• 授予對象（人或機器身分）、範圍、授予者、授予時間、到期時間（若為臨時）
• 臨時授權必須可設到期——承包商與外部合作方的存取若無到期日，實務上等於永久

AuditEvent

• 至少涵蓋：讀取、建立、修改、刪除、分享、授權變更、匯出、登入失敗
• 每筆需有：時間、身分、目標機密、來源（IP／裝置／CLI）、結果
• 保留期見 §13.2 常數表 AUDIT_RETENTION

RotationRecord

• 輪替時間、執行者、原因（定期／離職／疑似外洩／裝置遺失）、涉及的消費端是否已全部更新
• 「已更新全部消費端」是必填的完成條件，否則輪替只完成一半，會表現為隨機的服務中斷

Identity

• 人：一人一帳號，禁止共用登入帳號（否則稽核日誌無意義）
• 機器：CI／部署／runtime 各自獨立身分，可個別撤銷

BreakGlassKit

• 復原所需的憑據組合（主密碼／Secret Key／復原碼／解封金鑰）
• 保管形式與存放位置：實體、離線、雙人（見 ADR-007）
• 最後驗證日期——沒驗證過的破窗包等於不存在

5.3 分級定義（常數，見 §13.2 常數表）

分級的用途是排優先序，不是製造官僚。導入時只要求 P0 在第一週完成，P1／P2 可分批。

6. 介面需求（能力層，非畫面規格）

本 PRD 不含畫面（ADR-010）。工具本身會提供 UI；本節只描述必須存在的能力， 供 RD 在試用候選工具時當作勾稽清單。

7. 必要能力門檻（不可談判）

這是本 PRD 對 RD 唯一的硬性約束。 工具與拓撲隨你選，但下列每一條都必須被滿足； 任一條不滿足的方案直接出局，不需進入成本比較。

C-10 沒有客觀判定法，只有一個誠實的問題要回答：「這台機器出現 critical CVE 的那個週五晚上，誰會去升級？」 答不出具體姓名，這條就是不滿足。

8. 部署拓撲選項（RD 拍板）

8.1 兩層分治（本 PRD 的基本架構主張）

人用憑證與機器用機密是兩個不同的問題，硬塞進同一個工具通常兩邊都不好用（ADR-001）：

Tier M 的優先策略是「不要有長期憑證」（ADR-006）：能用 OIDC 聯邦換短期 token 的路徑（例：GitHub Actions → 雲端供應商），優先改用聯邦，不要把長期 key 存進保管庫再自我感覺良好。保管庫是「無法聯邦化的那些」的歸宿，不是第一選擇。這條的風險削減幅度大於任何工具選型。

8.2 拓撲候選與誠實評估

T1 — 廠商雲（零知識 E2EE）

• 代表：1Password Business、Bitwarden 雲、Passbolt Cloud
• 優點：可用性最高（不受辦公室電力／ISP 影響）；修補由廠商負責；有正式稽核報告可回答客戶問卷；導入最快
• 缺點：訂閱費；資料在境外；依賴廠商存續
• 關於「雲端不安全」的反直覺事實：零知識架構下，廠商被入侵不等於保管庫被入侵。1Password 在 2023 年 Okta 事件中內部租戶遭入侵，調查結論為使用者保管庫資料未被存取——因為 Secret Key 只存在使用者裝置上，從未送到伺服器。這是「多一道防線」，不是行銷話術。

T2 — 自架於辦公室 server（Eric 的原始構想）

原始構想把「機器放辦公室」與「對外走 VPN」綁在一起。這兩者是可以分開決定的—— 存取通道另有對照表見 §8.3；下列風險表中的第 1／5 項，主要來自「走自架 VPN」而非「放辦公室」。

• 優點：資料主權完整；無訂閱費；若 VPN 設定正確，對公網攻擊面接近零；對「東西在我看得到的地方」的心理需求最直接

• 誠實風險（這些不是否決理由，是 RD 必須有答案的問題）：

  #	風險	具體情境
  1	循環相依（bootstrap deadlock）	VPN 的憑證若存在只能透過 VPN 取得的保管庫裡，第一次設定新裝置或 VPN 壞掉時就完全鎖死。必須有明確的破解方案（見 §10.4 EC-2）
  2	辦公室即單點故障	停電、ISP 中斷、路由器故障、颱風、搬家 → 全員拿不到任何憑證。而災難當下正是最需要憑證的時刻（要登入雲端主控台救火）
  3	修補節奏	見 C-10。自架不是把風險消除，是把風險從「廠商的資安團隊」換成「我們的週五晚上」
  4	備份與異地	磁碟毀損 ＋ 備份未驗證 ＝ 全公司憑證歸零。備份本身也是 P0 資產，需異地且加密
  5	可用性摩擦導致繞道	出差、在家、週末要連 VPN 才拿得到密碼 → 有人會「先存一份在本機方便一點」。這會讓整個專案的效果歸零，而且不會有人回報
  6	硬體與維運的隱形成本	UPS、備援磁碟、監控、憑證續期、作業系統升級。名目上省下訂閱費，實際上換成人力

T3 — 自架於雲端 VPS ＋ Cloudflare Zero Trust

• 代表：Vaultwarden／Passbolt CE／Infisical 部署於 VPS，以 Cloudflare Tunnel ＋ Access 保護，不開防火牆孔
• 優點：保有自架的資料主權與零授權費；去掉辦公室 SPOF；可用性接近 T1；團隊既有技術棧已使用 Cloudflare（prd-web 以 Workers 部署，見 §2 台帳），Zero Trust 免費層涵蓋 50 人，邊際學習成本低
• 缺點：修補責任仍在我方（C-10 未解除）；資料仍在第三方機房（主權介於 T1 與 T2 之間）；多一層 Cloudflare 依賴
• 相對 T2 的關鍵差異：T3 保留了 T2 的幾乎全部優點，只換掉「機器放在辦公室」這一個決定，而那正是 T2 風險 1／2／5／6 的共同來源
• 成本註：付費 VPS 約 USD 5/月起（§3.3.1）。若考慮免費層 VPS，須注意閒置回收政策——保管庫的流量特徵正好長得像閒置，是特別糟的組合（EC-16）

T4 — 分層混合

• Tier H 與 Tier M 各自選最合適的承載方式；Tier M 以「OIDC 聯邦優先 ＋ 平台原生 secret store ＋ 統一清冊」承接
• 優點：各層用最合適的工具；導入可分階段；不需要一次到位
• 缺點：兩套系統，需要清冊把它們串成一個可稽核的整體（SecretInventory 的價值就在這裡）
• 註：T4 嚴格說是分層原則，不是與 T1／T2／T3 並列的部署地點選項——它的意思是「Tier H 與 Tier M 各自選 T1／T2／T3 之一」。§8.3 的對照表把兩者拆開比較

8.3 選型決策框架（交 RD；本 PRD 不拍板）

依 ADR-017，本 PRD 不指定拓撲、不指定工具、不設預算上限。 本節提供的是權衡用的對照表，讓 RD 的決策有依據、也讓半年後的人看得懂當初為什麼這樣選。

四種拓撲的一頁對照：

存取通道是可以與拓撲分開決定的一個維度——原始構想把「放辦公室」與「走 VPN」綁在一起，但兩者可拆：

依重視什麼來收斂：

PM 觀點（非決議，RD 可逕行忽略）

若要我押一個，我會押 T4 分層 ＋ Tier H 走 T1，理由是 §3.3.1 那張表裡的一個數字： 7 人用 1Password Teams Starter 約 NT$7,700／年，是月 burn 的 0.14%—— 而它換掉的是 C-10（誰在週五晚上升 CVE）這個沒有客觀判定法、失守時也不會有告警的風險。 這個交換在目前規模下我覺得划算。

若決定自架，我會把「放辦公室」與「走 VPN」分開看：前者合理，後者建議換成 Cloudflare Tunnel ＋ Access——免費、不必開防火牆孔，且剛好解掉原構想中最難補的 兩項風險（EC-2 循環相依、EC-8 可用性摩擦）。這是 ADR-016 的內容，狀態為 Proposed。

以上都不是決議。RD 推翻時只需在對應 ADR 補上理由，不需要說服我。

9. 交付 Map

• 本 PRD：doc/feature/pm_55/secrets-management-concept-prd.md
• Storybook：不適用（ADR-010）
• 後續文件：RD 評估報告 → 選型 ADR 回填 → 資安政策文件（§14 D-6）
• 對應 production 路由：無（非產品功能）

10. 流程圖（Lifecycle / Operations / Edge）

本節畫的是營運流程，不是畫面流程。這些流程與選哪個工具無關， 是 RD 選型時必須確認「這個工具做得到」的清單。

10.1 機密生命週期（主流程）

flowchart TD
    S1["產生新機密"] --> S2{"能否改用短期憑證<br/>OIDC 聯邦"}
    S2 -->|"可以"| S3["改用聯邦，不入庫<br/>僅在清冊登記來源"]
    S2 -->|"不行"| S4["入庫：設定分級、擁有者、用途、消費端"]
    S4 --> S5["授權：依最小權限授予"]
    S5 --> S6["使用：人由擴充取用 / 機器由 CLI 注入"]
    S6 --> S7{"觸發輪替"}
    S7 -->|"到期"| S8
    S7 -->|"成員離職"| S8
    S7 -->|"疑似外洩 / 裝置遺失"| S8
    S7 -->|"停用該服務"| S9["撤銷並自清冊除役"]
    S8["輪替子流程 SUB-ROT"] --> S6
    S3 --> S10["定期複檢：聯邦設定是否仍最小權限"]
    S10 --> S10
    S9 --> S11["確認舊值已失效，非僅刪除紀錄"]

10.2 輪替子流程（SUB-ROT，被 10.1 / 10.3 / 10.4 共用）

這段是整套機制中最容易做錯的地方：多數人以為輪替＝改密碼， 但漏掉任一消費端就是隨機的服務中斷，而中斷會出現在「換完之後的某一天」，很難歸因。

flowchart TD
    R1["自清冊取出該機密的消費端清單"] --> R2{"清單是否完整"}
    R2 -->|"不確定"| R3["先在非正式環境失效舊值<br/>觀察什麼壞掉，補完清單"]
    R3 --> R2
    R2 -->|"完整"| R4["產生新值"]
    R4 --> R5["逐一更新所有消費端"]
    R5 --> R6["驗證各消費端以新值正常運作"]
    R6 --> R7{"全部通過"}
    R7 -->|"否"| R8["回滾該消費端設定，舊值暫留<br/>記為未完成輪替"]
    R8 --> R5
    R7 -->|"是"| R9["失效舊值"]
    R9 --> R10["驗證舊值確實已無效"]
    R10 --> R11["寫入 RotationRecord：時間、執行者、原因、消費端已全數更新"]

10.3 入職 / 離職（人員異動）

sequenceDiagram
    participant M as 主管 / PM
    participant V as 保管庫
    participant P as 平台與第三方服務
    participant R as 輪替子流程 SUB-ROT

    Note over M,R: 入職
    M->>V: 建立個人帳號，強制 MFA
    M->>V: 依角色授予群組，最小權限
    V-->>M: 產生稽核事件 access.granted
    M->>M: 說明禁止事項（見 §13.1）

    Note over M,R: 離職 / 裝置遺失
    M->>V: 查詢該身分可存取的全部機密（能力 UX-6）
    V-->>M: 影響清單
    M->>V: 撤銷該身分全部存取
    M->>P: 停用該人在各平台的帳號
    M->>R: 依分級對影響清單執行輪替
    R-->>M: P0 於 1 小時內完成，其餘 24 小時內
    Note over M: 撤銷 ≠ 輪替。只撤銷不輪替，<br/>離職者本機仍握有可用的舊值。

這張圖要傳達的唯一重點：離職流程的成本，等於那個人能看到的機密數量。 這是把「最小權限」從教條變成有價格的東西——多給一個人 P0 權限，就是多一筆離職時要在 1 小時內輪替的債。

10.4 Edge Case Coverage（必填）

11. Mock Data Schema

不適用。本 PRD 不含畫面與 mock（ADR-010）。

12. ADR（架構決策紀錄）

Accepted ＝ 本 PRD 拍板，RD 不需再議。 Proposed ＝ 交由 RD 評估後拍板，拍板時請回填 Decision 與理由，Status 改為 Accepted。

ADR-001: 人用憑證與機器用機密分兩層治理

• Status: Accepted
• Context: 「密碼管理器」與「機密管理器」常被當成同一件事。實際上兩者的使用者、取用方式、輪替難度都不同：人用需要自動填入與行動裝置，機器用需要 CLI 注入與無人值守；機器用機密的輪替要同步更新所有消費端，難度高一個量級。硬用同一個工具，通常是人用層被工程化到非技術同仁不敢用，或機器用層被簡化到 CI 無法自動化。
• Decision: 架構上分為 Tier H（人用）與 Tier M（機器用），兩層可用不同工具，但共用同一份機密清冊以維持稽核完整性。
• Consequences: 需要維護兩套系統與一份跨系統清冊；換得各層都能選到合用的工具，且可分階段導入。清冊若沒人維護，這個決策的價值會歸零——因此清冊擁有者必須具名（§13.3 Q-3）。
• Decision maker: Eric | Date: 2026-09-01

ADR-002: 舊副本一律視為已外洩，遷移必須連帶輪替

• Status: Accepted
• Context: 遷移時最大的誘惑是「把 Google Sheet 的內容複製進保管庫，然後刪掉 Sheet」。這在資安上等於沒做：該憑證曾以明文存在於 Google Drive、存在於版本歷史、存在於任何看過共用連結的人的瀏覽器、存在於任何被授權的第三方 Drive app。無法證明沒有人抄走。
• Decision: 凡曾存在於 Google Sheet／Obsidian／git／聊天軟體／email 的機密，一律視為已外洩，遷移時必須產生新值，不得直接搬移。清冊以「曾外洩註記」欄位追蹤。
• Consequences: 遷移成本顯著提高——這是本案工作量的主要來源，而非工具導入。但不這麼做，整個專案只是把明文換個地方放。此決策不可談判：若因工作量而妥協，請改為「分批完成」而非「降低標準」。
• Decision maker: Eric | Date: 2026-09-01

ADR-003: 部署拓撲

• Status: Proposed — 待 RD 拍板
• Context: Eric 的初步構想是自架於辦公室 server、限內網存取、對外走 VPN（拓撲 T2）。此構想的資料主權與零授權費是真優點，但帶來六項具體風險（§8.2 T2 風險表），其中循環相依（EC-2）與可用性摩擦（EC-8）最難補。候選拓撲共四種：T1 廠商雲、T2 辦公室自架、T3 雲端 VPS ＋ Zero Trust、T4 混合。
• Decision: 待 RD 拍板。本 PRD 不預設答案（ADR-017）。四種拓撲的對照、存取通道的獨立對照、以及「重視什麼 → 傾向哪個」的收斂表，見 §8.3。PM 的個人傾向另置於 §8.3 標示為「非決議」的框內，RD 可逕行忽略。拍板時請在此補上理由與拍板人——特別是若選自架，需具名回答 Q-4（誰負責修補，C-10）。
  • 沿革：v1.0.0 曾建議 T3；v1.1.0 因 0 預算改建議 T2′；v1.2.0 依 ADR-017 取消一切預設建議，回到純比較。
• Consequences: 拓撲決定可用性上限與長期維運負擔，是本案最難逆轉的決策，因此交給實際要維運的人拍板，而非由 PRD 預設。
• Decision maker: [待 RD 回填] | Date: [待回填]

ADR-004: 自架時，優先雲端 VPS ＋ Zero Trust，而非辦公室實體機

• Status: Proposed — 待 RD 拍板（附屬於 ADR-003）
• Context: T2 的六項風險中，第 1（循環相依）、2（辦公室 SPOF）、5（可用性摩擦）、6（硬體隱形成本）四項的共同來源都是「機器放在辦公室」這一個決定，而非「自架」本身。T3 保留自架的資料主權與零授權費，同時移除該來源。團隊既有技術棧已使用 Cloudflare（§2 台帳），其 Zero Trust 免費層涵蓋 50 人，可讓自架服務不必開防火牆孔即可安全暴露。
• Decision: 待 RD 拍板（ADR-017）。本 ADR 原本主張「自架時優先雲端 VPS 而非辦公室實體機」；v1.2.0 起不再作為建議，僅保留其分析供權衡：T2 風險 1／2／5／6 的共同來源分別是「走自架 VPN」（風險 1、5）與「機器放辦公室」（風險 2、6），這兩個決定可以分開下——對照表見 §8.3。
• Consequences: 資料改放於第三方機房，主權介於 T1 與 T2 之間；多一層 Cloudflare 依賴。修補責任仍在我方，C-10 未因此解除。
• Decision maker: [待 RD 回填] | Date: [待回填]

ADR-005: 工具選型交 RD；PRD 只定能力門檻

• Status: Accepted
• Context: PM 若直接指定「就用 1Password」，會發生兩件壞事：一是繞過了實際維運者的判斷；二是當該工具在某個門檻上不合用時，沒有人有依據推翻。
• Decision: 本 PRD 定義 §7 的十條必要能力門檻（C-1～C-10）與 §3.6 的成功條件，不指定工具。RD 依門檻篩選候選、實測、提出建議並拍板。§3.3 的候選表僅為界定選項空間，非短名單。
• Consequences: 選型時程延長，換取選型品質與 RD 的擁有感（會用它的人選的，才會被用）。若 RD 評估後認為某條門檻不合理，可提案修改，但需在此 ADR 追加說明——不得默默略過。
• Decision maker: Eric | Date: 2026-09-01

ADR-006: 長期憑證優先改為短期聯邦憑證

• Status: Accepted（方向），實施範圍待 D-1 盤點後界定
• Context: 討論機密管理時的預設框架是「把 key 存到哪裡」，但風險削減幅度最大的動作其實是「讓 key 不存在」。CI 對雲端供應商的存取多半可改用 OIDC 聯邦，換發數分鐘有效的短期憑證，外洩時的價值趨近於零。存進保管庫的長期 key 仍然是長期 key。
• Decision: Tier M 的處理順序為：(1) 能聯邦化的改聯邦；(2) 不能的用平台原生 secret store；(3) 都不行的才進保管庫。三者一律登記於清冊。
• Consequences: 需要逐一改造 CI 設定，短期工作量高於「全部塞進保管庫」；但長期減少輪替負擔（聯邦憑證不需要輪替）。實際可聯邦化的比例待 D-1 盤點後才知道。
• Decision maker: Eric | Date: 2026-09-01

ADR-007: 破窗機制採實體離線 ＋ 雙人保管

• Status: Accepted
• Context: 零知識架構的代價是「廠商也救不了你」。管理員裝置全毀、MFA 全失、唯一知情者失聯時，若無破窗包，全公司憑證即永久歸零。而破窗包若存於數位系統，多半會回到「存在被它保護的那個系統裡」的循環相依。
• Decision: 破窗包（主密碼、Secret Key／解封金鑰、復原碼、VPN／Zero Trust 憑證）以實體紙本形式，由兩位成員分別保管於不同實體位置（至少一份不在辦公室），每季驗證一次有效性並記錄驗證日期。
• Consequences: 有實體遺失與竊取風險，故需雙份、異地、且內容本身不足以單獨解鎖全部（依所選工具的機制設計）。每季驗證是必要成本——未驗證的破窗包等於不存在。
• Decision maker: Eric | Date: 2026-09-01

ADR-008: 稽核日誌保留期

• Status: Proposed — 待 RD 拍板
• Context: 保留期直接決定「事故發生後能回溯多久」。外洩經常在數月後才被發現，保留期太短則發現時已無日誌可查。但長保留期在部分工具屬付費層級，且日誌本身是敏感資產（EC-11）。
• Decision: 建議 12 個月（AUDIT_RETENTION，§13.2）。RD 依所選工具的實際能力與成本回填，若低於 12 個月需說明補償措施（例如定期匯出至他處）。
• Consequences: 影響工具選型與方案層級；日誌本身需納入 P1 資產管理。
• Decision maker: [待 RD 回填] | Date: [待回填]

ADR-009: 明文機密的禁止載體

• Status: Accepted
• Context: 若不明確列出禁止項，「暫時放一下」會持續發生，且每次都有正當理由。
• Decision: 明文機密禁止存放或傳遞於：Google Sheet／Docs、Obsidian 或任何純文字筆記、git 追蹤的檔案、聊天軟體（Slack／LINE／Discord）、email 內文與附件、AI agent 可讀取的路徑、共用磁碟。完整清單與例外處理見 §13.1。
• Consequences: 需要提供夠方便的替代路徑（保管庫的一次性分享連結），否則禁令會被繞過。禁令與便利性必須同時交付，不得只交付禁令。
• Decision maker: Eric | Date: 2026-09-01

ADR-010: 本 PRD 不產畫面、不產 Storybook

• Status: Accepted
• Context: 本案是採購／導入既有工具與建立營運流程，不是自建產品功能。畫面由所選工具提供。
• Decision: 不產 Storybook、不畫 UI 規格。§6 只列「必須存在的能力」供選型勾稽。
• Consequences: 跳過了 gen-prd Rule 12「先讀 FE 檔案」的觸發條件，因此 Rule 33 的事實查核標準必須提高——本 PRD 的 §2 台帳明確標示未讀取實作 repo，所有相關敘述均標記 （推論，未實查），盤點交由 D-1。
• Decision maker: Eric | Date: 2026-09-01

ADR-011: 不自行開發保管庫

• Status: Accepted
• Context: 加密金鑰管理是極易做錯且錯了不會有告警的領域。7 人團隊自建保管庫的期望結果劣於任何成熟的開源方案。
• Decision: 一律採用既有方案（商用或開源），不自行開發。可以自架、可以客製整合，但核心加密與存取控制不自己寫。
• Consequences: 接受工具的既有限制與可能的廠商依賴（以 C-9 可攜匯出緩解）。
• Decision maker: Eric | Date: 2026-09-01

ADR-012: 公司機密與個人密碼分離

• Status: Accepted
• Context: 若成員把個人帳密也放進公司保管庫，離職時會產生「公司要不要保留／刪除個人資料」的爭議，且降低成員的使用意願（隱私顧慮會導致抗拒）。反之，公司帳密放在個人的私人管理器裡，公司則完全無法撤銷或稽核。
• Decision: 公司保管庫只放公司資產。多數工具提供的個人保管庫（family／personal vault）可視為福利提供，但公司不得存取、不納入稽核、離職時隨帳號一併移交或刪除，且此界線需於入職時明確說明。
• Consequences: 需在導入說明中明確劃線，避免成員誤把個人資料放進公司庫。
• Decision maker: Eric | Date: 2026-09-01

ADR-013: 明確排除 LastPass

• Status: Accepted
• Context: LastPass 於 2022 年遭入侵，攻擊者取得客戶的加密保管庫備份。由於部分帳號的主密碼強度不足且舊帳號的加密迭代次數偏低，離線暴力破解成為可行路徑，該事件的後續影響延續多年。這是「保管庫備份外洩後仍可被破解」的實例，正好是本案要避免的失效模式。
• Decision: 不將 LastPass 納入候選。
• Consequences: 縮小選項空間一項；同時把該事件當作評估其他方案時的檢查角度——要問的是「備份被偷走之後會怎樣」，不是「會不會被偷」。
• Decision maker: Eric | Date: 2026-09-01

ADR-014: prd repo 的 Coda API token 列為 P0-1，先輪替再談導入

• Status: Accepted
• Context: 撰寫本 PRD 時實查 prd repo，發現 .env 被 git 追蹤且含有效的 CODA_API_TOKEN，自 2026-03-24 起存在於 origin/main（證據見 §2 台帳）。Coda 的 API token 為使用者層級，可存取該使用者能存取的全部 doc，範圍大於本 repo 的用途。repo 為 private，故非公開外洩，但已散布至所有 clone、備份與讀過該 repo 的 AI agent context。
• Decision: 此項不等待選型完成，立即依序處理：(1) 於 Coda 撤銷該 token 並簽發新值；(2) 自 git 追蹤移除 .env 並補上 .gitignore 規則；(3) 檢視 Coda 端可得的存取紀錄；(4) 將此筆登記為清冊的第一個項目，標記「曾外洩」。不進行 git 歷史改寫——歷史改寫無法及於已經 clone 的副本，輪替才是有效的補救，改寫只會製造已處理的錯覺並打亂所有人的本機分支。
• Consequences: 需短暫中斷依賴該 token 的自動化（Coda backlog 同步）。此案例同時作為導入時的教材與 §3.6 指標 2 的第一個驗證點。
• Decision maker: Eric | Date: 2026-09-01

ADR-015: 預算為 0，成本改以維運時間計價

• Status: Superseded by ADR-017（2026-09-01 當日由 Eric 收回：「不處理預算了，只做比較」）
• Context: Eric 拍板預算 0，並要求「有不用錢的先處理」。這在現階段是合理的——本案的價值主要來自流程與紀律，而非工具本身，且 §3.6 的七項成功條件沒有一項需要付費功能才能達成。但 0 預算不是沒有成本，它把成本換了計價單位：所有商用託管方案出局，全部落到自架，而自架的帳單是人力。
• Decision: 採用 §3.3.1 的 $0 可行清單。同時明確承認：§7 的 C-10（無專職 SRE 仍能維持修補節奏）自此為本案的 binding constraint——它從「選型檢查項」升格為「決定本案成敗的單一因素」。
• Consequences: (1) 必須具名回答 Q-4「誰在週五晚上升級」，否則整個方案的安全性建立在無人負責的假設上；(2) 接受辦公室 SPOF（§8.3 風險 2），以破窗包（ADR-007）作為底線；(3) 若日後預算解禁，遷移至託管方案的成本很低——機密未曾以明文離開受控環境，依 C-9 匯出即可，不需重新輪替全部機密；(4) 本 ADR 不阻擋未來重議，預算是可變條件，門檻（C-1～C-10）不是。
• Decision maker: Eric | Date: 2026-09-01
• Superseded note: 本 ADR 的分析仍有效（0 預算會把成本換成維運工時，並使 C-10 成為 binding constraint），約束則已解除——預算不再是選型門檻。C-10 回復為 §7 的一般門檻，但仍是自架方案最容易失守的一條。

ADR-016: 存取通道採 Cloudflare Tunnel ＋ Access，取代自架 VPN

• Status: Proposed — 待 RD 拍板（v1.1.0 曾為 Accepted，v1.2.0 依 ADR-017 降為建議：通道選擇屬執行決策）
• Context: 原始構想為「自架於辦公室 ＋ 限內網 ＋ 對外走 VPN」。其中「放辦公室」在 0 預算下是正確的（既有硬體，邊際成本 $0，且不受免費層閒置回收影響，EC-16）；但「自架 VPN」帶來兩個最難補的風險：循環相依——VPN 憑證若存於只能經 VPN 取得的保管庫（EC-2）；以及可用性摩擦——出差／在家／週末要先連 VPN 才拿得到密碼，而摩擦會導致繞道，繞道不會有人回報（EC-8、§3.6 指標 5）。團隊既有技術棧已使用 Cloudflare（§2 台帳），其 Zero Trust 免費層涵蓋 50 人，遠超 7 人團隊所需。
• Decision: 待 RD 評估。建議：若採自架，保管庫不對公網開放連接埠，改以 Cloudflare Tunnel 出站連線暴露，並以 Cloudflare Access 做身分驗證，不自架 VPN。對照表見 §8.3「存取通道」一節。
• Consequences: (1) 解決 EC-2 循環相依與 EC-8 可用性摩擦；(2) 無需在防火牆開孔，對外攻擊面仍接近零；(3) 新增對 Cloudflare 的依賴——Cloudflare 中斷時無法存取保管庫，以破窗包與客戶端離線唯讀快取（EC-4）緩解；(4) Access 的身分驗證憑據必須列入破窗包，不得存於它所保護的保管庫內（ADR-007、EC-2）；(5) 辦公室 SPOF 仍未解決，見 ADR-015。
• Decision maker: Eric | Date: 2026-09-01

ADR-017: 不以預算作為選型約束；PRD 只提供比較，執行決策全數交 RD

• Status: Accepted（Supersedes ADR-015）
• Context: v1.1.0 曾把預算拍板為 0，據此淘汰全部付費方案並收斂出單一建議（T2′）。Eric 隨即收回此約束：「不處理預算了，只做比較，後續要怎樣做交給工程師決定」。這與本案自始的立場一致——pm_55 從第一版起就把執行交給 RD（ADR-005），v1.1.0 的預算約束其實是往回走了一步：它用一個商業條件替 RD 做掉了技術選擇。
• Decision: (1) 不設預算上限，付費與開源方案一律留在檯面，成本作為 RD 方案建議的一部分（§14 D-4）而非篩選前提；(2) PRD 的交付物是比較與門檻，不是結論——§3.3／§3.3.1／§8.2／§8.3 提供對照，§7 的 C-1～C-10 提供淘汰標準，拍板權在 RD；(3) 本 PRD 的單一建議收斂進 §8.3 明確標示的「PM 觀點（非決議）」框內，不散落於各節。
• Consequences: (1) 選型空間回復完整，RD 需自行估算成本，工作量略增（§14 D-4 恢復成本估算）；(2) ADR-015 標記 Superseded，其分析保留、約束解除；(3) ADR-016 自 Accepted 降為 Proposed——通道選擇屬執行決策；(4) §13.0 的階段 R-0 不受影響，因其五項本來就與預算無關；(5) 本 ADR 不改變任何門檻：C-1～C-10、ADR-002（必須輪替）、ADR-009（禁止載體）仍為不可談判項——「執行交給 RD」指的是怎麼做，不是要不要做。
• Decision maker: Eric | Date: 2026-09-01

13. 實作備註

13.0 遷移、相容與退場（Rule 23 必填）

本節是本案真正的工作量所在。 工具導入約佔 20%，這裡佔 80%。 若時程壓縮，正確做法是縮減批次範圍（先做 P0），不是降低每一批的完成標準。

階段 R-0：不需等待任何決策，現在就能做

這五項不依賴選型、拓撲或預算——不論 RD 最後選什麼，都得做，而且都是 $0 或近乎 $0。 先做完這一段，風險就已經下降一大截。

1. 輪替 prd repo 的 CODA_API_TOKEN，.env 移出 git 追蹤並補 .gitignore（ADR-014、F-1～F-4）。
2. 導入機密掃描作為 pre-commit hook ＋ CI 檢查，並對既有 repo 跑一次歷史掃描。工具由 RD 選：gitleaks（MIT，$0）或 GitHub Secret Protection（私有 repo 需付費，見 §2 台帳）。
3. 建立機密清冊初版（D-1）。清冊只放中繼資料、不放機密本體，故可置於私有 repo 的 Markdown（載體由 RD 定，但不得公開——清冊會洩漏「我們有哪些鑰匙、誰持有」，屬 P1 資產）。擁有者：Eric（Q-3 已拍板）。
4. 把「顯然沒人在用」的鑰匙砍掉。這是負成本的風險削減——砍掉的鑰匙不必保管、不必輪替、不會外洩。
5. 檢視各平台既有的原生 secret store 與可聯邦化的路徑（ADR-006），先把「本來就有、只是沒用」的機制打開。

階段 R-1：盤點與分級

1. 列出全部機密：git 歷史掃描、Google Drive 清查、Obsidian vault 全文檢索、各雲端平台既有 secret store、各成員自陳。
2. 逐筆標記：分級（§5.3）、擁有者、用途、消費端、是否曾存在於明文載體。
3. 標記「疑似已停用」者——盤點時最有價值的副產品是砍掉一批沒人在用卻仍然有效的鑰匙。能砍掉的鑰匙，就不必保管、不必輪替、不會外洩。
4. 產出物：機密清冊初版（含 §3.6 指標 1／2 的基準數字）。

階段 R-2：建置與 P0 導入

1. 依 ADR-003 拍板結果建置保管庫，完成備份與破窗包（ADR-007）。
2. 全員建立帳號並啟用 MFA。
3. P0 機密逐筆輪替後入庫（依 ADR-002，不得直接搬移），依 SUB-ROT（§10.2）執行。
4. 完成第一次還原演練（C-8）與破窗包驗證。

階段 R-3：全面遷移與舊副本銷毀

1. P1／P2 分批輪替入庫。

2. 舊副本銷毀，依載體採不同做法：

   載體	正確做法	為什麼不能只做「刪除內容」
   Google Sheet／Docs	刪除整份檔案 ＋ 清空垃圾桶 ＋ 撤銷共用連結 ＋ 檢視第三方 app 授權，且該機密已輪替	清空儲存格不會刪除版本歷史；共用連結可能已被轉發；已授權的第三方 Drive app 仍可能保有副本
   Obsidian vault	刪除筆記；若 vault 曾同步至第三方服務，一併檢視該服務的版本歷史；該機密已輪替	vault 多為純文字並同步至雲端；且 AI agent 可讀
   Git repo	自追蹤移除 ＋ 補 .gitignore；該機密必須輪替；不改寫歷史	改寫歷史對已 clone 的副本無效，卻會打亂所有人的分支並製造「已處理」的錯覺
   聊天／Email	該機密必須輪替；訊息刪除為輔助動作	訊息已同步至各成員裝置，刪除不可靠
   個人密碼管理器	成員自行刪除；該機密必須輪替	無法驗證是否真的刪除

3. 產出物：指標 2（舊載體零殘留）的驗證報告。

階段 R-4：防回歸與出口策略

1. 導入自動化機密掃描與 push protection，讓「不小心 commit 憑證」在進入歷史前被擋下。
2. 建立定期複檢節奏：季度還原演練、季度破窗包驗證、半年一次的權限複檢（誰還需要哪些）。
3. 出口策略驗證：每半年執行一次完整匯出（C-9），確認可攜性仍有效。匯出檔本身為 P0 資產，驗證後銷毀。
4. 將本節的節奏寫入資安政策文件（§14 D-6）。

Rollback

• 遷移期間舊值不得在新路徑驗證通過前失效（SUB-ROT 的 R7／R9 已強制此順序）。
• 若保管庫方案導入後不合用需更換：以 C-9 匯出 → 匯入新方案 → 驗證 → 銷毀匯出檔。更換工具不需要再次輪替全部機密（機密未曾以明文離開受控環境），這是 C-1 與 C-9 同時被列為門檻的原因。

相容性

• 本案不改動任何產品程式碼、資料模型或使用者流程，與既有 PRD 無功能衝突。
• 唯一的技術性變更是各服務改為自新來源取得憑證（Tier M），屬部署設定調整；影響範圍由 D-1 盤點界定。（推論，未實查——未讀取任何實作 repo，見 §2）

13.1 禁止事項

明文機密禁止存放或傳遞於以下載體（ADR-009）：

1. ❌ Google Sheet／Docs／Slides 或任何雲端試算表與文件
2. ❌ Obsidian、Notion、Apple Notes 或任何純文字筆記系統
3. ❌ git 追蹤的檔案（含 .env、設定檔、測試 fixture、註解）
4. ❌ 聊天軟體（Slack／LINE／Discord／Teams）
5. ❌ Email 內文或附件
6. ❌ AI agent 可讀取的路徑，或直接貼入 AI 對話視窗
7. ❌ 共用磁碟、隨身碟、印出的紙本（破窗包為唯一例外，見 ADR-007）
8. ❌ 未加密的截圖、錄影、教學文件

流程上的禁止事項：

9. ❌ 共用登入帳號（會使稽核日誌失去意義，C-2）
10. ❌ 只撤銷存取而不輪替（離職者本機仍握有可用的舊值，§10.3）
11. ❌ 未經驗證消費端即失效舊值（會造成隨機服務中斷，EC-6）
12. ❌ 把破窗包存進它所保護的系統（循環相依，EC-2）
13. ❌ 以 git 歷史改寫作為外洩補救的主要手段（ADR-014）

例外處理：需臨時傳遞機密時，使用保管庫提供的一次性、有到期時間的分享連結。若所選工具不具此能力，視為 UX-4 不滿足，需在選型時補上替代方案。

13.2 一致性表（Stage 5／6）

（一）語意欄位表

（二）常數表

（三）稽核事件字典

事件名稱為語意定義，實際名稱依所選工具而定；選型時需確認工具至少涵蓋下列語意。

（四）術語字典

（五）版本凍結表

13.3 PRD 問題清單

13.4 Sync-fix list

14. 下一步（交付 RD 的評估作業）

本 PRD 到此為止。以下是交給 RD 的作業清單，D-1 是其餘全部的前置。

時程建議：D-1 是唯一可以馬上開始、且不依賴任何決策的工作，建議先做。盤點本身就會產生價值——通常會找到一批沒人在用卻仍然有效的鑰匙，砍掉它們是零成本的風險削減。

現在就能開始、不需等待任何決策的一段：§13.0 的階段 R-0。其中 F-7（清冊擁有者）已拍板為 Eric，F-1～F-4（Coda token 輪替）可立即執行，F-8（機密掃描）只差選一個工具。

文件結束