서비스 경계 설계

이 문서에서는 권장되는 VPC 서비스 제어 배포 아키텍처를 설명합니다. 이 문서는 Google Cloud에서 대규모 프로덕션 규모의 배포를 실행 및 운영하고 민감한 정보 손실의 위험을 완화하려는 네트워크 관리자, 보안 설계자, 클라우드 운영 전문가를 대상으로 작성되었습니다.

VPC 서비스 제어 보호는 클라우드 서비스 기능에 영향을 주기 때문에 VPC 서비스 제어의 사용 설정을 사전에 계획하고 아키텍처 설계 중에 VPC 서비스 제어를 고려하는 것이 좋습니다. VPC 서비스 제어 설계는 최대한 단순하게 유지해야 합니다. 다중 브리지, 경계 네트워크 프로젝트(DMZ 경계라고도 함) 및 복잡한 액세스 수준을 사용하는 경계 설계를 피하는 것이 좋습니다.

공통 통합 경계 사용

공통 통합 경계라고 하는 하나의 큰 경계는 데이터 무단 반출에 대한 가장 효과적인 보호 조치를 제공하기 때문에 세분화된 경계를 여러 개 사용하는 것보다 보호 효과가 우수합니다.

공통 통합 경계는 경계 생성 및 유지보수를 담당하는 팀의 관리 오버헤드가 줄어드는 이점을 제공합니다. 경계 내의 서비스와 네트워크 리소스가 필요한 IAM 및 네트워크 제어 권한을 사용해 자유롭게 통신할 수 있으므로 경계 관리를 담당하는 팀이 인터넷에서 경계 내부 리소스로 액세스하는 North-South 액세스에 주로 집중하게 됩니다.

조직에서 여러 개의 작은 경계를 사용하는 경우 경계 관리팀에서 조직 외부의 North-South 트래픽 외에도 조직 경계 간 East-West 트래픽을 관리하는 데 리소스를 할애해야 합니다. 조직의 크기와 경계 수에 따라 이 오버헤드가 상당히 클 수 있습니다. VPC 네트워크의 리소스에 직접 인터넷 이그레스가 없도록 하는 등 추가 보안 제어 및 권장사항을 사용하여 경계를 계층화하는 것이 좋습니다.

서비스 경계는 IAM 제어의 필요성을 대체하거나 줄이기 위한 것이 아닙니다. 액세스 제어를 정의할 때는 최소 권한의 원칙을 따르고 IAM 권장사항을 적용하는 것이 좋습니다.

자세한 내용은 서비스 경계 만들기를 참조하세요.

한 조직에 여러 경계 사용

사용 사례에 따라서는 한 조직에 여러 경계가 필요할 수 있습니다. 예를 들어 의료 데이터를 처리하는 조직에서는 신뢰도가 높고 난독화되지 않은 데이터를 위한 경계를 하나 사용하고 신뢰도가 높은 데이터를 보호하면서 외부 주체와 간편하게 공유할 수 있도록 하위 계층의 익명화된 데이터에 대한 별도의 경계를 사용해야 할 수 있습니다.

조직에서 PCI DSS와 같은 표준을 준수하려면 규제 대상 데이터 주위에 별도의 경계를 사용해야 할 수 있습니다.

데이터 공유가 조직의 주요 사용 사례라면 경계를 두 개 이상 사용하는 것이 좋습니다. 익명화된 환자 건강 데이터와 같은 하위 계층 데이터를 생성 및 공유하는 경우 별도의 경계를 사용하여 외부 주체와 쉽게 공유할 수 있습니다. 자세한 내용은 보안 데이터 교환 참조 패턴을 참조하세요.

또한 파트너 또는 고객과 같은 독립적인 서드 파티 테넌트를 호스팅하기 위해 Google Cloud 조직을 사용할 경우 각 테넌트에 대한 경계를 정의하는 것이 좋습니다. 이러한 테넌트 중 하나에서 다른 테넌트로의 데이터 이동을 무단 반출로 간주하는 경우 별도의 경계를 구현하는 것이 좋습니다.

경계 설계

경계를 만들 때 모든 보호된 서비스를 사용 설정하는 것이 좋습니다. 이는 운영 복잡성을 줄이고 잠재적 무단 반출 벡터를 최소화하는 데 도움이 됩니다. API를 보호되지 않은 상태로 두면 무단 반출 벡터가 증가할 수 있으므로 조직에서 일부 API만 보호하기로 선택하는 경우 검토를 진행하고 근거를 확보해야 합니다.

모든 새로운 프로젝트는 다음 섹션에서 설명하는 검토 및 자격 부여 프로세스를 거쳐야 합니다. 자격 조건을 통과하는 모든 프로젝트를 경계에 포함시키세요.

경계 내에 있는 VPC에서 비공개 VIP로 가는 경로가 없도록 확인합니다. private.googleapis.com의 네트워크 경로를 허용할 경우 내부 데이터 무단 반출에 대한 VPC 서비스 제어 보호가 무효화됩니다. 지원되지 않는 서비스에 대한 액세스를 허용해야 하는 경우 지원되지 않는 서비스의 사용을 별도의 프로젝트로 분리하거나 전체 워크로드를 경계 외부로 이동합니다.

프로젝트 검토 및 자격 부여

일반적인 기업에는 제어 영역, 데이터 레이크, 비즈니스 단위, 수명 주기 단계와 같은 워크로드 및 상위 수준 구성을 나타내는 프로젝트가 많습니다. 이러한 프로젝트와 구성요소를 폴더로 정리하는 것과 더불어 VPC 서비스 제어 경계 내부 또는 외부에 위치하도록 자격을 부여하는 것이 좋습니다. 이러한 자격을 부여하려면 다음 질문을 고려하세요.

  • VPC 서비스 제어가 지원하지 않는 서비스에 엄격한 종속성을 갖는 구성요소가 있나요?

    VPC 서비스 제어 시행은 명확하므로 이 유형의 종속 항목은 경계 안에서 작동하지 않을 수 있습니다. 지원되지 않는 서비스의 요구사항을 별도의 프로젝트로 분리하도록 워크로드를 수정하거나 워크로드를 경계 외부로 옮기는 것이 좋습니다.

  • 민감한 정보가 없으며 다른 프로젝트의 민감한 정보를 사용하지 않는 구성요소가 있나요?

앞의 질문 중 하나라도 '예'라고 답했다면 프로젝트를 경계 안에 두지 않는 것이 좋습니다. 허용 목록 설계 주제에서 설명한 대로 이 문제를 해결할 수 있습니다. 하지만 경계 복잡성은 최소화하는 것이 좋습니다.

다음 단계