二段階認証やパスキーを設定したのに、なぜかアカウントが乗っ取られる――そんな報告が後を絶たない。背景には、パスワードそのものではなくログイン後に発行される「セッションCookie」を狙う手口がある。攻撃者は認証を破らず、認証済みの状態を丸ごと盗む。Google Chromeが2026年4月からWindows版で展開を始め、8月にはmacOS版への拡大も報じられたDevice Bound Session Credentials(DBSC)は、盗まれたCookieだけでは使えなくする技術だ。ただし守られる条件は限られている。

AD

Cookieは盗めても署名はできない、DBSCが断つ鍵の在り処

ログインの瞬間、ブラウザは公開鍵と秘密鍵のペアをその場で生成する。秘密鍵はWindowsならTPM(Trusted Platform Module、PCに搭載されるセキュリティ機能。独立チップのほか、CPU内蔵のfTPMとして実装される場合もある)に、macOSならSecure Enclaveと呼ばれる専用の隔離領域に格納され、OSからもアプリからも取り出せない。ここが従来のCookie窃取対策と決定的に違う点だ。ただしChromeの開発者向け資料は、セッション登録の瞬間に端末上でマルウェアが動作していた場合は鍵の抽出を完全には排除できないと注記している。

セッションを保つCookie自体は短時間で失効するよう設計されている。失効するたびにChromeはリフレッシュ用のエンドポイントへ、秘密鍵で署名した証明を送って新しいCookieを受け取る。マルウェアがブラウザのプロファイルからCookieファイルをまるごと盗み出しても、この署名だけは作れない。秘密鍵はハードウェアの中に留まったままだからだ。

この一連のやり取りが機能するには、ブラウザ側の対応だけでは足りない。実装するWebサービス側もリフレッシュエンドポイントに対応している必要がある。Googleは自社サービスにこの仕組みを組み込んでいるが、他のWebサービスが同じ仕組みを採用するかどうかは、それぞれの実装計画次第になる。

Report URIの創業者であるScott Helme氏は、この仕組みの核心を「攻撃者はデバイスから秘密鍵を盗めない」「Cookieは盗めても、端末に保管された秘密鍵で署名してDBSCチャレンジに応答することはできない」と説明している。この指摘が示すのは、DBSCの防御力を支えているのが複雑な暗号理論というより、秘密鍵を物理的に外へ出さないという単純な原理だという点だ。公開鍵暗号によるチャレンジ・レスポンス方式そのものは目新しくない。パスキーがログイン時の認証をこの方式に置き換えたのに対し、DBSCはログイン後のセッション維持に同じ発想を持ち込んだ。守る対象が「入り口」から「入った後の時間」へ広がった違いだ。

Cookieの有効期限を短く保つこと自体は、以前からある防御策の一つだった。ただし失効後の再発行を人間の再ログインに頼っていては利便性を損なう。DBSCは、その再発行を秘密鍵による自動署名に置き換えることで、ユーザー体験を保ったまま安全性を底上げした。

パスキーが固めた入り口の代わりに、攻撃者が狙ったのがセッションそのものだった

パスワード窃取を狙うフィッシングは、二段階認証とパスキーの普及で突破されにくくなったとされる。攻撃者が次に向かったのが、認証を突破する代わりに認証済みの状態そのものを盗む手口だ。infostealerと呼ばれる情報窃取型マルウェアや、AiTM(Adversary-in-the-Middle、中間者攻撃型のフィッシング)はブラウザに保存されたセッションCookieを丸ごと抜き取り、パスワードや二段階認証を経由せずログイン中のアカウントへ入り込む。AiTMはユーザーと本物のログインページの間に攻撃者のサーバーを割り込ませ、通信を中継しながらパスワードと二段階認証のやり取りをそのまま横取りする手口だ。認証が完了した瞬間に生成されるセッションCookieを攻撃者がリアルタイムで複製すれば、二段階認証を突破する手間なくログイン状態を丸ごと引き継げる。

脅威インテリジェンス企業Flashpointの調査によると、2025年上半期だけでinfostealerは580万台の端末から18億件を超える認証情報を窃取した。2025年に入ってから800%の増加だという。Verizonの2025年版データ侵害調査報告書(DBIR)によれば、認証情報の不正利用は侵害事案の初期アクセス経路として22%を占め、単独では最も多い侵入口になっている。

