Data security in Sisense can be divided into two types, data encryption and data access. Data communication is related to how data is secured by Sisense while being imported into Sisense and written on your server’s disk.
When data is imported into Sisense or when you connect directly to a data source, the protocol used depends on the protocols supported by the data source. Sisense supports importing data over SSL, if the source supports it. Sisense supports SSL for data retrieval, for example, when viewing data in dashboards.
Configuration data, such as account credentials and authorization profiles, are encrypted prior to being written to the disk. The encryption technology used by Sisense includes:
For data at rest, Sisense supports OS based disk encryption, Windows file system encryption. For more information, click here.
The second type of data security is data access. This type of data security refers to who can access your data after it is imported into Sisense and displayed in a dashboard.
What is 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, down to row granularity. For 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 that user is permitted to see.
Use Case Example
- 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.
How Does Data Access Security Work?
The Sisense security model is designed to work in a 'Grant access' model, and not in a 'Deny access' model.
By default, when applying a data security rule, access is blocked for everyone, and the best practice is to leave 'Everyone else' set to 'Nothing', while granting groups and users with access to specific data values. The model accumulates grants, meaning that the most permissive combination wins. So if both a group and one of its members have conflicting rules, the permissive combination wins.
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).
For 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).
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.Note: The entire row of data is not seen by the relevant user even when the field to which the ru
le applies does not appear in the widget.
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$.
Each Data Security Rule applies to a specific field in a data model and to specific user(s)/user group(s). It enables you to define the values that must be contained in a specific field to enable that entire row of data to be available to a user.
If you want to exclude or hide data from certain users, you can define these rules in the Sisense REST API. For more information, see Restricting Data Access for Data Models.
To access Data Security:
- Click Admin and select the Data Sources tab in the menu.
- For the relevant data model, click and select Data Security.
If no data security rules have yet been defined for this data model, then the following message is displayed:
- Click Add Field to display a list of the fields in this data model.
Note: Row-based data security rules may cause reduced performance when applied to floats.
- Select a field. For example, Brand. The following window is then displayed in which you can define rules.
Note: You cannot select date type fields.
The left side of this table enables you to define which users/user groups can access this data. Click + Add Restriction and start typing into the Restricted User/Groups field to get a drop-down list.
Add as many users/user groups as necessary.
The right side of this window enables you to define which values the specified users/user groups are permitted to see.
Start typing into the Values field to get a list.
Multiple values can be selected.
The value of numeric type fields must be typed into this field, as no auto-complete option appears for numeric type fields.
Alternatively, you can start typing in one of these values (in both text and numeric type fields):
- Everything: To specify that the selected users/user groups can see this data no matter what the value is in this field.
- Nothing: To specify that the selected users/user groups cannot see this data no matter what the value is in this field.
For example, you can define that the following Users/User Groups must have the following values in the Product Category column to enable them to see their data row in a widget.
This means that management can see the data of all Product Categories, Don can only see the data of Calculators and Camera Flashes, Bob can only see the data of Apple Mac Desktops, and Everyone else won’t see anything.
# User/User Group Product Category 1 Management Everything 2 Bob Apple Mac Desktops 3 Don Calculators, Camera Flashes 4 Everyone else Nothing
How Does Data Level Security Work for Tables with Relationships?
Tables in a data model may have a relationship between them.
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.
In addition, 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 does not appear in the widget. The entire row of data is also restricted even when the field of the relationship between the two tables does not appear in the widget.
Use Case Example – 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 does not 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.
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, which means you define what values of a field a user is allowed to see. For 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 may want to allow all of your users to see your data except for a specific user or group of users. In this case, exclusionary rules are preferred. For example, let’s 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 may have certain customers whose data is sensitive and should only be accessed by certain authorized Sales reps. In this case, it’s 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 restrict certain rows of data to a specific user or group of users, through the Sisense REST API, you can change the default data security behavior to exclusionary, which allows you to hide or restrict access to data to certain users.
You can combine inclusionary rules with exclusionary rules. In case the rules conflict, the exclusionary rules take precedence.
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:
- In Sisense, click Admin, and then Rest API.
- Select Version 0.9 on the top-right of the screen, select elasticubes, then POST /elasticubes/datasecurity, and click Test It Out.
- In the body of your call, update the value of “exclusionary” to true.
- Click Try it out and then Execute.