vSphere 환경을 노리는 BRICKSTORM 멀웨어 분석 및 방어 전략 지침서

해당 블로그의 원문은 2026년 4월 3일 Google Cloud 블로그(영문)에 게재되었습니다. 

작성자: Stuart Carrera

도입

구글 위협 인텔리전스 그룹(GTIG)의 최근 BRICKSTORM 연구 결과를 바탕으로, 본 게시물에서는 가상화 환경이 직면한 진화하는 위협에 대해 심층적으로 살펴봅니다. 공격자들의 이러한 작전은 VMware vSphere 생태계, 그중에서도 특히 vCenter Server Appliance (VCSA) 및 ESXi 하이퍼바이저를 직접적인 표적으로 삼습니다. 조직이 이러한 리스크보다 한발 앞서 대응할 수 있도록, 본 문서에서는 이러한 핵심 자산들을 보호하는 데 필요한 필수 보안 강화 전략과 완화 통제 방안에 초점을 맞출 것입니다.

위협 행위자들은 가상화 계층에 지속성을 확보함으로써, 전통적인 보안 방어 수단이 미치지 못하는 게스트 운영 체제 아래 깊숙한 곳에서 활동합니다. 이들은 이러한 제어 영역이 표준 엔드포인트 탐지 및 대응(EDR) 에이전트를 지원하지 않으며, 역사적으로 전통적인 엔드포인트에 비해 보안의 사각지대에 놓여 있었다는 사실을 교묘하게 악용하여 엄청난 가시성의 공백을 만들어냅니다.

주의해야 할 점은 이러한 활동이 벤더의 제품이나 인프라에 존재하는 보안 취약점 때문에 발생하는 것이 아니라는 점입니다. 그 대신, 취약한 보안 아키텍처 및 신원 설계의 허점을 노리고, 호스트 기반 구성 강제화의 부재, 그리고 가상화 계층 내의 제한적인 가시성을 악용하는 데 의존합니다. 공격자들은 이렇게 모니터링되지 않는 영역에서 활동함으로써 장기적인 지속성을 확립하고 전체 vSphere 환경에 대한 관리자 통제권을 탈취할 수 있습니다.

본 가이드는 인프라 중심의 방어 체계(Infrastructure-centric defense)를 구축하기 위한 프레임워크를 제공합니다. 이러한 지침 중 일부를 자동화하고 BRICKSTORM과 같은 위협으로부터 제어 영역(Control plane)을 보호하기 위해, Mandiant는 Photon Linux 계층에서 직접 보안 구성을 강제하는 vCenter 하드닝 스크립트(vCenter Hardening Script)를 배포했습니다. 이러한 권장 사항들을 구현함으로써, 조직은 가상화 계층을 지속적인 위협을 탐지하고 차단할 수 있는 강력하게 강화된 환경으로 탈바꿈시킬 수 있습니다.

vCenter Server Appliance 리스크 분석

vCenter Server Appliance(VCSA)는 vSphere 인프라의 중앙 제어 및 신뢰 지점(Point of trust)입니다. 특화된 Photon Linux 운영 체제에서 실행되는 VCSA는 일반적으로 도메인 컨트롤러나 특권 권한 관리(PAM) 솔루션과 같은 핵심 Tier-0 워크로드를 호스팅합니다. 이는 기반이 되는 가상화 플랫폼이 자신이 지원하는 고도로 민감한 자산들과 동일한 보안 분류 및 리스크 프로필을 상속받음을 의미합니다.

vCenter 제어 영역이 침해되면 공격자는 관리되는 모든 ESXi 호스트와 가상 머신(VM)에 대한 관리자 통제권을 얻게 되며, 조직의 기존 보안 계층화는 사실상 무의미해집니다. VCSA는 목적에 맞게 제작된 어플라이언스이므로, 단순히 제공되는 기본 설정에 의존하는 것만으로는 부족합니다. Tier-0 보안 표준을 달성하려면 vSphere와 기반 Photon Linux 계층 모두에서 의도적이고 맞춤화된 보안 구성이 필요합니다.

위협 행위자에게 VCSA는 다음과 같은 이점을 제공합니다.

• 중앙 집중식 명령: 모든 가상 머신을 전원 종료, 삭제 또는 재구성할 수 있는 권한과 관리되는 모든 ESXi 호스트의 루트(Root) 자격 증명을 재설정하여 하이퍼바이저를 완전히 제어할 수 있는 능력을 부여합니다.

• 전체 데이터 액세스: 모든 애플리케이션의 기반 저장소(VMDK)에 접근하여 운영 체제 권한 및 기존 파일 시스템 보안을 우회할 수 있습니다. 이는 Tier-0 자산의 데이터를 유출하는 직통 경로가 됩니다.

• 명령행 로깅 공백: 공격자가 보안 셸(SSH)을 통해 기반 Photon OS 셸에 접근할 경우, 셸 명령어에 대한 원격 로깅이 이루어지지 않습니다.

관리 평면(Management Plane) 종속성

많은 조직이 Active Directory(AD)와 통합된 vCenter로 관리되는 동일한 vSphere 클러스터 내에서 AD 도메인 컨트롤러를 가상 머신(VM)으로 호스팅합니다. 만약 공격자가 가상 네트워크를 비활성화하거나 데이터스토어(Datastore)를 암호화하면, vCenter는 관리자 인증 기능을 상실하게 됩니다. VCSA가 암호화되거나 삭제되는 시나리오에서는 대규모 복구에 필요한 도구들마저 사라집니다. 이 경우 조직은 개별 ESXi 호스트를 통해 수동 복구에 의존해야 하며, 복구 타임라인은 기하급수적으로 늘어납니다.

vSphere 7 서비스 종료 (End of Life)

vSphere 7은 2025년 10월에 서비스가 종료(EoL)되었습니다. 이러한 기술적 부채를 안고 있는 조직은 업그레이드 전까지 핵심 보안 패치를 더 이상 받지 못하는 위험 구간에 진입하게 됩니다. 이는 위협 행위자들이 수정되지 않을 알려진 취약점을 악용할 수 있는 기회를 제공합니다.

선제적 조치의 전략적 이점

제어 영역을 보호하기 위해 조직은 인프라 자체가 일차적인 방어선 역할을 하는 전략을 채택해야 합니다. 복원력 있는 방어는 다음 두 가지 전략에 의존합니다.

