하이퍼바이저 보안 : ESXi와 KVM의 차이, 보안점검 범위와 침해 영향

서버 보안점검에서는 보통 운영체제의 계정과 권한, 접근통제, 서비스 설정, 보안 패치 등을 확인한다. Linux 서버라면 SSH와 계정 권한, Windows 서버라면 로컬 보안 정책과 서비스 설정 등이 점검 대상이다.

가상화 환경에서는 여기에 하이퍼바이저(Hypervisor)가 추가된다. 여러 가상머신(VM)을 실행하고 관리하는 계층이다.

개별 VM의 운영체제와 하이퍼바이저는 관리하는 범위가 다르다. 하이퍼바이저는 여러 VM에 자원을 나누어 주고 서로 격리하므로, 이 계층의 권한이 탈취되면 함께 실행 중인 VM까지 영향을 받을 수 있다.

그중 ESXi와 KVM은 같은 하이퍼바이저로 묶이지만, 내부 구조와 운영 방식에 차이가 있다.

하이퍼바이저란?

하이퍼바이저는 하나의 물리 서버에서 여러 운영체제를 독립적으로 실행하도록 하드웨어 자원을 가상화하는 소프트웨어이다.

예를 들어 CPU 64코어, 메모리 256GB인 물리 서버가 있다고 하자. 하이퍼바이저는 이 자원을 여러 VM에 나누어 할당한다. 각 VM에는 Windows나 Linux를 설치하고, 사용자는 각각을 독립된 서버처럼 이용한다.

주요 역할은 아래와 같다.

• CPU 및 메모리 관리: 물리 서버의 자원을 여러 VM에 할당하고 실행을 제어한다.
• 스토리지 가상화: VM에 가상 디스크를 제공하고 실제 저장장치와 연결한다.
• 네트워크 가상화: 가상 스위치와 가상 네트워크 인터페이스를 통해 VM 간 통신을 처리한다.
• VM 격리: 개별 VM이 다른 VM의 메모리나 자원에 임의로 접근하지 못하도록 제어한다.
• VM 실행 및 관리: VM의 시작, 중지, 자원 변경 등 운영 기능을 제공한다.

여러 VM의 자원과 실행 권한이 이 계층에 모인다. 하이퍼바이저가 중요한 보안 경계인 이유이다.

Type 1과 Type 2

하이퍼바이저는 보통 Type 1과 Type 2로 구분한다.

Type 1(Bare-metal)은 물리 하드웨어에서 직접 가상화 기능을 수행하는 방식이다. VMware ESXi, Microsoft Hyper-V, KVM 등이 대표적이다.

Type 2(Hosted)는 일반 운영체제 위에서 애플리케이션 형태로 실행되는 방식이다. VMware Workstation이나 Oracle VirtualBox 등이 여기에 해당한다.

기업 데이터센터와 클라우드에서는 주로 Type 1을 사용한다. ESXi와 KVM도 여기에 속하며, 실제 구성은 아래와 같이 다르다.

ESXi와 KVM의 구조적 차이

VMware ESXi

ESXi는 물리 서버에 직접 설치하는 베어메탈 하이퍼바이저이다. ESXi 자체가 호스트 운영 환경이고, VMkernel이라는 전용 커널이 가상화 기능을 담당한다. 별도의 Windows나 일반 Linux를 먼저 설치하는 과정은 없다.

간단히 그리면 아래와 같다.

ESXi에는 관리 인터페이스와 관련 서비스가 포함되어 있다. 여러 ESXi 호스트를 중앙에서 관리할 때는 vCenter Server를 사용한다.

호스트 보안 설정도 VMware가 제공하는 기능과 보안 가이드를 기준으로 확인한다. 패키지나 보안 프로그램을 설치할 때는 해당 제품의 ESXi 지원 여부와 버전별 호환성을 먼저 확인해야 한다.

참고로 VMware Cloud Foundation 9.0부터는 ESX라는 명칭을 다시 사용한다. 이 글에서는 익숙한 ESXi로 표기하였다.

KVM

KVM(Kernel-based Virtual Machine)은 Linux 커널에 통합된 가상화 기술이다. Linux를 설치하고, 그 커널에 포함된 KVM 기능을 사용하는 구조이다. RHEL, Ubuntu, Rocky Linux 등 여러 배포판에서 사용할 수 있다.

KVM 환경에서는 보통 아래 세 가지 구성요소를 함께 사용한다.

• KVM: Linux 커널에서 CPU와 메모리 등 하드웨어 가상화 기능을 제공한다.
• QEMU: VM 실행과 가상 하드웨어 에뮬레이션을 담당하는 사용자 공간 구성요소이다.
• libvirt: VM을 생성하고 관리하기 위한 API와 관리 기능을 제공한다.

