Azure Front DoorとMicrosoft Intune連携のためのIPアドレス許可設定完全ガイド

Microsoft Intune を導入すると、最初にぶつかるのが「ファイアウォールでどの IP を許可すればよいか」です。とくに Azure Front Door 経由で社内アプリや Intune サービスへ接続する構成では、個別 IP を手作業で管理するのはすぐに限界に達します。本記事では、Azure のサービスタグを使って Azure Front Door の許可リストを設計し、Intune 連携を安全かつ運用しやすくする方法を詳しく解説します。

Azure Front Door と Intune 連携で何が起きているのか

まずは、「なぜ Intune 連携で Azure Front Door の IP アドレスを意識する必要があるのか」を整理します。

Azure Front Door とは

Azure Front Door（AFD）は、Microsoft が提供するグローバルなアプリケーション配信ネットワーク（CDN 兼アプリケーションゲートウェイ）で、世界中のエッジ拠点からアプリや API を公開できるサービスです。グローバル負荷分散、WAF（Web Application Firewall）、SSL 終端、キャッシュなどをまとめて提供し、「インターネットからの入り口」を一手に引き受けるのが役割です。

Microsoft Intune と Azure Front Door の関係

Microsoft Intune はクラウドサービスであり、多数のエンドポイント（FQDN と IP 範囲）を通じて端末と通信します。これらの一部は Azure Front Door を経由して提供されており、Intune の公式ドキュメントにも「Intune のエンドポイントは Azure Front Door を利用し、その IP 範囲は JSON ファイル上で AzureFrontDoor.MicrosoftSecurity というサービスタグ名で管理されている」と明記されています。

つまり、以下のような場面では Azure Front Door の IP アドレス（＝サービスタグ）を許可する設計 が必須になります。

社内ネットワークから Intune サービス（*.manage.microsoft.com など）への通信を、IP ベースで厳格に制御している。
Intune からアクセスさせたい自社 Web アプリや API を Azure Front Door 経由で公開している。
オンプレミスや Azure 内のオリジン（App Service / API Management / VM 等）を「Front Door からの通信だけ許可」にしたい。

このとき、個別の IP アドレスを列挙して許可するのではなく、Azure が提供する サービスタグ を使って管理するのが現実解となります。

サービスタグで Azure Front Door の IP を管理する

サービスタグとは何か

サービスタグは、Azure の特定サービスに紐づく IP アドレス範囲（CIDR）の集合に対して付けられた論理名です。たとえば Storage や AzureFrontDoor.Frontend といった名前で、裏側の大量の IP プレフィックスをまとめて扱えます。Microsoft がこの IP プレフィックスを管理し、サービスの拡張や変更に応じて自動的に更新してくれるため、管理者は「タグ名」をルールに書くだけで済むのが最大のメリットです。

サービスタグを利用すると、次のような利点があります。

IP 追加・削除の追従が不要：サービス側の IP 変更に自動追随できる（NSG / Azure Firewall など）。
ルール定義がシンプル：Source = AzureFrontDoor.Backend のように書けるため、読みやすくミスも減る。
クラウド／オンプレをまたいで共通化可能：JSON による定義をオンプレ FW に取り込み、Azure 側はタグ指定、といったハイブリッド運用がしやすい。

Azure Front Door のサービスタグ一覧と役割

Azure Front Door には、主に次の 4 つのサービスタグがあります。

サービスタグ名	主な役割	典型的な利用シナリオ
`AzureFrontDoor.Frontend`	クライアント（ブラウザ、社内端末など）が Front Door エッジに接続するときの宛先 IP 範囲。	社内ネットワークやプロキシから「Front Door 経由で公開されたアプリ」へアクセスさせるためのアウトバウンド許可。
`AzureFrontDoor.Backend`	Front Door がオリジン（アプリ／API）に接続するときの送信元 IP 範囲。	オリジン側（App Service / API Management / VM など）を「Front Door からの通信だけ許可」したいときのインバウンド制御。
`AzureFrontDoor.FirstParty`	一部の Microsoft ファーストパーティサービス専用の Front Door 経由トラフィック。	通常のカスタマーシナリオでは直接使わない（内部用途が中心）。
`AzureFrontDoor.MicrosoftSecurity`	Microsoft Security 系サービス（Intune を含む）で利用される Front Door 経由トラフィック。	Intune など Microsoft Security 由来のトラフィックを、IP ベースで許可したいときに使用。