• 기술적 하드닝(Technical Hardening): 공격 표면을 줄이기 위해 하이퍼바이저 계층에 심층 방어(Defense-in-depth)를 적용해야 합니다. 위협 행위자는 보안이 취약한 기본 설정을 노립니다. 보안 부팅(Secure Boot) 활성화, 관리 인터페이스의 엄격한 방화벽 적용, 셸 액세스 비활성화와 같은 하드닝 조치는 공격자에게 '마찰(Friction)'을 일으킵니다. 위협 행위자가 /etc/rc.local.d에 지속성 스크립트를 쓰거나 시작 파일을 수정하려고 할 때, 강화된 보안 구성은 이를 차단하거나 공격자가 과도한 로그 텔레메트리를 생성하는 방식을 강제로 사용하게 만듭니다.

• 고충실도 신호 분석(High-Fidelity Signal Analysis): 위협 행위자들은 인프라를 교체하고 도구를 재컴파일하여 시그니처를 변경하는 데 능숙합니다. 악성 IP 차단 목록이나 알려진 멀웨어 해시 데이터베이스에 의존하는 것은 공격자가 명령 및 제어(C2) 서버와 네이티브 바이너리를 사용하기 때문에 효과적인 전략이 아닙니다. 대신, 초점을 전적으로 '행동 패턴(Behavioral patterns)'으로 전환해야 합니다.

인프라 자체가 주요 방어선 역할을 하는 이러한 전략적 토대 위에, 본 가이드는 다음과 같은 4단계 기술 강제화 단계를 제시합니다.

• 1단계: 벤치마킹 및 기본 제어 – 보안 기술 구현 지침(STIG) 준수 및 패치를 통한 기초 확립.

• 2단계: ID 관리 – PAW 및 PAM 솔루션을 통한 핵심 인프라 관리 액세스 강화.

• 3단계: vSphere 네트워크 하드닝 – 제로 트러스트 네트워킹을 통한 수평 이동(Lateral movement) 차단.

• 4단계: 로깅 및 포렌식 가시성 – 어플라이언스를 선제적 보안 센서로 전환.

1단계: 벤치마킹 및 기본 제어

조직은 Mandiant vSphere 하드닝 블로그 포스트에 명시된 하드닝 조치와 함께 엄격한 패치 및 업그레이드 전략을 사용해야 합니다. 이는 강력한 보안 태세를 구축하기 위한 표준적인 토대를 제공합니다. Photon Linux DISA STIG 및 VMware 보안 하드닝 가이드를 중심으로 강화된 보안 베이스라인을 구현함으로써, 조직은 공격자가 표적으로 삼는 OS 수준의 구성 요소를 방어할 수 있습니다.

주요 프레임워크:

• VMware vSphere 7.0 VCSA Photon OS STIG

• VMware vSphere 8.0 VCSA Photon OS STIG

• VMware vSphere 보안 하드닝 가이드

• VMware BRICKSTORM 리소스 및 방어 지침

공격자 TTP(전술, 기법, 절차)에 따른 STIG 제어 매핑

vSphere 인프라 수준의 데이터 유출 위협

표준 vSphere 구성에서는 가상 머신(VM) 복제 및 내보내기와 같은 고위험 권한이 일반적인 관리자 역할(Administrative roles) 내에 숨겨져 있는 경우가 많습니다. 이로 인해 이러한 위험한 작업들이 일상적인 운영 과정에서 발생하는 백그라운드 노이즈와 구별되지 않게 됩니다. 이러한 아키텍처는 위협 행위자에게 도메인 컨트롤러나 자격 증명 저장소 등을 흔적 없이 은밀하게 유출할 수 있는 수단을 제공합니다. 따라서 조직은 기존의 허용적인 vSphere 액세스 제어 모델에서 벗어나, 데이터 보호를 보장하는 '포괄적인 암호화 강제 정책' 모델로 전환해야 합니다.

vSphere 내의 데이터 유출에 대한 복원력을 갖추려면, 고부가가치 가상 자산을 관리하는 방식을 근본적으로 바꿔야 합니다.

• Tier-0 암호화 의무화: vSphere 네이티브 VM 암호화를 강제하는 것은 모든 핵심 Tier-0 가상 머신에 대해 가장 필수적인 일차적 통제 수단입니다. 조직은 모든 도메인 컨트롤러, 인증 기관(CA), 그리고 비밀번호 저장소가 가상 머신 레벨에서 반드시 암호화되도록 의무화해야 합니다.

• 암호화 기반의 격리(Cryptographic Isolation): Tier-0 자산에는 고유하게 키가 잠금 설정된 암호화 정책이 적용되어야 합니다. 이러한 워크로드를 위해 별도의 키 관리 서버(KMS) 클러스터 사용을 의무화함으로써, 공격자가 보안 하드웨어 기반 금고(Vault)에 접근하지 않고서는 복제된 디스크의 잠금을 해제할 수 없도록 보장합니다.

• 권한 분리(Entitlement De-coupling): 일반적인 관리자 역할에서 "복제(Clone)" 및 "내보내기(Export)" 권한을 박탈해야 합니다. 이러한 기능들은 오직 비상 복구 시나리오에만 독점적으로 사용되는, 고도로 제한되고 감사가 가능한 "비상용(Break-glass)" 신원 계정으로 재할당되어야 합니다.

2단계: 신원 관리 (Identity Management)

vSphere 신원 관리의 모범 사례는 모든 vSphere 관리자 세션이 반드시 전용 특권 액세스 워크스테이션(PAW)에서 시작되도록 의무화하고, PAM 솔루션을 활용하는 데 초점을 맞춥니다. 이와 동시에 vpxuser의 셸(Shell) 액세스를 제한하여 호스트 수준의 하드닝을 강제해야 합니다.

특권 액세스 워크스테이션 (Privileged Access Workstations, PAWs)

위협 행위자가 침해된 일반 사용자 엔드포인트나 어플라이언스에서 가상화 관리 평면으로 수평 이동(Pivot)하는 것을 막기 위해, 관리자 세션은 반드시 전용 PAW에서 시작되어야 합니다. 이는 vSphere 관리 기능이나 인터페이스에 접속할 때만 사용하도록 특별히 강화된 전용 워크스테이션입니다.

특권 액세스 관리 (Privileged Access Management, PAM)

