Was sind Shadowed Rules?
Shadowed Rules (verdeckte Regeln) sind Regeln, die nie zur Anwendung kommen, weil eine früher ausgewertete Regel ihren Geltungsbereich vollständig abdeckt. Firewalls und Web-Gateways arbeiten Regelwerke in fester Reihenfolge ab: Die erste passende Regel gewinnt. Deckt eine breite Regel weiter oben alle Fälle einer spezifischeren Regel weiter unten ab, ist die untere faktisch wirkungslos, obwohl sie im Regelwerk korrekt aussieht. Besonders kritisch ist der Fall unterschiedlicher Aktionen: Verdeckt eine Erlauben-Regel eine Blockier-Regel, ist eine gewollte Schutzmaßnahme außer Kraft, ohne dass es jemand bemerkt. Shadowed Rules sind damit ein Spezialfall des Policy-Konflikts.
Shadowed Rules im Detail
Die Analyse unterscheidet vollständiges und teilweises Shadowing. Beim vollständigen Shadowing deckt die frühere Regel jeden Fall der späteren ab; die spätere greift nie. Beim teilweisen Shadowing überlappen sich die Geltungsbereiche nur zum Teil; die spätere Regel greift dann seltener oder anders als gedacht. Verwandt, aber harmloser ist Redundanz: Zwei Regeln mit gleicher Aktion überschneiden sich, das Verhalten bleibt korrekt, nur das Regelwerk wird unnötig groß.
Shadowed Rules entstehen fast immer durch Arbeitsroutine: Neue Regeln werden ans Ende gehängt, ohne die Auswertungsreihenfolge zu prüfen, oder eine als Zwischenlösung gedachte breite Freigabe bleibt weit oben im Regelwerk stehen. Im Zscaler-Betrieb betrifft das alle geordnet ausgewerteten Richtlinien, etwa URL-Filtering- und Cloud-Firewall-Regeln in ZIA sowie Zugriffsrichtlinien in ZPA. Je mehr Administratoren parallel arbeiten, desto wahrscheinlicher verdecken sich Regeln unbemerkt.
Warum sind Shadowed Rules im Zscaler-Betrieb wichtig?
Das Tückische an Shadowed Rules ist ihre Unsichtbarkeit im Alltag. Wie sich zwei sich überdeckende Regeln im direkten Vergleich gegenüberstellen lassen, zeigt unser rund zweiminütiges Video zum Policy Conflict Review. Das Regelwerk sieht vollständig aus, die Dokumentation stimmt scheinbar, aber das tatsächliche Verhalten weicht ab. Für den Helpdesk entstehen daraus schwer erklärbare Tickets: Eine Blockierung greift nicht, obwohl die Regel existiert, oder ein Zugriff scheitert, obwohl er freigegeben wurde. Ohne systematische Analyse endet die Fehlersuche im manuellen Abgleich von Regelwerken mit teils hunderten Einträgen.
Für Sicherheit und Nachweis wiegt der Fall unterschiedlicher Aktionen am schwersten: Eine verdeckte Blockier-Regel bedeutet, dass eine beschlossene Schutzmaßnahme nicht wirkt. Wer nach NIS2 oder DORA die konsistente Durchsetzung von Richtlinien belegen muss, braucht deshalb einen Review, der Shadowing systematisch erkennt und dessen Auflösung dokumentiert. Die Korrektur gehört dabei in Menschenhand: einzeln entschieden, freigegeben und protokolliert.
Typische Fehlerquellen
- Neue Regeln ungeprüft ans Ende hängen: Ohne Blick auf die Auswertungsreihenfolge entsteht Shadowing schon beim nächsten Eintrag.
- Nur einzelne Regeln prüfen: Shadowing zeigt sich erst im Paarvergleich der Geltungsbereiche, nicht an einer Regel für sich.
- Verdeckte Regeln pauschal löschen: Oft ist die verdeckte Regel die fachlich richtige; dann muss der Konflikt aufgelöst werden, nicht die Regel verschwinden.
- Massenhaftes Umsortieren als Abkürzung: Wer die Reihenfolge im Block ändert, verändert das Verhalten des gesamten Regelwerks und erzeugt neue Konflikte.
Shadowed Rules in der Praxis: so hilft CentaurNexus
Policy Conflict Review von CentaurNexus prüft das Zscaler-Regelwerk als rein lesende Analyse über die offizielle OneAPI und weist Shadowing-Befunde samt beider beteiligter Regeln und Fundstelle aus. Einen Knopf, der das Regelwerk automatisch umsortiert, gibt es bewusst nicht: Jede Auflösung bleibt eine einzelne, menschlich entschiedene Änderung, die optional per Vier-Augen-Prinzip freigegeben wird und im append-only geführten Audit-Trail landet. So lässt sich jederzeit belegen, welche Befunde erkannt, entschieden und behoben wurden. Wie sich verdeckte Regeln kontrolliert bereinigen lassen, zeigt der Beitrag Ungenutzte Zscaler-Regeln aufräumen.
Verwandte Begriffe
Häufige Fragen zu Shadowed Rules
Meist durch Routine: Neue Regeln werden ans Ende des Regelwerks gehängt, ohne zu prüfen, ob eine frühere, breitere Regel denselben Fall bereits abdeckt. Auch Sammel-Freigaben, die als Zwischenlösung weit oben eingefügt wurden, verdecken spätere spezifische Regeln. Mit jeder Änderung durch mehrere Bearbeiter steigt die Wahrscheinlichkeit unbemerkter Überdeckungen.
Durch einen Paarvergleich aller Regeln: Deckt der Geltungsbereich einer früher ausgewerteten Regel eine spätere ganz oder teilweise ab? Manuell ist das ab einigen Dutzend Regeln kaum leistbar. Praktikabel ist eine werkzeuggestützte, rein lesende Analyse über die Zscaler-API, die beide beteiligten Regeln samt Fundstelle benennt und die Befunde dokumentiert.
Potenziell ja. Verdeckt eine Erlauben-Regel eine Blockier-Regel, ist eine beschlossene Schutzmaßnahme faktisch abgeschaltet, ohne dass das Regelwerk es zeigt. Umgekehrt bleiben gewollte Freigaben wirkungslos und erzeugen Support-Fälle. Selbst harmlose Fälle täuschen eine Richtlinienlage vor, die es so nicht gibt, und schwächen damit jede Nachweisführung.
Bei Redundanz überschneiden sich Regeln mit gleicher Aktion: Das Verhalten bleibt korrekt, das Regelwerk ist nur unnötig groß. Beim Shadowing kommt eine Regel gar nicht mehr zur Anwendung; sehen beide Regeln unterschiedliche Aktionen vor, weicht das tatsächliche Verhalten vom dokumentierten ab. Shadowing ist deshalb der deutlich kritischere Befund.
Davon ist abzuraten. Die Reihenfolge ist Teil der Richtlinienlogik: Wer automatisch umsortiert, ändert das Verhalten des gesamten Regelwerks und riskiert neue Konflikte. Bewährt hat sich eine rein lesende Erkennung plus einzelne, menschlich geprüfte Korrekturen mit Vier-Augen-Freigabe und Audit-Trail. So bleibt jede Änderung nachvollziehbar und rückholbar.
- NIST SP 800-41 Rev. 1: Guidelines on Firewalls and Firewall Policy - csrc.nist.gov
- Zscaler Help Portal: offizielle Dokumentation zu ZIA-Richtlinien (URL-Filtering, Cloud Firewall) - help.zscaler.com
- BSI IT-Grundschutz, Baustein NET.3.2 Firewall (Anforderungen an Regelwerks-Pflege) - bsi.bund.de/.../NET_3_2_Firewall
Hinweis: CentaurNexus ist ein unabhängiges Produkt der SourcingBlox GmbH und kein Angebot von Zscaler, Inc. Produkt- und Markennamen gehören ihren jeweiligen Inhabern.