Azure ネットワーク 通信ログのまとめ

Azure と接続する際にネットワークサービスの利用 (Virtual Netowrk, Public IP, ExpressRoute , NSG, WAF 等) は多くのシナリオで必須となりますが、様々なリソースでアクセスログ、通信ログを取得することができます。そこでどのリソースでどういったログが取得可能で、どう使い分けるべきかをまとめていきたいと思います。一応ログは取っているが、どういったときに使い分けたらいいかわからないといった際のヒントになれば幸いです。
この記事ではネットワークサービスについて記載しているため PaaS (WebApps, Storage, SQL Database 等) に直接インターネット経由でアクセスするケースは考慮しておりません。

通信ログ、アクセスログが取得可能な製品一覧

以下のような製品がありますが、どれも Azure への入り口または出口として利用しているケースが多いのではないかと思います。

• Azure Firewall
• Network Security Group
• Virutal Network (2023/08/16 パブリックプレビュー 2024/04/24 GA 詳細はこちら)
• Application Gateway (WAF 含む)
• Bastion
• Azure Front Door (WAF 含む)
• Azure CDN (MS SKU のみ)　※ Verizon/Akamai でアクセスログは取得できません。

また、ExpressRoute Direct の Traffic Collector (プレビュー) はサンプリングですべての通信ログではないため、除外してます。

通信ログ、アクセスログの取得ができない製品

よくご質問いただく代表的なものを記載します。

• ExpressRoute 回線
• 仮想ネットワーク ゲートウェイ (ER/VPN)
• Azure Load Balander
• NAT Gateway

上記の製品ではメトリックにてスループット等の通信の利用状況を確認することはできますが、送信元、宛先アドレスなど各トラフィックの詳細を確認するようなログは提供されておりません。

ログの機能一覧

ネットワーク系の機能で取得可能な診断ログを比較した表です。診断ログまたはメトリックのどちらかで取得できる項目は 〇 としています。
単一の通信のサイズは "Bytes per traffic"、リソース単位でのスループットは "Throughput" 列で表現しています。

　　

リソース名	Layer	ログの記録対象						備考
		Src IP	Src Port	Dst IP/FQDN	Dest Port	Bytes per traffic	Throughput
Azure Load Balancer	L4	×	×	×	×	×	〇	メトリックのみ
NAT Gateway	L4	×	×	×	×	×	〇	メトリックのみ
Private Endpoint	L4	×	×	×	×	×	〇	メトリックのみ
Azure DNS (Private DNS 含む)	L4	×	×	×	×	×	〇	クエリ数のメトリックのみ
Private DNS Resolver	L4	×	×	×	×	×	〇	クエリ数のメトリックのみ
仮想ネットワーク ゲートウェイ (ER/VPN)	L4	×	×	×	×	×	〇	メトリックのみ
ExpressRoute 回線	L4	×	×	×	×	×	〇	メトリックのみ
NSG フローログ	L4	〇	〇	IP	〇	〇	×	非対応シナリオあり(詳細は後述)
VNet フローログ	L4	〇	〇	IP	〇	〇	×
NSG フローログ Traffic 分析	L4	〇	x	IP	〇	〇	〇	非対応シナリオあり(詳細は後述)
VNet フローログ Traffic 分析	L4	〇	x	IP	〇	〇	〇
DDoS Standard	L4	〇	〇	IP	〇	〇	×	攻撃中のトラフィックが対象
Bastion	L4	〇	〇	IP	〇	×	×
Azure Firewall DNAT Rule	L4	〇	〇	IP	〇	×	〇	ルール種別ごとのスループットは確認不可
Azure Firewall Network Rule	L4	〇	〇	IP	〇	×	〇	ルール種別ごとのスループットは確認不可
Azure Firewall Application Rule	L7	〇	〇	FQDN	〇	×	〇	ルール種別ごとのスループットは確認不可
Application Gateway	L7	〇	〇	FQDN or IP	〇	〇	〇
Application Gateway WAF	L7	〇	〇	FQDN or IP	×	×	〇
Azure Front Door	L7	〇	〇	FQDN	〇	〇	〇
Azure Front Door WAF	L7	〇	〇	FQDN	×	×	〇
Azure CDN (MS)	L7	〇	〇	FQDN	〇	〇	×

各ログで取得できる情報をまとめた結果、言えることとして、Hub&Spoke のような構成において、送信元、宛先の情報と共に送受信データのサイズ情報も一元的に取得できる機能がありません。 VNet フローログを利用することで送信元、宛先の情報と共に送受信データのサイズ情報も一元的取得できます。

