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 の 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 | プロトコル |