QEMU와 libvirt는 Linux의 사용자 공간에서, KVM은 커널 안에서 동작한다. KVM도 일반적으로 Type 1으로 분류하며, Linux 커널과 운영체제의 보안 기능을 함께 활용한다.

ESXi와 KVM 비교

구분	VMware ESXi	KVM
호스트 운영체제	ESXi 자체	Linux
커널	VMware VMkernel	Linux 커널
가상화 방식	전용 하이퍼바이저	Linux 커널 기반
주요 관리 구성요소	ESXi, vCenter	QEMU, libvirt 등
OS 보안 설정	ESXi 전용 설정	일반 Linux 보안 설정
패치 관리	VMware 보안 업데이트	Linux 커널 및 가상화 패키지 업데이트
중앙 관리	vCenter 등	OpenStack 등
보안점검 기준	ESXi 보안 가이드	Linux 보안 기준 + KVM 관련 설정

점검 범위도 이 구조를 따라간다. ESXi는 전용 하이퍼바이저 설정을 중심으로 확인하고, KVM은 Linux 호스트와 가상화 구성요소를 함께 확인한다.

하이퍼바이저 보안점검 범위

점검 대상은 호스트와 가상화 구성요소, 중앙 관리 시스템, 가상 네트워크, 스토리지, VM 내부 운영체제로 나누어 볼 수 있다.

1. 하이퍼바이저 호스트

ESXi에서는 관리 인터페이스 접근통제, 계정과 권한, 불필요한 서비스, 보안 패치 등을 확인한다. Secure Boot와 Lockdown Mode 같은 ESXi의 보안 기능도 점검 대상이다.

KVM 호스트는 Linux 서버이므로 계정과 패스워드 정책, SSH 접근통제, sudo 권한, 불필요한 서비스, 커널과 패키지의 취약점 등을 확인한다.

여기에 KVM, QEMU, libvirt의 설정을 더한다. libvirt 관리 권한과 VM 프로세스 실행 권한이 과도한지, SELinux나 AppArmor를 통한 VM 격리가 적절한지 살펴본다.

2. 중앙 관리 시스템

호스트가 여러 대라면 중앙 관리 시스템도 점검해야 한다. ESXi에서는 vCenter, KVM 기반 클라우드에서는 OpenStack 같은 플랫폼이 사용될 수 있다.

중앙 관리 시스템은 여러 호스트와 VM의 생성, 삭제, 변경을 제어한다. 아래 항목을 확인하는 이유도 이 권한 때문이다.

• 관리 인터페이스에 접근할 수 있는 네트워크와 IP 제한
• 관리자 계정의 다중요소 인증(MFA) 적용
• 역할 기반 접근제어(RBAC) 및 최소권한 설정
• API 및 서비스 계정의 권한 관리
• VM 생성, 삭제, 스냅샷, 디스크 내보내기 등의 작업 이력
• 중앙 관리 서버의 보안 패치와 취약점 관리

관리자 권한이 탈취되면 해당 계정이 제어할 수 있는 호스트와 VM이 함께 영향을 받는다. 호스트의 설정을 점검할 때 중앙 관리 시스템의 접근권한도 같이 확인해야 한다.

3. 가상 네트워크

VM 간 통신 경로도 살펴볼 필요가 있다. 같은 물리 서버에 있는 VM 두 대가 같은 가상 스위치에 연결되어 있다면, 통신이 호스트 내부에서 처리되어 물리 방화벽을 거치지 않을 수 있다.

이 경로의 접근통제는 가상 스위치와 네트워크 세그먼트, 분산 방화벽, VM 내부 방화벽 등의 구성에 따라 달라진다. 물리 방화벽 정책을 확인할 때 호스트 내부 통신의 통제 지점도 함께 확인하는 것이 좋겠다.

관리망, 서비스망, 스토리지망, 라이브 마이그레이션망은 용도에 맞게 분리하고, 각 망에서 허용할 통신을 제한한다.

4. 가상 디스크와 스토리지

VM의 가상 디스크와 스냅샷에는 운영체제와 애플리케이션 데이터가 들어간다. 따라서 이 파일에 접근할 수 있는 계정과 시스템도 점검 대상이다.

스토리지 공유 범위, 스냅샷 생성·삭제 권한, 백업 저장소 접근통제, 암호화 적용 여부 등을 확인한다. 여러 호스트가 스토리지를 공유한다면, 호스트 한 대에서 어떤 파일까지 접근할 수 있는지도 살펴봐야 한다.

5. VM 내부 운영체제

VM 내부 운영체제의 계정과 서비스, 취약점은 별도로 점검한다. 하이퍼바이저의 격리 설정과 게스트 OS의 보안 설정은 각각 관리하는 영역이다.

