1. 소개
이 Codelab에서는 VPC 서비스 제어를 사용하여 BigQuery API를 보호하는 방법을 알아봅니다. 이 Codelab은 서비스 경계로 보호되는 API 서비스가 없는 상태에서 시작하며, 공개 데이터 세트에서 쿼리를 실행하고 결과를 프로젝트 테이블에 저장할 수 있습니다. 쿼리는 한 프로젝트에서 실행되고 테이블 (결과가 저장되는 위치)이 다른 프로젝트에 생성됩니다. 즉, 한 프로젝트에 데이터를 저장할 수 있지만 다른 프로젝트를 사용하여 액세스해야 하는 설정을 모방합니다.
다음으로, 데이터 프로젝트를 보호하기 위한 서비스 경계를 소개합니다. 인그레스 규칙 및 이그레스 규칙을 사용하여 관찰된 위반 사항을 해결하는 방법을 알아보고, 나중에 내부 IP 주소를 사용하여 액세스를 제한하는 액세스 수준을 추가합니다. 이 Codelab의 목표는 다음과 같습니다.
- 인그레스 및 이그레스 규칙을 각각 사용하여 인그레스 및 이그레스 위반사항을 수정하는 방법을 이해합니다.
- 특정 위반이 발생한 이유 파악
- 적용된 위반사항 수정의 범위를 분석합니다.
- 액세스 수준을 사용하여 VPC 네트워크의 내부 IP 주소에서 오는 트래픽을 허용하는 옵션을 활용하여 수정 (인그레스 / 이그레스 규칙)을 수정하여 범위를 변경합니다.
2. 리소스 설정 및 요구사항
시작하기 전에
이 Codelab에서는 다음 내용을 이미 알고 있다고 가정합니다.
- BigQuery 쿼리 실행 기본사항: 이 Codelab에서 BigQuery에서 Wikipedia 데이터 세트를 쿼리하는 방법을 알아볼 수 있습니다.
- 폴더를 만들고 관리하는 방법
- 폴더에서 프로젝트를 생성하거나 폴더에서 기존 프로젝트를 이동하는 방법
- 범위가 지정된 액세스 정책을 만드는 방법
- 서비스 경계를 만들고 구성하는 방법
- 로그에서 보안 정책 위반을 찾는 방법
설정
초기 설정은 다음과 같이 설계되었습니다.
- Google Cloud 조직
- 조직에 속한 폴더 이 Codelab에서는 이름을
codelab-folder
이라고 합니다. - 두 개의 Google Cloud 프로젝트가 동일한 폴더(
codelab-folder
)에 배치되어 있습니다. 이 Codelab에서는project-1
및project-2
라고 합니다.- 폴더와 프로젝트를 아직 만들지 않았다면 Google Cloud 콘솔에서 조직 아래에 폴더를 만들고 생성된 폴더 아래에 새 프로젝트 2개를 만듭니다.
- 필수 권한은 다음과 같습니다.
- 폴더 관리를 위한 IAM 역할: 폴더 수준에서 할당됨
- 프로젝트 관리를 위한 IAM 역할: 프로젝트 수준에서 할당
- VPC 서비스 제어를 구성하는 데 필요한 IAM 역할: 조직 수준에서 할당
- BigQuery 관리를 위한 IAM 역할: 프로젝트 수준에서 할당됨
- Compute Engine 인스턴스 관리를 위한 IAM 역할: 프로젝트 수준에서 할당됨
project-2
및project-1
프로젝트 모두의 결제 계정입니다.
일반 서비스 경계 만들기
이 Codelab에서는 project-1
를 보호하는 일반 서비스 경계를 사용합니다.
- 일반 경계,
perimeter-1
를 만들고project-1
를 추가합니다.
Compute Engine VM 만들기
이 Codelab에서는 us-central1
에 있고 default
라는 기본 VPC 네트워크를 사용하는 project-2
에 Compute Engine 인스턴스 1개를 사용합니다.
- 이 문서를 공개 이미지를 사용하여 Compute Engine 인스턴스를 만드는 가이드라인으로 참조할 수 있습니다.
비용
클라우드 리소스/API를 사용하려면 Google Cloud 콘솔에서 결제를 사용 설정해야 합니다. 이 Codelab 이후에는 요금이 청구되지 않도록 사용된 리소스를 종료하는 것이 좋습니다. 신규 Google Cloud 사용자는 $300(USD) 상당의 무료 체험판 프로그램을 이용할 수 있습니다.
비용이 발생하는 리소스는 BigQuery와 Compute Engine 인스턴스입니다. BigQuery 가격 계산기와 Compute Engine 가격 계산기를 사용하여 비용을 추정할 수 있습니다.
3. VPC 서비스 제어 제한사항 없이 BigQuery에 액세스
project-1
에 공개 데이터 세트 쿼리 및 결과 저장
project-2
및project-1
에 액세스하여 BigQuery Studio 페이지로 이동하여 BigQuery API에 액세스할 수 있는지 확인합니다.project-1
가 서비스 경계에 있더라도 경계가 아직 서비스를 보호하지 않으므로 이렇게 할 수 있습니다.project-2
에서 다음 쿼리를 실행하여 공개 데이터 세트를 쿼리합니다.
SELECT name, SUM(number) AS total
FROM `bigquery-public-data.usa_names.usa_1910_2013`
GROUP BY name
ORDER BY total DESC
LIMIT 10;
공개 데이터 세트에 대한 쿼리를 실행한 후 (project-2
에 남아 있는 동안):
- 결과 저장을 클릭하고 BigQuery 테이블을 선택합니다. (아래 스크린샷 참조)
project-1
를 대상 프로젝트로 선택합니다.- 데이터 세트 이름을
codelab_dataset
로 지정합니다. (기존 데이터 세트를 사용하지 않는 경우 새 데이터 세트 만들기를 선택합니다.) <ph type="x-smartling-placeholder"></ph>
- 테이블 이름을
codelab-table
로 지정합니다. - 저장을 클릭합니다.
project-2
에서 쿼리를 실행한 결과로 공개 데이터 세트 데이터가 project-1
에 저장되었습니다.
project-2
에서 project-1
에 저장된 쿼리 데이터 세트
project-2
BigQuery Studio에서 다음 쿼리를 실행하여 데이터를 선택합니다.
- 프로젝트:
project-1
- 데이터 세트:
codelab_dataset
- 테이블:
codelab-table
SELECT name, total
FROM `project-1.codelab_dataset.codelab-table`
ORDER BY total DESC
LIMIT 10;
project-2
및 project-1
모두 BigQuery를 사용하도록 제한되지 않으므로 쿼리가 성공적으로 실행됩니다. 사용자에게 적절한 IAM 권한이 있으면 어디서나 BigQuery에 액세스할 수 있습니다.
이 다이어그램은 주 구성원이 BigQuery 데이터 세트를 쿼리하는 프로세스를 보여줍니다. 각 BigQuery 쿼리는 BigQuery 작업을 시작한 다음 실제 작업(이 시나리오에서는 데이터 검색)을 수행합니다. 공개 데이터 세트 및 별도의 Google Cloud 프로젝트에서 쿼리하는 동안 주 구성원 액세스는 Compute Engine 인스턴스와 인터넷에서 입증됩니다. 데이터 쿼리 프로세스 (
GetData
)가 VPC 서비스 제어에 의해 차단되지 않고 성공했습니다.
4. 소스 데이터 세트 프로젝트에서 BigQuery API 보호
경계 perimeter-1
의 구성을 수정하고 project-1
인 보호된 리소스와 함께 BigQuery API 서비스를 제한합니다.
서비스 경계 적용 확인
project-2
가 있는 경우 이전 단계와 마찬가지로 BigQuery Studio에서 다음 쿼리를 실행합니다.
SELECT name, total
FROM `project-1.codelab_dataset.codelab-table`
ORDER BY total DESC
LIMIT 10;
VPC 서비스 제어 RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER
위반이 발생합니다.
경계를 넘는 위반이 발생한 project-1
에 위반 감사 로그가 있습니다. 관찰된 vpcServiceControlsUniqueId
로 로그를 필터링할 수 있습니다 (VPC_SC_DENIAL_UNIQUE_ID
를 관찰된 고유 ID로 바꿈).
severity=ERROR
resource.type="audited_resource"
protoPayload.metadata.@type="type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
protoPayload.metadata.vpcServiceControlsUniqueId="[*VPC_SC_DENIAL_UNIQUE_ID*]"
위반사항은 다음과 같은 egressViolations
입니다.
principalEmail
: [쿼리를 실행하는 사용자 계정]callerIp
: [쿼리를 실행하는 사용자 에이전트의 IP 주소]
"egressViolations": [
{
"targetResource": "projects/project-2",
"sourceType": "Resource",
"source": "projects/project-1",
"servicePerimeter": "accessPolicies/REDACTED/servicePerimeters/perimeter-1",
"targetResourcePermissions": [ "bigquery.jobs.create"]
} ],
5. 위반사항 해결로 BigQuery 작업 만들기
이 다이어그램은 주 구성원이
project-1
의 데이터 세트에 대해 project-2
에서 쿼리를 실행하는 경우를 보여줍니다. 쿼리가 실행되는 프로젝트 (project-2
)의 데이터 세트 프로젝트 (project-1
)에서 BigQuery 작업을 만드는 작업이 BigQuery API를 보호하는 서비스 경계 perimeter-1
로 인해 VPC 서비스 제어 이그레스 위반으로 인해 실패합니다. 경계가 설정되어 있으면 project-1
에서 경계 외부로 또는 경계 외부에서 보호된 프로젝트를 향해 BigQuery API 요청을 시작할 수 없습니다. 서비스 경계 구성에서 허용되지 않는 한
이그레스 위반은 다음을 기반으로 하는 이그레스 규칙을 만들어 해결할 수 있습니다.
- 소스 (FROM): 즉, 사용자 이메일 주소 및 컨텍스트 (예: 발신자 IP 주소, 기기 상태, 위치 등)
- 대상 (TO): 즉, 대상 리소스, 서비스, 메서드 또는 권한을 정의합니다.
관찰된 이그레스 위반을 해결하려면 BigQuery 서비스에서 쿼리 (user@example.com
)를 실행하는 사용자 계정 및 bigquery.jobs.create
메서드/ 권한에서 targetResource (project-2
)로 향하는 트래픽을 허용하는 이그레스 규칙을 만듭니다.
구성된 이그레스 규칙의 예상 동작:
- FROM | ID: 지정된 ID
user@example.com
만 경계 경계를 넘을 수 있어야 합니다. - 변경 후 | 프로젝트: 대상이 지정된 프로젝트
project-2
인 경우에만 지정된 ID가 경계를 넘을 수 있습니다. - 변경 후 | 서비스: 지정된 ID가 지정된 서비스 및 메서드에 대한 API 호출인 경우에만 경계 외부에서 지정된 프로젝트로 트래픽을 시작할 수 있습니다. 그러지 않으면, 예를 들어 서비스 경계로 보호되는 다른 서비스를 시도하는 경우 다른 서비스가 허용되지 않기 때문에 작업이 차단됩니다.
해결 방법 테스트: 이그레스 규칙
이그레스 규칙이 준비되면 동일한 쿼리를 실행합니다.
SELECT name, total
FROM `project-1.codelab_dataset.codelab-table`
ORDER BY total DESC
LIMIT 10;
또 다른 위반이 발생합니다. 이번에는 NO_MATCHING_ACCESS_LEVEL
인그레스 위반입니다. 새 위반은 대상 프로젝트 및 방법 측면에서 첫 번째 위반과 다릅니다.
새로운 위반은
principalEmail
: [쿼리를 실행하는 사용자 계정]callerIp
: [쿼리를 실행하는 사용자 에이전트의 IP 주소]
ingressViolations: [
0: {
servicePerimeter: "accessPolicies/REDACTED/servicePerimeters/perimeter-1"
targetResource: "projects/project-1"
targetResourcePermissions: [0: "bigquery.tables.getData"]}
]
bigquery.tables.getData
메서드에 대한 위반은 BigQuery 테이블에서 데이터를 가져오려고 시도하는 BigQuery 작업에서 시작된 API 호출로 인해 발생합니다.
6. BigQuery 테이블 데이터 가져오기 관련 위반 해결
인그레스 규칙은 소스/ 대상 프로젝트, 액세스할 수 있는 API 메서드와 같은 허용된 액세스 컨텍스트와 함께 서비스 경계 경계를 넘을 수 있는 사용자에 대한 세부적인 제어를 제공하는 동시에 인그레스 위반을 수정합니다.
인그레스 위반은 다음과 같이 구성된 인그레스 규칙으로 해결됩니다.
- 소스 (FROM): 즉, 사용자 이메일 주소 및 컨텍스트 (예: 발신자 IP 주소, 기기 상태, 위치 등)
- 대상 (TO): 즉, 대상 리소스, 서비스, 메서드 또는 권한을 정의합니다.
인그레스 규칙은 지정된 서비스 및 메서드에서 지정된 사용자가 project-1
으로 향하는 트래픽을 허용합니다.
구성된 인그레스 규칙의 예상 동작:
- FROM | ID: 지정된 ID
user@example.com
만 경계 경계를 넘을 수 있어야 합니다. - 변경 후 | 프로젝트: 대상이 지정된 프로젝트
project-1
인 경우에만 지정된 ID가 경계를 넘을 수 있습니다. - 변경 후 | 서비스: 지정된 ID가 BigQuery API 및 지정된 메서드
bigquery.tables.getData
에 대한 API 호출인 경우에만 경계 내에서 트래픽을 시작할 수 있습니다.
따라서 VPC 서비스 제어 위반 없이 동일한 쿼리를 실행하면 적절하게 작동해야 합니다.
user2@example.com
가 아닌 user@example.com
에서만 BigQuery API를 사용할 수 있도록 project-1
에서 BigQuery API를 제한했습니다.
이 다이어그램은 두 명의 주 구성원이 동일한 데이터 세트를 쿼리하는 방식을 보여줍니다.
user2@example.com
(파란색 점선)의 액세스는 서비스 경계 구성에 따라 project-1
에서 BigQuery 작업을 실행할 수 없으므로 VPC 서비스 제어에서 거부되었습니다. user@example.com
(녹색 실선)의 액세스는 VPC 서비스 제어 구성에서 허용되고 project-1
에 대한 작업을 수행할 수 있기 때문에 성공한 것입니다.
7. 내부 IP 주소를 기반으로 서비스 경계에서 허용하는 트래픽 제한
현재 구성을 사용하면 지정된 사용자가 어디서나 project-1
의 BigQuery에 대해 쿼리를 실행할 수 있습니다. 액세스 권한을 받을 수 있습니다. 보안 관점에서 이는 계정이 도용된 경우 계정에 대한 액세스 권한을 얻은 모든 개인이 추가 제한 없이 BigQuery 데이터에 액세스할 수 있음을 의미합니다.
인그레스 및 이그레스 규칙에서 액세스 수준을 활용하여 사용자 컨텍스트를 지정하여 추가 제한을 구현할 수 있습니다. 예를 들어 호출자 ID에 의한 액세스를 승인하는 이전에 구성된 인그레스 규칙과 함께 소스 IP 기반 액세스를 허용할 수 있습니다. 소스 IP별 액세스는 두 공개 IP CIDR 범위 모두에 대해 가능합니다. 단, 사용자 클라이언트에 할당된 공개 IP가 있거나 사용자 클라이언트가 Google Cloud 프로젝트에서 작동하는 경우 내부 IP 주소를 채택하면 됩니다.
내부 IP 주소 액세스 조건이 있는 액세스 수준 만들기
동일한 범위가 지정된 액세스 정책 폴더에서 Access Context Manager 페이지를 열어 액세스 수준을 만듭니다.
- Access Context Manager 페이지에서 액세스 수준 만들기를 선택합니다.
- 새 액세스 수준 창에서 다음을 수행합니다.
- 제목을 입력합니다.
codelab-al
을 사용할 수 있습니다. - 조건 섹션에서 IP 서브네트워크를 클릭합니다.
- 비공개 IP 탭을 선택하고 VPC 네트워크 선택을 클릭합니다.
- VPC 네트워크 추가 창에서
default
네트워크를 찾아보거나//compute.googleapis.com/projects/project-2/global/networks/default
형식으로 전체 네트워크 이름을 수동으로 입력할 수 있습니다. - VPC 네트워크 추가를 클릭합니다.
- IP 서브네트워크 선택을 클릭합니다.
- VM 인스턴스가 있는 리전을 선택합니다. 이 Codelab에서는
us-central1
입니다. - 저장을 클릭합니다.
- 제목을 입력합니다.
경계 또는 인그레스/이그레스 정책에 아직 시행되지 않는 액세스 수준을 생성했습니다.
인그레스 규칙에 액세스 수준 추가
인그레스 규칙에서 허용하는 사용자가 액세스 수준에 대해서도 확인되도록 하려면 인그레스 규칙에서 액세스 수준을 구성해야 합니다. 쿼리 데이터에 대한 액세스를 승인하는 인그레스 규칙은 perimeter-1
에 있습니다. 인그레스 규칙을 변경하여 소스를 액세스 수준 codelab-al
으로 정의합니다.
새 구성 테스트
인그레스 규칙에 액세스 수준을 추가하면 project-2
프로젝트의 VPC 네트워크 default
에 있는 클라이언트에서 동일한 BigQuery 쿼리를 실행하지 않으면 동일한 BigQuery 쿼리가 실패합니다. 이 동작을 확인하려면 엔드포인트 기기가 인터넷에 연결된 상태에서 Google Cloud 콘솔에서 쿼리를 실행합니다. 쿼리가 종료되지 않고 인그레스 위반임을 나타냅니다.
동일한 쿼리를 project-2
에 있는 VPC 네트워크 default
에서 실행할 수 있습니다. 마찬가지로, default
VPC 네트워크를 사용하는 project-2
에 위치한 Compute Engine 인스턴스에서 동일한 BigQuery 쿼리를 실행하는 것도 실패합니다. 이는 인그레스 규칙이 여전히 주 구성원 user@example.com
만 허용하도록 구성되어 있기 때문입니다. 하지만 VM은 Compute Engine 기본 서비스 계정을 사용합니다.
project-2
의 Compute Engine 인스턴스에서 동일한 명령어를 성공적으로 실행하려면 다음을 확인하세요.
- VM에 BigQuery API를 사용할 수 있는 액세스 범위가 있습니다. 이렇게 하려면 VM 액세스 범위로 모든 Cloud API에 대한 전체 액세스 허용을 선택하면 됩니다.
- VM에 연결된 서비스 계정에는 다음을 수행할 IAM 권한이 필요합니다.
project-2
에서 BigQuery 작업 만들기project-1
에 있는 BigQuery 테이블에서 BigQuery 데이터를 가져옵니다.
- 기본 Compute Engine 서비스 계정은 인그레스 및 이그레스 규칙에서 허용해야 합니다.
이제 인그레스 규칙 (BigQuery 테이블에서 데이터 가져오기 허용)과 이그레스 규칙 (BigQuery 작업 생성 허용)에 Compute Engine 기본 서비스 계정을 추가해야 합니다.
default
VPC 네트워크의 project-2
에 있는 Compute Engine 인스턴스에서 다음 bq query 명령어를 실행합니다.
bq query --nouse_legacy_sql \
'SELECT name, total
FROM `project-1.codelab_dataset.codelab-table`
ORDER BY total DESC
LIMIT 10;'
현재 구성에서는 다음과 같은 경우에만 BigQuery 명령어가 성공합니다.
project-2
의 기본 VPC 네트워크를 사용하여 VM에서 실행- 지정된
us-central1
리전 (IP 서브네트워크)에 있음 - 서비스 경계에 구성된 기본 Compute Engine 서비스 계정을 사용하여 실행됩니다.
다음을 포함한 다른 위치에서 실행하면 BigQuery 명령어 쿼리가 실패합니다.
project-2
의 기본 VPC 네트워크를 사용하는 VM에서 실행되었지만 액세스 수준에서 추가된 서브넷과 다른 리전에 있는 경우- 사용자
user@example.com
가 인터넷의 사용자 클라이언트를 통해 실행하는 경우
이 다이어그램은 서로 다른 두 위치(인터넷 및 Compute Engine 인스턴스)에서 동일한 주 구성원(
user@example.com
)이 시작한 액세스를 보여줍니다. 인터넷에서 직접 BigQuery에 액세스하는 것 (파란색 점선)은 VPC 서비스 제어에 의해 차단되지만, Compute Engine 기본 서비스 계정을 가장한 상태에서 VM (녹색 실선)에서는 액세스가 허용됩니다. 내부 IP 주소에서 보호된 리소스에 액세스할 수 있도록 구성된 서비스 경계로 인해 액세스가 허용됩니다.
8. 삭제
서비스를 사용하지 않을 때 VPC 서비스 제어를 사용하는 데 별도의 요금은 청구되지 않지만 이 실습에서 사용한 설정을 정리하는 것이 좋습니다. VM 인스턴스와 BigQuery 데이터 세트 또는 Google Cloud 프로젝트를 삭제하여 요금이 청구되지 않도록 할 수도 있습니다. Cloud 프로젝트를 삭제하면 프로젝트 내에서 사용되는 모든 리소스에 대한 청구가 중지됩니다.
- VM 인스턴스를 삭제하려면 다음 단계를 완료하세요.
- Google Cloud 콘솔에서 VM 인스턴스 페이지로 이동합니다.
- VM 인스턴스 이름 왼쪽에 있는 체크박스를 선택하고 삭제를 선택한 후 삭제를 다시 클릭하여 확인합니다. <ph type="x-smartling-placeholder">
</ph>
- 서비스 경계를 삭제하려면 다음 단계를 완료하세요.
- Google Cloud 콘솔에서 보안을 선택한 다음 액세스 정책의 범위가 지정된 수준(이 경우 폴더 수준)에서 VPC 서비스 제어를 선택합니다.
- VPC 서비스 제어 페이지에서 삭제하려는 경계에 해당하는 표의 행에 있는 삭제를 클릭합니다.
- 액세스 수준을 삭제하려면 다음 단계를 완료하세요.
- Google Cloud 콘솔의 폴더 범위에서 Access Context Manager 페이지를 엽니다.
- 그리드에서 삭제하려는 액세스 수준의 행을 식별하고 점 3개로 된 메뉴를 선택한 다음 삭제를 선택합니다.
- 프로젝트를 종료하려면 다음 단계를 완료하세요.
- Google Cloud 콘솔에서 IAM 및 관리자 설정 페이지를 클릭합니다.
- IAM 및 관리자 설정 페이지에서 종료를 선택합니다.
- 프로젝트 ID를 입력하고 무시하고 종료를 선택합니다.
9. 축하합니다.
이 Codelab에서는 VPC 서비스 제어 경계를 만들고 적용하고 문제를 해결했습니다.
자세히 알아보기
다음 시나리오도 살펴볼 수 있습니다.
- 프로젝트가 VPC 서비스 제어로 보호되면 공개 데이터 세트에서 동일한 쿼리를 실행합니다.
project-1
와 동일한 경계에project-2
를 추가합니다.- 자체 경계에
project-2
를 추가하고 현재 경계에project-1
를 유지합니다. - 쿼리를 실행하여 데이터를 가져오는 것뿐만 아니라 테이블의 데이터를 업데이트합니다.
라이선스
이 작업물은 Creative Commons Attribution 2.0 일반 라이선스에 따라 사용이 허가되었습니다.