要把一把憑證交給合作廠商，而此刻雙方還沒有任何共用的安全通道——第一次交付本身就是先有雞還是先有蛋的問題。

本章的責任是把「這把憑證怎麼交出去」拆成兩個有先後的問題：這條整合需不需要有一把要交出去的憑證，以及交付免不掉時那一次交付要滿足什麼條件。本章說的配發是核發、交付與登記三個動作的合稱，其中核發專指產生憑證那一步。

本章涵蓋與不涵蓋

本章聚焦憑證從核發、送到使用方手上到被登記下來的這一段。憑證上線之後的輪替、回收與事件收斂節奏屬治理層，見 7.6 秘密管理與機器憑證治理。用哪一種憑證機制（共享密鑰、API key、mTLS、OAuth client credentials）是另一條判讀軸，分兩層：原語層（這個機制解的是機密性、來源與完整性還是別的）在 7.28 密碼學原語選型，系統層的機制選型在 7.34 機器憑證的機制選型，兩者都在本章的上游。人類帳號的開通不在本章形態裡，那一側走 7.2 身分與授權邊界。

本章 threat scope

In-scope：配發動作在可以免掉時仍然存在 / 初次交付的通道留下長期可讀的副本 / 初次交付的接收人由核發方認定 / 憑證的用途與擁有者沒有落在紀錄上 / 核發與請求由同一方完成。

Out-of-scope（路由到他章）：

Reader 對 in-scope 列表的 specific threat 應該能反向 trace 到本章問題節點；out-of-scope 議題請直接跳到對應章節。

從本章到實作

本章是 routing layer，沿兩條 chain 進入 implementation：

  • Mechanism：問題節點表「前置控制面」欄的連結進知識卡，看該控制的機制、邊界與適用條件。
  • Delivery：「交接路由」欄位指向 05 部署平台、06 可靠性、08 事故處理。

兩條 chain 完成判準與模組級 chain 規格見 從章節到實作的 chain。

配發是可以被消除的動作

配發的核心判讀是先確認這條整合真的有材料必須交出去。呼叫方能用它的執行環境本身證明身分時，沒有任何憑證離開核發方，交付這個動作連同它的三種失效一起消失——交付通道的副本、初次交付被冒領、以及憑證原文在雙方之間留下第二份，都以「有一把憑證要送出去」為前提。消失的是核發與交付，登記與範圍判斷留下來、換了載體：信任關係本身一樣要有用途、範圍、期限與擁有者，一樣會過時，而「要這條整合的人自己去設那條信任」這件事原封不動搬過去——把信任條件寫得比需要的寬（例如接受某個組織底下的任何專案，而非釘到單一專案與單一分支）是這條路上最常見的設定錯誤，成因與本章的「核發與請求同一方完成」一字不差。走這條路的讀者要把那個節點帶著走，信任關係本身的漂移判讀見 7.10 Workload Identity 與聯邦信任邊界。這條路徑的機制是呼叫方向自己的平台取得一份身分聲明（由平台簽發、內容是「這個執行中的程式是誰」，任何信任該平台的一方都驗得出來），被呼叫方驗證那份聲明後當場換發一把短效憑證，判讀與治理見 7.10 Workload Identity 與聯邦信任邊界。

常見的成因有五種，分成兩類。分類軸是決定權在誰、以及這個成因會不會自己消失——軸比列舉重要，因為列舉追不上真實系統，而軸可以拿來歸類沒被列到的那些。前三種的決定權在別處。

雙方沒有共同的信任錨。呼叫方的平台簽出來的身分聲明，被呼叫方沒有理由相信。最常見的成因是呼叫方由對方組織運行，而同一個組織跨雲、跨資料中心且尚未建立聯邦時也落在這一格。要讓它消失需要雙方共同接受一個外部的信任錨（公用的憑證信任鏈 或雙方都串接的身分提供者），而那本身是一次跨組織或跨平台的建置。兩邊的成本結構不同：信任錨是每一對平台付一次，配發是每一條整合各付一次，交叉點因此落在共用同一個錨的整合數上。合作對象少的時候配發便宜，而這個數字通常長得比預期慢，所以這個成因會維持很久。

執行環境不簽發身分。地端主機、現場裝置、遺留系統與部分託管平台沒有「向平台索取身分聲明」這個能力，呼叫方能拿出來的只有事先放進去的材料。這是環境屬性，它的變化跟隨基礎設施汰換而非跟隨自己的決定。落在這裡的整合沒有可以爭取的對象，處置就是把下方的核發、初次交付與登記走完，並在基礎設施汰換的規劃裡把這批憑證列為受影響清單。

