Was ist eine Access Policy in ZPA?
Eine Access Policy in Zscaler Private Access (ZPA) ist das Regelwerk, das entscheidet, welche Nutzer auf welche internen Anwendungen zugreifen dürfen. Sie setzt das Zero-Trust-Prinzip um: Ohne ausdrückliche Erlaubnis entsteht kein Zugriff. Jede Regel prüft Kriterien wie Nutzer, Gruppe, Geräte-Posture oder Netzwerk und trifft dann eine Aktion, meist Erlauben oder Sperren. ZPA wertet die Regeln von oben nach unten aus und wendet die erste passende an, bezogen auf das speziellste betroffene App-Segment. Damit ist die Access Policy die zentrale Stelle, an der aus Identität und Gerätezustand eine konkrete Zugriffsentscheidung wird.
Access Policy im Detail
Die Auswertung folgt zwei Grundregeln: von oben nach unten und erster Treffer gewinnt, jeweils für das speziellste App-Segment, das die Anfrage betrifft. Als Kriterien lassen sich laut Zscaler-Dokumentation Nutzer und Gruppen, SAML- und SCIM-Attribute, Geräte-Posture-Profile, Client-Typen, vertrauenswürdige Netzwerke und Maschinengruppen kombinieren. Innerhalb einer Regel steuern UND- und ODER-Operatoren, wie streng sie greift; mehrere gleichartige Werte verknüpft ZPA standardmäßig mit ODER.
Als Aktion kann eine Regel den Zugriff erlauben, sperren oder eine Freigabe verlangen. Weil ohne passende Erlauben-Regel nichts durchgeht, ist die Reihenfolge entscheidend: Eine breite Sperr-Regel weit oben kann speziellere Erlaubnisse darunter unwirksam machen. Die Access Policy hängt außerdem an der Identität aus dem Identity Provider und am Gerätezustand aus dem Posture-Profil, ist also nur so verlässlich wie diese Bausteine.
Warum ist eine Access Policy im Zscaler-Betrieb wichtig?
Die Access Policy ist der Ort, an dem sich Least Privilege konkret zeigt. Statt eines flachen Netzzugangs bekommt jeder Nutzer nur die Anwendungen, die seine Rolle braucht. Das reduziert die Angriffsfläche spürbar, weil ein kompromittiertes Konto nicht automatisch das ganze interne Netz sieht. Genau deshalb schauen Auditoren nach NIS2 oder DORA gern auf diese Regeln: Sie belegen, dass Zugriff kontrolliert und begründet vergeben wird.
Für den Helpdesk ist die Access Policy der erste Verdächtige, wenn eine interne Anwendung nicht erreichbar ist. Die Frage lautet dann: Welche Regel hat gegriffen, war es eine Sperre, oder scheiterte ein Kriterium wie das Posture-Profil? Wer diese Kette schnell lesen kann, klärt Zugriffstickets in Minuten statt in einer Eskalation an das ZPA-Team. Voraussetzung ist ein nachvollziehbarer Blick auf die Regeln, ohne dafür selbst Änderungsrechte zu brauchen.
Typische Fehlerquellen
- Reihenfolge unterschätzt: Eine breite Sperr-Regel weit oben verdeckt speziellere Erlaubnisse darunter, obwohl beide fachlich gewollt sind.
- ODER statt UND: Mehrere Attribute in einer Regel wirken standardmäßig mit ODER, was eine Regel unbeabsichtigt weiter öffnet als gedacht.
- Posture-Profil als stiller Blocker: Der Zugriff scheitert am Gerätezustand, nicht an der Zugriffslogik, und wird trotzdem dort gesucht.
- Zu breite Erlaubnisse: Regeln, die viele Anwendungen auf einmal freigeben, weichen das Zero-Trust-Prinzip wieder auf.
Access Policy in der Praxis: so hilft CentaurNexus
CentaurNexus macht ZPA-Access-Policy-Regeln über die Access-Lens lesend sichtbar, ohne dass der Helpdesk ein ZPA-Admin-Konto braucht. Zusammen mit der 360°-User-Suche, die den Status eines Nutzers über ZIA, ZPA und ZDX auf einer Seite zeigt, lässt sich ein gescheiterter Zugriff einordnen: Greift eine Sperre, fehlt eine Zuordnung, oder scheitert das Posture-Profil? Weil die Sicht rein lesend ist, bleibt die Zugriffslogik unangetastet, und die Erstdiagnose bleibt trotzdem im First-Level. Wie dieser Befund-statt-Bauchgefühl-Ansatz aussieht, zeigt der Beitrag Zscaler-Support ohne Admin-Rechte.
Verwandte Begriffe
Häufige Fragen zur Access Policy
Private Access wertet die Regeln von oben nach unten aus und wendet die erste passende Regel an. Maßgeblich ist dabei das speziellste betroffene App-Segment. Ergibt keine Regel einen Treffer, greift die restriktive Grundhaltung von Zero Trust: Ohne ausdrückliche Erlaubnis entsteht kein Zugriff.
Laut Zscaler-Dokumentation lassen sich Nutzer und Gruppen, SAML- und SCIM-Attribute, Geräte-Posture-Profile, Client-Typen, vertrauenswürdige Netzwerke sowie Maschinengruppen kombinieren. Mehrere Attribute verknüpft ZPA standardmäßig mit ODER, sodann steuern UND- und ODER-Operatoren, wie streng eine Regel greift.
Eine Access-Policy-Regel kann als Aktion Zugriff erlauben, Zugriff sperren oder eine Freigabe verlangen. Bei Require Approval wird der Zugriff erst nach einer Genehmigung möglich. So lassen sich sensible Anwendungen bereitstellen, ohne sie dauerhaft offen zu halten.
Meistens greift weiter oben eine speziellere Regel, oder ein Kriterium ist nicht erfüllt. Häufigster Fall: Das geforderte Geräte-Posture-Profil wird nicht bestanden, etwa weil Verschlüsselung oder Virenschutz fehlen. Dann blockt die Richtlinie korrekt, obwohl eine Erlauben-Regel existiert.
Die Client-Forwarding-Policy legt fest, welcher Verkehr überhaupt über ZPA geleitet wird. Die Access Policy entscheidet danach, ob ein Nutzer die angeforderte Anwendung erreichen darf. Erst beide zusammen ergeben den Weg vom Client bis zur freigegebenen internen Ressource.
- Zscaler Help Portal: About Access Policy - help.zscaler.com
- Zscaler Help Portal: Configuring Access Policies - help.zscaler.com
Hinweis: CentaurNexus ist ein unabhängiges Produkt der SourcingBlox GmbH und kein Angebot von Zscaler, Inc. Produkt- und Markennamen gehören ihren jeweiligen Inhabern.