Controlling access to data has always been one of the basics of cybersecurity hygiene. Managing this access has evolved from basic access control lists, to an entire Identity and Access Management industry. IAM controls are great at managing access to applications, infrastructure and on-prem data. But cloud data is a trickier issue. Data in the cloud changes environments and is frequently copied, moved, and edited.
This is where data access tools share the same weakness- what happens when the data moves? (Spoiler - the policy doesn’t follow).
The Different Access Management Models
There are 3 basic types of access controls enterprises use to control who can read and edit their data.
Access Control Lists: Basic lists of which users have read/write access.
Role Based Access Control (RBAC): The administrator defines access by what roles the user has - for example, anyone with the role ‘administrator’ is granted access.
Attribute Based Access Control (ABAC): The administrator defines which attributes a user must have to access an object - for example, only users with the job title ‘engineer’ and only those accessing the data from a certain location will be granted access. These policies are usually defined in XACML which stands for "eXtensible Access Control Markup Language’.
How Access Controls are Managed in the Cloud
The major public cloud providers include a number of access control features.
AWS for example, has long included clear instructions on managing access to consoles and S3 buckets. In RDS, users can tag and categorize resources and then build access policies based on those tags.
Similar controls exist in Azure: Azure RBAC allows owners and administrators to create RBAC roles and currently Azure ABAC is in preview mode, and will allow for fine grained access control in Azure environment.
Another aspect of access management in the cloud is ‘assumed roles’ in which a user is given access to a resource they aren’t usually permitted to access via a temporary key. This permission is meant to be temporary and permit cross account access as needed.
The Problem: Access Controls Don't Follow the Data
So what’s missing? When data access controls are put in place in the cloud, they’re tied to the data store or database that the controls were created for. Imagine the following scenario. An administrator knows that a specific S3 bucket has sensitive data in it. Being a responsible cloud admin, they set up RBAC or ABAC policies and ensure only the right users have permissions at the right times. So far so good.
But now someone comes along and needs some of the data in that bucket. Maybe just a few details from a CSV file. They copy/paste the data somewhere else in your AWS environment.
Now what happens to that RBAC or ABAC policy? It doesn’t apply to the copied data - not only does the data not have the proper access controls set, but even if you’re able to find the exposed sensitive data, it’s not clear where it came from, or how it’s meant to be protected.
How Sentra’s DSPM Ensures that Data Always Has the Proper Access Controls
What we need is a way for the access control policy to travel with the data throughout the public cloud. This is one of the most difficult problems that Data Security Posture Management (DSPM) was created to tackle.
DSPM is an approach to cloud security that focuses on finding and securing sensitive data, as opposed to the cloud infrastructure or applications. It accomplishes this by first discovering sensitive data (including shadow or abandoned data). DSPM classifies the data types using AI models and then determines whether the data has the proper security posture and how best to remediate if it doesn’t.
While data discovery and classification are important, they’re not actionable without understanding:
- Where the data came from
- Who originally had access to the data
- Who has access to the data now
The divide between what a user currently has access to vs what they should have access to, is referred to as the ‘authorization gap’.
Sentra’s DSPM solution is able to understand who has access to the data and close this gap through the following processes:
- Detecting unused privileges and adjusting for least privileged access based on user behavior: For example ,if a user has access to 10 data stores but only accesses 2 of them, Sentra will notice and suggest removing access from the other 8.
- Detecting user groups with excessive access to data. For example, if a user in the finance team has access to the developer environment, Sentra will raise a flag to remove the over privileged user.
- Detecting overprivileged similar data: For example, if sensitive data in production is only accessible by 2 users, but 85% of the data exists somewhere where more people have access, Sentra will alert the data owners to remediate.
Access control and authorization remains one of the most important ways of securing sensitive cloud data. A data centric security solution can help ensure that the right access controls always follow your cloud data.