Enforcing Least Privilege and SoDs in a Multi-Cloud environment

Risk Controller on Black Control Console with Blue Backlight

Enterprises are modernizing data platforms and embracing a multi-cloud strategy to drive their Digital Transformation (DX) initiatives by moving to platforms like Snowflake, Redshift, and Databricks. As we have discussed in previous blog posts, this paradigm shift has crucial implications for their Data Security Governance framework.

Specifically, it makes it harder to determine and enforce when users have overly granted access permissions, and more importantly, when those permissions create conflicts of interest from a security and governance standpoint. We of course know these two from their respective industry names – The Principle of Least Privilege and Separation of Duties.

Principle of Least Privilege

The Principle of Least Privilege states that an individual should have only the minimum data access privileges necessary to perform a specific job or task. For instance, a data engineer who has to build a data pipeline for customer experience data should be granted “Read-Only” access to the raw data and should not have Update / Delete privileges.

A common scenario that creates numerous violations of this principle is when enterprises are bootstrapping their cloud data platforms. During this period, engineers are frequently granted full privileges to reduce the initial friction of getting data migrated and consumed. These privileges don’t get revoked when the organization reaches a steady state, and can lead to data exfiltration risks. Apart from human users, a similar problem is prevalent with system users. Granting access to third party Cloud solutions is an easy way to build data integrations, for example granting access to data in AWS S3 to a Cloud Data Warehouse enables easy consumption of data. But if the privileges granted to the third party are not restrictive enough, it can lead to data exfiltration.

Similarly, in a machine learning system, scientists require access to a lot of historical data that can include  PII data during the training phase. Many of the data science operations do not need access to data that can uniquely identify a user. Following the Principle of Least Privilege this data should be masked or tokenized before Data Scientists access it . Furthermore, once the model is trained, Data Scientists do not need access to this data and should be revoked access.

Separation of Duties

Separation of Duties is an important security principle designed to prevent fraud and inappropriate usage of enterprise IT resources and data. The main idea is that no one person should have conflicting privileges that, when used together, could allow malfeasance to take place.  Segregation of these responsibilities provides a system of checks and balances that helps to reduce the risk of system misuse. 

In any data platform, a person responsible specifically for security administration, defining policies on data, and managing database security processes should not be the same person who creates new data sets. Similarly in a machine learning system, consumers of the inferences of a machine learning model should not be the users who are responsible for training and building that model. Or in an investment bank a person who oversees building predictive reports should not have privileges for manipulating the training and test data.

Multi Cloud Security Challenges

Staying true to these principles is challenging enough in an on-prem environment, but that challenge is compounded when this data moves in and out of multiple clouds and multiple data platforms. This is because while it’s hard enough to apply these concepts when the data is all in one repository, it is extremely difficult to rationalize dataset access across multiple platforms. 

Users who don't have access to a certain data set in one platform should not have access to the same data through another platform. If a particular user or role shouldn’t have access to a particular dataset in a source repository, that control should flow through to that same data that gets moved to an Enterprise Data Lake in Amazon S3 or a Cloud Data Warehouse in Snowflake.


New call-to-action


How TrustLogix helps

TrustLogix is a Data Security Governance platform that discovers data access patterns and analyzes access management policies across multiple clouds. We gather this data non-intrusively and business can continue to operate smoothly while we assess the security posture of your current cloud data operating environment.

(Read more about our Agentless, Proxyless Architecture here!)

Recommendation Engine

TrustLogix provides recommendations by analyzing the permissions granted to users and comparing them with those users’ actual access patterns to baseline the usage behavior and provide recommendations on right sizing access policies to align with a Least Privilege access model. This is a continuous process as new data and access policies are created. 

Dynamic Access Control policies

Trustlogix can enforce Separation of Duties in real-time. Our platform continuously assesses the conditions under which data access requests are being made. Our patent pending risk-based authorization model dynamically blocks access to data by analyzing sensitive role assignments and prevents access before risky actions are performed. 

This video shows how TrustLogix dynamically enforces SoD policies:




Protecting and securing data in a modern architecture that spans multiple cloud data platforms requires following multiple best practices including the Principle of Least Privilege and Separation of Duties.

Organizations should approach data security with a new perspective by building an architecture that allows improved visibility into data activities and data access permissions. They need to be able to identify potential blind spots and block access to data before those blind spots lead to data exfiltration or compliance violations.

The comparison of privileges granted to those used at the data and level of granularity provide an overview of any over-privileges present at the data level. Similarly, proactively blocking access to data if there is SoD violation helps enterprises to be compliant.


Financial Services Case Study