Jump to Content
Security & Identity

Safer by default: Automate access control with Sensitive Data Protection and conditional IAM

September 12, 2024
Scott Ellis

Senior Product Manager

Jordanna Chord

Senior Staff Software Engineer

Join us at Google Cloud Next

Early bird pricing available now through Feb 14th.

Register

The first step towards protecting sensitive data begins with knowing where it exists. Continuous data monitoring can help you stay one step ahead of data security risks and set proper access controls to ensure data is used for the right reasons while minimizing unnecessary friction. 

Google Cloud’s Sensitive Data Protection can automatically discover sensitive data assets and attach tags to your data assets based on sensitivity. Using IAM conditions, you can grant or deny access to data based on the presence or absence of a sensitivity level tag key or tag value.

This feature can help you:

  • Automate access control across various supported resources based on attributes and classifications of the data in those resources. Automation helps you keep up with the growth and changes in the data in your organization, folders, and projects.

  • Restrict access to the supported resources like Cloud Storage, BigQuery and CloudSQL until those resources are profiled and classified by Sensitive Data Protection. This practice is in accordance with the secure by default principle.

  • Change access to a resource automatically as the data sensitivity level for that resource changes.

Automated discovery and conditional access 

Sensitive Data Protection can look for evidence of sensitive data such as personally identifiable information, secrets, medical information, financial documents, and more. Discovery uses this technology to continuously monitor your data footprint looking for new assets and critical changes in existing assets that might increase or decrease risk to your business.  

Along with continuous monitoring, you can enable automated actions so that you can remediate issues as they arise and ensure that your data insights are deeply integrated downstream to power security workflows like data security posture management and enrich SecOps findings. With Sensitive Data Protection and Security Command Center, you can get vulnerability and posture alerts when sensitive data is exposed publicly or when credentials or passwords are found in storage systems.

https://storage.googleapis.com/gweb-cloudblog-publish/images/1_-_Dashboard_with_Map.max-1500x1500.png

Image showing geo map and results from a discovery scan of sensitive data

You can help prevent issues by leveraging conditional IAM allow and deny policies along with a new Discovery action to automatically tag your assets based on their sensitivity. 

With IAM Conditions, you can choose to grant or deny access to principles based on the presence of a tag or the value of a tag. This allows you to ensure that access is only granted when the right tag attributes are present for that user or principal accessing. With deny policies, you can proactively deny access based on a tag attribute.  

This enables safer default scenarios such as:

  • You have highly sensitive data and want to ensure that certain principals are denied access to that across your project or org.

  • You have a lot of new data entering your platform and want to allow access only once it’s been scanned and tagged appropriately. 

Safer by default, automated

With Sensitive Data Protection’s automated data tagging and IAM conditional access, you can help automate proper access control.

Consider the following example: Your data team creates new BigQuery tables throughout the week. These tables are moved and shared across a handful of projects and datasets. You want to keep business momentum by sharing these tables automatically with the broader team, but are concerned that some of these assets may contain highly sensitive customer data like personally identifiable information (PII) or moderately sensitive data like demographic information. Those two categories of data should only be seen by a select set of roles on the team, while nonsensitive data can be shared with the whole team. 

Step 1 - Create IAM Tags

First, create a set of tags to represent these three categories:

Level 1 : Low Sensitivity (no PII)
Level 2 : Moderate Sensitivity (names and demographic details)
Level 3 : High Sensitivity (unique or sensitive identifiers)

https://storage.googleapis.com/gweb-cloudblog-publish/images/2-_Creating_Tags.max-1500x1500.png

Image showing Tags create indicating three levels of data sensitivity

Step 2 - Enable IAM Conditional Access

Grant access to your data team with the condition that data has been automatically tagged as “Level 1” or “Low” sensitivity data.

https://storage.googleapis.com/gweb-cloudblog-publish/images/3-_Creating_IAM_Condition.max-1500x1500.png

Image showing an IAM condition based on a tag

Access to tables that are not tagged appropriately will now be blocked. 

Step 3 - Enable action for “Automated Tags”

Enable the “Tag resources” action in your Sensitive Data Protection discovery scan configuration and map the Sensitivity Level to the appropriate tag in your organization.

https://storage.googleapis.com/gweb-cloudblog-publish/images/4_-_Enabling_Auto_Tagging.max-700x700.png

Image showing the configuration of Sensitive Data Protection to automatically apply tags based on sensitivity level

Now, when a table is created, your team won't get access to it until it’s been automatically discovered, classified, and tagged by Sensitive Data Protection. For the higher sensitivity assets, you can ensure that only the right roles have access by adding the appropriate conditions to their IAM grants. 

Using IAM Deny

The examples above used conditional IAM grants to allow access based on the sensitivity. You may also have cases where you want to deny access based on the sensitivity. For example, consider an environment where access is granted to a partner to specific tables for different use cases. You want to ensure that this partner is not granted access to any highly sensitive data. For this, we’ll use an IAM deny policy

For this example, we’ll assume that you’ve followed all the steps above. Now you want to create a deny policy for the partner group account called partner@example.org. 

To do this, you can use the Google Cloud CLI (gcloud) or IAM API to deploy a policy to your project or organization.  The following example will deny access to BigQuery tables based on the presence of the tag value for high sensitivity data (Level 3).

Loading...

When this partner account tries to access a highly sensitive table, their access will be blocked:

https://storage.googleapis.com/gweb-cloudblog-publish/images/5_-_Access_Denied.max-700x700.jpg

Next steps

To get started on automating sensitive data discovery and conditional access control, see the following:

Posted in