VMware Engine 보안 권장사항
이 문서는 Mware Engine에 이미 익숙한 사용자를 대상으로 작성되었으며 Google Cloud VMware Engine 관리 및 구성을 위한 권장 보안 권장사항에 대해 설명합니다. 초보자의 경우에는 기본 요건 및 VMware Engine 보안에 대해 먼저 알아보세요.
VMware Engine에는 보안을 위한 공유 책임 모델이 있습니다. 클라우드에서 신뢰할 수 있는 보안은 서비스 제공업체로서 Google 및 고객의 공유 책임을 통해 이루어집니다. 이러한 권장사항을 따르면 시간을 절약하고 오류를 방지하며 장애점의 영향을 완화할 수 있습니다.
환경의 모든 트래픽 흐름 식별 및 파악
프라이빗 클라우드에서 워크로드와 관리 인터페이스를 보호하려면 환경의 모든 트래픽 흐름을 식별하고 이해하는 것이 중요합니다. VMware Engine의 주요 트래픽 흐름 목록은 VMware Engine용 프라이빗 클라우드 네트워킹 문서에서 확인할 수 있습니다.
VMware Engine은 비공개 서비스 액세스(PSA)를 사용하여 VMware Engine 프라이빗 클라우드 네트워크에서 VPC 네트워크로 비공개 네트워크 연결을 노출합니다. Google Cloud 환경의 VPC 또는 온프렘 네트워크에서 인그레스 트래픽은 Google 관리형 서비스 프로듀서 네트워크를 통과합니다.
인터넷 인그레스에 VMware Engine의 공개 IP 서비스 사용
인터넷 트래픽은 VMware Engine의 공개 IP 서비스를 사용하여 프라이빗 클라우드에 직접 들어갈 수 있습니다. 또는 인터넷 트래픽이 Google Cloud에서 공개 부하 분산기를 사용하여 들어갈 수 있습니다. 이 경우 트래픽은 비공개 서비스 액세스를 통해 다른 인그레스 트래픽과 마찬가지로 라우팅됩니다. 이러한 옵션은 상호 배타적입니다. URL 필터링, IPS/IDS 또는 Google Cloud 환경의 중앙 인스턴스 또는 서비스에서 제공하는 트래픽 검사와 같은 인터넷 트래픽에 커스텀 제어가 필요한 경우 VPC 및 서비스 프로듀서 공유 VPC를 통해 인터넷 연결 트래픽을 라우팅해야 합니다.
이를 수행할 수 없거나 프라이빗 클라우드 내에 구현된 제어 기능이 있는 경우 VMware Engine에 공개 IP 주소 서비스를 포함하는 것이 좋습니다. 또한 스테이트풀(Stateful) 방화벽 규칙을 사용하여 애플리케이션에 적용되지 않는 인터넷의 트래픽 패턴을 거부하는 것을 권장합니다.
VMware Engine NSX-T에서 게이트웨이 및 분산 방화벽의 North-South 및 East-West 방화벽 규칙 분리
tier-1 논리 라우터에서 NSX-T에 분산 방화벽(DFW)을 구성하여 가상 레이어 2 도메인 간에 내부 트래픽을 분류합니다. NSX DFW는 세그먼트 간에 (내부)East-West 네트워크 트래픽을 처리하도록 설계되었으며 세그먼트 내에서 개별 인스턴스 간의 트래픽을 허용하거나 거부하는 방화벽 규칙을 허용합니다.
세분화된 네트워크 액세스 제어를 위해서는 기본적으로 인스턴스 간 네트워크 트래픽을 거부하도록 DFW에 제한된 기본 정책을 적용해야 합니다. DFW를 사용하여 애플리케이션 간 및 애플리케이션 내 서비스 간 트래픽을 구체적으로 허용합니다.
프라이빗 클라우드에 들어오고 나가는 North-South 트래픽을 제어하도록 NSX 게이트웨이 방화벽을 구성하세요.
NSX 게이트웨이 방화벽은 North-South 트래픽을 제어하도록 설계되었으며 경계의 트래픽을 다른 보안 영역으로 제어하는 등의 사용 사례에 권장됩니다. 전체 프라이빗 클라우드에 대해 North-South 트래픽을 일관되게 구성해야 하는 경우 tier-0 라우터에서 게이트웨이 방화벽을 구성합니다. 각 개별 NSX-T 세그먼트에 North-South 트래픽을 구성해야 하는 경우 tier-1 라우터에 게이트웨이 방화벽을 구성합니다.
NSX-T 방화벽 외에도 VPC 방화벽을 활용하여 VMware Engine 프라이빗 클라우드의 워크로드와 VPC의 워크로드 간의 East-West 트래픽을 허용하고 차단하는 것이 좋습니다. VMware Engine 워크로드에서 Compute Engine 인스턴스로의 인그레스는 기본적으로 의식적으로 열린 트래픽만으로 제한되어야 합니다.
관리 어플라이언스는 물론 vSphere/vSAN CIDR 범위까지 이그레스는 VPC 방화벽을 사용하여 VPC로부터 차단되어야 합니다. 네트워크 내의 신뢰할 수 있는 호스트 및 IP 주소에서 관리 어플라이언스로의 이그레스만 엽니다. 관리 어플라이언스가 NSX-T 세그먼트 내에 있지 않으므로 액세스를 제한하기 위해 DFW 규칙이 적용되지 않는다는 점에 유의해야 합니다.
NSX-T에서 제로 트러스트 보안 원칙 및 마이크로세그멘테이션 적용
NSX-T DFW를 활용하여 개별 가상 머신처럼 세분화된 보안 세그먼트에 대한 트래픽 제어를 구현합니다. 기본적으로 거부되는 개별 VM 간의 트래픽을 보호하는 이 원칙을 '마이크로세그멘테이션'이라고도 하며, 레이어 3 도메인 간의 기존 방화벽 구현보다 세분화된 접근방식입니다.
DFW는 프라이빗 클라우드의 모든 VMware Engine vSphere 호스트에서 하이퍼바이저 커널에서 사용 설정되며 동일한 또는 별도의 NSX 세그먼트에 있는 워크로드 간의 트래픽 흐름을 제어할 수 있습니다. VM을 송수신하는 트래픽을 허용하는 방화벽 규칙은 VM 태그 또는 이름 일치와 같은 유연한 멤버십 기준을 포함할 수 있는 정책 그룹으로 VM을 구성하여 정의할 수 있습니다.
마이크로세그멘테이션을 사용하면 원하는 트래픽 패턴을 명시적으로 허용해야 하는 세분화된 트래픽 제어로 네트워크를 구현할 수 있습니다. 모든 네트워크 흐름이 암시적 신뢰가 아닌 ID 및 기기 확인 프로세스에 의해 제어되는 보안 개념을 제로 트러스트 보안이라고도 합니다.
IPS/IDS 기능을 위해 Cloud Marketplace 포털에서 타사 방화벽 어플라이언스 배포
네트워크의 나머지 부분에서 또는 NSX-T 네트워크 세그먼트 간에 프라이빗 클라우드로의 인그레스 트래픽을 위한 IDS/IPS 기능이 포함된 고급 레이어 7 보안이 필요한 경우 타사 방화벽 어플라이언스를 배포하는 것이 좋습니다. 타사 어플라이언스는 Google Cloud 네트워크의 두 VPC 또는 NSX-T와 통합된 프라이빗 클라우드 내의 멀티 NIC 어플라이언스로 배포할 수 있습니다.
IPS/IDS, DDoS, SSL 오프로드 등 다양한 고급 보안 사용 사례에 사용할 수 있는 중앙화된 어플라이언스가 있는 VMware Engine 아키텍처 심층 탐구는 클라우드 아키텍처 센터의 중앙화된 어플라이언스를 사용하여 문서 네트워크 보안을 참조하세요.
Google Cloud Armor를 사용하여 DDoS 공격으로부터 VMware Engine의 웹 서비스 보호
고객 VPC를 통해 VMware Engine의 워크로드로 인그레스 트래픽을 라우팅하는 경우 VMware Engine 워크로드를 Traffic Director 뒤의 하이브리드 네트워크 엔드포인트 그룹에 배치하고 외부 HTTP(S) 부하 분산기를 활용하는 것이 좋습니다. 두 설정 모두 공개용 애플리케이션에 Google Cloud Armor를 포함하여 DDoS 공격 및 SQL 삽입이나 교차 사이트 스크립팅과 같은 일반적인 취약점을 완화할 수 있습니다.
Envoy 프록시 또는 Certificate Authority Service 통합을 사용한 고급 트래픽 관리와 같은 서비스 메시 기능이 필요한 경우 Traffic Director를 사용하는 것이 좋습니다. 다른 모든 경우에는 외부 HTTP(S) 부하 분산기를 사용하는 것을 권장합니다.
다음 설정 중 하나에서 VMware Engine 워크로드를 하이브리드 NEG에 추가하는 방법에 대한 문서를 따르세요.
인터넷 액세스 없이 비공개로 Google Cloud 서비스에 연결
VMware Engine 프라이빗 클라우드 워크로드는 비공개 Google 액세스를 사용하여 Cloud Storage API와 같은 Google Cloud API에 액세스할 수 있습니다. 이그레스 비용 및 지연 시간이 감소하므로 비공개 Google 액세스를 사용하여 인터넷을 통해 트래픽을 전송하지 않고도 Google 서비스에 액세스하는 것이 좋습니다. 이렇게 하면 Google API 액세스만 필요한 워크로드에 대해 인터넷으로 가는 네트워크 경로가 필요하지 않습니다. 비공개 Google 액세스에 대해 자세히 알아보고 기술 세부정보 및 구성 단계를 확인하세요.
마찬가지로 Cloud SQL 또는 Memorystore 인스턴스와 같은 서비스 프로듀서 네트워크에서 Google Cloud 리소스에 액세스해야 하는 VMware Engine 워크로드는 PSA를 사용하여 비공개로 연결해야 합니다. 이 주제에 대한 자세한 내용은 VMware Engine의 PSA 섹션을 참조하세요.
온프레미스 환경과 Google Cloud 간의 통신 암호화
온프렘 시스템과 통신해야 하는 VMware Engine의 워크로드는 암호화된 채널을 통해 연결되어야 합니다. 온프렘 데이터 센터와 Google Cloud 간의 전송 중인 데이터 암호화에 대한 계층화된 접근 방식을 권장합니다. 온프렘과 Google Cloud 간의 연결은 IPSec 터널로 Cloud VPN을 설정하거나 Interconnect의 VLAN 연결에서 기본 IPSec을 사용하여 암호화할 수 있습니다. 또한 TLS를 사용하는 애플리케이션 구성요소 간에 애플리케이션 레이어 암호화를 사용 설정해야 합니다.
VPC 서비스 제어를 사용하여 데이터 유출 방지
Cloud Storage 버킷 및 BigQuery 데이터 세트와 같은 민감한 리소스를 VPC 서비스 제어 경계에 배치하여 VPC 서비스 제어를 사용하여 데이터 무단 반출 위험을 완화하는 것이 좋습니다. 경계 내부의 데이터에 액세스해야 하는 워크로드도 경계에 배치해야 합니다. 특히 프라이빗 클라우드를 호스팅하는 Google Cloud 프로젝트가 VPC 서비스 제어로 보호되는 리소스에 액세스하려면 VPC 서비스 제어 경계의 일부여야 합니다.
VMware Engine 프로듀서 서비스 API를 경계로 허용하도록 VPC 서비스 제어 구성에서 인그레스 및 이그레스 정책을 구성해야 합니다. 설정에 대한 자세한 안내는 VMware Engine의 VPC 서비스 제어에 대한 문서 페이지를 참조하세요.
VMware Engine IAM 및 권한
다음 섹션에서는 VMware Engine 환경에서 사용자 권한에 대한 권장사항을 소개합니다. VMware Engine 환경과 프라이빗 클라우드가 배포된 Google Cloud 프로젝트 내에서 권한을 관리하는 것이 중요합니다.
사전 정의된 역할 또는 커스텀 역할을 사용하여 액세스 권한 부여
VMware Engine의 vSphere 역할 및 권한 관리 방법은 다른 VMware Engine 환경에서 활용할 때와 동일한 방식으로 활용할 수 있습니다. 그러나 클러스터 배포와 같은 활동은 Identity and Access Management(IAM)에서 권한이 필요합니다. 다음 표에는 관련 액세스 관리자, 권한을 부여하는 ID 소스, 사용 설정하는 활동 예시가 나와 있습니다.
| 플랫폼 | 구성요소 | ID 소스 | 권한 구성 위치 | 활동 예시 |
|---|---|---|---|---|
| Google Cloud | VMware Engine 포털 | Cloud ID | Identity and Access Management | 예: 프라이빗 클라우드 배포 및 취소, 클러스터 배포 및 취소 |
| VMware Engine | vCenter | LDAP | vCenter UI의 호스트 및 클러스터, VM 및 폴더, Datastore | 예: VM 만들기, VM 폴더 만들기, Datastore 객체 만들기 및 삭제 |
| NSX-T | LDAP | NSX-T Manager UI의 '사용자 및 역할' | 예: NSX 세그먼트 생성, 방화벽 구성, 부하 분산기 구성 | |
| vCenter | VM 게스트 운영체제 | 예: Active Directory, LDAP, 로컬 사용자 | 게스트 운영체제 | 예: SSH 또는 RDP 로그인, 파일 작업 |
Google Cloud IAM에는 VMware Engine 포털에 대한 권한이 있는 사전 정의된 두 가지 역할이 있습니다.
- VMware Engine 서비스 관리자 - Google Cloud에서 VMware Engine 서비스에 대한 전체 액세스 권한을 부여합니다.
- VMware Engine 서비스 뷰어 - Google Cloud에서 VMware Engine 서비스에 대한 읽기 전용 액세스 권한을 부여합니다.
이러한 권한은 VMware Engine 포털의 작업과 관련이 있으며 API 또는 CLI의 작업과는 관련이 없습니다. 기본 역할에는 VMware Engine 서비스(소유자, 편집자)를 관리하거나 서비스 세부정보(뷰어)를 확인하는 기능이 포함되어 있습니다. 일반적으로 보다 세분화된 권한을 제공하므로 기본 역할 대신 사전 정의된 역할을 사용하는 것이 좋습니다.
API 또는 CLI를 사용하는 서비스 계정을 사용한 VMware Engine에 대한 프로그래매틱 액세스는 VMware Engine에만 적용되는 더 세분화된 권한을 포함하므로 사전 정의된 역할 또는 커스텀 역할을 사용하여 제한되어야 합니다. 사전 정의된 역할의 권한의 특정 하위 집합만 필요한 태스크에만 프로그래매틱 액세스가 사용되는 경우 커스텀 역할을 만드는 것이 좋습니다.
조직의 리소스 계층 구조에서 IAM 역할 할당에 적절한 위치를 선택합니다. 한 프로젝트에서 모든 VMware Engine 프라이빗 클라우드를 실행하는 경우 프로젝트 수준에서 역할만 할당할 수 있습니다. 프라이빗 클라우드가 별도의 프로젝트에 배치되는 기술적 또는 조직 요구사항이 있는 경우 프라이빗 클라우드에 사용되는 프로젝트에 공통된 폴더에서 필요한 역할을 정의합니다.
vCenter, NSX-T 또는 HCX 내에서만 수행해야 하는 활동에는 Cloud IAM 권한이 필요하지 않습니다. 이러한 환경만 운영하는 직원은 앞에서 나열된 IAM 역할이 필요하지 않습니다. 대신 vCenter 및 NSX-T에서 구성된 권한이 있는 LDAP ID를 사용해야 합니다. VMware Engine 서비스 관리자 또는 VMware Engine 서비스 뷰어 역할은 vCenter의 강력한 CloudOwner 사용자 계정 및 NSX-T용 관리자 사용자 계정에 액세스 권한을 부여하므로 매우 적은 수의 사용자에게만 제공하는 것이 좋습니다. 이러한 사용자 계정은 초기 설정 또는 긴급 상황 처리 절차에만 사용해야 합니다.
관리자 액세스 제한 및 적극적으로 감사
VMware Engine 서비스 관리자 역할은 매우 강력하며, VMware Engine 프라이빗 클라우드 및 해당 클러스터의 수명 주기를 관리해야 하는 사용자에게만 할당되어야 합니다. 일반적으로 클러스터와 노드의 수동 추가 또는 삭제는 자주 발생하지 않으며 결제 또는 클러스터 가용성에 큰 영향을 미칠 수 있습니다. 이 역할은 조직의 소수의 사용자에게만 할당합니다.
VMware Engine에 사용되는 프로젝트 또는 리소스 계층 구조의 상위 수준 중 하나에서 직접 VMware Engine 서비스 관리자 역할이 할당된 사용자를 정기적으로 감사합니다. 이 감사에는 VMware Engine과 관련된 중요한 권한이 포함된 기본 편집자 및 소유자 역할과 같은 다른 역할이 포함되어야 합니다. IAM 역할 추천자와 같은 서비스를 사용하여 과도한 권한이 있는 역할을 식별할 수 있습니다.
LDAP 또는 Active Directory ID 소스 구성
Active Directory와 같이 LDAP 인증을 지원하는 ID 공급업체를 구성하여 vCenter 및 NSX Manager에 대한 사용자 인증을 사용 설정해야 합니다. 이는 중앙 ID 수명 주기 관리, 그룹 관리, 비밀번호 관리 등을 수행하는 데 권장되는 방법입니다. 통합 Windows 인증을 위해 vCenter 및 NSX-T를 Active Directory에 직접 조인하는 기능은 지원되지 않습니다.
기본 제공 서비스 계정의 비밀번호 순환
VMware Engine은 프라이빗 클라우드(예: vCenter, NSX-T, HCX)의 관리 어플라이언스에 액세스하기 위한 사용자 인증 정보를 생성합니다. 기본 vCenter 서비스 계정 CloudOwner@gve.local과 기본 NSX-T 서비스 계정 관리자의 비밀번호를 순환하는 프로세스를 설정하는 것이 좋습니다. 두 사용자 계정 모두 초기 구성과 긴급 상황 처리 절차에만 사용해야 하며 비밀번호가 정기적으로 순환되어야 합니다(예: 60일 또는 90일마다). 마찬가지로 타사 도구의 통합에 일반적으로 사용되는 솔루션 사용자 계정의 비밀번호를 정기적으로 순환합니다. 서비스 계정 비밀번호를 자주 순환할수록 악의적인 행위자가 비밀번호를 발견했을 때 유효한 비밀번호일 가능성이 낮아집니다.
VMware Engine 로깅 및 모니터링
다음 섹션에서는 워크로드에 소비되는 리소스를 제공하는 VM 워크로드와 VMware Engine 인프라의 로깅 및 모니터링을 위한 권장사항을 소개합니다.
VMware Engine 로그 및 측정항목 수집
많은 조직이 중앙 집중식 '단일 제어 창'에서 로그를 수집하고 분석하려고 합니다. Google Cloud에서 Cloud Logging 및 Cloud Monitoring 제품은 로그 및 측정항목의 중앙 집중식 관리에 사용할 수 있는 서비스를 제공합니다. VMware Engine은 독립형 에이전트를 사용하여 Cloud Monitoring과 통합할 수 있습니다. 이 구성에서 vCenter는 ESXi CPU 및 메모리 사용률과 같은 측정항목을 Cloud Monitoring으로 전달합니다. vCenter에서 전달하는 측정항목을 기반으로 대시보드를 만들거나 GitHub에 게시된 샘플 대시보드를 시작하는 것이 좋습니다.
VMware Engine 프라이빗 클라우드는 플랫폼 로그를 수집하기 위해 Syslog 로그를 중앙 집중식 로그 애그리게이터로 전달할 수 있습니다. 이 작업은 vCenter 및 NSX-T Syslog 메시지 모두에 대해 수행할 수 있습니다. vCenter에서 Syslog 메시지를 수집, 보관, 분석하는 데에는 관리 권한 사용자(또는 '긴급 상황' 사용자) 로그인을 기반으로 한 실시간 알림과 같이 중요한 보안 사용 사례가 있으며 이는 예외적인 상황에서만 수행해야 합니다. Syslog 메시지를 분석하려면 Fluentd 또는 독립형 에이전트와 같은 Syslog 애그리게이터가 메시지를 Cloud Logging으로 릴레이하도록 구성해야 합니다.
단일 프로젝트의 중앙 대시보드에서 VMware Engine의 로그를 분석하는 것이 좋습니다. VMware Engine 환경이 여러 프로젝트에 걸쳐 있는 경우 로그 싱크 및 모니터링 범위를 구성하여 프로젝트를 추가로 집계해야 합니다.
워크로드 VM 로깅에 Cloud Logging 에이전트 사용
VMware Engine 워크로드 VM은 Logging 에이전트를 사용하여 Cloud Logging API에 직접 로그를 보낼 수 있습니다. Logging 에이전트는 fluentd를 기반으로 하며 일반적인 타사 애플리케이션과 시스템 소프트웨어에서 Cloud Logging으로 로그를 스트리밍합니다. VMware Engine에서 워크로드 VM의 로그 수집 및 분석 방법을 Compute Engine 인스턴스 및 온프레미스 자산(해당하는 경우)의 접근 방식과 맞추는 것이 가장 좋습니다. VMware Engine의 Logging 에이전트 사용은 두 플랫폼의 워크로드가 Cloud Logging에 로그를 전송하도록 Compute Engine의 VM에 사용되는 접근 방식과 일치합니다.
액세스 투명성 및 액세스 승인 정책의 동등한 기능 적용
VMware Engine은 아직 Google Cloud에서 액세스 투명성(AxT) 및 액세스 승인(AxA)을 기본적으로 지원하지 않지만 요청에 따라 동등한 기능을 사용 설정할 수 있는 프로세스를 구현했습니다.
동등한 액세스 투명성을 확보하려면 다음을 포함한 몇 가지 로그 소스를 고려해야 합니다.
- vCenter 로그 - 원격 syslog 서버 구성을 사용하여 내보낼 수 있습니다.
- ESXi 로그 - 원격 syslog 구성을 사용하여 수집할 수 있지만 ESXi syslog 전달을 구성하려면 Google Cloud에 지원 요청을 제출해야 합니다.
엄격한 규제 요구사항이 있는 경우 Google에서 액세스 승인과 동등한 기능을 제공하는 정책을 구현합니다. 이 정책에서 표준 서비스 작업에는 액세스 서비스 운영자가 액세스를 요구하는 이유로 지원 티켓이 생성되어야 합니다.
Google Cloud 액세스 승인 제외가 적용됩니다.
VMware Engine 암호화
다음 섹션에서는 프라이빗 클라우드의 스토리지 암호화에 대한 권장사항과 프라이빗 클라우드의 키 제공업체를 선택할 때 고려해야 할 중요한 요소를 소개합니다.
vSAN 저장 데이터 암호화에 사용 설정된 Google 관리형 키 제공업체 사용
저장 데이터의 암호화는 vSAN 소프트웨어 기반 암호화를 통해 구현됩니다. 기본적으로 VMware Engine은 각 ESXi 클러스터에서 vSAN 암호화를 사용 설정하고 vCenter에서 기본 키 제공업체를 구성합니다. Google에서는 고객이 ESXi 클러스터에서 vSAN 암호화를 사용 설정 상태로 유지해야 하며 vSAN 암호화를 사용 중지하는 것은 VMware Engine의 서비스 약관을 위반합니다. 많은 조직에서 회사 정책의 일환으로 저장 데이터 암호화를 요구하거나 데이터 암호화에 대한 규정(예: NIST, FIPS)을 준수해야 합니다.
각 ESXi 호스트는 무작위로 생성된 서로 다른 데이터 암호화 키(DEK)와 함께 표준 AES-256 XTS 모드를 사용하여 데이터를 암호화합니다. DEK는 키 암호화 키(KEK)를 사용하여 암호화되며 디스크에 암호화된 형식으로만 저장됩니다. vCenter Server는 KEK의 ID만 저장하며 Cloud Key Management Service(KMS)에 저장된 KEK 자체는 저장하지 않습니다. KEK가 유지되는 Cloud KMS의 위치를 선택할 수 있습니다.
Google에서 관리하는 기본 키 제공업체를 사용하는 것이 좋습니다. 그러나 Cloud KMS를 직접 관리해야 하는 경우 지원되는 공급업체 중 하나에서 타사 KMIP 1.1을 준수하는 Cloud KMS를 사용할 수 있습니다. 두 경우 모두 키 제공업체를 사용하여 저장 데이터 및 전송 중인 vMotion 트래픽을 암호화할 수 있습니다.
다음 표에서는 기본 키 제공업체와 타사 Cloud KMS 통합 간의 주요 차이점을 보여줍니다.
| 키 제공업체 | 장점 | 단점 |
|---|---|---|
| 기본 Google 관리형 키 제공업체 |
|
|
| 타사 Cloud KMS 키 제공업체 |
|
|
암호화된 VM의 경우 중복 삭제 효율성이 0에 근접하므로 vSAN Datastore 암호화와 함께 VM 수준 암호화를 사용 설정하지 않는 것이 좋습니다.
조직의 표준에 따라 암호화 키 순환 자동화
VMware Engine vSphere에서 제공하는 기능을 사용하여 KEK 순환을 수행해야 합니다. 이는 기본 키 제공업체와 외부 Cloud KMS를 모두 사용하는 경우입니다. vCenter에서 또는 API를 사용하여 KEK 순환을 시작할 수 있습니다. 조직의 요구사항에 따라 KEK 순환을 자동화하는 것이 좋습니다. GitHub에서 PowerCLI 스크립트 예시를 찾을 수 있습니다.
VMware Engine 백업 및 재해 복구
랜섬웨어, 손상, 사람의 실수와 같은 위협으로부터 데이터를 보호하는 것이 중요합니다. 또한 비즈니스에 중요한 애플리케이션은 데이터를 항상 가상으로 사용해야 하므로 갑작스러운 중단으로부터 데이터를 복구할 시간이 거의 없습니다. 이 섹션에는 데이터의 보안 및 가용성을 유지하기 위한 백업 및 DR 전략을 효과적으로 설계하는 것과 관련된 모든 백업 및 재해 복구의 전체 내용이 포함되지 않았으나, 올바른 VMware Engine 환경 전략을 선택할 때 중요한 고려사항이 포함됩니다.
백업 및 DR 서비스를 사용하여 워크로드 백업
백업 및 DR 서비스를 제공하는 Google Cloud는 Compute Engine 및 Google Cloud VMware Engine의 워크로드 백업을 비롯한 다양한 사용 사례에 사용할 수 있는 중앙 관리형 기본 백업 솔루션을 제공합니다. 백업 및 DR 서비스는 광범위한 워크로드 지원, 공간 효율적, 영구 증분 백업, 유연한 스토리지 옵션과 같은 이점을 제공하기 때문에 워크로드 백업에 권장되는 단일 솔루션입니다.
Google Cloud VMware Engine은 타사 에이전트 기반 백업 솔루션 사용도 지원합니다. 타사 백업 제품 라이선스가 이미 있으면 이 방법을 사용하는 것이 좋습니다. 이러한 유형의 도구 기본 요건은 다음과 같습니다.
- 애플리케이션 수준 백업을 제공해야 합니다.
- 애플리케이션 공급업체 인증을 받아야 합니다.
- VMware Engine에서 vSAN에 대한 인증을 받아야 합니다.
- VMware Engine vStorage API for Data Protection(VADP) 프로토콜 표준을 지원하거나 애플리케이션 수준 백업을 수행해야 합니다.
선택하는 백업 솔루션에 관계없이 백업의 장기 보관을 위해서는 비용 효율적인 스토리지 옵션으로 Cloud Storage를 선택하는 것이 좋습니다. Cloud Storage는 내구성과 비용 효율성이 뛰어난 객체 스토리지입니다. Cloud Storage 버킷은 여러 리전에 스토리지 객체를 자동으로 복제하도록 구성할 수 있으며 이는 멀티 리전 클라우드 토폴로지에 이상적입니다.
또한 Cloud Storage는 수명 기간이 사전 정의된 값을 초과하면 스토리지 객체를 다른 스토리지 계층으로 자동으로 이동하는 수명 주기 정책을 제공하므로 장기 보관에 적합합니다. 특히 비용이 중요한 요인인 경우 비용 효율적인 백업 스토리지 위치 및 중간에서 높은 수준의 RPO에 이 옵션을 사용합니다.
또는 vSAN 스토리지를 선택하여 RPO를 최소화할 수 있습니다. 더 높은 백업 스토리지 비용을 허용할 수 있으며 Cloud Storage로 RPO 요구사항을 충족할 수 없는 경우 이 스토리지 옵션을 사용하세요. VMware Engine 클러스터 크기가 스토리지 제한이 될 위험이 있으므로 장기 보관에는 이 옵션을 사용하지 마세요.
백업 및 DR 서비스로 재해 복구 구현
백업 및 DR 서비스를 사용하여 VMware Engine에서 애플리케이션을 복원하는 것이 좋습니다. VMware Engine을 두 개 이상의 영역에서 사용할 수 있는 경우 리전 내 단일 영역이 중단되지 않도록 프로덕션 워크로드를 보호하려면 프라이빗 클라우드를 리전 내 보조 영역에 배포하고 운영하는 것이 좋습니다. 그렇지 않으면 보조 리전에서 애플리케이션을 복원하는 것이 좋습니다.
Google Cloud 백업 및 DR 외에도 VMware Engine은 VMware Engine SRM 및 Zerto와 같은 다른 DR 옵션과 호환됩니다. VMware Engine SRM과 Zerto 모두 일반적으로 더 낮은 RPO를 지원하는 재해 복구를 위해 vSphere 복제를 사용합니다. RPO 대상이 시간이 아니라 분인 경우 vSphere 복제를 기반으로 하는 DR 솔루션을 고려하세요.
체크리스트 요약
다음 체크리스트에는 VMware Engine을 사용하기 위한 보안 권장사항이 요약되어 있습니다.
| 태스크 | 주제 |
|---|---|
| VMware Engine 네트워킹 |
|
| VMware Engine IAM 및 권한 | |
| VMware Engine 로깅 및 모니터링 | |
| VMware Engine 암호화 | |
| VMware Engine 백업 및 재해 복구 |
다음 단계
- Google Cloud VMware Engine을 직접 사용해 보기. 자세한 내용은 기능, 이점, 사용 사례를 참조하세요.
- VMware Engine 보안 개념에 대해 읽어보기
- Google Cloud에 대한 참조 아키텍처, 다이어그램, 튜토리얼, 권장사항을 살펴보기. 자세한 내용은 클라우드 아키텍처 센터를 참조하세요.