BigQuery 행 수준 보안 소개

이 문서에서는 행 수준 보안의 개념, BigQuery에서 작동하는 방식, 행 수준 보안을 사용하여 데이터를 보호해야 하는 경우 및 기타 세부정보를 설명합니다.

행 수준 보안이란 무엇인가요?

행 수준 보안을 사용하면 사용자의 자격 조건을 기준으로 데이터를 필터링하고 테이블의 특정 행에 액세스하도록 허용할 수 있습니다.

BigQuery는 이미 프로젝트, 데이터 세트, 테이블 수준에서 액세스 제어를 지원하며 정책 태그를 통한 열 수준 보안도 지원합니다. 행 수준 보안은 행 수준 액세스 정책을 통해 BigQuery 테이블의 데이터 하위 집합에 대한 세분화된 액세스 제어를 실현함으로써 최소 권한의 원칙을 확장합니다.

하나의 테이블에 여러 개의 행 수준 액세스 정책이 포함될 수 있습니다. 행 수준 액세스 정책은 데이터 세트 수준, 테이블 수준, 프로젝트 수준 액세스 제어는 물론 열 수준 보안과 함께 테이블에 공존할 수 있습니다.

행 수준 보안의 작동 원리

대략적으로, 행 수준 보안에는 대상 BigQuery 테이블에 행 수준 액세스 정책을 만드는 작업이 포함됩니다. 이러한 정책은 사용자나 그룹이 허용된 목록에 있는지 여부에 따라 특정 데이터 행을 숨기거나 표시하는 필터 역할을 합니다. 허용 목록에 명시적으로 포함되지 않은 사용자 또는 그룹은 액세스가 거부됩니다.

Identity and Access Management(IAM) 역할인 BigQuery 관리자 또는 BigQuery DataOwner 역할을 갖는 승인된 사용자는 BigQuery 테이블에 행 수준 액세스 정책을 만들 수 있습니다.

행 수준 액세스 정책을 만들 때는 테이블 이름을 지정하고 특정 행 데이터에 액세스할 수 있는 사용자 또는 그룹(grantee-list라고 함)을 지정합니다. 정책에는 filter_expression이라는 필터링 기준으로 사용할 데이터도 포함됩니다. filter_expression은 일반적인 쿼리의 WHERE 절처럼 작동합니다.

행 수준 액세스 정책을 만들고 사용하는 방법에 대한 안내는 행 수준 보안 작업을 참조하세요.

행 수준 액세스 정책을 만들 때의 전체 구문, 사용 방법, 옵션에 대한 DDL 참조를 확인하세요.

사용 사례

리전을 기반으로 행 데이터 필터링

dataset1.table1 테이블에 region 열이 가리키는 여러 리전에 속한 행이 있다고 가정해 보겠습니다.

데이터 소유자 또는 관리자는 행 수준 보안을 사용하여 'group:apac의 사용자는 APAC 리전의 파트너만 볼 수 있음'과 같은 정책을 구현할 수 있습니다.

리전에 대한 행 수준 보안 사용 사례

결과적으로 sales-apac@example.com 그룹의 사용자가 Region = "APAC"인 행만 볼 수 있습니다. 이와 비슷하게 sales-us@example.com 그룹의 사용자는 US 리전의 행만 볼 수 있습니다. APAC 또는 US 그룹에 없는 사용자에게는 행이 표시되지 않습니다.

us_filter라는 행 수준 액세스 정책은 미국의 영업 책임자인 jon@example.com을 포함한 여러 항목에 액세스 권한을 부여하며, 이제 이들은 모두 US 리전에 속하는 행에 액세스할 수 있습니다.

민감한 정보를 기준으로 행 데이터 필터링

이제 다른 사용 사례로, 급여 데이터 테이블을 살펴 보겠습니다.

급여에 대한 행 수준 보안 사용 사례

grantee_list는 회사 도메인의 구성원만 쿼리하도록 제한합니다. 또한 SESSION_USER() 함수를 통해 사용자의 이메일 주소를 기준으로 쿼리를 실행하는 사용자에게 속한 행으로만 액세스를 더 제한합니다. 이 경우에는 jim@example.com입니다.

참고표를 기준으로 행 데이터 필터링

이 기능에 대한 의견을 제공하거나 지원을 요청하려면 bigquery-row-level-security-support@google.com으로 이메일을 보내주세요.

