データの暗号化と復号

このガイドでは、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 が未設定のリクエストは引き続き承認されます。
    • 認可トークンの 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 が未設定のリクエストは引き続き承認されます。
    • 認可トークンの role クレームが「reader」または「writer」であることを確認します。
    • 認可トークンの kacls_url クレームが現在の KACLS URL と一致していることを確認します。これにより、内部者や不正なドメイン管理者によって構成された潜在的な中間サーバーを見つけることができます。

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

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

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

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

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

  6. ラップ解除された DEK または構造化エラー レスポンスを返します。