다른 BigQuery 기능과 함께 행 수준 보안 사용

이 문서에서는 다른 BigQuery 기능과 함께 행 수준 액세스 보안을 사용하는 방법을 설명합니다.

이 문서를 읽기 전에 BigQuery 행 수준 보안 소개행 수준 보안 작업을 읽어 행 수준 보안을 숙지합니다.

TRUE 필터

행 수준 액세스 정책은 쿼리를 실행할 때 사용자에게 표시되는 결과 데이터를 필터링할 수 있습니다. DML과 같은 비쿼리 작업을 실행하려면 테이블의 모든 행에 대한 전체 액세스 권한이 필요합니다. 필터 표현식이 TRUE로 설정된 행 액세스 정책을 통해 전체 액세스 권한이 부여됩니다. 이 행 수준 액세스 정책을 TRUE 필터라고 합니다.

모든 사용자는 서비스 계정을 포함하여 TRUE 필터 액세스 권한을 부여받을 수 있습니다.

비쿼리 작업 예시는 다음과 같습니다.

TRUE 필터 만들기

CREATE ROW ACCESS POLICY all_access ON project.dataset.table1
GRANT TO ("group:all-rows-access@example.com")
FILTER USING (TRUE);

TRUE 필터와 함께 작동하는 기능

복사 작업

행 수준 액세스 정책이 하나 이상 있는 테이블을 복사하려면 먼저 소스 테이블에 TRUE 필터 액세스 권한을 부여해야 합니다. 소스 테이블의 모든 행 수준 액세스 정책도 새 대상 테이블에 복사됩니다. 행 수준 액세스 정책이 없는 소스 테이블을 행 수준 액세스 정책이 있는 대상 테이블에 복사하면 --append_table 플래그를 사용하거나 "writeDisposition": "WRITE_APPEND"가 설정되어 있지 않는 한, 행 수준 액세스 정책이 대상 테이블에서 삭제됩니다.

리전 간 복사가 허용되며 모든 정책이 복사됩니다. 쿼리의 서브 쿼리 정책에 잘못된 테이블 참조가 포함된 경우 복사가 완료된 후 후속 쿼리가 손상될 수 있습니다.

테이블의 행 수준 액세스 정책에는 고유한 이름이 있어야 합니다. 복사 중에 행 수준 액세스 정책 이름이 충돌하면 잘못된 입력 오류가 발생합니다.

행 수준 액세스 정책으로 테이블을 복사하기 위해 필요한 권한

하나 이상의 행 수준 액세스 정책이 있는 테이블을 복사하려면 행 수준 액세스 정책이 없는 테이블 복사에 필요한 권한 외에도 다음 권한이 있어야 합니다.

권한 리소스
bigquery.rowAccessPolicies.list 소스 테이블
bigquery.rowAccessPolicies.getIamPolicy 소스 테이블
TRUE 필터 소스 테이블
bigquery.rowAccessPolicies.create 대상 테이블
bigquery.rowAccessPolicies.setIamPolicy 대상 테이블

BigQuery API의 Tabledata.list

행 수준 액세스 정책이 있는 테이블에서 BigQuery API의 tabledata.list 메서드를 사용하려면 TRUE 필터 액세스 권한이 필요합니다.

DML

행 수준 액세스 정책이 있는 테이블을 업데이트하는 DML 문을 실행하려면 테이블에 대한 TRUE 필터 액세스 권한이 필요합니다.

특히 MERGE 문은 다음과 같이 행 수준 액세스 정책과 상호작용합니다.

  • 대상 테이블에 행 수준 액세스 정책이 있으면 대상 테이블에 대한 TRUE 필터 액세스 권한이 필요합니다.
  • 소스 테이블에 행 수준 액세스 정책이 포함되면 MERGE 문이 사용자에게 표시되는 행에서만 작동합니다.

테이블 스냅샷

테이블 스냅샷은 행 수준 보안을 지원합니다. 행 수준 액세스 정책이 있는 테이블을 복사하는 데 필요한 권한에 설명된 것처럼 사용자는 기본 테이블(소스 테이블) 및 테이블 스냅샷(대상 테이블)에 대한 권한이 있어야 합니다.

