Wat is een Access Policy in ZPA?
Een Access Policy in Zscaler Private Access (ZPA) is het regelwerk dat bepaalt welke gebruikers welke interne applicaties mogen benaderen. Het zet het Zero Trust-principe om: zonder uitdrukkelijke toestemming ontstaat geen toegang. Elke regel toetst criteria zoals gebruiker, groep, apparaatposture of netwerk en voert dan een actie uit, meestal toestaan of blokkeren. ZPA evalueert de regels van boven naar beneden en past de eerste passende regel toe, voor het meest specifieke betrokken App Segment. Daarmee is de Access Policy de centrale plek waar identiteit en apparaatstatus een concrete toegangsbeslissing worden.
Access Policy in detail
De evaluatie volgt twee basisregels: van boven naar beneden, en de eerste match wint, telkens voor het meest specifieke App Segment waarop de aanvraag betrekking heeft. Volgens de Zscaler-documentatie zijn als criteria te combineren: gebruikers en groepen, SAML- en SCIM-attributen, Posture-profielen van apparaten, clienttypen, vertrouwde netwerken en machinegroepen. Binnen een regel bepalen EN- en OF-operatoren hoe streng ze werkt; meerdere gelijksoortige waarden koppelt ZPA standaard met OF.
Als actie kan een regel de toegang toestaan, blokkeren, of goedkeuring verlangen. Omdat zonder passende toestaan-regel niets doorkomt, is de volgorde bepalend: een brede blokkeerregel hoog in de lijst kan specifiekere toestemmingen daaronder buiten werking stellen. De Access Policy hangt bovendien af van de identiteit uit de Identity Provider en de apparaatstatus uit het Posture-profiel, en is dus maar zo betrouwbaar als deze bouwstenen.
Waarom telt een Access Policy in de Zscaler-praktijk?
De Access Policy is de plek waar Least Privilege concreet zichtbaar wordt. In plaats van platte netwerktoegang krijgt elke gebruiker alleen de applicaties die zijn rol nodig heeft. Dat verkleint het aanvalsoppervlak merkbaar, omdat een gecompromitteerd account niet automatisch het hele interne netwerk ziet. Precies daarom kijken auditors voor NIS2 of DORA graag naar deze regels: ze tonen aan dat toegang gecontroleerd en beargumenteerd wordt toegekend.
Voor de helpdesk is de Access Policy de eerste verdachte wanneer een interne applicatie onbereikbaar is. De vraag luidt dan: welke regel heeft gegrepen, was het een blokkade, of faalde een criterium zoals het Posture-profiel? Wie deze keten snel kan lezen, lost toegangstickets op in minuten in plaats van via een escalatie naar het ZPA-team. Voorwaarde is een navolgbaar zicht op de regels, zonder daarvoor zelf wijzigingsrechten nodig te hebben.
Veelvoorkomende foutbronnen
- Volgorde onderschat: een brede blokkeerregel hoog in de lijst overschaduwt specifiekere toestemmingen daaronder, ook al zijn beide functioneel gewenst.
- OF in plaats van EN: meerdere attributen in een regel werken standaard met OF, waardoor een regel onbedoeld ruimer openstaat dan gedacht.
- Posture-profiel als stille blokkade: de toegang faalt door de apparaatstatus, niet door de toegangslogica, en toch wordt daar gezocht.
- Te ruime toestemmingen: regels die veel applicaties tegelijk vrijgeven, verwateren het Zero Trust-principe weer.
Access Policy in de praktijk: wat CentaurNexus bijdraagt
CentaurNexus maakt ZPA Access Policy-regels leesbaar zichtbaar via de Access Lens, zonder dat de helpdesk een ZPA-beheerdersaccount nodig heeft. Samen met de 360°-gebruikerszoekfunctie, die de status van een gebruiker over ZIA, ZPA en ZDX op één pagina toont, is een mislukte toegang te duiden: grijpt een blokkade, ontbreekt een koppeling, of faalt het Posture-profiel? Omdat het overzicht puur leesbaar is, blijft de toegangslogica onaangetast, en blijft de eerste diagnose toch 1st Level-werk. Hoe deze aanpak van feiten in plaats van onderbuikgevoel eruitziet, laat dit artikel zien: Zscaler-support zonder beheerdersrechten.
Verwante begrippen
Veelgestelde vragen over de Access Policy
Private Access evalueert de regels van boven naar beneden en past de eerste passende regel toe. Bepalend is daarbij het meest specifieke betrokken App Segment. Levert geen enkele regel een match op, dan geldt de restrictieve basishouding van Zero Trust: zonder uitdrukkelijke toestemming ontstaat geen toegang.
Volgens de Zscaler-documentatie zijn te combineren: gebruikers en groepen, SAML- en SCIM-attributen, Posture-profielen van apparaten, clienttypen, vertrouwde netwerken en machinegroepen. ZPA koppelt meerdere attributen standaard met OF, waarna EN- en OF-operatoren bepalen hoe streng een regel werkt.
Een Access Policy-regel kan als actie toegang toestaan, toegang blokkeren, of goedkeuring verlangen. Bij Require Approval is toegang pas mogelijk na goedkeuring. Zo kunt u gevoelige applicaties beschikbaar stellen zonder ze permanent open te houden.
Meestal grijpt hoger in de lijst een specifiekere regel, of is een criterium niet vervuld. Meest voorkomend geval: het vereiste Posture-profiel van het apparaat wordt niet gehaald, bijvoorbeeld omdat versleuteling of virusbescherming ontbreekt. Dan blokkeert de policy terecht, ook al bestaat er een toestaan-regel.
De Client Forwarding Policy bepaalt welk verkeer überhaupt via ZPA wordt geleid. De Access Policy beslist daarna of een gebruiker de gevraagde applicatie mag bereiken. Pas beide samen vormen het volledige pad, van de client tot de vrijgegeven interne resource.
- Zscaler Help Portal: About Access Policy - help.zscaler.com
- Zscaler Help Portal: Configuring Access Policies - help.zscaler.com
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.