セッション バインディングで Cookie の盗難を防ぐ（ベータ版）

管理者は、デバイスにバインドされたセッション認証情報（DBSC）を実装することで、ユーザーのオンライン セッションのセキュリティを強化できます。DBSC は、セッション ハイジャック（Cookie 窃取とも呼ばれます）を防ぐように設計されています。

この種のサイバー攻撃は、ログイン中にウェブサイトから発行されるセッション Cookie（一意のセッション ID を含んだ小さなデータファイル）が盗まれ、不正な第三者がユーザーのアクティブなウェブ セッションを乗っ取ることで発生します。セッションの盗難は、多くの場合、ユーザーのデバイス上のマルウェアによって行われます。セッション Cookie は、ログイン中にウェブサイトから発行される一意のセッション ID を含んだ小さなデータファイルです。攻撃者は、この盗んだ Cookie を提示することで、正当なユーザーになりすまし、認証済みのセッションを続行できます。

DBSC は、ユーザーのセッションを特定のデバイスにバインドすることにより、攻撃者が盗んだ Cookie を他のデバイスで使用することを困難にします。DBSC を使用することで、ユーザー アカウントに対する不正アクセスのリスクを下げ、機微なユーザーデータを安全に保つことができます。

DBSC を使用するための要件

  • Windows 版 Chrome: 現在、DBSC は Windows デバイスの Chrome ブラウザでのみ使用できます。
  • ハードウェア セキュリティ（TPM）: 暗号関連のデータを安全に保存し、処理するために、ユーザーのデバイスはトラステッド プラットフォーム モジュール（TPM）という標準のハードウェア コンポーネントを搭載している必要があります。これは、Windows 11 が稼動しているデバイスであれば、ほとんどのデバイスですでに利用可能です。このハードウェアは、セッションをデバイスにバインドするために使用される暗号鍵を安全に保存します。ユーザーは通常、デバイスのシステム設定を参照するか、デバイス メーカーのドキュメントを参照することで、TPM が搭載されているかどうかを確認できます。
  • Chrome のバージョン: ユーザーは Chrome バージョン 136 以降を使用している必要があります。詳しくは、Google Chrome を更新するをご覧ください。
  • メイン アカウント: DBSC 保護とログイベント データは、Chrome ブラウザ プロファイルのメイン アカウントでのみ 使用できます。

注: セッション バインディングはほとんどの Google Cookie を保護しますが、一部の Cookie または セッションはバインドされないままになる可能性があります。

DBSC を有効にする

始める前に: 必要に応じて、部門またはグループに設定を適用する方法をご確認ください。

  1. Google 管理コンソールで、メニュー アイコン 次に [**セキュリティ**] 次に [**アクセスとデータ管理**] 次に [**Google セッションの管理**] に移動します。

    アクセスするにはセキュリティ設定の管理者権限が必要です。

  2. （省略可）設定を一部のユーザーにのみ適用するには、横にある [組織部門]（主に部署に使用）または [グループ]（高度な設定）を選択します。

    グループの設定は組織部門の設定をオーバーライドします。詳細

  3. [デバイスにバインドされたセッション認証情報] で、[DBSC を有効にする] を選択します。
  4. [保存] をクリックします。または、組織部門の [オーバーライド] をクリックします。

    後で継承値を復元するには、[継承]（グループの場合は [設定解除]）をクリックします。

コンテキストアウェア アクセスで DBSC を強制適用する

デスクトップ ウェブアプリに限定され、モバイルアプリや API には適用されません

特定の Google Workspace アプリにアクセスする際に、ユーザーに対して DBSC を必須にすることで、セキュリティをさらに強化できます。DBSC を強制適用すると、システムが以前に確立されたバインド済みセッションとの違いを検出した場合、ユーザーに再度ログインするよう求められます。この再認証により、システムは新しい安全なバインドを試行できます。サポートされていないプラットフォームのユーザーは、保護されたアプリにアクセスできません。このセキュリティ対策は、コンテキストアウェア アクセスを使用して構成されます。

DBSC の強制適用を設定するには:

  1. 保護するユーザーの DBSC を有効にします。手順については、 DBSC を有効にするをご覧ください。
  2. DBSC セッションからのアプリへのアクセスのみを許可するの手順に沿って、カスタム アクセスレベルを作成します。
  3. モニターモード で、DBSC セッションのみにアクセスを許可したいアプリにアクセスレベルを割り当てることで、ユーザーのアクセスをブロックすることなく適用をシミュレートできます。
  4. 影響を評価したら、アクティブ モード でアクセスレベルを割り当て、DBSC セッションによるアクセスのみを適用します。詳しくは、コンテキストアウェア アクセスを実装する をご覧ください。

DBSC の強制適用は即時ではありません。つまり、ユーザーがログインしてから強制適用されるまでの間に猶予期間があります。このように設計することで、一時的なバインドの問題に対応できます。バインドされると、システムは、指定されたアプリにアクセスするユーザーに DBSC セッションがあるかどうかを定期的にチェックします。再認証を行うとこの猶予期間はリセットされます。また、この再認証の際には DBSC の強制適用は行われません。

