서비스 경계의 테스트 실행 모드

VPC 서비스 제어를 사용할 때 서비스 경계가 생성되거나 수정될 때 환경에 미치는 영향을 확인하기 어려울 수 있습니다. 테스트 실행 모드를 사용하면 VPC 서비스 제어와 기존 환경의 경계에 대한 변경사항을 사용 설정할 경우의 영향을 더 잘 이해할 수 있습니다.

테스트 실행 모드에서는 경계 정책을 위반하는 요청이 거부되지 않고 로깅됩니다. 테스트 실행 모드를 사용하여 경계 구성을 테스트하고 리소스에 대한 액세스를 방지하지 않고 서비스 사용량을 모니터링할 수 있습니다. 일반적인 사용 사례는 다음과 같습니다.

기존 서비스 경계 변경이 미치는 영향을 확인할 수 있습니다.
새 서비스 경계가 미칠 영향을 미리 볼 수 있습니다.
서비스 경계 외부에서 시작된 보호되는 서비스에 대한 요청을 모니터링합니다. 예를 들어 특정 서비스에 대한 요청의 출처를 확인하거나 조직에서 예기치 않은 서비스 사용을 식별할 수 있습니다.
개발 환경에서 프로덕션 환경과 유사한 경계 아키텍처를 만듭니다. 이렇게 하면 프로덕션 환경에 변경 사항을 푸시하기 전에 서비스 경계로 인해 발생할 수 있는 문제를 식별하고 완화할 수 있습니다.

서비스 경계는 테스트 실행 모드만 사용할 수 있습니다. 또한 시행 및 테스트 실행 모드의 하이브리드를 사용하는 서비스 경계를 가질 수도 있습니다.

테스트 실행 모드의 이점

테스트 실행 모드를 사용하면 새 서비스 경계를 만들거나 기존 환경에 영향을 주지 않고 여러 기존 경계를 변경할 수 있습니다. 새 경계 구성을 위반하는 요청은 차단되지 않습니다. 또한 사용 중인 모든 서비스가 VPC 서비스 제어와 통합되지 않은 환경에서 경계의 영향을 이해할 수도 있습니다.

거부에 대한 VPC 서비스 제어 로그를 분석하고 구성을 변경하여 잠재적인 문제를 해결한 다음 새로운 보안 상태를 적용할 수 있습니다.

경계 구성 문제를 해결할 수 없는 경우 경계의 테스트 실행 구성을 유지하고 유출 시도를 나타낼 수 있는 예기치 않은 거부가 있는지 모니터링할 수 있습니다. 하지만 경계에 대한 요청은 거부되지 않습니다.

테스트 실행 모드 개념

테스트 실행 모드는 경계 구성의 두 번째 평가 패스로 작동합니다. 기본적으로 모든 서비스 경계에 적용된 모드 구성은 테스트 실행 모드 구성으로 상속됩니다. 이 구성은 적용되는 서비스 경계 작업에 영향을 주지 않고 구성을 수정하거나 삭제할 수 있습니다.

테스트 실행 모드는 시행 모드 구성을 상속하므로 각 단계에서 두 구성이 모두 유효해야 합니다. 특히, 프로젝트는 실행 구성 내 하나의 경계와 테스트 실행 구성 내 하나의 경계에만 있을 수 있습니다. 따라서 경계 간에 프로젝트를 이동하는 등 여러 경계에 걸쳐있는 변경 사항은 적절한 순서로 순서를 지정해야 합니다.

테스트 실행 모드는 다음 기준을 모두 충족하는 경우에만 요청을 로깅합니다.

경계의 강제 구성에 의해 요청이 아직 거부되지 않습니다.
요청이 경계의 테스트 실행 구성을 위반합니다.

예를 들어 동일한 테스트 실행 및 시행 모드 구성이 Cloud Storage 버킷을 제한하는 경우 시행 모드는 Cloud Storage 버킷에 대한 요청을 차단하고 로깅합니다. 테스트 실행 모드는 시행 모드와 비교하여 위반의 차이점만 로깅합니다.

테스트 실행 구성만 있는 경계를 만들 수도 있습니다. 이를 통해 환경에서 새로운 시행된 경계의 영향을 시뮬레이션할 수 있습니다.

정책 시맨틱스

다음 섹션에서는 시행 모드와 테스트 실행 모드 간의 정책 관계와 해결 방법을 설명합니다.

고유한 멤버십 제약조건

Google Cloud 프로젝트는 하나의 강제 구성과 하나의 테스트 실행 구성에만 포함될 수 있습니다. 그러나 강제 실행 및 테스트 실행 구성은 동일한 경계에 필요하지 않습니다. 이렇게 하면 현재 프로젝트에 적용된 보안을 손상시키지 않고 한 경계에서 다른 경계로 프로젝트를 이동하는 효과를 테스트할 수 있습니다.

예시

corp-storage 프로젝트는 현재 경계 PA의 강제 구성으로 보호됩니다. corp-storage를 경계 PB로 이동했을 때의 영향을 테스트하려고 합니다.

PA의 테스트 실행 구성이 아직 수정되지 않았습니다. 테스트 실행 구성은 수정되지 않으므로 적용된 구성의 corp-storage를 상속합니다.

영향을 테스트하려면 먼저 PA의 테스트 실행 구성에서 corp-storage를 삭제하고 PB의 테스트 실행 구성에 프로젝트를 추가합니다. 프로젝트는 한 번에 하나의 테스트 실행 구성에만 있을 수 있으므로 먼저 PA의 테스트 실행 구성에서 corp-storage를 삭제해야 합니다.