被呼叫方只接受長期憑證。對方的 API 只接受 API key，就算自己這邊具備完整的平台身分能力也用不上。它與前兩種的差別在決定權落在對方的產品藍圖，而產品藍圖會變。落在這裡的整合值得留下一筆重評估紀錄：記下當初是因為對方沒有支援才配發的，等到對方公告支援時回頭換掉。缺這筆紀錄時，這條整合會以「本來就是這樣接的」的形式留到憑證本身出事為止。

另外兩種的決定權在自己這邊，因此它們不會因為外部條件改善而消失。

身分服務故障時要有降級路徑。平台身分那條路把每一次呼叫都綁在身分服務的可用性上，而某些系統對降級的要求高於那個水準，於是保留一把預先配發的長期憑證作為故障時的通路。這一種的份量由自己的可靠性預算決定，配套是那把憑證平時停用、動用要留下紀錄，形態見 break-glass-access。

合規指定憑證形態。監理或契約要求特定 CA 簽發的用戶端憑證、或要求憑證本身可離線稽核。它字面上像「被呼叫方只接受長期憑證」那一種，差別在決定權落在法規而非對方的藍圖——「等對方公告支援就換掉」這個處置對它無效，重評估的觸發器要綁在法規或契約的修訂上。

判讀流程

  1. 先問呼叫方能不能用執行環境證明身分。這一題要查兩個地方：自己這一側的執行平台有沒有簽發身分聲明的端點（雲平台的實例中繼資料、容器編排的投射式 token、專用的身分代理），以及對方的 API 文件收不收那個形態。兩邊都成立才算能。能的話走 7.10，本章其餘各節不必進入。答案是不能的時候，把這次判定連同理由寫進下方第 5 步的登記——這是全章後果最大的一次判定，而它預設不留痕跡：日後有人問「這條整合為什麼用長期憑證」，沒有紀錄的話只能重做一次判斷，而重做的人多半不知道當初被什麼卡住。
  2. 免不掉時確認落在「配發是可以被消除的動作」那一節的哪一種成因，並依成因留下不同的後續。同時命中多種時（對方組織運行的地端系統會同時命中缺信任錨與環境不簽發身分）取決定權最遠的那一種，因為後續動作由決定權在誰決定：
    成因這一條要留下什麼
    缺共同信任錨重建信任錨的成本門檻與啟動條件
    執行環境不簽發身分綁進基礎設施汰換排程的受影響清單
    被呼叫方只接受長期憑證重評估紀錄，觸發器是對方公告支援
    故障降級路徑定期複查自己的可靠性預算
    合規指定憑證形態定期複查法規與契約版本
  3. 接著確認核發方與請求方是不同的人，以及審批要看的四個欄位填得出來。
  4. 再決定初次交付走哪條通道（三種形態見下方「初次交付」那一條），並把交付後的第一次輪替排進同一張工單。
  5. 最後把這把憑證登記到清單上，路由到 7.6 的輪替與回收節奏。

問題節點（案例觸發式）

問題節點判讀訊號風險後果前置控制面交接路由
可免的配發仍在進行雙方同平台或已有共同身分提供者，仍手動交憑證長期憑證存量隨整合數量線性增加workload-identity、credential05 + 06
交付通道留下副本憑證原文出現在聊天訊息、工單或郵件憑證的可讀範圍等於該通道的保存與搜尋範圍secret-management06 + 08
憑證缺用途與擁有者憑證清單只有名稱與建立時間回收沒有觸發者，存量只增不減credential、audit-log06
核發與請求同一方完成需要憑證的人自己開、自己決定範圍範圍由使用便利決定，沒有第二次判斷least-privilege、authorization06 + 08
接收人由核發方認定交付紀錄上找不到請求方指名收件人的那一步憑證直接交到冒充請求方的人手上credential、trust-boundary08

配發免不掉時要定什麼

核發方與請求方要是不同的人。這條分工存在的理由是讓範圍被判斷第二次，流程完整度只是它的副產品。請求方知道自己要做什麼，也因此傾向把範圍開到「肯定夠用」；核發方的責任是問「這些權限各自對應到哪個動作」。這個問法有一個前提：範圍的顆粒要細到對應得出來。自己就是核發方時顆粒由自己決定，對應不出來就切細；憑證由對方核發而對方只提供粗選項時，第二次判斷無事可做，該做的是把「實際用到的」與「被授予的」差額記下來當成已知風險，顆粒由誰決定這件事見 authorization-scope。同一個人兼任時這個問題沒有人會問，因為它對請求方而言沒有答案上的疑問。組織規模不足以分派兩個角色時，替代做法是讓範圍的決定留下書面理由——理由寫得出來的權限與寫不出來的權限，在事後盤點時是不同的兩堆。