하나 이상의 행 수준 보안 정책을 갖는 기본 테이블에는 시간 이동이 지원되지 않습니다.

JSON 열이 있는 BigQuery 테이블

행 수준 액세스 정책은 JSON 열에 적용할 수 없습니다. 행 수준 보안의 제한사항에 대해 자세히 알아보려면 제한사항을 참조하세요.

BigQuery BI Engine 및 Looker Studio

BigQuery BI Engine은 행 수준 액세스 정책이 하나 이상 있는 테이블에서 실행되는 쿼리를 가속화하지 않습니다. 이러한 쿼리는 BigQuery에서 표준 쿼리로 실행됩니다.

Looker Studio 대시보드의 데이터는 기본 소스 테이블의 행 수준 액세스 정책에 따라 필터링됩니다.

열 수준 보안

열 수준 액세스 제어동적 데이터 마스킹을 모두 포함하는 행 수준 보안과 열 수준 보안은 완전하게 호환됩니다.

주요 사항은 다음과 같습니다.

  • 특정 열의 데이터에 대한 액세스 권한이 없는 경우에도 해당 열의 데이터를 필터링하도록 행 수준 액세스 정책을 적용할 수 있습니다.
    • 서브 쿼리 행 수준 액세스 정책으로 이러한 열에 액세스하려고 시도하면 액세스가 거부되었음을 나타내는 오류가 발생합니다. 이러한 열은 시스템 참조 열로 간주되지 않습니다.
    • 비 서브 쿼리 행 수준 액세스 정책으로 이러한 열에 액세스하려고 하면 열 수준 보안을 우회합니다.
  • 열 수준 보안으로 인해 제한되고 쿼리의 SELECT 문 또는 서브 쿼리 행 수준 액세스 정책에서 열의 이름이 지정된 경우 오류가 발생합니다.
  • 열 수준 보안은 또한 SELECT * 쿼리 문으로 적용됩니다. SELECT *는 제한된 열을 명시적으로 지정하는 쿼리와 동일하게 취급됩니다.

행 수준 보안과 열 수준 보안의 상호작용 예시

이 예시에서는 테이블을 보호한 후 쿼리하는 과정을 안내합니다.

데이터

열 3개가 있는 my_table이라는 테이블이 포함된 my_dataset라는 데이터 세트의 데이터 소유자 역할을 수행한다고 가정해 보겠습니다. 테이블에는 다음 테이블에 표시된 데이터가 포함됩니다.

이 예시에서 한 사용자는 Alice이고 이메일 주소는 alice@example.com입니다. 두 번째 사용자는 Alice의 동료인 Bob입니다.

rank 과일 색상
1 사과 빨간색
2 orange orange
3 레몬 노란색
4 라임색 녹색

보안

Alice는 rank 열에서 번호가 짝수가 아닌 홀수인 행만 볼 수 있게 하려고 합니다. Bob은 짝수이든 홀수이든 어떠한 행도 볼 수 없어야 합니다. fruit 열의 데이터는 어떠한 사용자도 볼 수 없어야 합니다.

  • Alice가 짝수 행을 볼 수 없도록 제한하려면 rank 열에 표시되는 데이터를 기준으로 하는 필터 표현식이 있는 행 수준 액세스 정책을 만듭니다. Bob은 짝수 또는 홀수 행을 볼 수 없도록 수혜자 목록에 포함하지 않습니다.

    CREATE ROW ACCESS POLICY only_odd ON my_dataset.my_table GRANT
    TO ('user:alice@example.com') FILTER USING (MOD(rank, 2) = 1);
    
  • 모든 사용자가 fruit 열의 데이터를 볼 수 없도록 제한하려면 모든 사용자가 어떠한 데이터에도 액세스할 수 없도록 하는 열 수준 보안 정책 태그를 만듭니다.