PAM 도구는 BRICKSTEAL 자격 증명 수집기(Credential harvester)와 같은 특정 위협을 완화하는 중개자 역할을 수행합니다. 조직은 '자격 증명 주입(Credential injection)' 방식을 의무화함으로써, 타겟 시스템에 직접 비밀번호를 타이핑하거나 메모리에 노출되어 멀웨어가 이를 가로채는 상황을 원천 차단할 수 있습니다. 특히 루트 비밀번호와 서비스 계정 키의 경우, 자동화된 비밀번호 주기 변경(Secret rotation)을 강제하여 탈취된 자격 증명의 수명을 최소한으로 제한해야 합니다.

인증 및 플랫폼 하드닝

기본 vsphere.local SSO(Single Sign-On) 도메인에 상주하는 계정들, 그중에서도 특히 내장된 슈퍼유저인 administrator@vsphere.local은 최신 MFA 통합을 지원하지 않기 때문에 특별한 보안 리스크를 초래합니다. 이러한 한계 때문에 조직은 일상적인 관리 작업에서 vsphere.local 계정 사용을 제한해야 합니다. 대신 이 계정은 복잡하게 설정되어 안전한 금고(Vault)에 보관된 비상용 "break-glass" 자격 증명으로 취급되어야 합니다.

vSphere VPXUSER

vpxuser는 핵심 인프라 관리 작업을 원활하게 수행하기 위해 vCenter가 관리되는 각 호스트에 프로비저닝하는 높은 권한의 시스템 계정입니다.

VCSA에 대한 관리 권한을 탈취한 위협 행위자는 사실상 관리되는 전체 클러스터에 걸쳐 vpxuser에 위임된 권한을 상속받게 됩니다. 이러한 권한은 관리 평면에서 호스트 수준의 셸로 이동(Pivot)할 수 있는 기반이 됩니다.

주요 완화 조치 (vSphere ESXi 8.0 이상): 셸 액세스 비활성화

이러한 수평 이동(Lateral movement) 벡터를 완화하기 위해, vSphere 8.0부터는 관리자가 vpxuser 계정에서 셸 액세스 권한을 제거할 수 있는 기술적 통제 기능이 도입되었습니다. 모든 ESXi 8.0 이상 호스트에 다음 구성을 강제하여 vpxuser 신원을 제한해야 합니다.

esxcli system account set -i vpxuser -s false

ESXi Host Identity Hardening Strategy

Additional hardening measures to prevent bypasses via alternative mechanisms, such as Host Profile manipulation, include:

3단계: vSphere 네트워크 보안 하드닝

가상화 네트워크 보호

vSphere에 제로 트러스트 네트워크 태세(Posture)를 확립하는 것은 복원력 있는 Tier-0 아키텍처를 보호하기 위한 가장 기본적인 요구사항입니다. vCenter Server Appliance(VCSA) 및 ESXi 하이퍼바이저 내의 로컬 특권 계정들은 자체적인 네이티브 MFA를 지원하지 않기 때문에, 오직 신원 기반의 검증(Identity-based validation) 하나만으로는 완벽한 보안 통제를 달성하기에 불충분합니다. 위협 행위자가 이러한 자격 증명을 일단 수집하고 나면, 논리적인 네트워크 아키텍처만이 공격자의 vSphere 관리 평면 접근을 차단할 수 있는 유일한 방어 계층으로 남게 됩니다.

B. 발신 필터링 (VCSA/관리망에서 나가는 아웃바운드 트래픽)

마이크로 세그멘테이션(Micro-Segmentation) 관련 참고 사항: 물리적 방화벽이 관리 평면(남북 방향, North-South)을 보호한다면, VMware NSX 분산 방화벽(DFW)은 게스트 간(동서 방향, East-West) 트래픽을 제어하기 위한 필수 표준입니다. 데이터 평면 보호를 위해 필요한 경우 NSX를 사용해야 하며, 물리적 네트워크 하드웨어는 지속적으로 관리 평면의 통제권을 유지해야 합니다.

VAMI GUI 방화벽의 한계

VCSA의 호스트 기반 방화벽은 심층 방어 전략의 필수 구성 요소이지만, 관리자는 표준 VAMI GUI가 위협 행위자를 방어하는 데 있어 다음과 같은 운영상의 한계가 있음을 인지해야 합니다.

• 포트별 정밀 제어(Granularity) 부족: VAMI GUI는 진정한 제로 트러스트 모델에 필요한 정밀도가 부족합니다. 모든 버전에서 특정 서버(예: 가상 백업 서버)에 대해 IP 기반 규칙을 생성할 때 "전부 아니면 전무(all-or-nothing)" 방식을 강제합니다. 즉, 백업 서버에 TCP 443 포트를 통한 vSphere API 접근 권한을 부여하려면, 관리자는 종종 해당 IP에 대해 모든 포트를 신뢰하도록 설정해야 하는 상황에 놓입니다.

  • 리스크: 이는 백업 서버에 SSH(22) 및 VAMI(5480)와 같은 고도로 민감한 관리 인터페이스에 대한 무단 접근 권한까지 동시에 부여하는 결과가 됩니다. 공격자가 백업 서버를 침해하면, VCSA 셸로 향하는 방해받지 않는 관리 경로를 그대로 상속받게 됩니다.

• 순환적 관리 종속성(Circular Administrative Dependency): vCenter 자체 호스트 기반 방화벽의 근본적인 약점은, 보호해야 할 대상인 관리 평면 내부에 논리적으로 위치한다는 점입니다. 이 방화벽은 TCP 5480 포트를 사용하는 보조 관리 진입점인 VAMI를 통해 관리됩니다. 이 인터페이스는 표준 vSphere 클라이언트(TCP 443)와 논리적으로 인접해 있으며, 흔히 동일한 관리 네트워크 세그먼트에 노출되어 있습니다.

  • 리스크: BRICKSTEAL을 통해 탈취된 자격 증명은 위협 행위자에게 어플라이언스 자체를 재구성할 수 있는 권한을 부여합니다. 공격자는 탈취한 계정으로 VAMI에 접속하여 방화벽을 비활성화할 수 있습니다. 이러한 순환적 종속성으로 인해, 방화벽은 자신이 보호해야 할 바로 그 애플리케이션에 의해 관리되며, 공격자는 시스템 자체의 관리 도구를 사용해 보안 통제를 무력화할 수 있습니다.

