VMware Engine 보안 권장사항
이 문서는 Mware Engine에 이미 익숙한 사용자를 대상으로 작성되었으며 Google Cloud VMware Engine 관리 및 구성을 위한 권장 보안 권장사항에 대해 설명합니다. 초보자의 경우에는 기본 요건 및 VMware Engine 보안에 대해 먼저 알아보세요.
VMware Engine에는 보안을 위한 공유 책임 모델이 있습니다. 클라우드에서 신뢰할 수 있는 보안은 서비스 제공업체로서 Google 및 고객의 공유 책임을 통해 이루어집니다. 이러한 권장사항을 따르면 시간을 절약하고 오류를 방지하며 장애점의 영향을 완화할 수 있습니다.
VMware Engine 네트워킹
다음 섹션에서는 VMware Engine 환경의 네트워킹 권장사항을 소개합니다.
환경의 모든 트래픽 흐름 식별 및 파악
VMware Engine은 VMware Engine 네트워크 및 VPC 피어링을 활용하여 VMware Engine 프라이빗 클라우드 네트워크에서 VPC 네트워크까지 비공개 네트워크 연결을 연결합니다. Google Cloud 환경의 VPC 또는 온프레미스 네트워크의 인바운드 트래픽은 Google 관리 테넌시 유닛 네트워크를 통과합니다.
인터넷 데이터 전송에 VMware Engine의 공개 IP 서비스 사용
인터넷 트래픽은 VMware Engine의 공개 IP 서비스를 사용하여 직접 프라이빗 클라우드에 들어갈 수 있습니다. 또는 인터넷 트래픽이 Google Cloud에서 공개 부하 분산기를 사용하여 들어갈 수 있습니다. 이 경우 트래픽은 다른 인바운드 트래픽과 마찬가지로 라우팅됩니다. 이러한 옵션은 상호 배타적입니다. URL 필터링, IPS/IDS 또는 Google Cloud 환경의 중앙 인스턴스 또는 서비스에서 제공하는 트래픽 검사와 같은 인터넷 트래픽에 커스텀 제어가 필요한 경우 VPC 네트워크를 통해 인터넷 연결 트래픽을 라우팅해야 합니다.
자동으로 적용될 수 없거나 프라이빗 클라우드 내에 구현된 제어 기능이 있으면 VMware Engine에 외부 IP 주소 서비스를 포함하는 것이 좋습니다. 또한 외부 액세스 규칙을 사용하여 애플리케이션에 적용되지 않는 인터넷의 트래픽 패턴을 거부하는 것이 좋습니다.
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 워크로드를 Cloud Service Mesh 뒤의 하이브리드 네트워크 엔드포인트 그룹에 배치하고 외부 HTTP(S) 부하 분산기를 활용하는 것이 좋습니다. 두 설정 중 하나를 사용하면 공개용 애플리케이션의 Google Cloud Armor를 포함하여 DDoS 공격과 일반적인 취약점(예: SQL 삽입 또는 교차 사이트 스크립팅)을 완화할 수 있습니다.
Envoy 프록시를 사용하는 고급 트래픽 관리 또는 Certificate Authority Service 통합과 같은 서비스 메시 기능이 필요한 경우에는 Cloud Service Mesh를 사용하는 것이 좋습니다. 다른 모든 경우에는 외부 HTTP(S) 부하 분산기를 사용하는 것을 권장합니다.
다음 설정 중 하나로 VMware Engine 워크로드를 하이브리드 NEG에 추가하는 방법에 대한 문서를 따르세요.
인터넷 액세스 없이 비공개로 Google Cloud 서비스에 연결
VMware Engine 프라이빗 클라우드 워크로드는 비공개 Google 액세스를 사용하여 Cloud Storage API와 같은 Google Cloud API에 액세스할 수 있습니다. 비공개 Google 액세스는 아웃바운드 데이터 전송 비용과 지연 시간을 줄이므로 비공개 Google 액세스를 사용하여 인터넷을 통해 트래픽을 전송하지 않고 Google 서비스에 액세스하는 것이 좋습니다. 이렇게 하면 Google API 액세스만 필요한 워크로드에 인터넷에 대한 네트워크 경로가 필요하지 않습니다. 비공개 Google 액세스에 대해 자세히 알아보고 기술 세부정보 및 구성 단계를 확인하세요.
마찬가지로 Cloud SQL 또는 Memorystore 인스턴스와 같은 서비스 프로듀서 네트워크에서 Google Cloud 리소스에 액세스해야 하는 VMware Engine 워크로드는 PSA를 사용하여 비공개로 연결해야 합니다. 자세한 내용은 VMware Engine의 PSA 섹션을 참조하세요.
온프레미스 환경과 Google Cloud 간의 통신 암호화
온프레미스 시스템과 통신해야 하는 VMware Engine의 워크로드는 암호화된 채널을 통해 연결해야 합니다. 온프레미스 데이터 센터와 Google Cloud 사이에서 전송 중인 데이터 암호화에 계층화된 방식을 사용하는 것이 좋습니다. IPsec 터널로 Cloud VPN을 설정하거나 Interconnect의 VLAN 연결에서 기본 제공되는 IPsec을 사용하여 온프레미스 시스템과 Google Cloud 간의 링크를 암호화할 수 있습니다. 또한 TLS를 사용하여 애플리케이션 구성요소 간에 애플리케이션 레이어 암호화를 사용 설정해야 합니다.
VPC 서비스 제어를 사용하여 데이터가 유출되지 않도록 보호
Cloud Storage 버킷 및 BigQuery 데이터 세트와 같은 민감한 리소스를 VPC 서비스 제어 경계에 배치하여 VPC 서비스 제어를 사용해 데이터 무단 반출 위험을 완화하는 것이 좋습니다. 경계 내부의 데이터에 액세스해야 하는 워크로드도 경계에 배치해야 합니다. 특히 프라이빗 클라우드를 호스팅하는 Google Cloud 프로젝트가 VPC 서비스 제어에서 보호하는 리소스에 액세스하려면 VPC 서비스 제어 경계에 속해야 합니다.
VMware Engine 프로듀서 서비스 API를 경계로 허용하도록 VPC 서비스 제어 구성에서 인바운드 및 아웃바운드 데이터 전송 정책을 구성해야 합니다. 설정에 대한 자세한 안내는 VMware Engine을 사용하는 VPC 서비스 제어에 대한 Google 문서 페이지를 참조하세요.
VMware Engine IAM 및 권한
다음 섹션에서는 VMware Engine 환경에서 사용자 권한에 대한 권장사항을 소개합니다. VMware Engine 환경 및 프라이빗 클라우드가 배포된 Google Cloud 프로젝트 내에서 권한을 처리해야 합니다.
사전 정의된 역할이나 커스텀 역할을 사용하여 액세스 권한 부여
vSphere 역할 및 권한을 관리하는 VMware Engine 방식에서 다른 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 및 폴더, 데이터 스토어 | 예: 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에서 기본 키 제공업체를 구성합니다. 고객은 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의 경우 중복 삭제 효율성이 거의 없으므로 VM 수준 암호화를 vSAN 데이터 스토어 암호화와 함께 사용 설정하지 않는 것이 좋습니다.
조직의 표준에 따라 암호화 키 순환 자동화
개발자가 VMware Engine vSphere를 사용하여 KEK를 순환해야 합니다. 이는 기본 키 제공업체와 외부 Cloud KMS를 모두 사용하는 경우입니다. vCenter에서 또는 해당 API를 사용하여 KEK 순환을 시작할 수 있습니다. 조직 요구사항에 따라 KEK 순환을 자동화하는 것이 좋습니다. GitHub에서 PowerCLI 스크립트 예시를 찾을 수 있습니다.
VMware Engine 백업 및 재해 복구
랜섬웨어, 손상, 사람의 실수와 같은 위협으로부터 데이터를 보호하는 것이 중요합니다. 또한 비즈니스에 중요한 애플리케이션은 데이터를 항상 가상으로 사용해야 하므로 갑작스러운 중단으로부터 데이터를 복구할 시간이 거의 없습니다. 이 섹션에는 데이터의 보안 및 가용성을 유지하기 위한 백업 및 DR 전략을 효과적으로 설계하는 것과 관련된 모든 백업 및 재해 복구의 전체 내용이 포함되지 않았으나, 올바른 VMware Engine 환경 전략을 선택할 때 중요한 고려사항이 포함됩니다.
백업 및 DR 서비스를 사용하여 워크로드 백업
Google Cloud는 백업 및 DR 서비스를 통해 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에 대한 참조 아키텍처, 다이어그램, 튜토리얼, 권장사항을 살펴보기. 자세한 내용은 Cloud 아키텍처 센터를 참조하세요.