엔터프라이즈 워크로드 마이그레이션을 위한 네트워크 설계: 아키텍처 접근 방식

Last reviewed 2023-11-13 UTC

이 문서에서는 데이터 센터 워크로드를 Google Cloud로 마이그레이션하는 기업을 위한 네트워킹 및 보안 아키텍처를 설명하는 시리즈를 소개합니다. 이러한 아키텍처에서는 하이브리드 환경 전반의 최첨단 연결, 제로 트러스트 보안 원칙, 관리 효율성을 강조합니다.

함께 제공되는 클라우드 데이터 영역 보호 아키텍처에서 설명하듯이 기업에서는 클라우드 연결 및 보안 요구사항을 고려한 일정 범위의 아키텍처를 배포합니다. Google은 이러한 아키텍처를 리프트 앤 시프트, 하이브리드 서비스, 제로 트러스트 분산과 같은 별개의 세 아키텍처 패턴으로 분류합니다. 현재 문서에서는 기업에서 선택한 아키텍처에 따라 달라지는 보안 접근 방식을 고려합니다. 또한 Google Cloud에서 제공하는 구성요소를 사용하여 이러한 접근 방식을 실현하는 방법을 설명합니다. 이러한 보안 안내는 안정성, 가용성, 확장성, 성능, 거버넌스를 다루는 다른 아키텍처 안내와 함께 사용해야 합니다.

이 문서는 온프레미스 워크로드를 클라우드로 마이그레이션하려는 시스템 설계자, 네트워크 관리자, 보안 관리자를 대상으로 합니다. 이 문서에서는 다음과 같이 가정합니다.

  • 데이터 센터 네트워킹 및 보안 개념에 익숙합니다.
  • 온프레미스 데이터 센터에 기존 워크로드가 있으며 워크로드의 내용 및 사용자를 숙지하고 있습니다.
  • 마이그레이션할 워크로드가 1개 이상 있습니다.
  • 클라우드 데이터 영역 보호 아키텍처에 설명된 개념에 대체로 익숙합니다.

이 시리즈는 다음 문서로 구성됩니다.

이 문서에서는 세 가지 기본 아키텍처 패턴을 요약하고, 인프라를 만들기 위해 사용할 수 있는 리소스 구성요소를 소개합니다. 마지막으로 패턴과 일치하는 일련의 참조 아키텍처로 구성요소를 조합하는 방법을 설명합니다. 이러한 참조 아키텍처를 사용하면 자체 아키텍처를 만들 때 참고할 수 있습니다.

이 문서에서는 워크로드 리소스의 예로 가상 머신(VM)을 사용합니다. 이 정보는 Cloud SQL 인스턴스 및 Google Kubernetes Engine 노드와 같이 VPC 네트워크를 사용하는 다른 리소스에도 적용됩니다.

아키텍처 패턴 개요

일반적으로 네트워크 엔지니어는 주로 온프레미스 데이터 센터에서 물리적 네트워킹 인프라 및 보안 인프라를 구축합니다.

클라우드 네트워킹 구조는 소프트웨어로 정의되기 때문에 클라우드 여정은 이러한 접근 방식에 변화를 가져왔습니다. 클라우드에서는 애플리케이션 소유자가 기본 인프라 스택을 제한적으로 제어할 수 있습니다. 보안 경계가 있고 워크로드에 격리를 제공하는 모델이 필요합니다.

이 시리즈에서는 세 가지 일반적인 아키텍처 패턴을 다룹니다. 이 패턴들은 서로를 기반으로 하므로 엄격히 하나를 선택한다기보다는 하나의 범위로 인식할 수 있습니다.

리프트 앤 시프트 패턴

리프트 앤 시프트 아키텍처 패턴에서는 엔터프라이즈 애플리케이션 소유자가 워크로드를 리팩터링하지 않고 클라우드로 마이그레이션합니다. 네트워크 및 보안 엔지니어는 VPC 네트워크에서 온프레미스 실제 기기와 클라우드 방화벽 규칙을 모방하는 네트워크 가상 어플라이언스 조합을 사용해 보호를 제공하는 레이어 3 및 레이어 4 제어를 사용합니다. 워크로드 소유자는 VPC 네트워크에 서비스를 배포합니다.

하이브리드 서비스 패턴

리프트 앤 시프트를 사용하여 빌드된 워크로드가 BigQuery 또는 Cloud SQL과 같은 클라우드 서비스에 액세스해야 할 수 있습니다. 일반적으로 이러한 클라우드 서비스에 대한 액세스는 레이어 4 및 레이어 7에 있습니다. 이러한 상황에서는 레이어 3에서만 격리 및 보안을 수행할 수 없습니다. 따라서 액세스 중인 서비스의 ID와 액세스를 요청하는 서비스를 기반으로 서비스 네트워킹과 VPC 서비스 제어를 사용해 연결 및 보안을 제공합니다. 이 모델에서는 다양한 액세스 제어 정책을 표현할 수 있습니다.

제로 트러스트 분산 패턴

제로 트러스트 아키텍처에서는 엔터프라이즈 애플리케이션이 경계 제어 이상으로 보안 적용 범위를 확장합니다. IAM ID에 기본적으로 거부되는 특정 권한이 있는 경우에만 경계 내에서 워크로드가 다른 워크로드와 통신할 수 있습니다. 제로 트러스트 분산 아키텍처에서 트러스트는 ID 기반이며 각 애플리케이션에 적용됩니다. 워크로드는 중앙에서 발급된 ID가 있는 마이크로서비스로 빌드됩니다. 이를 통해 서비스에서 호출자를 검증하고 각 요청마다 액세스 허용 여부에 대한 정책 기반 결정을 내릴 수 있습니다. 이 아키텍처는 중앙 집중식 게이트웨이를 사용하는 대신 분산 프록시(서비스 메시)를 사용하여 구현되는 경우가 많습니다.