서브 쿼리 지원을 사용한 행 액세스 정책은 다른 테이블을 참조하여 참고표로 사용할 수 있습니다. 필터링 규칙에 사용되는 데이터는 테이블에 저장할 수 있으며 단일 서브 쿼리 행 액세스 정책은 구성된 여러 행 액세스 정책을 대체할 수 있습니다. 행 액세스 정책을 업데이트하려면 여러 행 액세스 정책을 대체하는 참고표만 업데이트하면 됩니다. 각 개별 행 액세스 정책을 업데이트할 필요가 없습니다.

다른 방법이 아닌 행 수준 보안을 사용해야 하는 경우

승인된 뷰, 행 수준 액세스 정책, 별도 테이블에 데이터 저장 방식은 각기 다른 수준의 보안, 성능, 편의성을 제공합니다. 사용 사례에 적합한 메커니즘을 선택해야 적절한 수준으로 데이터의 보안을 강화할 수 있습니다.

승인된 뷰와 비교: 취약점

행 수준 보안 및 승인된 뷰를 통한 행 수준 액세스 적용이라는 두 가지 방법 모두 잘못 사용할 경우 취약점이 발생할 수 있습니다.

행 수준 보안을 위해 승인된 뷰를 사용하든 행 수준 액세스 정책을 사용하든, 감사 로깅을 사용하여 의심스러운 활동을 모니터링하는 것이 좋습니다.

쿼리 기간과 같은 사이드 채널은 스토리지 샤드 에지에 있는 행에 대한 정보를 유출할 수 있습니다. 이러한 공격을 실행하려면 테이블이 샤딩된 방식을 어느 정도 알고 있거나 대량의 쿼리를 사용해야 합니다.

이러한 부차 채널 공격 방지에 대한 상세 설명은 행 수준 보안 권장사항을 참조하세요.

승인된 뷰, 행 수준 보안, 별도 테이블 비교

다음 표에서는 승인된 뷰, 행 수준 액세스 정책, 별도 테이블의 유연성, 성능 및 보안을 비교합니다.

메서드 보안 고려사항 권장사항
승인된
뷰		 유연성을 위해 권장됩니다. 신중하게 설계된 쿼리, 쿼리 기간 및 기타 유형의 사이드 채널 공격에 취약할 수 있습니다. 승인된 뷰는 다른 사용자와 데이터를 공유해야 하는데 유연성과 성능이 중요할 경우 적합한 선택입니다. 예를 들어 승인된 뷰를 사용하여 작업 그룹 내에서 데이터를 공유할 수 있습니다.
행 수준 액세스 정책 유연성과 보안의 균형을 위해 권장됩니다. 쿼리 기간 부채널 공격에 대해 취약할 수 있습니다. 행 수준 액세스 정책은 다른 사용자와 데이터를 공유해야 하고 뷰 또는 테이블 슬라이스보다 더 강력한 보안을 제공하려는 경우 적합합니다. 예를 들어 일부 사용자가 다른 사용자보다 더 많은 데이터에 액세스할 수 있는 경우에도 행 수준 액세스 정책을 사용하여 동일한 대시보드를 사용하는 모든 사용자와 데이터를 공유할 수 있습니다.
별도 테이블 보안을 위해 권장됩니다. 사용자는 테이블 액세스 없이는 데이터를 추론할 수 없습니다. 다른 사람과 데이터를 공유하면서 데이터를 격리된 상태로 유지해야 하는 경우 별도의 테이블을 선택하는 것이 좋습니다. 예를 들어, 행의 수가 보안 비밀이어야 하는 경우 여러 개의 개별적인 테이블을 사용하여 서드 파티 파트너 및 공급업체와 데이터를 공유할 수 있습니다.

행 수준 액세스 정책 만들기 및 관리

테이블에서 행 수준 액세스 정책을 생성, 업데이트(다시 만들기), 나열, 조회, 삭제하는 방법에 대한 자세한 내용과 행 수준 액세스 정책이 있는 테이블을 쿼리하는 방법은 행 수준 액세스 보안 작업을 참조하세요.

할당량

행 수준 보안의 할당량 및 한도에 대한 자세한 내용은 BigQuery 할당량 및 한도를 참조하세요.

가격 책정