Linux VM에는 Linux 기준을, Windows VM에는 Windows 기준을 적용한다. 하이퍼바이저와 게스트 OS를 각각 점검 대상으로 두는 방식이다.

침해 시 영향 범위: Blast Radius

Blast Radius는 침해 사고가 주변 시스템과 서비스에 미칠 수 있는 영향 범위이다. 가상화 환경에서는 어느 계층의 권한이 탈취되었는지에 따라 이 범위가 달라진다.

VM 한 대가 침해된 경우

VM 내부의 관리자 권한이 탈취된 경우, 우선 직접 제어할 수 있는 대상은 해당 VM이다. VM 사이의 메모리와 자원은 하이퍼바이저가 격리한다.

이후 네트워크를 통한 내부 이동이나 다른 계정의 탈취가 이어지면 피해가 확산될 수 있다. VM Escape처럼 가상화 경계를 벗어나는 취약점이 악용되는 경우에도 호스트와 다른 VM까지 영향을 받을 수 있다.

ESXi 호스트가 침해된 경우

ESXi 호스트의 높은 권한을 확보한 공격자는 접근 가능한 범위에서 VM을 중지하거나, 가상 디스크와 설정을 변경하거나, 데이터에 접근할 수 있다.

예를 들어 호스트 한 대에 VM 20대가 실행 중이라면, 그 20대가 직접적인 영향 대상이 될 수 있다. 공유 스토리지나 다른 관리 계정까지 접근할 수 있는 환경에서는 다른 호스트로 피해가 이어질 가능성도 있다.

2023년 ESXiArgs 랜섬웨어 공격에서도 취약한 ESXi 서버가 공격받았고, VM 관련 파일이 암호화되면서 가상머신을 사용할 수 없는 피해가 발생하였다.

KVM 호스트가 침해된 경우

KVM도 Linux 호스트의 root 권한이 탈취되면 그 위에서 실행되는 여러 VM이 위험해진다. 일반적인 KVM 환경에서는 VM이 QEMU 프로세스로 실행되므로, 호스트의 높은 권한으로 VM 프로세스와 관련 파일, 관리 기능에 접근할 수 있다.

실제 접근 범위는 SELinux, 프로세스 격리, 파일 권한, 암호화 등의 구성에 따라 달라진다. 여러 VM을 제어하는 KVM 호스트는 그 관리 범위에 맞는 중요 자산으로 취급할 필요가 있다.

중앙 관리 시스템이 침해된 경우

중앙 관리 시스템의 침해는 여러 호스트에 걸쳐 영향을 줄 수 있다. 아래와 같은 가상 환경을 예로 들어보자.

• 물리 서버 4대
• 호스트당 VM 20대
• 전체 VM 80대
• 모든 호스트를 하나의 중앙 관리 시스템에서 관리

VM 한 대의 관리자 권한이 탈취되면 최초의 직접적인 피해 대상은 그 VM이다. 호스트 한 대의 관리자 권한이 탈취되면 해당 호스트의 VM 20대가 영향을 받을 수 있다.

중앙 관리 시스템의 전체 관리자 권한까지 탈취되면 호스트 4대와 VM 80대가 모두 잠재적인 영향 범위에 들어간다. 설명을 위한 예시이며, 실제 범위는 계정 권한과 호스트 연결 구조, 스토리지 구성, 보안 통제에 따라 달라진다.

침해 지점별 영향 범위

침해 지점	직접적인 영향 대상	추가 확산 가능성
개별 VM	해당 VM의 데이터와 서비스	네트워크 이동, 계정 탈취, VM Escape
ESXi 호스트	해당 호스트의 VM과 접근 가능한 자원	공유 스토리지, 관리 계정 등을 통한 확산
KVM 호스트	해당 호스트의 VM과 접근 가능한 자원	관리 서비스, 공유 자원을 통한 확산
vCenter	관리 권한이 있는 호스트와 VM	다수 클러스터 및 서비스로 확산
OpenStack 관리 영역	탈취한 권한으로 제어 가능한 클라우드 자원	여러 컴퓨트 호스트 및 테넌트로 확산 가능
공유 스토리지·백업 관리 시스템	접근 가능한 가상 디스크 및 백업	다수 VM의 데이터 유출·변조·복구 실패

이때는 이미 확보한 권한으로 접근할 수 있는 범위와 추가 공격이 필요한 범위를 나누어 보아야 한다. 호스트 한 대에서 클러스터 전체로 확산하려면 다른 자원에 접근할 권한이나 추가 공격 경로가 필요하다. 관리 계정과 공유 스토리지의 권한이 넓을수록 그 경로도 늘어날 수 있다.

