Introducing Data Users Directory by Satori
Today, we here at Satori are announcing a new service, Data Users Directory. This new capability is aimed to help enterprises organize data users using a universal data access group, allowing them to decouple user management from database RBAC and permissions implementations. With this, organizations will receive a streamlined data entitlement process and effectively reduce the time spent by their data engineering teams on database RBAC implementations and ongoing maintenance. By mixing DB users, roles, and IdP groups together, it equates to obtaining simplified role management for databases and easily defining universal data access identities across all data stores.
Many companies that use role based access controls for data access find their native data store capabilities to be static, manual and limited, especially for companies that have a significant number of different roles. Because data analysts and data scientists frequently move between teams - modeling your data access needs using native DB access and permission models requires ongoing data engineering work, making managing roles at scale complex and cumbersome. The functionality gap lay in the fact that DB groups, roles, and permissions were designed for DB administrative tasks rather than for satisfying data stewardship requirements.
Using Satori’s Data Users Directory remediates such concerns, and is now available for anyone using Satori.
How to get started?
Within the Satori management console navigation menu, you will see on the left side of the screen, a new item labeled ‘Directory.’ Navigate to this tab and click on ‘start’ by adding a new Satori Group.
Next, you will be promoted to give the group a name and a description. Once you do this, you can start adding members by typing a member username, IDP, group, or role. You can filter the list of members by selecting the member type in the dropdown field on the right:
As you start searching and adding new members you’ll notice the list expands, you can add an unlimited number of members to each group. In addition, you can also add different member types to the same group, and even add other Satori groups as members to a new group.
Once you’re done, click save and your new group is ready to be used in the Satori analytics screen, where you can analyze the group members aggregated data, access behaviour, as well as in Satori’s data access policies so you can set a single, universal, policy for the entire group.
Why did we build this?
Simple put, and as described in this post about the complexity of scaling roles management, our customers are in pain - and since Satori has a comprehensive data user context, we can ease this pain by letting customers simply organize existing users and groups in a way that fit data access.
Satori groups are built for organizations that do not use an identity provider, in cases where the association of users to groups in the identity provider does not match how their data is actually accessed, and for organizations that have data engineering teams who don’t want to be dependent on external stakeholders such as IT Okta admins.
For example, let’s say that an organization has a data set for a project X which is being accessed by 3 different types of data consumers:
5 Software engineers who all are all assigned to an Okta group ProjectXEng
A python script that uses the username project_x_job
Several analysts using a BI tool that uses the username project_x_b
To enforce the same data access policy on all these users, and to easily produce a report on the data access of these users, create the following Project X Satori group:
Organizations can enforce policies on Satori groups in the same way policies are being enforced on users or identity provider groups: by using the identity.directory.group tag.
For instance, the following policy will alert on access to PII data by members of the Satori Group Project X:
- name: "Project X PII alert" action: alert identity_tags: - identity.directory.group::<Project X group ID> data_tags: - c12n.pii priority: 1
As we build the future data engineering platform with a goal of simplifying data governance tasks, we are focused on continuing to add capabilities that streamline the data access and entitlements process. Now that we have the Data Users Directory to simplify how identities are organized, our next objective is to implement those same principles to help companies organize database tables and locations. Stay tuned!