Fully managed in the cloudStarburst GalaxySelf-managed anywhereStarburst Enterprise
- Start Free
Fully managed in the cloud
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.
Published July 24, 2023
Role-based access control is a system of fine-grained access privileges granted to authorized users to perform a defined set of tasks. Unlike access control lists (ACLs) or user-based permissions, the RBAC model can create highly refined permissions that enable democratized data access with less overhead or security risk.
By denying access by default and limiting access to what users need for their work, RBAC systems can apply the principle of least privilege within a framework of zero trust.
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.
The RBAC model consists of three technical elements — roles, permissions, and users — implemented through three rules — role assignment, role authorization, and rule authorization.
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.
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.
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.
System processes or individual users are assigned to the roles appropriate to the tasks they perform. Once assigned, they automatically receive the relevant permissions.
Three interlinked rules govern how the role, permission, and user structure enforce principles of least privilege.
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.
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.
Assigning or changing permissions within a role requires authorization.
Best governance practices enforce accountability by tracking changes to the access control system.
RBAC’s structure and rules are deceptively simple. However, they generate complexity that makes role-based access control challenging.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
Your administrators can quickly create or modify roles within the Starburst interface.
In the Roles and Privileges section, a button click plus the role’s name and description are all it takes.
Authorize the role to run on the right cluster by choosing the Cluster entity type, the appropriate cluster name, and the “use cluster” checkbox.
Select an entity kind and name, specify the applicable schema and tables, and choose the privileges to grant or deny.
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.
Up to $500 in usage credits included
Up to $500 in usage credits included