Windowsドメイン環境のGoogle Chromeで拡張機能を制御するなら、現在はChromeの管理用ADMXとグループポリシー（GPO）を使い、ExtensionSettingsへ設定を集約する方法が分かりやすく安全です。基本形は、未承認の拡張機能を既定でブロックし、審査済みの32文字の拡張機能IDだけを個別に許可する構成です。ただし、許可リストは作って終わりではありません。既存拡張機能の棚卸し、必要権限とWebサイトアクセスの審査、検証OUでの動作確認、申請窓口、緊急削除、定期レビューまでを一つの運用として設計します。
現行の中心はExtensionSettingsポリシー
ChromeにはExtensionInstallBlocklist、ExtensionInstallAllowlist、ExtensionInstallForcelistなど従来の個別ポリシーもありますが、Googleの現行資料ではExtensionSettingsがこれらを含む複数の拡張機能設定を制御し、同時に設定された場合は従来ポリシーを上書きします。新規設計ではExtensionSettingsへ集約し、既存環境は旧ポリシーとの競合を調べてから移行すると、最終的な値を説明しやすくなります。
ExtensionSettingsは拡張機能IDまたは更新URLごとの辞書形式で、特殊なキー*を未個別設定のすべての拡張機能に対する既定値として使います。既定をblockedにし、承認済みIDだけをallowedへ上書きすれば許可リスト方式になります。ポリシーはChromeプロファイル単位で適用され、WindowsではレジストリのSoftware\Policies\Google\Chrome\ExtensionSettingsに反映されますが、直接編集せずGPOで管理するのが本記事の前提です。
適用前に既存拡張機能と業務影響を棚卸しする
いきなり全拡張機能をブロックすると、パスワード管理、Web会議、電子署名、DLP、認証、開発支援などの業務が止まる可能性があります。対象Chromeのバージョン、端末とユーザーのOU、現在の管理元、導入済み拡張機能のID・名称・発行元・配布元・利用部門・必須機能・要求権限を一覧化します。個人プロファイル、ゲスト、シークレットモード、未管理端末を業務で許容するかも先に決めます。
承認判断では「Chrome Web Storeにある」だけで安全とみなしません。発行元の実在性と保守状況、プライバシーポリシー、ソースまたは審査資料、要求するAPI権限、閲覧・変更できるサイト、収集データ、外部送信先、アップデート経路、脆弱性対応、代替手段を確認します。Googleは拡張機能の権限リスク評価ガイドを提供しています。広い閲覧権限やcookie、USB、Webリクエストなどを求める場合は、業務上の必要性を個別に説明できるものだけを許可します。
最新のGoogle Chrome ADMXとADMLを準備する
Google Chrome Enterprise Bundleから現行の管理テンプレートを取得し、google.admxとchrome.admx、利用言語に対応するgoogle.admlとchrome.admlを準備します。ドメインでCentral Storeを使う場合は、既存テンプレート一式をバックアップし、検証環境で新旧の定義と表示を確認してから更新します。ADMXだけを更新して古いADMLを残す、または言語フォルダーを間違えるとGPOエディターで表示エラーになります。
GPOエディターで「管理用テンプレート → Google → Google Chrome → 拡張機能」に「拡張機能の管理設定」が表示されることを確認します。Googleのクイックスタートは、ポリシー定義フォルダーへADMX、対応する言語フォルダーへADMLをコピーする手順を示しています。管理テンプレートの更新と拡張機能ポリシーの変更は別の変更記録にし、問題発生時に定義ファイルを戻すのか、設定値を戻すのか判断できるようにします。
許可する拡張機能IDを公式配布元で確認する
Chrome Web Storeの各拡張機能には、バージョンが変わっても共通する32文字のIDがあります。ストアの製品ページURL末尾からIDを取得し、名称、発行元、ストアURL、審査日と一緒に台帳へ保存します。表示名が同じ別製品や検索広告を選ばないよう、発行元とURLを二人で照合します。対象端末のchrome://extensionsで開発者モードを使ってIDを確認する場合も、最終的には承認したストアURLと一致させます。
Web記事や掲示板に載ったIDをそのまま設定しないでください。拡張機能は権限や所有者が更新で変わる可能性があり、IDが同じことは将来も安全である保証ではありません。社内台帳には利用目的、対象者、要求権限、データ分類、所有部門、承認者、更新監視方法、失効条件を記録します。自己配布CRXは、署名、TLS配布、更新マニフェスト、サーバー可用性、鍵の保護まで自社責任になるため、Chrome Web Store版で代替できない理由を明確にします。
既定ブロックと個別許可のJSONを作る
「拡張機能の管理設定」を有効にし、基本形として{"*":{"installation_mode":"blocked","blocked_install_message":"承認済み拡張機能のみ利用できます。申請は社内窓口へ連絡してください。"},"EXTENSION_ID":{"installation_mode":"allowed"}}のような一行JSONを入力します。EXTENSION_IDは説明用の文字列なので、実際には承認済みの32文字IDへ置き換えます。*は個別設定がない拡張機能をブロックし、個別IDのallowedは利用者によるインストールを許可します。
GoogleのWindows向け手順では、GPO欄へ改行なしのコンパクトJSONを入力し、事前にJSON構文を検証するよう案内しています。オンラインの無名JSON整形サイトへ社内IDやURLを貼らず、承認済みのローカルツールで括弧、引用符、カンマ、キー重複を検査します。変更記録には整形前JSON、実際に投入した一行JSON、ハッシュ、対象GPO、変更番号を残します。JSONが壊れているとポリシー全体がエラーになり得るため、一度に大量のIDを追加しません。
allowedと自動インストールを使い分ける
allowedは利用者が承認済み拡張機能を任意にインストールできる状態です。force_installedは自動導入され、利用者は無効化も削除もできません。normal_installedも自動導入ですが利用者が無効化できます。removedはインストールを禁止し、既存の拡張機能も削除します。全社員へ必須のセキュリティ拡張など明確な根拠があるものだけをforce_installedとし、利便性ツールはallowedを基本にします。
自動インストールにはupdate_urlが必要です。Chrome Web Store配布版の公式URLはhttps://clients2.google.com/service/update2/crxです。サンプルURLを別製品へ推測転用せず、配布元と公式資料を照合します。removedは拡張機能内の未同期データや設定を失う可能性があるため、緊急時以外は影響、代替、告知、復旧方法を確認します。force_installedを一括解除すると業務制御が同時に失われるため、ID単位で戻せる設計にします。
ワイルドカードから継承されない項目に注意する
ExtensionSettingsでは、個別IDの設定がある場合に*から継承されるのはinstallation_modeとupdate_urlだけです。Googleのポリシーリファレンスは、その他のプロパティは継承されないと明記しています。たとえば全体の*へblocked_permissionsやruntime_blocked_hostsを書いても、個別にallowedとしたIDへ同じ制限が自動で効くと決めつけてはいけません。
個別許可する拡張機能にも必要なblocked_permissions、runtime_blocked_hosts、runtime_allowed_hostsなどを明示するか、別の統制で補います。機密な認証サイト、管理コンソール、ソースコード、決済、人事システムなどでは、拡張機能によるスクリプト挿入、cookieアクセス、Webリクエスト変更を制限できるか検討します。ホストパターンはパスを含められず上限もあるため、対象範囲を実機で検証し、URL設計だけでデータ保護が完成すると考えません。
GPOのスコープと複数の管理元を整理する
Chromeポリシーはコンピューター構成とユーザー構成のどちらからも設定できます。共用端末を含め端末上の全利用者へ適用するのか、特定のOSユーザーへ適用するのかを決め、専用GPOを検証OUへリンクします。セキュリティフィルター、WMIフィルター、継承ブロック、強制、ループバック処理がある環境では、対象が意図どおりになるかResultant Set of Policyやgpresultで確認します。
Chrome Enterprise CoreやGoogle管理コンソールも利用している場合、プラットフォームポリシー、クラウドのマシンポリシー、ユーザークラウドポリシーが競合する可能性があります。優先順位は設定で変更でき、辞書型ポリシーのマージ設定もあるため、「GPOに書いた値が必ず最終値」とは限りません。新旧GPO、レジストリ直接配布、MDM、クラウド管理を棚卸しし、管理元を一つに寄せるか、優先順位と責任者を文書化します。
chrome://policyで最終値とソースを検証する
検証端末でGPO更新後、Chromeのchrome://policyを開き「ポリシーを再読み込み」し、ExtensionSettingsを絞り込みます。StatusがOK、値が空でないことに加え、適用対象がMachineかCurrent userか、SourceがPlatform、Cloud、Enterprise defaultのどれかを確認します。Googleの資料でも、chrome://policyは端末で有効な最終ポリシーとソースを確認する場所です。GPOエディターの画面だけで展開成功と判断しません。
次に、承認済みIDをChrome Web Storeから導入できること、未承認IDが社内メッセージ付きで拒否されること、既存の未承認拡張機能の挙動、再起動後、別ユーザー、別Chromeプロファイル、オフライン後の挙動を試します。force_installedなら自動導入と無効化不可、normal_installedなら利用者が無効化可能かも確認します。chrome://managementで管理状態を確認し、ログ、ヘルプデスク手順、スクリーンショットを変更証跡へ残します。
検証OUから段階的に展開する
展開順は、IT管理者の検証端末、代表利用者、少人数部門、全社の順にします。各段階で未承認拡張のブロック件数、業務アプリの失敗、認証・会議・電子署名の影響、問い合わせ、Chrome起動時間、クラッシュを観測し、次の段階へ進む承認条件を決めます。締め日前、全社会議、証明書更新などの繁忙期を避け、申請窓口と既知の代替手段を先に案内します。
ロールバックはGPO自体を削除するのではなく、直前に検証したExtensionSettingsの値へ戻す方法を基本にします。GPOのリンク解除は同じGPOに他設定があれば巻き戻し範囲が広くなり、Not Configuredへの変更は端末上の他管理元が表面化する可能性があります。変更前のJSON、GPOバックアップ、対象OU、レプリケーション確認、戻し判定、実施者を用意し、問題のIDだけallowedへ一時復帰できるようにします。
申請と定期レビューで許可リストを維持する
ブロック画面のblocked_install_messageには、個人の連絡先ではなく社内ヘルプデスクURL、申請番号、必要情報、標準回答時間を記載します。申請では拡張機能ID、Chrome Web Store URL、発行元、業務目的、対象者、必要期間、要求権限、アクセスするサイト、扱うデータ、代替手段、所有部門を受け付けます。承認はITだけでなく、情報セキュリティとデータ所有者がリスクに応じて参加します。
少なくとも定期的に、ストア公開状態、所有者変更、権限追加、プライバシー条件、最終更新、利用者数、脆弱性情報、業務必要性を再確認します。使われていないIDは段階的に廃止し、まず新規導入を止め、影響を確認してからremovedを検討します。ストアから非公開になった、悪性判定された、更新サーバーが変わった、権限が大幅に増えたなどの事象を検知した場合に、誰がどのGPOを何分以内に変更するかを手順化します。
緊急時もID単位で安全に封じ込める
許可済み拡張機能に侵害や不正更新の疑いが出た場合は、対象ID、バージョン、影響ユーザー、通信先、発生時刻を保全し、そのIDをremovedまたはblockedへ変更して検証端末で挙動を確認します。全体を無条件ブロックすると認証やセキュリティ拡張まで止まるため、影響ID単位で封じ込めるのが基本です。必要に応じて認証トークンの失効、パスワード変更、端末隔離、ログ調査を別のインシデント対応として実施します。
復旧時は同じIDを即時allowedへ戻さず、発行元の修正版、権限差分、更新経路、侵害範囲を再審査します。Chrome Web Storeから削除された拡張機能を非公式CRXで延命するのは避けます。許可リストは侵入を完全に防ぐ仕組みではなく、導入可能なソフトウェアを限定して攻撃面を縮小する統制です。Safe Browsing、OS・Chrome更新、EDR、DNS・プロキシ、ID保護、データ損失防止、利用者教育と組み合わせて運用します。
確認チェックリスト
- 最新のgoogle.admx・chrome.admxと対応ADMLを検証済みのCentral Storeへ配置する
- 既存拡張機能のID・発行元・権限・利用部門・必要性を棚卸しする
- ExtensionSettingsで既定blocked、承認済みIDだけallowedにした一行JSONを構文検証する
- 個別IDがblocked_permissionsやruntime_blocked_hostsを継承しない点を確認する
- chrome://policyで値、Status、適用対象、Sourceを確認する
- 検証OUから段階展開し、ID単位で戻せるJSONとGPOバックアップを保持する
Chrome拡張機能のGPO制御は、最新ADMXのExtensionSettingsへ設定を集約し、*をblocked、承認済み32文字IDだけをallowedにする構成が基本です。自動導入が本当に必要な拡張機能だけforce_installedを使い、正しいupdate_urlを指定します。さらに、個別IDがワイルドカードの権限制限をすべて継承するわけではない点、クラウド管理との競合、既存拡張の業務影響を見落とさないことが重要です。台帳、審査、申請、段階展開、chrome://policyでの実機確認、緊急削除、定期レビューまで整えて初めて、許可リストが継続的なセキュリティ統制になります。
公式情報・参考資料
- Google Chrome Enterprise Help: Set policies on Windows
- Google Chrome Enterprise Help: Set Chrome app and extension policies on Windows
- Google Chrome Enterprise Help: Configure ExtensionSettings policy
- Chrome Enterprise policy reference: ExtensionSettings
- Google Chrome Enterprise Help: View current Chrome policies
- Google Chrome Enterprise Help: Extension permission risks
- Google Chrome Enterprise Help: Understand Chrome policy management
コメント