기업에서 IAP(Identity-Aware Proxy)를 구성하여 사용자 및 기기부터 엔터프라이즈 애플리케이션까지 제로 트러스트 액세스를 적용할 수 있습니다. IAP는 인터넷 또는 인트라넷의 사용자 트래픽에 대한 ID 기반 및 컨텍스트 기반 제어를 제공합니다.

패턴 결합

비즈니스 애플리케이션을 빌드하거나 클라우드로 마이그레이션하는 기업은 일반적으로 세 가지 아키텍처 패턴의 조합을 사용합니다.

Google Cloud는 아키텍처 패턴을 지원하는 클라우드 데이터 영역을 구현하기 위한 구성요소 역할을 하는 제품 및 서비스 포트폴리오를 제공합니다. 이러한 구성요소는 이 문서의 뒷부분에서 설명합니다. 클라우드 데이터 영역에서 제공되는 제어와 클라우드 리소스를 관리할 수 있는 관리 제어의 조합은 엔드 투 엔드 보안 경계의 기반을 형성합니다. 이 조합을 통해 생성된 경계로 클라우드에서 워크로드를 관리, 배포, 운영할 수 있습니다.

리소스 계층 구조 및 관리 제어

이 섹션에서는 Google Cloud에서 리소스 컨테이너로 제공하는 관리 제어를 요약합니다. 제어에는 클라우드 리소스를 그룹화하고 계층적으로 구성할 수 있게 해주는 Google Cloud 조직 리소스, 폴더, 프로젝트가 포함됩니다. 이 계층적 조직은 소유권 구조와 정책 및 제어 적용을 위한 고정점을 제공합니다.

Google 조직 리소스는 계층 구조의 루트 노드이며 클라우드에서 배포를 만드는 기초입니다. 조직 리소스에는 폴더와 프로젝트가 하위 요소로 포함될 수 있습니다. 폴더에는 프로젝트 또는 다른 폴더가 하위 요소로 포함됩니다. 그 밖의 모든 클라우드 리소스는 프로젝트의 하위 요소입니다.

폴더는 프로젝트를 그룹화하기 위한 방법으로 사용됩니다. 프로젝트는 모든 Google Cloud 서비스 만들기, 사용 설정, 사용을 위한 기초를 형성합니다. 프로젝트를 통해 API를 관리하고 결제를 사용 설정하며 공동작업자를 추가 및 삭제하고 권한을 관리할 수 있습니다.

Google Identity and Access Management(IAM)를 사용하면 모든 리소스 계층 구조 수준에서 역할을 할당하고 액세스 정책 및 권한을 정의할 수 있습니다. IAM 정책은 계층 구조에서 하위 리소스에 상속됩니다. 계층 구조에서 하위에 있는 리소스의 소유자는 정책을 변경할 수 없습니다. 경우에 따라 ID 및 액세스 관리가 보다 세부적인 수준에서 제공됩니다(예: Google Kubernetes Engine에서 네임스페이스 또는 클러스터 내 객체 범위).

Google Virtual Private Cloud 네트워크의 설계 고려사항

클라우드로의 마이그레이션 전략을 설계할 때는 기업에서 VPC 네트워크를 사용하는 방법에 대한 전략을 개발하는 것이 중요합니다. VPC 네트워크는 기존 물리적 네트워크의 가상 버전이라고 볼 수 있습니다. VPC 네트워크는 완전히 격리된 비공개 네트워크 파티션입니다. 기본적으로 한 VPC 네트워크에 배포된 워크로드 또는 서비스는 다른 VPC 네트워크의 작업과 통신할 수 없습니다. 따라서 VPC 네트워크에서는 보안 경계를 형성하여 워크로드 격리를 사용 설정합니다.

클라우드의 각 VPC 네트워크는 완전한 가상 네트워크이므로 각각 자체 비공개 IP 주소 공간이 있습니다. 따라서 충돌 없이 여러 VPC 네트워크에서 동일한 IP 주소를 사용할 수 있습니다. 일반적인 온프레미스 배포는 RFC 1918 비공개 IP 주소 공간의 상당 부분을 소비할 수 있습니다. 반면 온프레미스 및 VPC 네트워크 모두에 워크로드가 있는 경우 해당 네트워크가 연결되거나 피어링되지 않아서 IP 주소 공간을 사용하는 속도가 빠르지 않다면 다른 VPC 네트워크에서 동일한 주소 범위를 재사용할 수 있습니다.

VPC 네트워크는 전역임

Google Cloud의 VPC 네트워크는 전역입니다. 즉, VPC 네트워크가 있는 프로젝트에 배포된 리소스가 Google의 비공개 백본을 사용하여 서로 직접 통신할 수 있습니다.

그림 1과 같이 프로젝트에 여러 영역에 걸쳐 있는 다양한 리전의 서브네트워크가 포함된 VPC 네트워크가 있을 수 있습니다. 모든 리전의 VM은 로컬 VPC 경로를 사용하여 서로 비공개로 통신할 수 있습니다.

서브네트워크가 다른 리전에 구성된 Google Cloud 전역 VPC 네트워크 구현

그림 1. 서브네트워크가 다른 리전에 구성된 Google Cloud 전역 VPC 네트워크 구현

공유 VPC를 사용한 네트워크 공유