Microsoft のサービスタグ一覧ドキュメントでは、AzureFrontDoor.Frontend が「クライアントが Front Door に到達するための IP 範囲」、AzureFrontDoor.Backend が「Front Door からオリジンへ到達する IP 範囲」、そして FirstParty と MicrosoftSecurity が一部の Microsoft サービス専用タグであると説明されています。

Intune 連携でどのサービスタグを使うか

大まかな整理

Intune 連携で Azure Front Door の IP を許可したい場合、まずは「どの通信を制御したいのか」を明確にします。用途ごとに使うべきサービスタグは次のように整理できます。

制御する場所	目的	対象となる通信	推奨サービスタグ
社内ネットワーク（端末・サーバ・プロキシ）	社内から Front Door 経由のアプリ／Intune サービスへの送信許可	アウトバウンド（宛先 IP）	`AzureFrontDoor.Frontend` または Intune 向けには `AzureFrontDoor.MicrosoftSecurity`
オリジン（自社アプリ／API／App Service 等）	Front Door 経由のみ受け入れたい（直アクセスを禁止）	インバウンド（着信元 IP）	`AzureFrontDoor.Backend`

シナリオ 1：Intune からアクセスさせたいアプリを Front Door で公開している場合

たとえば、次のような構成を考えます。

Intune 管理デバイスからアクセスさせる社内 Web アプリ（ポータル、API）を Azure Front Door 経由でインターネット公開している。
社内からも同じ URL を使ってアクセスしたいが、社内プロキシ／FW は IP ベースで送信先制御を行っている。

この場合、社内ネットワーク側では「宛先 IP として Front Door のエッジ IP 範囲」を許可しておく必要があります。その際、個々の IP を列挙するのではなく、宛先として AzureFrontDoor.Frontend サービスタグに含まれるプレフィックスを許可しておくと、Front Door 側のスケールアウトに自動追従できます。

同時に、アプリ側（オリジン）では「Front Door 経由以外のアクセスを禁止したい」ニーズがよくあります。その場合はオリジン側の NSG や Azure Firewall、App Service のアクセス制御で 着信元として AzureFrontDoor.Backend を許可し、それ以外のインターネットからのアクセスは拒否する設計にします。

シナリオ 2：社内から Intune サービスへのアクセスを IP ベースで制御したい場合

Intune の公式ドキュメントでは、管理デバイスや各種コネクタがアクセスすべき FQDN・IP 範囲が一覧で提供されており、その中で「Intune のエンドポイントは Azure Front Door を利用し、AzureFrontDoor.MicrosoftSecurity というサービスタグ名で JSON 内に定義されている」と説明されています。

これに加え、2025 年末にかけて Microsoft から「Intune のネットワークエンドポイントに Azure Front Door の新しい IP レンジを追加するので、AzureFrontDoor.MicrosoftSecurity をファイアウォールの許可リストに含めてほしい」というアナウンスも行われています。

したがって、

これまで Intune 向けに個別の IP 範囲を許可していた環境
今後も IP ベースで Intune への通信を厳格に制御したい環境

では、アウトバウンド宛先として AzureFrontDoor.MicrosoftSecurity のプレフィックスを許可する設計が推奨されます。クラウド側で Intune のフロントエンド IP が追加・変更されても、サービスタグ側が更新されるため、運用負荷を大きく下げることができます。

Azure IP Ranges and Service Tags JSON から CIDR を取得する手順

オンプレミスのファイアウォールや、一部のクラウド製品ではサービスタグ名を直接指定できません。その場合、Microsoft が公開している JSON ファイルから AzureFrontDoor.Frontend や AzureFrontDoor.Backend、AzureFrontDoor.MicrosoftSecurity に該当する CIDR を抽出し、アドレスオブジェクトとして登録します。

JSON ファイルの取得

サービスタグの定義は、「Azure IP Ranges and Service Tags – Public Cloud」などの名称で Microsoft ダウンロードセンターから入手できます。Public / US Government / China（21Vianet）/ Germany などクラウドごとに JSON ファイルが公開されており、週次で更新されています。また、新しい IP 範囲は JSON に追加されてから少なくとも 1 週間は実際のトラフィックに使われないため、計画的に反映する余裕があります。

JSON の概要は次のとおりです。

ファイル名例：ServiceTags_Public_20251117.json
トップレベルに values 配列があり、その中の各要素が 1 つのサービスタグに対応
各要素には name と properties.addressPrefixes などのプロパティが含まれる