例えば以下のようなトラフィックパターンにおいて、Azure Firewall の診断ログにて送信元、宛先の情報を一元管理できますが、データサイズも取得する場合、NSG/VNet のフローログや各リソースのログの取得を行う必要があります。

シナリオに応じたログ取得

様々なケースで通信ログを取得しておきたいといった要件があると思いますが、どのような方法があるかを以下にまとめてみました。
前提としてはそれなりの規模の環境かつ以下の様な Hub&Spoke の構成を対象としています。

North-South (Inbound)

• Web traffic については Front Door (Global) や Application Gateway (Regional) でログ取得
• VM への接続 (SSH, RDP) は Bastion でログ取得
• その他の通信は Azure Firewall でログ取得
• DDoS に対する 攻撃分析、アラート対応、コスト補償等が必要である場合、DDoS Protection を検討
• トラフィックサイズのログも取得したい場合、以下のどちらかで対応可能かを確認
  • NSG/VNet フローログ
  • 各種リソースの診断ログのアクセスログ

North-South (Outbound)

• Azure Firewall でログ取得
• トラフィックサイズも取得したい場合、NSG/VNet フローログを検討

East-West

• Azure Firewall でログ取得
• Azure Firewall を経由しない通信については Application Gateway や NSG/VNet フローログを検討
• トラフィックサイズも取得したい場合、NSG/VNet フローログまたはリソースの診断ログ取得を検討

各リソースのログについて

NSG フローログ、Trrafic 分析

NSG フローログは NSG のルールで評価されたトラフィックの詳細をログとして出力する機能です。送信元、宛先の情報に加えて、対象トラフィックのパケットのバイト数も取得ができます。

制限事項

• ユーザーが追加した NSG ルールではログがパケットサイズが出力されない可能性があり。詳細は後述。
• Private Endpoint の通信はサポートされていない
• 以下のようないくつかのリソースはサポートされていない (Link)
  • Application Gateway
  • Bastion
  • Azure Firewall (サブネットに NSG の適用がサポートされてない)
  • 仮想ネットワークゲートウェイ (サブネットに NSG の適用がサポートされてない)
  • Azure Container Instances
  • Azure Logic Apps
  • Azure Functions
  • Azure DNS Private Resolver
  • App Service
  • Azure Database for MariaDB
  • Azure Database for MySQL
  • Azure Database for PostgreSQL

ユーザー定義の NSG ルールのフローログについて

ユーザー定義の受信 TCP 規則 に記載があるように、ユーザーが追加した受信ルールではバイト数、パケット数が記載されない可能性があります。

ユーザー定義の受信規則が影響を与えるフローは、終了しないフローになります。 また、これらのフローのバイト数やパケット数は記録されません。 これらの要因により、NSG フローログ (および Network Watcher トラフィック分析) で報告されるバイト数とパケット数は、実際の数とは異なる可能性があります。

どういった動作になるかというと、以下の様に通信した際のログ自体は記録がありますが、パケット数、バイト数が 0 となります。

トラフィック分析用のログ

フローログにも、以下の様に記録自体はありますが、Flow State が B (Begin) で、パケット数、サイズがないログのみが出力されています。

この動作に対応するためには仮想ネットワークのプロパティ FlowTimeoutInMinutes を明示的に 4-30 (分) に設定する必要があります。この設定は NSG 等のリソースで無通信状態の時にどのくらい通信 (フロー) を保持しておくかの設定となります。既定値は 4 分となりますので、4 分以上の無通信状態の時に該当の通信が切断される可能性があります。

FlowTimeoutInMinutes の設定方法は、以下の様に仮想ネットワークの "概要" -> "フローのタイムアウト" -> "フローのタイムアウトを有効にする" から設定することができます。

VNet フローログ、Trrafic 分析

詳細はこちら

Bastion

Bastion を利用することで、以下のような情報のログを取得することができます。

項目	内容	備考
Time	接続日時
UserName	OS のログインユーザー	ネイティブクライアントの場合、出力なし
ClientIpAddress	クライアント端末の IP
UserEmail	Bastion を利用した Microsoft Entra ID ユーザー
TargetResourceId	接続先 VM のリソース ID
Message	ログイン成功または失敗

Azure Firewall

各通信の送信元、宛先の IP アドレス、ポート、拒否・許可等の情報が取得できます。

Azure Firewall の診断ログ AZFWFatFlow というテーブルにて帯域消費レートの情報をとれる機能がプレビューでありますが、Azure Firewall インスタンスの CPU 使用率があがるため、主にトラブルシューティングのみで有効化することが推奨されています。