• 포렌식 가시성 공백: 표준 VAMI 방화벽은 보안 모니터링이 아닌 연결 관리를 위해 설계되었습니다. 거부된 연결 시도나 특정 셸 활동에 대해 원격 로그를 생성하지 않습니다.

  • 리스크: 이는 보안팀이 활발히 진행 중인 수평 이동 시도를 감지하지 못하게 만듭니다. 공격자가 권한이 없는 VM에서 VCSA를 여러 번 스캔하거나 감시되지 않는 VCSA 셸을 사용하더라도, 방화벽이 차단 알림을 주지 않고 셸 명령어가 로깅되지 않기 때문에 SOC는 공격의 최종 단계에 이를 때까지 침입 시도를 알아차릴 수 없습니다.

• 수신 전용 정책에 따른 가시성 공백: GUI는 주로 수신(Inbound) 트래픽에만 집중하며, 발신(Egress/Outbound) 정책은 관리되지 않은 상태로 방치됩니다.

  • 리스크: BRICKSTORM 백도어와 같은 최신 멀웨어는 명령을 받기 위해 외부로 "Phone Home(C2)" 트래픽을 보내는 데 의존합니다. 발신 트래픽을 제한하지 않는 방화벽은 침해된 VCSA가 외부의 악성 인프라와 아무런 제약 없이 통신할 수 있도록 허용하는 꼴이 됩니다.

이러한 네이티브 VAMI 방화벽의 한계를 극복하기 위해, 조직은 네이티브 vSphere GUI 기반 관리 방식에서 탈피하여 기반이 되는 Photon Linux의 iptables 또는 nftables를 활용한 OS 수준의 하드닝으로 전환할 것을 권장합니다.

• 변조 방지 무결성: Photon Linux 운영 체제 수준에서 정밀한 방화벽 규칙을 직접 구현하면, 보안 통제가 vCenter 애플리케이션 권한으로부터 독립됩니다. vCenter 관리자 권한이 탈취되더라도 VCSA GUI를 통해 Photon OS 수준의 규칙을 비활성화할 수 없습니다.

• 정밀한 로직 적용: OS 수준의 규칙은 "출발지 IP + 목적지 포트" 매핑을 엄격하게 적용할 수 있습니다. 이를 통해 백업 서버가 오직 443 포트만 볼 수 있게 하고 다른 모든 포트 접근은 거부할 수 있습니다.

• 센서로의 전환: VCSA GUI와 달리 Photon OS 수준의 로깅은 SIEM(보안 정보 및 이벤트 관리) 시스템과 연동될 수 있습니다. 이를 통해 거부된 모든 연결 시도를 고충실도의 조기 경보 알림으로 변환할 수 있습니다.

VAMI GUI 방화벽은 기본적인 보안 제어 수단일 뿐, 포괄적인 Tier-0 보안 제어 수단으로 간주되어서는 안 됩니다. 지능형 캠페인에 필요한 공격 벡터를 효과적으로 완화하기 위해, 조직은 취약한 GUI를 우회하고 VCSA Photon Linux 커널 수준에서 엄격하게 검증되고 정밀하며 로깅이 가능한 방화벽 정책을 강제해야 합니다.

ESXi 하이퍼바이저 방화벽

ESXi 방화벽은 VMkernel과 네트워크 사이에 위치하는 상태 저장 패킷 필터(Stateful packet filter)입니다. 개별 서비스를 허가된 관리 IP로만 제한하는 것은 동일한 VLAN에 있는 공격자가 호스트 API나 SSH 포트에 도달하는 것을 차단할 수 있는 유일한 방법입니다.

전략적 구현: "모든 IP 주소의 연결 허용" 옵션을 해제하고 특정 관리 IP를 입력하여 서비스 레벨에서 접근을 제한해야 합니다.

권장 ESXi 호스트 기반 방화벽 규칙

탐지 수단으로서의 하드닝(Hardening)

인프라가 "기본 거부(Default Deny)" 태세로 구성되면, 위협 행위자를 노출시키는 데 필요한 '마찰(Friction)'이 발생합니다. 하드닝되지 않은 환경에서는 공격자의 포트 스캔이나 수평 이동 시도가 흔적 없이 성공하지만, 하드닝된 환경에서는 이와 동일한 작업들이 모두 침해 지표(Indicators of compromise)가 됩니다.

다계층 신호 체인(Multi-Layered Signal Chain)

• 네트워크 수준 가시성: 탐지는 트랜짓 계층(Transit layer)에서 시작됩니다. 조직은 물리적 네트워크와 가상 스위치(VDS) 수준 모두에서 로깅이 활성화되어 있는지 확인해야 합니다. 이를 통해 SOC는 위협 행위자의 "경로"를 추적하고, vSphere 관리 평면을 향해 서브넷을 가로지르는 승인되지 않은 스캐닝이나 연결 시도를 식별할 수 있습니다.

• 호스트 기반 방화벽 로깅 (IPtables): VCSA가 방화벽 관리를 위한 GUI를 제공하긴 하지만, 접근 거부 내역을 자체적으로 기록하지는 않습니다. 어플라이언스를 능동적인 센서로 전환하기 위한 호스트 기반 방화벽 로깅은, 전적으로 커널 수준의 맞춤형 OS IPtables 구성에 의존합니다. 기저의 Photon OS 커널에 로깅 타겟을 추가함으로써 거부된 모든 패킷이 기록되며, 이는 승인되지 않은 위협 행위자가 VCSA에 접근하려 한다는 결정적인 증거를 제공합니다.

• 변경 불가능한 로깅(Immutable Logging): 원격 Syslog 포워딩(Remote Syslog Forwarding)을 활성화하면 이러한 거부 로그들이 즉시 외부로 전송됩니다. 공격자가 결국 호스트를 침해하더라도 로컬 로그 소스는 삭제할 수 없습니다.

조기 탐지 신호 (Early Detection Signals)

거부된 액세스 내역을 신원 기반(Identity-based) 이벤트와 상호 연관 분석함으로써, 조직은 가장 초기 단계에서 BRICKSTORM 생명 주기 이벤트 패턴을 식별할 수 있습니다.

• 인증 실패 경보: 승인되지 않은 내부 IP에서 발생한 "로그인 시도 실패"를 보여주는 표준 auth.log(SSH용) 또는 vCenter UserLoginSessionEvent의 로그 항목은 매우 가치 있는 경보입니다.

