Google は2026年5月、Chrome の新セキュリティ機能「Device Bound Session Credentials（DBSC）」の一般提供を開始し、全ユーザーへの展開を始めた。セッションクッキーをデバイスのTPMやSecure Enclaveに暗号的に紐付けることで、クッキーを盗み出されても攻撃者が悪用できない状態にする仕組みだ。

セッションクッキー盗難の何が問題か

多要素認証（MFA）が普及した今も、「クッキー窃取→アカウント乗っ取り」という攻撃手法は現役で使われ続けている。ブラウザがログイン状態を記憶するために保存するセッションクッキーを入手すれば、攻撃者はパスワードもワンタイムコードも不要でアカウントにアクセスできてしまうからだ。

代表的な情報窃取型マルウェアである Lumma や Rhadamanthys は、Google の OAuth 「MultiLogin」APIエンドポイントを悪用して期限切れのクッキーを再生する機能まで実装していた。これに対してGoogleはこれまで「マルウェアを除去せよ」「Enhanced Safe Browsingを有効にせよ」と呼びかけるしかなかった——DBSC以前は、クッキーが盗まれた時点でほぼ詰みだった。

DBSCの仕組み——鍵はハードウェアの外に出ない

DBSCはセッションクッキーを特定デバイスのハードウェアセキュリティチップに暗号的に紐付ける技術だ。

  • Windowsの場合: TPM（Trusted Platform Module）
  • macOSの場合: Secure Enclave

セッション確立時にセキュリティチップが公開鍵・秘密鍵のペアを生成し、クッキーの暗号化・復号に使用する。秘密鍵はチップの外に一切出ないため、マルウェアがクッキーファイルを盗み出しても、対応する秘密鍵なしには使えない状態になる。

Googleは「事後検知から事前防止へのパラダイムシフト」と表現しており、「クッキーが盗まれること自体を防ぐ」のではなく「盗まれたクッキーを使えない状態にする」という設計思想がポイントだ。

展開状況と管理者が知っておくべき制約

DBSCは現在、以下のアカウントへ順次展開中だ。

  • Google Workspace 企業ユーザー
  • Workspace Individual サブスクライバー
  • 個人Googleアカウント利用者

管理者にとって重要なのは、Google Workspaceでは管理者がDBSCを無効化できない点だ。有効化はデフォルトで行われ、管理コンソールからのオプトアウトは提供されない。ユーザー体験に影響が出た場合でも、設定で戻す手段がないことを事前に把握しておく必要がある。

実務への影響——日本のエンジニア・IT管理者が押さえるべき点

1. TPMの搭載・有効化状況を確認する

DBSCはTPM対応デバイスを前提とする。Windows 11がTPM 2.0を必須要件とした背景と整合しているが、古いPCや設定上TPMが無効になっている環境では効果が限定的になる可能性がある。BIOS/UEFIでTPMが有効になっているかを一度確認しておきたい。

2. InfoStealer対策はEDRと組み合わせて多層化する

DBSCはクッキー盗難の「悪用」を防ぐが、マルウェアの侵入自体を防ぐわけではない。EDR（エンドポイント検知・対応）によるマルウェアの早期検知と組み合わせることで、多層防御が初めて完成する。

3. ログ監視の重点を移行する準備を

クッキー再利用による不審なセッション異常が今後減っていく代わりに、攻撃者はフィッシングやクレデンシャルスタッフィングなど別の初期アクセス手段に移行する可能性が高い。セキュリティ監視の重点を「セッション系の異常」から「認証試行の異常パターン」にシフトさせる準備を始めたい。

4. サードパーティサービスへの普及は時間がかかる

現時点でDBSCが有効に機能するのはGoogleサービス向けに限られている。一般のWebサービスがDBSCのAPIを実装するまでの「過渡期」は相応の時間がかかるため、過信は禁物だ。

筆者の見解

「MFAを突破できるのだからMFAは意味がない」という言説がSNSでたびたび流れるが、これは正確ではない。問題の本質はMFAの弱さではなく、認証後のセッション管理の甘さにある。DBSCはその弱点を、既存のクレデンシャル管理フローを変えずにハードウェア層で塞ぐ設計だ。「禁止」ではなく「仕組みで安全にする」という方向性は、IT現場で機能する本物のセキュリティ対策の正道だと思う。

ゼロトラストの文脈で言えば、「デバイスの信頼性を認証フローに織り込む」という考え方はまさに原則に忠実だ。これまでデバイスの信頼性はネットワーク層やMDM（モバイルデバイス管理）で担保しようとしてきたが、DBSCはブラウザのセッション層でも同じ思想を実現した点が評価できる。

ただし懸念もある。Workspaceの管理者が無効化できない設計は、エンタープライズ環境でのトラブル対応を難しくする可能性がある。新機能の強制展開は互換性問題が出たときの退避策がないという意味でリスクでもある。Googleがこの点についてどう対応するか、引き続き注目したい。

出典: この記事は Google Chrome adds session cookie theft protection for all users の内容をもとに、筆者の見解を加えて独自に執筆したものです。