Satori enables you to create data filters for users and or groups by implementing row-level access controls. Satori intercepts the query before it is sent to the database and then rewrites the query and adds the necessary filters.
Satori Data filtering is defined by specifying the data store locations that you wish to filter by. For each specified location the list of allowed values is based on the user querying the data.
You can associate multiple data store locations with the same filter. For example, when your dataset consists of several tables that need to be filtered the same way.
Satori Data Filter Builder Methods
Satori provides two methods to configure data filters:
The Standard Data Filter Builder - Use the standard data filter builder to create a simple filter comprised of a single field.
The Advanced Data Filter Builder - Use the advanced data filter builder to create a complex filter comprised of several fields with an AND/OR relationship.
Using the Standard Data Filter Builder
The standard data filter builder enables you to select the data store fields that you want to filter. To configure a data filter you must perform a series of steps. Repeat the steps for each field you wish to filter.
Setting the Location
First, select the relevant data store and field location.
Defining Multiple Locations - The same filter can be used in more than one data store location.
Defining the Filter
The Satori Data Filter Builder lets you create natural language conditions that consist of normal terms without using special syntax terminology or formatting.
An empty values filter is created by default. You can also add one or more conditions to specify which values each user or group will be allowed to view.
Adding Multiple If/Allow Condition to a Filter - By adding an additional If then Allow conditions to a data filter you can create intricate data filtering configurations in a couple of clicks.
Defining Multiple Filters - You can add multiple filters to your policy.
Using If, Allow and All Users to Define a Filter Condition
A filter contains sets of conditions that define how you filter your data values. A condition is comprised of two main building blocks, If and Allow.
The If Section - First you must define Who is going to be filtered, by constructing the first part of the condition If (the user/s), (is/is not) MIKE or, (is a member of/is not a member of) - GROUP A.
The Allow Section - Once you have defined who is being filtered now you must define which values the user or group can see or not see by selecting one of the allow options in the Filter Builder. Finally, you can define what All Users can view.
When you create a filter condition you can allow the defined user/s or group/s to view data values according to the following condition options:
Filter Example 1
The following data filter example shows that MIKE is Allowed to see city text values Sydney, New York and London and all other users are not allowed to view any text values by default.
If you need to create a condition that includes a user and or a group to view specific data while excluding either a user or a group from viewing the same data value then you must create a multiple line "If and Allow" Condition rule.
Filter Example 2
The following example shows, if the user is a member of the ACME VIP Customer Success team, they can view all text values that include the VIP map values and if the user is a member of the ACME Customer Success team they can view the text values that include SILVER, GOLD and PLATINUM map values. Finally, all the users are not allowed to view any values by default.
Using the Advanced Data Filter Builder
In the advanced data filter builder, you write a YAML snippet that describes the boolean expression of your filter using the Advanced YAML Editor. Each field in the YAML snippet can be associated with a filter.
To access the Advance Data Filter click the button on the right side of the User Field Value input field.
Writing a YAML Condition
CUSTOMERS table from the previous example. If you want to filter the CUSTOMERS table by the
CUSTOMER_TIER column for an EU team member who is also a member of the VIP Customer Success team, the following query should be generated:
SELECT * FROM CUSTOMERS WHERE REGION IN ('US') AND CUSTOMER_TIER IN ('VIP')
The YAML snippet would appear as follows.
The filters section would contain two filters:
Using a JSON Path Syntax
You can create more complex filter by nesting
or mappings as required. Use the JSON-path syntax to filter by semi-structured datastore locations.
and: - or: - and: - field: name: c1 path: $.a['b'] filterName: abc - field: name: c2 filterName: with space - and: - field: name: c3 filterName: abc - field: name: c4 path: $.a.b filterName: xyz - or: - field: name: lala filterName: abc - field: name: lala path: $.a.b filterName: abc - field: name: d3 path: $.a['b'] filterName: abc
Renaming your Location Selectors and Data Filters
You can rename the locations and filters that you create with meaningful custom names or in accordance with your company naming policies.
- Simply, place you mouse cursor over the name and click in the input field of your newly created rule of filter and rename it.
- Then, click in blank space to save the new masking rule or filter name.
IMPORTANT: If you decide to change the name of your rule, ensure that you reselect the updated "User Filter Value" drop menu item that appears in the "Location Selectors" filter section.
SQL MERGE in AWS Redshift
Data Filtering will not work when copying data from a source table to a target table using MERGE in AWS Redshift, because AWS Redshift only supports specifying a source table and not a subquery. To prevent users from executing MERGE in AWS Redshift using Satori, set the Baseline Security Policy to Block Query when recognizing unsupported queries and objects.