グループポリシー（GPO)でGoogle Chromeのプロキシ設定を一元管理する方法

Windows版Google ChromeのプロキシをGPOで一元管理する場合は、公式Chrome Enterpriseテンプレートの複合ポリシーProxySettingsを中心に設計します。現行のProxyModeはdirect、system、auto_detect、fixed_servers、pac_scriptの5種類です。旧ProxyServerModeは非推奨なので新規構成に使いません。まず通信要件、システムプロキシとの分担、PAC障害時に直結を許すか、バイパス範囲、認証、TLS検査、管理元の競合を決めます。検証OUへ配り、chrome://policyでSource・Scope・Status・値を確認してから、社内外、VPN、有線/Wi-Fi、通常/シークレットの実通信を試します。

Chromeだけを管理する理由を明確にする

Windowsにはユーザーのシステムプロキシ、WinHTTP、VPN/セキュリティエージェント、アプリ独自設定があり、同じ「プロキシ」でも対象が違います。Chromeをsystemにすればプラットフォーム設定を利用しますが、WinHTTPを直接参照するすべてのサービスまでChromeポリシーで変わるわけではありません。Windows Update、Office、サービスアカウント、WebView、Firefoxの通信をChrome結果だけで判定しません。

Chrome固有GPOが必要なのは、システム設定と異なる経路をChromeに強制する、管理アカウントに関係なく端末単位で統一する、PACの直結フォールバックを明示する、といった要件がある場合です。単にWindows設定と同じにしたいならsystemを検討し、二重管理を避けます。監査対象、ログ責任者、障害時の連絡先、例外承認者を先に決めます。

対象・通信・例外を読み取りで棚卸しする

Chrome版/チャネル、32/64ビット、ユーザー/端末、既存GPO、クラウド管理、拡張機能、ショートカット引数、Windowsプロキシ、VPN、DNS、証明書を確認します。通信先はインターネット、社内FQDN、IP直指定、localhost、WebSocket、ファイル共有ではなくWeb API、認証基盤、PAC配布元に分けます。現在の設定と成功/失敗URLを記録してから変更します。

プロキシが必要なネットワークと不要なネットワーク、オフライン、キャプティブポータル、在宅回線を代表端末で確認します。バイパス依頼は「社内全部」ではなく、所有者、FQDN/ポート、理由、有効期限、送信データ、直接接続時のファイアウォールを記録します。疎通問題を解決するために全通信直結や*相当の広い除外を入れません。

公式ADMX/ADMLを同じ版で配置する

Google公式Chrome Enterprise BundleのConfiguration/admxからgoogle.admxとchrome.admx、対象言語フォルダーから対応するADMLを取得します。配布元、取得日、版、ハッシュを記録し、非公式ブログのADMや古いテンプレートを混在させません。GPMCでGoogle/Google Chrome配下にProxy設定が表示され、ヘルプのスキーマと5モードが公式ポリシー一覧と一致することを確認します。

ドメインのCentral Storeを使う場合はPolicyDefinitions全体を世代バックアップし、ADMX/ADMLを対で更新してDFSR複製を確認します。検証管理端末だけでGPMCを開き、参照エラーがないことを確認してから他管理者へ案内します。StableとBeta/Devのテンプレート、Google Updaterのテンプレートを取り違えず、テンプレート更新とChrome本体更新の責任を台帳化します。

5つのProxyModeから一つだけ選ぶ

directはプロキシを使わず他フィールドを無視します。systemはシステム設定を使い他フィールドを無視します。auto_detectはWPADで検出し他フィールドを無視します。fixed_serversはProxyServerとProxyBypassList、pac_scriptはProxyPacUrl、ProxyPacMandatory、ProxyBypassListを使います。不要フィールドを同じ辞書へ残しません。

ProxySettingsは一つの辞書として扱います。例えば固定プロキシは{"ProxyMode":"fixed_servers","ProxyServer":"http://proxy.example.com:8080","ProxyBypassList":"*.corp.example.com,<local>"}の形です。実値はGPOテンプレートの説明と公式スキーマへ合わせ、引用符、カンマ、真偽値の型を確認します。ProxyModeだけ別ポリシーで上書きするなど、新旧の個別設定を混在させません。

directとsystemの影響を誤解しない

directはChromeの対象通信をプロキシへ送らない強い指定です。障害回避の一時策として全社へ配ると、フィルタリング、監査、出口制御、DLPを迂回し得ます。ネットワーク側で直接通信が拒否されるか、例外が承認されているかを確認します。プロキシ障害時の緊急経路は、期限、対象OU、承認、監視を持つ別手順にします。

systemはWindows側設定の責任へ戻すモードです。Chrome GPOを未構成にすることと同義ではなく、利用者がChrome内で別モードを選べない管理値です。Windowsのユーザー設定、PAC、自動検出、ネットワークごとの差、ログオン前サービスを別途確認します。Chromeが正常でもWinHTTPアプリが失敗する、またはその逆があり得るため、対象アプリごとにテストします。

