Azure Networking documentation updateの今回のポイントは、Cloud NGFW by Palo Alto Networks のファイアウォールに対して、オンデマンドのカスタムパケットキャプチャをAPIから開始・確認・削除できるようになったことです。新しい子リソースは PaloAltoNetworks.Cloudngfw/firewalls/customCaptureConfigurations/default で、API version は 2026-05-11-preview です。障害調査や通信経路の切り分けで「特定の送信元・宛先・ポートだけを短時間キャプチャしたい」運用担当者、REST API・SDK・IaCで Cloud NGFW を管理している開発者は、早めに確認しておく価値があります。(GitHub)
この更新は、すべてのAzureファイアウォール利用者に影響するものではありません。対象は PaloAltoNetworks.Cloudngfw リソースプロバイダーで管理される Cloud NGFW by Palo Alto Networks です。Microsoft Learnでは、Cloud NGFW by Palo Alto Networks はAzure上の統合サービスとして管理でき、リソースプロバイダー名は PaloAltoNetworks.Cloudngfw と説明されています。(Microsoft Learn)
Azure Networking documentation updateで追加された内容
今回追加された中心機能は、Cloud NGFW firewall配下のシングルトン子リソース customCaptureConfigurations/default です。シングルトンのため、名前は固定で default になり、1つのファイアウォールに対して複数の任意名キャプチャ設定を並べる設計ではありません。GETで状態を読み、PUTでキャプチャを開始し、DELETEで進行中または完了済みのキャプチャ状態をクリアする流れになります。(GitHub)
| 項目 | 内容 |
|---|---|
| 対象サービス | Cloud NGFW by Palo Alto Networks |
| リソースプロバイダー | PaloAltoNetworks.Cloudngfw |
| 追加リソース | firewalls/customCaptureConfigurations/default |
| API version | 2026-05-11-preview |
| 主な用途 | Cloud NGFW上でのオンデマンドのカスタムパケットキャプチャ |
| 状態確認 | pcapStatus をGETでポーリング |
| 終了状態 | Success または Failed |
| 注意点 | 通常のARM LROではなく、pcapStatus を基準に確認する |
公式PRでは、2026年5月19日に main へマージされ、2026-05-11-preview の新しいAPIバージョンとして customCaptureConfigurations が追加されています。レビューコメントでは、新規構成は Versions.v2026_05_11_preview に限定され、既存APIバージョンのサーフェスには触れていないため破壊的変更ではないと整理されています。(GitHub)
何ができるようになるのか
これまでCloud NGFWで通信トラブルを調査する場合、ログやルール、メトリックを確認しながら原因を推測する運用が中心になりがちでした。今回の更新により、REST APIから条件を指定して短時間のパケットキャプチャを開始し、その結果を指定したストレージアカウントへ出力する運用を組み込みやすくなります。
たとえば、次のような場面で役立ちます。
| 活用シーン | 使い方の例 |
|---|---|
| 特定アプリだけ接続できない | 送信元IP、宛先IP、宛先ポート443を指定して短時間キャプチャする |
| ルールでドロップされている疑いがある | pcapStages に Drop を含めて、破棄されたパケットを確認する |
| ファイアウォール処理前後を比較したい | Receive と Transmit を組み合わせて確認する |
| 障害対応手順を自動化したい | PUTで開始、GETで状態確認、完了後にストレージ上のpcapを調査する |
ただし、これは常時監視の代替ではありません。durationInSec は1〜180秒、pcapFilter と pcapStages はそれぞれ1〜4件という制約があるため、日常的な監視はログやメトリック、詳細な切り分けはカスタムパケットキャプチャ、という使い分けが現実的です。(Microsoft Learn)
追加された操作と管理上の意味
今回のリソースで押さえるべき操作は、GET、LIST、PUT、DELETEです。PRの説明ではGETとLISTで状態確認、PUTでフィルター・ステージ・時間・出力先ストレージを指定してキャプチャを開始すると説明されており、最終的なTypeSpecではDELETEも含まれています。(GitHub)
| 操作 | 目的 | 管理者・開発者が見るべき点 |
|---|---|---|
| GET | 現在のキャプチャ状態を取得 | pcapStatus、nextCheckInSeconds、message を確認 |
| LIST | ファイアウォール配下のキャプチャ設定を一覧取得 | シングルトンなので最大1件という前提で扱う |
| PUT | 新しいカスタムキャプチャを開始 | フィルター、ステージ、秒数、ストレージアカウントIDを指定 |
| DELETE | キャプチャ状態をクリア | 進行中・完了済みの状態を消す操作として扱う |
特に重要なのは、PUTのレスポンスが返った時点でキャプチャが完了したとは限らないことです。公式サンプルでもPUT後のレスポンスは pcapStatus: "InProgress" になっており、nextCheckInSeconds が返る例があります。運用スクリプトでは、PUTのHTTPステータスだけで成功判定せず、GETを繰り返して Success または Failed まで確認する必要があります。(GitHub)
PUTで指定する主なプロパティ
PUTでは、properties 配下にキャプチャ条件を指定します。最低限、どの通信を、どのステージで、何秒間キャプチャし、どのストレージアカウントに書き込むかを決めます。Microsoft Learnの定義では、pcapFilter、pcapStages、durationInSec、storageAccountResourceId はPUT入力で必要と説明されています。(Microsoft Learn)
| プロパティ | 指定内容 | 実務上の判断ポイント |
|---|---|---|
pcapFilter | キャプチャ対象の通信条件。1〜4件 | 広げすぎると不要な通信まで取得するため、送信元・宛先・ポートを絞る |
protocol | TCP または UDP | まず障害対象のアプリケーションプロトコルを確認する |
sourceIpAddress | 送信元IPv4アドレス | 対象VMやアプリの実IPを指定する |
sourcePort | 送信元ポート。省略可 | 省略すると任意の送信元ポートに一致する |
destinationIpAddress | 宛先IPv4アドレス | FQDNではなくIPで指定する点に注意 |
destinationPort | 宛先ポート。1〜65535 | HTTPSなら443、DNSなら53など、調査対象に合わせる |
pcapStages | Receive、Transmit、Firewall、Drop から1〜4件 | ドロップ調査なら Drop、処理判断なら Firewall を優先 |
durationInSec | キャプチャ秒数。1〜180秒 | まず30秒程度の短時間で試し、必要に応じて延長する |
storageAccountResourceId | 出力先ストレージアカウントのARMリソースID | 書き込み権限、保持期間、アクセス制御を事前確認する |
pcapStatus、pcapDetailReason、nextCheckInSeconds、message は読み取り専用として扱うべき値です。message は表示用の人間向けメッセージで、英語のみと定義されています。運用自動化では message の文言ではなく、pcapStatus を機械判定に使うのが安全です。(GitHub)
REST APIのリクエスト例
実装時は、api-version=2026-05-11-preview を明示します。プレビューAPIなので、既存の本番コードに直接組み込む前に、検証環境でレスポンス形式、権限、ストレージ出力、ポーリング処理を確認してください。
PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/PaloAltoNetworks.Cloudngfw/firewalls/{firewallName}/customCaptureConfigurations/default?api-version=2026-05-11-preview
Content-Type: application/json
Authorization: Bearer {token}
{
"properties": {
"pcapFilter": [
{
"protocol": "TCP",
"sourceIpAddress": "10.0.0.5",
"destinationIpAddress": "52.39.204.87",
"destinationPort": 443
}
],
"pcapStages": [
"Firewall"
],
"durationInSec": 30,
"storageAccountResourceId": "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Storage/storageAccounts/{storageAccountName}"
}
}上記のように sourcePort を省略すると、任意の送信元ポートに一致します。公式の最小セットサンプルでも、sourcePort を指定せず、protocol、sourceIpAddress、destinationIpAddress、destinationPort、pcapStages、durationInSec、storageAccountResourceId を指定して開始する例が示されています。(GitHub)
状態確認はGETで行います。
GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/PaloAltoNetworks.Cloudngfw/firewalls/{firewallName}/customCaptureConfigurations/default?api-version=2026-05-11-preview
Authorization: Bearer {token}InProgress の間は、GETレスポンスに pcapFilter や durationInSec などの入力値がまだ返らない場合があります。Microsoft Learnの定義では、バックエンドがエコーバックを確定していない間、これらの値はGETレスポンスから省略される可能性があると説明されています。スクリプトで「入力値が返らない＝失敗」と判定しないようにしてください。(Microsoft Learn)
pcapStagesの選び方
pcapStages は、キャプチャをどの処理段階で取るかを決める重要な項目です。選び方を間違えると、キャプチャは成功しても、知りたい情報が含まれないことがあります。
| ステージ | 使う場面 | 注意点 |
|---|---|---|
Receive | ファイアウォールが受信した時点の通信を確認したい | そもそもCloud NGFWまで到達しているかを見るのに向く |
Transmit | ファイアウォールから送出される通信を確認したい | 通過後の挙動確認に向く |
Firewall | ファイアウォール処理段階を確認したい | ポリシーや処理判断の切り分けに向く |
Drop | 破棄された通信を確認したい | 「ルールで落ちている疑い」があるときに優先 |
たとえば、アプリケーションサーバーから外部APIへのHTTPS通信が失敗している場合、最初は Firewall と Drop を中心に、送信元IP、宛先IP、宛先ポート443で絞ると、ポリシー処理やドロップの有無を確認しやすくなります。ステージの定義として、Receive はファイアウォール受信時、Transmit は送信時、Firewall は処理段階、Drop は破棄されたパケットのキャプチャとされています。(Microsoft Learn)
影響範囲：既存環境はすぐ壊れるのか
既存のCloud NGFW環境が、今回の更新だけで直ちに動作変更される可能性は高くありません。PRレビューでは、新規構成は 2026-05-11-preview に追加され、既存APIバージョンのサーフェスには触れていないため、破壊的変更なしとされています。(GitHub)
影響が出るのは、主に次のようなチームです。
| 対象者 | 影響 |
|---|---|
| Cloud NGFW運用管理者 | 障害調査手順にカスタムパケットキャプチャを追加できる |
| REST API利用者 | 2026-05-11-preview を使う場合、新しい子リソースを扱える |
| SDK利用者 | SDKへの反映状況を確認し、未対応ならREST API利用を検討する |
| IaC管理者 | AzAPIや直接REST呼び出しでの検証対象が増える |
| セキュリティ監査担当 | pcap取得権限、出力先ストレージ、保持期間の統制が必要になる |
一方で、Microsoft.Network/azureFirewalls のAzure Firewallを使っているだけの環境は、この PaloAltoNetworks.Cloudngfw 向け更新の直接対象ではありません。名前に「firewalls」が含まれるため混同しやすいですが、対象リソースプロバイダーを必ず確認してください。
管理者が確認すべき設定
最初に確認すべきなのは、対象リソース、権限、出力先ストレージ、運用ルールの4点です。
対象がCloud NGFW by Palo Alto Networksか確認する
AzureポータルやResource Graphで、対象ファイアウォールのリソースタイプが PaloAltoNetworks.Cloudngfw/firewalls か確認します。Cloud NGFWはAzure Native ISV Serviceとして管理され、Azure portal、Azure CLI、Azure SDK、Azure PowerShell、ARM/Bicep、Terraformなどの方法で管理できるとPalo Alto Networksのドキュメントでも説明されています。(Palo Alto Networks TechDocs)
RBACを最小権限に寄せる
パケットキャプチャはトラブルシュートに便利ですが、通信内容に近い情報を扱うため、誰でも実行できる状態は避けるべきです。Palo Alto NetworksのCloud NGFW向けロール説明では、Owner、Contributor、LocalNGFirewallAdministrator、LocalRuleStacksAdministratorなどが紹介されており、ロールはAzure RBACで割り当てると説明されています。(Palo Alto Networks TechDocs)
実務では、少なくとも次を決めておきます。
- 誰がキャプチャを開始できるか
- 誰がキャプチャ結果の保存先にアクセスできるか
- 本番環境で実行する場合の承認フロー
- 取得したpcapファイルの保持期間と削除ルール
- 監査ログに残すべき操作とチケット番号
ストレージアカウントの扱いを決める
storageAccountResourceId は、キャプチャファイルを書き込む顧客側ストレージアカウントのARMリソースIDです。出力先が未整理だと、障害対応時に「キャプチャは成功したが、どこに保存されたか分からない」「権限がなくて取得できない」という失敗が起きます。(Microsoft Learn)
おすすめは、キャプチャ専用のストレージアカウントまたは専用コンテナーを用意し、次の運用ルールを先に決めることです。
| 確認項目 | 推奨する考え方 |
|---|---|
| 保存先 | 障害調査用に用途が分かる名前へ分離する |
| アクセス権 | ネットワーク管理者とセキュリティ担当に限定する |
| 保持期間 | 調査完了後に削除できるライフサイクルを設定する |
| 暗号化・監査 | 組織のストレージ標準に合わせる |
| コスト | 長期保存しない前提で運用する |
プレビューAPIとして扱う
2026-05-11-preview は名前の通りプレビューAPIです。Azureのプレビューは、一般提供前の機能やサービスなどを評価目的で利用する位置付けで、Microsoft Azure Previewsの追加使用条件が適用されます。(Microsoft Azure)
本番運用に組み込む場合は、最低でも次の対策を入れてください。
| リスク | 対策 |
|---|---|
| API仕様が変わる可能性 | api-version を固定し、変更時にテストできるようにする |
| SDK反映に時間差がある | REST API直呼び出しとSDK利用の両方を比較する |
| 自動化が失敗する | pcapStatus、HTTPステータス、エラー本文をログに残す |
| 権限不足で書き込めない | 検証環境でストレージ出力まで確認する |
| 過剰なキャプチャ | フィルターを狭くし、時間を短くする |
開発者が実装時に注意すべきポイント
実装で最も失敗しやすいのは、PUTを通常の完了型更新として扱ってしまうことです。このリソースは同期プロキシリソースとして定義され、GETで pcapStatus を確認し、Success または Failed までポーリングする設計です。nextCheckInSeconds は次回ポーリングまでの目安として返るため、短い間隔で連打するのではなく、この値を尊重する実装にします。(GitHub)
実装フローは次の形にすると安全です。
| 手順 | 処理 | 判定 |
|---|---|---|
| 1 | PUTでキャプチャ開始 | HTTP 200または201でも完了扱いにしない |
| 2 | レスポンスの pcapStatus を確認 | InProgress なら継続 |
| 3 | nextCheckInSeconds を待つ | 省略時は固定の安全な間隔を使う |
| 4 | GETで状態確認 | Success なら完了、Failed なら理由確認 |
| 5 | 必要に応じてDELETE | 状態クリアや後処理として実行 |
DELETEは、カスタムキャプチャ設定をクリアする操作です。Microsoft Learnでは、DELETEは進行中または終了状態のキャプチャ状態をクリアし、成功時は200、存在しない場合は204を返すと説明されています。運用スクリプトでDELETEを自動実行する場合、調査担当者がまだ結果確認中ではないかを確認するガードを入れておくと安全です。(Microsoft Learn)
よくある失敗パターン
pcapStatusではなくHTTPステータスだけで成功判定する
PUTで200または201が返っても、キャプチャは InProgress の可能性があります。成功判定は pcapStatus: "Success" まで待つ必要があります。Failed の場合は、pcapDetailReason や標準のエラー情報を確認します。(GitHub)
GETレスポンスに入力値がないことを異常扱いする
InProgress 中は、pcapFilter、pcapStages、durationInSec、storageAccountResourceId がGETレスポンスに含まれない場合があります。これは仕様上想定されています。自動化では、これらの値ではなく pcapStatus を中心に状態遷移を見ます。(Microsoft Learn)
複数キャプチャを同時に名前付きで作ろうとする
このリソースは default 固定のシングルトンです。LISTの結果も最大1件という前提で設計されています。チケットごと、調査担当者ごとに複数のキャプチャ設定を並列管理するような実装は避け、運用側で排他制御や実行履歴を持たせる必要があります。(GitHub)
キャプチャ範囲を広げすぎる
pcapFilter は1〜4件指定できますが、広すぎる条件は調査ノイズを増やします。最初から「全通信に近い条件」で取るのではなく、問題のある送信元、宛先、ポート、プロトコルに絞って開始します。必要なら2回目で条件を広げる方が、分析もコスト管理も楽です。(Microsoft Learn)
ストレージの運用を後回しにする
キャプチャの出力先はストレージアカウントです。保存先の権限、ネットワーク制限、ライフサイクル、監査を事前に決めていないと、障害時に調査ファイルを取り出せない、または不要なpcapが残り続ける原因になります。storageAccountResourceId はPUT入力で必要とされるため、API実装より先に出力先設計を済ませておくべきです。(Microsoft Learn)
移行・展開時のチェックリスト
既存環境にいきなり組み込むのではなく、次の順序で確認すると安全です。
| フェーズ | 確認内容 |
|---|---|
| 事前調査 | 対象が PaloAltoNetworks.Cloudngfw/firewalls か確認する |
| 権限設計 | 実行者、閲覧者、ストレージアクセス権を決める |
| 検証 | 非本番環境で30秒程度の最小キャプチャを実行する |
| 実装 | PUT→GETポーリング→結果確認→必要に応じてDELETEの流れを作る |
| 監査 | 誰が、いつ、どの条件でキャプチャしたか記録する |
| 展開 | 本番では承認フローと実行時間帯を定める |
| 見直し | API仕様、SDK、ドキュメント更新を定期確認する |
特にIaCや自動化基盤に取り込む場合は、プレビューAPIを使う箇所を明確に分離してください。既存のファイアウォール作成・更新テンプレートと同じ感覚で扱うと、意図せずキャプチャ状態をクリアしたり、未検証のAPIバージョンを本番パイプラインに入れたりするリスクがあります。
まず取るべき次のアクション
今回のAzure Networking documentation updateは、Cloud NGFW運用に「必要なときだけ狭く深く見る」ための調査手段を追加するものです。既存APIを壊す更新ではありませんが、障害対応の手順、RBAC、ストレージ、ポーリング実装には影響します。
まずは、対象環境にCloud NGFW by Palo Alto Networksがあるかを確認し、ある場合は非本番環境で 2026-05-11-preview のPUTとGETを試してください。最小構成は、送信元IP、宛先IP、宛先ポート、Firewall ステージ、30秒、検証用ストレージアカウントです。ここで、pcapStatus の遷移、nextCheckInSeconds の扱い、ストレージへの出力、DELETE後の状態を確認してから、本番の障害対応ランブックに組み込むのが現実的です。
コメント