마지막으로 color 열에 대한 액세스를 다음 두 가지 방법으로 제한합니다. 즉, 열에 모든 사용자의 모든 액세스를 금지하는 열 수준 보안 정책 태그를 적용합니다. 또한 color 열의 행 데이터 중 일부를 필터링하는 행 수준 액세스 정책의 영향을 받습니다.

  • 이 두 번째 행 수준 액세스 정책은 color 열이 green 값인 행만 표시합니다.

    CREATE ROW ACCESS POLICY only_green ON my_dataset.my_table
    GRANT TO ('user:alice@example.com') FILTER USING (color="green");
    

Bob의 쿼리

Alice의 동료인 Bob이 my_dataset.my_table의 데이터를 쿼리하려고 하면 Bob은 테이블의 모든 행 수준 액세스 정책에서 수혜자 목록에 속하지 않았으므로 어떤 행도 볼 수 없습니다.

쿼리 my_dataset.my_table 설명
rank

(일부 데이터는 행 액세스 정책 only_odd의 영향을 받음)
fruit

(모든 데이터는 CLS 정책 태그로 보호됨)
color

(모든 데이터는 CLS 정책 태그로 보호되며 또한 일부 데이터는 행 액세스 정책 only_green의 영향을 받음)
SELECT rank FROM my_dataset.my_table
(0) 행 반환
Bob은 행 수준 액세스 정책의 수혜자 목록에 속하지 않으므로 이 쿼리는 성공하지만 행 데이터는 반환되지 않습니다.

결과가 행 액세스 정책에 따라 필터링되었을 수 있다는 메시지가 Bob에게 표시됩니다.

Alice의 쿼리

Alice가 쿼리를 실행하여 my_dataset.my_table의 데이터에 액세스할 때의 결과는 다음 테이블과 같이 실행한 쿼리와 보안에 따라 달라집니다.

쿼리 my_dataset.my_table 설명
rank

(일부 데이터는 행 액세스 정책 only_odd의 영향을 받음)
fruit

(모든 데이터는 CLS 정책 태그로 보호됨)
color

(모든 데이터는 CLS 정책 태그로 보호되며 또한 일부 데이터는 행 액세스 정책 only_green의 영향을 받음)

SELECT rank FROM my_dataset.my_table


(2) 홀수 행 반환
Alice는 순위 열의 데이터에 대한 only_odd 행 수준 액세스 정책의 수혜자 목록에 있습니다. 따라서 Alice에게는 홀수 번호의 행 데이터만 표시됩니다. 짝수 번호 행은 only_odd라는 행 수준 액세스 정책에 의해 숨겨집니다.

결과가 행 액세스 정책에 따라 필터링되었을 수 있다는 메시지가 Alice에게 표시됩니다.

SELECT fruit FROM my_dataset.my_table


access denied

fruit 열의 이름이 쿼리에서 명시적으로 지정되었습니다.

열 수준 보안이 적용됩니다.

액세스가 거부됩니다.

SELECT color FROM my_dataset.my_table


access denied

color 열의 이름이 쿼리에서 명시적으로 지정되었습니다.

color 열의 데이터에 대한 행 수준 액세스 정책이 적용되기 전에 열 수준 보안이 적용됩니다.

액세스가 거부됩니다.

SELECT rank, fruit FROM my_dataset.my_table


access denied

`fruit` 열의 이름이 쿼리에서 명시적으로 지정되었습니다.

rank 열의 데이터에 대한 행 수준 액세스 정책이 적용되기 전에 열 수준 보안이 적용됩니다.

액세스가 거부됩니다.

SELECT rank, color FROM my_dataset.my_table


access denied

color 열의 이름이 쿼리에서 명시적으로 지정되었습니다.

rankcolor 열의 데이터에 대한 행 수준 액세스 정책이 적용되기 전에 color 열의 열 수준 보안이 적용됩니다.

액세스가 거부됩니다.

SELECT fruit, color FROM my_dataset.my_table


access denied


access denied

fruitcolor 열의 이름이 쿼리에서 명시적으로 지정되었습니다.

color 열의 데이터에 대한 행 수준 액세스 정책이 적용되기 전에 fruitcolor 열의 열 수준 보안이 적용됩니다.

액세스가 거부됩니다.

SELECT * FROM my_dataset.my_table


access denied


access denied

fruitcolor 열의 이름이 쿼리에서 'SELECT *'를 사용하여 암시적으로 지정되었습니다.

