Restricting Access to BigQuery, Storage and SQL

Cloud Storage (opens in a new tab) is a low-cost object store for many data types that can be reached from inside and outside Google Cloud and is replicated across locations for redundancy. Object protection for Cloud Storage uses two independent boundaries: Identity and Access Management (IAM) (opens in a new tab) for identity-based access and VPC Service Controls (opens in a new tab) for context-based perimeter defense. Together they keep sensitive objects confined even when an IAM grant is too permissive.

1.1Enforce Uniform Bucket-Level Access with IAM

Uniform bucket-level access in Cloud Storage means the IAM policy is the single authority for who can access buckets and objects. Identity and Access Management (IAM) defines who, such as a user, service account, group, or domain, has what access in the form of a role, for which resource. An IAM policy is attached to the resource and is checked on every access attempt, so a principal can upload or read data only with the appropriate permissions. Centralizing authorization in IAM removes divergent per-object controls, makes least-privilege reviews consistent, and lets tools such as Policy Analyzer verify who can read sensitive data or delete buckets.

1.2Apply IAM Conditions for Constrained Delegation

IAM Conditions are conditional statements added to an IAM policy that allow access only when configured conditions are met. The base IAM grant defines the principal, role, and resource, while the condition constrains when that grant can be used. This pattern enables time-limited and attribute-based delegation for Cloud Storage objects, including time-limited delegation patterns such as signed URLs, without creating separate long-lived grants. Use IAM Conditions when delegation must expire or be narrowed, and keep the underlying role scoped to least privilege so the condition reduces exposure.

1.3Eliminate Public Exposure and Exfiltration with VPC Service Controls

VPC Service Controls is a managed perimeter defense that is independent of IAM and can override permissive IAM settings to prevent public access. While IAM provides granular identity-based control, VPC Service Controls provides broader context-based perimeter security, including control of data egress across the perimeter. You create a service perimeter that forms a security boundary around resources such as Cloud Storage and BigQuery, and you manage what is allowed in and out of that boundary.

Data flows from the uploader to the storage service inside the perimeter through an ordered enforcement sequence:

1. Upload with IAM authorization: A principal with appropriate IAM permissions uploads data to Cloud Storage inside the perimeter.
2. Perimeter check on every request: VPC Service Controls evaluates whether the request originates from inside the perimeter or satisfies an allowed context.
3. Context-aware allowance: Designated principals that satisfy an Access Context Manager access level, based on attributes such as IP address and identity, are permitted to access data inside the perimeter.
4. Default deny: VPC Service Controls denies access to anyone not specified in the access level template, blocking copying or transfer of data outside.

Because the perimeter sits outside the storage service, traffic flows from the requester to VPC Service Controls for boundary evaluation before it reaches the bucket or object. The storage service depends on the perimeter for exfiltration defense, while Access Context Manager depends on IAM identity to define which principals qualify for an access level.

1.4Design Perimeters for Storage Workloads

Perimeter design for Cloud Storage determines how exfiltration paths are closed without breaking legitimate access. A common unified perimeter, a single large perimeter around all sensitive projects, gives the most effective protection against exfiltration with the lowest management overhead because services inside communicate freely under IAM and network controls. Management then focuses on north-south access, which is access from the internet into the perimeter, rather than east-west traffic between multiple perimeters. Choose multiple perimeters only when isolation demands it, such as separating high-trust data from de-identified data for sharing, isolating regulated data for standards such as PCI DSS, or hosting independent third-party tenants.

When you create a perimeter, enable all protected services rather than protecting one API and not another, because any unprotected API remains an exfiltration vector. Keep the design simple, avoid multiple bridges and complex access levels, and ensure resources inside the VPC network have no direct internet egress.

BigQuery (opens in a new tab) fine-grained access control restricts visibility below the dataset level to specific tables, columns, and rows. Identity and Access Management (IAM) provides the base layer, where organizations contain projects, projects contain datasets, and tables inherit permissions from the dataset that contains them. Column-level security, row-level security, and authorized views then narrow that inherited access so analytical users see only the slices they are entitled to.

2.1IAM Hierarchy and Table-Level Access Control

Table-level access control in BigQuery grants a user, group, or service account access to a specific table or view without granting access to the entire dataset. Organization and project roles control the ability to run jobs or manage the project, while dataset roles control the ability to access or modify data inside the project. Access is granted with predefined roles for common patterns or custom roles for a user-specified list of permissions. This table-level grant is the foundation on which column-level and row-level filters are then applied.

