從 CISA/DHS 憑證外洩疑慮，看企業在委外開發、雲端與 CI/CD 流程中的憑證管理責任
文／游政卿
我常在客戶查核或稽核會議被問到一個很直接的問題：你們怎麼確定承包商、委外人員與合作夥伴，不會把你們的憑證、金鑰或環境設定帶走？
這題聽起來像是在懷疑人，其實問的是制度。企業有沒有把 secrets，也就是密碼、API key、Token、私鑰、簽章憑證這些東西，當成正式資產來管理？還是散落在工程師的工作習慣、專案交接資料、測試環境與聊天紀錄裡，平常沒人注意，等到出事才開始回頭找？
近期外媒 Axios 報導一起涉及 CISA 與 DHS 內部憑證、承包商公開 GitHub 程式碼庫的事件，引發外界對第三方協作與機敏憑證管理的關注。相關細節仍待當事單位完整說明，CISA 也對外表示，目前沒有跡象顯示敏感資料遭侵害；但這類事件提醒企業一件很現實的事：第三方在交付、協作、測試與同步資料的過程中，很容易把機敏憑證當成一般檔案處理。
我不會拿別人的事件當笑話，但我會把它當成提醒。第三方不是天生比較危險。比較麻煩的是，企業在專案開始時，把資料、權限與交付成果交出去，卻沒有同步把控制邊界畫清楚。等到事情被發現，管理層第一時間常常只剩幾句話可以說：我們正在查、資料已撤下、權限已停用。可是對稽核與客戶而言，他們要看的通常不是你撤得多快，而是你平常有沒有把這些東西管起來。
我通常會先問三件事。這項機敏憑證是誰產生的？放在哪裡？最後誰真的可以用？這三題答不清楚，後面的掃描、輪替與例外管理，多半只是補破網。對企業來說，機敏憑證至少要能說明用途、負責人、關聯系統與失效條件，否則就很難在事件發生時判斷影響範圍。
哪些機敏憑證是研發建立的？哪些是維運管理的？哪些是供應商或第三方產生的？沒有明確負責人，就不會有輪替窗口，也不會有到期策略。很多企業在盤點伺服器、端點、帳號時很認真，但一談到憑證與金鑰，就變成「應該在某個系統裡」、「應該是某個團隊在用」。這種回答在事件處置時通常撐不住。
比較務實的作法，是在委外或合作一開始，就把「可以開發」和「可以控制環境」分開來看。以我們自己的經驗，委外開發多半是協助 AWS 上的服務開發，但第三方可以寫程式，不代表企業要把 DNS、憑證、雲端權限與存取路徑一起交出去。
DNS 與憑證由內部開好，合作夥伴只能使用，不能自行操作。AWS 權限依最小權限原則（PoLP）處理。能掛在 AWS 伺服器或服務上的，就用 IAM Role，不另外把權限發給個人帳號；真的需要授權給個人使用，也是一件一件確認用途，不會因為專案方便就先開大。
程式碼需要用到的 API key，也不能寫進程式碼庫或交付文件，只能從環境變數或 AWS Secrets Manager 讀取。環境變數與 Secrets Manager 都由內部操作，不讓外部團隊自行管理。這樣做不是不信任合作夥伴，而是把責任邊界先講清楚。委外團隊負責開發與交付，企業自己要負責權限、憑證與存取路徑。
存取紀錄則靠 AWS CloudTrail 留下來。外部人員離場時，撤銷流程比照同仁離職處理，不會因為他是供應商就用比較鬆的標準。這一點平常看起來像行政細節，真的發生爭議時，差別很大。你要能說清楚某個時間點誰進來過、做過什麼、權限何時被關掉，而不是靠專案經理回想。
很多組織已經有做機敏憑證掃描，但常常只做一半。只掃公開程式碼庫，不掃私有程式碼庫；只掃程式碼，不掃設定檔與文件；只發警示，不設阻擋。久了之後，掃描結果變成另一種待處理清單，資安團隊知道有問題，開發團隊覺得干擾進度，管理層則看到看板上多了很多紅色項目。
掃描不能只停在提醒，它要進到流程裡。程式碼提交前要擋，進入 CI/CD 流程前要擋，發布前也要有最後一道檢查。但更重要的是，掃描結果要能連到後面的處置。發現憑證外洩後，多久內會失效？哪些系統要同步更換？誰確認換完？如果暫時不能換，例外由誰核准？這些紀錄平常看起來瑣碎，客戶查核或事件復盤時就會變得很重要。
第三方治理也不能只靠保密協議（NDA）或一句「請注意不要外流」。我會把要求寫進交付條款：合作夥伴必須使用企業指定的帳號與工作區，不得自行建立外部同步用的程式碼庫；不得用個人帳號保存含有憑證與機敏設定的資料；必要時要接受機敏憑證掃描與最小權限驗證。
還有一個常被低估的地方，是 CI/CD、自動化部署與測試流程。這些帳號與 Token 的權限有時比一般使用者還大，而且不會請假、不會離職，也不會主動提醒你已經很久沒換過。企業如果沒有把這些流程當成重要存取路徑來管，一個被濫用的 Token，就可能讓事件從單點外洩變成一串系統問題。
憑證輪替我也不會把它當成宗教式規定。不是每一項機敏憑證都要固定時間輪替才叫安全。有些項目本身沒有曝險面，硬性輪替反而增加維運風險，甚至造成不必要的服務中斷。但遠端存取、值班待命這類會碰到實際存取權的機制，只要成員異動就一定要換。這不是為了形式，而是因為人員異動是很明確的風險訊號。
事件處置面，我會要求團隊把憑證輪替當成可以演練的能力，不是出事才臨時做。憑證輪替最麻煩的地方通常不在技術，而在跨系統協調。哪些服務會受影響？維護窗口怎麼排？供應商要不要配合？是否需要對客戶說明？如果平常沒有憑證清冊，事件發生時就會一路追資料、一路猜影響範圍，最後變成「先不要動，怕弄壞」。
所以我不太接受「程式碼庫已經撤下就好」這種說法。撤下只是把現場先遮起來。機敏憑證是否仍然有效、權限是否已關閉、相關系統是否完成更換、是否留下處置紀錄，這些才是管理層日後要面對的問題。尤其在客戶查核或主管機關詢問時，企業不能只說「我們相信已經沒事」，要能說明根據是什麼。
secrets 外洩不是少數組織才會遇到的特殊事故，它是每個使用雲端、CI/CD、委外開發與第三方工具的企業都要面對的題目。管理層最後要能回答的，其實都很實際。這些憑證誰管、放在哪裡、多久換一次、例外誰准、第三方怎麼被約束，出事後又怎麼證明已經處理。
第三方管不好，通常不是第三方一個人的問題，而是企業平常交換資料、開權限、收交付成果的方式本來就太鬆。企業要避免的，是事件發生後才發現自己不知道哪些憑證還活著、哪些第三方仍有權限、哪些紀錄拿不出來。到了那個時候，外界追問的就不只是某一把金鑰怎麼外流，而是企業平常對第三方、權限與憑證是否真的有管理紀律。
(本文授權非營利轉載，請註明出處：CIO Taiwan)
