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 3500 values in the result set of a specific dimension (column and table). If the number of Values built based on your rules exceeds 3500, 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 behaves on filters and filter relationships. These flags are located in Configuration Manager > 5 clicks > Base Configuration > Security.
For the following parameters, toggle them on for evaluation to first occur, and only then the filter members are shown. By default, both parameters are toggled on.
- security.applyDataSecurityOnFilters
- security.applyDataSecurityOnFiltersRelations
The following is the behavior of these flags:
applyDataSecurityOnFilters
- If the dashboard contains any type of filter based on columns which have data security rules, the filters are not shown until after Data Security is calculated.
- Evaluates the entire table from which the column is used as a filter.
applyDataSecurityOnFiltersRelations
- If the dashboard contains filters on a datasource with ANY data security rule, the filters are not shown until after Data Security is calculated.
- Performs calculations to see what effective members the user should have access to.
- Can cause longer compute times.
- It is necessary for some customer types to enable. Some customer types who do not need to calculate the net effective filter members can toggle this off.