2.2Column-Level Security with Policy Tags and Taxonomy

Column-level security in BigQuery controls access to sensitive columns using policy tags organized in a taxonomy. A taxonomy is a classification hierarchy created in Data Catalog, and policy tags are the nodes in that hierarchy attached to columns in the table schema. A user must have dataset access plus the Data Catalog Fine-Grained Reader role on the relevant policy tag to read protected column data, while untagged columns remain available to all users with warehouse access. Policy tags also support type-based classification and work with column-level dynamic data masking, which obscures values while still allowing access to the column.

A secured warehouse commonly defines a tiered taxonomy where higher tiers include lower tiers:

• 3_Confidential for very sensitive information such as credit card numbers, which also grants access to columns tagged 2_Private or 1_Sensitive.
• 2_Private for sensitive personally identifiable information (PII) such as first name, which also grants access to 1_Sensitive but not to 3_Confidential.
• 1_Sensitive for non-public data such as credit limit, which grants no access to 2_Private or 3_Confidential.

Protection remains enforced even after data is re-identified, because the column cannot be read until access to its tag is explicitly granted. The same column control applies when protected columns are accessed through logical views and authorized views, since both types of views derive from the source table.

2.3Query Behavior and Lifecycle for Protected Columns

Query behavior for protected columns fails closed when the caller lacks the Fine-Grained Reader grant. A user with dataset access but without the tag grant who runs SELECT * receives an error that lists the inaccessible columns and names the full policy tag required. The user can then query with SELECT * EXCEPT (ssn) to exclude the denied column or request the Fine-Grained Reader role on that tag from a Data Catalog Administrator. Protected tables require GoogleSQL, because any legacy SQL query is rejected if target tables have policy tags, and policy tag checks are logged in Cloud Logging.

The lifecycle for policy tags preserves protection against accidental exposure. Policy tags can be applied to leaf fields of STRUCT or RECORD columns only, and only those leaf fields are protected. To clear a tag, the schema policyTags.names field must be explicitly set to an empty list [], and the tables.patch method is preferred over tables.update because tables.update replaces the entire table resource. Deleting a policy tag automatically removes its association from all columns, and when the deleted tag had an associated data policy, the data policy can take up to 30 minutes to be deleted unless deleted directly.

2.4Row-Level Security Filtering by User

Row-level security in BigQuery filters table data so a principal can access only specific rows that satisfy a qualifying user condition. Whereas column-level security removes entire columns for unauthorized readers, row-level security keeps the column visible but returns a different subset of rows per user. The row filter is evaluated at query time, so the same table can serve multiple tenants or groups without duplicating data.

2.5Authorized Views and Datasets for Tenant Isolation

An authorized view is a view that is authorized to read its source dataset, allowing specific users to query the view results without granting them access to the underlying source data. This pattern shares a curated subset of rows or columns across datasets, projects, or tenant boundaries while the base table retains its IAM and column policies. Column policies on a base table apply to all authorized views regardless of permissions on those views, and data access through the view is reflected in logging of the base table. There is a hard limit of 2500 authorized resources per dataset, where authorized resources include authorized views, authorized datasets, and authorized functions.

Tenant access to large fact tables is commonly implemented with tenant-specific authorized views or tenant-specific subset tables, which differ in scale and tradeoffs:

Choose authorized views when tenant segmentation needs instant logic changes and centralized policy enforcement from the base table. Choose subset tables when tenants need independent partitioning, clustering, regionalization, or isolated access logging.

Cloud SQL (opens in a new tab) secure connectivity and database authentication removes public network paths to the database, requires encrypted transit for every connection, and allows only authorized identities to perform administrative and transactional work. Cloud SQL instances hold sensitive transactional data, so access is restricted at the network boundary, at the transport layer with SSL/TLS, and at the identity layer with Identity and Access Management (IAM). Together these three layers prevent unauthorized exposure, eavesdropping, and privilege misuse.

3.1Restrict Network Exposure with Private IP Connectivity

