Data Security

Applicable to Sisense on Microsoft Windows

To learn about data security in Linux, see Data Security.

When you share dashboards with your users, by default, they all have access to the dashboard and an see all of the data shown in the widgets. You can override this behavior by applying a type of filter that allows you to specify which data “rows” any given person signed in to the server can see in the view.

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. communication between Client web browser and Sisense servers, can be secured over HTTPS

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:

1. SHA-256

2. TripleDES

3. AES-256

For data at rest, Sisense supports OS based disk encryption, Windows file system encryption. For more information, click here. Sisense on Linux utilizes shared storage and supports storage options that are encrypted by default.

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, at row granularity. For example:

Use Case Example

How Does Data Access Security Work?

The Sisense security model is designed to work in both a 'Grant access' model and a 'Deny access' model. When applying a data security rule, you decide if access is blocked for everyone or open to everyone. 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 restrictive combination wins. So if both a group and one of its members have conflicting rules, the restrictive 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).

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.

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$.

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, 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 all of your data except for a few specific restricted rows. 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 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:

  1. In Sisense, open the Admin page and select Data Sources.
  2. Next to the relevant data source, click and select Data Security.
  3. Click + Add field to display a list of fields that you can apply data security rules to.
  4. 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.
  5. 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 will limit the number of results that are returned for a Viewer as applying your rule will force 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 does not need to be secured, as long as they are not combined with restricted tables.
  6. Click Save.
  7. Click + Add User / Group to define who is affected by the rule. By default, everyone is affected.
  8. 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.
  9. 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 you 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.

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