Skip to content

Satori Directory

The Satori Directory enables Satori administrators to define user groups in Satori, based on existing users, identity provider groups, data store groups and more. These groups can then be used to set policies or analyze data access. Satori groups are useful for organizations that do not use an identity provider, or in cases where the association of users to groups in the identity provider does not fit how data is accessed.

For example, an organization has a data set for a project which is being accessed by:

  • Several software engineers, all of them are assigned to an Okta group ProjectXEngineers
  • A python script that uses the username project_x_billing_job
  • Several analysts using a BI tool that uses the username project_x_bi

To enforce the same policy on all these users, and to be able to easily produce a report on the data access of these users, create a Satori group named Project X and add the following members:

  • Okta group ProjectXEngineers
  • project_x_bi and project_x_billing_job usernames

Groups hierarchy

To enable organizations to model a hierarchy of groups, Satori groups can be added as members of other Satori groups, under these constraints:

  1. A maximum of 10 levels
  2. A group cannot be added as a member of itself, indirectly (loops)

Creating Satori groups

To create a Satori group go to the Directory page in the navigation menu. Select Add and provide a name for the group. A group can contain the following members:

  • Usernames - any user that is used to access a data store
  • Identity provider groups - Okta, AzureAD or others
  • Snowflake roles
  • Other Satori groups

Define policies using Satori Groups

Organizations can enforce policies on Satori groups in the same way policies are enforced on users or identity provider groups, by using the tag. For example, the following policy will alert on access to PII data by members of the Project X team:

- name: "Project X PII"
  action: alert
    - c12n.pii
  priority: 1