|
1 | 1 | --- |
2 | 2 | title: [Data and object security] |
3 | 3 | keywords: "data,security,row level security,privileges" |
4 | | -tags: [rls] |
5 | | -last_updated: tbd |
6 | | -summary: "Understand how to secure your data and other key information in ThoughtSpot." |
| 4 | +tags: [rls,cls,security] |
| 5 | +last_updated: 08/13/2019 |
7 | 6 | sidebar: mydoc_sidebar |
8 | 7 | permalink: /:collection/:path.html |
9 | 8 | --- |
10 | | -ThoughtSpot provides these features for protecting data security: |
11 | | - |
12 | | -* Object security |
13 | | -* Row level security |
14 | | -* Column level security |
15 | | -* System privileges |
| 9 | +ThoughtSpot provides many features for protecting data. |
16 | 10 |
|
17 | 11 | ## Object Security |
18 | 12 |
|
19 | | -Object security is the ability for users to see content within ThoughtSpot. |
20 | | -Objects can be tables, columns in tables, worksheets, pinboards, and saved |
21 | | -answers. |
| 13 | +Object security controls what content users see within ThoughtSpot. |
| 14 | +Objects are tables, columns in tables, worksheets, pinboards, and saved answers. |
22 | 15 |
|
23 | | -Users gain access to objects when an object owner share-answers with them. |
| 16 | +Users gain access to objects when an object owner shares access with them. |
24 | 17 | Owners can share with individual users or with entire groups, giving access to |
25 | | -anyone within that group. Owners can share with edit or view options. |
| 18 | +everyone within that group. Objects may be shared with edit or view-only options. A user can automatically share objects |
| 19 | +with anyone else in the groups to which they belong. This has implications on setting up privileges, and on applying row-level security. |
| 20 | + |
| 21 | +### Permissive Security Mode ### |
| 22 | + |
| 23 | +The default Permissive Security mode of ThoughtSpot means that when someone shares an object with you, you can see all the data it uses, regardless of explicit permissions to the parent object data. You can see a shared pinboard without having access to its underlying worksheet or table. |
| 24 | + |
| 25 | +### Advanced Security Mode ### |
26 | 26 |
|
27 | | -Currently, you cannot restrict someone who has had content shared with them from |
28 | | -sharing with others. Also, a user who belongs in a group can automatically share |
29 | | -with anyone else in the group. This has implications on setting up privileges |
30 | | -and applying row level security. |
| 27 | +ThoughtSpot's Advanced Security mode is opposite of the default permissive mode. Unless the user has explicit permissions to the entire stack of parent objects, they cannot see the data in the child object. For example, in a shared pinboard, you can see data only if you have explicit permissions to the relevant columns of the parent worksheet. Similarly, you can only see the data in a worksheet to which you have access if you have explicit permissions to its parent table object. |
31 | 28 |
|
| 29 | +Work with your ThoughtSpot support team to enable the Advanced Security Mode on the relevant clusters. |
32 | 30 |
|
33 | 31 | ## Row level security (RLS) |
34 | 32 |
|
35 | 33 | Row level security controls what data a user can see in each shared piece of |
36 | | -content. Even if a user has access to a worksheet, for example, they can only |
37 | | -see rows from the tables they have been given permission to see. |
| 34 | +content. Even if a user has access to a worksheet, they can only |
| 35 | +see rows from the tables they have permission to see. |
38 | 36 |
|
39 | | -RLS is applied at the table level and automatically applied every time. Also, in |
| 37 | +RLS applies at the table level, so it automatically extends to all worksheets, saved answers, and pinboards based on that table, every time. Also, in |
40 | 38 | queries where there are tables with table filters, all joins are always |
41 | | -enforced, to avoid accidentally allowing users access to data they shouldn’t |
42 | | -see. RLS requires three things: |
| 39 | +enforced to avoid accidentally allowing users access to data they shouldn’t |
| 40 | +see. |
| 41 | + |
| 42 | +RLS requires three things: |
43 | 43 |
|
44 | 44 | * A table filter with a column (possibly in a joined table) that can be used to |
45 | | -determine who can see a row, for example, account id or tenant id. |
| 45 | +determine who can see a row, such as account id or tenant id. |
46 | 46 |
|
47 | 47 | * A group that can be associated with the row of data by name. For example, if the |
48 | 48 | column is `account_id` and has values of `1`, `2`, `3`, users can be assigned to groups |
49 | 49 | `group_1`, `group_2`, `group_3` and then only see their data. |
50 | 50 |
|
51 | | -* Users must be assigned to the given group. If they are not assigned to a group |
| 51 | +* Users must be assigned to the group. If they are not assigned to a group |
52 | 52 | that has access, they do not see any data. |
53 | 53 |
|
54 | | -Administrative users can always see all rows of data since RLS is not applied |
55 | | -for these users. |
| 54 | +Administrative users can always see all rows of data because RLS does not apply to them. |
56 | 55 |
|
57 | | -RLS supports a hierarchy of groups allowing you to give access to some users |
58 | | -across multiple groups. |
| 56 | +RLS supports a hierarchy of groups, which makes it possible to grant access to some users across multiple groups. |
59 | 57 |
|
60 | | -Keep in mind that users within a group can share with one another group. This |
61 | | -means that putting everyone into a company group for RLS means they can share |
62 | | -with anyone in the company. |
| 58 | +Keep in mind that users within a group can share with one another. If you put everyone in your organization into the same group for RLS, they can share with anyone in the company. |
63 | 59 |
|
64 | 60 | ## Column level security (CLS) |
65 | 61 |
|
66 | | -Column level security means only allowing users to see certain columns in a |
67 | | -table. This can be accomplished by only sharing certain columns with groups of |
68 | | -users from a table. |
69 | | - |
70 | | -However, most of the time users are given access to worksheets instead of |
71 | | -columns. There is currently no way to only share certain worksheet columns with |
72 | | -certain groups. If you need this capability, you must create different |
73 | | -worksheets with the columns you want. |
74 | | - |
75 | | -Also, note that because someone can share with anyone in a group they belong to, |
76 | | -that means they could potentially share restricted columns. For example, assume |
77 | | -that HR has a column with salary information in a worksheet that only HR has |
78 | | -access to. An HR person could create an answer with the salary information and |
79 | | -share with someone outside of HR. That person would now have access to the |
80 | | -salary information. |
| 62 | +Column level security lets users see certain columns in a |
| 63 | +table, but not other columns. This can be accomplished by sharing a limited set of columns in a table with specific users or groups. |
| 64 | + |
| 65 | +Because someone can share with anyone in the same group, |
| 66 | +they can potentially share restricted columns. For example, if a _Human Resources_ repository has a column with salary information, and it appears in a worksheet, any _Human Resources_ group member could create an answer with visible salary information and |
| 67 | +mistakenly share with someone outside of _Human Resources_. That 'outside' person now has access to the salary information. In such cases, we recommend that you work with your ThoughtSpot support team to enable the Advanced Security Mode on the relevant clusters. |
| 68 | + |
81 | 69 |
|
82 | 70 | ## System privileges |
83 | 71 |
|
|
0 commit comments