Review von WAF-Policies¶
Reviewer-Runbook für pull requests, die eine Web-Application-Firewall-(WAF-)Policy des Application Gateway ändern: eine Custom Rule, ein Override einer Managed Rule, eine Exclusion oder eine deaktivierte Regel. Die Policy-Dateien und ihre Auswirkungen stehen unter Application Gateway. Das Deployment ist dasselbe wie für das Gateway (Application-Gateway-Deployment).
Was eine Änderung der WAF-Policy ist¶
Eine WAF im Prevention-Modus blockiert Anfragen, die ihren Managed Rules entsprechen. Eine Änderung der WAF-Policy hat normalerweise einen dieser Gründe:
| Grund | Beispiel |
|---|---|
| Ein False Positive: Eine legitime Anfrage wird blockiert | Eine Anfrage mit vielen Sonderzeichen in einem Argument. |
| Ein neuer Schutz | Eine Custom Rule, die eine Quelle oder ein Muster blockiert. |
| Eine neue Policy für einen workload | Eine separate Policy für einen Listener oder Pfad. |
Jede Policy ist eine Datei web_application_firewall_policy_<name>.json in <region>/web_application_firewall_policies/.
1. Den pull request öffnen und seinen Zustand prüfen¶
Öffne das Ticket, folge dem Link zum pull request und führe die Prüfungen aus Pull-Request-Review durch: kein Draft, die Validierungs-pipeline ist grün, keine Merge-Konflikte, alle Kommentare gelöst, ein Ticket verlinkt. Schlägt eine fehl, schicke den pull request zurück.
2. Den Nachweis prüfen¶
Eine Änderung, die eine Regel deaktiviert oder ausnimmt, braucht einen Nachweis im Ticket:
| Nachweis | Warum |
|---|---|
| Die blockierte Anfrage: URI, Name des Arguments oder Headers, die Rule ID aus dem WAF-Log | Zeigt, welche Regel man sich ansehen muss. |
| Warum es ein False Positive ist | Ohne das ist die Ausnahme geraten. |
| Die Freigabe der Security | Eine Ausnahme senkt den Schutz. |
| Das Ende der Ausnahme oder ein Review-Datum | Ausnahmen sollten nicht ewig leben. |
3. Die Datei prüfen¶
Für jede Datei im pull request:
| Check | Warum |
|---|---|
| Die Änderung ist die engste, die das Problem löst: eine Exclusion für ein Argument statt eine Regel zu deaktivieren | Erhält den Rest des Schutzes. |
| Die Rule IDs sind die aus dem Log | Eine falsche ID lässt das False Positive bestehen. |
Der Dateiname folgt web_application_firewall_policy_<name>.json und liegt im richtigen Regionsordner |
Die Datei wird über dieses Muster gefunden. |
| Das JSON passt zum Schema der WAF-Policy | Die Config Tests nutzen es. |
Die Policy, auf die von einem Gateway, Listener oder Pfad verwiesen wird, existiert, mit einer korrekten firewall_policy_id |
Eine falsche ID lässt die Gateway-Änderung scheitern. |
| Custom Rules: eindeutige Prioritäten, eine klare Match-Bedingung, eine korrekte Aktion | Eine zu breite Custom Rule kann echte Benutzer blockieren. |
Die Änderung ist in canary und in prod, oder die Beschreibung sagt, warum nur in prod |
canary ist der Ort zum Testen. |
| Die Liste der Exclusions und deaktivierten Regeln ist aktualisiert, mit Begründung | Du brauchst sie, um sie später zu prüfen. |
policy_settings werden nur beim Erstellen der Policy angewendet
Das Modul ignoriert spätere Änderungen von policy_settings (zum Beispiel den Modus Detection oder Prevention und die Limits
für die Body-Größe), weil Azure Policy sie ebenfalls ändert. Ein pull request, der nur diese Einstellungen ändert, hat keine
Wirkung auf eine bestehende Policy. Custom Rules und Overrides von Managed Rules werden aktualisiert. Frag den Autor, wie die Einstellung
geändert werden soll (im Portal, mit Nachweis der Änderung, oder mit einer neuen Policy). Siehe
WAF-Policy für den workload.
Die Wirkung testen
Eine zusätzliche WAF-Einstellung zu aktivieren, etwa die Prüfung des Request Body, kann ohne Test legitime Anfragen blockieren
(Benutzer sehen 403). Bitte um einen Test auf canary und prüfe nach dem Deployment das WAF-Log
(Bekannte Probleme).
4. Abschließendes Review¶
- Alles ist in Ordnung: Genehmige den pull request und deploye (Application-Gateway-Deployment).
Der layer ist
connectivity. - Etwas stimmt nicht: Kommentiere, setze das Ticket zurück auf New und weise es dem Autor zu.
Bitte den Anfragenden nach dem Deployment, die blockierte Anfrage zu wiederholen, und prüfe, dass sie durchkommt. Sieh im WAF-Log nach der Rule ID, ob sie noch greift.