auto_detectはWPADのDNS境界まで確認する

auto_detectではWPADがDHCPやDNSからPACを探索します。Chromiumの公式文書ではWindows上でDHCPオプション252を先に、次にDNSを試します。検出の便利さだけで選ばず、DHCP管理、DNSサフィックス検索リスト、wpad名の所有、拠点/ゲスト/VPNの応答、なりすまし防止を確認します。制御できないネットワークでの自動検出を無条件に強制しません。

DNSベースWPADは非FQDNのwpadをサフィックスで補完するため、管理外ドメインが検索リストに入ると攻撃者管理PACを選ぶ危険が公式文書で説明されています。必要なら明示的なHTTPS PAC URLを検討します。auto_detectが失敗したときの挙動、キャプティブポータル、名前解決時間を測り、外出先だけ極端に起動が遅い問題を見逃しません。

fixed_serversはURIと認証を正しく扱う

ProxyServerはhttp://proxy.example.com:8080のようにFQDN、スキーム、ポートを明示します。ChromeはHTTP、HTTPS、SOCKSv4、SOCKSv5、DIRECTの識別子を扱いますが、対応認証とDNS解決場所が異なります。HTTPプロキシはHTTPS宛てをCONNECTで中継しても、プロキシとの通信自体がTLS保護されるHTTPSプロキシとは別です。要件と製品対応を確認します。

Chromeの手動プロキシ設定はURLへ埋め込んだ平文ユーザー名/パスワードを使いません。user:password@proxyをGPOへ保存せず、通常のプロキシ認証、Kerberos/NTLM、証明書、セキュアな認証基盤を設計します。複数経路やDIRECTフォールバックを記述する場合は、障害時に監査を迂回しないかを確認します。可用性目的の直結を暗黙に足しません。

ProxyBypassListはホスト単位で最小化する

Chromeの手動プロキシのバイパスはホストパターン、任意のスキーム/ポート、IPリテラル、単純ホスト名の<local>などを扱います。完全なURLパスを並べるアクセス制御リストではありません。*.corp.example.comはサブドメイン向けで、親ドメイン自体も必要なら別確認します。区切り、ワイルドカード、末尾ドット、IDNを対象版でテストします。

IP範囲のバイパスは、URLのホスト部分が明示的なIPリテラルの場合にだけ一致します。intranet.exampleが私設IPへDNS解決されるからといって、IP範囲ルールで自動バイパスされません。解決後IPで判断したい複雑な要件はPACを検討します。localhostとリンクローカルには暗黙バイパスがあり、セキュリティ上の理由なく<-loopback>で解除しません。

pac_scriptは配布元と失敗時動作を設計する

pac_scriptではProxyPacUrlを、認証情報や個人識別クエリを含まない管理下のHTTPS URLへします。PAC取得は通常ページと異なり、プロキシを通らず、200応答、30秒以内、非圧縮1MB未満が必要です。HTTP認証でUIプロンプトを出せず、クライアント証明書も使えないため、PAC配布元へ全対象ネットワークから安全に到達できるかを実測します。

PACはコードなので、版管理、レビュー、構文テスト、ステージング、監視、二重化、直前版ロールバックを用意します。レスポンスのContent-Type/charsetを明示し、変更直後に全端末へ同時負荷をかけません。端末のIP判定は複数NIC、VPN、IPv4/IPv6で変わるため、myIpAddress()だけへ依存した条件を避け、代表ネットワークでFindProxyForURLの結果を検証します。

ProxyPacMandatoryでfail-open/closedを明示する

Chrome独自PACでProxyPacMandatoryをtrueにすると、PACが無効または取得不能でもDIRECTへフォールバックできず、ERR_MANDATORY_PROXY_CONFIGURATION_FAILEDで通信が失敗します。falseまたは未指定では、PAC取得失敗時に直結へ静かにフォールバックすることがあります。前者は制御を維持しますが業務停止、後者は可用性を保ちますが監査迂回のリスクがあります。

値はセキュリティ担当と業務所有者が決め、障害演習でPACサーバー停止、DNS失敗、証明書期限切れ、VPN切替を再現します。mandatoryをtrueへ変える前に、PAC配布元の可用性と外部ネットワーク到達を確認します。障害時に利用者へレジストリ削除や個人VPNを案内せず、期限付き緊急GPO、サービス復旧、監視通知の順序を文書化します。

TLS検査と認証は別ポリシーとして検証する

プロキシがHTTPSを復号検査する場合、組織CAの安全な配布、秘密鍵保護、対象外カテゴリ、証明書失効、監査、プライバシーが必要です。ChromeのProxySettingsは証明書警告を正当化しません。接続できないサイトのためにSSLエラー回避を全許可したり、証明書検証を無効化したりせず、プロキシ証明書チェーン、SNI、CONNECT、Chrome Root Storeの設計を担当者と確認します。

