User Guide
Working With Access Controls
Roll Based Access Controls (RBAC) are how you set who has access to what data within your organization. Roles include controls that determine whether users can create scans, playbooks, and custom reports.
RBAC is used to assign permissions for a role for the level of access to Scan result data. You can have many different types of Roles, and administrators will assign permissions by Role when a group of Users with the same expected level of access needs to be configured for a single Target or group of Targets (Tags). At the same time, individual Users in an organization may require a different level of access for the Role they have been assigned, but the rest of a team may not.
You need to plan how your organization will manage your access by using any of these methods:
For example, you could start with a Compliance Department where their roles only allow View permissions. Then, using User level permissions on Tags and Targets, you could expand to add the HR Department to View and Manage HR data. This would allow users and their supervisors to access their own data and shared files, but it would not be shared across all the HR users. Gradually, you add each area of your organization, based on Roles, until you have added all your employees that need access to SDP.
It's important to remember that:
-
Roles and Users are where you know the person or their role and you are looking for specific things (Tags/Targets) to manage.
-
Tags and Targets are where you know the things (Tags/Targets) and you are looking for specific people (role/user) to assign permissions to.
Role Based Access Controls Permissions
With Role based Access Controls, you assign permissions by Role for the level of access to scan result data or configuration to a target or tag. See Managing Roles for how to set up a Role. It is a best practice to set a few Roles at a time, access to a few tags and then expand it out based on your organizational needs.
For example:
1. User with the same expected level of access:
An IT Support team may need access to configure all policies across the organization, but does not need to be privy to all the sensitive information.
A compliance team may need access to masked sensitive information to allow for spot checking privacy policies are being followed.
A DSAR fulfillment team may need full access to unmasked data to accurately report on PII.
2. User that requires a different level of access for the Role they have been assigned:
The Privacy Officer may be in charge of the Compliance team, but need unmasked information as the highest escalation point where the remainder of the team would not.
The Engineering manager may be given the authority to alter policies, but only for test machines.
The organization's DBA may be individually given access to view unmasked results on every database used in the organization, regardless of department.
User Based Access Control Permissions
With User based Access Control permissions, you set for a User the level of access to scan result data or configuration to a target or tag. See Manage Users for how to set up a User. It is a best practice to set a few Users at a time, access to a few tags and then expand it out based on your organizational needs.
For example:
User Mary in the HR Department needs to have access to view and edit data only their local computer, and at the same time no other users except her supervisor can have access to her machine.
1. Mary is added to the system as a User.
2. Mary's laptop is created as an Asset in the Data Asset Inventory.
3. The Admin creates a Role, for example: Laptop User, and assigns Mary to this Role.
4. The Admin creates a Tag that modifies the permissions for that asset, which are limited to the owner of the Asset and their manager, and assigns it the Role.
5. The Admin sets up the agent on Mary's laptop and creates the Target that sets permission for User of Mary only to access this target.
Note: User permissions override any Role based permissions.
Permissions by Target
The user is to view or assign permissions for a user or role for the level of access to scan result data or configuration to a target. See Working with Data Assets and Targets for more information.
For example:
The Sales department wants to limit who has access to their customer information in their OneDrive files to only the Sales team members:
1. Create a new Target for the OneDrive location with the login credentials for the Cloud-based OneDrive.
2. Edit the permissions for the Target to assign access by User or Role (members of the Sales team).
Permissions by Tag
The user is to view or assign permissions for a user or role for the level of access to scan result data or configuration to a tag. See Tag Management for more information.
For example:
The Accounts department wants to mask customer credit card numbers except for the last four digits for certain Roles:
1. Create an organization Tag for Accounting Databases.
2. Modify the Tag by Roles:
a. Auditors have a masked view and can see only the last four digits of the data.
b. A lead auditor whose specific User is authorized to view unmasked data can view unmasked data.
c. Accountants have an unmasked view of the data.
d. All other Users cannot view any of the data.
Note: Targets and Tags can have the following properties:
• Hidden from a Role or User
• Configured with access credential for scanning/remediation or assigned policies by a Role or User.
• Sensitive data found on a Target can be masked for a Role or User
• Sensitive data found on a Target can be viewed by a Role or User