• 계정 잠금 이벤트: 공격자가 로컬 "비상용(break-glass)" 계정(예: administrator@vsphere.local)에 대해 무차별 대입 공격(Brute-force)을 시도하거나 수집된 자격 증명을 사용할 때 발생하는 "계정 잠금" 이벤트는, 자격 증명을 겨냥한 표적 공격이 진행 중임을 알리는 우선순위가 높은 신호입니다.

• 행동 패턴 연관성 분석(Correlation): 가장 강력한 신호는 SIEM이 서로 다른 출처의 정보들을 연관 지을 때 나타납니다. 예를 들어, IPtables를 통한 '방화벽 패킷 드롭' 직후 동일한 출발지 IP에서 SSO를 통한 '로그인 실패'가 연달아 발생하는 경우, 이는 현재 침입 시도가 활발히 진행 중임을 나타내는 신뢰도 높은 지표입니다.

스위치 수준의 네트워크 세그멘테이션은 필수 전제 조건이지만, 호스트 기반 방화벽은 vSphere 제로 트러스트 아키텍처의 핵심 실행 지점입니다. 호스트 수준의 필터링으로 네트워크 기반 방화벽을 보완함으로써, 조직은 관리 VLAN의 가시성 공백을 해소하고 VCSA 및 ESXi 호스트를 침입 초기 단계에서 적을 노출시킬 수 있는 센서로 탈바꿈시킬 수 있습니다.

4단계: 로깅 및 포렌식 가시성

vSphere 제어 평면 내에서의 탐지를 원활하게 하기 위해, 조직은 그동안 모니터링되지 않았던 VCSA 운영 체제의 기반 계층 전반에 걸쳐 포괄적인 텔레메트리(Telemetry)를 확보해야 합니다.

이번 캠페인에서 공격자가 주로 악용한 운영상의 이점은 가상화 제어 평면에 내재된 '가시성의 부재'였습니다. 이러한 모니터링 가시성의 공백은 다음 세 가지 핵심 요인에 기인합니다.

• 로깅의 공백: 기본적으로 VCSA는 커널 수준의 감사 로그를 외부로 전송하지 않습니다. 공격자가 로컬 디스크를 지워버리면 그들이 상주했던 증거는 영구적으로 삭제됩니다.

• 제한적인 로깅 파이프라인: Fluentd나 Logstash와 같은 최신 표준 로그 포워딩 에이전트는 VCSA에 설치를 지원하지 않습니다. 어플라이언스의 무결성을 유지하기 위해 방어자들은 네이티브 rsyslog 데몬 사용으로만 제한됩니다. 이로 인해 호스트 내부에서의 로그 강화(Enrichment)나 고급 파싱(Parsing)이 불가능해져, SIEM은 정제되지 않은 구형(Legacy) 데이터 스트림을 그대로 처리해야만 합니다. 이러한 기술적 복잡성은 종종 중요 커널 수준 신호가 잘못 분류되거나 무시되는 결과로 이어집니다.

• 운영 텔레메트리의 파편화: 보안 지표들은 종종 일반적인 클러스터 및 애플리케이션 수준 이벤트 속에 파묻혀 있습니다. vCenter 이벤트 매핑(vCenter Event Mapping)에 자세히 설명되어 있듯, VmNetworkAdapterAddedEvent나 VmClonedEvent와 같은 중대한 작업조차 일상적인 인프라 관리 이벤트로 기록됩니다. 이러한 신호들이 보안보다는 운영에 초점이 맞춰져 있기 때문에, 위협 행위자의 움직임은 일상적인 작업으로 쉽게 위장됩니다.

auditd란 무엇인가요?

Linux 감사 데몬(auditd)은 보안 관련 이벤트를 추적하기 위한 커널의 핵심 하위 시스템입니다. 애플리케이션 및 관리 이벤트를 기록하는 일반적인 "시스템 로그"와 달리, auditd는 **시스템 호출(System calls)**을 기록합니다. 즉, 셸에서 어떤 명령어가 실행되었는지, 어떤 파일이 수정되었는지, 어떤 사용자가 권한을 상승시켰는지를 정확하게 파악합니다. 기본 Photon auditd 규칙은 신원 관리(계정 생성/삭제) 및 권한 상승(sudo/특권 권한 사용) 등을 포함합니다.

auditd 상태: 현재 방어 태세 검증

auditd는 저수준(low-level)의 움직임을 탐지하기 위한 핵심적인 포렌식 토대입니다. VCSA Photon 로그가 관리 작업에 대한 가시성을 제공하긴 하지만, 이번 캠페인의 특징인 "리빙오프더랜드(LotL, 자급자족형)" 기법에 대해서는 근본적으로 감지하지 못합니다. 위협 행위자는 VCSA 셸 깊숙한 곳에서 작동하며 바이너리 주입을 수행하고, sed를 사용해 시작 스크립트를 수정하며, sudo를 활용해 BRICKSTEAL 자격 증명 수집기를 구동합니다. 오직 시스템 호출(syscalls)을 기록하는 auditd만이 이러한 명령행 조작(Manuevers)에 대한 정밀한 기록을 제공할 수 있습니다. 전통적인 EDR이 없는 환경에서 auditd는 일반적인 로그가 무시하는 미세한 행동 패턴을 포착해 냅니다.

기본 설정의 공백

최신 VCSA(vSphere 7 및 8)는 사전 구성된 STIG 규칙 세트(/etc/audit/rules.d/audit.STIG.rules에 위치)와 함께 제공됩니다. 하지만 기본 설정에는 다음과 같은 제약 사항이 있습니다.

• 로컬 저장 전용: 기본적으로 auditd는 로컬 파일(/var/log/audit/audit.log)에만 기록을 남깁니다.

• VAMI에서 인식 불가: VAMI(포트 5480)에서 구성하는 원격 로깅에는 기본적으로 이러한 커널 로그가 포함되지 않습니다.

