In many cases, it is necessary to create security limitations that protect data sets from unauthorized users. For example, an organization with multiple departments (sales and support) using a shared table. Specific columns may contain data that should not be exposed to one of the teams, and thus, there is a need to limit access to these columns based on the users’ identity.
In these cases, different databases provide solutions that allow security measures to protect and segment data according to a predefined set of permissions that are then implemented on certain levels of the data.
In column-level security, certain policies are applied to utilize direct column encryption, redaction, or hashing, transforming the results returned to the user. Column-level security may be applied by dynamically masking data before it is served to the data consumer. The data store itself can do this (for example: by Snowflake or Redshift), at the BI tool level (for example: in Looker or Tableau), or by a security platform de-coupled from the data platforms (for example: by Satori).
Column-Level Security vs. Row-Level Security
Column-level security is not the same as row-level security, a similar procedure used to protect and apply fine-grained permissions to the information stored in specific rows of a table.
Column-level security plays well with row-level security. For example, we can combine column-level security to restrict columns returned based on the different teams accessing it. At the same time, we can enforce row-level security to restrict the results per the region of the requesting user. This way, we can have a master table holding all the data we filter upon serving without creating multiple copies of the data.
