使用每個儲存貯體金鑰的伺服器端加密 (SSE-KMS)
MinIO 伺服器端加密 (SSE) 保護物件作為寫入操作的一部分,允許客戶利用伺服器處理能力來保護儲存層上的物件 (靜態加密)。SSE 還提供金鑰功能,以滿足關於安全鎖定和清除的法規和合規性要求。
MinIO SSE 使用 MinIO 金鑰加密服務 (KES) 和 受支援的外部金鑰管理服務 (KMS) 來大規模執行安全加密操作。MinIO 還支援客戶管理的金鑰管理,其中應用程式完全負責建立和管理用於 MinIO SSE 的加密金鑰。
MinIO SSE-KMS 使用金鑰管理系統 (KMS) 管理的外部金鑰 (EK) 加密或解密物件。每個儲存貯體和物件都可以有單獨的 EK,支援部署中更精細的加密操作。MinIO 只有在可以存取 KMS和用於加密該物件的 EK 時才能解密物件。
您可以使用 mc encrypt set
命令啟用儲存貯體預設 SSE-KMS 加密
mc encrypt set sse-kms EXTERNALKEY play/mybucket
將
EXTERNALKEY
替換為要用於加密儲存貯體中物件的 EK 名稱。將
play/mybucket
替換為您要啟用自動 SSE-KMS 加密的別名
和儲存貯體。
MinIO SSE-KMS 在功能上與 AWS S3 伺服器端加密與儲存在 AWS 中的 KMS 金鑰相容,同時擴展支援以包括以下 KMS 提供者
快速入門
重要
在 MinIO 部署上啟用 SSE 會使用預設加密金鑰自動加密該部署的後端資料。
MinIO 需要存取 KES 和外部 KMS 才能解密後端並正常啟動。KMS 必須維護並提供對 MINIO_KMS_KES_KEY_NAME
的存取權限。您不能稍後停用 KES 或「復原」稍後的 SSE 組態。
以下程序使用 play
MinIO KES 沙箱,以支援評估和早期開發環境中的 SSE-KMS 的 SSE。
對於擴展的開發或生產環境,請使用以下受支援的外部金鑰管理服務 (KMS) 之一
重要
MinIO KES Play
沙箱是公開的,並授予對所有建立的外部金鑰 (EK) 的根存取權限。Play
沙箱上儲存的任何 EK 都可能隨時被存取或銷毀,導致受保護的資料變得脆弱或永久無法讀取。
切勿使用
Play
沙箱來保護您無法承受遺失或洩漏的資料。絕對不要使用會洩漏貴組織私有、機密或內部命名慣例的名稱來產生EK。
絕對不要將
Play
沙箱用於生產環境。
此程序需要以下組件:
在可連線網際網路的機器上安裝 MinIO 金鑰加密服務 (KES)。請參閱
kes
入門指南,取得下載、安裝和設定 KES 的說明。
1) 建立用於 SSE-KMS 加密的加密金鑰
使用 kes 命令列工具,建立新的外部金鑰 (EK),以用於 SSE-KMS 加密。
以下命令會擷取 play
KES 伺服器的根 身分
curl -sSL --tlsv1.2 \
-O 'https://raw.githubusercontent.com/minio/kes/master/root.key' \
-O 'https://raw.githubusercontent.com/minio/kes/master/root.cert'
在終端機或 Shell 中設定下列環境變數:
export KES_CLIENT_KEY=root.key
export KES_CLIENT_CERT=root.cert
|
KES 伺服器上身分的私密金鑰。該身分必須至少授權存取 |
---|---|
|
KES 伺服器上身分的對應憑證。此步驟會使用 MinIO |
以下命令透過 KES 建立新的 EK。
kes key create my-minio-sse-kms-key
本教學課程使用範例名稱 my-minio-sse-kms-key
以便於參考。指定唯一的金鑰名稱,以避免與現有金鑰發生衝突。
2) 設定 MinIO 以進行 SSE-KMS 物件加密
在部署中每個 MinIO 伺服器主機上的 Shell 或終端機中指定下列環境變數:
export MINIO_KMS_KES_ENDPOINT=https://play.min.io:7373
export MINIO_KMS_KES_API_KEY=<API-key-identity-string-from-KES> # Replace with the key string for your credentials
export MINIO_KMS_KES_KEY_NAME=my-minio-sse-s3-key
注意
API 金鑰是與 KES 伺服器進行驗證的偏好方式,因為它為 KES 伺服器提供了簡化且安全的驗證流程。
或者,指定
MINIO_KMS_KES_KEY_FILE
和MINIO_KMS_KES_CERT_FILE
,而不是MINIO_KMS_KES_API_KEY
。API 金鑰與基於憑證的驗證互斥。指定 API 金鑰變數或金鑰檔案和憑證檔案變數兩者之一。
本網站上的文件使用 API 金鑰。
MinIO |
|
KES 為 MinIO 部署產生的 API 金鑰。API 金鑰的身分必須授權建立、產生和解密金鑰的權限。 API 金鑰是與 KES 伺服器進行驗證的偏好方式。如果情況需要,請指定 |
|
用於執行 SSE 加密操作的外部金鑰 (EK) 名稱。KES 會從已設定的金鑰管理服務 (KMS) 中擷取 EK。指定在上一個步驟中建立的金鑰名稱。 |
3) 重新啟動 MinIO 部署以啟用 SSE-KMS
您必須重新啟動 MinIO 部署才能套用組態變更。使用 mc admin service restart
命令來重新啟動部署。
mc admin service restart ALIAS
將 ALIAS
替換為要重新啟動的部署別名。
4) 設定自動儲存貯體加密
使用 mc encrypt set
命令,以啟用自動 SSE-KMS 保護所有寫入特定儲存貯體的物件。
mc encrypt set sse-kms my-minio-sse-kms-key ALIAS/BUCKET
寫入指定儲存貯體的物件會自動使用指定的 EK 進行加密。
針對您要啟用自動 SSE-KMS 加密的每個儲存貯體重複此步驟。您可以為每個儲存貯體或儲存貯體前置詞產生額外的金鑰,以便將每個 EK 的範圍限制為物件的子集。
安全清除和鎖定
SSE-KMS 使用在儲存貯體自動加密設定中指定或作為寫入操作一部分的 EK 來保護物件。因此,MinIO 需要存取該 EK 才能解密該物件。
停用 EK 會暫時鎖定使用該 EK 加密的物件,使其無法讀取。您可以稍後啟用 EK,以恢復對這些物件的正常讀取操作。
刪除 EK 會使該 EK 加密的所有物件永久無法讀取。如果 KMS 沒有或不支援 EK 的備份,則此過程是不可逆的。
單個 EK 的範圍取決於:
哪些儲存貯體指定該 EK 進行自動 SSE-KMS 加密,以及
哪些寫入操作在請求 SSE-KMS 加密時指定該 EK。
例如,考慮使用每個儲存貯體一個 EK 的 MinIO 部署。停用單個 EK 會使關聯儲存貯體中的所有物件無法讀取,而不會影響其他儲存貯體。如果部署改為對所有物件和儲存貯體使用一個 EK,則停用該 EK 會使部署中的所有物件無法讀取。
加密流程
注意
本節說明 MinIO 內部邏輯和功能。此資訊純粹是教育性的,並非設定或實作任何 MinIO 功能的先決條件。
SSE-KMS 使用已設定的金鑰管理系統 (KMS) 管理的外部金鑰 (EK) 來執行加密操作和保護物件。下表說明加密流程的每個階段:
階段 |
說明 |
---|---|
已啟用 SSE 的寫入操作 |
MinIO 收到請求 SSE-KMS 加密的寫入操作。寫入操作必須有相關聯的外部金鑰 (EK) 以用於加密物件。
|
產生資料加密金鑰 (DEK) |
MinIO 使用EK產生資料加密金鑰 (DEK)。具體來說,MinIO 金鑰加密服務 (KES) 使用 EK 作為「根」金鑰,向金鑰管理系統 (KMS) 請求新的加密金鑰。 KES 會同時傳回 DEK 的明文以及以 EK 加密的表示形式。MinIO 將加密的表示形式儲存為物件元資料的一部分。 |
產生金鑰加密金鑰 (KEK) |
MinIO 使用決定性演算法產生一個 256 位元的唯一金鑰加密金鑰 (KEK)。金鑰推導演算法使用一個偽隨機函數,該函數採用明文的 DEK、一個隨機產生的初始化向量,以及一個包含儲存桶和物件名稱等值的上下文。 MinIO 在每次加密或解密操作時產生 KEK,並且絕不將 KEK 儲存到硬碟。 |
產生物件加密金鑰 (OEK) |
MinIO 產生一個隨機的 256 位元唯一物件加密金鑰 (OEK),並使用該金鑰來加密物件。MinIO 絕不將 OEK 的明文表示形式儲存在硬碟上。在加密操作期間,明文 OEK 會駐留在 RAM 中。 |
加密物件 |
MinIO 在將物件儲存到硬碟之前,使用OEK來加密物件。然後,MinIO 使用KEK加密OEK。 MinIO 將OEK和DEK的加密表示形式儲存為元資料的一部分。 |
對於讀取操作,MinIO 會檢索 EK 來解密 DEK,進而解密物件。然後,MinIO 會重新產生KEK、解密OEK,並解密物件。