セッション盗難という「静かな脅威」に、Googleがハードウェアで応答した

Googleは2026年4月、Chrome 146（Windows版）にDevice Bound Session Credentials（DBSC）を正式実装した。狙いはシンプルだ——インフォスティーラーと呼ばれるマルウェアによるセッションクッキーの窃取を、ソフトウェアではなくハードウェアの力で原理的に無効化すること。macOS版は追って対応予定とされており、今後のアップデートで順次展開される。

これはセキュリティ界隈の地味なアップデートに見えるかもしれないが、実際には「パスワードを知らなくてもアカウントに侵入できる」という長年の攻撃手法に対する、構造的な回答である。

なぜセッションクッキーが狙われるのか

Webアプリケーションでは、ログイン後にサーバーが発行するセッションクッキーが認証トークンとして機能する。有効期限が来るまでの間、このクッキーさえあればパスワードなしで認証が通る。

問題は、このクッキーがローカルのファイルやメモリに保存される点だ。LummaC2をはじめとするインフォスティーラー型マルウェアは、こうしたデータを組織的に収集してC2サーバーへ送信する手口を洗練させてきた。多要素認証（MFA）を突破しなくても、セッションを「そのまま使い回す」ことで正規ユーザーになりすませてしまう。

Googleが公式見解として「ソフトウェアだけではクッキーの流出を防ぐ信頼できる手段がない」と明言しているのは、この構造的な弱さへの正直な認識である。

DBSCが解決する仕組み

DBSCは、セッションをデバイスのセキュリティチップに暗号的にバインドするプロトコルだ。WindowsではTPM（Trusted Platform Module）、macOSではSecure Enclaveが使われる。

仕組みの要点は以下のとおり：

  • セッションごとに固有の公開鍵/秘密鍵ペアをセキュリティチップが生成する
  • 秘密鍵はチップ外にエクスポートできない
  • 新しいセッションクッキーの発行には、Chromeがサーバーに対して「この秘密鍵を保持している」ことを証明する必要がある
  • 秘密鍵を持たない攻撃者がクッキーを盗み出しても、すぐに無効化される

設計上、プライバシーへの配慮もある。セッションごとに異なる鍵を使うことで、複数サービス間での行動追跡に利用されない構造になっている。サーバー側へ送信されるのはセッションごとの公開鍵のみで、デバイス識別情報は含まれない。

このプロトコルはGoogleとMicrosoftが共同開発し、W3Cでオープン標準として策定が進む。Okta等との実証実験では、セッション盗難の件数が顕著に減少したとGoogleは報告している。

日本のエンジニア・IT管理者にとっての実務的意味

管理者が今すぐやるべきこと

  • Chrome 146以降への更新管理を確認する: Intune・GPO等でバージョンポリシーを管理している組織では、DBSC有効化のためにChrome 146以降を対象バージョンに含める必要がある
  • TPMの有効化状態を棚卸しする: DBSCはTPMに依存する。TPMが無効・未搭載のデバイスではこの保護が効かない。特に古い社用PCが混在する環境では要注意だ
  • SaaSのDBSC対応状況を把握する: ウェブアプリ側もバックエンドに登録・リフレッシュ用エンドポイントを追加する必要がある。主要SaaSベンダーの対応ロードマップを確認しておきたい

開発者向けの視点

自社サービスでDBSCを実装する場合、GoogleのDBSC実装ガイドとW3Cの仕様書が公開されている。既存フロントエンドとの互換性を維持しつつ、バックエンドにエンドポイントを追加するだけで対応できる設計になっており、段階的な導入が可能だ。

注意点

DBSCはあくまでセッション盗難後の横展開を防ぐ仕組みであり、マルウェア感染そのものを防ぐものではない。エンドポイント保護（EDR等）との組み合わせが前提となる。「Chromeがアップデートされたから安心」という過信は禁物だ。

筆者の見解

セキュリティの話は正直に言えば得意分野ではないが、このDBSCのアプローチは技術的に筋が通っていると感じる。「ソフトウェアだけではクッキー流出を防げない」というGoogleの認識は、ゼロトラストの文脈で語られてきた「ネットワーク境界では守れない」と同じ構造的な問いへの誠実な回答だ。

TPMやSecure Enclaveといったハードウェアの信頼の根（Root of Trust）を利用してセッションをバインドする発想は、Just-In-Timeアクセスと同じ方向性を持つ。「常時使えるトークンではなく、特定の文脈でのみ有効な証明」という考え方は、特権アカウント管理の理想形に近い。

GoogleとMicrosoftがこのプロトコルを共同で開発し、W3Cで標準化を進めているのも重要な点だ。ベンダー固有の実装ではなくオープン標準として育てることで、SaaSエコシステム全体への普及が現実的になる。

一方で、展開には時間がかかる。TPMが普及していない古いデバイスが残存する環境、DBSCに未対応のSaaS、macOS版の対応待ち——現実の企業環境は「理想の状態」からはほど遠い。この技術が「当たり前の防御層」として機能するには、サーバーサイドの対応が広がるまで数年単位の時間軸で考える必要がある。

その間も、インフォスティーラーの攻撃は止まらない。DBSCを「将来の保険」として認識しつつ、今日できるEDRの強化・TPMの有効化・セッション有効期限の短縮といった対策を地道に積み上げることが、現実的な判断だと思う。

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