New ZIA Role-Based Access Controls Ensure Precise Access to Policy, Reporting and other Controls

As a security model, Role Based Access Control (RBAC) simplifies access management, enhances security, and ensures users only have the minimal access necessary to perform their duties. Restricting system access to users based on their defined roles within an organization means more tightly controlled access to critical functions and thus better security: instead of assigning individual permissions to users, permissions are tied to roles, and users are assigned to these roles. 

Zscaler recommends that customers define roles in the ZIA Admin Portal before adding administrator accounts since each admin created requires a role being applied to it—and we’ve offered this ability for many years now. 

In the past ZIA Super Administrators could only restrict admin accounts to access policy and reporting by granting either full edit, view only or no access at all. There was no way to apply granular control over which specific admins could create, edit or view specific policy and reports based on where the admin was geographically located or the scope of their responsibilities. Now with our new granular RBAC capability, Super Administrators can define precise access to specific policy, reporting and other controls for admin accounts based on role and functional scope. 

Assigning granular access based on an admin role

Zscaler’s RBAC enforces least privilege access in the admin console. Before adding administrator accounts, customers should define roles in the Admin Portal. Each administrator requires a role. The Super Administrator can select specific access rights for other administrators. This allows for fine-grained controls for policies, reports and other admin controls. The Super Administrator can restrict access to specific functional scopes within the Admin Portal. Access levels (create/edit, view only, or no access) depend on the role and scope of each administrator:

• Roles specify features administrators can access in the Admin Portal.
• Scopes specify organizational departments or geographic locations for configuring policies and settings.

Customers can define what administrators can do and see in the Zscaler Admin Portal with flexible criteria, including multiple policy permissions, cloud configurations, admin controls, traffic forwarding, and reporting data.

Simplified yet precise access management enhances security

Prior to this enhanced feature, Zscaler customers were somewhat limited in defining what admin accounts could access based on three primary criteria:

• Admin Rank: creates a hierarchy among admins and ensures that policies and settings configured by admins with higher rank cannot be overridden by admins with lower rank
• Permissions: allow you to control an admin's access to the major features of the Admin Portal across various criteria
• Functional Scope: specify the features and depth of access a role can access, from Full or View Only permission for the Dashboard, Reports Access, Insights Access, and Policy Access.

As a result, admins often ended up with far more privileges than needed, creating risks to the stability of the customer organization’s desired tenant configuration. Alternatively, some customers have opted to fully restrict access for admins to reduce risk, leaving them unable to perform their given job duties effectively. At a more granular level, RBAC issues customers faced included:

• Not having the means to apply granular control over which specific admins could create, edit or view specific policy and reports based on criteria applied uniquely to each admin.
• End user data such as email address and other associated data was not restricted to specific administrators, leading to potential compliance violations.
• Super Admins could only restrict administrator access to policy and reporting in a rudimentary fashion.
• Super Admins could only grant either full edit, view only or no access at all for all administrators, not specific admin accounts

Now Super Administrators can: 

• Apply specific criteria to easily define and enforce access rights to policy and reporting for any administrator in your organization
• Delineate access based on the functional scope of an admin’s responsibilities, location and rank
• Block access to end-user information, reporting and security policy and grant access only to specific admin accounts

Now when the Super Administrator creates a new admin account in the ZIA Admin Portal, they can define what policy and reporting that admin accounts can create, edit and view—or not access at all. Customers can also retroactively apply granular RBAC criteria to pre-existing admin accounts.

Real-world examples of granular role based access control

Theory is great when you need to understand the what, why and how behind a new concept. But now we’ll look at some real-world examples of how to apply granular RBAC access permissions:

Data Loss Prevention admins should have view-only access to SSL Inspection policy: Peter is a DLP admin with privileges to add new or modify DLP policy. Peter would like to have "view only" rights to read SSL Inspection policies to determine if DLP rules will work.

Admins with write access to Bandwidth Control policy: Jane is an admin tasked with adding or modifying the Bandwidth Control Policy and Bandwidth Classes. Jane would like "full" rights to add or change only the Bandwidth Control Policy and Bandwidth Classes.

Visibility of URL Filtering and SSL Inspection policies only: Amir is hired as a help desk contractor from a third-party consulting firm. Amir requires view-only access to the URL Categories and SSL Inspection policy sections in the ZIA Admin Portal for his work. For example, when an employee raises a ticket stating that they cannot visit a site, Amir checks the URL Categories section to see if the site the employee wants access to  is in the Custom URL Category.

Backup operation privileges for many admins and restore privileges for only specific admin accounts: Jo, Jill, and Rohan are ZIA admins, and Peter is a ZIA super administrator of Company XYZ Inc. Jo, Jill, and Rohan are tasked to perform a backup operation after every configuration change. The customer wants only some admins, like Peter, to restore configurations. Since backup is a less disruptive activity from a user-impact standpoint, it can be made available to more admins. Restoring, however, is a very disruptive activity and needs to be accessed only by a few admins.

Leverage the power of RBAC for admin access

RBAC is a powerful way to determine which administrators in your organization can access specific functionality across policy creation and editing and reporting. Now with our new granular functionality, you can extend both the specificity and depth of what your admins can do.

Learn more about our new RBAC capability and how you can put it to work for your organization with additional examples, from allowing HR Admins to access control policies to allowing Admins view-only access to the Zscaler Client Connector Portal.