GPOでGoogle Chromeから特定サイトへのアクセスを止めるには、管理対象ブラウザーへ`URLBlocklist`を配布します。例外を許可する場合は`URLAllowlist`を併用します。フィルターはスキーム、ホスト、ポート、パス、クエリの構造で評価され、単純な文字列一致ではありません。ブラウザーだけの制御なので、Edge、アプリ内WebView、コマンド、別回線まで止めるセキュリティ境界にはなりません。
まず監査対象と業務影響を確認し、少人数へブロックを適用します。全URLを遮断して許可リストだけにする構成は、OS認証・更新・業務連携を壊す可能性があるため段階設計が必須です。
ブロック条件を具体化する
- ドメイン全体か、特定ホストか、特定パスだけか
- HTTP/HTTPSの両方か、特定ポートか
- サブドメインを含めるか、正確なホストだけか
- 利用者全体か、部署・端末・共有キオスクだけか
- 業務上必要な例外URL、認証、CDN、API、ダウンロード先
- 期限付きの緊急ブロックか恒久ポリシーか
Google公式のフィルター形式は`[scheme://][.]host[:port][/path][@query]`です。`example.com`は通常サブドメインにも一致し、先頭のドットを付けた`.www.example.com`は正確なホスト一致に使います。パスは大文字小文字を区別します。同じ精度でBlockとAllowが競合する場合はAllowが優先されます。
管理テンプレートとGPO
Chrome Enterprise公式テンプレートのADMX/ADMLをCentral Storeへ導入し、既存版をバックアップします。レジストリを端末ごとに手編集せず、検証GPOを作ります。ユーザー構成とコンピューター構成のどちらへ置くかは端末利用形態で決め、同じポリシーを複数階層へ重複設定しません。
- 検証用ユーザー・端末と、ブロックしても業務影響のないテストURLを用意します。
- URLBlocklistに目的のフィルターを一件だけ登録します。値の番号や書式を公式テンプレートUIで確認します。
- 必要な例外がある場合だけURLAllowlistへ、より具体的なフィルターを登録します。
- GPOを検証OUへリンクし、ポリシー更新後にChromeを再起動します。
- chrome://policyでURLBlocklist/URLAllowlistの値、ソース、エラーを確認します。
- リンク、直接入力、HTTP/HTTPS、サブドメイン、パス、別プロファイルで動作を試します。
Googleを例にするときの注意
`https://www.google.com/`をブロックする例は確認しやすい一方、検索、reCAPTCHA、SSO、フォント、地図、Chromeサービスなど業務へ広く影響し得ます。本番テストには自組織の無害な検証URLを用い、主要外部サービスを遮断しません。ブロック画面のスクリーンショットに社内ポリシー情報が出る場合は公開しないでください。
全遮断＋許可リスト方式
特殊値で広く遮断し、業務URLだけAllowlistにするキオスク設計も可能ですが、Chrome内部URL、拡張機能ページ、プラットフォーム固有New Tabは別扱いになることがあります。Google公式資料は、`*`が内部chrome://等を自動的にすべて含むわけではないと説明しています。更新、証明書失効確認、認証CDN、サポート接続を含む依存関係を洗い出します。
反映されない・範囲が違う場合
- chrome://policyで値が読み込まれ、ステータスがOKか
- フィルターのスキーム、先頭ドット、ポート、末尾パス、クエリ
- BlockとAllowのうち、より長いホスト・パス・クエリがどちらか
- Chromeクラウド管理、MDM、ローカルGPOとの優先順位
- 対象ユーザーが正しいGPOセキュリティフィルターに含まれるか
- ブラウザー再起動後も別プロファイルやゲストモードで同じか
回避経路と多層防御
利用者がEdge、Firefox、スマートフォン、IP直打ち、VPN、プロキシを使えば、Chromeポリシー外の経路が残ります。規制・情報漏えい対策が目的なら、セキュアWebゲートウェイ、DNSフィルタリング、ファイアウォール、端末アプリ制御、ID条件付きアクセスと組み合わせます。Chromeブロック画面を安全性の証明としません。
利用者通知と例外
ブロック理由、開始日、対象、代替サービス、申請窓口を案内します。例外はホスト全体ではなく必要パス、部署、期間へ限定し、承認者と終了日を記録します。個人の送信元IPを恒久許可する方式は動的IPと侵害端末に弱いため避けます。
ロールバック
GPOとリストを事前バックアップし、誤遮断時は追加したフィルターだけを削除または旧リストへ戻します。全Chromeポリシーを未構成にしないでください。適用後、chrome://policyから該当値が戻り、業務URL、認証、更新が復旧したことを確認します。緊急解除の承認者と連絡経路を決めておきます。
フィルター例を作るとき
記事や手順書には実在の重要サービスを遮断する例ではなく、組織が所有するテストドメインや`example.com`を使います。ただしexample.comを実際の本番リストへ入れる必要はありません。フィルター例には「正確なホスト」「サブドメイン込み」「特定パス」の期待結果表を添えます。
URLには国際化ドメイン、エンコード、末尾スラッシュ、リダイレクト、短縮URLなどがあります。ブラウザーが正規化した後のURLで評価されるため、アドレスバー表示と実際の要求ホストをNetworkログで比較します。認証情報やクエリ値は記録から除きます。
Allowlistの落とし穴
Blocklistで広く止め、Allowlistでログインページだけ許可しても、認証後の別ホスト、静的資産、API、ファイル配信が止まることがあります。ブラウザー開発者ツールとベンダー公式の許可先一覧で依存ドメインを確認します。ワイルドカードを広げて解決しません。
許可エントリがブロックより具体的なら優先されるため、意図しないパスまで許可していないかを試します。クエリ条件は順序やトークンの扱いを公式仕様で確認し、秘密値をポリシーへ埋め込みません。
ブロック画面の問い合わせ対応
利用者からはURL、時刻、業務目的、表示メッセージ、端末資産番号を受け取ります。ページ全体のスクリーンショットには個人情報が映るため必要部分だけにします。ヘルプデスクはポリシーエラー、正規ブロック、ネットワーク障害を区別します。
緊急例外を利用者がローカルレジストリで作る手順は提供しません。承認後に中央ポリシーの限定グループへ追加し、終了時に自動削除できる運用にします。
監査と見直し
ブロックリストの所有者、理由、根拠、追加日、終了日、例外を記録します。ドメイン所有者が変わる、サービスが別CDNへ移る、脅威が解消するなど変化があります。四半期ごとに到達試験ではなく、必要性と範囲をレビューします。
Chromeのポリシー上限や仕様は更新されるため、固定の「1000件まで」だけを前提に設計しません。現在の公式ポリシー一覧で上限と対応版を確認し、巨大なリストはセキュアWebゲートウェイへ移します。
法務・人事要件との調整
Webサイト制限が就業規則、学校利用、法令、契約に基づく場合は、記録の透明性、異議申立て、例外、個人利用の扱いを法務・人事と決めます。アクセスログを必要以上に長く保存せず、閲覧権限と利用目的を明示します。技術的にブロックできることと、監視・制限が適切であることは別です。
コメント