Democratizing data access empowers executives, managers, and employees to make better analytics-based decisions. Yet opening data to every employee has profound implications for the company’s data security, privacy, and compliance.
Role-based access controls (RBACs) let people use the data they need while hiding everything else. RBAC keeps companies in compliance with security frameworks and privacy regulations without hindering growth-driving analytics initiatives.
Organizations can choose from many access management models, including attribute-based access control (ABAC), discretionary access control (DAC), and mandatory access control (MAC). However, RBAC strikes a balance between simplicity and security that increasingly matches the needs of modern, data-driven cultures.
Six components of RBAC
The RBAC model consists of three technical elements — roles, permissions, and users — implemented through three rules — role assignment, role authorization, and rule authorization.
RBAC structure
Role definitions, permission assignments, and user assignments determine the level of access people have to sensitive data. In addition, the RBAC structure can enforce business rules such as separation of duties. For example, finance department specialists and their managers can have roles that prohibit either employee from both generating and approving a payment.
1. Roles
A role is a set of tasks groups of employees commonly perform. An all employees role would include tasks like reading and writing emails. However, customer data requires more judicious policies that limit authorized end-user access.
2. Permissions
Each role consists of one or more permissions that grant access to a system or dataset. Fine-grained permissions can explicitly allow rights such as reading, changing, creating, or deleting records within a table or database.
3. Users
System processes or individual users are assigned to the roles appropriate to the tasks they perform. Once assigned, they automatically receive the relevant permissions.
RBAC rules
Three interlinked rules govern how the role, permission, and user structure enforce principles of least privilege.
4. Role assignment
Users can only exercise privilege when assigned to roles with those rights.
Access is denied by default. Users can exercise a privilege only through explicit assignment to a role with that privilege.
5. Role authorization
Users cannot join a role without authorization.
Governance processes will define how to authorize changes to a user’s roles. For example, a promotion can trigger automatic authorizations and deauthorizations of an employee’s roles.
6. Permission authorization
Assigning or changing permissions within a role requires authorization.
Best governance practices enforce accountability by tracking changes to the access control system.
Challenges of RBAC
RBAC’s structure and rules are deceptively simple. However, they generate complexity that makes role-based access control challenging.
Development and Implementation Challenges
Complex role patterns spread across organizational and regulatory boundaries make RBAC implementation in large organizations difficult. A protracted planning process must audit every job function and develop a logical set of roles that addresses every use case.
Inevitably, implementing RBAC uncovers edge cases that deny users critical data access. A phased approach will minimize operational risk at the cost of extended implementation timetables.
Lack of Scalability
Once in place, RBAC can become resistant to change. Modifying a role or its permissions can have unanticipated consequences for user access and data security.
Business leaders must accept that mergers and other organizational changes require additional time to evaluate their impacts on role-based controls.
Lack of Contextual Flexibility
As analysts move from project to project and executives take on new responsibilities, the business cannot wait for role changes to work their way through overly-bureaucratic authorization processes.
Role Proliferation and Maintenance Overhead
RBAC teams may create many narrowly-defined roles to address scalability and flexibility issues. This role proliferation increases complexity and maintenance overhead.
Additionally, role proliferation undermines security and compliance as users accumulate roles. Over-permissioned users become security risks as their credentials grant excessive access to sensitive information.
Risk of Role Misuse or Privilege Abuse
RBAC’s inconveniences can lead to inappropriate behaviors that misuse or abuse the system. For instance, teams may use dummy accounts with multiple permissions as workarounds for gaps in team members’ role assignments.
Misuse like this jeopardizes compliance by undermining control over sensitive or protected information.
Benefits of RBAC
Despite its challenges, RBAC provides a well-documented path to security, data protection, and compliance. Addressing its challenges ensures that these security benefits do not interfere with RBAC’s most important benefit — collaborative data usage.
Collaboration
Properly implementing least-privileged access through RBAC makes data more accessible. You can assign people to roles that grant all the access they need to collaborate and generate impactful business insights.
Within the analytics context, RBAC policies can grant some users secure access to sensitive data while limiting others to less sensitive data — all within the same table.
Fine-grained access control
RBAC policies within analytics platforms can control access at many levels, from platform features to schemas, tables, or columns. This granularity lets certain users work with sensitive data while limiting others to aggregated data with less risk.
Data security
Least-privileged access policies implemented through RBAC make data more secure by minimizing inappropriate data usage and unauthorized access.
RBAC limits the scope of external security breaches since a user’s compromised credentials will not give hackers unconstrained access to every system and dataset.
The same is true for risks from insider threats. Disgruntled workers only have access to data their roles permit. Gathering data beyond the scope of their roles is significantly harder.
Data privacy
Organizations that handle public data, such as healthcare providers or payment processors, are subject to data privacy protection regulations that impose severe penalties for data loss and inappropriate access.
RBAC lets regulated companies define roles and permissions based on data privacy policies. Need-to-know roles, assigned regionally, reduce the risk of privacy violations.
Auditing and compliance
RBAC systems track data access across the company and log changes to roles, permissions, and user assignments. Activity and change logs are essential to an effective governance program’s continuous compliance monitoring and auditing efforts.
Robust auditing capabilities streamline accreditations documenting the company’s compliance with security and privacy frameworks. After a security incident, these records will accelerate the resulting forensic investigations.
What is an example of RBAC access control?
Starburst’s data analytics platform unifies a company’s on-premises and cloud-hosted data sources. Analysts can use Starburst’s single point of access to combine data from legacy systems, data lakes, and third-party data sources into actionable business insights.
Starburst denies access to every data source by default. Users must first authenticate their identities, either through a Starburst password or an identity and access management (IAM) system. Even when authenticated, users cannot access data unless assigned to a role.
The Starburst access control system uses the following terms:
- Roles: A collection of business tasks that require certain access rights
- Entities: Objects that authorized users may access, including tables, queries, functions, data products, and UI components.
- Privileges: Rights to perform defined actions on an entity, including SELECT, ALTER, SHOW, and more.
- Users: An authenticated person or system process.
Within the Starburst system, a company’s human resources schema may include a “Kentucky staff” role that limits employee database access to certain fields for employees living in Kentucky.
This role will include privileges that allow, deny, or limit privileges for the employee database entity.
After authentication, an HR analyst will choose their Kentucky staff role to run a query. Starburst applies row filters to the query that only request records where the state field’s value is “KY”. Modifying the query before sendingit to the data source reduces performance and network overhead while ensuring the data source only returns authorized records.
Before sending the results table to the HR analyst, Starburst applies the column filters and masks specified in the Kentucky staff role.
Column masks substitute null values for personal information like a home address and phone number.
A column filter will only display the last four digits of each employee’s Social Security Number.
Other fields will be fully visible for the analyst to use.
How do you use RBAC?
Your administrators can quickly create or modify roles within the Starburst interface.
Create a role
In the Roles and Privileges section, a button click plus the role’s name and description are all it takes.
Add cluster use privilege
Authorize the role to run on the right cluster by choosing the Cluster entity type, the appropriate cluster name, and the “use cluster” checkbox.
Add entity privilege(s)
Select an entity kind and name, specify the applicable schema and tables, and choose the privileges to grant or deny.
Assign users
Drop-downs let admins quickly assign users to the role.
Create row filters, column masks, and column filters
Fine-grained controls let you limit access to the contents of tables and other entities. To add row filters to a role’s table access permissions, go to the Row Filters section of the main admin interface. Create an SQL-based filter which you can then specify within the role’s table privileges. A similar process applies to column masks and filters.
