If you are managing access to data, especially sensitive customer data at scale, your job isn’t easy. In most cases, you’re probably using a combination of a ticketing system, where users request access data and you then run the required approval flow, and a manual process to implement those new permissions in each database system.
That sounds like a good idea at first, but as the organization starts to scale, with more employees and a decent-size data infrastructure this process can become a bottleneck. The actual cost of such an approach under permissive assumptions is huge. Let’s do a quick back-of-the-envelope exercise.
ACME corp has 1,000 employees who access data. Let’s assume each employee submits on average one access request per month. The time it takes to implement the request takes approximately 15 minutes, not including the time spent on reviewing, discussing and approving the request. The math works out to the following:
1,000 employees x 1 request per month x 12 months = 12,000 requests per year
12,000 requests x 15 minutes per request = 3,000 hours per year
3,000 hours per year / 8 hours per working day = 375 working days
A typical year has 260 working days, so we are looking at the equivalent of 1.5 full time (FTE) engineers just to manage access to data. If we include the time spent removing the access, which can take even longer than granting it, we get to 3-4 FTEs to manage access to data. That’s an entire engineering team who could be focused on delivering value to the business instead!
No wonder a lot of organizations we talk to say that one of their top goals is to reduce the overhead that security and compliance incur on the DevOps and Data Engineering teams.
To get to a meaningful reduction in the time spent on managing access to data, a few fundamental things need to change:
- Automate the database administration work – granting and revoking permissions on databases is not the best use of your engineering team’s time, and it’s also error prone, leading to more risk and time spent debugging permissions issues.
- Eliminate repetition – most access requests are typically similar to each other. By defining a playbook of when to approve access automatically you can save a lot of time.
A high priority customer support ticket is a good enough reason to auto-approve access to a production database for the on-call software engineer.
- Grant temporary access or leverage activity information to understand what permissions can be removed – just granting permissions without revoking them, leads to an enormous risk of that excess access being used as part of a data breach.
Either make all permissions temporary with a manual or automatic process that removes them, or leverage database audit logs to understand what permissions are no longer needed.
The sad truth is that unless you’re Google, with infinite resources to throw at reducing the effort spent on managing access to data, you’re more likely to maintain the status quo and keep on using your current manual processes.
Introducing Access Manager
That’s why the new Access Manager feature in the Satori data security platform is such a big deal. It’s a solution for admins and users to manage access to data that doesn’t scale with the number of users or datasets you have to manage. With Access Manager, admins can:
- Define datasets that can range in scope from one table to include several databases, and determine who should approve access to these datasets.
- Specify groups of end users and the permissions they should receive to access the data, including expiration and automatic revocation settings.
- Understand if users are using the access they were granted, what permissions can be revoked and the overall data access governance posture of the organization.
How does it work?
Access Manager combines all the settings for datasets, access controls and security policies that exist in the Satori management console into a single view, and adds a layer of analytics on top, based on the audit logs captured by the Satori Data Access Controller.
This new and combined approach lets you view and manage all access rules across all datasets and understand which access rules are used and which are not.
Satori provides a new metric called Governed Traffic which is the percentage of queries in your data environment executed with permissions granted by a dataset access rule, vs. queries that were just audited by the Satori Data Access Controller.
The higher the percentage of Governed Traffic, the more control you have over access to data. Satori also tracks Governed Traffic over time to let you know if you’re trending in the right.
You gain better control and visibility over access rules, especially those with no expiration or automatic revocation. Selecting an access rule you can now assess if it is being used, by looking at the number of users and queries that it granted access to recently. Using this information you can determine whether to continue with the access rule as is, modify or revoke the access rule.
Ease of use
Lastly, creating new datasets and access rules is much easier and can be done from a single location. This feature makes it significantly easier to view the different access rules and datasets to which they are applied. You can now view all access rules at once, without having to go back and forth between different views.
Improving the end user experience
We’re not stopping at just the admins. As part of the Access Manager release your users now have more flexibility in how they gain access to data.
Previously, the Data Portal only enabled users to choose a specific permission level, i.e. Read Only, Read Write and Full, which was limiting because if users needed access with a different set of permissions or policies they had to manually write a text message and admins had to then deal with the custom request.
Now, users can choose from any of the predefined access rules made available to them by the admin. For example, a software engineer can gain access to masked data with automatic approval (self-service access), and can then make a separate request to access unmasked data so they can debug an urgent production issue, with that request going directly to the data owner for approval.
We have a few more improvements we’re working on to make end users’ lives easier, including a command line interface (CLI) to get credentials to a data store, a new access request form to allow users to request access to data that has not yet been defined as a dataset and more.
If you’d like to learn more about Satori, book a demo with one of our experts, or if you’re an existing customer, reach out to your Satori account team to learn more about these new capabilities.