공유 VPC를 사용하면 조직 리소스가 여러 프로젝트를 공통 VPC 네트워크에 연결하여 공유 네트워크의 내부 IP 주소를 사용하여 서로 안전하게 통신할 수 있어야 합니다. 공유 네트워크의 네트워크 관리자가 네트워크 리소스에 대한 중앙 집중식 제어를 적용하고 시행합니다.

공유 VPC를 사용할 때는 프로젝트 하나를 호스트 프로젝트로 지정하고 여기에 하나 이상의 서비스 프로젝트를 연결합니다. 호스트 프로젝트의 VPC 네트워크를 공유 VPC 네트워크라고 합니다. 서비스 프로젝트의 요건을 충족하는 리소스는 공유 VPC 네트워크의 서브넷을 사용할 수 있습니다.

일반적으로 기업에서는 네트워크 및 보안 관리자가 서브넷 및 경로와 같은 네트워크 리소스의 관리를 중앙화해야 할 때 공유 VPC 네트워크를 사용합니다. 동시에 공유 VPC 네트워크를 사용하면 애플리케이션 및 개발팀이 서비스 프로젝트를 사용하여 지정된 서브넷에 VM 인스턴스를 만들고 삭제하며 워크로드를 배포할 수 있습니다.

VPC 네트워크를 사용한 환경 격리

VPC 네트워크를 사용하여 환경을 격리하면 여러 가지 장점이 있지만 몇 가지 단점도 고려해야 합니다. 이 섹션에서는 이러한 장단점을 다루고 격리 구현을 위한 일반적인 패턴을 설명합니다.

환경을 격리하는 이유

VPC 네트워크는 격리 도메인을 나타내므로 많은 기업에서 이를 사용하여 환경 또는 사업부를 별도의 도메인에 유지합니다. VPC 수준 격리를 만드는 일반적인 이유는 다음과 같습니다.

  • VPC 네트워크는 조직적으로 유의미한 차이를 나타내기 때문에 기업에서는 VPC 네트워크 간에 기본 거부 통신을 설정하기를 원합니다. 자세한 내용은 이 문서의 뒷부분에 나오는 일반적인 VPC 네트워크 격리 패턴을 참조하세요.
  • 기업에는 기존 온프레미스 환경, 인수 또는 다른 클라우드 환경에 대한 배포로 인해 서로 겹치는 IP 주소 범위가 필요합니다.
  • 기업에서는 네트워크에 대한 전체 관리 권한을 기업의 일부에 위임하기를 원합니다.

환경 격리의 단점

VPC 네트워크로 격리된 환경을 만들면 몇 가지 단점이 있을 수 있습니다. 여러 VPC 네트워크가 있으면 여러 네트워크에 걸쳐 있는 서비스 관리 오버헤드가 늘어날 수 있습니다. 이 문서에서는 이러한 복잡성을 관리하는 데 사용할 수 있는 기법에 대해 설명합니다.

일반적인 VPC 네트워크 격리 패턴

VPC 네트워크 격리를 위한 일반적인 패턴은 다음과 같습니다.

  • 개발, 스테이징, 프로덕션 환경을 격리합니다. 이 패턴을 사용하면 기업에서 개발, 스테이징, 프로덕션 환경을 서로 완전히 분리할 수 있습니다. 실제로 이 구조에서는 각 환경 간에 점진적으로 출시되는 여러 개의 완전한 애플리케이션 사본을 유지합니다. 이 패턴에서 VPC 네트워크는 보안 경계로 사용됩니다. 개발자가 일상 업무를 처리하기 위해 개발 VPC 네트워크에 대한 높은 수준의 액세스 권한을 가집니다. 개발이 완료되면 엔지니어링 프로덕션팀 또는 QA팀에서 변경사항을 스테이징 환경으로 마이그레이션할 수 있으며, 여기에서 변경사항이 통합 방식으로 테스트될 수 있습니다. 변경사항을 배포할 준비가 되면 프로덕션 환경으로 전송합니다.
  • 사업부를 격리합니다. 일부 기업은 특히 인수된 사업부 또는 높은 수준의 자율성과 격리가 필요한 사업부 간에 높은 수준의 격리를 적용하기를 원합니다. 이 패턴에서 기업은 각 사업부별로 VPC 네트워크를 만들고 해당 VPC에 대한 제어를 사업부의 관리자에게 위임하는 경우가 많습니다. 기업은 이 문서의 뒷부분에서 설명하는 기술을 사용하여 기업 전체에서 사용되는 서비스를 노출하거나 여러 사업부를 포함하는 사용자 대상 애플리케이션을 호스팅합니다.

격리된 환경 만들기 권장사항

VPC 네트워크를 기업 관리 및 보안 경계에 맞는 가장 광범위한 도메인으로 설계하는 것이 좋습니다. 방화벽과 같은 보안 제어를 사용해서 동일한 VPC 네트워크에서 실행되는 워크로드 간에 추가 격리를 달성할 수 있습니다.

조직을 위한 격리 전략을 설계하고 빌드하는 방법에 대한 자세한 내용은 Google Cloud 엔터프라이즈 기반 청사진에서 VPC 설계에 관한 권장사항 및 참조 아키텍처 및 네트워킹을 참조하세요.

클라우드 네트워킹의 구성요소

이 섹션에서는 네트워크 연결, 네트워크 보안, 서비스 네트워킹, 서비스 보안을 위한 중요한 구성요소에 대해 설명합니다. 그림 2는 이러한 구성요소가 서로 어떻게 관련되는지 보여줍니다. 지정된 행에 나열된 제품을 하나 이상 사용할 수 있습니다.