보안점검 범위는 어떻게 정해야 할까?

점검표는 제품별 구조를 반영해 구성하는 것이 좋겠다. ESXi와 KVM의 공통 항목을 두고, 각각의 호스트와 가상화 구성요소에 맞는 항목을 추가하는 방식이다.

점검 영역	ESXi	KVM
하드웨어·펌웨어 보안	적용	적용
호스트 OS 계정·서비스 점검	ESXi 전용 기준	Linux 기준
커널·패키지 취약점	ESXi 업데이트 기준	Linux 커널 및 패키지 기준
가상화 구성요소 보안	ESXi 설정 및 서비스	KVM, QEMU, libvirt
관리자 접근통제	ESXi, vCenter	SSH, libvirt, 관리 플랫폼
VM 격리 설정	적용	적용
가상 네트워크 보안	적용	적용
스토리지·스냅샷 보안	적용	적용
게스트 OS 보안	별도 점검	별도 점검

나는 공통 점검 항목을 먼저 정리하고 제품별 기준을 더하는 방식이 관리하기에 수월하다고 생각한다.

관리자 접근통제, 권한, 패치, 로깅, 네트워크 분리, 스토리지 보호는 공통 영역으로 둔다. ESXi에는 Lockdown Mode와 ESXi 서비스 설정을, KVM에는 SSH, sudo, SELinux/AppArmor, libvirt 권한, QEMU 프로세스 격리 등을 추가한다.

자산 목록에도 물리 호스트, 중앙 관리 시스템, 스토리지, 백업 인프라를 포함해야 한다. VM 목록과 함께 이 자원들의 연결 관계와 관리 권한을 파악해두는 것이 좋겠다.

Blast Radius를 줄이기 위한 보안 설계

설정과 패치를 점검하면서 사고가 발생했을 때 피해가 어디까지 이어질지도 함께 고려해야 한다.

관리망에 접근하는 시스템과 계정은 필요한 범위로 줄인다. 관리자는 통제된 경로로 접속하도록 하고, 중앙 관리 시스템에는 MFA와 최소권한을 적용한다.

VM 배치도 영향을 준다. 업무 중요도와 보안 수준에 따라 배치를 검토하고, 강한 격리가 필요한 시스템은 별도의 호스트나 클러스터를 사용하는 방안도 고려할 수 있다.

가상 네트워크에서는 업무에 필요한 VM 간 통신만 허용한다. 물리 방화벽과 가상 방화벽이 각각 어느 경로를 통제하는지도 명확히 해두어야 한다.

스토리지와 백업은 관리 권한을 분리할 필요가 있다. 하이퍼바이저 관리자 계정으로 백업까지 삭제할 수 있다면 랜섬웨어 사고에서 복구 수단도 함께 잃을 수 있다. 백업의 불변성과 권한 분리, 정기적인 복구 검증을 함께 챙겨야 한다.

점검 결과의 위험도 역시 해당 자산의 관리 범위에 따라 판단하는 것이 적절하다. 같은 접근통제 취약점이라도 업무용 VM 한 대와 전체 클러스터를 관리하는 시스템에서의 잠재적 피해 규모는 다르기 때문이다.

마무리

ESXi는 전용 VMkernel을, KVM은 Linux 커널의 가상화 기능을 사용한다. 같은 하이퍼바이저라도 점검 기준에 차이가 생기는 이유이다.

ESXi는 전용 보안 설정을 중심으로, KVM은 Linux 호스트와 가상화 구성요소를 함께 점검한다.

그리고 개별 VM에서 호스트, 중앙 관리 시스템, 가상 네트워크, 공유 스토리지로 점검 범위를 넓혀가며 서로의 연결 관계를 확인한다.

개인적으로는 취약점 목록을 정리하는 만큼, 그 자산이 어느 범위까지 제어할 수 있는지 파악하는 과정이 중요하다고 본다.

호스트 한 대의 권한이 탈취되었을 때 어떤 VM과 스토리지에 접근할 수 있는지, 중앙 관리 계정으로 어디까지 변경할 수 있는지 설명할 수 있어야 한다. 이 범위를 파악해두어야 점검 우선순위와 피해를 줄일 방법도 구체적으로 정할 수 있을 것이다.

참고자료

• NIST SP 800-125A Rev.1 – Security Recommendations for Server-based Hypervisor Platforms
• NIST SP 800-125B – Secure Virtual Network Configuration for VM Protection
• VMware – What is a Hypervisor?
• VMware – vSphere Security Configuration & Hardening Guide
• Red Hat – RHEL Virtualization Architecture
• Red Hat – Securing Virtual Machines
• CISA – ESXiArgs Ransomware Virtual Machine Recovery Guidance