Wat zijn Shadowed Rules?
Shadowed Rules (gemaskeerde regels) zijn regels die nooit worden toegepast, omdat een eerder beoordeelde regel hun reikwijdte volledig afdekt. Firewalls en webgateways werken regelsets in een vaste volgorde af: de eerst passende regel wint. Dekt een brede regel hogerop alle gevallen van een specifiekere regel lager af, dan is die laatste feitelijk zonder effect, ook al ziet ze er in de regelset correct uit. Bijzonder kritiek is het geval van verschillende acties: maskeert een toestaan-regel een blokkeer-regel, dan is een bedoelde beveiligingsmaatregel buiten werking, zonder dat iemand het merkt. Shadowed Rules zijn daarmee een bijzonder geval van het policy-conflict.
Shadowed Rules in detail
De analyse onderscheidt volledig en gedeeltelijk shadowing. Bij volledig shadowing dekt de eerdere regel elk geval van de latere af; die laatste werkt dan nooit. Bij gedeeltelijk shadowing overlappen de reikwijdtes maar ten dele; de latere regel werkt dan minder vaak of anders dan bedoeld. Verwant, maar onschuldiger, is redundantie: twee regels met dezelfde actie overlappen, het gedrag blijft correct, alleen wordt de regelset onnodig groot.
Shadowed Rules ontstaan bijna altijd door werkroutine: nieuwe regels worden achteraan toegevoegd zonder de beoordelingsvolgorde te controleren, of een als tussenoplossing bedoelde brede vrijgave blijft hoog in de regelset staan. In de Zscaler-praktijk raakt dit alle geordend beoordeelde richtlijnen, bijvoorbeeld URL Filtering- en Cloud Firewall-regels in ZIA en toegangsrichtlijnen in ZPA. Hoe meer beheerders parallel werken, hoe waarschijnlijker regels elkaar ongemerkt maskeren.
Waarom tellen Shadowed Rules in de Zscaler-praktijk?
Het verraderlijke aan Shadowed Rules is hun onzichtbaarheid in de dagelijkse praktijk. Hoe twee elkaar overlappende regels rechtstreeks naast elkaar zijn te zetten, laat onze video van ongeveer twee minuten over Policy Conflict Review zien. De regelset oogt compleet, de documentatie lijkt te kloppen, maar het werkelijke gedrag wijkt af. Voor de helpdesk ontstaan daardoor lastig te verklaren tickets: een blokkering werkt niet, hoewel de regel bestaat, of toegang mislukt, hoewel die is vrijgegeven. Zonder systematische analyse eindigt het onderzoek in een handmatige vergelijking van regelsets met soms honderden regels.
Voor beveiliging en bewijsvoering weegt het geval van verschillende acties het zwaarst: een gemaskeerde blokkeer-regel betekent dat een besloten beveiligingsmaatregel niet werkt. Wie onder NIS2 of DORA de consistente handhaving van richtlijnen moet aantonen, heeft daarom een review nodig die shadowing systematisch herkent en de oplossing ervan documenteert. De correctie hoort daarbij in mensenhanden: afzonderlijk beslist, goedgekeurd en vastgelegd.
Veelvoorkomende foutbronnen
- Nieuwe regels ongecontroleerd achteraan toevoegen: zonder aandacht voor de beoordelingsvolgorde ontstaat shadowing al bij de eerstvolgende regel.
- Alleen afzonderlijke regels controleren: shadowing blijkt pas uit een paarsgewijze vergelijking van reikwijdtes, niet uit één regel op zich.
- Gemaskeerde regels zomaar verwijderen: vaak is de gemaskeerde regel inhoudelijk de juiste; dan moet het conflict worden opgelost, niet de regel verdwijnen.
- Massaal herschikken als kortere weg: wie de volgorde in blok wijzigt, verandert het gedrag van de hele regelset en creëert nieuwe conflicten.
Shadowed Rules in de praktijk: wat CentaurNexus bijdraagt
Policy Conflict Review van CentaurNexus controleert de Zscaler-regelset als zuiver lezende analyse via de officiële OneAPI en toont shadowing-bevindingen inclusief beide betrokken regels en vindplaats. Een knop die de regelset automatisch herschikt, is er bewust niet: elke oplossing blijft een individuele, door een mens beslist wijziging, die optioneel via het vierogenprincipe wordt goedgekeurd en in de append-only audit trail terechtkomt. Zo is te allen tijde te bewijzen welke bevindingen zijn herkend, beslist en verholpen. Hoe gemaskeerde regels beheerst zijn op te ruimen, laat het artikel zien Ongebruikte Zscaler-regels opruimen.
Verwante begrippen
Veelgestelde vragen over Shadowed Rules
Meestal door routine: nieuwe regels worden achteraan in de regelset toegevoegd, zonder te controleren of een eerdere, bredere regel hetzelfde geval al afdekt. Ook verzamelvrijgaven die als tussenoplossing hoog zijn ingevoegd, maskeren latere specifieke regels. Met elke wijziging door meerdere beheerders neemt de kans op onopgemerkte afdekkingen toe.
Via een paarsgewijze vergelijking van alle regels: dekt de reikwijdte van een eerder beoordeelde regel een latere geheel of gedeeltelijk af? Handmatig is dat vanaf enkele tientallen regels nauwelijks te doen. Praktisch is een toolondersteunde, zuiver lezende analyse via de Zscaler-API, die beide betrokken regels inclusief vindplaats benoemt en de bevindingen documenteert.
Potentieel wel. Maskeert een toestaan-regel een blokkeer-regel, dan is een besloten beveiligingsmaatregel feitelijk uitgeschakeld, zonder dat de regelset dit toont. Omgekeerd blijven gewenste vrijgaven zonder effect en leiden ze tot supportgevallen. Zelfs onschuldig ogende gevallen wekken de indruk van een regelsituatie die zo niet bestaat, en verzwakken daarmee elke bewijsvoering.
Bij redundantie overlappen regels met dezelfde actie: het gedrag blijft correct, de regelset wordt alleen onnodig groot. Bij shadowing wordt een regel helemaal niet meer toegepast; voorzien beide regels verschillende acties, dan wijkt het werkelijke gedrag af van het gedocumenteerde. Shadowing is daarom de duidelijk kritischere bevinding.
Dat wordt afgeraden. De volgorde maakt deel uit van de regellogica: wie automatisch herschikt, verandert het gedrag van de hele regelset en riskeert nieuwe conflicten. Beproefd is een zuiver lezende opsporing plus individuele, door een mens gecontroleerde correcties met goedkeuring via het vierogenprincipe en audit trail. Zo blijft elke wijziging navolgbaar en terug te draaien.
- NIST SP 800-41 Rev. 1: Guidelines on Firewalls and Firewall Policy - csrc.nist.gov
- Zscaler Help Portal: officiële documentatie over ZIA-regels (URL Filtering, Cloud Firewall) - help.zscaler.com
- BSI IT-Grundschutz, bouwsteen NET.3.2 Firewall (eisen voor het onderhoud van de regelset) - bsi.bund.de/.../NET_3_2_Firewall
Let op: CentaurNexus is een onafhankelijk product van SourcingBlox GmbH en geen aanbod van Zscaler, Inc. Product- en merknamen behoren toe aan hun respectieve eigenaren.