データの暗号化と復号

このガイドでは、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 のコピーが 1 つだけ含まれている必要があります。実装固有のデータはバイナリ オブジェクトに保存できます。

データの復号

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

  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 または構造化されたエラー応答を返します。