• 공격 벡터: 공격자가 루트 권한을 얻어 작업을 수행한 뒤, 단순히 rm -rf /var/log/audit/* 명령을 실행해 증거를 지워버릴 수 있습니다. 이 로그들이 실시간으로 SIEM에 스트리밍되지 않는다면 포렌식 추적은 불가능해집니다.

• 로컬 로그 순환(Rotation): 로컬 로그 위치인 /var/log/audit/audit.log는 파일 순환 및 삭제의 대상입니다. 만약 공격자가 이 파일을 지워버리면, 원격 Syslog에 저장된 버전만이 유일한 포렌식 기록이 됩니다.

모든 auditd 로그는 VCSA 원격 Syslog를 통해 포워딩되어야 합니다. auditd의 원격 포워딩은 "auditd 브릿지(Bridge)" 구성에 의존합니다. 만약 /etc/audisp/plugins.d/syslog.conf 설정이 active = yes로 되어 있다면, 이 로그들에 태그가 지정되어 외부로 전송됩니다. no로 설정되어 있으면 로컬에만 저장됩니다. auditd 이벤트의 원격 로깅을 활성화하고 포렌식 영속성을 확보하려면 다음 단계를 수행해야 합니다.

단계 A: 서비스 및 규칙 상태 확인

auditd 원격 로깅 브릿지를 활성화하기 전에, 현재 VCSA가 auditd를 사용하도록 구성되어 있는지 확인해야 합니다. 루트(root) 권한으로 다음 명령어를 실행하십시오.

# 1. Check if the audit service is active
systemctl status auditd

# 2. List the rules currently enforced by the kernel memory
auditctl -l

만약 auditctl -l 실행 결과가 아무것도 나오지 않는다면, 규칙이 로드되지 않은 것이며 커널이 공격자의 행위를 전혀 "감시"하지 못하고 있는 상태입니다.

단계 B: "auditd 브릿지(Bridge)" 상태 확인

커널 이벤트가 로컬 디스크에만 저장되고 있는지, 아니면 원격 SIEM으로 포워딩되고 있는지 확인하십시오.

# Check the active status of the syslog plugin
# Note: vSphere 8 still uses the /etc/audisp/ path for compatibility
grep "^active" /etc/audisp/plugins.d/syslog.conf

auditd 원격 로깅 활성화 방법

1단계: Syslog 플러그인 활성화

감사 디스패처(audisp)가 이벤트를 로컬 syslog 서비스로 전송하여 VCSA 원격 syslog를 통해 외부로 포워딩될 수 있도록 구성해야 합니다.

# Use sed to change the status from 'no' to 'yes'
sed -i 's/^active = no/active = yes/' /etc/audisp/plugins.d/syslog.conf

# Verify the change
grep "^active" /etc/audisp/plugins.d/syslog.conf

2단계: 감사 데몬 재시작

디스패처와 syslog 브릿지를 초기화하기 위해 서비스를 다시 로드해야 합니다.

kill -HUP $(pidof auditd)

3단계: 브릿지 작동 여부 확인

플러그인이 성공적으로 시작되었는지 확인하기 위해 로컬 시스템 메시지를 확인합니다.

grep "audisp-syslog" /var/log/messages

플러그인이 초기화 또는 시작되었음을 나타내는 메시지가 표시되어야 합니다.

4단계: 로그 포워딩 확인

journalctl -f | grep audit

로그에 msg=audit 접두사가 포함된 이벤트가 보이는지 확인해야 합니다.

Syslog 태그(Key) 확인: 사용 중인 SIEM에서 msg=audit 필드 뒤에 이어지는 key="XYZ"(예: key="execpriv") 형식의 값을 검색하십시오. 이를 통해 일반적인 시스템 로그를 걸러내고, 고충실도의 보안 이벤트에만 집중할 수 있습니다.

추가적인 auditd 규칙 적용

Photon OS 4.0 STIG의 auditd 설정에 포함된 기본 audit.STIG.rules 출력 결과를 바탕으로, 다음 세 가지 규칙을 추가로 적용할 것을 권장합니다.

AIDE(Advanced Intrusion Detection Environment)

auditd가 저수준(low-level) 모니터링을 담당한다면, AIDE는 VCSA의 디지털 검증(Digital validation)을 위한 원천 역할을 합니다. AIDE는 호스트 기반의 파일 무결성 모니터링(FIM) 도구로, 높은 보안 수준이 요구되는 Linux 환경의 산업 표준으로 간주되며 DISA STIG 준수(PHTN-40-000237)를 위한 필수 요구 사항입니다.

참고: Mandiant는 특정 vSphere 구성 및 운영 워크로드에 따른 변수를 고려하여, 프로덕션 배포 전 스테이징 환경에서 이러한 규칙들을 포괄적으로 테스트하고 미세 조정할 것을 권장합니다. 승인되지 않은 수정에 대해 고충실도 경보를 확보하고 최적의 신호 대 잡음비(Signal-to-noise ratio)를 달성하기 위해서는 모니터링 임계값과 파일 제외 목록의 적절한 보정이 필수적입니다.

auditd와 함께 AIDE가 필수적인 이유

단일 텔레메트리 스트림에만 의존하는 것은 BRICKSTORM의 정교한 전술에 대응하기에 부족합니다. auditd의 행동 감사와 AIDE의 암호화 무결성 검사를 결합함으로써, 조직은 공격자가 탐지되지 않고 활동할 가능성을 낮추는 상호 보완적 방어 체계를 구축할 수 있습니다.

• auditd (행동 모니터링): '행위'(예: "루트 권한자가 sed를 사용해 스크립트를 수정함")를 포착합니다. 만약 공격자가 높은 수준의 권한을 얻어 감사 서비스를 무력화하거나 로컬 로그를 지워버리면, 행동 추적 경로는 사라집니다.

• AIDE (상태 모니터링): '결과'를 포착합니다. AIDE는 모든 핵심 시스템 파일에 대해 암호화된 베이스라인(디지털 지문)을 생성합니다. 파일이 어떻게 변경되었는지, 감사 로그가 삭제되었는지는 중요하지 않습니다. 오직 파일의 정통성(Authenticity)이 훼손되었다는 사실에만 집중합니다.

auditd와 병행하여 AIDE 활용하기

다음 단계는 현재의 AIDE 무결성 토대를 검증하고, BRICKSTORM 관련 탐지 규칙을 추가하며, 변경 불가능한 암호화 베이스라인을 구축하는 과정을 안내합니다.

1단계: 진단 평가

환경을 수정하기 전에 AIDE 구성 상태를 확인해야 합니다. SSH를 통해 VCSA에 로그인한 후 루트(root) 권한으로 다음 명령어를 실행하십시오.

AIDE가 설치되어 있고 필요한 설정(WITH_AUDIT 및 SHA-512)과 함께 컴파일되었는지 확인합니다.

# Check version and compiled options
aide -v

2. AIDE 데이터베이스 확인

AIDE가 작동하려면 암호화 베이스라인(스냅샷)이 존재해야 합니다. 데이터베이스의 상태를 확인하십시오.

# Resolve the database directory (typically /var/lib/aide)
grep "@@define DBDIR" /etc/aide.conf
# Check for the active database
ls -lh /var/lib/aide/aide.db.gz

만약 aide.db.gz 파일이 없다면 베이스라인이 존재하지 않는 것입니다. 파일은 있지만 생성 날짜가 몇 달 전이라면, 무결성 토대가 낡았기 때문에 점검 시 많은 노이즈(오탐)를 유발할 수 있습니다.

3. 현재 AIDE 모니터링 범위 감사

기본 규칙에 의해 현재 어떤 상위 디렉터리들이 모니터링되고 있는지 확인하십시오.

# Filter for active file selection rules
grep -v "^#" /etc/aide.conf | grep "^/"

4. BRICKSTORM 탐지 범위를 위한 AIDE 규칙 세트 편집

설정 파일을 엽니다.

vi /etc/aide.conf

# --- BRICKSTORM TARGETS ---
/root/.ssh              STIG    # Detects unauthorized SSH
/lib64                  STIG    # Detects system-level libraries
/etc/aide.conf          STIG    # Detects tampering with AIDE
/etc/audit/             STIG    # Detects attempts to edit config
/etc/audisp/            STIG    # Detects attempts to sever bridge

# --- NOISE REDUCTION: EXCLUDE DYNAMIC LOGS ---
!/var/log/.*             # Ignore all standard logs
!/opt/vmware/var/log/.*  # Ignore vCenter-specific service logs
!/var/lib/.*             # Ignore dynamic database/state files

참고: 추가된 문장에서 모든 #을 제거하십시오.

5. AIDE 데이터베이스 초기화

규칙 정의가 완료되면 새로운 암호화 스냅샷을 생성해야 합니다. 이 작업은 VCSA가 깨끗한 상태임이 확인되었을 때(예: 패치 직후)에만 수행해야 합니다.

# 1. Initialize the new fingerprint database
aide --init

# 2. Activate the database
mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

생성된 aide.db.gz 파일을 읽기 전용인 외부 위치(off-box)로 복사하십시오. VCSA를 안전하게 보관된 외부의 "골든 이미지(Gold Image)"와 비교하면, 루트 권한을 가진 공격자라도 로컬 데이터베이스를 재초기화하여 자신의 수정 내역을 숨길 수 없습니다.

6. Logger 파이프를 통한 AIDE 이벤트 원격 로깅 활성화

# Run a check and bridge the output to Syslog/SIEM
aide --check | logger -t AIDE_TRAP -p local6.crit

7. AIDE 데이터베이스 검사 자동화 활성화

수동 점검 방식에서 벗어나 자동화된 알림 체계를 구축하려면 반복 예약 작업(Scheduled task)을 설정해야 합니다. 이를 통해 VCSA가 프로그래밍 방식으로 스스로의 상태를 검증하고 불일치 사항을 보고하도록 보장할 수 있습니다.

crontab을 엽니다.

crontab -e

작업을 구성하기 위해 다음 내용을 추가합니다.

# Execute check every 6 hours and send results via VCSA remote syslog
0 */6 * * * /usr/bin/aide --check | logger -t AIDE_TRAP -p local6.crit