この半年間の数字を1台あたりに割り戻すと規模感がつかみやすい。18億件を580万台で割ると、1台の端末から平均310件前後のログイン情報が流出した計算になる。1つのメールアドレスに紐づくSNS・通販・銀行・業務アプリのアカウントを数え上げれば、1台の端末が普段使う認証情報の大半をカバーする桁数だ。

infostealerが盗み出したCookieやログイン情報は、そのままダークウェブ上のマーケットで転売されることが多い。買い手は転売されたセッションを使えば、パスワードや二段階認証を突破する手間なくアカウントへ入り込める。侵害の起点がフィッシングメールの1通であっても、被害の広がり方は転売市場の存在によって桁違いになる。DBSCが狙うのはまさにこの経路だ。Cookieというファイルそのものを盗まれても、それだけではログインの継続に必要な署名ができない設計にすることで、infostealerの主力戦術を鈍らせる。

AD

Windows版は4月に展開開始、macOS版はどこまで進んでいるか

Google公式ブログ(2026年4月9日付)によれば、DBSCはOrigin Trial(限定公開の試験提供)を経て、2026年3月に安定版公開されたChrome146上でWindows版ユーザー向けの展開が始まった。以降はブラウザの自動更新を通じて対応端末へ順次配布されている。Origin Trialは、新機能を一部の開発者やサイトに限定公開し、実運用でのフィードバックを集めてから広く展開する仕組みだ。DBSCはこの試験期間を経て、ブラウザ単体の実験的機能から日常的な認証基盤の一部へと格上げされた。

企業向けのGoogle Workspaceでは、2026年5月25日から段階的な展開が始まり、無料の個人アカウントを含む全顧客へ最大60日かけてデフォルト有効化が広がる設計になっている(Google Workspace Updatesはこの展開開始を正式版(GA)化と位置づけている)。管理者側での設定操作は不要だ。Workspaceのような大規模テナントでは、全世界のアカウントへ機能を一斉に反映するとサーバー負荷やサポート対応が急増しかねないため、数週間かけて段階的に展開するのが一般的な進め方になる。

Ars Technica(2026年8月11日)は、この機能を担うバージョンとしてChrome147(Windows)・150(macOS)を挙げ、対象は限定的なユーザーにとどまると報じている。Google公式ブログが明記するWindows版のGAバージョン(Chrome146)とは数字が一致しない。この食い違いは、GA後に配布が進んだ最新パッチバージョンとの単純な差か、あるいはmacOS版など一部ユーザー向けの限定的な追加展開を指すとみられる。macOS向けのSecure Enclave連携は、Ars記事の報道時点でもChrome150の限定ユーザー向けにとどまり、Windows版のような広い展開には至っていない。

OktaとMicrosoft Entraも同じ鍵を握っている、ただし無料ではない

端末に紐づけた鍵でセッションを守る発想はGoogle独自のものではない。IDプラットフォームのOktaは、デバイスに紐づくSSO(シングルサインオン)機能を提供し、登録済み端末からのアクセス時にサインオンポリシーを評価してセッションを固定する仕組みを持つ(2026年8月時点でEarly Access機能)。「盗んでも使えない」セッション管理を目指す方向性はDBSCと重なる。

Microsoftも同様の防御をEntra ID(旧Azure AD)のToken Protectionという機能で提供している。Conditional Access(条件付きアクセス)のポリシーを通じてサインイントークンを特定の端末に固定する仕組みで、トークンを盗んでも別の端末では使えなくする狙いはDBSCと同じだ。ただし対象はEntraに参加・登録済みのWindows端末と対応アプリ・リソースに限られ、この機能自体もEntra ID P1という有料ライセンスの契約者向けに限られる。

同じ技術思想を、Googleは個人アカウントを含む全ユーザーへ無償でデフォルト有効にし、Microsoftは法人向けの追加課金メニューに置いた。ID管理業界全体がハードウェア紐づけの鍵という同じ答えにたどり着きつつある一方、その答えに誰が無償でアクセスできるかは提供元ごとに割れている。恩恵を受けるのはGoogleやOkta、Microsoftのようなベンダーと対応端末を使う利用者であり、盗んだCookieを転売するダークウェブ市場やinfostealerの運用者は締め出される側に回る。ただし後述するTPM非搭載機やDBSC未対応のサードパーティWebサービスを使い続けるユーザーは、この恩恵の外側に置かれたままになる。