DBSC 保護とセッションの問題を調査する

セキュリティ調査ツールを使用して、DBSC 保護をモニタリングし、セッションの中断に関するトラブルシューティングを行うことができます。DBSC アクティビティのログソースは 2 つあります。

  • ユーザーのログのイベント : ユーザー デバイスへのアクセス トークンのバインドをモニタリングします。
  • アクセス評価のログイベント : 特定の Cookie のステータスを確認します。

ステップ 1: ユーザーのログのイベントで DBSC アクティビティを検索する

このデータソースを使用して、DBSC がキーをユーザー デバイスに正常にバインドし、セッションを検証しているかどうかを確認します。

DBSC がキーをバインドしているかどうかを確認するには:

  1. Google 管理コンソールで、メニュー アイコン 次に [**セキュリティ**] 次に [**セキュリティ センター**] 次に [**調査ツール**] に移動します。

    調査ツールを開くには、セキュリティ センターの管理者権限が必要です。

  2. [データソース] で、[ユーザーのログイベント] を選択します。
  3. [条件を追加] をクリックします。
  4. [属性] で、[イベント]次に[次に一致] を演算子として次に[DBSC キーのバインディング] をイベントとして選択します。
  5. [検索] をクリックします。
  6. 結果の表で、[イベントのステータス] 列を確認します。
    • 成功 : ユーザーに対して DBSC 保護が有効になっており、セッションが保護されています。
    • 失敗 : DBSC バインディングに失敗し、ユーザーに対して保護が 有効になっていません。
    • 結果なし—DBSC 保護は、このユーザー セッションでは試行されませんでした。

DBSC がセッションを検証しているかどうかを確認するには:

  1. Google 管理コンソールで、メニュー アイコン 次に [**セキュリティ**] 次に [**セキュリティ センター**] 次に [**調査ツール**] に移動します。

    調査ツールを開くには、セキュリティ センターの管理者権限が必要です。

  2. [条件を追加] をクリックします。
  3. [属性] で、[イベント]次に[次に一致] を演算子として次に[DBSC キーの検証] をイベントとして選択します。
  4. [検索] をクリックします。
  5. 結果の表で、[イベントのステータス] 列を確認します。
    • 成功 : Cookie の検証が正常に完了しました。
    • 失敗 : DBSC 検証に失敗しました。ステータス をクリックすると、エラーコードなどの詳細情報が表示されます。

1 回の失敗で、必ずしもユーザーのセッションが中断されるとは限りません。検証が連続して複数回失敗すると、中断が発生する可能性があります。

ステップ 2: アクセス 評価のログイベントでアクセス拒否を確認する

このデータソースを使用して、ユーザーの Cookie へのアクセスが拒否されたかどうかを確認します。

  1. Google 管理コンソールで、メニュー アイコン 次に [**セキュリティ**] 次に [**セキュリティ センター**] 次に [**調査ツール**] に移動します。

    調査ツールを開くには、セキュリティ センターの管理者権限が必要です。

  2. [データソース] で、[アクセス 評価のログイベント] を選択します。
  3. [条件を追加] をクリックします。
  4. For [Attribute], select [Event]次に[Is] as the operator次に[Deny Cookie Validation Request] as the event.
  5. [検索] をクリックします。
  6. 結果の表で、[拒否]を [イベントのステータス]列でクリックするか、 [説明]列のリンクをクリックしてサイドパネルを開き、 次の失敗理由を確認します:
    • DBSC_BOUND_COOKIE_MISSING
    • DBSC_BOUND_COOKIE_CORRUPTED
    • DBSC_BOUND_COOKIE_EXPIRED

ログイベントはセッションごとにグループ化されます。その間に複数のアクセス試行がブロックされた場合でも、ユーザーごとに 1 時間に 1 つのイベントのみが記録されます。

ステップ 3: セッションの中断の原因が DBSC かどうかを調査する

セッションの長さの制限 、管理者定義のポリシー、ネットワークの問題など、さまざまな理由でユーザーがログアウトされることがあります。ログアウトは必ずしも DBSC の問題を示すものではありませんが、特定のログシーケンスは、DBSC 関連のアクティビティや、システムが侵害されたセッションをブロックしたインスタンスを特定するのに役立ちます。

次の点を確認して、DBSC 関連のアクティビティを特定します。

  • ログシーケンスを確認する : [DBSC キーの検証] の失敗の後に [Cookie 検証リクエストを拒否] が続く場合は、DBSC がユーザーのログアウトの原因である可能性があります。
  • ユーザーへの影響を把握する : アカウントを安全に保つため、バインド プロセスでエラーが発生した場合は、ユーザーが再度ログインする必要があります。
  • DBSC からユーザーを除外する: ユーザーが常に ログアウトする場合は、DBSC から除外される設定グループを作成し、 そのグループにユーザーを追加して、ログアウトの原因が DBSC かどうかを評価できます。


Google、Google Workspace、および関連するマークとロゴは、Google LLC の商標です。その他すべての企業名および商品名は関連各社の商標です。