加密(&A)；解密資料

本指南說明如何使用 Google Workspace 用戶端加密 API 進行加密和解密。

您必須將使用者用來共用加密檔案的任何識別資訊提供者 (IdP) 服務加入許可清單。一般來說，您可以在相應的公開 .well-known 檔案中找到所需的 IdP 詳細資料。如果找不到，請與機構的 Google Workspace 管理員聯絡，瞭解對方的 IdP 詳細資料。

加密資料

Google Workspace 使用者要求儲存用戶端加密 (CSE) 資料時，Google Workspace 會將 wrap 要求傳送至金鑰存取控制清單服務 (KACLS) 端點網址，以進行加密。除了選用的安全性檢查 (例如邊界和 JWT 聲明檢查)，KACLS 還必須執行下列步驟：

  1. 驗證提出要求的使用者。

    • 驗證驗證權杖和授權權杖。
    • 不區分大小寫比對電子郵件聲明，確認授權和驗證權杖是否屬於同一位使用者。
    • 如果驗證權杖包含選用的 google_email 聲明，則必須使用不區分大小寫的方法，與授權權杖中的電子郵件聲明進行比較。請勿使用驗證權杖中的電子郵件聲明進行這項比較。
    • 如果驗證權杖缺少選用的 google_email 聲明，應使用不區分大小寫的方法，比較驗證權杖中的電子郵件聲明與授權權杖中的電子郵件聲明。
    • 如果 Google 為未與 Google 帳戶建立關聯的電子郵件地址核發授權權杖，則必須提供 email_type 聲明。這是訪客存取功能的重要環節，可為 KACLS 提供有價值的資訊，以便對外部使用者強制執行額外的安全措施。
      • KACLS 可將這類資訊用於下列用途：
      • 強制執行額外的記錄規定。
      • 將驗證權杖核發者限制為專屬的訪客 IdP。
      • 在驗證權杖中要求額外聲明。
      • 如果客戶未設定訪客存取權，系統可能會拒絕所有將 email_type 設為 google-visitor 或 customer-idp 的要求。如果要求具有 google 的 google 或未設定 email_type，應繼續接受。email_type
    • 如果驗證權杖包含選用的 delegated_to 聲明，也必須包含 resource_name 聲明，且這兩項聲明必須與授權權杖中的 delegated_to 和 resource_name 聲明進行比較。應使用不區分大小寫的方法比較 delegated_to 聲明，且權杖中的 resource_name 應與作業的 resource_name 相符。
    • 確認授權權杖中的 role 聲明是 writer 或 upgrader。
    • 檢查授權權杖中的 kacls_url 聲明是否與目前的 KACLS 網址相符。這項檢查可偵測內部人員或惡意網域管理員設定的潛在中間人伺服器。
    • 使用驗證和授權聲明執行周邊檢查。

  2. 使用經過驗證的加密演算法，加密下列部分：

    • 資料加密金鑰 (DEK)
    • 授權權杖中的 resource_name 和 perimeter_id 值
    • 任何其他機密資料

  3. 記錄作業，包括發起作業的使用者、resource_name 和要求中傳遞的原因。

  4. 傳回不透明的二進位物件，供 Google Workspace 與加密物件一併儲存，並在後續任何金鑰解除包裝作業中原封不動地傳送。或者，提供結構化錯誤回覆。

    • 二進位物件應只包含已加密 DEK 的副本，實作專屬資料可儲存在其中。

解密資料

當 Google Workspace 使用者要求開啟用戶端加密 (CSE) 資料時，Google Workspace 會向您的 KACLS 端點網址傳送 unwrap要求，以便解密。除了選用的安全性檢查 (例如周邊和 JWT 聲明檢查) 外，KACLS 還必須執行下列步驟：

  1. 驗證提出要求的使用者。

    • 驗證驗證權杖和授權權杖。
    • 不區分大小寫比對電子郵件聲明，確認授權和驗證權杖是否屬於同一位使用者。
    • 如果驗證權杖包含選用的 google_email 聲明，則必須使用不區分大小寫的方法，與授權權杖中的電子郵件聲明進行比較。請勿使用驗證權杖中的電子郵件聲明進行這項比較。
    • 如果驗證權杖缺少選用的 google_email 聲明，應使用不區分大小寫的方法，比較驗證權杖中的電子郵件聲明與授權權杖中的電子郵件聲明。
    • 如果 Google 為未與 Google 帳戶建立關聯的電子郵件地址核發授權權杖，則必須提供 email_type 聲明。這是訪客存取功能的重要環節，可為 KACLS 提供有價值的資訊，以便對外部使用者強制執行額外的安全措施。
      • KACLS 可將這類資訊用於下列用途：
      • 強制執行額外的記錄規定。
      • 將驗證權杖核發者限制為專屬的訪客 IdP。
      • 在驗證權杖中要求額外聲明。
      • 如果客戶未設定訪客存取權，系統可能會拒絕所有將 email_type 設為 google-visitor 或 customer-idp 的要求。如果要求具有 google 的 google 或未設定 email_type，應繼續接受。email_type
    • 如果驗證權杖包含選用的 delegated_to 聲明，也必須包含 resource_name 聲明，且這兩項聲明必須與授權權杖中的 delegated_to 和 resource_name 聲明進行比較。應使用不區分大小寫的方法比較 delegated_to 聲明，且權杖中的 resource_name 應與作業的 resource_name 相符。
    • 確認授權權杖中的 role 聲明是 reader 或 writer。
    • 檢查授權權杖中的 kacls_url 聲明是否與目前的 KACLS 網址相符。這樣一來，系統就能偵測內部人員或惡意網域管理員設定的潛在中間人伺服器。

  2. 使用經過驗證的加密演算法解密下列部分：

    • 資料加密金鑰 (DEK)
    • 授權權杖中的 resource_name 和 perimeter_id 值
    • 任何其他機密資料

  3. 確認授權權杖和解密 Blob 中的 resource_name 相符。

  4. 使用驗證和授權聲明執行周邊檢查。

  5. 記錄作業，包括發起作業的使用者、resource_name 和要求中傳遞的原因。

  6. 傳回未包裝的 DEK 或結構化錯誤回覆。