A DKIM 私鑰是創建簽名的權限，可以根據匹配的公共記錄進行驗證。僅保護DNS記錄並不能保護此權限。在決定控制金鑰之前，盤點簽署系統、可以使用它們的帳戶以及秘密的每個操作副本。
確定監護權而不是承擔監護權
從實際的提供者或簽名軟體開始。託管服務可以產生並保留金鑰；自操作簽署者可以讀取檔案、秘密儲存或支援的硬體支援的介面。這些模型具有不同的存取和恢復控制。除非所選產品記錄並實施，否則不要承諾硬體保護、不可匯出性或客戶管理的輪調。
RFC 6376 §8.3 解釋了私鑰洩漏的後果：入侵者可以創建由發布相應公鑰的網域簽署的郵件。它還描述了受控外發郵件伺服器的價值，該伺服器對提交者進行身份驗證並應用發送控制。以下的具體儲存和審核步驟是操作建議，而不是通用的DKIM協定要求。
建立一個暴露隱藏副本的監管地圖
對於每個 選擇器，記錄簽章域、服務擁有者、金鑰保管人、活躍簽章節點、部署路徑和支援的復原機制。追蹤秘密的引用或標識符，而不是秘密本身。透過組織批准的秘密處理流程，審查配置儲存庫、容器建置步驟、臨時部署檔案、備份和診斷包，以查找意外副本。
一個綜合範例是具有兩個簽章節點和一個部署作業的計費叢集。 DNS金鑰是公開的且是預期的。私鑰旨在僅到達兩個節點，但舊的建置管道還將其嵌入到不相關項目可存取的映像中。保護目前節點檔案權限不會消除舊的暴露。根據事件過程調查傳播路徑並處理可能暴露的秘密。
切勿將私鑰貼到公用DNS欄位、票證、聊天或公用DKIM檢查器。當支持需要證據時，向公共選擇者提供資訊和適當控制的診斷結果。原始訊息也可能包含敏感內容；盡量減少分享內容並使用經批准的管道。
減少誰可以簽名以及誰可以檢索秘密
使用平台支援的最低權限控制進行管理和執行時間存取。即使無法匯出金鑰，可以要求簽署的帳戶也可能很強大。查看誰可以更改允許的發送身分、提交郵件、輪換金鑰、部署簽署者配置和檢索備份。
具有不同所有者或信任等級的獨立服務，其中架構支援獨立的金鑰和選擇器。將一個密鑰複製到每個應用程式中會使事件更難以確定範圍，並且報廢更具破壞性。高可用性可能合法地需要共享簽名身份，但這應該是具有受控分發的明確設計，而不是複製配置文件的意外結果。
在不分發秘密的情況下測試恢復
詢問是否可以透過恢復受保護的金鑰、產生替換金鑰或使用提供者的託管復原路徑來恢復中斷。在受控環境中測試支援的過程。記錄復原時間、 DNS依賴以及排隊郵件是否仍使用舊選擇器。不要僅僅為了使演練更容易而創建額外的未受保護的備份副本。
查看簽名平台和秘密管理系統中可用的日誌和存取事件。有用的問題是是否可以檢測和調查未經授權的更改或使用，而不是特定的儀表板是否存在。記錄日誌記錄差距，而不是發明稽核追蹤。
以可操作的生命週期記錄結束
將監管地圖放在輪換和妥協程序旁邊。當員工或供應商離開時刪除過時的存取權限，並在基礎設施變更後重新檢查分配。在可疑暴露期間，協調訪問遏制、乾淨更換以及舊密鑰報廢的驗證後果。受保護的當前文件只是受控簽名生命週期的一部分。
使用監護決定工作表
對於每個簽名身份，記錄這些非秘密欄位：
- 使用：哪些服務帳戶可以提交或要求簽名，以及它們可以使用哪些身分。
- 檢索：哪些角色可以匯出或還原私鑰，以及核准的副本所在的位置。
- 更改：誰可以更改簽署者配置、允許的身份或部署工件。
- 復原：受支援的路徑是否恢復受保護的金鑰或產生替換，以及DNS和排隊郵件依賴。
- 證據：可用的存取/簽名日誌、任何覆蓋範圍差距以及負責審查的所有者。
如果舊的建置工件包含暴露的金鑰，則僅保護活動節點是不夠的：確定舊的暴露範圍並根據事件程序決定乾淨的替換。此工作表是編輯安全指南，而不是聲稱特定平台提供這些控制項。
相關閱讀
撤銷DKIM金鑰並區分撤銷與遺失的DNS記錄 · DKIM金鑰長度 和演算法：檢查當前接收器支持.