Azure Firewall のログとメトリック
Azure Firewall を監視するには、ファイアウォール ログを使用できます。 また、アクティビティ ログを使用して、Azure Firewall リソースに対する操作を監査することもできます。
一部のログにはポータルからアクセスできます。 ログを Azure Monitor ログ、Storage、および Event Hubs に送信し、Azure Monitor ログや他のツール (Excel、Power BI など) で分析することができます。
メトリックは軽量で、ほぼリアルタイムのシナリオをサポートできるため、アラートや迅速な問題の検出に役立ちます。
Note
構造化ファイアウォール ログを使用できます。これにより、ログをより詳細に制御し、クエリを高速化できます。 詳細については、「Azure 構造化ファイアウォール ログ」を参照してください。
診断ログ
Azure Firewall では、次の診断ログを利用できます。
アプリケーション ルール ログ
アプリケーション ルール ログは、Azure Firewall ごとに有効にしている場合にのみ、ストレージ アカウントに保存され、イベント ハブにストリーム配信されて、Azure Monitor ログに送信されます。 構成されているアプリケーション ルールのいずれかと一致する新しい接続ごとに、許可/拒否された接続のログが生成されます。 次の例に示すように、データは JSON 形式でログに記録されます。
Category: application rule logs. Time: log timestamp. Properties: currently contains the full message. note: this field will be parsed to specific fields in the future, while maintaining backward compatibility with the existing properties field.
{ "category": "AzureFirewallApplicationRule", "time": "2018-04-16T23:45:04.8295030Z", "resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/AZUREFIREWALLS/{resourceName}", "operationName": "AzureFirewallApplicationRuleLog", "properties": { "msg": "HTTPS request from 10.1.0.5:55640 to mydestination.com:443. Action: Allow. Rule Collection: collection1000. Rule: rule1002" } }
{ "category": "AzureFirewallApplicationRule", "time": "2018-04-16T23:45:04.8295030Z", "resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/AZUREFIREWALLS/{resourceName}", "operationName": "AzureFirewallApplicationRuleLog", "properties": { "msg": "HTTPS request from 10.11.2.4:53344 to www.bing.com:443. Action: Allow. Rule Collection: ExampleRuleCollection. Rule: ExampleRule. Web Category: SearchEnginesAndPortals" } }
ネットワーク ルール ログ
ネットワーク ルール ログは、Azure Firewall ごとに有効にしている場合にのみ、ストレージ アカウントに保存され、イベント ハブにストリーム配信されて、Azure Monitor ログに送信されます。 構成されているネットワーク ルールのいずれかと一致する新しい接続ごとに、許可/拒否された接続のログが生成されます。 次の例に示すように、データは JSON 形式でログに記録されます。
Category: network rule logs. Time: log timestamp. Properties: currently contains the full message. note: this field will be parsed to specific fields in the future, while maintaining backward compatibility with the existing properties field.
{ "category": "AzureFirewallNetworkRule", "time": "2018-06-14T23:44:11.0590400Z", "resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/AZUREFIREWALLS/{resourceName}", "operationName": "AzureFirewallNetworkRuleLog", "properties": { "msg": "TCP request from 111.35.136.173:12518 to 13.78.143.217:2323. Action: Deny" } }
DNS プロキシ ログ
DNS プロキシ ログは、Azure Firewall ごとに有効にしている場合にのみ、ストレージ アカウントに保存され、イベント ハブにストリーム配信されて、Azure Monitor ログに送信されます。 このログは、DNS プロキシを使用して構成された DNS サーバーへの DNS メッセージを追跡します。 次の例に示すように、データは JSON 形式でログに記録されます。
Category: DNS proxy logs. Time: log timestamp. Properties: currently contains the full message. note: this field will be parsed to specific fields in the future, while maintaining backward compatibility with the existing properties field.
成功:
{ "category": "AzureFirewallDnsProxy", "time": "2020-09-02T19:12:33.751Z", "resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/AZUREFIREWALLS/{resourceName}", "operationName": "AzureFirewallDnsProxyLog", "properties": { "msg": "DNS Request: 11.5.0.7:48197 – 15676 AAA IN md-l1l1pg5lcmkq.blob.core.windows.net. udp 55 false 512 NOERROR - 0 2.000301956s" } }
[失敗]:
{ "category": "AzureFirewallDnsProxy", "time": "2020-09-02T19:12:33.751Z", "resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/AZUREFIREWALLS/{resourceName}", "operationName": "AzureFirewallDnsProxyLog", "properties": { "msg": " Error: 2 time.windows.com.reddog.microsoft.com. A: read udp 10.0.1.5:49126->168.63.129.160:53: i/o timeout” } }
メッセージの形式:
[client’s IP address]:[client’s port] – [query ID] [type of the request] [class of the request] [name of the request] [protocol used] [request size in bytes] [EDNS0 DO (DNSSEC OK) bit set in the query] [EDNS0 buffer size advertised in the query] [response CODE] [response flags] [response size] [response duration]
ログを保存するための 3 つのオプションがあります。
- ストレージ アカウント: ストレージ アカウントは、ログを長期間保存し、必要に応じて参照する場合に最適です。
- イベント ハブ:イベント ハブは、他のセキュリティ情報/イベント管理 (SEIM) ツールと統合してリソースに関するアラートを取得する場合に便利なオプションです。
- Azure Monitor ログ: Azure Monitor ログは、アプリケーションをリアルタイムに監視したり、傾向を見たりする一般的な用途に最適です。
アクティビティ ログ
アクティビティ ログ エントリは既定で収集され、Azure Portal で表示できます。
Azure アクティビティ ログ (以前の操作ログと監査ログ) を使用して、Azure サブスクリプションに送信されるすべての操作を表示できます。
メトリック
Azure Monitor において、メトリックは特定の時点におけるシステムの何らかの側面を表す数値です。 メトリックは 1 分ごとに収集され、頻繁にサンプリングできるためアラート発信に役立ちます。 アラートは比較的シンプルなロジックで迅速に発生させることができます。
Azure Firewall では、次のメトリックを利用できます。
[Application rules hit count](アプリケーション規則のヒット数) - アプリケーション規則がヒットした回数。
単位: カウント
[Network rules hit count](ネットワーク規則のヒット数) - ネットワーク規則がヒットした回数。
単位: カウント
[処理済みデータ] - 所与の時間枠内でファイアウォールを通過したデータの合計。
単位: バイト
[スループット] - 1 秒間にファイアウォールを通過したデータの率。
[単位]: 1 秒あたりのビット数
[Firewall health state](ファイアウォール正常性状態) - SNAT ポートの可用性に基づいて、ファイアウォールの正常性を示します。
単位: パーセント
このメトリックには次の 2 つのディメンションがあります。
状態:値は [Healthy] (正常)、 [Degraded] (低下)、 [Unhealthy] (異常) のいずれかになります。
理由:ファイアウォールの対応する状態の理由を示します。
SNAT ポートの使用率が > 95% の場合、使い果たされたと見なされ、正常性は 50% で、状態 = 低下、および理由 = SNAT ポート になります。 ファイアウォールによってトラフィックの処理が継続され、既存の接続に影響はありません。 ただし、新しい接続は断続的に確立されない可能性があります。
SNAT ポートの使用率が 95% 未満の場合、ファイアウォールは正常と見なされ、正常性は 100% として表示されます。
SNAT ポートの使用が報告されない場合、正常性は 0% として表示されます。
[SNAT port utilization](SNAT ポート使用率) - ファイアウォールによって使用されている SNAT ポートの割合。
単位: パーセント
ファイアウォールにパブリック IP アドレスを追加すると、より多くの SNAT ポートが使用可能になり、SNAT ポートの使用率が低下します。 さらに、さまざまな理由 (CPU やスループットなど) に応じてファイアウォールをスケールアウトすると、追加の SNAT ポートも使用できるようになります。 実際には、サービスがスケールアウトされると、パブリック IP アドレスを追加しなくても、SNAT ポートの使用率の割合が低下する可能性があります。使用可能なパブリック IP アドレスの数を直接制御して、ファイアウォールで使用可能なポートを増やすことができます。 ただし、ファイアウォールのスケーリングを直接制御することはできません。
ファイアウォールで SNAT ポートの枯渇が起きている場合は、少なくとも 5 つのパブリック IP アドレスを追加する必要があります。 これにより、使用可能な SNAT ポートの数が増えます。 詳細については、Azure Firewall の機能に関するページをご覧ください。
AZFW 待機時間プローブ - Azure Firewall の平均待機時間を推定します。
単位: ms
このメトリックでは、Azure Firewall の全体的または平均的な待機時間をミリ秒単位で測定します。 管理者は、次の目的でこのメトリックを使用できます。
ネットワークの待機時間の原因が Azure Firewall にあるかどうかを診断する
待機時間やパフォーマンスの問題があるかどうかを監視してアラートを生成し、IT チームが積極的に関与できるようにする。
さまざまな理由により、Azure Firewall で待機時間が長くなることがあります。 たとえば、CPU 使用率やスループットが高い、またはネットワークの問題が発生している可能性があります。
このメトリックを使用しても、特定のネットワーク パスのエンドツーエンドの待機時間は測定されません。 言い換えると、この待機時間の正常性プローブを使用しても、Azure Firewall で追加される待機時間は測定されません。
待機時間メトリックが想定どおりに機能していない場合は、メトリック ダッシュボードに値 0 が表示されます。
参考までに、ファイアウォールの想定される平均待機時間は、約 1 ms です。 これは、デプロイのサイズと環境によって異なる場合があります。
待機時間プローブは、Microsoft の Ping Mesh テクノロジに基づいています。 そのため、待機時間メトリックには断続的なスパイクが予想されます。 これらのスパイクは正常であり、Azure Firewall に関する問題を示しているわけではありません。 これらは、システムをサポートする標準のホスト ネットワーク セットアップの一部です。
その結果、一般的なスパイクよりも長時間続く一貫した長い待機時間が発生する場合は、サポートを受けられるようサポート チケットを提出することを検討してください。
Azure Firewall メトリックに関するアラート
メトリックは、リソースの正常性を追跡するための重要なシグナルを提供します。 そのため、リソースのメトリックを監視し、異常がないか注意することが重要です。 しかし、Azure Firewall メトリックのフローが停止した場合はどうすればよいですか? これは、潜在的な構成の問題や、障害のようなもっと険悪なものを示している可能性があります。 メトリックが見つからない原因は、Azure Firewall によるメトリックのアップロードをブロックする既定のルートの発行や、正常なインスタンスの数が 0 に減ったことである可能性があります。 このセクションでは、Log Analytics ワークスペースにメトリックを構成し、メトリックの欠落に関するアラートを生成する方法について説明します。
Log Analytics ワークスペースに対してメトリックを構成する
最初の手順では、ファイアウォールの診断設定を使用して、Log Analytics ワークスペースに対するメトリックの可用性を構成します。
次のスクリーンショットに示すように、Azure Firewall リソース ページを参照して診断設定を構成します。 これにより、構成されたワークスペースにファイアウォール メトリックがプッシュされます。
Note
メトリックの診断設定は、ログとは別の構成である必要があります。 ファイアウォール ログは、Azure Diagnostics またはリソース固有を使用するように構成できます。 ただし、ファイアウォール メトリックでは常に Azure Diagnostics を使用する必要があります。
アラートを作成して、エラーなしでファイアウォール メトリックの受信を追跡する
メトリック診断設定で構成されているワークスペースを参照します。 次のクエリを使用して、メトリックが使用可能かどうかを確認します。
AzureMetrics
| where MetricName contains "FirewallHealth"
| where ResourceId contains "/SUBSCRIPTIONS/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/RESOURCEGROUPS/PARALLELIPGROUPRG/PROVIDERS/MICROSOFT.NETWORK/AZUREFIREWALLS/HUBVNET-FIREWALL"
| where TimeGenerated > ago(30m)
次に、60 分間を超えるメトリックの欠落に対するアラートを作成します。 Log Analytics ワークスペースのアラート ページを参照して、メトリックの欠落に関する新しいアラートを設定します。
次のステップ
Azure Firewall のログとメトリックを監視する方法については、Azure Firewall のログを監視する方法に関するチュートリアルを参照してください。
Azure Monitor のメトリックの詳細については、「Azure Monitor のメトリック」を参照してください。