Qu'est-ce qu'une Access Policy dans ZPA ?
Une Access Policy dans Zscaler Private Access (ZPA) est l'ensemble de règles qui détermine quels utilisateurs peuvent accéder à quelles applications internes. Elle met en œuvre le principe Zero Trust : sans autorisation explicite, aucun accès n'est créé. Chaque règle vérifie des critères comme l'utilisateur, le groupe, la Posture de l'appareil ou le réseau, puis déclenche une action, le plus souvent autoriser ou bloquer. ZPA évalue les règles de haut en bas et applique la première qui correspond, pour le App Segment le plus spécifique concerné. L'Access Policy est ainsi le point central où l'identité et l'état de l'appareil se transforment en une décision d'accès concrète.
Access Policy en détail
L'évaluation suit deux règles de base : de haut en bas, et la première correspondance l'emporte, à chaque fois pour le App Segment le plus spécifique concerné par la demande. Selon la documentation Zscaler, les critères combinables sont les utilisateurs et groupes, les attributs SAML et SCIM, les profils de Posture des appareils, les types de client, les réseaux de confiance et les groupes de machines. À l'intérieur d'une règle, des opérateurs ET et OU déterminent sa rigueur ; ZPA relie par défaut plusieurs valeurs de même type avec OU.
Comme action, une règle peut autoriser l'accès, le bloquer, ou exiger une validation. Comme rien ne passe sans règle d'autorisation correspondante, l'ordre est déterminant : une règle de blocage large placée en haut peut rendre inopérantes des autorisations plus spécifiques situées en dessous. L'Access Policy dépend en outre de l'identité fournie par l'Identity Provider et de l'état de l'appareil issu du profil de posture ; elle n'est donc fiable qu'à la hauteur de ces briques.
Pourquoi une Access Policy compte-t-elle dans l'exploitation Zscaler ?
L'Access Policy est l'endroit où le Least Privilege se manifeste concrètement. Au lieu d'un accès réseau plat, chaque utilisateur ne reçoit que les applications dont son rôle a besoin. Cela réduit nettement la surface d'attaque, car un compte compromis ne voit pas automatiquement tout le réseau interne. C'est précisément pourquoi les auditeurs NIS2 ou DORA examinent volontiers ces règles : elles prouvent que l'accès est accordé de façon contrôlée et justifiée.
Pour le helpdesk, l'Access Policy est le premier suspect lorsqu'une application interne est inaccessible. La question devient alors : quelle règle s'est appliquée, était-ce un blocage, ou un critère comme le profil de posture a-t-il échoué ? Qui sait lire cette chaîne rapidement résout des tickets d'accès en quelques minutes plutôt que par une escalade vers l'équipe ZPA. Cela suppose un accès compréhensible aux règles, sans avoir besoin soi-même de droits de modification.
Sources d'erreur courantes
- Ordre sous-estimé : une règle de blocage large placée en haut masque des autorisations plus spécifiques en dessous, alors que les deux sont fonctionnellement voulues.
- OU au lieu de ET : plusieurs attributs dans une règle fonctionnent par défaut avec OU, ce qui ouvre une règle plus largement que prévu, sans que ce soit voulu.
- Profil de posture comme blocage silencieux : l'accès échoue à cause de l'état de l'appareil, pas de la logique d'accès, mais c'est pourtant là qu'on cherche le problème.
- Autorisations trop larges : des règles qui ouvrent de nombreuses applications à la fois affaiblissent à nouveau le principe Zero Trust.
Access Policy en pratique : ce qu'apporte CentaurNexus
CentaurNexus rend les règles ZPA Access Policy visibles en lecture via l'Access Lens, sans que le helpdesk ait besoin d'un compte administrateur ZPA. Combinée à la recherche utilisateur à 360°, qui affiche sur une seule page le statut d'un utilisateur pour ZIA, ZPA et ZDX, elle permet de qualifier un accès en échec : un blocage s'applique-t-il, une affectation manque-t-elle, ou le profil de posture échoue-t-il ? Comme la vue reste purement en lecture, la logique d'accès n'est jamais modifiée, et le premier diagnostic reste malgré tout au niveau 1st Level. L'article suivant montre à quoi ressemble cette approche fondée sur les faits plutôt que sur l'intuition : Support Zscaler sans droits d'administration.
Termes associés
Questions fréquentes sur l'Access Policy
Private Access évalue les règles de haut en bas et applique la première règle correspondante. Le App Segment le plus spécifique concerné fait foi. Si aucune règle ne correspond, la posture restrictive par défaut du Zero Trust s'applique : sans autorisation explicite, aucun accès n'est créé.
Selon la documentation Zscaler, il est possible de combiner utilisateurs et groupes, attributs SAML et SCIM, profils de Posture des appareils, types de client, réseaux de confiance ainsi que groupes de machines. ZPA relie par défaut plusieurs attributs avec OU ; des opérateurs ET et OU déterminent ensuite la rigueur d'une règle.
Une règle Access Policy peut, comme action, autoriser l'accès, le bloquer, ou exiger une validation. Avec Require Approval, l'accès n'est possible qu'après une approbation. Cela permet de mettre à disposition des applications sensibles sans les laisser ouvertes en permanence.
Le plus souvent, une règle plus spécifique s'applique plus haut, ou un critère n'est pas rempli. Cas le plus fréquent : le profil de posture requis n'est pas validé, par exemple parce que le chiffrement ou l'antivirus font défaut. La policy bloque alors correctement, même si une règle d'autorisation existe.
La Client Forwarding Policy détermine quel trafic est acheminé via ZPA. L'Access Policy décide ensuite si un utilisateur est autorisé à atteindre l'application demandée. C'est seulement la combinaison des deux qui constitue le chemin complet, du client jusqu'à la ressource interne autorisée.
- Portail d'aide Zscaler : About Access Policy - help.zscaler.com
- Portail d'aide Zscaler : Configuring Access Policies - help.zscaler.com
Remarque : CentaurNexus est un produit indépendant de SourcingBlox GmbH et non une offre de Zscaler, Inc. Les noms de produits et de marques appartiennent à leurs détenteurs respectifs.