データの暗号化と復号

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

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

データの暗号化

Google Workspace ユーザーがクライアントサイド暗号化（CSE）データの保存または保存をリクエストすると、Google Workspace は暗号化のために wrap リクエストを KACLS エンドポイント URL に送信します。境界や 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 が設定されていないリクエストは、引き続き受け入れられます。
    • 認証トークンの 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 アカウントに関連付けられていないメールアドレスの認証トークンを 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. 認証トークンの resource_name と復号された blob が一致していることを確認します。

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

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

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