Why Row-Level Security Isn’t Enough to Protect Your Cloud Data Warehouse

Business and big data have become fast friends, with the reliance on this technological field netting big data around $57 billion every single year. Considering that data allows companies to make better decisions, increase customer engagement, and develop better products, it’s no wonder that many see this as a must-have aspect of modern business.

To store all this data, companies are moving away from on-site data structures and embracing cloud data storage solutions. These act as turnkey solutions to data storage, collecting, and formatting to ensure that companies are ready to better utilize the data that they produce. While cloud data warehouses have a huge range of benefits, they also come with debatable security features.

Often, businesses rely on one or two security systems to keep their data safe. Yet, one of these central technologies, row-level security, is currently leading to a huge number of data breaches. Considering that 60% of small businesses will go bust within six months after experiencing a data breach, this is something that you should be trying to prevent.

From losing precious data to exposing private files from your customers, a data breach always goes down terribly in the world of business. In this article, we’ll be pointing out some major flaws in row-level security, demonstrating the need for you to bring further security features to your cloud data warehouses.

While we’re at it, if you’re not sure which data warehouse to use, be sure to check out the comparison of Snowflake vs. Redshift, which puts their security features head to head. 

Let’s jump right into it!

What is row-level security?

Row-level security is a form of permission security enacted on individual users. Instead of creating structural defenses throughout the database, row-level security is a way of giving some users permission to see certain fields. You can either do this on an individual basis or select groups of users and give them a certain extent to which they can interact with the databases.

Within these systems, a user that doesn’t have access to a certain level of data will simply not be able to see the figures within that dataset, all the private data being obfuscated from their perspective. 

A database administrator account will be able to access all of the records, as well as change the permissions of different levels. From there, they’ll be able to construct permission layers, giving different account groups access to different data sets and pieces of information. 

Administrators can also change the formatting of the data, or edit the records within the data warehouse.

Why Row-Level Security Isn’t All It’s Made Out To Be

On paper, row-level security sounds like a fantastic system. By giving permissions to some users and not others, you’re able to let everyone access the database but only see the data that they need to get their work done. While that’s true, this security framework also comes with a range of loopholes and backend problems that can lead to data breaches.

We’ll discuss:

  • Target for Attacks
  • Disastrous Errors
  • Time Consuming Editing
  • Side Attacks

Let’s break these down.

Target for Attacks

The benefit of the administrator system is that this format makes it easy for a user to log onto the administrator account and make permissions edits whenever a new employee needs access to certain files or if an employee has received a promotion. If the password to this account is kept within upper management, many believe that this is a secure way of keeping their data warehouse safe.

However, while this central account does give high functionality when it comes to effectively managing the whole data warehouse permissions system, it also means there is a prime target for hackers to go for. Instead of having to search for a way in through a range of different means until they find a possible route of entry, hackers now know exactly what to look for.

Disregarding all else and focusing on obtaining access to the administrator account means that a hacker can concentrate their resources, brutally attempting to access the account. Once they get access to the administrator account, they’re then able to quickly use these advanced permissions to make a duplicate of the whole database and transfer it to a secure location for them.

In minutes, you can lose access to your whole system as the account with all the permissions begins to close out access points. Very rapidly, you can lose all the data in that system, leading to ransom situations. Having cost the world $20 billion in 2021, with this number expected to rise to over $250 billion by 2031, asking businesses for huge amounts of ransom is not an uncommon experience. 

When using row-level security, you’re making a very obvious target out of the administrator accounts, helping hackers to effectively take down your data warehouse system.

Errors can be disastrous 

Again, this flaw comes back to the power that administrator accounts have over the data stored in your warehouse. Part of the benefit of an administrator account is that they can format and configure the data within the pool, helping to construct it in useful ways for the employees that need it.

However, due to the sheer power these accounts have, if they accidentally configure something wrong, they instantly expose the whole system, creating huge errors that are blown way out of proportion. Without several levels of security, these accounts can make accidental changes that lead to disastrous consequences. 

What’s more, if any of the users that manage these accounts accidentally leave a weak point in the system, there is no fail-safe system to check their work before they publish the changes. This can lead to your attack surface having many more potential access points for a hacker to take advantage of than a system that has more than one layer of security. 

Time Consuming

Another problem with row-level security is that it is incredibly difficult to scale. While other security systems can be edited to cover more ground as a database expands in size, the same cannot be said for row-level security. On the contrary, row-level security needs editing every single time a new dataset is added.

Equally, if a new employee joins the company, permissions need to be set up for them, creating a lot of work for the system administrators. As the company increases the amount of data that it’s collecting and the number of employees it has, this creates a massive scalability issue that instantly hinders the possibility of successfully increasing the scope of the business.

Security is meant to be a flexible system that protects data without hindering it. While row-level security does protect, it is a hard system, creating problems when it comes to adapting any of the settings. This problem also feeds back into the previous one, with the sheer amount of times that a user will have to edit permissions also leading to a high probability of errors being made and the data being exposed.

Row-Level Security is weak to side attacks

Row-level security is more about hiding data than completely protecting it. Instead of creating an impenetrable system that no one can access, this form of data protection acts as a visibility barrier. While this stops a potential hacker from reading and editing the data, it does not protect them from expressing commands that could reflect what’s in a certain cell.

If a hacker wanted to know what was hidden in a cell, they could run a mathematical query to either confirm or deny their suspicions. With this trial and error method, hackers can actually build up quite a complete understanding of what is hidden in each data field, leading to the corruption of the security system without any alarm bells being set off.

Due to the inventiveness of side attacks, they’re notoriously difficult to defend against without just creating an impervious system. As effective as it can be in some situations, row-level security is far from comprehensive.

Final Thoughts

While row-level security does indeed have a range of different benefits, it has several major pitfalls, which make this one of the least favorable ways of securing a cloud data warehouse. If your business is currently using this system, we recommend that you discuss with your cloud warehouse provider and see if there are any other options available to you.

From there, you can begin the process of changing over your security to a more stable and comprehensive system. With this, you’ll always know that you’re keeping your company’s and customers’ data safe at all times.