corp-storage를 PA에서 PB로 마이그레이션해도 보안 상태에 부정적인 영향을 미치지 않는다고 판단되면 변경 사항을 적용하기로 결정합니다.

경계 PA 및 PB를 변경하는 방법에는 두 가지가 있습니다.

PA의 강제 구성에서 corp-storage를 수동으로 제거하고 PB의 강제 구성에 프로젝트를 추가할 수 있습니다. corp-storage는 한 번에 하나의 강제 구성만 있을 수 있으므로 이 순서대로 단계를 수행해야 합니다.

-또는-
gcloud 명령줄 도구 또는 Access Context Manager API를 사용하여 모든 테스트 실행 구성을 적용할 수 있습니다. 이 작업은 경계의 모든 수정된 테스트 실행 구성에 적용되므로 경계의 테스트 실행 구성을 수정한 조직의 다른 사용자와 작업을 조정할 수 있습니다. PA에 대한 테스트 실행 구성은 이미 corp-storage을 제외하므로 추가 단계가 필요하지 않습니다.

경계의 강제 구성이 먼저 실행됩니다.

경계의 강제 구성에서 허용되지만 테스트 실행 구성에서 거부된 요청만 테스트 실행 정책 위반으로 로깅됩니다. 강제 구성에서 거부되었지만 테스트 실행 구성에서 허용되는 요청은 로깅되지 않습니다.

액세스 수준에 상응하는 테스트 실행 모드가 없습니다.

경계에 대한 테스트 실행 구성을 만들 수 있지만 액세스 수준에는 테스트 실행 구성이 없습니다. 실제로 액세스 수준 변경이 테스트 실행 구성에 미치는 영향을 테스트하려면 다음을 수행해야 합니다.

기존 액세스 수준의 변경 사항을 반영하는 액세스 수준을 만듭니다.
경계의 테스트 실행 구성에 새 액세스 수준을 적용합니다.

테스트 실행 모드는 보안에 부정적인 영향을 미치지 않습니다.

경계에 새 프로젝트 또는 액세스 수준을 추가하거나 경계 내의 네트워크에서 보호하거나 액세스할 수 있는 서비스 변경과 같은 경계의 테스트 실행 구성 변경은 경계의 실제 적용에 영향을 미치지 않습니다.

예를 들어 서비스 경계 PA에 속하는 프로젝트가 있다고 가정해 보겠습니다. 프로젝트가 다른 경계의 테스트 실행 구성에 추가되어 있으면 프로젝트에 적용되는 실제 보안은 변경되지 않습니다. 프로젝트는 예상대로 경계 PA의 강제 구성으로 계속 보호됩니다.

테스트 실행 작업 및 구성 상태

테스트 실행 기능을 사용하여 다음을 수행할 수 있습니다.

테스트 실행 구성만으로 경계 만들기
기존 경계의 테스트 실행 구성 업데이트
새 프로젝트를 기존 경계로 이동
한 경계에서 다른 경계로 프로젝트 이동
경계의 테스트 실행 구성 삭제

테스트 실행 모드에서 수행 한 작업에 따라 경계는 다음 구성 상태 중 하나일 수 있습니다.

시행에서 상속됨: 시행 경계의 기본 상태입니다. 이 상태에서는 경계의 강제 구성에 대한 변경 사항이 테스트 실행 구성에도 적용됩니다.

수정됨: 경계의 테스트 실행 구성을 보거나 변경한 후 저장합니다. 이 상태에서는 경계의 시행된 구성 변경사항이 테스트 실행 구성에 적용되지 않습니다.

신규: 경계에 테스트 실행 구성만 있습니다. 테스트 실행 구성이 변경되더라도 이 경계가 시행될 때까지 상태가 신규로 유지됩니다.

삭제됨: 경계의 테스트 실행 구성이 삭제되었습니다. 이 상태는 경계에 대한 새로운 테스트 실행 구성을 만들거나 작업을 실행 취소할 때까지 유지됩니다. 이 상태에서는 경계의 시행된 구성 변경사항이 테스트 실행 구성에 적용되지 않습니다.

테스트 실행 모드의 제한사항

테스트 실행 모드는 경계에만 적용됩니다. Google Cloud API 액세스를 제한된 공개 또는 비공개 VIP로 제한하는 경우 이 문제를 파악할 수 없습니다. restricted.googleapis.com 도메인을 구성하기 전에 사용하려는 모든 서비스를 제한된 VIP에서 사용할 수 있는지 확인하는 것이 좋습니다.

기존 환경에서 사용 중인 API가 제한된 VIP에서 지원되는지 확실하지 않으면 비공개 VIP를 사용하는 것이 좋습니다. 지원되는 서비스에 경계 보안을 적용할 수도 있습니다. 하지만 비공개 VIP를 사용하는 경우 네트워크 내의 항목은 Gmail 및 드라이브의 일반 버전과 같이 비보안 서비스(VPC 서비스 제어에서 지원하지 않는 서비스)에 액세스할 수 있습니다. 비공개 VIP는 VPC 서비스 제어에서 지원하지 않는 서비스를 허용하므로 손상된 코드, 멀웨어 또는 네트워크 내 악의적인 사용자가 해당 보안 서비스를 사용하지 않는 데이터를 유출할 수 있습니다.