Zum Inhalt

Application-Gateway-Logs

Wenn deine Anwendung über das hub Application Gateway veröffentlicht wird (Shared Services), helfen dir die Access- und Firewall-Logs (WAF), die Frage „Wurde meine Anfrage blockiert, und warum?“ zu beantworten. Auf Plattformen, die die Gateway-Diagnosedaten an einen zentralen Log-Analytics-Workspace senden, kannst du sie mit der Kusto Query Language (KQL) abfragen.

Plattformspezifisch

Wohin die Logs gehen, in welcher Tabelle sie landen und welche Gruppe Zugriff gibt, hängt von deiner Plattform ab. Die Namen von Workspace und Gruppe unten sind Platzhalter. Frag dein Plattform-Team.

Zugriff erhalten

Der Zugriff wird über eine Entra-ID-Gruppe vergeben. In der Beispielplattform gibt die Reader-Gruppe zwei Berechtigungen:

Berechtigung Scope
Lesezugriff auf die Diagnosetabelle Der zentrale Log-Analytics-Workspace (<central workspace>)
Monitoring Reader Die Application-Gateway-Ressource

Bitte dein Plattform-Team, dich zur Reader-Gruppe (<application gateway readers group>) hinzuzufügen. Die Gruppenmitgliedschaft wird wie jeder andere Zugriff verwaltet, siehe Zugriff, Gruppen und PIM.

Die Logs abfragen

  1. Öffne die Application-Gateway-Ressource (<application gateway name>) im Azure-Portal.
  2. Wähle Logs. Die Abfrage läuft gegen den zentralen Workspace.
  3. Frage die Tabelle ab, die die Gateway-Diagnosedaten enthält.

In der Beispielplattform liegen die Logs in der Legacy-Tabelle AzureDiagnostics. Sie wird von vielen Ressourcentypen gemeinsam genutzt, daher solltest du immer nach Ressourcentyp und Log-Kategorie filtern:

AzureDiagnostics
| where ResourceType == "APPLICATIONGATEWAYS"
| where Category == "ApplicationGatewayFirewallLog"
| where TimeGenerated > ago(1h)
| take 50

Verwende ApplicationGatewayAccessLog als Kategorie für Access-Logs. Die Spalten unterscheiden sich je Kategorie. Sieh dir zuerst ein paar Zeilen mit take an. Die Plattform kann später auf ressourcenspezifische Tabellen umsteigen, wodurch sich die Tabellennamen ändern. Dein Plattform-Team kündigt das an.

Woher die Logs kommen

Logs gibt es nur, wenn eine Diagnoseeinstellung sie an einen Workspace sendet. Der Shared-Services-Code für das Application Gateway legt keine Diagnoseeinstellung für das Gateway an (nur für einige andere Shared Services). Auf einer Plattform, die ihn nutzt, kommt die Einstellung von anderer Stelle, zum Beispiel von einer policy. Wenn du keine Zeilen siehst, frag dein Plattform-Team, ob und wohin die Gateway-Logs gesendet werden, bevor du annimmst, dass nichts blockiert wurde.

Von einer blockierten Anfrage zu einer Ausnahme

Das Firewall-Log einer blockierten Anfrage zeigt dir, welche Managed Rule zugeschlagen hat. Nutze es, um die Anfrage für eine Ausnahme aufzubauen (WAF-False-Positives und Ausschlüsse):

  1. Finde den Eintrag zu deiner Anfrage: Filtere nach Zeitpunkt, Hostname und Client-Adresse.
  2. Notiere die Rule ID, die Rule Group und das passende Argument, den Header oder die URI.
  3. Prüfe, dass die Anfrage legitim ist und die Blockierung ein False Positive ist, kein Angriff.
  4. Schicke diese Angaben an das Plattform-Team, mit dem Grund und dem engsten Match, das funktioniert (ein Header-Wert, eine Client- Adresse oder eine URI). Das Plattform-Team und dein Security Officer entscheiden. Das Modul hat Grenzen für Ausnahmen (WAF-Ausnahmen), eine breite Anfrage wird also wahrscheinlich abgelehnt.

Beachte den Policy-Modus: Im Modus Detection protokolliert die WAF nur, im Modus Prevention blockiert sie. Frag, welcher Modus für deinen Listener gilt.

Firewall-Logs

Logs der hub Azure Firewall funktionieren auf dieselbe Weise: eine Reader-Gruppe, ein zentraler Workspace und Tabellen wie AZFWNetworkRule und AZFWApplicationRule. Siehe Firewallregeln und das Firewall-Runbook, wie du sie nutzt, wenn eine Verbindung blockiert wird.