Recently I was talking with a data leader about access control and they described it as the dementor of their day, referring to Harry Potter’s dementors, who suck all the happiness from around them, or as Professor Lupin puts it:
“Dementors are among the foulest creatures that walk this earth. They infest the darkest, filthiest places, they glory in decay and despair, they drain peace, hope and happiness out of the air around them. Even Muggles feel their presence, though they can’t see them.”
Today, I’m going to drill down into access control and explain some of the reasons why it’s viewed as a dementor.
Why Data Engineers Don’t Like Access Control
Data engineers don’t like creating access control. We have assembled some of the most common reasons why access control makes them unhappy, or more specifically what bothers them when dealing with access requests to data.
Access requests are in many cases yet another unplanned task. Data engineers have many competing tasks and when these unplanned ticket requests arrive, the engineers have to pause their prescribed, interesting, and valuable work, to address them. This disrupts their workflow and can slow down the valuable work that they provide to the organization.
No Clear Ownership Or Process
There is no clear process or in some cases even data ownership. While this may be the result of poor data governance, if no one is accountable for the data, and there are no clear guidelines or procedures for granting access, then the data engineer may be left feeling that granting access could expose a security risk. Further, they themselves may be solely responsible for this security breach.
More Than Just Granting Access
In many cases, access requests entail more than simply adding access to a dataset. In order to provide access, the engineer may need to anonymize the data, which is very simple from the business perspective but is difficult to apply within the data infrastructure. In some cases, access has to be given across multiple systems, regions, and technologies (for example, AWS Redshift and Snowflake). In these cases, the engineer must determine whether different security requirements apply in different regions and apply the appropriate access controls.
Or in some cases, they need to locate the data and apply access controls across different technologies. This will require the data engineer to separately access the data and then provide the appropriate control within each technology.
In other words, a simple request for data access turns into a complicated, time consuming process for the data engineer.
Becomes Messy Over Time
In many cases, sometimes to overcome some of the hardships mentioned above, access control becomes messy. These hurdles can take the form of role explosion, complicated role hierarchy designs, custom views, and functions to enable differential access such as dynamic data masking or row-level security.
This means that there’s often either a spaghetti-code view or a system that is hard to comprehend. The data engineer then does not clearly understand how a change in role or user access will affect the organization and security of the data.
Becomes More Risky Over Time
In many cases, since authorizing users for data access is difficult and becoming harder and messier, data engineers opt to give broad permissions, or simply not to remove access when no longer needed. This creates a security risk in the long run and is a burden that the data engineers carry with them.
There is a Patronus Charm
Just like the Patronus Charm is the best defense against a dementor, Satori is the best defense for access control. Satori helps you streamline access control in your organization with tools like self-service data access (including Slack integration), and access control across all your databases, data warehouses and data lakes from a single location. Importantly, this does not require data engineering resources when giving access, and can be managed by the data owners themselves.
Learn more about our access control management here, or book a meeting with one of our experts.