클라우드 네트워크 연결 및 보안 영역의 기본 구성요소

그림 2. 클라우드 네트워크 연결 및 보안 영역의 기본 구성요소

다음 섹션에서는 각 구성요소에 대해 설명하고 각 요소에 사용할 수 있는 Google Cloud 서비스를 설명합니다.

네트워크 연결

네트워크 연결 요소는 계층 구조의 기저를 이룹니다. Google Cloud 리소스를 온프레미스 데이터 센터 또는 다른 클라우드에 연결합니다. 필요에 따라 이러한 제품 중 하나만 필요할 수도 있고, 이 모든 제품을 사용하여 다른 사용 사례를 처리할 수도 있습니다.

Cloud VPN

Cloud VPN을 사용하면 IPsec VPN 연결을 통해 멀리 떨어진 지사 또는 기타 클라우드 제공업체를 Google VPC 네트워크에 연결할 수 있습니다. 한쪽 VPN 게이트웨이에서 두 네트워크 사이의 트래픽 이동을 암호화하면 이후 다른 쪽 VPN 게이트웨이에서 이를 복호화하여 인터넷을 순회하는 데이터를 보호하는 데 도움을 줍니다.

Cloud VPN을 사용하면 Cloud Interconnect에 필요한 물리적 교차 연결을 프로비저닝하는 오버헤드 없이 온프레미스 환경과 Google Cloud 간의 연결을 사용 설정할 수 있습니다(다음 섹션 참조). HA VPN을 프로비저닝하면 적절한 아키텍처를 사용하는 경우 최대 99.99%의 가용성 SLA 요구사항을 충족할 수 있습니다. 워크로드에 짧은 지연 시간이나 높은 대역폭이 필요 없는 경우 Cloud VPN을 사용하는 것이 좋습니다. 예를 들어 Cloud VPN은 업무상 중요하지 않은 사용 사례나 다른 클라우드 제공업체로 연결을 확장할 때 적합합니다.

Cloud Interconnect

Cloud Interconnect는 VPN 또는 인터넷 인그레스를 사용할 때보다 높은 처리량과 안정적인 네트워크 성능을 제공하는 엔터프라이즈급 전용 Google Cloud 연결을 제공합니다. Dedicated Interconnect는 라우터에서 Google의 네트워크에 대한 물리적인 직접 연결을 제공합니다. Partner Interconnect는 Dedicated Interconnect보다 넓은 범위 또는 다른 대역폭 옵션을 제공할 수 있는 광범위한 파트너 네트워크를 통해 전용 연결을 제공합니다. Cross-Cloud Interconnect는 VPC 네트워크에서 다른 클라우드 제공업체로의 전용 직접 연결을 제공합니다. Dedicated Interconnect를 사용하려면 Google 접속 지점이 있으며 Partner Interconnect는 접속 지점이 없는 코로케이션 시설에서 연결해야 합니다. Cross-Cloud Interconnect를 사용하면 연결을 설정하기 위한 요구사항을 충족하는 위치를 선택할 수 있습니다. Cloud Interconnect는 온프레미스 네트워크 또는 다른 클라우드 네트워크와 VPC 네트워크 간의 트래픽이 공개 인터넷을 거치지 않도록 합니다.

이러한 Cloud Interconnect 연결을 프로비저닝하면 적절한 아키텍처를 프로비저닝하는 경우 최대 99.99%의 가용성 SLA 요구사항을 충족할 수 있습니다. Cloud Interconnect를 사용하면 모든 트래픽을 비공개로 유지하면서 짧은 지연 시간, 높은 대역폭, 예측 가능한 성능을 요구하는 워크로드를 지원할 수 있습니다.

하이브리드용 Network Connectivity Center

Network Connectivity Center는 온프레미스와 다른 클라우드 네트워크 간에 사이트 간 연결을 제공합니다. Google의 백본 네트워크를 사용하여 사이트 간에 안정적인 연결을 제공합니다.

또한 VM 또는 서드 파티 공급업체 라우터 어플라이언스를 논리적 스포크 연결로 구성하여 기존 SD-WAN 오버레이 네트워크를 Google Cloud로 확장할 수 있습니다.

라우터 어플라이언스, VPN 또는 Cloud Interconnect 네트워크를 스포크 연결로 사용하여 VPC 네트워크 내의 리소스에 액세스할 수 있습니다. Network Connectivity Center를 사용하면 온프레미스 사이트, 다른 클라우드에 있는 접속 지점, Google Cloud 간의 연결을 통합하고 단일 뷰를 사용하여 모두 관리할 수 있습니다.

VPC 네트워크용 Network Connectivity Center

Network Connectivity Center를 사용하면 여러 VPC 네트워크 간에 메시를 만들 수도 있습니다. Cloud VPN 또는 Cloud Interconnect를 사용하여 이 메시를 온프레미스 또는 다른 클라우드에 연결할 수 있습니다.

VPC 네트워크 피어링

VPC 네트워크 피어링을 사용하면 Google VPC 네트워크를 연결하여 여러 VPC 네트워크의 워크로드가 동일한 프로젝트 또는 동일한 조직 리소스에 속하는지 여부에 관계없이 내부적으로 서로 통신할 수 있습니다. 트래픽은 Google 네트워크에 그대로 머무르며 공개 인터넷을 거치지 않습니다.

VPC 네트워크 피어링을 사용하려면 피어링할 네트워크의 IP 주소가 겹치지 않아야 합니다.

네트워크 보안

