Get hands-on experience with 20+ free Google Cloud products and $300 in free credit for new customers.

BQ: secured dataset with sensitive info

Hello,

I would like to have a dataset in BQ which only specific users/groups can access. The issue here is that I don't want inherited access to work on this dataset. Is there a way to achieve that?

To add more context: Some groups already have access to this project, so by inheritance they have access to all the datasets. I need a secured dataset where I would like to keep sensitive data and only a few users should  have access to that.

0 3 1,136
3 REPLIES 3

Yes, you can achieve a high level of control and prevent unwanted inherited access in BigQuery by using a combination of IAM roles and permissions, along with column-level access control. Here's how you can do it:

  1. Using IAM Roles and Permissions:

    • Grant Specific Roles: Assign specific roles like bigquery.dataViewer or bigquery.dataEditor to users or groups for the dataset you want to secure. These roles should be granted directly at the dataset level, ensuring that only the intended users have access.
    • Avoid Inherited Roles: In BigQuery, access control is additive, meaning you grant roles to allow access. There is no direct "Deny" functionality for roles at the dataset level. To prevent unwanted access, you should not grant broader project-level roles that would include access to this dataset. Manage access strictly at the dataset level.
  2. Implementing Column-Level Access Control (CLAC):

    • Tag Sensitive Columns: Use policy tags to identify sensitive columns in your dataset. You can create these tags in the Data Catalog and apply them to specific columns in your BigQuery tables.
    • Set Access Policies on Tags: Define IAM policies for each policy tag. This allows you to specify which users or groups can access data in columns associated with each tag, providing granular control over who can view or query sensitive data.

Additional Tips:

  • Service Accounts: For automated processes, use service accounts. For human access, individual user accounts are recommended for better audit trails and security compliance.
  • Regular Monitoring: Continuously monitor and audit dataset permissions and access patterns to ensure that only authorized users have access.
  • Use Views for Masking: Create views that mask or redact sensitive information. This allows you to provide limited access to a subset of the data, which is particularly useful when users need to query the data without seeing sensitive information.

By carefully managing IAM roles and permissions at the dataset level and utilizing column-level access control with policy tags, you can create a secure environment in BigQuery. This approach ensures that sensitive data is accessible only to specific users or groups, effectively preventing unwanted access due to inherited permissions. Remember, regular audits and monitoring are key to maintaining this security over time.

Google Cloud uses IAM for security.  When you create a BigQuery dataset, that dataset is owned by a project.  You can grant permissions to users/groups at the dataset level and that would allow those users to access the dataset and tables contained within.  If you have granted BigQuery permissions at the project level (for the project which owns the dataset) then YES ... inheritance will be honored and EVERYONE that was granted BigQuery permissions at the project level will ALSO have permissions at the dataset level.  The resolution is to contemplate the thinking behind granting access at the project level.  Instead, consider granting access to users at the dataset level and remove permissions at the project level.  While this appears to be more work ... lets contemplate what you have currently said ... "I have users that I want to be give permissions to ALL datasets owned by this project and have hence granted them permissions at the project level ... however now I have a dataset that is also owned by this project and I don't want to grant permissions to those users that I previously gave permissions".  Another solution would be to create a separate project and create your dataset in that project and don't give project level permissions to anyone (in that project).

Cant we use Deny Policy here?