プロキシ認証ではBasic、Digest、NTLM、Negotiate等の選択、IWA許可先、SPN、時刻、DNSを確認します。Basicを平文HTTPで使わず、サービスアカウントの資格情報をPACやGPOへ埋め込みません。認証ループはChromeプロファイル削除で直すのではなく、401/407、プロキシログ、Kerberosチケット、SPN、Source/Scopeを読み取りで切り分けます。

ユーザー/端末と管理元の競合をなくす

端末全利用者へ同じ経路を強制するならコンピューター構成、部署/利用者ロールで分けるならユーザー構成を検討します。同じ端末で両方へ異なるProxySettingsを入れません。Chrome Enterprise Coreのクラウドマシン、管理Googleアカウントのクラウドユーザー、プラットフォームGPO、拡張機能、手動設定を棚卸しし、どこを正とするか決めます。

chrome://policyではSourceがPlatform、Cloud、Enterprise defaultなど、ScopeがMachine/Current userなどで表示されます。期待値が見えても別ソースの優先度で無効な場合があります。さらにChrome 144以降のProxyOverrideRulesは一致時にProxySettings、拡張API、手動設定より優先されます。現行端末に設定があるか確認し、不要な旧試験ルールを残しません。

chrome://policyと実通信で検証する

GPO更新後にChromeでchrome://policyを開き、Reload policiesを押してProxySettingsを検索します。Valueを展開し、Mode、Server/PAC、Mandatory、Bypass、Source、Scope、Level、Statusを確認します。Unknown、Invalid、Deprecated、Errorを無視せず、GPOのgpresult、レジストリSoftware\Policies\Google\Chrome\ProxySettings、公式スキーマを照合します。

設定画面の「管理されています」表示だけでは経路の証明になりません。HTTP/HTTPS、社内/外部、バイパス対象/非対象、WebSocket、認証あり/なし、VPN接続前後を試し、プロキシ側ログと時刻を照合します。Chromeポリシーは再起動なしで適用可能でも進行中処理には反映されない場合があるため、新しいタブ、完全終了/再起動でも確認します。

NetLogは機密情報として限定取得する

原因が分からない場合はchrome://net-exportで短時間だけNetLogを取得し、問題URLの失敗と比較用成功を再現します。Chromium公式文書ではProxy概要、Original/Effective設定、PAC/WPAD、bad proxy、ネットワーク変更を確認できます。取得前に承認と保存先を決め、余計なタブを閉じ、再現後すぐ停止します。常時収集や利用者全員からの一括回収をしません。

NetLogにはURL、ホスト、タイミング、ヘッダーなど機密情報が含まれ得ます。暗号化されたアクセス制限場所へ保存し、問い合わせ先の要件に沿って最小化/削除します。公開掲示板やチケットへ無加工添付しません。解析後は保持期限で消去します。パケット取得やTLS復号を追加する場合は、権限、個人情報、資格情報への影響が大きいため別承認にします。

段階展開と同時ロールバックを用意する

IT端末、代表部門、限定拠点、全体のリングで展開し、Chrome成功率、PAC取得、407、証明書エラー、ページ時間、プロキシ負荷、ヘルプデスク件数を監視します。ProxySettings、PAC内容、DNS/DHCP、証明書を同時に大変更せず、原因を追える単位にします。Chrome更新前はBetaリングでプロキシ/PAC/認証の回帰試験を行います。

ロールバックはProxySettings辞書全体を直前値または未構成へ戻し、ProxyOverrideRulesなど関連する管理元も確認します。Modeだけ戻してServer/Bypassの旧値を残さず、GPO複製、chrome://policy、実通信、プロキシログを再確認します。未構成ではシステム、クラウド、拡張、利用者設定が表面化し得るため、それを期待値と比較します。利用者プロファイルや全レジストリを削除して戻しません。

確認チェックリスト

• Chrome固有設定とWindows/WinHTTP等の対象を区別した
• 公式ADMX/ADMLと現行ProxySettingsスキーマを使った
• 5つのProxyModeから要件に合う一つを選んだ
• 旧ProxyServerModeや新旧個別ポリシーを混在させていない
• PAC配布元とProxyPacMandatoryのfail-open/closedを試験した
• ProxyBypassListをホスト単位で最小化した
• chrome://policyでSource・Scope・Status・Overrideを確認した
• 実通信、限定NetLog、段階展開、辞書単位ロールバックを用意した

公式情報・参考資料

• Chrome Enterprise：ProxySettingsポリシーの現行スキーマ
• Chrome Enterprise：ProxyOverrideRulesの優先順位
• Chrome Enterprise：Chromeポリシー一覧
• Google Chrome Enterprise Help：公式BundleとADMX/ADMLを取得する
• Google Chrome Enterprise Help：Windowsでポリシーを設定する
• Google Chrome Enterprise Help：chrome://policyで現在値とSourceを確認する
• Chromium公式文書：プロキシ設定とPACの仕様