이 문서는 데이터 센터 워크로드를 Google Cloud로 마이그레이션하는 기업을 위한 네트워킹 및 보안 아키텍처를 설명하는 시리즈의 일부입니다.
이 시리즈는 다음 문서로 구성됩니다.
- 엔터프라이즈 워크로드 마이그레이션을 위한 네트워크 설계: 아키텍처 접근 방식
- 클라우드 내 보안 액세스를 위한 네트워킹: 참조 아키텍처(이 문서)
- 인터넷 연결 애플리케이션 전송을 위한 네트워킹: 참조 아키텍처
- 하이브리드 및 멀티 클라우드 워크로드를 위한 네트워킹: 참조 아키텍처
클라우드 내 사용 사례의 워크로드는 VPC 네트워크에 있으며 Google Cloud의 다른 리소스에 연결해야 합니다. BigQuery 등 클라우드에서 기본적으로 제공되는 서비스를 사용할 수 있습니다. 보안 경계는 방화벽, VPC 서비스 제어, 네트워크 가상 어플라이언스와 같은 다양한 자사(1P) 및 타사(3P) 기능으로 제공됩니다.
대부분의 경우 이러한 워크로드는 여러 Google Cloud VPC 네트워크에 걸쳐 있으므로 VPC 네트워크 사이의 경계를 보호해야 합니다. 이 문서에서는 이러한 보안 및 연결 아키텍처에 대해 자세히 설명합니다.
리프트 앤 시프트 아키텍처
클라우드 내 사용 사례의 첫 번째 시나리오는 기존 워크로드를 클라우드로 그대로 이동하는 리프트 앤 시프트 아키텍처입니다.
방화벽
방화벽 규칙을 구성하면 보안 경계를 설정하는 데 도움이 됩니다.
네트워크 태그를 사용하여 세분화된 방화벽 규칙을 VM 모음에 적용할 수 있습니다. 태그는 VM을 만들 때 VM의 tags 필드에 추가되는 문자열로 구성된 임의의 속성입니다.
나중에 VM을 수정하여 태그를 할당할 수도 있습니다. Google Cloud 방화벽 규칙으로 트래픽을 관리하는 방법에 대한 구현 가이드라인은 엔터프라이즈 기반 청사진의 네트워크 방화벽 정책을 참조하세요.
또한 방화벽 로깅을 사용하여 방화벽 규칙 설정의 영향을 감사하고 확인할 수 있습니다.
네트워크 포렌식에 VPC 흐름 로그를 사용하고 로그를 스트리밍하여 SIEM과 통합할 수 있습니다. 이러한 전반적인 시스템은 실시간 모니터링, 이벤트 상관관계, 분석, 보안 알림을 제공할 수 있습니다.
그림 1은 방화벽 규칙이 VM 태그를 사용하여 VPC 네트워크의 VM 간에 트래픽을 제한하는 방법을 보여줍니다.
그림 1. 네트워크 태그를 사용하여 세분화된 이그레스 제어를 적용하는 네트워크 방화벽 구성
네트워크 가상 어플라이언스
네트워크 가상 어플라이언스(NVA)는 네트워크 인터페이스가 여러 개 있는 VM입니다. NVA를 사용하면 여러 VPC 네트워크에 직접 연결할 수 있습니다. 웹 애플리케이션 방화벽(WAF) 및 보안 애플리케이션 수준 방화벽과 같은 보안 기능은 VM에서 구현할 수 있습니다. 특히 그림 2와 같이 허브 스포크 구성을 사용할 때 NVA를 사용하여 East-West 트래픽에 대한 보안 기능을 구현할 수 있습니다.
Google Cloud에서 NVA를 사용하는 방법에 대한 구현 가이드라인은 Google Cloud의 중앙 집중식 네트워크 어플라이언스를 참조하세요.
그림 2. 공유 VPC 네트워크의 중앙 집중식 네트워크 어플라이언스 구성
Cloud IDS
Cloud IDS(Cloud Intrusion Detection System)를 사용하면 VPC 네트워크의 서브넷에서 들어오는 트래픽을 미러링하여 기본 보안 검사 및 로깅을 구현할 수 있습니다. Cloud IDS를 사용하면 네트워크 계층과 애플리케이션 레이어에서 다양한 위협을 검사하고 모니터링할 수 있습니다. Google Cloud 프로젝트와 연결된 VPC 네트워크에서 Cloud IDS 엔드포인트를 만드세요. 이러한 엔드포인트는 Google Cloud 네트워킹 스택에 내장된 패킷 미러링 기능을 사용하여 해당 네트워크를 오가는 인그레스 및 이그레스 트래픽과 VPC 내 네트워크 트래픽을 모니터링합니다. Cloud IDS를 호스팅하는 서비스 프로듀서 프로젝트(Google 관리 프로젝트)에 연결하려면 비공개 서비스 액세스를 사용 설정해야 합니다.
허브 및 스포크 아키텍처가 있으면 그림 3과 같이 각 스포크의 트래픽을 Cloud IDS 인스턴스로 미러링할 수 있습니다.
그림 3. 비공개 서비스 액세스를 사용하는 VPC 트래픽을 미러링하는 Cloud IDS 구성
추가 단계를 사용하여 VPC 서비스 제어 서비스 경계에서 Cloud IDS를 보호할 수 있습니다. VPC 서비스 제어 지원에 대한 자세한 내용은 지원되는 제품을 참조하세요.
VPC 네트워크 피어링
여러 VPC 네트워크에 걸친 애플리케이션의 경우 동일한 Google Cloud 프로젝트 또는 동일한 조직 리소스에 속하는지 여부에 관계없이 VPC 네트워크 피어링은 VPC 네트워크 간 연결을 사용 설정합니다. 이 연결을 통해 트래픽이 Google 네트워크 내에 유지되어 공개 인터넷을 통과하지 않습니다.
리프트 앤 시프트 아키텍처에서 VPC 네트워크 피어링을 사용하는 모델은 두 가지입니다. 하나는 '순수한' 허브 및 스포크 아키텍처이고, 다른 하나는 스포크의 트래픽이 다른 스포크에 도달할 수 있는 전이성 허브 및 스포크 아키텍처입니다. 다음 섹션에서는 이러한 다양한 아키텍처에서 VPC 네트워크 피어링을 사용하는 방법을 자세히 설명합니다.
허브 및 스포크 아키텍처
허브 및 스포크 아키텍처는 VPC 네트워크 피어링을 사용하는 VPC 연결에 널리 사용되는 모델입니다. 이 모델은 기업에 로깅 또는 인증과 같은 일반적인 서비스 집합에 액세스해야 하는 다양한 애플리케이션이 있는 경우에 유용합니다. 또한, 이 모델은 기업이 허브를 통해 네트워크를 나가는 트래픽에 대해 공통 보안 정책 집합을 구현해야 하는 경우에도 유용합니다. 순수한 허브 및 스포크 모델에서는 스포크 간의 트래픽 교환(전환 트래픽이라고 함)이 허용되지 않습니다. 그림 4는 VPC 네트워크 피어링을 사용하여 스포크를 허브에 연결하는 순수한 허브 및 스포크 아키텍처를 보여줍니다. 허브 및 스포크 네트워크 빌드를 위한 구현 가이드라인은 엔터프라이즈 기반 청사진의 허브 및 스포크 네트워크 토폴로지를 참조하세요.
하지만 VPC 수준을 분리할 필요가 없으면 공유 VPC 아키텍처를 사용할 수 있습니다. 이 아키텍처는 이제 막 Google Cloud에서 시작한 일부 기업에 더 단순한 모델을 제공할 수 있습니다.
그림 4. 네트워크 격리 및 비전환 연결을 위해 VPC 네트워크 피어링을 사용하는 허브 및 스포크 네트워크 아키텍처
전이성 허브 및 스포크
허브 및 스포크를 전이성(스포크의 트래픽이 허브를 통해 다른 스포크에 도달할 수 있음)으로 사용 설정할 때 VPC 네트워크 피어링을 사용하는 몇 가지 방법이 있습니다. 한 가지는 모든 VPC 네트워크가 연결이 필요한 다른 모든 VPC 네트워크와 직접 피어링하는 풀 메시 토폴로지로 VPC 네트워크 피어링을 사용하는 것입니다.
또는 NVA를 사용하여 허브와 스포크를 함께 연결하는 방법도 있습니다. 그러면 NVA는 VPC 스포크에서 전송되는 트래픽의 다음 홉으로 사용되는 내부 부하 분산기 뒤에 상주합니다. 그림 5는 이러한 옵션을 모두 보여줍니다.
또한 VPN을 사용하여 허브와 스포크 VPC 네트워크 간을 연결할 수 있습니다. 이 배치는 스포크-스포크 연결에서 연결 가능성을 지원하여 허브 VPC 네트워크에서 전이성을 제공합니다.
그림 5. 네트워크 격리 및 전이적 연결을 위해 Cloud VPN을 사용하는 허브 및 스포크 네트워크 구성
공유 VPC
공유 VPC를 사용하여 호스트 프로젝트의 서브넷, 경로, 방화벽과 같은 네트워크 리소스를 중앙에서 제어할 수 있습니다. 이 제어 수준은 네트워크 관리 작업을 네트워크 및 보안 관리자에게 위임할 수 있으므로 네트워크 관리, 감사, 액세스 제어에 대한 최소 권한의 보안 권장사항을 구현할 수 있습니다. 서비스 프로젝트를 사용하여 인스턴스 관리자에게 VM을 만들고 관리하는 권한을 할당할 수 있습니다. 서비스 프로젝트를 사용하면 VM 관리자에게 인스턴스를 만들고 관리할 수 있는 권한만 부여되며 공유 VPC 네트워크에서 네트워크에 영향을 미치는 변경은 허용하지 않습니다.
예를 들어 두 호스트 프로젝트에 있는 두 개의 VPC 네트워크를 정의하고 프로덕션용 및 테스트용 네트워크에 각각 여러 서비스 프로젝트를 연결하여 더 많은 격리를 제공할 수 있습니다. 그림 6은 별도의 프로젝트를 사용하여 프로덕션 환경을 테스트 환경과 격리하는 아키텍처를 보여줍니다.
VPC 네트워크 빌드를 위한 권장사항에 대한 자세한 내용은 VPC 설계에 관한 권장사항 및 참조 아키텍처를 참조하세요.
그림 6. 격리된 여러 호스트와 서비스 프로젝트(테스트 및 프로덕션 환경)를 사용하는 공유 VPC 네트워크 구성
하이브리드 서비스 아키텍처
하이브리드 서비스 아키텍처는 멀티 VPC 환경에서 서비스를 연결하고 보호할 수 있도록 설계된 추가적인 클라우드 네이티브 서비스를 제공합니다. 이러한 클라우드 네이티브 서비스는 리프트 앤 시프트 아키텍처에서 사용할 수 있는 기능을 보완하며 VPC 세분화 환경을 대규모로 더 쉽게 관리할 수 있습니다.
Private Service Connect
Private Service Connect를 사용하면 하나의 VPC 네트워크에서 호스팅되는 서비스를 다른 VPC 네트워크에 표시할 수 있습니다. 동일 조직 리소스에서 서비스를 호스팅할 필요는 없으므로 Private Service Connect를 사용하면 다른 조직 리소스에 연결된 경우에도 다른 VPC 네트워크의 서비스를 비공개로 사용할 수 있습니다.
Google API에 액세스하거나 다른 VPC 네트워크에 호스팅되는 서비스에 액세스하는 방법으로 Private Service Connect를 사용할 수 있습니다.
Google API에 액세스하도록 Private Service Connect 사용
Private Service Connect를 사용하는 경우 그림 7과 같이 VPC 네트워크에 포함된 Private Service Connect 엔드포인트를 사용하여 Google API를 노출할 수 있습니다.
그림 7. VPC 네트워크에 비공개인 Private Service Connect 엔드포인트를 사용하여 트래픽을 Google API로 보내는 Private Service Connect 구성
워크로드는 Private Service Connect 엔드포인트를 사용하여 전역 Google API 번들으로 트래픽을 전송할 수 있습니다. 또한 Private Service Connect 백엔드를 사용하여 단일 Google API에 액세스하여 부하 분산기의 보안 기능을 API 서비스로 확장할 수 있습니다. 그림 8은 이 구성을 보여줍니다.
그림 8. Private Service Connect 백엔드를 사용하여 트래픽을 Google API로 보내는 Private Service Connect 구성
VPC 네트워크 또는 항목 간에 Private Service Connect 사용
Private Service Connect를 사용하면 서비스 프로듀서가 동일한 조직 리소스나 다른 조직 리소스에 있는 다른 VPC 네트워크의 서비스 소비자에게 서비스를 제공할 수도 있습니다. 서비스 프로듀서 VPC 네트워크는 여러 서비스 소비자를 지원할 수 있습니다. 소비자는 소비자의 VPC 네트워크에 있는 Private Service Connect 엔드포인트로 트래픽을 전송하여 프로듀서 서비스에 연결할 수 있습니다. 엔드포인트는 게시된 서비스를 포함하는 VPC 네트워크로 트래픽을 전달합니다.
그림 9. 서비스 연결을 통해 관리형 서비스를 게시하고 엔드포인트를 통해 서비스를 사용하기 위한 Private Service Connect 구성
VPC 서버리스 액세스 커넥터
VPC 서버리스 액세스 커넥터는 서버리스 환경과 VPC 네트워크 간의 트래픽을 처리합니다. Google Cloud 프로젝트에서 커넥터를 생성할 때 특정 VPC 네트워크 및 리전에 연결합니다. 그런 다음 아웃바운드 네트워크 트래픽에 커넥터를 사용하도록 서버리스 서비스를 구성할 수 있습니다. 서브넷이나 CIDR 범위를 사용하여 커넥터를 지정할 수 있습니다. 커넥터를 통해 VPC 네트워크로 전송된 트래픽은 그림 10과 같이 지정된 서브넷 또는 CIDR 범위에서 시작됩니다.
그림 10. VPC 네트워크 내부의 내부 IP 주소를 사용하여 Google Cloud 서버리스 환경에 액세스하는 서버리스 VPC 액세스 커넥터 구성
서버리스 VPC 액세스 커넥터는 Cloud Run, Cloud Functions, App Engine 표준 환경을 지원하는 모든 리전에서 지원됩니다. 자세한 내용은 VPC 서버리스 액세스 커넥터 사용에 대한 지원되는 서비스 및 지원되는 네트워킹 프로토콜 목록을 참조하세요.
VPC 서비스 제어
VPC 서비스 제어는 인터넷이나 보안 경계에 포함되지 않은 프로젝트에서의 승인된 액세스를 차단하여 Cloud Storage 또는 BigQuery와 같은 서비스의 데이터 무단 반출을 방지합니다. 예를 들어 사람의 실수 또는 잘못된 자동화로 인해 Cloud Storage 또는 BigQuery와 같은 서비스에서 IAM 정책이 잘못 설정된 경우를 가정해 보겠습니다. 결과적으로 이러한 서비스의 리소스에 공개적으로 액세스할 수 있게 되었습니다. 이 경우 데이터 노출 위험이 있습니다. 이러한 서비스를 VPC 서비스 제어 경계의 일부로 구성한 경우 IAM 정책에서 액세스를 허용하더라도 리소스에 대한 인그레스 액세스가 차단됩니다.
VPC 서비스 제어는 ID 유형(서비스 계정 또는 사용자)과 네트워크 원본(IP 주소 또는 VPC 네트워크)과 같은 클라이언트 속성을 기반으로 경계를 만들 수 있습니다.
VPC 서비스 제어는 다음과 같은 보안 위험을 완화하는 데 도움이 됩니다.
- 도용된 사용자 인증 정보를 사용하는 승인되지 않은 네트워크에서의 액세스
- 악의적인 내부자 또는 손상된 코드에 의한 데이터 유출
- 잘못 구성된 IAM 정책으로 인한 비공개 데이터의 공개 노출
그림 11은 VPC 서비스 제어를 사용하여 이러한 위험을 완화하는 데 도움이 되는 서비스 경계를 설정하는 방법을 보여줍니다.
그림 11. 비공개 액세스 서비스를 사용하여 하이브리드 환경으로 확장된 VPC 서비스 경계
그림 12와 같이 인그레스 규칙과 이그레스 규칙을 사용하여 두 서비스 경계 간의 통신을 사용 설정할 수 있습니다.
그림 12. 서비스 경계 간에 통신하도록 인그레스 및 이그레스 규칙 구성
VPC 서비스 제어 배포 아키텍처에 대한 자세한 권장사항은 서비스 경계 설계를 참조하세요. VPC 서비스 제어에서 지원되는 서비스 목록에 대한 자세한 내용은 지원되는 제품 및 제한사항을 참조하세요.
제로 트러스트 분산 아키텍처
네트워크 경계 보안 제어는 최소 권한 및 심층 방어의 보안 원칙을 지원하기에 필요하지만 충분하지 않습니다. 제로 트러스트 분산 아키텍처는 보안 적용을 위해 네트워크 경계 에지를 기반으로 하지만, 여기에만 의존하지는 않습니다. 분산 아키텍처이므로 보안 정책, 강력한 인증, 워크로드 아이덴티티에 대한 서비스별 시행을 갖는 마이크로서비스로 구성됩니다.
Traffic Director 및 Anthos Service Mesh에서 관리되는 서비스로 제로 트러스트 분산 아키텍처를 구현할 수 있습니다.
Traffic Director
서비스 보안을 사용하여 GKE 클러스터 내에 제로 트러스트 분산 아키텍처 마이크로서비스 메시를 제공하도록 Traffic Director를 구성할 수 있습니다. 이 모델에서는 Envoy 사이드카 또는 프록시리스 gRPC를 사용하는 GKE 서비스의 ID, 인증, 승인 정책은 모두 Traffic Director, 워크로드 아이덴티티, Certificate Authority Service, IAM 모두의 관리 대상입니다. 인증서 관리 및 안전한 이름 지정이 플랫폼에서 제공되며 모든 서비스 통신에는 mTLS 전송 보안이 적용됩니다. 그림 13은 이 구성을 사용하는 클러스터를 보여줍니다.
그림 13. Traffic Director를 사용하는 단일 클러스터 제로 트러스트 분산 아키텍처 메시
승인 정책은 서버가 들어오는 요청 또는 RPC를 승인하는 방법을 지정합니다. 요청을 보낸 클라이언트의 ID, 호스트, 헤더, 기타 HTTP 속성과 같은 다양한 매개변수를 기반으로 하여 들어오는 요청 또는 RPC를 허용하거나 거부하도록 승인 정책을 구성할 수 있습니다. 구현 가이드라인은 gRPC 및 Envoy를 기반으로 메시에서 승인 정책을 구성하는 데 사용할 수 있습니다.
그림 13에서 이 아키텍처에는 단일 클러스터와 플랫 네트워킹(공유 IP 주소 공간)이 있습니다. 다중 클러스터는 일반적으로 격리, 위치, 확장을 위해 제로 트러스트 분산 아키텍처에서 사용됩니다.
더 복잡한 환경에서는 클러스터가 Fleet을 사용하여 그룹화되면 여러 클러스터가 관리형 ID를 공유할 수 있습니다. 이 경우 Private Service Connect를 사용하여 독립적인 VPC 네트워크에서 네트워킹 연결을 구성할 수 있습니다. 이 접근 방식은 이 문서의 뒷부분에서 설명하는 하이브리드 워크로드 액세스 멀티 클러스터 네트워크 연결 방식과 유사합니다.
Traffic Director로 트래픽을 세밀하게 제어하는 방법에 대한 자세한 내용은 고급 트래픽 관리 개요를 참조하세요.
Anthos Service Mesh
Anthos Service Mesh는 Istio 기반을 기반으로 하는 즉시 사용 가능한 mTLS 제로 트러스트 분산 아키텍처 마이크로서비스 메시를 제공합니다. 통합 흐름을 사용하여 메시를 설정하세요. Google 관리 데이터 및 제어 영역이 포함된 관리형 Anthos Service Mesh는 GKE에서 지원됩니다. 클러스터 내 제어 영역도 사용할 수 있으며, 이는 Google Distributed Cloud Virtualises 또는 GKE Multi-Cloud 등의 다른 환경에 적합합니다. Anthos Service Mesh는 Istio 기반 승인 정책 모델을 제공하여 ID와 인증서를 자동으로 관리합니다.
Anthos Service Mesh는 멀티 클러스터 서비스 배포 구성 및 ID를 관리하기 위해 Fleet을 사용합니다. Traffic Director와 마찬가지로 워크로드가 플랫 또는 공유 VPC 네트워크 연결 환경에서 작동하는 경우 방화벽 구성 외에 특별한 네트워크 연결 요구사항이 없습니다. 아키텍처에 별도의 VPC 네트워크 또는 네트워킹 환경(예: Cloud Interconnect 연결)에 걸쳐 여러 Anthos Service Mesh 클러스터가 포함된 경우 동서 게이트웨이도 필요합니다. Anthos Service Mesh 네트워킹 권장사항은 GKE 네트워킹 권장사항에 설명된 것과 동일합니다.
Anthos Service Mesh는 또한 IAP(Identity-Aware Proxy)와 통합됩니다. IAP를 사용하면 사용자 ID, IP 주소, 기기 유형 같은 원래 요청의 속성을 기반으로 워크로드에 대한 사용자 액세스를 제어할 수 있도록 세분화된 액세스 정책을 설정할 수 있습니다. 이러한 제어 수준은 엔드 투 엔드 제로 트러스트 환경을 지원합니다.
Anthos Service Mesh를 사용할 때 GKE 클러스터 요구사항을 고려해야 합니다. 자세한 내용은 'GKE에서 단일 프로젝트 설치' 문서의 요구사항 섹션을 참조하세요.
다음 단계
- 인터넷 연결 애플리케이션 배포를 위한 네트워킹: 참조 아키텍처
- 하이브리드 및 멀티 클라우드 워크로드를 위한 네트워킹: 참조 아키텍처
- Google Cloud로의 마이그레이션은 워크로드를 Google Cloud로 마이그레이션하는 프로세스를 계획, 설계, 구현하는 데 도움이 됩니다.
- Google Cloud의 시작 영역 설계에서 시작 영역 네트워크 생성에 대해 알아보기
- 클라우드 아키텍처 센터에서 참조 아키텍처, 다이어그램, 권장사항 자세히 살펴보기