Data security
Data security involves filtering the data queried by ThoughtSpot from the data warehouse. It is the next layer of security after access control, which determines if a user can view or edit ThoughtSpot objects.
Data security in ThoughtSpot is divided into row-level and column-level security, of which row-level security is by far the most common.
Row-level security (RLS)🔗
Row Level Security (RLS) is the term for filtering down to rows of data based on a set of entitlements for a user.
ThoughtSpot has three mechanisms for row-level security:
-
RLS Rules applied to the ThoughtSpot table objects.
-
Attribute-Based Access Control (ABAC) with custom variables referenced in RLS rules passed in via login token.
-
Attribute-Based Access Control (ABAC) with filters parameters passed in via login token.
-
OAuth connections: Individualized login to the data warehouse connection using OAuth, where security rules have already been implemented for each user.
The OAuth workflow requires opening a new window or redirecting to the OAuth provider for the initial sign-in workflow, making it less seamless than using a service account and defining data security via ThoughtSpot. It tends to be used for non-embedded ThoughtSpot use cases or for embedded applications for an organization’s internal users with existing individual data warehouse user accounts.
Column-level security (CLS)🔗
CLS restricts user access to specific columns of a table. When CLS is applied, users see only the columns that they are allowed to view. Object owners can configure CLS by sharing a relevant set of columns in a table with a specific user or user group.
For more information on CLS, see Sharing tables and columns.
Column security rules (CSR) on Liveboards🔗
Starting with ThoughtSpot Cloud 26.10.0.cl, Liveboards that include columns restricted by Column Security Rules (CSR) open and work normally for users who cannot access those columns, including in embedded Liveboards. Previously, such Liveboards were blocked for these users. Column security remains fully enforced:
-
Filter chips from columns that the user cannot access are masked instead of blocking the Liveboard. Only one masked filter chip is shown, at the end of the filter bar, to indicate that one or more filters are inaccessible. For example, if five filters are inaccessible, the Liveboard still shows a single masked filter chip.
-
Scheduled Liveboard deliveries apply CSR separately for each recipient.
To control whether masked filter chips are visible in an embedded Liveboard, use the showMaskedFilterChip SDK property. For more information, see Masked filter chips.
For more information, see Column security rules on Liveboards.