Access control and data security
ThoughtSpot supports the following features to control user access to ThoughtSpot objects and application data.
-
User groups with system privileges
-
Sharing visibility
-
Object-level permissions
-
Row-level security (RLS) and column-level security (CLS) for data security
-
Granular access to buttons and menu actions in the embedded app (applicable to embedded ThoughtSpot instances)
User groups and system privileges🔗
Along with user authentication for application access, ThoughtSpot provides an additional layer of authorization and access control through user groups and system privileges.
System privileges determine the workflows and actions that users can perform within the ThoughtSpot application context.
ThoughtSpot allows you to define several types of privileges for a given user group:
-
Role-specific privileges for administrators, developers, and other user personas.
-
Data-related privileges to allow or prevent access to upload, download, or manage data.
-
Workflow-specific privileges to enable or disable access to features such as SpotIQ analysis, scheduling Liveboards, or the experimental features available for evaluation and early adoption.
-
Sharing privilege to control a user’s or group’s visibility in the Share dialog.
For more information about system privileges, see Understand groups and privileges.
Sharing visibility🔗
The Sharing visibility configuration allows users and groups to be set as SHAREABLE or NOT SHAREABLE.
For example, if UserA is marked as SHAREABLE, other users can view UserA in the Share dialog when they try to share an object.
Similarly, if a user group is set as NOT SHAREABLE, it does not appear in the Share dialog when a user tries to share an object.
|
Note
|
Avoid using the same group for sharing permissions and other privileges. Because a user can share with anyone in a group they belong to, they can potentially share restricted data. |
Object-level permissions🔗
ThoughtSpot users can share objects such as Liveboards, answers, tables, worksheets, and table columns. Users can set either read-only or edit permissions at the individual object level when sharing an object with another user or a user group. A user can automatically share objects with anyone else in the groups to which they belong.
When an object is shared, users can view all the data regardless of the permissions set at the parent object level. For example, a user can view a shared Liveboard without having access to its underlying Worksheet or table from which the visualizations in the Liveboard are built.
|
Note
|
If your application instance has classic Answer Experience enabled, administrators can restrict user access to Liveboards by selecting the Cannot create or update Liveboards checkbox in the admin UI. Note that this feature is deprecated on clusters on which the New Answer Experience is enabled. ThoughtSpot recommends that you use the |
Data access control with RLS and CLS🔗
When a user shares an object with a user group, all users in that group can view data. You can override this behavior by applying RLS and CLS controls.
- Row-level Security
-
Using Row Level Security (RLS), you can restrict access to sensitive data and filter tables to show only relevant data for the signed-in user.
RLS rules are defined on table objects, and automatically extend to all worksheets, saved answers, and Liveboards based on that table, every time.
RLS rules are defined using either the ts_username variable or ts_groups variable. The RLS rules translate into WHERE clauses in any SQL query generated from that table object, with the variables expanding into the details of the signed-in user. ts_groups turns into the set of group name properties of the ThoughtSpot groups the user belongs to.
A common RLS rule type pattern for a multi-tenanted data warehouse involves each user belonging to a ThoughtSpot group names to match the values in a 'customer name' or 'tenant name' column on every table. Alternatively, username can be used if the data is stored at an individual rather than tenant level.
RLS rules on one table object can reference other tables objects that are joined within a given connection. This allows for more a more complex RLS pattern to be used, where an "access control list" or "entitlements" table (ACL table) exists in the database, with a JOIN in ThoughtSpot to the fact or dimension tables.
The RLS rule is defined on the fact or dimension table, but will reference the ACL table, typically by comparing ts_username variable against a column in the ACL table, which filters the ACL table’s rows to only those defined for the user. The JOIN defined between the ACL table and the other tables then reduces down the rows to only those that match the remaining rows in the ACL table.
In the ACL table pattern, the embedding web application must define a process for updating the ACL table in the data warehouse with the correct entitlement rows for each user. This is a separate process that does not involve ThoughtSpot, although it can be combined with the authenticator service used for Trusted Authentication.
A comprehensive examples and best practices guide to RLS data model setup is available on the ThoughtSpot Community.
- Column-level security
-
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, see Sharing tables and columns.
Granular access to menu actions🔗
If you are using Visual Embed SDK to embed ThoughtSpot objects and you want to restrict user access to certain menu actions, you can use the visibleActions, disabledActions or hiddenActions attributes. For more information, see Show or hide UI actions.