データの暗号化と復号

このガイドでは、Google Workspace Client-side Encryption API を使用して暗号化と復号を行う方法について説明します。

ユーザーが使用する ID プロバイダ（IdP）サービスを許可リストに登録する必要があります 暗号化されたファイルの共有もできます。通常、必要な IdP の詳細は .well-known ファイルそれ以外の場合は、組織の IdP の詳細に対する Google Workspace 管理者。

データの暗号化

Google Workspace のユーザーがクライアントサイド暗号化が適用された保存または保存をリクエストしたとき （CSE）データを送信すると、Google Workspace は wrap 暗号化のために KACLS エンドポイント URL に送信されます。オプションの セキュリティ チェック（境界や JWT クレームベースのチェックなど）を使用するには、KACLS を使用して 次の操作を行います。

  1. リクエストしているユーザーを検証します。

    • 両方の認証トークンを検証する および認可トークンです。
    • 次の方法で、認証トークンと認証トークンが同じユーザーのものであることを確認 メールによる申し立てに対して大文字と小文字を区別しない一致を行います。
    • 認証トークンにオプションの google_email クレームが含まれている場合、 その認証トークンを認可トークン内のメール クレームと比較する必要がある 大文字と小文字を区別しません。メールによる申し立てを あります。
    • 認証トークンにオプションの google_email クレーム。認証トークン内のメール クレーム 認証トークンのメールによる要求と比較する必要がある 大文字と小文字は区別されません。
    • Google がメールに対して認証トークンを発行し、認証が email_type クレームが存在する必要があります。 これはゲストアクセス機能の重要な部分であり、 追加のセキュリティ対策を KACLS が できます。
      • KACLS によるこの情報の使用例を次に示します。
      • 追加のロギング要件を課すため。
      • 認証トークンの発行元を専用のゲスト IdP に制限する。
      • 認証トークンに対する追加のクレームを要求する。
      • お客様がゲストアクセスを構成していない場合、すべてのリクエストは ここで、email_type は google-visitor に設定されます。また、customer-idp は、 拒否されます。email_type が google または未設定のリクエスト email_type は引き続き承認されます。
    • 認証トークンの role クレームが「writer」であることを確認するまたは 「upgrader」です。
    • 認証トークンの kacls_url クレームが 現在の KACLS の URL を入力します。このチェックにより 内部または不正なドメインによって構成された中間者サーバー できます。
    • 認証と認可の両方を使用して境界チェックを実行する

  2. 認証された暗号化アルゴリズムを使用して、次の部分を暗号化します。

    • データ暗号鍵（DEK）
    • 認証トークンの resource_name 値と perimeter_id 値
    • その他のセンシティブ データ

  3. 操作（起点となったユーザー、resource_name、 リクエストで渡された理由。

  4. Google Workspace で保存される不透明なバイナリ オブジェクトを返します。 暗号化され、その後の鍵のラップ解除ではそのまま送信されます。 あります。構造化されたエラー リプライを提供する。

    • バイナリ オブジェクトには、暗号化された DEK の唯一のコピーが含まれている必要があります。 実装固有のデータを格納できます。
で確認できます。

データの復号

Google Workspace ユーザーがクライアントサイド暗号化（CSE）データを開くようリクエストすると、 Google Workspace が unwrap リクエストを送信します。 KACLS エンドポイント URL に追加して復号します。セキュリティ オプションには、 チェック（境界や JWT クレームベースのチェックなど）を使用するには、KACLS が 次のとおりです。

  1. リクエストしているユーザーを検証します。

    • 両方の認証トークンを検証する および認可トークンです。
    • 次の方法で、認証トークンと認証トークンが同じユーザーのものであることを確認 メールによる申し立てに対して大文字と小文字を区別しない一致を行います。
    • 認証トークンにオプションの google_email クレームが含まれている場合、 その認証トークンを認可トークン内のメール クレームと比較する必要がある 大文字と小文字を区別しません。メールによる申し立てを あります。
    • 認証トークンにオプションの google_email クレーム。認証トークン内のメール クレーム 認証トークンのメールによる要求と比較する必要がある 大文字と小文字は区別されません。
    • Google がメールに対して認証トークンを発行し、認証が email_type クレームが存在する必要があります。 これはゲストアクセス機能の重要な部分であり、 追加のセキュリティ対策を KACLS が できます。
      • KACLS によるこの情報の使用例を次に示します。
      • 追加のロギング要件を課すため。
      • 認証トークンの発行元を専用のゲスト IdP に制限する。
      • 認証トークンに対する追加のクレームを要求する。
      • お客様がゲストアクセスを構成していない場合、すべてのリクエストは ここで、email_type は google-visitor に設定されます。また、customer-idp は、 拒否されます。email_type が google または未設定のリクエスト email_type は引き続き承認されます。
    • 認証トークンの role クレームが「reader」であることを確認するまたは 「writer」。
    • 認証トークンの kacls_url クレームが 現在の KACLS の URL を入力します。これにより、潜在的な中間者を検出できます。 内部または不正なドメイン管理者が設定したサーバーを 保護します

  2. 認証された暗号化アルゴリズムを使用して、次の部分を復号します。

    • データ暗号鍵（DEK）
    • 認証トークンの resource_name 値と perimeter_id 値
    • その他のセンシティブ データ

  3. 認証トークンと復号された blob の resource_name を確認する 一致します。

  4. 認証クレームと認可クレームの両方を使用して、境界チェックを実行します。

  5. 操作（起点となったユーザー、resource_name、 リクエストで渡された理由。

  6. ラップ解除された DEK または構造化エラー リプライを返します。

で確認できます。