Google BigQuery Column-Level Security

Column-level Security (CLS) lets organizations control access to specific columns within a BigQuery table, ensuring that sensitive data is visible only to authorized principals.

BigQuery enforces Column-level Security through a three-layer architecture:

• Policy Tag (Taxonomy): a classification label within a Data Catalog Taxonomy (e.g., "SSN" under a "Sensitivity" taxonomy).
• Schema Association: the step that attaches the Policy Tag to a specific column in the table schema.
• Data Policy: a resource that links the Policy Tag to a masking rule and grants access to specific principals.

BigQuery doesn't apply masking directly to a column. Instead, it applies masking to the tag on that column. PlainID discovers Policy Tags as protected resources and the linked Data Policies in their native form, giving users visibility into data protection in Google BigQuery and laying the foundation for centralized Policy management.

For general Native Policy concepts that Row-level and Column-level Policies share (the Native tab, the Protected Resource sub-tab, and how Vendor Compare deploys changes to BigQuery), see Google BigQuery Native Support.

Dynamic Data Masking

BigQuery supports the following masking rules, which PlainID exposes as options when you define a Column-level Policy:

You can also create Routines (User Defined Functions) and set them as masking logic within a Data Policy in Google BigQuery.

Viewing Column-level Policies in PlainID

PlainID displays Column-level Policies in Native mode.

To view a Column-level Policy in Native:

1. In the Policies Workspace, select the relevant Policy connected to Google BigQuery.
2. On the top navigation bar, click Native.
3. The Native Code panel displays the Policy Core Logic, Identities Filter, and UDF (if applicable) for the Column-level Policy. See Policy Core Logic, Identities Filter, and UDF (Conditional) below for the full JSON structure of each section.

Creating a Column-level Policy from Native

You can create new Column-level Policies for Google BigQuery directly from their native structure. There are three steps when you create a Policy:

• Details
• Code
• What

This POP has no Wizard-based creation path.

Details Step

1. From the Create Policy drop-down, select From Native.
2. On the Policy Details step, input a:

• Display Name
• Change the Policy ID if required
• Enter an optional description

3. The Access Type is fixed to Allow. BigQuery Data Policies only grant visibility into masked or unmasked values, so there's no restrictive option to choose here.

4. In the Google POP Details section, under the Vendor Policy Kind dropdown, choose Masking Policy.

5. Enter a Vendor Policy Name.

6. Input the following.

   • Project ID: Select the project ID inherited from the POP.
   • Location: Select the location manually. This must match the location of the selected Taxonomy.
   • Taxonomy: select from the taxonomies discovered by the POP.
   • Policy Tag ID: select from the Policy Tags discovered for the selected taxonomy.

7. Input the custom details if applicable to your Policies (optional).

8. Click Continue.

Code Step

In the Code step, input the logic and relevant links. Replace the placeholder with the intended masking logic. Each section includes its predefined structure and a logic placeholder, for example:

{
  "dataMaskingPolicy": {
    "predefinedExpression": "{{logic placeholder}}"
  }
}

A Column-level Native Policy in BigQuery consists of two required sections and one conditional section.

• Section 1: Policy Core Logic (always present): defines the masking behavior
• Section 2: Identities Filter (always present): defines the IAM bindings
• Section 3: UDF (conditional): present only when the Data Policy uses a routine instead of a predefinedExpression

Policy Core Logic

The Policy Core Logic defines the masking behavior applied to the column via the dataMaskingPolicy object. This can use either a predefinedExpression or a routine, but not both.

Using a predefined expression:

{
  "dataMaskingPolicy": {
    "predefinedExpression": "SHA256"
  }
}

Using a custom routine:

{
  "dataMaskingPolicy": {
    "routine": "projects/498531790395/datasets/jon_dataset/routines/mask_last_four"
  }
}

Field Reference:

Identities Filter

The Identities Filter defines the IAM bindings that control which principals receive masked access. The Platform retrieves these bindings via a separate getIamPolicy request.

{
  "bindings": [
    {
      "members": ["<principal_1>", "<principal_2>"],
      "role": "roles/bigquerydatapolicy.maskedReader"
    }
  ]
}

Example:

{
  "bindings": [
    {
      "role": "roles/bigquerydatapolicy.maskedReader",
      "members": [
        "domain:plainid.com",
        "group:qa@plainid.com",
        "principalSet://cloudresourcemanager.googleapis.com/projects/498531790395/type/ServiceAccount",
        "serviceAccount:bq-learn-research@plainid-orchestration.iam.gserviceaccount.com",
        "user:jon.kraversky@plainid.com"
      ]
    }
  ]
}

Field Reference:

UDF (Conditional)

The UDF section appears only when the Data Policy uses a routine in the Policy Core Logic section above. It describes the custom masking function applied to the column.

Example:

{
  "arguments": [
    {
      "dataType": { "typeKind": "STRING" },
      "name": "input_val"
    }
  ],
  "creationTime": "1779708810580",
  "dataGovernanceType": "DATA_MASKING",
  "definitionBody": "LPAD(SUBSTR(input_val, -4), LENGTH(input_val), '*')",
  "etag": "1pZPdwussEQJ2fUxO8qLHw==",
  "language": "SQL",
  "lastModifiedTime": "1779708810580",
  "returnType": { "typeKind": "STRING" },
  "routineReference": {
    "datasetId": "jon_dataset",
    "projectId": "plainid-orchestration",
    "routineId": "mask_last_four"
  },
  "routineType": "SCALAR_FUNCTION"
}

Field Reference:

What Step

In the What Step, add the relevant Policy Tag as the Asset Type. Ensure it's the same Policy Tag ID you set in the Details step.

How PlainID Deploys a Column-level Policy

When you deploy a Column-level Policy from PlainID, the Platform orchestrates the three-layer architecture described above:

Step 1: Taxonomy and Policy Tag
The Policy Tag and its Taxonomy must already exist in BigQuery. PlainID discovers them as protected resources so you can link a Column-level Policy to the correct Policy Tag, but it doesn't create or manage Taxonomies or Policy Tags themselves.

Step 2: Schema Association
PlainID retrieves the current table schema and attaches the Policy Tag to the target column. This is a schema modification operation (tables.update).

Step 3: Data Policy
PlainID creates or updates a Data Policy resource that links the Policy Tag to the selected masking rule, and assigns the maskedReader role to the target principals.

PlainID handles the Schema Association and Data Policy steps for you whenever you deploy a Column-level Policy. Taxonomies and Policy Tags, however, must already exist in BigQuery; PlainID discovers and links to them but doesn't create or manage them.

Deploying Policy Changes

When you discover or edit a Column-level Policy in Manage Mode, PlainID doesn't push the changes to BigQuery automatically. Use the Policy Deploy operation to:

• Accept the vendor's version of a single Policy, discarding the pending Platform change.
• Accept the Platform's version of a single Policy, or all pending Policies, and push the Data Policy update to BigQuery.

The Platform marks discrepancies between the vendor and Platform versions of a Policy, and you can review them side by side in Vendor Compare. For general information on how the Native tab, Protected Resource linking, and Vendor Compare work, see Google BigQuery Native Support.

Known Limitations