審批看的是四個欄位填不填得出來，而不是請求方值不值得信任。四個欄位是用途、範圍、期限、擁有者。填不出來的那一格會在日後變成回收的障礙：用途空白時沒有人知道停用它會壞掉什麼，擁有者空白時沒有人會收到它該停用的通知。這四欄與 7.6 回收沒有發動時機 是同一件事的兩端——那一節談的是回收缺少發動時機，而發動時機的材料就在配發當下填的這四欄裡。缺這四欄的憑證日後要補，成本是逐把去問還有誰在用。

初次交付

此刻雙方還沒有共用的安全通道，而要送出去的正是建立通道的材料——先有雞還是先有蛋。可行的做法是承認第一次交付的通道有風險，並讓那個風險只存在很短的時間。三條各自獨立成立：

  • 交付通道與整合本身分開。整合走 API，交付就別走同一組帳號能看到的地方。同一條通道被入侵時，入侵者同時拿到憑證與它的用法。實際能選的通道由雙方的既有工具決定。對方在同一個身分域時把值放進對方能自行取用的秘密存放位置、完全不經人手，託管服務的形態見 vendors 的 secrets 服務頁。跨組織而雙方都有秘密管理工具時用一次性取用連結：連結本身可以走日常通道，因為它取用一次就失效，機制見 HashiCorp Vault 的動態憑證 的 response wrapping 段。兩者皆無時退到值與取用方式各走一條通道，這是三者中唯一需要接收方分辨兩則訊息的做法，也因此最容易在對方那一側被合併回同一個地方——驗收動作是請對方回報從哪兩個位置各取到什麼，不由自己假設分開了。

    離線與現場交付（憑證隨安裝包出貨、現場人員手動輸入、可攜媒體）落不進上面三種，因為它們沒有可用的第二條電子通道。這一類的最小要求是把分離換成時間上的分離：交付與啟用分兩次進行，到場之後由現場人員完成第一次輪替，讓出貨那一份在啟用前就已作廢。

  • 接收人由請求方指名。核發方猜收件人的時候，猜錯的成本是把憑證直接送給冒充者，而冒充請求在對方組織裡看起來與正常請求相同。指名的動作要發生在請求當下，而不是交付當下——交付當下才問等於在已經被冒充的對話裡確認身分。

  • 交付完成後立刻輪替一次。這一條的成本由「新憑證能不能由接收方自助取得」決定：能的話是幾分鐘，不能的話它本身就是一次要對方改設定的協調，而排不進工單的結果就是這一步被跳過。輪替的順序（先發新的再停舊的雙密過渡、還是直接換）見 Shared Secret 安全輪替設計。它把交付通道的安全性從必要條件降級成時間條件：第一把憑證只需要撐到對方完成第一次連線，之後那則訊息裡的內容已經是作廢的值。它有兩個前提。第一，新憑證要由接收方在已經建立的認證通道上自助取得、或走另一條通道——第二把憑證若貼回同一個群組，暴露面沒有縮小，只是多了一則訊息。第二，這一條收斂的是副本長期留存，收斂不了在窗口內即時讀到的人：那個人在窗口內可以自行開一把新憑證或拉一次資料，而那些動作不會因為原憑證作廢而失效。它同時是輪替能力的一次實測——輪替在這裡失敗，代表日後事件當天的輪替也會失敗，而那時的時間壓力大得多；交付當天也是唯一一次對方在線且有動機配合輪替的時刻。

登記要在交付當下完成。憑證存在這件事要落在一份清單上，而不是落在核發者的記憶裡。這份清單不是平台自己的憑證列表——平台的建立表單多半只要求名稱，承載不了用途與擁有者。最小形態是版控裡的一份表、每把憑證一列；已經有秘密管理工具時放進它的 metadata 欄位，讓登記跟著憑證走而不是跟著人走。兩份並存時要指定哪一份是判定依據、以及新增憑證時由誰負責同步：沒有指定的話兩份會各自演化，而事件當天翻出來的那一份通常是舊的。這份清單同時是 7.6 的回收判斷與 7.27 的 scope map 的輸入。除了審批那四欄，還要記下「為什麼這條整合免不掉配發」——落在哪一種成因、以及那一種對應的重評估觸發器是什麼。這一項讓判讀流程第 1 步與第 2 步的判定有住址，否則那兩次判斷做完就消失，而它們正是日後要重新檢視這條整合時唯一該讀的東西。事後補登記要重新取得同樣的資訊，而那時資訊的持有者可能已經換人。

問題節點出現在什麼樣的系統

憑證還沒開始流通時上表的訊號都量不到，這一節給的是那個階段能對照的系統形態。