name が AzureFrontDoor.Frontend や AzureFrontDoor.Backend、AzureFrontDoor.MicrosoftSecurity である要素を探し、その addressPrefixes に列挙されている CIDR をファイアウォールの許可リストへ登録します。

PowerShell で特定サービスタグのプレフィックスを抜き出す例

PowerShell を使って、AzureFrontDoor.Frontend などのプレフィックスだけを抽出し、テキストファイルに出力する簡単な例を示します（Public クラウド向け）。

$tagName = "AzureFrontDoor.Frontend"   # 例：Frontend。Backend や MicrosoftSecurity に切り替えて利用
$downloadFolder = "C:\Temp\AzureServiceTags"
$jsonFileName = "ServiceTags_Public_latest.json"
$jsonPath = Join-Path $downloadFolder $jsonFileName

# 保存先フォルダを作成
if (-not (Test-Path $downloadFolder)) {
    New-Item -ItemType Directory -Path $downloadFolder | Out-Null
}

# 公式ダウンロードセンターの JSON（または ZIP 内 JSON）の URL を事前に確認して設定しておく
$jsonUrl = "https://download.microsoft.com/..."  # 実際の URL は最新ドキュメントで確認

Invoke-WebRequest -Uri $jsonUrl -OutFile $jsonPath

# JSON を読み込んで PowerShell オブジェクトに変換
$json = Get-Content $jsonPath -Raw | ConvertFrom-Json

# 指定したサービス タグの要素を抽出
$tagObject = $json.values | Where-Object { $_.name -eq $tagName }

if ($null -eq $tagObject) {
    Write-Error "Service Tag '$tagName' が JSON ファイル内に見つかりません。"
    return
}

$prefixes = $tagObject.properties.addressPrefixes

# 結果をファイルに書き出し（FW のアドレスオブジェクト作成などに利用）
$outFile = Join-Path $downloadFolder "$($tagName)_prefixes.txt"
$prefixes | Set-Content -Path $outFile

Write-Host "抽出したプレフィックス数: $($prefixes.Count)"
Write-Host "出力ファイル: $outFile"

このスクリプトをタスクスケジューラに登録して週 1 回実行することで、常に最新の IP 範囲をファイルとして保持できます。あとは FW ベンダーの API や CLI に合わせて、このテキストファイルを読み込んでアドレスオブジェクトを更新する処理を追加すれば、自動同期の仕組みが完成します。

Python での JSON 処理例（オンプレ側ジョブなど向け）

Python を使う場合も考え方は同じです。以下は、指定したサービスタグのプレフィックスを標準出力に表示する例です。

import json
from pathlib import Path

TAG_NAME = "AzureFrontDoor.Backend"  # Backend / Frontend / MicrosoftSecurity などに切り替え
JSON_PATH = Path(r"C:\Temp\AzureServiceTags\ServiceTags_Public_latest.json")

def load_service_tag_prefixes(json_path: Path, tag_name: str) -&gt; list[str]:
    data = json.loads(json_path.read_text(encoding="utf-8"))
    for item in data.get("values", []):
        if item.get("name") == tag_name:
            return item.get("properties", {}).get("addressPrefixes", [])
    raise ValueError(f"Service Tag '{tag_name}' が JSON に見つかりません")

if __name__ == "__main__":
    prefixes = load_service_tag_prefixes(JSON_PATH, TAG_NAME)
    print(f"{TAG_NAME} prefixes ({len(prefixes)}):")
    for p in prefixes:
        print(p)

Fortinet / Palo Alto / Cisco など、多くのファイアウォール製品は REST API を提供しているため、このスクリプトを拡張して「既存のオブジェクトとの差分を取り、追加・削除を反映する」処理を組み込むと、完全自動化が可能になります。

Service Tag Discovery API を使う方法

Azure 内だけで完結する場合（NSG や Azure Firewall のルール生成など）は、JSON ダウンロードではなく「Service Tag Discovery API」や Get-AzNetworkServiceTag コマンドレットを使う方法もあります。これは Azure の管理プレーン API から、現在利用可能なサービスタグとそのプレフィックスを取得する仕組みで、NSG などと同じソースを参照します。

ただし、API の結果は一部のタグしか返さない場合や、JSON ファイルとの差分が一時的に存在する場合があるため、オンプレ FW との同期用途では「JSON ファイルを基準」とする運用の方が分かりやすいケースもあります。

ファイアウォール／プロキシ製品ごとの設定パターン

