Table of Contents
  • Problem #1: Brittle Security Configuration
  • Problem #2: Prone to Mistakes
  • Problem #3: Single Point of Failure
  • Problem #4: Vulnerable to Side-Channel Attacks
  • Problem #5: Non-Compliance With GDPR
  • How Integrate.io Can Help Protect Your Sensitive Data

Introduction

Extracting your data from multiple sources and collecting it in a centralized data warehouse is hard enough—but how do you keep it safe once it arrives? Organizations use a variety of data security methods to protect sensitive and confidential information, including share-level security (all users sharing a password) and user-level security (with separate accounts and passwords for each user).

Row-level security is an evolution of user-level security in which the visibility of different database rows or records depends on the access level of individual users or user groups. For example, basic users may only have view-level access to certain records in a database based on their job function, while database administrators can view and edit all the records in the database. Major public cloud providers such as Google Cloud Platform, Amazon Web Services, and Microsoft Azure have all built row-level security into their offerings.

But is row-level security really the best way to keep your data protected? In this article, we’ll go over five reasons why row-level security may not fix your data warehouse security issues, and may even be putting you at greater risk.

1. Brittle Security Configuration

Row-level security may seem like a step up compared to alternatives such as user-level and share-level security—but it’s not without its downsides. As the size of your database continues to grow, trying to properly manage row-level security for all of your users and user groups will become an ever more time-consuming and error-prone process. In other words, row-level security is highly brittle: it’s not easily scalable as you collect more data or as the number of users increases.

2. Prone to Mistakes

Ideally, organizations should use a variety of data security techniques, giving them a “Plan B” (and “Plan C,” and “Plan D”) to fall back on if there's a breach of the initial protections. Unfortunately, row-level security does not offer this level of in-depth defense. If the database administrator makes even a single configuration mistake while setting up row-level security (or while editing configurations for new data), then sensitive data may be irrevocably exposed to an unauthorized user.

3. Single Point of Failure

Row-level security is also concerning because it potentially has only a single point of failure: the account of the data warehouse’s administrator, who has access to all the sensitive information inside the database. If an attacker were to gain access to the administrator’s account (say, via a breach in the account credentials) then there would be no recourse—the attacker could view and exfiltrate the entire data warehouse, before anything could be done to stop it.

4. Vulnerable to Side-Channel Attacks

In IT security, a “side-channel attack” is an attempted exploit of a computer system based on inadvertent leakage of supposedly irrelevant information. Even though it conceals direct exposure of information, row-level security may not be enough to protect against side-channel attacks by a clever attacker.

To analyze a table of employees’ salaries, for example, an attacker could run a query containing the expression “1/(salary-50000)”. If this query returns a “divide by zero” error, then the attacker knows that someone in the organization has a $50,000 salary (since “salary-50000” would be equal to 0).

5. Non-Compliance With GDPR

Last but not least, row-level security could run afoul of data privacy and security regulations such as the European Union’s General Data Protection Regulation (GDPR). Article 32 of the GDPR requires organizations to “implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk.”

In particular, the GDPR mentions data pseudonymization and encryption as potentially useful data security techniques. However, row-level security is neither pseudonymization nor encryption: it merely conceals data from unauthorized users, and is therefore vulnerable to malicious actors who gain access to users’ credentials.

How Integrate.io Can Help Protect Your Sensitive Data

In this article, we’ve gone over five reasons why row-level security could be a poor fit for your data warehouse security, and could even put you at greater risk. So given these security concerns, what’s the best alternative to row-level security?

Rather than keeping sensitive data unprotected in your data warehouse, you have two better options:

  1. Encrypt the data during the ETL (extract, transform, load) process.
  2. Filter out sensitive data during the data transformation stage, so that it never reaches the data warehouse.

In either case, you’ll need a powerful, feature-rich ETL tool like Integrate.io. Integrate.io is a cutting-edge ETL and data integration platform that helps anyone—regardless of technical skill—build data pipelines to their cloud data warehouse. Integrate.io includes more than 100 pre-built connectors and integrations and a rich array of data transformations, so that you can handle sensitive information in the way that best fits your organization’s needs.

Related Reading: Encrypt and Decrypt Sensitive Data with Integrate.io

Want to learn more about how Integrate.io can help protect your confidential data? Get in touch with our team of data experts today for a chat about your business needs and objectives, or to start your 14-day pilot of the Integrate.io platform.