可免的配發仍在進行出現在平台能力領先於團隊習慣的組織。雲平台的原生身分能力上線之後，既有整合沒有人回頭改，新整合則沿用既有整合的做法。沿用有兩種成因，而它們的修法相反：一種是抄現成範例最省事、而現成範例是舊的，處置是把新範例放到人會看到的地方；另一種是寫整合的團隊沒有設定平台信任的權限，抄舊做法是唯一走得通的路，處置是下放那個設定權或提供代辦窗口。兩者的識別特徵相同（同一個雲帳號內的兩個服務之間用著長期 key），要分辨得問一次「你有沒有辦法自己設那條信任」。

交付通道留下副本幾乎與所有手動配發同時出現，因為聊天軟體與工單系統是雙方本來就在用的通道。它的形態差異在通道的保存政策：聊天工具的保留期限未設上限時訊息長期留存且全文可搜，而工單系統的附件會跟著工單被歸檔、日後由其他人瀏覽。這個參數在自己的組織查得到，在對方的組織查不到——跨組織交付時只能假設對方那一側沒有上限。

憑證缺用途與擁有者出現在配發由工程師直接在平台介面完成的組織。平台的建立表單只要求名稱，於是名稱承擔了全部的語意，而名稱是自由文字。

核發與請求同一方完成出現在有平台管理權限的人同時是使用者的團隊，這在小型團隊是常態而非疏失。接收人由核發方認定與交付通道留下副本同源——兩者都發生在交付這一步由人手完成的時候，差別只在失效的方向：一個是憑證留在不該留的地方，一個是憑證去了不該去的人手上。

交付通道留下副本的後果在這張表裡最不直觀：當下的每一步都成功，而後果沒有任何時間點會自己浮現。可免的配發與缺用途擁有者最後累積出來的場面在 7.6 憑證生命周期失衡。

它的失敗長這樣：與合作廠商串接時，對方的工程師在共用的聊天群組裡問要用哪把 key，這邊的人就把 key 貼上去了。對方接完、整合上線、運作正常。那則訊息留在群組裡，而群組成員隨著兩邊的專案人員異動持續增加，訊息本身沒有到期。這一則沒有「開始出問題」的那個時刻——那正是它的形狀，也是它與其他四個節點最大的差別。

沒有被發現是因為這件事不產生任何失敗訊號：憑證能用就是流程完成的表徵，而「憑證同時存在於另一個地方」在系統這一側看起來與正常持有沒有差別。監控看的是呼叫是否成功，稽核看的是憑證是否有效，兩者都通過。浮現要靠外部事件把它翻出來：有人開始問憑證曾經出現過哪些位置，或那條通道的存取範圍發生變化。

止血的動作是輪替，而輪替要對方配合換設定，於是這一條的處置時間由對方的排期決定，跟 7.29 系統層的撤銷 是同一個約束。交付當下多做一次輪替，在新憑證能由對方自助取得時只是幾分鐘；那個條件不成立時，當天輪替一樣是一次協調，差別只在對方此刻在線且有動機配合。事後補做則連這個差別都沒有。

常見風險邊界

配發要從日常操作升級成治理議題的時機有五種。

  • 憑證原文在自己控制範圍之外的通道留有副本，且沒有後續輪替時，代表這把憑證的可讀範圍已經無法界定。
  • 憑證清單查不出「這把是誰要的、給什麼用」時，代表回收缺少發動條件，收斂路徑見 7.6 其餘節點的收斂動作。
  • 對方要求以寫死在設定檔或程式碼的形式接收憑證時，這條整合的撤銷時間由對方的發版週期決定，這超出工程修復能承擔的範圍。處置要往合約層走——在對接契約裡談定輪替窗口與整合終止條件，讓事件當天的時程有依據；憑證隨產出物散佈之後被檢索重用的實際後果見 USAHERDS 2021。
  • 同一把憑證交付給兩個以上的使用方時，代表撤銷粒度在配發階段就已經失去，處置見 7.6 token 分域不足。
  • 平台已具備原生身分能力而配發仍在持續發生時，代表長期憑證存量會隨整合數量繼續累積，而每一把都要各自輪替與回收。收斂分兩段：新增整合直接切到平台身分那條路，目標態的判讀與治理走 7.10 Workload Identity 與聯邦信任邊界；既有的那批要逐條遷移，而遷移程序本身（新舊並行的驗證窗口、回退時限、撤銷確認）走 7.27 Credential Rotation with Scoped Evidence 的五步骨架。排序用 7.27 的維度而非憑證年齡——年齡只反映它累積了多少用途，看不出換錯了會壞掉什麼。

案例觸發參考

下一步路由