네트워크 보안 요소는 네트워크 연결 요소 위에 있습니다. IP 패킷의 특성에 따라 리소스 액세스를 허용하거나 거부합니다.

VPC 방화벽 규칙

VPC 방화벽 규칙이 특정 네트워크에 적용됩니다. VPC 방화벽 규칙을 사용하면 지정한 구성을 기준으로 VM 인스턴스 간의 연결을 허용하거나 거부할 수 있습니다. 사용 설정한 VPC 방화벽 규칙은 인스턴스의 구성, 운영체제, VM이 완전히 부팅되었는지 여부와 상관없이 인스턴스를 보호할 수 있도록 항상 실행됩니다.

모든 VPC 네트워크는 분산형 방화벽으로 작동합니다. 방화벽 규칙은 네트워크 수준에서 정의되지만 연결은 인스턴스별로 허용되거나 거부됩니다. VPC 방화벽 규칙은 인스턴스와 다른 네트워크 사이뿐만 아니라 동일한 네트워크 내의 개별 인스턴스 간에 존재하는 것으로 생각할 수 있습니다.

계층식 방화벽 정책

계층식 방화벽 정책을 사용하면 기업 전체에 일관된 방화벽 정책을 만들고 적용할 수 있습니다. 이러한 정책에는 연결을 명시적으로 거부하거나 허용할 수 있는 규칙이 포함됩니다. 계층식 방화벽 정책을 조직 리소스 전체 또는 개별 폴더에 할당할 수 있습니다.

패킷 미러링

패킷 미러링은 VPC 네트워크의 특정 인스턴스 트래픽을 클론하여 검사를 위해 수집기로 전달합니다. 패킷 미러링은 페이로드와 헤더를 포함한 모든 트래픽과 패킷 데이터를 캡처합니다. 인그레스 및 이그레스 트래픽 모두에, 인그레스 트래픽에만 또는 이그레스 트래픽에만 미러링을 구성할 수 있습니다. 미러링은 네트워크가 아닌 VM 인스턴스에서 수행됩니다.

네트워크 가상 어플라이언스

네트워크 가상 어플라이언스를 사용하면 온프레미스 환경의 제어와 일관된 보안 및 규정 준수 제어를 가상 네트워크에 적용할 수 있습니다. Google Cloud Marketplace에서 제공되는 VM 이미지를 각각 다른 VPC 네트워크에 연결된 여러 네트워크 인터페이스가 있는 VM에 배포하여 다양한 네트워크 가상 기능을 수행하면 됩니다.

가상 어플라이언스의 일반적인 사용 사례는 다음과 같습니다.

  • 차세대 방화벽(NGFW) NGFW는 VPC 방화벽 규칙에서 사용할 수 없는 기능을 제공하는 VM으로 실행되는 중앙 집중식 방화벽 집합으로 구성됩니다. NGFW 제품의 일반적인 기능에는 애플리케이션 레이어의 딥 패킷 검사(DPI)와 방화벽 보호가 있습니다. 일부 NGFW는 이 목록의 뒷부분에 설명된 대로 TLS/SSL 트래픽 검사 및 기타 네트워킹 기능도 제공합니다.
  • 침입 감지 시스템/침입 방지 시스템(IDS/IPS) 네트워크 기반 IDS는 잠재적 악성 트래픽에 대한 가시성을 제공합니다. 침입을 방지하기 위해 IPS 기기는 악성 트래픽이 대상에 도달하지 못하도록 차단할 수 있습니다.
  • SWG(Secure Web Gateway). SWG는 기업이 인터넷을 오가는 트래픽에 기업 정책을 적용할 수 있게 하여 인터넷 위협을 차단합니다. 이 작업은 URL 필터링, 악성 코드 감지, 액세스 제어를 사용하여 수행됩니다.
  • 네트워크 주소 변환(NAT) 게이트웨이 NAT 게이트웨이는 IP 주소와 포트를 번역합니다. 이 같은 변환은 IP 주소가 겹치지 않도록 하는 데 도움이 됩니다. Google Cloud는 Cloud NAT를 관리형 서비스로 제공하지만 이 서비스는 온프레미스 또는 다른 VPC 네트워크로 이동하는 트래픽이 아닌 인터넷으로 이동하는 트래픽에만 사용할 수 있습니다.
  • 웹 애플리케이션 방화벽(WAF) WAF는 웹 애플리케이션으로 이동하는 악성 HTTP(S) 트래픽을 차단하도록 설계되었습니다. Google Cloud는 Google Cloud Armor 보안 정책을 통해 WAF 기능을 제공합니다. 정확한 기능은 WAF 공급업체마다 다르므로 필요한 사항을 파악하는 것이 중요합니다.

Cloud IDS

Cloud IDS는 네트워크에 대한 침입, 멀웨어, 스파이웨어, 명령어 및 제어 공격에 대한 위협 감지를 제공하는 침입 감지 서비스입니다. Cloud IDS는 미러링된 트래픽을 수신하는 VM이 포함된 Google에서 관리하는 피어링된 네트워크를 만들어 작동합니다. 그러면 미러링된 트래픽이 Palo Alto Networks 위협 보호 기술로 검사되어 고급 위협 감지 기능이 제공됩니다.

Cloud IDS는 서브넷 내 트래픽에 대한 완전한 가시성을 제공하므로 VM 간 통신을 모니터링하고 측면 이동을 감지할 수 있습니다.

Cloud NAT

