Qu'est-ce que le Privileged Remote Access (PRA) ?

Privileged Remote Access en détail

PRA s'appuie sur la logique d'accès de ZPA et en hérite le principe Zero Trust : les systèmes cibles ne sont pas accessibles ouvertement depuis Internet, mais uniquement via une session expressément autorisée et contrôlée. L'utilisateur se connecte sur un portail d'accès puis ouvre la console du système cible directement dans le navigateur. Selon la documentation, les protocoles disponibles sont RDP, SSH, VNC et RealVNC, complétés par des fonctions comme le transfert de fichiers, le presse-papiers et le clavier virtuel.

La différence avec un serveur de rebond classique tient au contrôle des identifiants et des sessions. Les identifiants privilégiés peuvent être injectés dans la session sans être révélés à l'utilisateur ; sinon, l'utilisateur saisit ses propres identifiants. Si l'enregistrement de session est actif, chaque session privilégiée est conservée comme preuve et rattachée à un utilisateur précis. L'accès reste par ailleurs soumis à la policy d'accès et au profil de posture.

Pourquoi Privileged Remote Access compte-t-il dans l'exploitation Zscaler ?

L'accès privilégié est la voie que les attaquants préfèrent emprunter : des droits élevés, souvent attribués largement, rarement journalisés de bout en bout. L'architecture classique VPN plus serveur de rebond ouvre pour cela un accès réseau et diffuse des mots de passe privilégiés. PRA inverse la logique : pas de client, pas d'accès réseau ouvert, mais une session dans le navigateur limitée à un seul système cible, avec des identifiants contrôlés. Cela convient particulièrement aux prestataires externes et aux environnements OT où aucun poste géré ne peut être déployé.

Pour les preuves exigées par NIS2 ou DORA, l'enregistrement de session et les logs d'audit comptent avant tout. Qui doit prouver qui a travaillé quand, avec quels droits, sur un système critique dispose, avec des sessions journalisées et enregistrées, d'une base solide. Dans l'exploitation, cela crée un niveau supplémentaire que le helpdesk et les responsables sécurité doivent garder à l'œil : à côté de ZIA, ZPA et ZDX, les sessions privilégiées s'ajoutent comme canal d'accès à part entière.

Sources d'erreur courantes

• PRA pensé comme un VPN complet : l'accès se limite à des systèmes cibles précis, pas à tout un réseau.
• Gestion des identifiants approximative : qui n'utilise pas l'injection contrôlée finit par redistribuer des mots de passe privilégiés à la main.
• Enregistrement de session non activé : là où des preuves sont exigées, l'absence d'enregistrement prive de la trace décisive.
• Access Policy et Posture négligées : PRA hérite des deux, un accès en échec peut aussi venir de là.

Privileged Remote Access en pratique : ce qu'apporte CentaurNexus

Avec Unified Support Center, CentaurNexus regroupe la vision à 360 degrés étendue d'un utilisateur et y intègre les sessions PRA, en plus du statut ZIA, ZPA et ZDX. Le helpdesk voit ainsi sur une seule page si et comment un utilisateur a utilisé des sessions privilégiées, sans avoir besoin d'un compte administrateur Zscaler pour la recherche. La vue reste en lecture seule : elle ne modifie rien à l'accès ni à l'enregistrement, mais rend l'accès privilégié compréhensible au quotidien. L'article suivant montre comment fonctionne cette approche à 360 degrés sans droits d'administration : Support Zscaler sans droits d'administration.

Termes associés