「パスワードは複雑にしているし、2段階認証も全員に設定させています。それなのに、ある社員のGoogleアカウントに、深夜、海外からログインした記録が残っていました」——社員三十名ほどの会社で情シスを兼任している方から、こんな相談を受けました。調べても、パスワードが漏れた形跡はありません。2段階認証の追加確認も、本人は一切していない。それでも、誰かが「ログイン済みの状態」でアカウントに入っていました。
これは「セッション乗っ取り（セッションハイジャック）」と呼ばれる手口で、盗まれているのはパスワードではありません。ログイン済みであることを証明する「セッションCookie」そのものが盗まれています。だからパスワードを変えても、2段階認証をかけても素通りされる。感覚的にいちばん納得しづらい事故です。この攻撃に対して、Chrome（Windows）で DBSC という新しい防御が既定で効き始めました。何をどこまで守れるのかを、管理する側の目線で整理します。
なぜパスワードと2段階認証を突破できるのか
ログインの流れを思い出してください。パスワードを入れ、2段階認証で本人確認をすると、ブラウザには「この人はもうログイン済みです」という通行証が発行されます。これがセッションCookieです。以降しばらくは、この通行証があるだけでパスワードも追加確認も求められずにサービスを使えます。便利さの正体はここにあります。
問題は、この通行証が 持っているだけで通用する 点です。端末に入り込んだ情報窃取型のマルウェア（インフォスティーラー）は、パスワードを解読するのではなく、このCookieをそのまま抜き取って攻撃者のサーバーへ送ります。攻撃者は盗んだCookieを自分のブラウザに読み込ませるだけで、ログイン済みの状態を丸ごと再現できる。パスワードを知らなくても、2段階認証を通らなくても、通行証さえあれば入れてしまうわけです。
規模も小さくありません。セキュリティ各社の集計では、こうして流通する認証情報のパッケージは2025年に前年比7割増で急増しており、その多くに 生きたセッションCookieが含まれ、2段階認証を丸ごと回避できるとされています（SpyCloud: DBSCとセッションハイジャック、Help Net Security）。「うちは2段階認証があるから大丈夫」という前提が、この一点で崩れます。認証まわりの土台をまだ固めていない場合は、先にアカウント乗っ取りとパスキー・2段階認証の記事から押さえておくと、この先の話がつながります。
DBSCは「通行証を端末に縛りつける」
そこで登場したのが DBSC（Device Bound Session Credentials／デバイス バウンド セッション クレデンシャル） です。考え方はシンプルで、通行証を その端末でしか使えないように縛りつける。持っているだけでは通用しない状態にする、という発想です。
仕組みはこうです。ログインすると、ブラウザは端末の中で鍵のペア（公開鍵と秘密鍵）を作ります。Chrome（Windows）ではこの秘密鍵を、PCに載っているセキュリティチップ（TPM）の中に保管し、外に取り出せないようにします。以降、セッションを使い続けるには その秘密鍵を持っていることを定期的に証明する必要があります。攻撃者がCookieだけを盗み出しても、秘密鍵は端末のチップから出てこないため、別のPCでは証明ができず、盗んだCookieが使えなくなる（Chrome for Developers: DBSCがWindowsで利用可能に、Google: DBSCによるCookie保護）。
従来のCookieとの違いを一枚で見ると、変わったポイントがはっきりします。
| 観点 | 従来のセッションCookie | DBSCで保護されたセッション |
|---|---|---|
| 盗んだ後の扱い | 別の端末に貼り付ければ使える | 別の端末では秘密鍵を証明できず使えない |
| 突破される認証 | パスワードも2段階認証も素通り | Cookieだけでは通らない |
| 管理者の設定作業 | ― | 不要（既定で有効） |
中小企業の管理者が押さえるべき前提
実務でありがたいのは、管理者側で有効化の設定が要らないことです。DBSCはChrome（Windows）で既定で動作し、管理コンソールから無効化することもできません。Googleは2026年5月25日から段階的な展開を始めており、通常は数十日ほどで全体に行き渡るとされています（Google Workspace Updates: DBSCがWindows版Chromeで一般提供に）。つまり「自動で効き始める防御」の一つです。こうした既定変更が知らないうちに効く流れは、2段階認証やセキュリティ既定の変更をまとめた記事でも触れたとおりで、情シスの仕事は「効かせる」ことから「効いている前提を最新化する」ことへ移りつつあります。
とはいえ、自動で効くからこそ管理者が確認しておきたい前提があります。DBSCが力を発揮するのは、業務でChromeを使い、WindowsのTPMが有効になっている環境です。裏を返せば、社員が私物ブラウザや古い端末で業務アカウントに入っていると、この防御の外に出ます。まずは「誰が、どの端末の、どのブラウザで業務アカウントにログインしているか」を把握するところが起点になります。端末とアクセスの棚卸しはGoogle Workspace セキュリティ設定チェックリストの項目に組み込んでおくと、抜けにくくなります。
DBSCが「守らないもの」を勘違いしない
ここを取り違えると危険なので、はっきり書きます。DBSCは 盗まれたCookieの再利用を防ぐ仕組みであって、端末そのものが乗っ取られる事態を防ぐものではありません。
たとえば、マルウェアが感染した端末の中で、正規の社員になりすまして操作するようなケースには効きません。秘密鍵はその端末にあるのですから、端末の中で悪用されれば証明は通ってしまいます。同様に、Chrome以外のブラウザや、対応していない環境では、この保護は働きません（Constella: DBSCが防げないこと）。DBSCは「Cookieを盗んで別の場所から入る」という最も多い経路を塞ぐ強力な一手ですが、端末の感染対策・怪しいアプリやリンクへの注意・退職者のアクセス停止といった基本を置き換えるものではない、と理解しておくのが正確です。
まず「自社の入口」を確かめる
DBSCは、管理者が何もしなくても効き始める数少ない「追い風」です。だからこそ、追い風を受けきれる状態か——業務がChromeに寄っているか、端末が最新か、社外の私物端末から業務アカウントに入っていないか——を一度確認しておく価値があります。次の情シス定例では、「うちの社員は、どの端末のどのブラウザで業務アカウントに入っているか」を一覧にするところから始めてみてください。それが、この防御を自社に効かせる最初の一歩になります。
自社のGoogle Workspaceのセキュリティ設定が今の脅威に合っているか棚卸ししたい、端末とアクセスの現状を第三者に点検してほしい——そうしたご相談は、グリームハブのIT・Google Workspace 無料相談からお気軽にお問い合わせください。情シス専任のいない体制に合わせて、無理のない順番で整えるお手伝いをします。お問い合わせからご相談いただけます。
Sources
- Device Bound Session Credentials now available on Windows — Chrome for Developers
- Prevent account takeovers with DBSC, now generally available in Chrome for Windows — Google Workspace Updates
- Protecting Cookies with Device Bound Session Credentials — Google
- What You Need to Know About Google Chrome DBSC — SpyCloud
- To counter cookie theft, Chrome ships device-bound session credentials — Help Net Security
- Google Just Fixed Session Cookie Theft in Chrome. Here Is What It Cannot Stop — Constella
