加密概念
高層次流程
你在自己的雲端中控制一把 OpenAI 永遠無法看到的主金鑰
你的主金鑰會用於加密 OpenAI 使用的資料加密金鑰（DEK）
OpenAI 使用 DEK 加密你的靜態資料。DEK 由你的主金鑰加密，產生一個 eDEK（已加密 DEK），並與你的資料一併儲存
讀取資料時，OpenAI 會取得 eDEK，要求你的 KMS 將其解密成 DEK，然後解密你的資料
EKM 加密如何運作？
詳細資料請參閱我們的文章：OpenAI Enterprise Key Management (EKM) 概覽
OpenAI 會儲存我的 DEK 嗎？
不會——我們儲存的是已加密的 DEK（eDEK），由你的 KMS 產生。若要解密資料，我們會要求你的 KMS 將 eDEK 解密回 DEK。
OpenAI 會快取我的 DEK 嗎？
會——只在記憶體中。這是為了提升效能，避免每次資料加密／解密要求都連到你的 KMS。DEK 絕不會寫入儲存空間。
雲端權限
OpenAI 將會對我的 KMS 擁有哪些權限？
只會擁有你透過所設定政策授予我們的權限。我們至少只需要 Encrypt/Decrypt 操作。另請在你的雲端 KMS 中為 OpenAI 建立一個新金鑰，不要重用任何已有生產用途的現有金鑰。
OpenAI 何時會取得存取我的 KMS 的權限？
必須已完成以下所有步驟：
你已識別 OpenAI 的身份（視乎雲端供應商而定，可透過信任政策、工作負載身份等）。
你已建立用於存取 KMS 的政策。
你已向 OpenAI 的身份指派存取該政策的權限。
如果你只是建立 KMS 而未完成所有這些步驟，OpenAI 並不會擁有存取權。
我是否必須將主金鑰儲存在我的雲端中？
不需要——你可自行決定如何管理主金鑰。你可以採用雲端管理方案，或使用外部方案將金鑰分開儲存。OpenAI 只需要呼叫你 KMS 上的加密／解密操作；主金鑰實際如何執行加密／解密，屬於我們看不到的實作細節。
金鑰生命週期
DEK/eDEK 輪換（由 OpenAI 控制）
DEK/eDEK 多久輪換一次？
在加密路徑上每 24 小時一次（要求 DEK/eDEK 金鑰對）
在解密金鑰路徑上每 1 小時一次（DEK -> eDEK）
DEK 變更時，我需要做任何事嗎？
不需要——DEK/eDEK 輪換會在 OpenAI 內部完成。只要你的主金鑰仍然有效，任何由你的主金鑰加密的 eDEK 都可繼續解密成 DEK，然後用於解密你的資料。
主金鑰輪換與撤銷（由你控制）
金鑰輪換和金鑰撤銷多久發生一次？
這由你決定，因為 OpenAI 無法看到你的主金鑰。
金鑰輪換與金鑰撤銷有何不同？
金鑰撤銷會移除對使用較舊金鑰加密資料的存取權。金鑰輪換會使用新金鑰加密資料，但仍保留對較舊資料的讀取權限。
如果我撤銷主金鑰，會發生甚麼事？
如果金鑰被撤銷或權限被移除，工作區會在快取金鑰到期後最終無法運作。屆時，OpenAI 將無法再解密已儲存資料或加密新資料。實際上，資料會被「銷毀」。
撤銷多久會生效？
OpenAI 會為了效能和韌性，將 DEK 快取在記憶體中。撤銷通常會在一小時內生效，即快取金鑰到期且重新驗證失敗之後。
可以安全地測試撤銷嗎？
不建議在生產工作區測試撤銷，因為這會令現有資料永久無法存取。不過，客戶可以（亦應該）在沙盒環境中測試撤銷，以確認行為正確並驗證其信任假設。
如果金鑰被永久撤銷，是否可以透過附加新金鑰來復原工作區？
不可以。金鑰一旦遺失，按設計資料便無法取回。唯一補救方法是建立新的工作區。
如果工作區因金鑰變更而無法存取，我們應該怎樣做？
預期的補救方法是建立新的工作區。更新 KMS 不會復原現有資料。
如果我們決定停止使用 CMEK，有甚麼回退計劃？
目前沒有回退計劃。工作區一旦以 CMEK 建立，所有相關資料都會使用客戶管理的金鑰加密，沒有這些金鑰便無法存取。停止使用 CMEK 的唯一方法是建立新的工作區——現有加密資料將永久無法存取。
當我輪換主金鑰時會發生甚麼事？
系統會產生新的加密材料用於加密，因此新的加密要求會使用新金鑰。不過，KMS 識別碼（ARN 或金鑰名稱）會保持不變，而舊資料仍可解密。許多雲端供應商都提供自動金鑰輪換（AWS、GCP、Azure）。
當我輪換主金鑰時，OpenAI 會重新加密較舊資料嗎？
不會。新的加密材料只會用於加密新資料。
金鑰輪換或金鑰撤銷需要多久才會生效？
1 小時。這是因為 DEK/eDEK 會快取在記憶體中，而我們會每小時透過你的 KMS 重新驗證這些項目。
更換 KMS 識別碼
更換 KMS 識別碼屬於金鑰撤銷還是金鑰輪換？
金鑰撤銷。一把金鑰無法解密由另一把金鑰加密的資料。
OpenAI 可以協助我更換 ChatGPT 工作區的 KMS 識別碼嗎？
如果你確認意圖是撤銷金鑰，我們可以協助你為 ChatGPT 工作區執行此操作。請注意，更新 KMS ARN 後，較舊資料仍會無法存取，因此變更後你會同時有無法存取和可以存取的資料。
OpenAI 可以協助我更換 API 專案的 KMS 識別碼嗎？
如果你使用的是 API，API 可讓你輕鬆封存及建立新專案；因此，請改為封存那個資料本來已無法存取的專案，向 OpenAI 註冊新的 EKM 設定，並使用新的 KMS 金鑰建立新的 API 專案。
如果我想定期自行更換 KMS 識別碼，該怎麼辦？
不建議這樣做，因為你大概不會想定期撤銷金鑰。不過，如果你使用支援 KMS 金鑰別名的雲端供應商，仍可這樣做（AWS 範例）。你可以向 OpenAI 註冊該 KMS 金鑰別名，然後在雲端供應商端隨時替換別名所指向的底層 KMS 識別碼，以發出金鑰撤銷。
Beta 與 GA 行為比較
在生產環境中使用加密 beta 版時，是否有任何已知風險或系統層級變更？
beta 環境在功能上等同 GA，預期不需要遷移步驟。主要風險是，由於部分程式碼路徑尚未完成，某些邊緣情況功能可能尚未支援加密內容。這些情況很少見，且正在積極解決。無論這些潛在問題如何，資料都會完全加密並受到保護。
從 beta 版轉至 GA 時會有任何遷移步驟嗎？
沒有。使用加密 beta 版的工作區將在 GA 中自動獲支援，使用者無需採取任何操作。
其他技術詳情
信封加密與權限
我們需要向 OpenAI 授予 EKM 的 GenerateDataKey 權限嗎？
不需要。OpenAI 只需要你 KMS 金鑰上的 Encrypt 和 Decrypt 權限。EKM 整合並不需要 GenerateDataKey 權限。
OpenAI 是否對客戶資料使用信封加密？
是。OpenAI 使用信封加密模型：
客戶 KMS：管理 Key Encryption Keys（KEK）。OpenAI 永遠不會看到或儲存 KEK。
OpenAI 基礎架構：產生並管理 Data Encryption Keys（DEK）。每個 DEK 在儲存前都會以你的 KEK 加密（包裝）。
資料流程：
客戶資料會使用 DEK 加密。
該 DEK 會使用你的 KEK 加密，產生一個 eDEK。
eDEK 會與加密資料一併儲存。
若要解密資料，OpenAI 會要求你的 KMS 解密 eDEK，取得 DEK，然後解密內容。
為何 OpenAI 選擇此模型，而不是讓 KMS 同時管理 KEK 和 DEK？
常見的信封加密方法有兩種：
由 KMS 管理的 KEK 和 DEK：
優點：實作較簡單，無需維護加密基礎架構。
缺點：每個加密／解密要求都會連到 KMS，增加延遲和成本，並引入單點故障。
由 KMS 管理 KEK／由 OpenAI 管理 DEK（我們的方法）：
優點：延遲和成本大幅降低，可擴展性和可靠性更佳，並可在 KMS 局部故障期間繼續運作（直至 DEK 快取 TTL 為止）。
缺點：OpenAI 端的實作稍為較複雜。
此設計讓 OpenAI 能在提供強大安全保證的同時，盡量降低客戶的營運風險和成本。
DEK 多久輪換一次？
每個 DEK 約每 60 分鐘輪換一次。這提供時間上的隔離——即使某個 DEK 因某種方式遭到入侵，影響亦會限於該一小時時段內加密的資料。
KMS 要求量與可觀察性
我們看到的 KMS 要求遠少於使用者訊息數量。這些數字應該相符嗎？
不會，它們不會直接相關。
由於 OpenAI 會基於效能原因將 DEK 快取在記憶體中，因此只有在需要解密 DEK 時才會呼叫 KMS，而不是每次加密或解密操作都會呼叫。因此，你應預期會出現：
KMS 要求少於使用者互動次數。
當快取 DEK 到期（約每小時一次）或需要存取較舊的加密資料時，會出現偶發高峰。
擷取歷史資料時會有額外呼叫，例如使用者繼續一段長時間對話，而系統必須載入較舊 DEK。
KMS 要求的確切數量取決於快取狀態、使用者行為、資料存取模式及對話長度，因此不會與訊息量直接相關。