Cloud NAT는 애플리케이션을 위한 완전 관리형 소프트웨어 정의 네트워크 주소 변환 지원을 제공합니다. 외부 IP 주소가 없는 VM에서 인터넷 연결 트래픽에 대한 소스 네트워크 주소 변환(소스 NAT 또는 SNAT)을 사용 설정합니다.

방화벽 통계

방화벽 통계는 방화벽 규칙을 이해하고 최적화하는 데 도움이 됩니다. 방화벽 규칙이 사용되는 방식에 대한 데이터를 제공하고, 잘못된 구성을 노출하고, 더 엄격할 수 있는 규칙을 식별합니다. 또한 머신러닝을 사용하여 방화벽 규칙의 향후 사용을 예측하므로 권한이 과도하게 부여된 것으로 보이는 규칙을 삭제할지 아니면 강화할지 여부를 정보를 기반으로 결정할 수 있습니다.

네트워크 로깅

여러 Google Cloud 제품을 사용하여 네트워크 트래픽을 로깅하고 분석할 수 있습니다.

방화벽 규칙 로깅을 사용하면 방화벽 규칙의 영향을 감사, 확인, 분석할 수 있습니다. 예를 들어 트래픽을 거부하도록 설계된 방화벽 규칙이 의도한 대로 작동하는지 확인할 수 있습니다. 방화벽 규칙 로깅은 특정 방화벽 규칙의 영향을 받는 연결 수를 확인해야 하는 경우에도 유용합니다.

연결을 로깅해야 하는 각 방화벽 규칙에 방화벽 규칙 로깅을 개별적으로 사용 설정합니다. 방화벽 규칙 로깅은 방화벽 규칙의 작업(허용 또는 거부) 또는 방향(인그레스 또는 이그레스)에 관계없이 모든 방화벽 규칙에 대한 옵션입니다.

VPC 흐름 로그는 Google Kubernetes Engine(GKE) 노드로 사용되는 인스턴스를 포함한 VM 인스턴스에서 전송되거나 수신되는 네트워크 흐름의 샘플을 기록합니다. 이러한 로그를 네트워크 모니터링, 포렌식, 실시간 보안 분석, 비용 최적화에 사용할 수 있습니다.

서비스 네트워킹

서비스 네트워킹 요소는 요청을 전달해야 하는 위치(DNS, 서비스 디렉터리)를 서비스에 알리는 조회 서비스를 제공하고 올바른 위치(Private Service Connect, Cloud Load Balancing)에 대한 요청을 가져옵니다.

Cloud DNS

워크로드는 도메인 이름을 사용하여 액세스합니다. Cloud DNS는 우수한 안정성과 짧은 지연 시간으로 도메인 이름을 세계 어느 곳에나 있는 IP 주소로 변환해 줍니다. Cloud DNS는 공개 및 비공개 관리형 DNS 영역을 모두 제공합니다. 공개 영역은 공개 인터넷에서 노출되지만 비공개 영역은 지정된 VPC 네트워크 하나 이상에서만 노출됩니다.

Cloud Load Balancing

Google Cloud 내에서 부하 분산기는 중요한 구성요소입니다. 트래픽을 다양한 서비스로 라우팅하여 속도와 효율성을 보장하고 내부 및 외부 트래픽 모두의 전역적 보안을 보장합니다.

부하 분산기를 사용하면 여러 클라우드 또는 하이브리드 환경에서 트래픽을 라우팅하고 확장할 수 있습니다. 따라서 Cloud Load Balancing은 애플리케이션이 어디에 있든 호스팅되는 위치가 몇 개든 관계없이 애플리케이션을 확장할 수 있는 '현관문'이라 할 수 있습니다. Google은 다양한 유형의 부하 분산(전역 및 리전, 외부 및 내부, 레이어 4 및 레이어 7)을 제공합니다.

서비스 디렉터리

서비스 디렉터리를 사용하면 서비스 인벤토리를 관리하여 서비스를 게시, 검색, 연결할 수 있는 안전한 단일 위치를 제공할 수 있으며 ID 기반 액세스 제어가 모든 작업을 뒷받침합니다. 이렇게 하면 이름이 지정된 서비스와 엔드포인트를 등록할 수 있습니다. 수동으로 또는 Private Service Connect, GKE, Cloud Load Balancing과의 통합을 사용하여 등록할 수 있습니다. 명시적 HTTP 및 gRPC API와 Cloud DNS를 사용하여 서비스를 검색할 수 있습니다.

서비스 메시: Anthos Service Mesh 및 Traffic Director

Anthos Service Mesh 및 Traffic Director는 서비스 메시 아키텍처의 풍부한 트래픽 관리 및 보안 정책 집합을 사용하여 모두 복잡한 분산형 애플리케이션을 쉽게 실행할 수 있도록 설계되었습니다. 두 제품은 지원하는 환경, 제품의 Istio API, 전역 부하 분산 기능에서 차이가 있습니다.

Anthos Service Mesh는 Google Cloud와 온프레미스에서의 Kubernetes 기반 리전 및 전역 배포에 적합하며, 관리형 Istio 제품을 활용합니다.

Traffic Director는 Google Cloud에서 전 세계에 배포된 상태 및 부하 인식 서비스를 제공하는 네트워킹 사용 사례에 적합합니다. Traffic Director는 사이드카 또는 게이트웨이로 작동하는 Envoy 프록시를 사용하거나 프록시리스 gRPC 워크로드를 사용하여 워크로드를 관리합니다.

다음 표에는 Traffic Directory 및 Anthos Service Mesh의 기능이 요약되어 있습니다.

