データの暗号化と復号

このガイドでは、Google Workspace クライアントサイド暗号化 API を使用した暗号化と復号の仕組みについて説明します。

暗号化されたファイルを共有するユーザーが使用する ID プロバイダ（IdP）サービスを許可リストに追加する必要があります。通常、必要な IdP の詳細は一般公開されている .well-known ファイルに記載されています。記載されていない場合は、組織の Google Workspace 管理者に IdP の詳細についてお問い合わせください。

データの暗号化

Google Workspace ユーザーがクライアントサイド 暗号化（CSE）データの保存または格納をリクエストすると、Google Workspace は暗号化のために鍵アクセス制御リスト サービス（KACLS）のエンドポイント URL に wrap リクエストを送信します。境界や JWT クレームに基づくチェックなどのオプションのセキュリティ チェックに加えて、KACLS は次の手順を実行する必要があります。

  1. リクエスト元のユーザーを検証します。

    • 認証 トークンと認可 トークンの両方を検証します。
    • メール クレームで大文字と小文字を区別しない照合を行い、認可トークンと認証トークンが同じユーザーのものであることを確認します。
    • 認証トークンにオプションの google_email クレームが含まれている場合は、大文字と小文字を区別しない方法で認可トークンのメール クレームと比較する必要があります。この比較には、認証トークン内のメール クレームを使用しないでください。
    • 認証トークンにオプションの google_email クレームがない場合は、大文字と小文字を区別しない方法で、認証トークン内のメール クレームを認可トークンのメール クレームと比較する必要があります。
    • Google が Google アカウントに関連付けられていないメールアドレスの認可トークンを発行する場合は、email_type クレームが存在する必要があります。 これはゲスト アクセス機能の重要な部分であり、外部ユーザーに対して追加のセキュリティ対策を適用するために KACLS に役立つ情報を提供します。
      • KACLS がこの情報を使用する方法の例をいくつか示します。
      • 追加のロギング要件を課す。
      • 認証トークン発行者を専用のゲスト IdP に制限する。
      • 認証トークンに追加のクレームを要求する。
      • お客様がゲスト アクセスを構成していない場合、email_type が google-visitor または customer-idp に設定されているリクエストはすべて拒否できます。email_type が google のリクエスト、または email_type が設定されていないリクエストは引き続き受け付ける必要があります。
    • 認証トークンにオプションの delegated_to クレームが含まれている場合は、resource_name クレームも含まれている必要があります。また、これらの 2 つのクレームを認可トークンの delegated_to クレームと resource_name クレームと比較する必要があります。delegated_to クレームは、大文字と小文字を区別しない方法で比較する必要があります。トークン内の resource_name は、オペレーションの resource_name と一致する必要があります。
    • 認可トークンの 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 は復号のために KACLS エンドポイント URL に unwrap リクエストを送信します。境界や JWT クレームに基づくチェックなどのオプションのセキュリティ チェックに加えて、KACLS は次の手順を実行する必要があります。

  1. リクエスト元のユーザーを検証します。

    • 認証 トークンと認可 トークンの両方を検証します。
    • メール クレームで大文字と小文字を区別しない照合を行い、認可トークンと認証トークンが同じユーザーのものであることを確認します。
    • 認証トークンにオプションの google_email クレームが含まれている場合は、大文字と小文字を区別しない方法で認可トークンのメール クレームと比較する必要があります。この比較には、認証トークン内のメール クレームを使用しないでください。
    • 認証トークンにオプションの google_email クレームがない場合は、大文字と小文字を区別しない方法で、認証トークン内のメール クレームを認可トークンのメール クレームと比較する必要があります。
    • Google が Google アカウントに関連付けられていないメールアドレスの認可トークンを発行する場合は、email_type クレームが存在する必要があります。 これはゲスト アクセス機能の重要な部分であり、外部ユーザーに対して追加のセキュリティ対策を適用するために KACLS に役立つ情報を提供します。
      • KACLS がこの情報を使用する方法の例をいくつか示します。
      • 追加のロギング要件を課す。
      • 認証トークン発行者を専用のゲスト IdP に制限する。
      • 認証トークンに追加のクレームを要求する。
      • お客様がゲスト アクセスを構成していない場合、email_type が google-visitor または customer-idp に設定されているリクエストはすべて拒否できます。email_type が google のリクエスト、または email_type が設定されていないリクエストは引き続き受け付ける必要があります。
    • 認証トークンにオプションの delegated_to クレームが含まれている場合は、resource_name クレームも含まれている必要があります。また、これらの 2 つのクレームを認可トークンの delegated_to クレームと resource_name クレームと比較する必要があります。delegated_to クレームは、大文字と小文字を区別しない方法で比較する必要があります。トークン内の resource_name は、オペレーションの resource_name と一致する必要があります。
    • 認可トークンの role クレームが reader または writer であることを確認します。
    • 認可トークンの kacls_url クレームが現在の KACLS URL と一致することを確認します。これにより、内部関係者や不正なドメイン管理者によって構成された中間者サーバーを検出できます。

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

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

  3. 認可トークンと復号された BLOB の resource_name が一致していることを確認します。

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

  5. オペレーションをログに記録します。これには、オペレーションを開始したユーザー、resource_name、リクエストで渡された理由が含まれます。

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