AD

この鍵にも死角がある、W3C自身が認める限界とソースが語らない取り残され

DBSCを標準化しているW3C Web Application Security Working Groupの仕様README(GitHub上で公開)には、この技術が防げない範囲が明記されている。攻撃者がすでに端末を侵害し、そのユーザーエージェントを継続的に操作している間の一時的なセッションアクセスまでは防げないという一文だ。リモートアクセス型のマルウェアが感染端末上で動作し続けている状況を例に取ると、秘密鍵は端末の外へ出ないため盗み出しはできないが、攻撃者は端末上で鍵を使う権限ごと乗っ取ったまま、正規のブラウザセッションになりすまして操作を続けられる。DBSCが防ぐのは「Cookieだけを持ち出して別の端末から使う」窃取であり、端末を乗っ取られたまま使われ続ける状況までは対象外だ。

保護が始まるタイミングにも区切りがある。DBSCは新規に開始されるセッションにのみ適用され、機能が有効になった時点で既にサインイン済みだったユーザーは、一度サインアウトして再度サインインしない限りセッションが鍵に紐づかない。ログイン済みのまま放置された端末では、この保護がまだ働いていない可能性がある。

Ars Technicaの記事もGoogleの公式発表も、この保護がTPMやSecure Enclaveという特定のハードウェアを前提にしている点についてはあまり踏み込んでいない。TPMを搭載しない、あるいはBIOS上で無効化されたままの旧型PCは、Chromeが対応バージョンに更新されてもDBSCの保護対象から外れる。Windows 11が必須要件に定めるTPM 2.0と同種の線引きが、ここでも実質的に生まれている。

Chrome以外のブラウザを使うユーザーの扱いも整理されないままだ。DBSCはChromiumエンジンに実装された機能であり、FirefoxやSafariのユーザーは対応サービス側が別途対策を講じない限り、これまで通りの露出にさらされる。DBSCはW3Cで標準化作業が進む段階にあり、まだ勧告(Recommendation)としては確定していない。MozillaやAppleがいつ追随するかについて、公式な言及は見当たらない。

Workspace利用企業が次にすべきなのは、端末棚卸しだ

Google Workspaceを使う日本企業にとって、Windows版DBSCは特別な導入作業なしに恩恵を受けられる数少ないセキュリティ強化の一つだ。管理者がコンソールで何かを切り替える必要はなく、対象端末がTPMを搭載しChrome146以降に更新されていれば、新規に開始されるセッションから保護が働く。ただし機能有効化前からサインインしたままの端末は、一度サインアウトしてサインインし直すまで対象にならない。

長期利用のノートPCやBYOD端末の中にTPM非搭載機が混ざっていれば、同じ社内ネットワークの中で守られる従業員と守られない従業員が同時に存在することになる。特に更新サイクルが長い部署ほど、TPM非搭載機が残っている可能性は高い。IT部門がまず確認すべきは、Workspaceの設定より先に、手元の端末台帳がTPMの搭載状況を把握しているかどうかだ。

同じ理屈は自社で運営するWebサービスにも当てはまる。ブラウザがDBSC対応でも、サービス側がリフレッシュエンドポイントを実装していなければ効果は生まれない。社外向けにログイン機能を提供する企業であれば、自社の認証基盤がこの仕組みに対応する計画を持っているかどうかを、次の見直しのタイミングで確認する価値がある。ChromeやWorkspace以外の環境、たとえばFirefoxやSafariを使い続ける従業員には、この保護が及ばないことを前提に、二段階認証の徹底など従来型の対策を並行して続ける必要がある。

パスキーは認証の瞬間を、DBSCはログインした後の時間を、それぞれ端末に固定された鍵で守る。この2つが揃って初めて、盗まれた認証情報でもCookieでも突破できないセッションに近づく。ただしその線引きの外側、TPM非搭載機と非対応ブラウザには、これまでと変わらない攻撃面が残ったままだ。