rank 또는 color 열의 데이터에 대한 행 수준 액세스 정책이 적용되기 전에 fruitcolor 열의 열 수준 보안이 적용됩니다.

액세스가 거부됩니다.

TRUE 필터 액세스

마지막으로 TRUE 필터 액세스 섹션의 설명대로 Alice 또는 Bob에게 TRUE 필터 액세스 권한이 있으면 테이블의 모든 행이 표시되며 이러한 행을 비쿼리 작업으로 사용할 수 있습니다. 그러나 테이블에 열 수준 보안이 있더라도 여전히 적용되고 결과에 영향을 미칠 수 있습니다.

추출 작업

테이블에 행 수준 액세스 정책이 포함된 경우 추출 작업을 실행할 때 볼 수 있는 데이터만 Cloud Storage로 내보냅니다.

Legacy SQL

행 수준 액세스 정책은 Legacy SQL과 호환되지 않습니다. 행 수준 액세스 정책이 있는 테이블 쿼리에는 GoogleSQL이 사용되어야 합니다. Legacy SQL 쿼리는 거부됩니다.

파티션을 나눈 테이블 및 클러스터링된 테이블

행 수준 보안은 파티션을 나눈 테이블의 기능인 쿼리 프루닝에 참여하지 않습니다.

행 수준 보안이 파티션을 나누고 클러스터링된 테이블과 호환되지만 파티션 프루닝 중에는 행 데이터를 필터링하는 행 수준 액세스 정책이 적용되지 않습니다. 파티션 열에서 작동하는 WHERE 절을 지정하여 행 수준 보안을 사용하는 테이블에는 파티션 프루닝을 사용할 수 있습니다. 마찬가지로, 행 수준 액세스 정책 자체가 클러스터링된 테이블에 대한 쿼리의 성능을 개선하지 않지만 사용자가 적용하는 다른 필터링을 방해하지는 않습니다.

쿼리 가지치기는 정책에 필터를 사용하여 행 수준 액세스 정책을 실행하는 동안 수행됩니다.

테이블 이름 바꾸기

행 액세스 정책이 하나 이상 있는 테이블의 이름을 바꾸는 데 TRUE 필터 액세스 권한이 필요하지 않습니다. DDL 문으로 테이블 이름을 바꿀 수 있습니다.

대신 또한 테이블을 복사하고 대상 테이블에 다른 이름을 지정할 수 있습니다. 소스 테이블에 행 수준 액세스 정책이 있는 경우 자세한 내용을 보려면 이 페이지의 테이블 복사 작업을 참조하세요.

스트리밍 업데이트

변경 데이터 캡처로 스트리밍 테이블 UPDATE 또는 DELETE 작업을 수행하려면 TRUE 필터 액세스 권한이 있어야 합니다.

시간 이동

테이블 관리자만 행 수준 액세스 정책이 있거나 이전에 있었던 테이블의 이전 데이터에 액세스할 수 있습니다. 다른 사용자가 행 수준 액세스 권한이 있거나 이전에 있었던 테이블에서 시간 이동 데코레이터를 사용하면 access denied 오류가 발생합니다. 자세한 내용은 시간 이동 및 행 수준 액세스를 참조하세요.

뷰 및 구체화된 뷰

뷰 또는 구체화된 뷰에 표시되는 데이터는 기본 소스 테이블의 행 수준 액세스 정책에 따라 필터링됩니다.

또한 행 수준 액세스 정책이 있는 기본 테이블에서 구체화된 뷰가 파생되는 경우의 쿼리 성능은 소스 테이블을 직접 쿼리할 때와 동일합니다. 즉, 소스 테이블에 행 수준 보안이 있으면 소스 테이블을 쿼리할 때에 비해 구체화된 뷰를 쿼리할 때 일반적으로 나타나는 성능상의 이점이 없습니다.

행 수준 액세스 정책에서는 뷰 또는 구체화된 뷰를 참조할 수 없습니다.

와일드 카드 쿼리

행 수준 액세스 정책이 있는 테이블에 대한 와일드 카드 쿼리INVALID_INPUT 오류와 함께 실패합니다.

다음 단계