また、今まで Azure Firewall のログは AzureDiagnostics テーブルに出力されておりましたが、現在は構造化されたリソース固有のテーブルによるログ取得もサポートされております。

以下のようなメリットがありますので、これから作成される環境ではリソース固有のテーブルによるログ取得もご検討ください。

次の理由により、この方法をお勧めします。

• ログ クエリ内のデータの操作がはるかに容易になる
• スキーマとその構造の検出が容易になる
• インジェストの待ち時間とクエリ時間の両方でパフォーマンスが向上する
• 特定のテーブルに対する Azure RBAC 権限を付与できる

以下は各ルールのログ出力の違いですが、主に異なる点は Azure Diagnostics テーブルでは通信の詳細がすべて、msg_s の中にまとめられておりましたが、リソース固有テーブルでは Policy, RuleCollection, Rule 等がすべて別の列として出力されております。そのためクエリの操作も容易になります。

Nat Rule (AzureDiagnostics/AZFWNatRule)

Network Rule (AzureDiagnostics/AZFWNetworkRule)

Application Rule (AzureDiagnostics/AZFWApplicationRule)

Application Gateway

ApplicationGateway V2 のアクセスログでは以下のような情報が取れます。(主な項目のみ抜粋)

項目	内容	備考
clientIP_s	クライアント端末の IP
receivedBytes_d	クライアントから受信したパケットのサイズ (バイト単位)
sentBytes_d	クライアントへ送信したパケットのサイズ (バイト単位)
timeTaken_d	クライアントへ応答が返るまでの時間	TimeGenerated は timeTaken の時間も含まれているため注意が必要
httpStatus	Application Gateway が返した Status コード
WAFPolicyID_s	WAP Policy のリソース ID
WAFEvaluationTime_s	WAF の処理時間
WAFMode_s	Detection または Prevention モード
serverRouted_s	振り分けられたバックエンドサーバー
serverStatus_s	バックエンドが返した Status コード
serverResponseLatency_s	バックエンドからの応答時間	timeTaken_d と比較することで AppGW, バックエンドどちらで時間がかかってるか見当がつく
upstreamSourcePort_s	AppGW 側のソースポート
transactionId_g	リクストの一意識別子	HTTP ヘッダーにも X-AppGW-Trace-Id として付与される

Azure Front Door

Azure Front Door のアクセスログでは以下のような情報が取れます。(主な項目のみ抜粋)

項目	内容	備考
ClientIp_s	クライアント端末の IP	X-Forwarded-For がある場合、その値になります
SocketIp_s	Azure Front Door エッジへ接続した IP アドレス
RequestBytes_s	HTTP Request のサイズ (バイト単位)
ResponseBytes_s	HTTP Response のサイズ (バイト単位)
timeTaken_d	クライアントへ応答が返るまでの時間 (応答の最後のバイトを送るまで)	TimeGenerated は timeTaken の時間も含まれているため注意が必要
timeToFirstByte_s	クライアントへ応答の最初のバイトが返るまでの時間
OriginIP_s	リクエストを転送した配信元の IP アドレス
httpStatusCode_s	FrontDoor が返した HTTP の Status コード

以下はアクセスログのサンプルです。X-Forwarded-For を意図的に設定したため、clientIp_s と socketIp_s が異なる IP アドレスになってます。

Azure CDN (MS SKU)

Azure CDN (MS) のアクセスログでは以下のような情報が取れます。(主な項目のみ抜粋)
その他の SKU (Verizon, Akamai) ではこの粒度でアクセスログを取得する機能はありません。

項目	内容	備考
ClientIp	クライアント端末の IP	X-Forwarded-For がある場合、その値になります
RequestBytes	HTTP Request のサイズ (バイト単位)
ResponseBytes	HTTP Response のサイズ (バイト単位)
timeTaken	クライアントへ応答が返るまでの時間 (応答の最後のバイトを送るまで)	TimeGenerated は timeTaken の時間も含まれているため注意が必要
timeToFirstByte	クライアントへ応答の最初のバイトが返るまでの時間
httpStatusCode_s	CDN が返した HTTP の Status コード

DDoS Protection

DDoS Protction を利用することで攻撃中に削除されたトラフィック、転送されたトラフィックの詳細をほぼリアルタイムで確認することができます。

DDoS の軽減フローログでは以下のような情報が確認できます。(主な項目のみ抜粋)

項目	内容	備考
SourcePublicIpAddress	クライアントの IP
DestPublicIpAddress	宛先の パブリック IP
Message	攻撃、トラフィックの詳細
Protocol	プロトコル