Private IP connectivity for Cloud SQL means clients reach the instance through a Virtual Private Cloud (VPC) network instead of the public internet, so traffic never leaves Google-controlled or private boundaries. Public access is restricted by preventing public IP assignment, auditing existing instances to extract public IP addresses, and defining allowlisted IP addresses in access-level policy rules when hybrid access is required. For hybrid paths from on-premises or another cloud, an encrypted connection using Cloud VPN or Cloud Interconnect protects all data that flows between Google Cloud and the external environment, with Dedicated Interconnect recommended when streaming large volumes because it provides a direct connection and high throughput.

Defense around the private path depends on deny-by-default controls and perimeters. Firewall rules deny all traffic by default and explicitly allow only traffic that meets defined criteria, such as specific ports and sources. VPC Service Controls defines a service perimeter around supported resources so only API traffic originating within the perimeter can access restricted services, which limits the value of compromised credentials used from attacker-controlled endpoints outside. Ingress and egress rules on the perimeter then control how data flows into and out of the protected Cloud SQL and related data services.

3.2Enforce SSL/TLS Encryption for Database Connections

Enforced SSL/TLS encryption for Cloud SQL means every incoming database connection and every remote access session must use cryptographic protection for confidentiality and integrity. The control requires SSL for all incoming database connections, verifies SSL certificates in use, and encrypts application traffic between clients and servers and between on-premises networks and Google Cloud, including encrypted proxy-based paths such as the Cloud SQL Auth proxy pattern. Remote sessions use SSH or HTTPS rather than cleartext protocols, and the on-premises to Google Cloud link is further protected with mechanisms such as HA VPN over Cloud Interconnect for IPsec encryption.

The minimum transport standard is TLS 1.2 or higher, and legacy TLS versions are restricted to prevent downgrade to weak protocols. Enforcing a modern TLS version ensures authentication and encryption when data moves outside physical boundaries controlled by Google or on behalf of Google, while data inside those boundaries is generally authenticated. For instances with sensitive data, transport encryption is paired with customer-managed encryption keys (CMEKs) in Cloud Key Management Service (Cloud KMS) so data at rest is encrypted under keys the organization controls.

3.3Implement Cloud IAM Database Authentication with Least Privilege

Cloud IAM database authentication for Cloud SQL means administrative and transactional access is granted only to authorized users, groups, and service accounts through IAM roles that follow least privilege. Organization and project roles control the ability to manage the project and run jobs, while finer-grained roles control the ability to access or modify data inside the project. Access is implemented with predefined roles for common patterns and custom roles for a user-specified list of permissions, combined with IAM policies with conditions and tags to limit who can reach specific instances, databases, and operations.

Separation of duties and temporary elevation further restrict standing privilege:

• Map IAM roles to groups rather than individuals and regularly analyze and adjust assigned roles.
• Enforce separation of duties so no single identity holds both administrative and data-access power without collusion safeguards.
• Use principal access boundary (PAB) policies to limit which resources a principal can reach even when granted broader roles.
• Use Privileged Access Manager for just-in-time, temporary privilege elevation, then review audit logs for that activity.
• Restrict service account key creation and use more secure authentication alternatives, because downloaded key material can be copied from CLI configuration, file systems, or code repositories.

A hardened Cloud SQL posture therefore depends on Cloud SQL relying on IAM for authentication, on the VPC for private routing, and on SSL/TLS for transit protection. The workflow depends on the VPC for private routing, depends on IAM for identity decisions, and depends on Cloud KMS when CMEK protection is required for sensitive instances. When all three are enforced, only the correct identity from the correct network with a compliant encrypted session can perform database administration or transactions.

Key Facts

• Cloud Storage protection requires both Identity and Access Management (IAM) for identity-based access and VPC Service Controls for context-based perimeter defense, where VPC Service Controls can deny a request that passes IAM.
• Uniform bucket-level access makes the IAM policy the single authority for Cloud Storage buckets and objects, while IAM Conditions constrain a grant to an approved context such as a time window.
• BigQuery column-level security requires dataset access plus the Data Catalog Fine-Grained Reader role on the policy tag, and a SELECT * query without that role fails with an error naming the required tag.
• BigQuery authorized views allow users to query view results without access to the source data, subject to a limit of 2500 authorized resources per dataset.
• Cloud SQL must use private IP connectivity to avoid the public internet and enforce SSL/TLS with a minimum of TLS 1.2, paired with customer-managed encryption keys (CMEKs) in Cloud KMS for sensitive data at rest.