確保資料完整性

本頁說明如何使用總和檢查碼，在新增和存取密鑰版本時，維護及驗證密鑰資料的完整性。

您可以將檢查碼視為資料的專屬指紋。這是使用 CRC32C 演算法，從密碼資料生成的短程式碼。如果機密資料中即使只有一個位元發生變化，檢查碼也會隨之變更。這可讓 Secret Manager 偵測任何意外修改或損毀。

Secret Manager 會透過下列方式使用檢查碼：

  1. 新增密鑰版本時，請注意下列事項：

    • Secret Manager 會計算密鑰資料的 CRC32C 總和檢查碼。

    • 這個總和檢查碼會與密鑰資料一併儲存。

  2. 存取密鑰版本時：

    • Secret Manager 會傳回密鑰資料和總和檢查碼。

    • 您可以使用這個總和檢查碼，驗證收到的資料與 Secret Manager 中儲存的資料完全相同。

為確保總和檢查碼與 SecretPayload 結構相容，必須使用 CRC32C 演算法計算密碼資料的總和檢查碼，並編碼為十進位整數。SecretVersion 回應包含一個欄位，指出伺服器是否已成功接收並驗證這個檢查碼。

以下範例說明 Secret Manager 中的檢查碼運作方式：

API

這些範例使用 curl 示範如何使用 API。您可以使用 gcloud auth print-access-token 產生存取權杖。 在 Compute Engine 或 GKE 上，您必須使用 cloud-platform 範圍進行驗證。

使用 gcloud storage hash，計算儲存在資料檔案中的私密資料的總和檢查碼。 檢查碼必須轉換為十進位格式，並以 int64 編碼形式儲存在 SecretPayload proto 中。 

$ gcloud storage hash "/path/to/file.txt" --hex

在指令列中傳遞密鑰資料，然後依下列方式計算檢查碼： 

$ gcloud storage hash --hex cat <(echo ${SECRET_DATA})

以 Base64 編碼密鑰資料，並儲存為殼層變數。

$ SECRET_DATA=$(echo "seCr3t" | base64)

使用 curl 叫用 API。

$ curl "https://secretmanager.googleapis.com/v1/projects/project-id/secrets/secret-id:addVersion" \
    --request "POST" \
    --header "authorization: Bearer $(gcloud auth print-access-token)" \
    --header "content-type: application/json" \
    --data "{\"payload\": {\"data\": \"${SECRET_DATA}\", \"data_crc32c\": $CHECKSUM}}"

存取密鑰版本時，傳回的 SecretPayload 會包含資料和總和檢查碼。以下是回應範例：

{
  "name": "projects/PROJECT_ID/secrets/SECRET_ID/versions/VERSION_ID",
  "payload": {
    "data": "YQo=",
    "dataCrc32c": "163439259"
  }
}

在控制台中新增密鑰版本時，系統會在您輸入密鑰值後自動計算檢查碼。

以客戶自行管理的加密金鑰 (CMEK) 加密，且在 2021 年 7 月 16 日前建立的 Secret 版本，不會儲存總和檢查碼。

後續步驟