本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
搭配客戶提供的金鑰 (SSE-C) 使用伺服器端加密
伺服器端加密是有關保護靜態資料。伺服器端加密只會加密物件資料，非物件中繼資料。您可以在一般用途儲存貯體中使用伺服器端加密搭配客戶提供的金鑰 (SSE-C)，以使用您自己的加密金鑰來加密資料。如果您提供的加密金鑰作為請求的一部分，Amazon S3 會在資料寫入磁碟時管理資料加密，以及在您存取物件時管理資料解密。因此，您不需要維護任何程式碼來執行資料加密與解密。您只需要管理自己提供的加密金鑰即可。
Amazon S3 中的大多數現代使用案例都不再使用 SSE-C，因為它缺乏使用 Amazon S3 受管金鑰 (SSE-S3) 進行伺服器端加密的靈活性，或使用 AWS KMS 金鑰 (SSE-KMS) 進行伺服器端加密的靈活性。每次與 SSE-C 加密資料互動時，SSE-C 需要提供加密金鑰，因此與從 S3 儲存貯體讀取資料的其他使用者、角色 AWS 或服務共用 SSE-C 金鑰，以便操作您的資料並不切實際。由於對 SSE-KMS 的廣泛支援 AWS，大多數現代工作負載不會使用 SSE-C 加密，因為它缺乏 SSE-KMS 的靈活性。若要進一步了解 SSE-KMS，請參閱 搭配 AWS KMS 金鑰使用伺服器端加密 (SSE-KMS)。
如果您想要防止 SSE-C 加密用於寫入儲存貯體的物件，您可以在變更儲存貯體的預設加密組態時封鎖 SSE-C 加密。當一般用途儲存貯體封鎖 SSE-C CopyObject時，任何指定 SSE-C 加密的 PutObject、PostObject、、分段上傳或複寫請求都會遭到拒絕，並顯示HTTP 403 AccessDenied錯誤。若要進一步了解如何封鎖 SSE-C，請參閱 封鎖或取消封鎖一般用途儲存貯體的 SSE-C。
使用 SSE-C 無須額外付費。不過，請求設定和使用 SSE-C 會產生標準的 Amazon S3 請求費用。如需定價的資訊，請參閱 Amazon S3 定價
重要
從 2026 年 4 月開始， AWS 將使用客戶提供的金鑰 (SSE-C) 停用所有新儲存貯體的伺服器端加密。此外，對於 中沒有任何 SSE-C 加密資料的所有現有儲存貯體 AWS 帳戶 ，將停用 SSE-C 加密。隨著這些變更，需要 SSE-C 加密的少數應用程式在建立儲存貯體後，必須刻意透過 PutBucketEncryption API 啟用使用 SSE-C。在這些情況下，您可能需要更新自動化指令碼、 CloudFormation 範本或其他基礎設施組態工具來設定這些設定。如需詳細資訊，請參閱 AWS Storage Blog 文章
使用 SSE-C 之前的考量事項
-
當您使用 SSE-C 時，S3 永遠不會存放加密金鑰。 每次您希望任何人從 S3 下載 SSE-C 加密資料時，都必須提供加密金鑰。
-
您會管理哪個加密金鑰用來加密哪個物件的對應。您會負責追蹤針對哪個物件提供哪個加密金鑰。這也表示如果您遺失加密金鑰，則會遺失物件。
-
由於您是在用戶端管理加密金鑰，因此您會在用戶端管理任何額外的保護措施，例如金鑰輪替。
-
這種設計可能會讓您難以與您在資料上操作的其他使用者、角色 AWS 或服務共用 SSE-C 金鑰。由於對 SSE-KMS 的廣泛支援 AWS，大多數現代工作負載不會使用 SSE-C，因為它缺乏 SSE-KMS 的靈活性。若要進一步了解 SSE-KMS，請參閱使用伺服器端加密搭配 AWS KMS 金鑰 (SSE-KMS)。
-
這表示受管服務無法原生解密使用 SSE-C 加密的 AWS 物件。
-
-
在請求上指定 SSE-C 標頭時，您必須使用 HTTPS。
-
使用 SSE-C 時，Amazon S3 會拒絕所有透過 HTTP 提出的請求。為安全起見，建議任何錯誤地透過 HTTP 傳送的金鑰皆視為已遭洩漏。請捨棄該金鑰，並適當地輪換。
-
-
如果您的儲存貯體已啟用版本控制，您上傳的每個物件版本都可以有自己的加密金鑰。您會負責追蹤針對哪個物件版本使用了哪個加密金鑰。
-
Amazon S3 主控台不支援 SSE-C。您無法使用 Amazon S3 主控台上傳物件並指定 SSE-C 加密。您也無法使用主控台來更新使用 SSE-C 存放的現有物件 (例如變更儲存方案或新增中繼資料)。
