Data Access Security
Sisense enables you to define data security rules that control which users can access which portions of the raw data in a data model, at row granularity.
Example:
Each widget only shows the data permitted by the data security rules that apply, including totals, averages and so on.
The data browsers used while building dashboards and widgets only show the data permitted by the data security rules that apply.
You can define a single dashboard that automatically displays different results for each user (or user group), based on the rows which that user is permitted to see.
Example Use Cases:
- A Sales Order table has a column representing the salesperson that closed a deal.
- You created a quarterly performance dashboard for your salespeople, but want each of them to see only their own data.
- You do not want any of them to be exposed to data that represents the performance of others.
Watch this video about data security:
How Data Access Security Works
The Sisense security model is designed to work as both a 'Grant access' model and a 'Deny access' model. When applying a data security rule, you determine whether access is blocked for everyone or open to everyone.
Note:
Assigning no value to Everyone is the same as blocking everyone.
The best practice is to leave 'Everyone else' set to 'Nothing', while granting groups and users access to specific data values. The model accumulates grants, meaning that the most restrictive combination wins. So if both a group and one of its members have conflicting rules, the more restrictive combination wins.
Example:
| Rule 1 | Rule 2 | Result |
|---|---|---|
| Everything | Nothing | Nothing |
| Allow 1 | Nothing | Nothing |
| Everything | Block 1 | Everything except 1 |
| Allow 1, 2 | Block 1 | 2 |
| Allow 1 | Block 1 | Nothing |
| User Rule | Group Rule | Default Rule | Result |
|---|---|---|---|
| Y | Y |
Y |
The more restrictive of the user and group rules |
| Y |
Y |
Group rule | |
| Y |
Y |
User rule | |
|
Y |
Default rule |
Each data model contains tables and each table contains fields.
A data security rule defines that a specific user can only see any data of an entire row of a table, if a specific field in that row has a specific value(s).
Example:
In a Sales widget, a salesperson (for example, Dan) will only see the sales amounts from the rows of a Sales model whose Salesperson field contains the value Dan (rows 1 and 4).
Sales Table
| # | Salesperson | Product | Amount |
|---|---|---|---|
| 1 | Dan | HD-TV | $100 |
| 2 | Matthew | TV | $300 |
| 3 | Amber | Media Center | $700 |
| 4 | Dan | Player | $200 |
| 5 | Matthew | Air Conditioner | $600 |
Dan will not see any part of a row in the data model that does not contain the value Dan in the Salesperson field, nor will any amounts from this row be included in totals.
If a widget that shows the amount spent per product is shared with Dan, then he will only see HD-TV and Player and the sales total will be $300.
Note:
The entire row of data is not seen by the relevant user even when the field to which the rule applies does not appear in the widget.
Defining Data Access Security for a Data Model
In Sisense, all users who have access to your data models can see all of the data. If you define any data security rules, the default behavior is inclusionary, meaning that you define which values of a field a user is allowed to see.
Example:
You can allow each sales rep to see transactions for their own customers, and prevent sales reps from seeing the transactions of other customers. In this case, you define a row-based data security rule for each sales rep, based on the customer IDs of each customer.
In some cases, you might want to allow all of your users to see all of your data except for a few specific restricted rows. In this case, exclusionary rules are preferred.
Example:
Assume that your company has thousands of customers, and your policy is that all sales reps can see information for most of your customers, not only for their own customers. You might have certain customers whose data is sensitive and should only be accessed by certain authorized sales reps. In this case, it is easier to manage a definition that allows access to everything, except the few restricted customers, than to manage a list of the thousands of customers whose data is freely available to all sales reps.
To allow or restrict certain rows of data to a specific user or group of users, you can set the default data security behavior for each table and then define when the rule applies.
Note:
When multiple data security rules exist for a specific field-user or field-group combination, the "Inclusionary" rules will be combined with "OR" logic between them. "Exclusionary" rules will be combined with "AND" logic between them.
To change the data security behavior for a rule:
-
There are two ways to access the Data Security settings:
-
From the Data page, click the ElastiCube menu button (
) and, from the menu, select Data Security.
-
-
Click + Add field (or, if any fields already exist, + Add another field) to display a list of fields that you can apply data security rules to.
-
Select the field you want to apply data security to. The field is added to the page. By default, the field is fully restricted so no one can see any values.
Note:
Sisense supports up to 1450 values in the result set of a specific dimension (column and table). In some cases, up to 3500 values may be supported. If the number of Values built based on your rules exceeds 3500, and possibly even exceeding 1450, try a different approach. For example, instead of excluded values, try including them in your rule or create multiple rules.
-
Click Scope limitations to set the scope of your rules. The following options are displayed:
-
Always apply this rule: Select this option to always apply your rule. This option limits the number of results that are returned for a Viewer because applying your rule forces joins between related tables.
-
Apply only on queries including this table: Select this option if you want to restrict the application of data security rules only to cases where the table containing the data security field is directly included in the query. This is useful when you have a specific table whose values you must secure, but you do not want to secure related tables.
-
Apply this rule when any of the following tables are included in the query: Select this option if you want to restrict the application of a data security rule only to cases where at least one table from a group of tables are directly included in the query. This is useful when you have a list of tables whose data should be secured, but the rest of the tables do not include sensitive data.
-
Exclude this rule when all the tables in the query are from the following list: Select this option if you want to restrict the application of a data security rule and exclude cases where columns from any one of a specific group of tables are directly included in the query to prevent it being applied in cases that are irrelevant. This is useful if you have a list of tables whose data doesn't need to be secured, as long as they aren't combined with restricted tables.
-
-
Click Save.
-
Click + Add User / Group to define who is affected by the rule. By default, everyone is affected.
-
Under Values, click
to open a list of values you can apply rules to and set access rights to that value. Multiple values can be selected. -
Set the access rights for the value you selected. There are two options:
-
Allow Access: The selected users / user groups can see this data no matter what the value is in this field.
-
Block Access: The selected users / user groups cannot see this data no matter what the value is in this field.
After you have set the access rights, the rule is applied to your data.
-
How Does Data Level Security Work for Tables with Relationships?
Sisense protects your data across relationships. This allows you to define your data security rules in a single field, and ensures your data is protected across your model, whenever it relates to your data security rules.
As described above, each widget only shows any data of an entire row of a table, if a specific field in that row has a specific value.
A widget may further restrict the data shown to a specific user when a rule is defined for a table that has a relationship to a table that has a field in the widget.
This means that a widget only shows the data permitted by the combined data security rules assigned to all the tables that have any field in the widget.
As described above, the entire data row is restricted even when the field to which the rule applies doesn't appear in the widget. The entire row of data is also restricted even when the field of the relationship between the two tables doesn't appear in the widget.
Use Case - Expanding Upon the Example Above
- The Sales table has a column that has a relationship with a Deal Contacts table that holds the contacts that were involved in each deal.
- You created a Deal Contacts widget for your salespersons.
- As described in the example above, the Sales table has a data security rule that maps each user to their matching field value, so that each sales person only sees their own data.
- Even though the Deal Contacts table doesn't have any data security rules defined for it, the Deal Contacts widget only enables each sales person to see the contacts associated with their own sales, because of the data security rule assigned to the Sales table.
Configurable Filter Security Parameters
There are additional configuration parameters that dictate how data security is applied to the filter values displayed to the dashboard users.
The toggles for these parameters are located in Admin Tab > Server & Hardware > System Management > Configuration > 5 clicks on Sisense logo on System Configuration page > Base Configuration > Security.
When a dashboard designer creates a dashboard, their filter selections are part of the dashboard. These filter security parameters define whether the filter selections (of the dashboard designer) should be checked before they are displayed to a dashboard user - based on the data security rules that impact the user. If the dashboard user should not be able to see some of the filter values, those values will be removed before the filters are displayed.
Scope:
-
security.applyDataSecurityOnFilters - The data security rules are checked for the tables that are used directly by the dashboard.
-
security.applyDataSecurityOnFiltersRelations - All of the data security rules defined for the dashboard’s datasource are checked. (This option has a much bigger impact on performance.)
Once the filters have been displayed, widget query performance is not affected by the use (or not) of these parameters.
Note:
Both of these parameters are toggled on by default and both of them impact performance. These parameters should be toggled off if their related functionality is not required.
