Satori selected as a representative vendor in the Gartner Market Guide for Data Security Platforms 🥳

Access Control,


Zero Trust For Data Access: Why Is It So Important?

|Chief Scientist

The term “Zero Trust” has been used for security, especially network security, over the last two decades. However, it wasn’t until 2018 when NIST published “Implementing a Zero Trust Architecture,” that the zero trust model gained significant popularity across organizations.

In this post, we’ll take a look at why Zero Trust Architecture is especially important when dealing with data access.

What is the Zero Trust Model?

The zero trust model requires users to be continuously authenticated, authorized, and validated for access to applications and data. The continuous validation of users’ access and application of security policies is important, as users and assets are not “perimeterized”.

As an example, with the move to a hybrid and distributed workforce logging on from home and office locations around the world, users are commonly not accessing data from a specific network segment. In addition, as more applications and data are SaaS or otherwise not part of a specific company perimeter, a different model is needed – zero trust.

Zero trust is based on applying policies in a continuous way when users are accessing data and applications. In this article, we will focus on zero trust data access aspects.

Get the latest from Satori

Why Is Data Access Special?

There are a lot of reasons why data access is crucial both in terms of value and risk. In essence, since most companies have sensitive data within their databases, data warehouses, and data lakes, it is imperative that access is controlled and secured. 

In addition, because in many cases there is an increase in the amount of data users in companies (in what’s referred to as data democratization), this is both an opportunity (in terms of generating more business value), as well as an additional risk (in terms of less control over who accesses the sensitive data).

How the Zero Trust Model is Applied On Data Access

One of the functional components of the zero trust architecture, according to NIST is data security, or more specifically from NIST’s “Implementing a Zero Access Architecture”:

“The data security component includes all the data access policies and rules that an enterprise develops to secure its information, and the means to protect data at rest and in transit.”

What does this mean? It means that an enterprise should have clear and deterministic data security and data access policies (which is also one of the principles of DataSecOps). Such policies should ensure that data is stored, processed, accessed, used and shared in a secure way.

There is no single strategy of designing such security policies for the organization, as different companies have different goals, priorities, and are at different maturity levels in their data accessibility journey. For example, some organizations’ strategies are to enforce “need to know”, while others are moving to a “need to share” state of mind. Regardless of the organizational strategy, according to the zero trust principle, the organization must continuously validate that users can access the data – in terms of authentication, authorization and validation. Let’s explore access along each of these dimensions in more detail.


Authentication means verifying the identity of the user accessing data. Authentication can be done in many different ways, such as with database credentials, using key-pair authentication, or through a SSO (Single-Sign On) with an IdP (Identity Provider).

Let’s take the case of employees who need to access production data. A non-ideal yet common practical solution is for them to either have constant access to the data or to have one user sign in from which many users access the production data. Instead, an optimal solution according to a zero trust model is to provide temporary access to the data as the need arises.


Authorization means verifying, once authenticated, what data a user can access. Authorization is a major challenge, especially at scale. On one hand, the more data you authorize, the more security risk you assume. On the other hand, you want users to actually have access to all the data they require.

In an ideal situation, the data access platform should be agile enough to “breathe” with the needs of the data consumers. This means that users are able to:

  1. know about the different datasets they can use
  2. easily request access to the data
  3. gain access, to the data as quickly as possible, if this is in-line with the organization’s data access policy
  4. exhale once the data is no longer in use; revoke the access


Validations on data access should ensure that no excess risk is assumed, and that data is used in the way it’s intended. Examples of this type of validation are applying anonymization policies such as data masking policies, data localization, and more.

Another aspect is applying the organization’s data security policies continuously on all data access, and across all data platforms.

In addition, data access should be audited & monitored accordingly.

Zero Trust for Data Access With Satori

Satori is a core component for applying the zero trust model on data access. Satori enables the organization to set clear security and access control policies that are continuously applied on all data access to databases, data warehouses and data lakes.

Satori provides just-in-time authentication and authorization to data, as well as validation anonymization by using different policies such as data masking, row-level security and ABAC.

Go here to learn more, or book a meeting with one of our data security experts.

Learn More About Satori
in a Live Demo
Book A Demo
About the author
|Chief Scientist

Ben is an experienced tech leader and book author with a background in endpoint security, analytics, and application & data security. Ben filled roles such as the CTO of Cynet, and Director of Threat Research at Imperva. Ben is the Chief Scientist for Satori, the DataSecOps platform.

Back to Blog