In this blog, we will explore how Row Level Security (RLS) works in ThoughSpot, and offer a detailed guide on how to implement it effectively. With today’s world being very data-centered, companies need powerful security measures to control accessing sensitive information. RLS is a crucial feature that allows organizations to secure data at a granular level by ensuring that users can only view the data they are authorized to access.
What is Row-Based Security Within Thoughtspot?
In ThoughtSpot, Row-Based Security or Row-Level Security allows administrators to control access to a specific row of data in a table. It ensures that users can only see the data relevant to them based on criteria like departments, country, or role. This is crucial for maintaining data privacy and compliance, especially when dealing with sensitive or segmented data.
There are different ways to secure the data in ThoughtSpot:
Object-Level Security (OLS): OLS in ThoughtSpot manages permissions on objects such as worksheets, answers, and liveboards. It defines who can view, edit, or share these objects, allowing administrators to control user access at a high level.
Column Level Security (CLS): Column Level Security (CLS) restricts access to specific columns within a table. This will help to hide sensitive information, like salaries, SSNs, etc., from users who don’t have access to these fields.
Row-Level Security (RLS): Row-level security (RLS) filters the data so users only see relevant information.
What’s the Difference Between Row-Level and User-Level Security?
Row-level security controls data visibility at the row level, allowing users to see only specific rows based on defined filters in a dataset. It is applied to groups or roles, so anyone sees only the rows they can access. In contrast, User-Level Security provides personalized access to data based on individual user attributes, like a user’s location or job function. Each user sees a tailored subset of data, which can vary even within the same role, as access is restricted according to each user’s unique attributes.
What Are the Benefits of Row Level Security in ThoughtSpot?
Row-Based Security in ThoughtSpot Provides a flexible way to control data access at a granular level, making it ideal for companies needing segmented data visibility across teams or departments. Below are a few advantages of adding RLS to the data:
Data Privacy and Compliance: Ensures that sensitive data/information is accessible only to authorized users.
Improved Performance: Limits unnecessary data exposure and reduces the query load.
Customization: Provides tailored data access without duplicating tables or creating complex views.
How to Setup Row Level Security in Thoughtspot
To create an RLS, you should be granted the option of Can administer ThoughtSpot or Can Administer and Bypass RLS.
Define the Row Level Security Requirements: Understand the requirements and criteria for restricting data access.
Let’s create an RLS rule on the
DIMSALESTERRITORYtable. If you need more help and information on connecting to data sources, check out this blog. If we want territory managers to see only data relevant to their country, the restriction criteria could be based on theSALESTERRITORYCOUNTRYfield in the table.
-
Create User Attributes: Define user attributes corresponding to row-level restrictions criteria. These attributes link users to specific data segments.
-
Go to Admin Console and navigate to Groups from the Home screen.
-
Choose Add Group and create a group. The users in this group can only view sales records where the
SALESTERRITORYCOUNTRYis equal to “Australia.”
We will be using the
SALESTERRITORYCOUNTRYfield. With the above group created, it will return records of Australian members within that group.
Create Row Level Security rule: Open the
DIMSALESTERRITORYtable and select Row Security. Choose + Add row security to create the rule.
Let’s write the rule on the
SALESTERRITORYCOUNTRYfield. This will restrict the data to a particular region or country.
Test your RLS rule: Verify the rule is functioning correctly by logging in as a test user who is a group member created in step one.
Adding multiple RLS rules: You can also add multiple RLS rules to a single table to fulfill any needs based on the requirement. It is important to know that ThoughSpot will consider the rules as an
ORstatement, which means the users can view the data if either of the rules is passed.
Best Practices
To implement RLS effectively, define the access requirements and identify who needs access to data. Ensure you have the necessary admin permissions. Always align security filters with business needs, regularly audit user roles and access levels, and educate the business about RLS to maximize its value.
Closing
Following the above steps, we can successfully create the RLS inThoughtspot. Implementing RLS is a robust approach to securing data while offering personalized insights to users.
If you’re ready to enhance your organization’s data security or have questions about implementing RLS, contact our team of experts for tailored support and guidance.
FAQs
What are the common mistakes to avoid while implementing the RLS in ThoughtSpot?
When implementing RLS in ThoughtSpot, common mistakes to avoid are overusing complex filters that are hard to manage and failing to maintain accurate and up-to-date use attributes, which can leave security gaps unnoticed.
Another issue that could potentially expose data to unauthorized users is the incorrect mapping of filters to roles, groups, or tables.
Audit negligence and failing to update RLS configurations regularly can lead to outdated security settings that no longer align with organizational changes or user roles.
Addressing the above mistakes ensures secure and effective RLS implementations.
What is the difference between row-level, object-level, and column-level security?
Row-level security controls access to specific rows of data in a table based on user attributes or roles, ensuring users see only the data for which they are authorized.
Object Level Security: Restricts access to entire objects like tables, dashboards, or worksheets, determining whether a user can view or interact with them.
Column Level Security: Restricts access to specific columns within a table, allowing users to view only attributes they can see.