8. 테스트 이벤트 실행

방어 체계가 정상적으로 작동하고 SIEM이 AIDE 경보를 성공적으로 수신하는지 확인하기 위해 모의 침투 테스트를 수행합니다.

모니터링 대상 영역(예: /etc/rc.local)에 주석을 추가합니다.

echo "# Forensic Bridge Test" >> /etc/rc.local

원격 이벤트 트랩(Remote event trap)을 트리거합니다.

aide --check | logger -t AIDE_TRAP -p local6.crit

경보 확인: VCSA 원격 Syslog 대상에서 AIDE_TRAP 태그를 확인합니다.

AIDE found differences between database and filesystem!! followed by Changed files: /etc/rc.local.

VCSA 셸 기록

Photon 기반 VCSA에서 /root/.bash_history 파일은 기본적으로 다른 로그 파일로 복제되지 않으며, 원격 Syslog로도 전송되지 않습니다. 이는 위협 행위자들이 모니터링을 우회하고 지속성(Persistence)을 유지하기 위해 악용하는 심각한 포렌식 가시성 공백입니다.

• 버퍼 문제: 셸에 입력된 명령어는 메모리 버퍼에 보관됩니다. 이 명령어들은 사용자가 세션에서 로그아웃할 때에만 디스크의 물리적 파일에 기록(추가)됩니다.

• 안티 포렌식 리스크: 위협 행위자가 셸 액세스 권한을 얻으면 가장 먼저 취하는 행동은 종종 unset HISTFILE 또는 history -c를 실행하는 것입니다. 이는 메모리 버퍼가 디스크에 기록되는 것을 원천적으로 차단합니다. 파일이 기록되더라도 공격자는 종료 전에 간단히 rm /root/.bash_history를 실행해 지워버릴 수 있습니다.

• 원격 전송 부재: 표준 VCSA Syslog 구성은 /var/log/와 같은 디렉터리를 모니터링하지만, .bash_history와 같은 숨겨진 사용자 파일은 모니터링하지 않습니다.

이전 단계에서 논의된 auditd 원격 Syslog가 그토록 중요한 이유는 .bash_history에 대한 의존도를 완전히 없애기 때문입니다. auditd는 커널 수준에서 시스템 호출(syscalls)을 가로채고, 명령어가 실행되는 즉시 원본 사용자 ID(AUID) 및 명령어 실행 결과를 포함한 상세한 포렌식 데이터를 원격 SIEM으로 전송(Exfiltrate)합니다. 이 브릿지를 통해 위협 행위자가 로컬 로그를 삭제하거나 세션을 강제 종료하더라도, 변경 불가능한(Immutable) 실시간 감사 추적 기록이 어플라이언스 외부(Off-appliance)에 안전하게 보존됩니다.

로깅 설계 원칙

최근의 CISA 보고서 및 GTIG 분석에 따르면, 위협 행위자들은 관리 인터페이스를 악용하고(SSH 활성화 포함), 지속성 관련 구성 변경을 수행하며, vCenter 기능을 활용해 고부가가치 가상 머신에 접근하는 것으로 나타났습니다. 따라서 조직의 로깅 전략은 관리 평면 감사 추적, 서비스 상태 변경, 신원 이벤트, 하이퍼바이저 텔레메트리, 그리고 중앙 집중식 포워딩을 최우선으로 삼아야 합니다.