次に、代表的な構成別に「どこでサービスタグを使い、どこで CIDR リストを使うか」を整理します。

場所・製品	おすすめ設定	ポイント
NSG（Network Security Group）	ルールの宛先／送信元に `AzureFrontDoor.Frontend` / `AzureFrontDoor.Backend` を直接指定。	サービスタグを直接使えるため、IP 管理がほぼ不要。場所（リージョン）は任意で問題ないが、管理しやすいリージョンを 1 つ決めておくと良い。
Azure Firewall	アプリケーションルール／ネットワークルールの宛先にサービスタグを指定。	インターネット全体を許可するのではなく、Front Door や AzureCloud などのサービスタグを使って最小限に絞る。
Azure 内の仮想アプライアンス（NVA）	製品がサービスタグに対応していればタグ指定、未対応なら JSON から CIDR を同期。	一部ベンダーは Azure サービスタグ対応を進めているため、バージョンアップで対応有無を確認する価値あり。
オンプレミスファイアウォール	JSON から抽出した CIDR をアドレスグループとして登録し、送信先／着信元に紐付ける。	オブジェクト数制限がある場合は、グループ分割やサブネットの集約を検討。
プロキシサーバ（Web Proxy）	宛先 IP ベースの許可に `AzureFrontDoor.Frontend` の CIDR グループを使用。	FQDN ベースの制御が可能なら、Intune の公式エンドポイント一覧＋ Front Door 由来の FQDN を優先し、どうしても IP 制御が必要な箇所のみサービスタグの CIDR を使うと運用が楽。

更新運用の設計（週次の自動反映）

サービスタグを使うと「IP 変更の追従」という大きな課題はかなり軽減されますが、オンプレ FW など CIDR リストを直書きする機器では、JSON を元にした自動更新フローを用意しておくと安心です。

推奨フロー（例）

週 1 回、スクリプトで最新の JSON（Public / Government / China など環境に合わせたもの）をダウンロード。
AzureFrontDoor.Frontend / AzureFrontDoor.Backend / AzureFrontDoor.MicrosoftSecurity を抽出し、前回の結果と差分を比較。
差分をログに記録し、必要に応じてメールや Teams で通知。
テスト用 FW（またはステージングポリシー）に差分を適用し、問題がなければ本番へ反映。
反映後、Intune 管理端末や代表的な業務端末で接続テストを実施し、結果を記録。

Service Tags の公式ドキュメントでは、「ダウンロード可能な JSON は週次で更新され、新しい IP アドレスは少なくとも 1 週間は実際のサービスでは使われない」とされています。この猶予期間を前提に、例えば「毎週月曜日に JSON を取得 → 翌週の運用開始までに FW ポリシーを更新」というサイクルを組むと、安定した運用がしやすくなります。

オブジェクト数制限への対処

一部のファイアウォール製品では、アドレスオブジェクト／アドレスグループの最大数が制限になりがちです。Azure Front Door のプレフィックスもそれなりの数になるため、次のような工夫を検討します。

近接する CIDR をまとめて 1 つのオブジェクトとして扱う（例：/24 を 2 つまとめて /23 として登録）。
役割ごとにアドレスグループを分け、「Intune 用」「社内アプリ用」など意味のある単位で再利用する。
どうしても制限に近づく場合は、IP ベース制御を最小限にし、FQDN ベースやプロキシ経由での制御に寄せる。

クラウド種別とリージョンに注意する

サービスタグや JSON ファイルは、Azure のクラウド種別ごとに分かれています。

Public（通常の商用クラウド）
US Government
China（Microsoft Azure operated by 21Vianet）
Germany（旧分離クラウド）

Service Tags のドキュメントでは、これらのクラウドごとに JSON のダウンロードリンクが示されており、各クラウドの IP 範囲が独立しています。Intune の US Government 向けエンドポイント解説でも、Government Cloud 用の JSON を参照するよう案内されています。

したがって、

自社テナントがどのクラウドに属しているか（Public / GCC / GCC High / DoD / China など）
Intune テナントのリージョン（North America / Europe / Asia Pacific など）

を事前に確認し、それに合致する JSON を利用する必要があります。誤ったクラウドの JSON を使うと、本来不要な IP を許可してしまったり、必要な IP を許可し損ねるリスクがあるため要注意です。

Intune 自体のネットワーク要件との付き合い方

