Microsoft Global Secure Access を運用している管理者にとって、ブロックページの追加は「画面が少し親切になる」だけの変更ではありません。これまでユーザーには、単なる接続エラーやブラウザーの警告に見えることがあり、ヘルプデスクには「サイトが落ちている」「ネットワーク障害ではないか」という問い合わせが集まりがちでした。
2026年4月16日時点で確認できる Microsoft Entra の更新では、Global Secure Access の新機能として block pages が追加されています。これにより、管理者は組織向けのメッセージを表示し、ブロック理由・問い合わせ先・社内ポリシーへのリンクをユーザーに伝えやすくなります。特に Network security admins と helpdesk leads にとっては、ユーザー体験、トラブルシューティング、ポリシー透明性を同時に改善できる実務上の重要アップデートです。(TECHCOMMUNITY.MICROSOFT.COM)
Microsoft Global Secure Access の block pages とは
Microsoft Global Secure Access の block pages は、Internet Access ポリシーによってユーザーの Web アクセスがブロックされたときに、組織独自の案内を表示できる機能です。
Global Secure Access は、Microsoft Entra Internet Access と Microsoft Entra Private Access を含む Microsoft の Security Service Edge、いわゆる SSE ソリューションです。Microsoft Entra 管理センター内で、インターネット、SaaS、プライベートリソースへのアクセス制御を統合的に扱うための領域として提供されています。(Microsoft Learn)
今回の block pages は、その中でも主に Microsoft Entra Internet Access のアクセス制御に関わる機能です。Web content filtering や threat intelligence filtering によってアクセスがブロックされた場面で、ユーザーに「なぜアクセスできないのか」「どうすればよいのか」を伝えるために使います。Microsoft Learn の手順では、Global Secure Access の設定から Custom Block Page を有効化し、本文メッセージやリンクを設定できます。(Microsoft Learn)
従来のブロック挙動では、ユーザーから見ると「接続がリセットされた」「ブラウザーのエラーが出た」といった状態になり、セキュリティポリシーによるブロックなのか、通信障害なのかが判断しにくいケースがありました。Web content filtering の検証手順でも、HTTP ではプレーンテキストのエラー、HTTPS では Connection Reset のようなブラウザーエラーが発生することが説明されています。(Microsoft Learn)
block pages の価値は、この曖昧さを減らす点にあります。ユーザーにとっては状況が分かりやすくなり、ヘルプデスクにとっては問い合わせの一次切り分けがしやすくなり、セキュリティ管理者にとってはポリシー適用の説明責任を果たしやすくなります。
なぜ block pages が重要なのか
Global Secure Access のような SSE 製品では、ポリシーが正しく機能していても、ユーザー体験が悪いと「ネットワークが不安定」「仕事を邪魔する仕組み」と受け止められることがあります。
特にインターネットアクセス制御では、ユーザーが次のように感じやすくなります。
- 仕事で必要なサイトなのに、なぜ開けないのか分からない
- ブラウザーのエラーなので、通信障害だと思ってしまう
- どこに問い合わせればよいか分からない
- 一時的な不具合なのか、会社のルールなのか判断できない
block pages は、こうした不満を完全になくす機能ではありません。しかし、「ブロックされた事実」と「次に取るべき行動」を画面上で伝えることで、サポート負荷を下げる効果が期待できます。
たとえば、ユーザーに次のようなメッセージを表示できます。
このサイトへのアクセスは、会社のインターネット利用ポリシーにより制限されています。業務上必要な場合は、申請フォームから例外申請を行ってください。
この一文があるだけで、ユーザーは「Wi-Fi が壊れている」「VPN が不調」「サイトが閉鎖された」といった誤解をしにくくなります。ヘルプデスク側も、問い合わせを受けた時点で「Global Secure Access のポリシーに関係する可能性が高い」と判断しやすくなります。
block pages で変わるユーザー体験
block pages の最も分かりやすい効果は、エンドユーザーの混乱を減らせることです。
これまでのように接続エラーだけが表示される場合、ユーザーは原因を推測するしかありません。特に SaaS、生成AIサービス、ファイル共有サイト、SNS、個人メールなどは、業務利用と私的利用の境界が曖昧なことがあります。単にブロックするだけでは、ユーザーから「なぜこのサイトだけ使えないのか」という不満が出やすくなります。
block pages を使うと、管理者はブロック時の画面に組織固有の説明を入れられます。Microsoft Learn では、既定の本文を組織のスタイルガイドに合わせたメッセージに変更でき、限定的な Markdown 形式でクリック可能なリンクも設定できると説明されています。(Microsoft Learn)
ユーザーに伝えるべき情報
ブロックページには、長い規程文をそのまま載せるよりも、ユーザーがその場で判断できる情報を短く載せるほうが実用的です。
| 表示する情報 | 目的 | 具体例 |
|---|---|---|
| ブロックされた理由 | 障害ではなくポリシー適用だと伝える | 「このサイトは情報漏えいリスクのあるカテゴリに分類されています」 |
| 次の行動 | ユーザーの迷いを減らす | 「業務上必要な場合は、例外申請フォームから申請してください」 |
| 問い合わせ先 | ヘルプデスクへの連絡を標準化する | 「問い合わせ時はアクセス先URLと時刻を記載してください」 |
| 社内ポリシーへのリンク | ポリシー透明性を高める | 「インターネット利用ガイドラインを確認する」 |
| 緊急時の代替手段 | 業務停止を避ける | 「顧客対応で緊急の場合は上長承認後にIT窓口へ連絡」 |
重要なのは、ユーザーに責任を押し付ける文面にしないことです。
「禁止されています」とだけ表示すると反発を招きやすくなります。代わりに、「情報保護とマルウェア対策のため、組織のポリシーにより制限されています」と書くと、制御の目的が伝わります。
ヘルプデスクの問い合わせ対応がどう変わるか
block pages は、helpdesk leads にとっても大きな意味があります。新しい enforcement UX、つまりポリシー適用時の見え方が変わると、ユーザーからの問い合わせが増えることがあります。特に展開直後は、「今まで見たことのない画面が出た」という問い合わせが発生しやすくなります。
ただし、適切に設計された block pages は、中長期的には問い合わせの質を改善します。
問い合わせ内容が「ネットがつながらない」から「このブロックページが表示された。業務上必要なので例外申請したい」に変わるためです。これはヘルプデスクにとって非常に大きな違いです。
問い合わせの一次切り分け例
| ユーザーの申告 | 想定される原因 | ヘルプデスクの初動 |
|---|---|---|
| ブロックページが表示された | Global Secure Access のポリシー適用 | URL、ユーザー、時刻、表示文言を確認 |
| Connection Reset が出る | TLS inspection 未対象、または別の通信要因 | GSA クライアント、転送プロファイル、ログを確認 |
| 特定ユーザーだけ開けない | 条件付きアクセスやグループ割り当ての差分 | 対象ユーザーの CA ポリシーと security profile を確認 |
| 全員が同じサイトを開けない | Web content filtering または threat intelligence の一致 | 対象ドメインの分類、許可リスト、ポリシー優先度を確認 |
| 申請済みなのにまだブロックされる | 反映待ち、セッション、キャッシュの影響 | 反映時間、セッション失効、ブラウザーキャッシュを確認 |
Microsoft Learn では、custom block page の変更はアクティブセッションへ反映されるまで数分かかる場合があると説明されています。また、web content filtering に関連する Global Secure Access 側の設定変更は通常数分、条件付きアクセスに関連する変更は約1時間かかる場合があることも示されています。(Microsoft Learn)
そのため、ヘルプデスクのナレッジには「設定直後に再テストしても反映されない場合がある」ことを明記しておくべきです。展開直後の問い合わせで、ここを知らないと不要な調査に時間を取られます。
セキュリティ管理者が設定前に確認すべき前提条件
block pages は、Global Secure Access を有効にすれば自動的にすべてのブロックで表示される、という単純なものではありません。設定前に前提条件を確認しておく必要があります。
Microsoft Learn の custom block page 手順では、前提条件として TLS inspection の構成、web content filtering または threat intelligence filtering の構成、Global Secure Access Administrator ロールまたは同等の権限が必要とされています。(Microsoft Learn)
特に注意したいのは、custom block pages は TLS inspected traffic に対して表示されるという制限です。HTTPS 通信が主流の現在、TLS inspection の設計なしにブロックページの体験だけを期待すると、想定した画面が出ないケースがあります。
導入前チェックリスト
| 確認項目 | 見るべきポイント | 失敗しやすい点 |
|---|---|---|
| TLS inspection | 対象ユーザー・対象通信に適用されているか | HTTPS でブロックページが出ない |
| Web content filtering | ブロック対象カテゴリや FQDN が正しいか | ルートドメインとサブドメインの指定漏れ |
| Threat intelligence | 高リスク宛先のブロックと許可リストを設計しているか | 誤検知時の例外運用が決まっていない |
| Security profile | 対象ポリシーが正しい profile に紐づいているか | 別 profile に設定していてユーザーに効かない |
| Conditional Access | 対象ユーザー・グループに適用されているか | テストユーザーが対象外になっている |
| ヘルプデスク導線 | 問い合わせ先や申請フォームがあるか | ブロックページを見ても次の行動が分からない |
Web content filtering では、カテゴリ、URL、FQDN によるフィルタリングを構成できます。FQDN を入力する場合は、https:// のようなプロトコルやパスを含めず、ドメイン名だけを指定する必要があります。また、*.contoso.com はサブドメインには一致しますが、ルートドメイン contoso.com には一致しないため、両方を対象にしたい場合は両方を指定する必要があります。(Microsoft Learn)
この仕様を理解していないと、「ブロックページが出ない」のではなく、そもそもポリシーが期待通りに一致していないという状態になります。
block pages の設定手順
Microsoft Learn で示されている custom block page の基本的な設定手順は、Global Secure Access の設定画面から行います。実際の管理画面はテナントやロール、プレビュー状態によって見え方が変わる可能性があるため、ここでは運用に必要な流れとして整理します。
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 1 | Global Secure Access の設定を開く | Settings > Session management > Custom Block Page |
| 2 | Custom body message を有効化する | On になっているか |
| 3 | 表示する本文を入力する | 1024 Unicode 文字以内に収める |
| 4 | 必要に応じてリンクを追加する | 限定的な Markdown 形式でクリック可能なリンクを設定 |
| 5 | Preview で表示を確認する | スマートフォンや小さい画面でも読める文量にする |
| 6 | Save で保存する | 反映に数分かかる可能性を考慮する |
| 7 | テスト端末からブロック対象サイトへアクセスする | GSA クライアントと Internet Access traffic forwarding profile の有効性を確認 |
custom body message には 1024 Unicode 文字の制限があります。長文の規程を貼るのではなく、「理由」「次の行動」「問い合わせ先」「リンク」を短くまとめる構成が適しています。(Microsoft Learn)
実務で使いやすいメッセージ例
ブロックページの文面は、セキュリティ部門だけで決めるのではなく、ヘルプデスク、法務、コンプライアンス、人事、現場部門と合意しておくと運用しやすくなります。
例として、次のような文面が考えられます。
このサイトへのアクセスは、会社のセキュリティポリシーにより制限されています。
業務上必要な場合は、アクセス先URL、利用目的、期限を記載して例外申請を行ってください。
緊急の場合は、ITヘルプデスクへ連絡してください。
この文面のポイントは、単に「禁止」と伝えるのではなく、例外申請に必要な情報を明示していることです。ヘルプデスクは問い合わせのたびに「URLを送ってください」「用途を教えてください」と聞き返す必要が減ります。
トラブルシューティングで見るべきポイント
block pages 導入後に多いトラブルは、「ブロックページが表示されない」「想定外のサイトで表示される」「例外申請後もブロックされる」の3つです。
それぞれ、見るべき場所が異なります。
ブロックページが表示されない場合
まず確認すべきは、ユーザーの通信が Global Secure Access に取得されているかどうかです。Web content filtering の検証手順では、Global Secure Access クライアントの Advanced Diagnostics から Forwarding profile を確認し、Internet Access の acquisition rules が存在するか、ブラウジング時に hostname acquisition や flows が取得されているかを確認する流れが示されています。(Microsoft Learn)
次に、TLS inspection の対象になっているかを確認します。custom block pages は TLS inspected traffic のみで表示されるため、HTTPS サイトで単なる接続エラーになる場合は、TLS inspection の適用範囲を疑うべきです。(Microsoft Learn)
また、DoH、IPv6、QUIC も切り分け対象です。Web content filtering と threat intelligence の前提条件では、DNS over HTTPS の無効化、Chrome と Microsoft Edge の組み込み DNS クライアント無効化、IPv4 優先、UDP 443 の扱いが説明されています。これらを放置すると、想定したトラフィックがトンネルされず、ポリシー評価の対象外になる可能性があります。(Microsoft Learn)
想定外のサイトでブロックされる場合
想定外のブロックでは、まず「どの制御がブロックしたのか」を確認します。
Global Secure Access では、web content filtering、threat intelligence、file type、DLP など複数の制御が関係する場合があります。Threat intelligence のドキュメントでは、security controls の順序として TLS inspection、Web content filtering、Threat intelligence、File type、Data loss prevention、Third-party の順で扱われることが説明されています。(Microsoft Learn)
実務では、次の順序で確認すると効率的です。
| 確認順 | 確認内容 | 判断のポイント |
|---|---|---|
| 1 | Traffic logs | ブロックされた時刻、ユーザー、宛先、ポリシーを確認 |
| 2 | Web category | サイト分類が想定どおりか確認 |
| 3 | FQDN / URL ルール | ワイルドカードやルートドメインの指定漏れを確認 |
| 4 | Threat intelligence | 高リスク判定や false positive の可能性を確認 |
| 5 | Conditional Access | 対象ユーザーに別の security profile が当たっていないか確認 |
| 6 | 例外ルール | 許可リストの優先度と反映状況を確認 |
Threat intelligence では、誤検知や業務上必要なサイトに対して allow list を設定できます。ただし、脅威状況は変化するため、許可リストは期限や所有者を決めて管理する必要があります。(Microsoft Learn)
例外申請後もブロックされる場合
例外を入れたのにブロックが続く場合は、反映時間、キャッシュ、セッションを確認します。
Microsoft Learn では、threat intelligence の allow list テストでは、設定後おおむね短時間でアクセス可能になる場合がある一方、ブラウザーキャッシュのクリアが必要になることがあると説明されています。また、Conditional Access 変更を早くテストしたい場合は、ユーザーのセッションを取り消して新しいトークンを取得させる方法も案内されています。(Microsoft Learn)
ヘルプデスク向けには、次のような確認テンプレートを用意しておくと便利です。
| 収集項目 | 理由 |
|---|---|
| ユーザー名またはUPN | 対象ポリシーとグループ割り当てを確認するため |
| アクセス先URL | FQDN、URL、カテゴリの一致を確認するため |
| 発生日時とタイムゾーン | Traffic logs と照合するため |
| 画面のスクリーンショット | block page かブラウザーエラーかを判断するため |
| 利用目的 | 例外申請の妥当性を判断するため |
| 緊急度と期限 | 一時許可か恒久許可かを判断するため |
ポリシー透明性を高める block pages の設計
block pages は、単なるエラーメッセージではなく、組織のセキュリティポリシーをユーザーに説明する接点です。
セキュリティ部門が厳格な制御を行うほど、ユーザー側には「なぜ制限されるのか」という疑問が生まれます。この疑問を放置すると、シャドーIT、個人端末利用、別ネットワークへの逃避といったリスクにつながります。
透明性の高い block pages には、次の要素があります。
理由を短く説明する
「ポリシーによりブロックされました」だけでは不十分です。可能であれば、次のように制御目的を示します。
- マルウェアやフィッシングから保護するため
- 情報漏えいリスクのあるカテゴリに該当するため
- 業務利用が承認されていないサービスであるため
- 法務・コンプライアンス上の確認が必要なため
ただし、脅威インテリジェンスの詳細や検知ロジックを過度に表示する必要はありません。攻撃者にヒントを与えないよう、ユーザーに必要な範囲で説明します。
例外申請の基準を明確にする
例外申請を受け付ける場合は、承認基準を曖昧にしないことが重要です。
たとえば、次の基準を設けると判断しやすくなります。
| 申請内容 | 判断例 |
|---|---|
| 顧客指定のファイル共有サービスを一時利用したい | 期限付き許可を検討 |
| 個人SNSを業務広報で利用したい | 広報部門など特定グループのみ許可を検討 |
| 生成AIサービスを開発調査に使いたい | データ入力ルールと承認済みサービスを確認 |
| マルウェア判定されたサイトを開きたい | 原則拒否。必要なら隔離環境で検証 |
| カテゴリ誤判定の可能性がある | 分類とログを確認し、必要に応じて例外化 |
ポイントは、「例外を認めるかどうか」をヘルプデスク担当者の個人判断にしないことです。block pages に申請フォームをリンクし、フォーム側で URL、目的、期間、データ種別、上長承認を入力させると運用が安定します。
プライバシーに配慮する
Microsoft Learn でも、custom block page に掲載する連絡先情報は組織のプライバシーポリシーに準拠させる必要があると説明されています。(Microsoft Learn)
たとえば、個人名の直通連絡先を表示するより、共有メールアドレス、ITSM ポータル、社内問い合わせフォームを案内するほうが望ましいケースがあります。グローバル企業では、地域ごとの問い合わせ先や言語対応も検討が必要です。
グローバル展開で注意すべきポイント
対象読者がグローバル組織の Network security admins や helpdesk leads である場合、block pages の設計では言語、地域、サポート体制の違いを考慮する必要があります。
日本本社では自然な文面でも、海外拠点では意味が伝わりにくいことがあります。また、国や地域によって、従業員監視、通信ログ、個人情報の扱いに対する期待値や規制が異なります。
グローバル向け block page 文面の考え方
| 観点 | 推奨 |
|---|---|
| 言語 | 英語を基本にし、必要に応じて地域別サポートページへ誘導 |
| 表現 | 「違反」「不正」など断定的な言葉を避ける |
| 申請 | 地域共通のフォームを使い、承認フローを分ける |
| ログ説明 | 必要最小限の監視目的を社内ポリシーで説明 |
| サポート | 24時間対応が必要な業務部門には別導線を用意 |
| 例外 | 永続許可ではなく、期限付き・所有者付きで管理 |
特にグローバル企業では、「ブロックページの文面が各国の従業員規程と矛盾していないか」を確認しておくべきです。日本語だけでなく、英語での標準文面を先に作り、各地域にローカライズする流れが現実的です。
導入時に失敗しやすいポイント
block pages の導入は、設定自体よりも運用設計で失敗しやすい機能です。
メッセージが抽象的すぎる
「アクセスは制限されています」だけでは、ユーザーは次に何をすればよいか分かりません。
少なくとも、問い合わせ先、申請方法、必要情報を入れるべきです。特に URL と発生時刻を添えて連絡するよう書いておくと、ログ調査が早くなります。
例外申請の受け皿がない
block pages に「必要な場合は問い合わせてください」と書いても、問い合わせ先が曖昧だとヘルプデスクにメールが集中します。
理想は、ITSM ツールやフォームに誘導し、申請データを構造化して受け取ることです。少なくとも、件名テンプレートや必要項目を明示しましょう。
TLS inspection の適用範囲を誤解する
custom block pages は TLS inspected traffic に表示される制限があります。HTTPS サイトで常に期待どおり表示されるとは限らないため、TLS inspection の設計、証明書配布、対象外サイトの扱いを事前に整理する必要があります。(Microsoft Learn)
条件付きアクセスの反映時間を考慮していない
テスト時に「設定したのに効かない」と判断する前に、条件付きアクセスや security profile の反映時間を考慮します。新しい security profile の適用には、アクセストークンの更新が関係するため時間がかかる場合があります。(Microsoft Learn)
許可リストを増やしすぎる
問い合わせを減らすために例外許可を乱発すると、Web content filtering や threat intelligence の意味が薄れます。
許可リストには、所有者、理由、有効期限、レビュー日を設定しましょう。特に threat intelligence の allow list は、業務継続上どうしても必要な場合に限定すべきです。
導入後に見るべき運用指標
block pages の効果は、画面が表示されるかどうかだけで判断しないほうがよいです。運用上は、問い合わせとポリシー改善につながっているかを確認します。
| 指標 | 見る理由 |
|---|---|
| ブロック件数 | ポリシーが想定どおり機能しているか |
| 問い合わせ件数 | ユーザー混乱が増えていないか |
| 例外申請件数 | 業務影響の大きいカテゴリを把握するため |
| 誤ブロック率 | カテゴリや FQDN ルールの改善に使うため |
| 再問い合わせ率 | ブロックページの文面が分かりにくくないか |
| 解決までの時間 | ヘルプデスク運用が機能しているか |
| 許可リストの件数 | 例外が肥大化していないか |
導入直後は問い合わせが増える可能性がありますが、それだけで失敗とは限りません。むしろ、これまで可視化されていなかった業務上の例外ニーズが表面化している可能性があります。
重要なのは、問い合わせ内容を分類し、ポリシー、文面、申請フローの改善に戻すことです。
Network security admins と helpdesk leads が今やるべきこと
Global Secure Access の block pages は、セキュリティ制御をユーザーに説明するための重要な接点です。単に機能をオンにするのではなく、ヘルプデスク運用、例外申請、ログ確認、ポリシー説明をセットで設計する必要があります。
まずは、次の順番で進めるのが現実的です。
| 優先度 | やること | 担当 |
|---|---|---|
| 高 | 現在の Web content filtering / threat intelligence の適用範囲を確認 | Network security admins |
| 高 | TLS inspection の対象と制限を確認 | Network security admins |
| 高 | ブロックページに載せる標準文面を作成 | Security / Helpdesk |
| 高 | 例外申請フォームまたは ITSM キューを用意 | Helpdesk leads |
| 中 | テストユーザーで表示、ログ、反映時間を検証 | Security / Helpdesk |
| 中 | 問い合わせテンプレートと一次切り分け手順を作成 | Helpdesk leads |
| 中 | 許可リストの所有者、期限、レビュー手順を決める | Security governance |
| 低 | 地域別・言語別の文面を整備 | Global IT / Local IT |
最初から全社展開するより、まずは IT 部門や一部ユーザーグループでテストし、ブロックページの文面と問い合わせフローを磨くほうが安全です。特にグローバル環境では、地域ごとの業務サイトやサポート窓口の差があるため、小さく検証してから展開範囲を広げるべきです。
まとめ
Microsoft Global Secure Access の block pages は、アクセス制御の結果をユーザーに分かりやすく伝えるための機能です。2026年4月16日時点の更新として注目すべき点は、単にブロック画面をカスタマイズできることではなく、ユーザー体験、トラブルシューティング、ポリシー透明性をまとめて改善できることです。
導入時は、TLS inspection、web content filtering、threat intelligence、Conditional Access、security profile の関係を確認し、ブロックページが表示される条件を正しく理解しておく必要があります。あわせて、ヘルプデスク向けの一次切り分け手順、例外申請フロー、許可リスト管理を整備しておくと、展開後の混乱を抑えられます。
次に取るべき行動は明確です。まずはテストグループを作り、ブロックページの文面、表示条件、ログ確認、問い合わせフローを一通り検証しましょう。そのうえで、全社展開前に「ユーザーが読んで次の行動を取れる画面」になっているかを確認することが、Global Secure Access 運用を成功させる近道です。
コメント