이 페이지에서는 BigQuery 열 수준 액세스 제어를 사용하여 열 수준에서 데이터 액세스를 제한할 때 쓰기에 미치는 영향을 설명합니다. 열 수준 액세스 제어에 대한 일반적인 내용은 BigQuery 열 수준 액세스 제어 소개를 참조하세요.
열 수준 액세스 제어를 사용하려면 정책 태그로 보호되는 열에 대한 읽기 권한이 있어야 합니다. 일부 쓰기 작업은 실제로 열에 쓰기 전에 열 데이터를 읽어야 합니다. 이러한 작업의 경우 BigQuery는 사용자의 읽기 권한을 확인하여 사용자가 열에 액세스할 수 있는지 확인합니다. 예를 들어 사용자가 보호된 열에 대한 쓰기 수행을 포함하는 데이터 업데이트를 하는 경우 사용자는 보호된 열에 대한 읽기 권한이 있어야 합니다. 사용자가 보호된 열에 대한 쓰기 수행을 포함하는 새 데이터 행을 삽입할 경우 사용자는 보호된 열에 대한 읽기 액세스 권한이 필요하지 않습니다. 하지만 이러한 행을 쓰는 사용자는 보호된 열에 대한 읽기 권한이 없으면 새로 작성된 데이터를 읽을 수 없습니다.
다음 섹션에서는 여러 유형의 쓰기 작업에 대한 세부정보를 제공합니다. 이 주제의 예시에서는 다음 스키마가 있는 customers 테이블을 사용합니다.
필드 이름
유형
모드
정책 태그
user_id
STRING
REQUIRED
policy-tag-1
credit_score
정수
null 허용
policy-tag-2
ssn
STRING
null 허용
policy-tag-3
BigQuery DML 사용
데이터 삽입
INSERT 문의 경우 BigQuery는 스캔된 열 또는 업데이트된 열의 정책 태그에 대한 세분화된 권한의 리더 권한을 확인하지 않습니다. 이는 INSERT가 열 데이터를 읽을 필요가 없기 때문입니다. 하지만 읽기 권한이 없는 열에 값을 성공적으로 삽입해도 값은 정상적으로 보호됩니다.
데이터 삭제, 업데이트, 병합
DELETE, UPDATE, MERGE 문의 경우 BigQuery는 스캔된 열에서 세분화된 권한의 리더 권한을 확인합니다. WHERE 절 또는 쿼리가 데이터를 읽어야 하는 다른 절 또는 하위 쿼리를 포함하지 않는 한 이러한 문에서 열이 스캔되지 않습니다.
데이터 로드
Cloud Storage 또는 로컬 파일에서 데이터를 테이블로 로드하는 경우 BigQuery는 대상 테이블 열의 세분화된 권한의 리더 권한을 확인하지 않습니다. 이는 데이터를 로드할 때 대상 테이블의 콘텐츠를 읽을 필요가 없기 때문입니다.
BigQuery로 스트리밍하는 것은 LOAD, INSERT와 비슷합니다.
세분화된 권한의 리더 권한이 없더라도 BigQuery에서는 데이터를 대상 테이블 열로 스트리밍할 수 있습니다.
데이터 복사
복사 작업의 경우 BigQuery는 사용자에게 소스 테이블에 대한 세분화된 권한의 리더 권한이 있는지 확인합니다. BigQuery는 사용자에게 대상 테이블의 열에 대한 세분화된 권한의 리더 권한이 있는지 확인하지 않습니다. LOAD, INSERT, 스트리밍과 마찬가지로 대상 테이블의 열에 대한 세분화된 권한의 리더 권한이 없으면 복사가 완료된 후에 방금 작성한 데이터를 읽을 수 없습니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[[["\u003cp\u003eBigQuery's column-level access control requires read permission for columns protected by policy tags when performing certain write operations that involve reading column data.\u003c/p\u003e\n"],["\u003cp\u003e\u003ccode\u003eINSERT\u003c/code\u003e statements and data loading operations (from Cloud Storage, local files, or streaming) do not require read permission on the destination table's columns, but users will be unable to read data they have written without read permission.\u003c/p\u003e\n"],["\u003cp\u003e\u003ccode\u003eDELETE\u003c/code\u003e, \u003ccode\u003eUPDATE\u003c/code\u003e, and \u003ccode\u003eMERGE\u003c/code\u003e statements need read permissions on columns scanned as part of the operation, such as those in a \u003ccode\u003eWHERE\u003c/code\u003e clause or other subquery.\u003c/p\u003e\n"],["\u003cp\u003eCopying data requires read permissions on the source table's columns, but not the destination table's, however once the data is written users must have read permissions to be able to read that data.\u003c/p\u003e\n"],["\u003cp\u003eWhen using BigQuery change data capture, policy tags are checked on the primary key columns.\u003c/p\u003e\n"]]],[],null,["# Impact on writes from column-level access control\n=================================================\n\nThis page explains the impact to writes when you use BigQuery\ncolumn-level access control to restrict access to data at the column level. For\ngeneral information about column-level access control, see [Introduction to\nBigQuery column-level access control](/bigquery/docs/column-level-security-intro).\n\nColumn-level access control requires a user to have read permission for columns that\nare protected by policy tags. Some write operations need to read column data\nbefore actually writing into a column. For those operations,\nBigQuery checks the user's read permission to ensure the user has\naccess to the column. For example, if a user is updating data that includes\nwriting to a protected column, the user must have read permission for the\nprotected column. If the user is inserting a new data row that includes writing\nto a protected column, the user doesn't need read access for the protected\ncolumn. But, the user who writes such a row won't be able to read the newly\nwritten data unless the user has read permission for the protected columns.\n\nThe following sections provide details about different types of write\noperations. The examples in this topic use `customers` tables with the following\nschema:\n\nUsing BigQuery data manipulation language (DML)\n-----------------------------------------------\n\n### Inserting data\n\nFor an `INSERT` statement, BigQuery does not check Fine-Grained\nReader permission on the policy tags on either the scanned columns or the\nupdated columns. This is because an `INSERT` does not require reading any of the\ncolumn data. But, even if you successfully insert values into columns where you\ndon't have read permission, once inserted, the values are protected as expected.\n\n### Deleting, updating, and merging data\n\nFor `DELETE`, `UPDATE`, and `MERGE` statements, BigQuery checks\nfor the Fine-Grained Reader permission on the scanned columns. Columns aren't\nscanned by these statements unless you include a\n[`WHERE` clause](/bigquery/docs/reference/standard-sql/query-syntax#where_clause),\nor some other clause or subquery that requires the query to read data.\n\n### Loading data\n\nWhen loading data (for example, from Cloud Storage or local files) to a\ntable, BigQuery does not check the Fine-Grained Reader\npermission on the columns of the destination table. This is because loading data\ndoes not require reading content from the destination table.\n\nStreaming into BigQuery is similar to `LOAD` and `INSERT`.\nBigQuery lets you stream data into a destination table\ncolumn, even if you don't have the Fine-Grained Reader permission.\n\n### Copying data\n\nFor a copy operation, BigQuery checks whether the user has\nthe Fine-Grained Reader permission on the source table. BigQuery\ndoes not check whether the user has the Fine-Grained Reader permission to the\ncolumns in the destination table. Like `LOAD`, `INSERT`, and streaming,\nonce the copy is complete, you won't be able to read the data that was just\nwritten, unless you have the Fine-Grained Reader permission to the destination\ntable's columns.\n\nDML examples\n------------\n\n### `INSERT`\n\n**Example:** \n\n INSERT INTO customers VALUES('alice', 85, '123-456-7890');\n\n### `UPDATE`\n\n**Example:** \n\n UPDATE customers SET credit_score = 0\n WHERE user_id LIKE 'alice%' AND credit_score \u003c 30\n\n### `DELETE`\n\n**Example:** \n\n DELETE customers WHERE credit_score = 0\n\nLoad examples\n-------------\n\n### Loading from a local file or Cloud Storage\n\n**Example:** \n\n load --source_format=CSV samples.customers \\\n ./customers_data.csv \\\n ./customers_schema.json\n\n### Streaming\n\nNo policy tags are checked when streaming with the legacy `insertAll` streaming API or the\nStorage Write API. For BigQuery [change data capture](/bigquery/docs/change-data-capture), the policy tags are checked on the primary key columns.\n\nCopy examples\n-------------\n\n### Appending data to an existing table\n\n**Example:** \n\n cp -a samples.customers samples.customers_dest\n\n### Saving query results to a destination table\n\n**Example:** \n\n query --use_legacy_sql=false \\\n --max_rows=0 \\\n --destination_table samples.customers_dest \\\n --append_table \"SELECT * FROM samples.customers LIMIT 10;\""]]
