Google WorkspaceのDBSCとは？ChromeのセッションCookie盗難対策と管理者が見るべき設定
Google Workspaceを使う企業では、パスワードや2段階認証だけでなく、ログイン後のセッションをどう守るかが重要になっています。端末内のCookieが盗まれると、攻撃者が正規ユーザーのログイン状態を悪用するリスクがあるためです。
DBSC（Device Bound Session Credentials）は、このログイン後のセッションを利用端末に結びつけるためのChromeの保護機能です。Google WorkspaceではWindows版Chromeで一般提供され、管理者は「有効化するか」よりも「どの端末で効くか」「監査ログで何を見るか」「他のセキュリティ設定とどう組み合わせるか」を確認する必要があります。
結論として、DBSCはセッションCookie盗難対策の新しい防御層です。Cookieそのものをなくす仕組みではありませんが、盗まれたCookieだけで別端末からセッションを再利用しにくくします。Google Workspace管理者は、Chrome利用状況、端末管理、監査ログ、Context-Aware Accessとの組み合わせで運用を点検するのが実務的です。
本記事のポイント
- DBSCはログイン後のセッションCookieを端末に結びつけ、Cookie窃取によるアカウント乗っ取りリスクを下げる仕組みです。
- Google WorkspaceではWindows版Chromeで既定有効化されるため、管理者は有効化作業よりも対象端末、監査ログ、例外端末の確認に注力します。
- DBSCだけでゼロトラストが完成するわけではなく、Context-Aware Access、2段階認証、共有監査、端末管理と組み合わせることが重要です。
この記事で扱うテーマ
関連キーワード
- Google Workspace DBSC
- DBSC とは
- Device Bound Session Credentials とは
- Chrome セッション Cookie 盗難 対策
- Google Workspace セッションバインディング
- Google Workspace Cookie 盗難 対策
- Context-Aware Access DBSC
- Google Workspace 監査ログ DBSC
このページで答える質問
- Google WorkspaceのDBSCとは何ですか？
- DBSCはセッションCookie盗難対策として何を守る仕組みですか？
- Google Workspace管理者はDBSCについて何を確認すべきですか？
- DBSCとContext-Aware Accessや監査ログはどう組み合わせますか？
DBSCとは何か
DBSCは、Device Bound Session Credentialsの略です。ログイン後に発行されるセッション情報を、認証した端末と結びつけることで、盗まれたセッションCookieの悪用を難しくします。
通常、WebサービスはCookieを使って「このユーザーはログイン済みである」と判断します。攻撃者がマルウェアなどでCookieを盗むと、パスワードや2段階認証を突破しなくても、ログイン済み状態を再利用できる場合があります。DBSCは、このセッションを端末側の条件と結びつけ、別端末でそのまま使い回しにくくする考え方です。
Google Workspace Updatesでは、Windows版ChromeでDBSCが一般提供され、Google Workspaceユーザー向けに既定で有効になると説明されています。公式情報は Google Workspace UpdatesのDBSC告知 を確認してください。
| 観点 | DBSCで見ること | 管理者が確認すること |
|---|---|---|
| 守る対象 | ログイン後のセッション | 重要アプリへのログイン状態がどう維持されているか |
| 主なリスク | セッションCookieの窃取 | 端末感染、ブラウザ拡張、盗難端末、個人端末利用 |
| 効き方 | セッションを端末に結びつける | Windows版Chromeの利用状況と端末管理の状態 |
| 運用確認 | 監査ログでイベントを追う | Security Investigation Toolや管理コンソールでの確認手順 |
Google Workspace管理者が見るべき設定とログ
Google WorkspaceでDBSCを見るとき、最初に確認するのは「有効化ボタン」ではありません。Workspace Updatesの告知では、対象ユーザーには既定で有効になり、管理者が無効化する設定はないとされています。したがって、管理者の役割は、DBSCが効く前提で端末・ブラウザ・監査ログを整えることです。
特に確認したいのは次の4点です。
- Chromeの利用範囲：業務端末でChromeが標準ブラウザとして使われているか。
- 対象OS：DBSCの一般提供対象となるWindows版Chromeが、主要な利用端末をどれだけカバーしているか。
- 監査ログ：DBSCのバインディングイベントを、Security Investigation Toolなどで確認できるか。
- 例外端末：Mac、モバイル、個人端末、古いOSなど、DBSCの恩恵を受けにくい端末がどこに残るか。
DBSCは「何もしなくても全部安全になる」機能ではありません。むしろ、端末管理やログ確認が弱い組織では、効いている範囲と効いていない範囲が見えないままになります。Google Driveや共有ファイルの監査は Google Drive監査ログの見方、Workspace全体の管理者確認は Workspace Studioを安全に有効化する管理者チェックリスト とあわせて整理すると実務に落とし込みやすくなります。
DBSCだけで防げること、防げないこと
DBSCはセッションCookie盗難対策として有効な防御層ですが、すべてのアカウント乗っ取りを防ぐ仕組みではありません。どこまで期待できるかを分けて考えることが大切です。
| リスク | DBSCの効き方 | 追加で必要な対策 |
|---|---|---|
| 盗まれたCookieの別端末利用 | 悪用しにくくする | 端末管理、監査ログ、リスク検知 |
| パスワード流出 | 直接は防がない | 2段階認証、パスキー、漏えい検知 |
| 端末そのものの感染 | 被害拡大を抑える一要素 | EDR、OS更新、拡張機能管理 |
| 過剰なファイル共有 | 直接は防がない | DLP、共有監査、外部共有ルール |
| 退職者・異動者の権限残り | 直接は防がない | アカウント棚卸し、権限レビュー |
たとえば、共有ドライブの外部共有が広すぎる場合、DBSCでログイン後のセッションを守っても、公開範囲そのものの問題は残ります。外部共有の点検は 共有ドライブの外部共有設定 を確認してください。
Context-Aware Accessと組み合わせる考え方
DBSCは、Context-Aware Access（CAA）と組み合わせると意味が分かりやすくなります。DBSCが「ログイン済みセッションを利用端末に結びつける」防御層だとすると、CAAは「どの条件の端末・ユーザー・ネットワークならアクセスを許可するか」を制御する層です。
実務では、次のように役割を分けて設計します。
| 層 | 主な役割 | 確認ポイント |
|---|---|---|
| 本人確認 | ユーザーが本人かを確認する | 2段階認証、パスキー、ログイン通知 |
| 端末条件 | 業務利用に適した端末かを見る | OS、Chrome、端末管理、会社所有端末 |
| セッション保護 | ログイン後のセッション悪用を抑える | DBSC、セッションイベント、異常ログイン |
| アクセス制御 | 条件に合わないアクセスを止める | Context-Aware Access、アプリ別ポリシー |
| データ保護 | アクセス後の共有・持ち出しを抑える | DLP、Drive共有監査、ラベル、承認フロー |
営業やカスタマーサクセスの現場では、CRM、提案資料、契約前情報、顧客名簿がGoogle Workspaceに集まりがちです。Google WorkspaceをCRM的に使っている場合は、Google Workspace CRM や Workspace DLPによるCRMデータ保護 とセットで見ると、セッション保護とデータ保護の境界が明確になります。
導入後のチェックリスト
DBSCが既定で有効化されるとしても、管理者側のチェックは必要です。次の観点で棚卸しすると、セキュリティ部門だけでなく、営業・マーケティング・CS部門にも説明しやすくなります。
- 対象範囲：主要な業務端末がWindows版Chromeを使っているか確認する。
- 例外端末：Mac、モバイル、BYOD、共有PCなど、別管理が必要な端末を洗い出す。
- 監査ログ：DBSC関連イベントを誰が、どの頻度で確認するか決める。
- インシデント対応：Cookie窃取や端末感染が疑われたときの停止・再認証・端末隔離手順を決める。
- 利用者説明：ユーザー側に追加設定が不要なことと、端末更新・Chrome更新を止めないことを周知する。
AIエージェントや自動化ツールをGoogle Workspaceに接続する場合も、セッション・権限・監査ログの設計は欠かせません。AI活用側の権限設計は AIエージェントの権限設計、監査ログの基本設計は AIエージェント監査ログテンプレート も参考になります。
よくある質問
DBSCとは何ですか？
DBSCはDevice Bound Session Credentialsの略で、ログイン後のセッションを利用端末に結びつける仕組みです。盗まれたCookieだけでは別端末からセッションを再利用しにくくするため、アカウント乗っ取り対策の一部として使われます。
DBSCを使えば2段階認証は不要になりますか？
不要にはなりません。2段階認証はログイン時の本人確認、DBSCはログイン後のセッション悪用を抑える防御層です。役割が違うため、併用するのが前提です。
Google Workspace管理者はDBSCを有効化する必要がありますか？
Workspace Updatesの告知では、対象ユーザーでは既定で有効になり、管理者が無効化する設定はないとされています。実務上は、有効化作業よりも、対象端末、監査ログ、例外端末、他のアクセス制御との組み合わせを確認することが重要です。
DBSCはMacやモバイルにも効きますか？
一般提供の告知対象はWindows版Chromeです。Mac、モバイル、BYOD端末では別の管理策が必要になる場合があります。組織内の端末構成を棚卸しし、DBSCでカバーされない利用経路を確認してください。
DBSCとContext-Aware Accessはどう違いますか？
DBSCはログイン後のセッションを端末に結びつける保護層です。Context-Aware Accessは、ユーザー、端末、場所、ネットワークなどの条件に基づいてアクセス可否を制御する仕組みです。セッション保護とアクセス制御を分担する関係です。
関連ページと関連記事
- Gemini for Workspaceの入力データは学習に使われる？：Workspaceで扱うデータの保護設定を確認できます。
- Google Drive監査ログの見方：共有変更や外部共有を追う手順を確認できます。
- Google Workspace共有ドライブの外部共有設定：DBSCでは防げない共有範囲の問題を点検できます。
- Workspace Studioを安全に有効化する管理者チェックリスト：権限・監査・共有範囲を横断的に確認できます。
- Google Workspace CRMとは？：営業・CSデータをWorkspaceで扱う場合の設計を確認できます。
Google Workspaceのセキュリティ運用を見直したい方へ
DBSC、Context-Aware Access、Drive監査ログ、DLP、端末管理は、それぞれ単体で見るよりも「どの業務データを、どの端末から、誰が、どこまで扱うか」で整理すると判断しやすくなります。営業・マーケティング・CSでGoogle Workspaceを使っている場合は、顧客データの保管場所、共有範囲、監査ログ、AI連携の範囲までまとめて点検することが重要です。