Anthos Service Mesh Traffic Director
배포 유형 Kubernetes VM, Kubernetes
환경 Google Cloud, 온프레미스, 멀티 클라우드 Google Cloud, 온프레미스, 멀티 클라우드
배포 범위 리전 및 제휴 리전 글로벌
API 노출 영역 Istio 서비스 라우팅(Kubernetes 게이트웨이 모델)
네트워크 연결 Envoy 사이드카 Envoy 사이드카, 프록시리스 gRPC
백엔드 상태를 기준으로 한 전역 부하 분산 예(Kubernetes 기반) 예
백엔드 로드를 기준으로 한 전역 부하 분산 아니요 예
워크로드 mTLS(제로 트러스트)의 관리형 ID 예 예(GKE만 해당)

Google에서 BeyondProd 아키텍처를 사용하여 엔드 투 엔드 제로 트러스트 분산형 아키텍처 환경을 빌드하는 방법을 자세히 설명한 바 있습니다. 네트워크 경계와 서비스 인증 및 승인 외에도 BeyondProd는 신뢰할 수 있는 컴퓨팅 환경, 코드 출처, 배포 출시가 안전한 분산형 제로 트러스트 서비스 아키텍처를 달성하는 데 어떤 역할을 하는지 자세히 보여줍니다. 제로 트러스트 접근 방식을 채택할 때는 네트워킹 이상으로 확장되는 문제를 고려해야 합니다.

Private Service Connect

Private Service Connect는 단일 엔드포인트를 통해 VPC 네트워크에서 워크로드에 액세스할 수 있도록 하여 서비스 추상화를 만듭니다. 이렇게 하면 두 네트워크가 전체 네트워크 또는 워크로드 자체가 아닌 서비스만 소비자에게 노출하는 클라이언트-서버 모델에서 통신할 수 있습니다. 서비스 중심 네트워크 모델을 사용하면 네트워크 관리자가 서브넷 또는 VPC가 아닌 네트워크 간에 노출되는 서비스를 추론하여 퍼스트 파티 또는 서드 파티 서비스(SaaS)를 위해 제작자-소비자 모델의 서비스가 소비되도록 지원할 수 있습니다.

Private Service Connect를 사용하면 소비자 VPC가 비공개 IP 주소를 사용하여 Google API 또는 다른 VPC의 서비스에 연결할 수 있습니다.

Private Service Connect를 온프레미스 네트워크로 확장하여 Google API 또는 다른 VPC 네트워크의 관리형 서비스에 연결하는 엔드포인트에 액세스할 수 있습니다. Private Service Connect를 사용하면 레이어 4 또는 레이어 7에서 서비스를 소비할 수 있습니다.

레이어 4에서 Private Service Connect를 사용하려면 제작자가 Private Service Connect 전용 서브넷을 하나 이상 만들어야 합니다. 이러한 서브넷을 NAT 서브넷이라고도 합니다. Private Service Connect는 Private Service Connect 서브넷 중 하나에서 선택된 IP 주소를 사용하여 소스 NAT를 수행하여 서비스 프로듀서에게 요청을 라우팅합니다. 이 접근 방식에서는 소비자와 생산자 사이에 IP 주소를 겹쳐서 사용할 수 있습니다.

레이어 7에서는 내부 애플리케이션 부하 분산기를 사용하여 Private Service Connect 백엔드를 만들 수 있습니다. 내부 애플리케이션 부하 분산기를 사용하면 URL 맵을 사용하여 제공되는 서비스를 선택할 수 있습니다. 자세한 내용은 Private Service Connect 백엔드 정보를 참조하세요.

비공개 서비스 액세스

비공개 서비스 액세스는 VPC 네트워크와 Google 또는 서드 파티 소유 네트워크 간의 비공개 연결입니다. Google 또는 서비스를 제공하는 서드 파티를 서비스 제작자라고 합니다. 비공개 서비스 액세스는 VPC 네트워크 피어링을 사용하여 연결을 설정하며, 제작자 및 소비자 VPC 네트워크가 서로 피어링되어야 합니다. 이것은 단일 비공개 IP 주소를 서브넷에 프로젝션할 수 있는 Private Service Connect와 다릅니다.

비공개 연결을 통해 VPC 네트워크의 VM 인스턴스와 액세스하는 서비스가 내부 IP 주소를 사용하여 독점적으로 통신할 수 있습니다. VM 인스턴스는 비공개 서비스 액세스를 통해 사용 가능한 서비스에 도달하기 위해 인터넷 액세스 또는 외부 IP 주소가 필요하지 않습니다. Cloud VPN 또는 Cloud Interconnect를 사용해 온프레미스 호스트에서 서비스 제작자의 네트워크에 도달할 수 있는 방법을 제공하여 비공개 서비스 액세스를 온프레미스 네트워크로 확장할 수도 있습니다. 비공개 서비스 액세스를 사용하여 지원되는 Google 관리 서비스 목록은 Virtual Private Cloud 문서의 지원되는 서비스를 참조하세요.

서버리스 VPC 액세스

서버리스 VPC 액세스를 사용하면 Cloud Run, App Engine, Cloud Functions와 같은 서버리스 환경에서 호스팅되는 서비스에서 VPC 네트워크에 직접 연결할 수 있습니다. 서버리스 VPC 액세스를 구성하면 내부 DNS 및 내부 IP 주소를 사용하여 서버리스 환경에서 VPC 네트워크로 요청을 보낼 수 있습니다. 이러한 요청에 대한 응답도 가상 네트워크를 사용합니다.

서버리스 VPC 액세스는 내부 트래픽이 서버리스 VPC 액세스 커넥터를 통해 서버리스 환경에서 전송된 요청에 대한 응답인 경우에만 VPC 네트워크에서 서버리스 환경으로 내부 트래픽을 전송합니다.