행 수준 보안은 BigQuery에 추가 비용 없이 포함되어 있습니다. 그러나 행 수준 액세스 정책은 다음과 같은 방식으로 쿼리 실행 비용에 영향을 줄 수 있습니다.

  • 행 수준 액세스 정책, 특히 다른 테이블을 참조하는 서브 쿼리가 포함된 정책에 의해 추가 비용이 발생할 수 있습니다.

  • 행 수준 액세스 정책 필터는 파티션을 나누고 클러스터링된 테이블의 쿼리 프루닝에 참여하지 않습니다. 그렇다고 해서 기본 쿼리 실행 중에 더 많은 데이터를 읽는 것은 아닙니다. 더 이상 프루닝할 때 행 액세스 정책 조건자를 활용하지 않습니다.

  • 행 수준 액세스 정책 필터를 사용하면 모든 사용자 필터가 조기에 적용되지는 않습니다. 이로 인해 테이블에서 읽은 데이터 양이 증가하고 더 많은 행을 읽고 청구할 수 있습니다.

BigQuery 쿼리 가격 책정에 대한 자세한 내용은 BigQuery 가격 책정을 참조하세요.

제한사항

행 수준 보안 제한사항에 대한 자세한 내용은 BigQuery 행 수준 보안 제한을 참조하세요. 다음 섹션에서 행 수준 보안 제한에 대해 추가로 설명합니다.

성능 제한사항

행 수준 보안이 일부 BigQuery 기능 및 서비스와 상호작용하는 방법에 대한 자세한 내용은 다른 BigQuery 기능과 함께 행 수준 보안 사용을 참조하세요.

기타 제한사항

  • 특정 BigQuery 버전으로 생성된 예약을 사용하는 경우에는 이 기능을 사용하지 못할 수 있습니다. 각 버전에서 사용 설정된 기능에 대한 자세한 내용은 BigQuery 버전 소개를 참조하세요.

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

  • JSON 열에서는 행 수준 액세스 정책을 적용할 수 없습니다.

  • 일부 BigQuery 기능은 행 수준 보안과 호환되지 않습니다. 자세한 내용은 행 수준 보안 사용을 참조하세요.

  • 테이블 데이터에 대한 전체 액세스 권한이 필요한 서비스 계정 작업을 포함한 쿼리가 아닌 작업은 TRUE 필터로 행 수준 보안을 사용할 수 있습니다. 예시에는 테이블 복사, dataproc 워크플로 등이 포함됩니다. 자세한 내용은 행 수준 보안 사용을 참조하세요.

  • 행 수준 액세스 정책 만들기, 교체 또는 삭제는 DDL 문으로 수행되어야 합니다. 행 수준 액세스 정책 나열 및 보기는 Google Cloud 콘솔 또는 bq 명령줄 도구를 통해 수행될 수 있습니다.

  • 테이블 미리보기 또는 찾아보기는 행 수준 보안과 호환되지 않습니다.

  • 테이블 샘플링은 행 수준 보안과 호환되지 않습니다.

  • 최상위 서브 쿼리 정책 결과는 100MB로 제한됩니다. 이 한도는 행 수준 액세스 정책별로 적용됩니다.

  • 참조된 테이블 삭제로 인해 행 수준 액세스 정책 조건자를 평가할 수 없으면 쿼리가 실패합니다.

  • 서브 쿼리 행 수준 액세스 정책은 BigQuery 테이블, BigLake 외부 테이블, BigLake 관리 테이블만 지원합니다.

감사 로깅 및 모니터링

행 수준 액세스 정책이 하나 이상 있는 테이블의 데이터를 읽으면 읽기 액세스에 대해 승인된 행 수준 액세스 정책과 하위 쿼리에서 참조되는 해당 테이블이 읽기 요청에 대한 IAM 승인 정보에 표시됩니다.

행 수준 액세스 정책 만들기 및 삭제는 감사 로깅되며 Cloud Logging을 통해 액세스될 수 있습니다. 감사 로그에는 행 수준 액세스 정책의 이름이 포함됩니다. 하지만 행 수준 액세스 정책의 filter_expression 및 grantee_list 정의는 사용자 정보 또는 기타 민감한 정보를 포함할 수 있기 때문에 로그에서 생략됩니다. 행 수준 액세스 정책의 나열 및 보기는 감사 로깅되지 않습니다.

BigQuery의 로깅에 대한 자세한 내용은 BigQuery 모니터링 소개를 참조하세요.

Google Cloud의 로깅에 대한 상세 설명은 Cloud Logging을 참조하세요.

다음 단계