Microsoft Edgeで許可した拡張機能だけを使えるようにする現行GPOは、ExtensionSettings（拡張機能の管理設定を構成する）を中心に設計します。既定スコープ*のinstallation_modeをblockedにし、承認済みの32文字の拡張機能IDごとにallowedを設定します。自動導入が必要なものだけforce_installedまたはnormal_installedと公式update_urlを指定します。全社適用前に現在の拡張機能、権限、業務用途、保存データを棚卸しし、検証OUで既存拡張の停止影響とロールバックを確認してください。
ExtensionSettingsを現行の中心にする
Microsoftの現行ポリシー資料では、ExtensionSettingsは拡張機能IDまたは更新URLごとの構成と、*による既定構成を一つの辞書で管理し、従来の拡張機能関連ポリシーより優先する仕組みです。旧ExtensionInstallBlocklistとExtensionInstallAllowlistだけの手順を新規標準にせず、競合を避けて集約します。
一方、既存環境が旧ポリシーで安定している場合は、いきなり全削除しません。GPOレポート、Intune、Microsoft Edge管理サービス、レジストリ、edge://policyを調べ、どの管理元が各拡張機能を許可・遮断・強制しているか一覧化します。移行後のJSONと同じ結果を検証してから旧値を廃止します。
導入済み拡張機能を業務用途と権限で棚卸しする
代表端末でedge://extensionsを開き、開発者モードで拡張機能ID、名前、版、配布元、状態を確認します。利用部門、所有者、必要性、更新責任者、要求権限、アクセスするWebサイト、保存データを台帳化します。利用者数がゼロ、所有者不明、同機能が重複する拡張機能は許可候補へ自動追加しません。
Microsoftは、固定的な許可・ブロックだけでなく、要求権限とアクセス可能なホストを基準に管理する方法を推奨しています。閲覧履歴、全サイトの読み取り・変更、ダウンロード、ネイティブメッセージングなどの権限を確認し、社内の認証・人事・財務サイトへ拡張機能を実行させる必要があるかを評価します。
拡張機能IDと配布元を正確に確認する
拡張機能IDは32文字の文字列で、ストアの詳細ページやedge://extensionsから確認できます。表示名が同じでも配布元やIDが異なる場合があるため、検索結果の名称だけを許可一覧へ写しません。Edge Add-onsの発行者、権限、プライバシー情報、最終更新、レビューを確認し、台帳へストアURLとIDを一緒に残します。
Chrome Web Storeや自社配布を許可する場合は、更新URL、署名、配布サーバー、ネットワーク到達性、障害時の更新を追加で管理します。Microsoftは、外部ストアからの強制導入に端末のAD参加またはMicrosoft Entra参加などの条件を設けています。可能ならEdge Add-ons版を優先し、第三者ストア全体を開放しません。
最新MSEdge.admxとADMLを準備する
Edgeの公式ビジネス向けポリシーテンプレートからMSEdge.admxと対応ADMLを取得し、既存Central Storeをバックアップして版を更新します。GPOエディターで「Microsoft Edge」「拡張機能」「拡張機能の管理設定を構成する」が表示され、ポリシー一意名ExtensionSettings、対応Edge版、Mandatory、動的更新の情報を確認します。
MSEdge.admxだけを新しくして古いADMLを残したり、ベータ版と安定版の定義を混ぜたりしません。JSONを入れる前に、対象端末のEdge安定版が対応範囲にあることを確認します。Central Store更新の検証と、拡張機能制御GPOの変更を別の変更記録にすると、表示エラーとポリシーエラーを切り分けられます。
既定ブロックと個別許可のJSONを作る
ExtensionSettingsのJSONでは、{"*":{"installation_mode":"blocked"},"EXTENSION_ID":{"installation_mode":"allowed"}}という形を基本にします。EXTENSION_IDは承認済みの実際の32文字IDへ置き換えます。*は個別スコープのない全拡張機能へ適用され、allowedの個別スコープは利用者によるインストールを許可します。
GPOエディターには改行のない一行JSONを入力します。オンラインの無名整形サイトへ社内IDや機密ホストを貼らず、承認済みのローカルJSON検証ツールで構文を確認します。引用符、波括弧、カンマ、ID重複を機械検証し、整形版と一行版のハッシュを変更記録へ残します。構文エラー時の戻し値も用意します。
個別スコープの継承制約に注意する
Microsoftの仕様では、個別IDの設定がある拡張機能は、その個別スコープだけを使います。*から継承するのはinstallation_modeとupdate_urlに限られ、blocked_permissionsやruntime_blocked_hostsなどの他項目は継承しません。全体で機密サイトを保護したつもりでも、個別許可した拡張へ効かない可能性があります。
許可IDごとに必要なblocked_permissions、runtime_blocked_hosts、runtime_allowed_hosts、minimum_version_requiredなどを明示するか、設計上の例外としてレビューします。既定と個別の有効設定を表で展開し、JSONの見た目だけで判断しません。Microsoftの詳細ガイドにあるスコープ別の利用可能キーも確認します。
allowed・normal・force・removedを選び分ける
allowedは利用者が承認済み拡張を自分で導入できる状態です。normal_installedは自動導入するが利用者が無効化でき、force_installedは自動導入され利用者が無効化・削除できません。強制導入では権限が暗黙に許可されるため、セキュリティや認証など本当に必須な少数に限定します。
removedはインストールを禁止し、既存導入も削除します。全体スコープをremovedにすると広範な削除になり得るため、許可リスト方式の既定はblockedを使います。既存拡張のローカル設定や未送信データを確認せずremovedへ変えません。撤去が必要なら個別ID、利用者通知、データ退避、戻し方を承認します。
自動導入には正しいupdate_urlを指定する
normal_installedまたはforce_installedでは、拡張機能の取得元を示すupdate_urlが必要です。Edge Add-ons版はMicrosoftが指定する公式更新エンドポイントを使い、Chrome Web Store版や自社配布は各マニフェストと公式資料に一致させます。記事のサンプルURLを別拡張へ推測転用しません。
更新URLを上書きするoverride_update_urlは、初回導入だけでなく以後の更新元へ影響します。必要性がなければ有効にせず、発行者署名、TLS、可用性、更新ロールバックを確認します。自社配布サーバーを使う場合、アクセス制御、改ざん検知、証明書更新、CRXと更新マニフェストの版管理を別途設計します。
権限と機密サイトへのアクセスを制限する
blocked_permissionsでは、組織が許容しない権限を要求する拡張機能の利用を抑えられます。runtime_blocked_hostsでは、指定ホスト上でJavaScript挿入、Cookieアクセス、Web要求変更など拡張機能の操作を防げます。Microsoftの詳細ガイドではホスト項目は最大100件で、超過分は破棄されると説明されています。
全社の重要サイトを無計画に100件並べず、認証、決済、人事、管理コンソールなど優先度を決めます。パスは指定できないホストパターンの仕様を確認し、eTLDワイルドカードを理解します。業務拡張が必要なサイトはruntime_allowed_hostsで例外化できますが、個別IDごとにデータアクセスをレビューします。
ブロック理由と例外申請先を表示する
blocked_install_messageを設定すると、利用者が未承認拡張を導入しようとした際に管理者メッセージを表示できます。個人の電話番号ではなく、ヘルプデスクURL、申請番号、必要情報、標準回答時間を案内します。メッセージ自体に社内機密や管理者メールの個人情報を入れません。
例外申請では拡張ID、ストアURL、業務用途、利用者範囲、要求権限、対象サイト、データ種別、代替手段、期限、所有者を求めます。許可後も恒久に放置せず、発行者変更、権限増加、更新停止、脆弱性、利用者数を定期レビューします。一時許可は期限付きセキュリティグループや別GPOで管理します。
GPOを検証OUへ限定して適用する
GPOをバックアップし、専用GPOへExtensionSettingsだけを設定します。コンピューターまたはユーザーのどちらで管理するかを統一し、検証OUと限定セキュリティフィルターへリンクします。既存のEdge基準GPO、Intune、Edge管理サービスがExtensionSettingsや旧リストを配っていないか確認します。
対象プロファイルにも注意が必要です。現行資料ではExtensionSettingsはプロファイル単位で、Microsoftアカウントでサインインしたプロファイルには適用されません。組織プロファイル、個人Microsoftアカウント、ゲスト、InPrivate、共有端末を区別し、必要ならブラウザーのサインイン・プロファイル方針を別ポリシーで管理します。
edge://policyとedge://extensionsで検証する
対象端末で通常のポリシー更新を待つかgpupdateを実行し、Edgeのedge://policyでポリシーを再読み込みします。ExtensionSettingsが表示され、値、レベル、スコープ、ソース、エラーが設計どおりかを確認します。JSONエラーがあれば展開を止め、前の既知値へ戻します。
edge://extensionsでは、許可済みを導入でき、未承認を導入できず、force_installedを利用者が無効化・削除できないことを確認します。既存未承認拡張の状態、ブロックメッセージ、Edge再起動後、複数プロファイル、ストア別を試します。gpresultも併用し、見た目だけで適用元を判断しません。
段階展開とロールバックを用意する
検証後はIT部門、代表業務、小規模本番、全体へ段階展開し、ブロックされた拡張、業務障害、申請数、Edgeエラー、CPU・メモリ、認証・会議・パスワード管理など主要業務を監視します。拡張機能の停止でデータや設定が失われないか、所有者へ確認します。
問題時はExtensionSettingsを全体allowedへ変えて急場をしのがず、影響したIDだけを前のallowedへ戻すか、対象グループを検証GPOから外します。force_installedを一覧から外すと自動アンインストールにつながる場合があるため、データと影響を確認します。既知JSON、GPOバックアップ、適用対象、再試験項目を使い、個別に戻します。
確認チェックリスト
- 現在の拡張ID・配布元・権限・利用者・所有者を棚卸しする
- ExtensionSettingsで既定blockedと個別allowedを一行JSONにする
- 個別IDが権限・ホスト設定を継承しない点を反映する
- force_installed・removedは少数の承認済みIDに限定する
- 組織プロファイルとMicrosoftアカウントの適用差を試す
- edge://policy、edge://extensions、gpresultで段階検証する
許可リスト方式は分かりやすい一方、拡張IDだけを見て安全と判断するのは不十分です。現行EdgeではExtensionSettingsへ集約し、既定ブロック、個別許可、要求権限、機密ホスト、更新元、最小版、申請メッセージを一体で管理できます。特に個別スコープが全体の権限・ホスト制限を継承しない点と、Microsoftアカウントのプロファイル条件を見落とさないでください。既存拡張とデータを棚卸しし、検証OUから段階展開して、ID単位で戻せる構成にします。
公式情報・参考資料
- Microsoft Learn: ExtensionSettings policy
- Microsoft Learn: Detailed ExtensionSettings guide
- Microsoft Learn: Manage Microsoft Edge extensions
- Microsoft Learn: Edge management service extensions
- Microsoft Learn: ExtensionInstallForcelist policy
- Microsoft Learn: Microsoft Edge policy reference
- Microsoft Learn: Configure Microsoft Edge policy settings
コメント