The Satori Security Policy is a re-usable object that can be configured to contain multiple sets of dynamic masking configurations and data filtering configurations. A Security Policy can be applied to one or more datasets.
Satori's security policy engine is designed to protect an organization's data by authorizing specific individuals or groups of individuals to view data. The main objective of a security policy is to protect an organization's business interests.
The Satori security policy mechanism achieves this by implementing dynamic masking and data filtering on specific tables, columns, rows and fields within a dataset. Satori's security policies can be applied to one or more datasets.
The Satori security policy provides two configurable mechanisms for protecting an organization's data:
Dynamic Masking - The dynamic masking mechanism of the security policy is used to obfuscate sensitive or confidential data such as credit card information, social security numbers, names, addresses and phone numbers from unintended exposure and to reduce the risk of data breaches.
Data Filtering - The data filter is designed to restrict the records returned from queries based on the authorization context of the user. The Satori data filtering mechanism automatically rewrites the queries based on the filter and mapping configuration that are configured in the policy.
Dynamic Masking and Data Filtering Made Easy
A Satori security policy can be created in just a few minutes. The policy can then be implemented and reused on a single dataset or multiple datasets.
Security Policies are displayed as tiles, each security policy tile displays which datasets are implementing the security policy as well as the number of active users and the amount of queries over the past 7 days.
Creating a Security Policy
To create a security policy you need to have either administrator or editor permissions. Ensure that you have added the relevant users and groups to the "User Directory". Make sure that you have prepared the required masking profiles in the "Masking Profiles" view.
The Main Configuration Tasks
Select the "Security Policies" view from the navigation menu in Satori.
Click on the plus button and name the new security policy.
Assign the security policy to the relevant dataset
Assign the (preconfigured) users and groups to the dataset.
Apply a "masking profile" to a dynamic masking rule of a security policy.
Configure the dynamic masking and the data filtering rules for the new security policy.
Assigning the Security Policy to a Dataset
Once you have created the security policy, it is now time to assign it to a dataset which you access from the "Datasets" view.
The are two configuration tasks required for assigning a security policy to a dataset, they are as follows:
1 - Configuring the Access Rules
The first task is to add and configure a new "Access Rule" to the dataset and then select an enforcement rule for the new user or group. There three types of security policy enforcement:
A - Default Security Policies - represents the fallback security policy
B - The Following Security Policies - Enables you to add multiple security policies to a single dataset
C - No Security Policies - No security policy assigned to the dataset as the default policy
Assigning a security policy to a dataset is a simple task achieved by performing the following:
Step 1 - Click the "Datasets" view and then select the relevant dataset.
Step 2 - Click the "Access Rules" tab and click the "Add" button and then complete the "Grant Access Rule" by selecting the relevant drop menu configuration options.
Step 3 - Ensure to select the relevant enforcement option which defines what type of policy enforcement you wish to apply to the dataset.
Step 4 - Make sure that the "Access to this dataset is controlled by Satori" toggle switch is "turned on".
Note: Satori automatically sets the dataset security policy to the "Default Security Policies" option.
2 - Assigning the Default Security Policy to a Dataset
Now that you have created and defined your dataset, you must assign it a default security policy. To assign the "default" security policy click the "Security Policies" tab and select the default security policy from the drop menu.
3 - Enforcing a Security Policy on a User or a Group
Once you have assigned the default security policy to the data store return to the access rules tab and add a new access rule to your dataset. This is the default security policy that you assign to the dataset.
To assign the default security policy to a new user or group for the dataset perform the following tasks:
- Select the Access Rule tab.
- Click the Add button.
- Select the relevant user or group from the available options.
- Select user or groups access level.
- Set the expiration date.
- Enter the revoke access timeframe.
- Enforce the "default security policy" option.
Setting Up Dynamic Masking
Satori provides you with the ability to perform real-time data masking of sensitive or regulated data. Dynamic masking changes the data stream so that the data requester does not get access to the sensitive data, while no physical changes to the original production data take place.
Step 1 Click the "Start" button
Step 2 Select the user and the relationship type from the available options
Step 3 Select or enter either an individual user or group
Step 4 Now select a predefined masking profile from the available list options.
NOTE: Select a pre-configured masking profile from the masking profile templates provided by Satori out-of-the-box, or create and configure a masking profile customized to your specific organizational requirements.
Satori masking profiles and Pre-configured masking templates are located in the "Masking Profiles" view of the application.
Setting Up Data Filtering
Satori filters data to users by implementing row-level access controls. When a data filtering policy is enforced, Satori intercepts the query before it is sent to the database and then rewrites the query and adds the necessary filters.
Take, for example a
CUSTOMERS table with a
REGION column, where only the US team members can access the rows of the
US region and only the EU team members can access the rows of the
EU region. When a US team member sends the following query:
SELECT * FROM CUSTOMERS
Satori then rewrites the query as follows:
SELECT * FROM CUSTOMERS WHERE REGION IN ('US')
Note: If you select the Advanced YAML Editor option you can not switch back to the "Standard Filter Builder" option. If you wish to use the standard filter builder after selecting the advanced filter builder the YAML snippet will be lost.
Data filtering is defined by specifying the data store locations that you wish to filter by. For each 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 provides two methods to configure data filtering policies:
- 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.
Standard Data Filter Builder
The standard data filter builder enables you to select the data store fields you want to filter by.
Repeat the following steps for each field:
Step 1 - First, select the relevant data store and field location.
Step 2 - Then, select the values filter. An empty values filter is created by default. You can add one or more conditions to specify which values each user or group will be allowed to view.
The same filter can be used in more than one data store location:
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.
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:
You can create more complex filter by nesting
or mappings as required. Use the JSON-path syntax to filter by semi-structure 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 Masking Rules and Data Filters
You can rename the rules 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.