이 문서에서는 액세스 수준 구현을 설명하고 허용 목록을 기준으로 서비스 경계 적용을 시작하기 위한 권장사항을 제공합니다.
워크로드의 테스트 실행 실행을 완료하면 허용 목록에 추가해야 하는 IP 주소와 ID의 목록이 표시됩니다. 일부 워크로드에는 기기 기반의 허용 목록이 필요할 수도 있습니다. 보호되는 Google Cloud 리소스에 대해 액세스 권한을 부여하려면 VPC 서비스 제어 액세스 수준을 사용하면 됩니다. 액세스 수준을 구현할 수 있는 실용적인 방법은 IP 주소, ID 또는 기기를 기반으로 합니다.
자세한 내용은 인그레스 규칙을 사용한 컨텍스트 인식 액세스를 참조하세요.
소스 IP를 기반으로 액세스 권한 부여
IP 기반 허용 목록의 액세스 수준에서는 공개 IP CIDR 범위만 사용할 수 있습니다. 이 메서드는 이 IP 범위에서 보호되는 모든 API를 허용하므로 이러한 IP를 지원하는 환경은 신뢰 및 제어가 가능해야 합니다. 이 허용 목록에 대한 일반적인 사용 방법은 온프레미스 네트워크에서 경계 액세스를 허용하는 것입니다. 다음 다이어그램은 IP 기반 허용 목록이 경계 액세스를 차단하고 허용하는 방법을 보여줍니다.
앞의 다이어그램에서 유효한 ID는 경계에 액세스를 시도합니다. 액세스 시도는 액세스 시도가 인터넷 IP 주소에서 시작되면 거부됩니다. 단, 회사의 공개 IP 주소에서 시작되는 경우 액세스가 허용됩니다.
이 시나리오의 변형은 다른 프로젝트 또는 조직에 배포된 비공개 리소스의 경계 액세스를 허용하는 경우입니다. 이 사용 사례에서는 소스 프로젝트에 Cloud NAT 게이트웨이가 필요합니다.
Cloud NAT는 비공개 Google 액세스와 통합되어 리소스의 서브넷에서 비공개 Google 액세스를 자동으로 사용 설정하고 Cloud NAT 게이트웨이 외부 IP 주소를 사용하여 트래픽을 인터넷으로 라우팅하는 대신 Google API 및 서비스로의 트래픽을 내부로 유지합니다.
트래픽이 내부 Google 네트워크 내에서 라우팅되므로 AuditLog 객체의 RequestMetadata.caller_ip 필드가 gce-internal-ip로 수정됩니다. 이 경우 경계 액세스를 허용하려면 외부 소스 IP 주소를 기반으로 액세스 수준을 구성하는 대신 프로젝트 또는 서비스 계정과 같은 다른 속성을 기반으로 액세스를 허용하도록 인그레스 규칙을 구성해야 합니다.
호출자 ID에 따라 액세스 권한 부여
ID 기반 허용 목록을 구현하려면 허용 목록에 서비스 계정과 조직 최고 관리자를 추가합니다. 모든 IP 주소에서 이 ID에 대한 경계가 열려 있으므로 ID가 올바르게 보호되도록 해야 합니다. 또한 허용 목록에 추가한 서비스 계정에 키를 발급하지 않도록 해야 합니다. 경계에서 사용자 ID를 허용 목록 (허용 목록에 추가할 수 없는 경우)에 추가하는 것은 드문 일입니다.
경계 내의 리소스는 경계 내의 VM, 신뢰할 수 있는 온프레미스 네트워크 또는 신뢰할 수 있는 기기를 통해 액세스할 수 있습니다. VPC 서비스 제어는 Cloud Shell을 지원하지 않으므로 경계 내의 리소스에 액세스하려면 Cloud Workstations를 사용하는 것이 좋습니다.
호출자 기기 속성에 따른 액세스 자격 부여
신뢰할 수 있는 엔드포인트라고도 하는 기기 트러스트는 Chrome 브라우저 또는 Chromebook에 로그인한 유효한 조직 사용자가 필요합니다. 트러스트는 OS 로그인 세션에 적용됩니다. 예를 들어 Chrome 세션에 로그인되어 있고 Windows 세션을 실행하는 Windows 사용자는 보호된 경계 API에서 gcloud CLI 명령어를 성공적으로 호출할 수 있습니다. 그러나 동일한 머신의 다른 Windows 사용자 세션은 보호된 경계 API에서 명령어를 호출할 수 없습니다.
다음은 기기 트러스트 설정에 도움이 되는 기기 조건입니다.
확인된 Chrome OS는 유효한 조직 사용자가 안전하게 부팅된 Chromebook에 로그인했음을 나타내는, 매우 안전하고 암호화로 확인된 조건입니다. 권장 Tier 1 트러스트 조건입니다.
기기 액세스에 관리자 승인 필요는 액세스 권한이 부여되기 전에 Cloud ID 관리자가 승인하는 것을 허용합니다. 기본적으로 유효한 조직 사용자가 로그인된 기기는 자동으로 승인됩니다. 하지만 자동 승인 옵션은 해제하는 것이 좋습니다.
기업 소유 기기 필요는 일반적으로 BIOS에서 제공하는 OS의 일련번호를 검색하는 Chrome 에이전트를 사용합니다. 이 번호는 Cloud ID에 입력한 기존 일련번호와 일치해야 합니다.
Chrome OS가 아닌 기기에서는 일련번호를 승인할 수 없으므로(관리자 권한이 높은 사용자가 일련번호를 스푸핑할 수 있음) 이 조건은 Tier 2 확인 용도로만 사용하는 것이 좋습니다.
앞의 목록에 설명된 조건에 따라 제어 액세스 권한을 부여하는 샘플 추적기는 VPC 서비스 제어 온보딩 템플릿 - 허용 목록(PDF)을 참조하세요.
시행 시작
허용 목록 설계 및 업데이트 수준을 설계한 후에는 워크로드를 다시 실행하여 위반사항이 없는지 확인하는 것이 좋습니다. 워크로드가 위반사항 없이 실행되는 경우 애플리케이션에 영향을 주지 않으면서 VPC 서비스 제어 시행을 시작할 수 있습니다.
시행을 계획할 때는 다음 사항을 고려하세요.
- 시행일을 선택하고 해당 날짜를 모든 관련 팀에 알립니다.
- 보안 운영팀과 이슈 대응팀에서 배포에 대해 알고 있어야 합니다. 또한 적절한 권한이 있는 개인이 로그를 검사하고 필요한 경우 추가 허용 목록을 승인해야 합니다.
- 질문이나 문제가 발생하면 상황 대응팀이 Google Cloud 지원 기록을 열 수 있는지 확인합니다.
- Terraform과 같은 자동화 도구를 사용하여 경계 및 액세스 수준을 만들거나 수정합니다. 이 작업은 수동으로 실행하지 않는 것이 좋습니다.
시행을 시작할 때는 단일 워크로드와 연결된 프로젝트를 테스트 실행 경계에서 라이브 경계로 먼저 이동합니다. 위반사항 로그를 확인하는 동안 애플리케이션이 올바르게 실행될 수 있도록 기다립니다. 나머지 워크로드의 프로세스를 한 번에 하나씩 반복합니다.
차단된 위반을 표시하려면 경계 내 모든 프로젝트의 감사 로그를 BigQuery로 전송하는 집계 로깅 싱크를 구성하세요. 그런 후 다음 쿼리를 실행합니다.
SELECT
receiveTimestamp, #time of violation
Resource.labels.service, #protected Google Cloud service being blocked
protopayload_auditlog.methodName, #method name being called
resource.labels.project_id as PROJECT, #protected project blocking the call
protopayload_auditlog.authenticationInfo.principalEmail, #caller identity
protopayload_auditlog.requestMetadata.callerIp, #caller IP
JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.dryRun') as DRYRUN, #dry-run indicator
JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.violationReason') as REASON, #reason for violation
protopayload_auditlog.metadataJson, #raw violation entry
FROM `BQ_DATASOURCE_NAME.cloudaudit_googleapis_com_policy_*`
WHERE JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.dryRun') is null #exclude logs from a dry-run perimeter
다음 단계
- 서비스 경계 외부에서 보호된 리소스에 액세스 허용하는 방법 알아보기
- 서비스 경계를 나열, 업데이트, 삭제하는 방법 알아보기