本記事のメインテーマは「Azure Front Door のサービスタグをどう扱うか」ですが、Intune 連携では当然ながら Intune 公式ドキュメントに記載されているエンドポイント一覧 を満たしていることが大前提になります。

実務上のポイントをまとめると、次のようになります。

まずは Intune の公式「Network endpoints for Microsoft Intune」を参照し、FQDN とポート要件を満たす（特に *.manage.microsoft.com など）。
エンドポイント一覧の中で「Azure Front Door を利用する」と明記されている部分について、IP ベース制御が必要な箇所だけをサービスタグ（AzureFrontDoor.MicrosoftSecurity 等）で補完する。
SSL インスペクションが禁止されているエンドポイント（*.manage.microsoft.com / *.dm.microsoft.com など）があるため、その例外設定も忘れない。

つまり、サービスタグはあくまで「IP ベースで制御せざるを得ない部分を安全に管理するための仕組み」であり、Intune の FQDN ベースの要件を置き換えるわけではない、という認識が重要です。

注意点・ベストプラクティス

`AzureFrontDoor.FirstParty` は通常不要

AzureFrontDoor.FirstParty は、主に Microsoft 自身のサービス向けに内部的に利用されるタグであり、通常のカスタマー環境で「自社アプリ用のタグ」として使う必要はありません。Intune を含む Microsoft Security 関連サービスについては、AzureFrontDoor.MicrosoftSecurity を使う方が明確です。

最小権限の原則を守る

サービスタグを使うと簡単に広い範囲を許可できてしまうため、「とりあえず AzureCloud を全部許可」のような設定は慎重に検討すべきです。Azure のベストプラクティスでも、AzureCloud のような広いタグは基本的に推奨されていません。

Intune 連携の観点では、次の優先度で検討するとよいでしょう。

FQDN ベースでの許可（プロキシや L7 FW が使える場合）。
どうしても IP ベースが必要な箇所のみ、Front Door 関連は AzureFrontDoor.MicrosoftSecurity や AzureFrontDoor.Frontend に限定。
それでも足りない場合に限り、AzureCloud など広いタグを検討。

監査ログと変更履歴を残す

IP 範囲の更新は、意図せぬ通信断につながりがちです。自動更新スクリプトを組む場合でも、次のようなログを必ず残すことをおすすめします。

いつ、どの JSON バージョン（changeNumber）からどのバージョンへ更新したか。
追加・削除されたプレフィックスの一覧。
適用された FW / プロキシのポリシー名。
適用後に実施した疎通テストの結果。

これらが残っていれば、万が一トラブルが発生しても「どのタイミングで何が変わったのか」を素早く追跡できます。

テナント／クラウド移行時の見直し

テナントのリージョン変更や、Government / China クラウドとの連携などを行った場合は、Intune のネットワーク要件だけでなく Front Door のサービスタグも見直す必要があります。Public 向けの JSON のまま運用していると、Government 専用クラウドでは正しい IP 範囲にならない可能性があるためです。

最小チェックリスト（おさらい）

最後に、本記事で解説した内容を踏まえた「最小チェックリスト」をまとめます。自社環境に合わせてカスタマイズし、運用ドキュメントに組み込むと便利です。

[ ] 送信先許可が目的（社内から Front Door へのアウトバウンド）なら、AzureFrontDoor.Frontend または AzureFrontDoor.MicrosoftSecurity の範囲を利用している。
[ ] オリジン側の着信元制限が目的なら、AzureFrontDoor.Backend の範囲のみ許可している。
[ ] Intune 公式ドキュメントのエンドポイント一覧を満たしており、必要な FQDN とポートが開放されている。
[ ] 「Azure IP Ranges and Service Tags – Public Cloud（または自環境に対応したクラウド）」の JSON を週 1 回自動取得し、差分を FW に反映している。
[ ] テナントのクラウド種別（Public / Government / China など）とリージョンを確認し、対応する JSON を利用している。
[ ] サービスタグ対応製品（NSG / Azure Firewall など）では、IP ではなくタグ名をルールに指定して運用を簡素化している。
[ ] オブジェクト数制限や性能に配慮し、アドレスグループの設計や CIDR の集約を検討している。
[ ] IP 範囲更新時のログ（追加／削除分、適用対象、結果）を残している。

まとめ：サービスタグ前提の Intune 時代のファイアウォール設計

Microsoft Intune と Azure Front Door を組み合わせると、「どの IP を許可すべきか」という課題は必ず浮上します。しかし、個々の IP アドレスをスプレッドシートで管理する時代はすでに終わりつつあり、Azure が提供する サービスタグ を前提にした設計へ切り替えることが、運用負荷とセキュリティのバランスを取る近道です。

