Data Jurisdictions restrict user access to a second layer of role-based access control for users. Administrators can use Data Jurisdictions to restrict user access to subsets of Shadow IT, Sanctioned Services, Web, and also create Data Jurisdictions based on Saved Views to restrict user access to specific features. The users have only access to data corresponding to that Jurisdiction in the Skyhigh CASB dashboard.
Once you have created a Data Jurisdiction, you can assign users to it on the Users page. Users will not know which Data Jurisdiction they belong to, and they can only access the data corresponding to that Jurisdiction in the Skyhigh CASB dashboard. It will affect what the user can see in Filters, My Dashboard Cards, reports, and charts.
What the users are allowed to see in the Skyhigh CASB user interface is based on the type of page the user tries to access – Shadow, Sanctioned, Web, or Saved Views. So, if the user navigates to the Policy Incidents page, User Activity, or Resources, Sanctioned Service Jurisdictions will apply.
Shadow IT Jurisdictions
For Shadow IT, you can base Data Jurisdictions on Active Directory Attributes or Enterprise Connector Tags. You can then use these tags to segment data by office location, functional group, or any other AD attribute.
For example, you could configure Data Jurisdictions to allow a user in the Mountain View office to only see and access Users and Services corresponding to that office. The user would not be able to see User and Service information from any other geographic location.
For details, see Create Data Jurisdictions for Shadow IT.
Sanctioned Service Jurisdictions
For Sanctioned Services, you can create Data Jurisdictions to limit access to users by Service or Service instance or AD attributes. For example, you could create a Data Jurisdiction for users who are allowed to access AWS accounts or only a particular AWS instance.
For example, let's say a Skyhigh CASB tenant has 20 AWS accounts distributed across four account owners. When an account owner logs in, he or she would see data only for the accounts he or she has access to in Skyhigh CASB on the Policy Incidents page, User Activities, Resources, etc.
In another example, let's say a Skyhigh CASB tenant has three Box accounts, two OneDrive accounts, five Microsoft Azure instances, and 15 AWS accounts. The EU region includes one Box account, one OneDrive, two Azure instances, and three AWS accounts. As the Skyhigh CASB admin, you can create an EU Sanctioned Service Jurisdiction and assign users to it. Then in that EU Jurisdiction, you may configure users who are allowed to see data under specific Azure subscriptions only. You even can create another EU Jurisdiction that has specific subscriptions within those two Azure instances, and assign users to it.
- You can assign a user to each of the following Data Jurisdiction types: Shadow IT, Sanctioned Service Jurisdiction, Web, and Saved View. The overall constraints are the logical ANDing of these jurisdictions.
- Users with these roles cannot be assigned to a Data Jurisdiction:
- User Manager
- Policy Manager
- Users under Jurisdiction will see an alert that some data subject to jurisdiction may not be available for download in a CSV file.
For details, see Create Data Jurisdictions for Sanctioned Services.
For the Web, you can create Data Jurisdictions to limit web services and associated log sources.
For example, you could configure Data Jurisdictions to allow users in the North American region to only see and access the web services and associated log sources corresponding to that region. The user would not be able to see web service information from any other geographic location.
For details, see Create Data Jurisdictions for Web.
Saved View Jurisdictions
Saved View Data Jurisdictions are a second layer of role-based access control for your Skyhigh Security Cloud users. You can restrict the access of users to a specific Saved View in the Policy Incidents using data jurisdiction. You can define the jurisdictional boundaries using either Skyhigh recommended or your own Custom Saved Views. This ensures that any users within the tenancy can access the data in the desired Saved View, providing an extra level of security.
For example, A SOC could restrict access to the DLP incidents on the Policy Incident pages by using Data Jurisdiction. To achieve this, create a saved view by selecting the desired DLP incidents, create a saved view data jurisdiction based on that saved view, and then assign that data jurisdiction to a designated SOC to only see those incidents.
NOTE: Currently, Data Jurisdiction only supports the "Policy Incidents" view.