VPC 서비스 제어 사용 설정을 위한 권장사항

이 문서에서는 Google Cloud 조직에서 VPC 서비스 제어 보호를 구성하고 시행하기 위한 권장 프로세스를 설명합니다.

VPC 서비스 제어를 부주의하게 사용 설정하면 기존 애플리케이션에 문제가 발생할 수 있으며 서비스가 중단될 수 있습니다. 사용 설정 기간을 신중하게 계획하고, 데이터 수집, 테스트 수행, 위반 로그 분석에 필요한 시간을 충분히 확보하는 것이 좋습니다. VPC 서비스 제어 운영팀과 애플리케이션팀의 이해관계자가 작업을 진행할 수 있어야 합니다.

VPC 서비스 제어에 온보딩하는 워크로드 또는 애플리케이션마다 사용 설정 프로세스를 반복해야 합니다.

커뮤니케이션 조정

네트워크 보안 또는 클라우드 지원팀에서 VPC 서비스 제어 사용 설정을 주도하는 경우가 많습니다. 하지만 부서 간 회의를 조직 및 추적하고 작업 항목을 문서화하는 전담 직원이 있는 것이 좋습니다. 팀원들은 다음과 관련한 공동작업을 진행합니다.

Google Cloud API 액세스 패턴
서비스 경계 위반사항 식별
경계에 대한 액세스 허용

기존의 네트워크 방화벽과 마찬가지로 합법적인 비즈니스 워크로드의 효율적인 작동에 필요한 흐름을 식별하고 허용하는 것이 목적입니다.

문서 액세스 패턴 및 사용 사례

사용 설정 프로세스를 시작하려면 모든 유효한 액세스 패턴을 식별하고 명확하게 문서화하세요. 액세스 패턴은 경계 내부 및 외부의 요소 간에 반복 가능한 상호작용 유형입니다. 다음은 일반적인 액세스 패턴입니다.

데이터 액세스 패턴: 경계 외부의 서비스는 경계에 있는 데이터를 저장하거나 검색합니다.
리소스 액세스 패턴:
- 사용자는 Google Cloud Console을 통해 경계 안의 프로젝트에 액세스합니다.
- 제3자 도구 또는 서비스는 경계 내부의 리소스를 관리하고 액세스합니다.
- 경계 내 서비스 또는 리소스는 Google API에 액세스합니다.
엔드포인트 액세스 패턴:
- 사용자는 조직에서 관리하는 기기에서 경계 내의 리소스에 액세스합니다.
- 온프레미스 리소스는 경계 내의 리소스와 통신합니다.

워크로드의 액세스 패턴을 식별한 후에는 사용 사례를 파악하여 이전 목록의 액세스 패턴 중 하나로 분류합니다. 다음은 몇 가지 일반적인 사용 사례입니다.

클라우드 관리자는 경계에 속하는 프로젝트를 관리합니다.
경계 외부에 있는 Terraform, Jenkins, Microsoft Azure DevOps와 같은 자동화 서비스는 경계 내의 리소스 배포를 관리합니다.
경계 외부에 있는 Ansible, Chef 또는 Puppet과 같은 구성 관리 서비스는 경계 내에 있는 리소스의 소프트웨어 배포 및 구성을 관리합니다.
경계 외부에 있는 Forseti 또는 SIEM 같은 보안 모니터링 및 시행 서비스는 데이터를 사용하거나 경계 내부에 있는 리소스에 보안 정책을 시행합니다.

모든 사용 사례에 대해 다음 사항을 문서화하세요.

액세스 패턴
사용 사례를 트리거할 수 있는 행위자
사용 사례를 트리거하는 조건
사용 사례가 유효한 액세스 패턴이며 허용되어야 하는지 여부
사용 사례와 관련된 모든 가정

샘플 액세스 패턴 및 사용 사례 추적기는 VPC 서비스 제어 온보딩 템플릿 - 사용 사례(PDF)를 참조하세요.

인터뷰 진행

워크로드팀과 인터뷰를 진행하여 이전 커뮤니케이션 템플릿에서 수집한 액세스 패턴과 사용 사례를 논의합니다. 다음은 이러한 인터뷰 중에 물어볼 수 있는 질문의 예시입니다.

여러분의 사용 사례는 VPC 서비스 제어 사용 설정을 위해 고려해야 할 최우선순위인가요? 초기 사용 설정에는 우선순위가 가장 높은 워크로드만 고려하고 비즈니스에 중요한 리소스를 보호한 후에 덜 중요한 다른 워크로드를 온보딩하는 것이 좋습니다.
모든 사용 사례의 포괄적인 실행을 완료할 수 있나요? 이렇게 하면 가능한 경계 시나리오를 모두 트리거하여 경계를 완벽하게 적용한 후 애플리케이션이 올바르게 작동하는지 확인할 수 있습니다.
사용 사례 실행을 진행하는 데 시간이 얼마나 걸리나요?
VPC 서비스 제어 사용 설정과 충돌할 수 있는 이 워크로드에 주요 변경사항을 도입할 계획인가요? VPC 서비스 제어를 사용 설정하려면 워크로드 기능이 안정적인 상태여야 합니다.

테스트 실행 준비

테스트 실행 모드를 이용하면 애플리케이션 중단 없이 위반사항을 식별함으로써 VPC 서비스 제어 시행의 복잡성이 줄어듭니다. 모든 위반을 기록하지만 차단을 수행하지 않는 개별 경계로 테스트 실행을 구성하세요. 테스트 실행 경계에 있는 동안 워크로드를 실행하고 분석할 위반 로그를 생성할 수 있습니다.