ポイントを整理すると次のとおりです。

クライアント → Front Door の送信許可には AzureFrontDoor.Frontend（Intune 用には AzureFrontDoor.MicrosoftSecurity）を利用する。
Front Door → オリジンの着信元制限には AzureFrontDoor.Backend を利用し、直アクセスを遮断する。
オンプレ FW では JSON から CIDR を自動抽出・同期し、週次更新を前提とした運用サイクルを作る。
クラウド種別（Public / Government / China 等）と Intune テナントのリージョンに合わせて正しい JSON を選ぶ。
Intune の公式エンドポイント一覧とあわせて設計し、「FQDN 制御＋サービスタグによる IP 制御」のハイブリッドで考える。

これらを押さえておけば、Intune 連携時に必要となる Azure Front Door の通信要件を確実に満たしながら、将来的な IP 変更にも強いネットワーク許可リスト運用を実現できます。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Azure Front DoorとMicrosoft Intune連携のためのIPアドレス許可設定完全ガイド

Azure Front Door と Intune 連携で何が起きているのか

Azure Front Door とは

Microsoft Intune と Azure Front Door の関係

サービスタグで Azure Front Door の IP を管理する

サービスタグとは何か

Azure Front Door のサービスタグ一覧と役割

Intune 連携でどのサービスタグを使うか

大まかな整理

シナリオ 1：Intune からアクセスさせたいアプリを Front Door で公開している場合

シナリオ 2：社内から Intune サービスへのアクセスを IP ベースで制御したい場合

Azure IP Ranges and Service Tags JSON から CIDR を取得する手順

JSON ファイルの取得

PowerShell で特定サービスタグのプレフィックスを抜き出す例

Python での JSON 処理例（オンプレ側ジョブなど向け）

Service Tag Discovery API を使う方法

ファイアウォール／プロキシ製品ごとの設定パターン

更新運用の設計（週次の自動反映）

推奨フロー（例）

オブジェクト数制限への対処

クラウド種別とリージョンに注意する

Intune 自体のネットワーク要件との付き合い方

注意点・ベストプラクティス

`AzureFrontDoor.FirstParty` は通常不要

最小権限の原則を守る

監査ログと変更履歴を残す

テナント／クラウド移行時の見直し

最小チェックリスト（おさらい）

まとめ：サービスタグ前提の Intune 時代のファイアウォール設計

この記事を書いた人

コメント

コメントするコメントをキャンセル

Azure Front DoorとMicrosoft Intune連携のためのIPアドレス許可設定完全ガイド

Azure Front Door と Intune 連携で何が起きているのか

Azure Front Door とは

Microsoft Intune と Azure Front Door の関係

サービス タグで Azure Front Door の IP を管理する

サービス タグとは何か

Azure Front Door のサービス タグ一覧と役割

Intune 連携でどのサービス タグを使うか

大まかな整理

シナリオ 1：Intune からアクセスさせたいアプリを Front Door で公開している場合

シナリオ 2：社内から Intune サービスへのアクセスを IP ベースで制御したい場合

Azure IP Ranges and Service Tags JSON から CIDR を取得する手順

JSON ファイルの取得

PowerShell で特定サービス タグのプレフィックスを抜き出す例

Python での JSON 処理例（オンプレ側ジョブなど向け）

Service Tag Discovery API を使う方法

ファイアウォール／プロキシ製品ごとの設定パターン

更新運用の設計（週次の自動反映）

推奨フロー（例）

オブジェクト数制限への対処

クラウド種別とリージョンに注意する

Intune 自体のネットワーク要件との付き合い方

注意点・ベストプラクティス

AzureFrontDoor.FirstParty は通常不要

最小権限の原則を守る

監査ログと変更履歴を残す

テナント／クラウド移行時の見直し

最小チェックリスト（おさらい）

まとめ：サービス タグ前提の Intune 時代のファイアウォール設計

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

サービスタグで Azure Front Door の IP を管理する

サービスタグとは何か

Azure Front Door のサービスタグ一覧と役割

Intune 連携でどのサービスタグを使うか

PowerShell で特定サービスタグのプレフィックスを抜き出す例

`AzureFrontDoor.FirstParty` は通常不要

まとめ：サービスタグ前提の Intune 時代のファイアウォール設計

コメントするコメントをキャンセル