1. 먼저 중앙 집중화한 후 조정하라. 로그를 거의 실시간으로 호스트 외부로 포워딩하여 공격자가 로컬 디스크를 지워 로그를 조작하지 못하게 하십시오. VCSA와 ESXi 모두 중앙 Syslog/SIEM 대상으로 로그를 포워딩하도록 구성해야 합니다.

2. 로그를 Tier-0 데이터로 취급하라. vCenter가 Tier-0이라면, vCenter 및 ESXi 로그 역시 Tier-0입니다. 로그를 읽을 수 있는 사람, 포워딩 설정을 변경할 수 있는 사람, 로깅 서비스를 중단할 수 있는 사람을 엄격하게 제한하십시오.

3. 방어 가능한 타임스탬프를 유지하라. 인시던트 발생 시 신뢰할 수 있는 연관성 분석(Correlation)이 가능하도록 VCSA, ESXi 호스트, 점프 박스(Jump boxes), 로그 수집기 전반에 걸쳐 일관된 네트워크 시간 프로토콜(NTP) 동기화를 보장하십시오.

4. 모든 것이 아닌 중요한 작업을 로깅하라. 위협 행위자의 활동과 관련하여, "시스템이 정상 실행 중"이라는 일반적인 노이즈보다는 다음 사항에 집중해야 합니다. 누가 관리에 접근했는지, 무엇이 변경되었는지, 무엇이 복제/내보내기 되었는지, 어떤 서비스가 활성화되었는지, 어떤 바이너리/구성이 수정되었는지, 어플라이언스/호스트가 네트워크상에서 어디와 통신했는지.

조직은 모든 인프라 로그를 중앙 집중화된 원격 SIEM으로 전송함으로써, Mandiant가 이전에 제시한 "vSphere 로깅 기본 원칙"을 확립해야 합니다.

vSphere 통합 로깅 아키텍처

다음 요약 표는 앞서 설명한 vSphere 텔레메트리 스트림에 대한 명확한 맵을 제공합니다. 이러한 단계들을 구현함으로써, 조직은 국소적인 단일 로그 방식에서 벗어나 BRICKSTORM 멀웨어 생명 주기 전체를 포괄하는 다계층 원격 탐지 아키텍처로 나아갈 수 있습니다.

원격 로깅 구현 모범 사례

VCSA 및 ESXi 호스트 모두 원격 Syslog를 구현할 때 암호화되지 않은 구형(Legacy) 프로토콜에서 벗어나야 합니다. 포렌식 추적 기록의 무결성과 생존성을 보장하기 위해 다음 표준이 요구됩니다.

• TLS를 통한 암호화 (TCP 포트 6514): UDP/514를 통해 로그를 전송하는 것은 안전하지 않으며 신뢰할 수 없습니다. 위협 행위자가 관리 트래픽에 접근하거나 로그 항목을 위장할 수 있습니다. 조직은 모든 Syslog 트래픽에 대해 TLS 암호화가 적용된 TCP를 강제해야 합니다. 이를 통해 로그가 전송 중 암호화되며 TCP 핸드셰이크를 통해 확실한 전달이 보장됩니다.

• 인증서 검증: 로깅 파이프라인에 대한 중간자 공격(MitM)을 방지하기 위해 VCSA 및 ESXi 호스트는 원격 Syslog 서버의 SSL 인증서를 검증하도록 구성되어야 합니다. 이는 텔레메트리가 공격자가 통제하는 불법 리스너가 아닌, 검증된 보안 시스템(SIEM 등)으로 안전하게 전송되도록 보장합니다.

• VCSA 커스텀 셸 브릿징: VCSA는 기본적으로 셸 활동이나 거부된 방화벽 연결 기록을 포워딩하지 않기 때문에, 관리자는 Photon OS 수준에서 에이전트 없는(Agentless) 브릿지 구현을 고려해야 합니다. audisp(감사 디스패처)를 구성하고 iptables 로그를 네이티브 rsyslog 서비스로 파이프(Pipe) 연결함으로써, VCSA는 수동적인 어플라이언스에서 능동적인 센서로 변환되어 실시간 커널 수준 경보를 암호화된 TLS 파이프라인으로 직접 스트리밍할 수 있게 됩니다.

• 표준화된 보존 기간 설정: 이 위협 행위자의 평균 체류 시간(Dwell time)이 393일임을 고려할 때, 원격 Syslog 저장소의 최소 보존 기간은 400일 이상으로 구성되어야 합니다. 이를 통해 조사관은 1년 전 발생한 초기 침해의 프로그래밍 방식 eventTypeId와 현재 진행 중인 침해의 저수준(low-level) auditd 신호를 상호 연관 지어 분석할 수 있습니다.

로깅을 통한 탐지 요약

결론

조직은 vCenter Server 제어 평면이 국가 지원 사이버 간첩 활동(State-sponsored espionage) 및 글로벌 랜섬웨어 작전의 주요 표적임을 분명히 인식해야 합니다. 고충실도 신호를 생성하는 데 필요한 '마찰(Friction)'을 일으키려면 기술적인 하드닝(Hardening)이 필수적입니다. 조직은 VCSA OS 수준의 방화벽, 피싱 저항성(Phishing-resistant) MFA, 엄격하게 제한된 관리 인터페이스와 같은 방어막을 강제함으로써, 위협 행위자가 본질적으로 의심스러운 행동을 시도할 수밖에 없도록 몰아넣어야 합니다.

auditd, AIDE 및 중앙 집중식 원격 로깅의 구현을 통해 포렌식 가시성 공백을 해결하면, 사고 대응(Incident response) 활동을 위해 공격자의 지속성(Persistence) 증거가 안전하게 보존됩니다. 조직은 이렇게 강화된 텔레메트리를 활용하여 정적인 침해 지표(IoCs)에 의존하기보다는 패턴 기반의 행동 탐지(Behavioral detections) 체계를 구축해야 합니다. 공격자들이 전체 공격 생명 주기에 걸쳐 점점 더 AI를 활용함에 따라, 이 가이드에 명시된 하드닝 및 로깅 제어는 승인되지 않은 모든 움직임이 즉각적이고 변경 불가능한 포렌식 대응으로 이어지도록 보장하는 보편적인 vSphere 보안 베이스라인이 되어야 합니다.