테스트 실행 환경을 준비하려면 다음 안내를 따르세요.

경계에 포함될 자격이 있는 모든 프로젝트를 확인하고 해당 프로젝트의 사용 사례 및 인터뷰 프로세스를 완료합니다.
테스트 실행 경계를 만들고 모든 프로젝트를 추가합니다.
VPC 서비스 제어의 서비스 경계에서 제한된 서비스 > 보호할 서비스에 지원되는 모든 서비스를 추가합니다.
모든 로그를 BigQuery로 전송하는 집계 로깅 싱크를 만들거나 공동 BigQuery 데이터 세트로 테스트 실행 로그를 전송하는 각 프로젝트의 로그 싱크를 만듭니다. 이러한 로그 메시지를 쿼리하고 VPC 서비스 제어 위반을 식별하려면 SQL 쿼리를 사용하면 됩니다.

모든 관련 VPC 서비스 제어 로그 메시지가 포함된 로그 싱크를 만들려면 다음 필터를 사용합니다.
```
logName="projects/$PROJECT/logs/cloudaudit.googleapis.com%2Fpolicy"
```
보안 강화를 위해 지원되지 않는 서비스에 대한 액세스를 허용하지 않습니다. 제한된 서비스만 경계에서 작동하도록 경계를 구성합니다. 이렇게 하려면 액세스 가능한 서비스 목록을 RESTRICTED-SERVICES로 구성합니다.
허용된 공개 IP, ID, 신뢰할 수 있는 기기, 프로젝트 또는 VPC 네트워크의 목록이 이미 있으면 테스트 실행 경계에서 적용되는 인그레스 규칙 또는 액세스 수준에 추가합니다. 알려진 적법한 흐름을 허용하면 위반사항 로그 수를 줄일 수 있고 검토자가 실행 가능한 이벤트에 집중할 수 있습니다.
프로젝트의 VPC에 인터넷 또는 비공개 VIP에 대한 이그레스 경로가 없는지 확인합니다.
모든 VPC에 restricted.googleapis.com을 가리키는 *.googleapis.com DNS가 있는지 확인합니다.

사용 사례 실행

합의된 시간에 애플리케이션팀이 테스트 실행 경계 내의 프로젝트에서 워크로드를 실행하도록 합니다. Google API를 호출할 수 있는 모든 코드를 사용할 수 있도록 합니다. 테스트 실행이 완료되면 지정된 검토팀에서 위반사항 로그 분석을 진행할 수 있습니다.

위반사항 분석

테스트 실행 위반사항 로그에는 애플리케이션 위반으로 인해 ID 또는 IP 주소를 경계 허용 목록에 추가하는 등의 조치가 필요한지 결정하는 데 필요한 정보의 대부분이 포함되어 있습니다. 위반사항 데이터는 BigQuery 테이블 cloudaudit_googleapis_com_policy에 저장됩니다. 위반사항을 분석하는 기본 요소는 다음과 같습니다.

호출되는 보호된 서비스 및 API 메서드
요청을 차단한 경계 내부의 프로젝트
보호 대상 API를 호출하는 ID의 이메일
호출자의 IP 주소
위반 유형

다음은 모든 위반 세부정보를 반환한 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') = "true" #ensure these are dry-run logs

위반사항 로그 검토

위반 로그를 검토할 때 다음 사항이 참인지 판단합니다.

ID(이메일)가 보호된 API를 호출할 것으로 예상됩니까?
호출자가 경계 외부에서 API를 호출할 수 있도록 허용해야 합니까?

앞의 기준에 따라 ID, 기기, IP 주소, CIDR 범위, 프로젝트 또는 네트워크가 외부에서 경계에 액세스하도록 허용해야 하는지 판단하세요.

일부 항목의 IP 주소는 private일 수 있습니다. 이는 Google 자체 서비스 또는 경계 외부에 있는 프로젝트의 VPC에 의해 Google 네트워크에서 발생한 호출을 나타냅니다. 로그 싱크 작성자와 같은 Google 서비스의 경우 허용 목록에 Google 서비스 계정을 추가해야 합니다.

이메일이 없는 항목은 IAM 권한 부족으로 인해 거부된 읽기 전용 작업의 Cloud 감사 로그 수정 때문에 발생합니다. 이 경우 IP 주소와 리소스 이름을 사용하여 액세스 시도의 출처를 파악할 수 있습니다. 이러한 종류의 액세스 시도는 조직 외부의 사용자가 실수로 액세스한 것일 수 있습니다. 예를 들면 사용자가 이름이 비슷한 버킷을 잘못 입력한 경우입니다.

SERVICE_NOT_ALLOWED_FROM_VPC 위반 유형이 있으면 워크로드가 VPC 서비스 제어에서 지원되지만 보호된 API 목록에 추가되지 않은 서비스를 사용 중일 수 있습니다. 예를 들어 IAM이 이러한 위반을 초래한 경우 관리자는 다음 Google Cloud CLI 명령어를 실행하여 액세스 가능한 서비스 목록에 IAM을 추가해야 합니다.

gcloud access-context-manager perimeters update perimeter_test \
 --add-vpc-allowed-services=RESTRICTED-SERVICES,IAM.googleapis.com \
 --policy=1234567890

Looker Studio 대시보드를 만들어 위반사항을 검토할 수 있습니다. 자세한 내용은 Looker Studio로 Google Cloud 조직의 VPC 서비스 제어 위반 모니터링을 참조하세요. Looker Studio의 이전 이름은 데이터 스튜디오입니다.

다음 단계

서비스 경계에 대해 자세히 알아보기
서비스 경계 생성 방법 알아보기