서버리스 VPC 액세스에는 다음과 같은 이점이 있습니다.

  • VPC 네트워크로 전송된 요청은 절대 인터넷에 노출되지 않습니다.
  • 서버리스 VPC 액세스를 통한 통신은 인터넷을 통한 통신에 비해 지연 시간이 짧을 수 있습니다.

서비스 보안

서비스 보안은 요청자의 ID를 기준으로, 또는 개별 패킷의 특성 대신 패킷 패턴에 대한 개괄적인 이해를 기반으로 리소스에 대한 액세스를 차단합니다.

DDoS/WAF용 Google Cloud Armor

Google Cloud Armor는 여러 유형의 위협으로부터 웹 애플리케이션 및 서비스를 보호할 수 있는 웹 애플리케이션 방화벽(WAF) 및 DDoS 완화 서비스입니다. 이러한 위협으로는 DDoS 공격, 교차 사이트 스크립팅(XSS) 및 SQL 삽입(SQLi) 등의 웹 기반 공격, 사기 및 자동화 기반 공격 등이 있습니다.

Google Cloud Armor는 Google의 글로벌 에지에서 들어오는 요청을 검사합니다. 일반적인 웹 공격을 검사하는 기본 제공되는 웹 애플리케이션 방화벽 규칙 집합과 정상 트래픽 모델을 빌드한 후 비정상 트래픽을 감지하는 고급ML 기반 공격 감지 시스템이 포함되어 있습니다. 마지막으로 Google Cloud Armor는 Google reCAPTCHA Enterprise와 통합되어 엔드포인트 원격 분석 및 클라우드 원격 분석을 모두 사용하여 정교한 사기 및 자동화 기반 공격을 감지하고 중지하는 데 도움이 됩니다.

IAP(Identity-Aware Proxy)

IAP(Identity-Aware Proxy)는 Google Cloud에서 실행 중이거나 하이브리드 네트워킹 기술을 사용해 Google Cloud에 연결된 클라우드 기반 애플리케이션 및 VM에 컨텍스트 인식 액세스 제어를 제공합니다. IAP는 사용자 ID를 확인하고 다양한 컨텍스트 속성을 기준으로 사용자 요청이 신뢰할 수 있는 소스에서 발생한 것인지 확인합니다. IAP는 또한 기업 사용자의 SSH/RDP 액세스를 위한 TCP 터널링을 지원합니다.

VPC 서비스 제어

VPC 서비스 제어를 사용하면 Cloud Storage 및 BigQuery와 같은 Google Cloud 서비스에서 데이터 무단 반출의 위험을 완화할 수 있습니다. VPC 서비스 제어를 사용하면 승인된 환경에서만 Google Cloud 서비스가 사용되도록 보장하는 데 도움이 됩니다.

VPC 서비스 제어를 사용하면 서비스 계정 및 VPC 네트워크와 같은 특정 클라우드 기반 ID 구성으로 액세스를 제한하여 지정한 서비스의 리소스와 데이터를 보호하는 경계를 만들 수 있습니다. 경계가 생성되면 경계 내에서 요청이 발생하지 않는 한 지정된 Google 서비스에 대한 액세스가 거부됩니다.

콘텐츠 전송

콘텐츠 전송 블록은 애플리케이션 및 콘텐츠의 전송 최적화를 제어합니다.

Cloud CDN

Cloud CDN은 Google의 글로벌 에지 네트워크를 사용하여 사용자에게 가장 가까운 지점에서 콘텐츠를 전송하여 정적 콘텐츠 가속화를 제공합니다. 웹사이트 및 애플리케이션의 지연 시간을 줄이는 데 도움이 됩니다.

Media CDN

Media CDN은 Google의 미디어 전송 솔루션이며 처리량이 많은 이그레스 워크로드를 위해 빌드되었습니다.

관측 가능성

관측 가능성 요소는 네트워크를 파악하고 문제 해결, 문서화, 조사, 문제 해결에 사용할 수 있는 통계를 제공합니다.

Network Intelligence Center

Network Intelligence Center는 네트워크 관측 가능성의 다양한 측면을 다루는 여러 제품으로 구성됩니다. 각 제품은 다른 측면에 초점을 두며 관리자, 설계자, 실무자에게 네트워크 상태 및 문제에 대한 풍부한 정보를 제공합니다.

참조 아키텍처

다음 문서에서는 클라우드 내, 인터넷 연결, 하이브리드와 같은 다양한 워크로드 유형의 참조 아키텍처를 보여줍니다. 이러한 워크로드 아키텍처는 이 문서의 앞부분에서 설명한 구성요소와 아키텍처 패턴을 사용하여 실현되는 클라우드 데이터 영역을 기반으로 합니다.

참조 아키텍처를 사용하여 클라우드에서 워크로드를 마이그레이션하거나 빌드하는 방법을 설계할 수 있습니다. 그러면 워크로드가 클라우드 데이터 영역을 기반으로 하며 아키텍처를 사용합니다. 이 문서에서 모든 참조 아키텍처 집합을 제공하는 것은 아니지만 가장 일반적인 시나리오를 다루고 있습니다.

클라우드 데이터 영역 보호 아키텍처에 설명된 보안 아키텍처 패턴과 마찬가지로 실제 서비스에서는 이러한 설계들을 조합하여 사용할 수 있습니다. 이 문서에서는 각 워크로드 유형과 각 보안 아키텍처의 고려사항을 설명합니다.

다음 단계