vSphere 6.7 Update 2의 릴리스에는 새로운 vSphere CPU 스케줄러 옵션인 Side-Channel Aware Scheduler v2(SCAv2) 또는 “Sibling Scheduler”가 포함되었다. 이 새로운 스케줄러는 CPU 취약점 완화에 대한 손실된 성능을 복구하는 데 도움이 될 수 있지만, 그에 따른 위험도 수반할 수 있다. 더욱 복잡한 문제는 최신 Intel CPU 취약성, CVE-2018-12126, CVE-2018-12127, CVE-2018-121 및 CVE-2019-11091로 식별된 MDS(Micro Architectural Data Sampling) 및 VMware Security Advisory VMSA-2019-0008이다. 우리의 목표는 이 게시물이 vSphere 6.7 CPU Scheduler Advisor 툴과 결합되어 고객이 비즈니스 관점에서 위험과 가능한 솔루션에 대한 대화를 시작할 수 있도록 돕는 것이다.
이 글은 복잡한 주제라서 길다. 원하는 경우 vSphere 6.7 CPU Scheduler Advisor를 직접 방문하거나 아래쪽의 일반적인 질문으로 넘어가기 바란다.
CPU Scheduler는 무엇이고 왜 관심을 가져야 하는가?
간단히 말해서 vSphere CPU 스케줄러 ESXi에서 VM이 사용할 프로세서를 얻는 것을 결정한다. 프로세서의 활용도를 극대화하는 동시에 모든 워크로드에 공정하게 대응하려고 노력한다. CPU에 워크로드를 배치하는 방법을 결정할 때 스케줄러는 CPU 캐시, 메모리 인접성, 성능 요구, 우선순위, 스토리지 및 네트워크에 대한 I/O 등과 같은 많은 요소를 고려한다.
CPU 취약성은 주요 CPU 벤더가 제공하는 프로세서에 존재하는 보안 문제들이다. 보안문제는 특히 심각하다. 왜냐하면 이러한 문제들은 공격자들이 우리의 환경에서 구축한 다른 모든 보안 통제장치들을 우회할 수 있게 할 수 있고, 전통적인 방법을 통해서는 감지할 수 없기 때문이다.
예상할 수 있듯이, 소프트웨어와 달리 컴퓨터의 프로세서는 서버나 데스크탑 내부에 있고, 일단 만들어지고 고객에게 배송되면 업데이트하기가 어렵거나 불가능하다. ESXi는 소프트웨어고, VMware로 인해 발생한 문제는 아니지만 Spectre, Meltdown, L1TF 및 MDS와 같은 취약성에 있는 문제를 방지하는 방법을 vSphere CPU 스케줄러에게 가르칠 수 있으다. ESXi의 일부로 제공되거나 벤더 펌웨어 업데이트에 제공된 마이크로코드를 사용하여 CPU 벤더가 제공하는 새로운 지침을 활용한다.
그러나 이는 보안 위험과 성능 모두에 대한 트레이드오프를 수반한다. 예를 들어, L1TF 취약성은 프로세서가 Intel CPU의 코어에 있는 두 스레드 간에 정보를 누출할 수 있는 문제를 노출시켰다. 원래 ESXi Side-Channel Aware Scheduler, 버전 1(SCAv1)은 스레드(Intel Hyper-Threading)의 사용을 허용하지 않음으로써 우리를 보호하는 데 도움을 주었고, 그에 따라 문제를 완화시켰으나 CPU 용량에서 비용이 발생하였다. 또한 MDS 취약성은 프로세스 간에 정보가 유출될 수 있으므로 SCAv1은 이를 완화하기 위한 좋은 선택이다. 그러나 경우에 따라서는 가상 머신 내에서 Hyper-Threading을 사용할 수 있는 보안 요구사항이 필요할 수 있다. SCAv2는 하이퍼스레딩을 사용할 수 있게 해주며, 손실된 성능과 용량의 일부를 되찾을 수 있다.
이러한 공격은 이론적이지 않기 때문에 모든 경우에 위험을 신중하게 고려할 필요가 있다. 유투브에서는 이러한 공격 각각에 대한 실무적인 데모가 있다. 데모 중 하나는 Active Directory 도메인 컨트롤러인 다른 가상 시스템에서 사용자 이름과 암호를 복구하는 사용하기 쉽고 상용화된 도구를 보여준다. 그것은 매우 심각한 문제다.
어떻게 CPU 스케쥴러 선택하는가?
ESXi 6.7 Update 2에서 선택할 수 있는 스케줄러는 3가지 : Default, SCAv1, SCAv2
Default
기본 스케줄러는 고유한 보안 인식은 없지만 성능이 가장 우수하다. 기본 스케줄러가 있는 호스트에서 실행되는 모든 워크로드가 서로의 데이터를 볼 수 있다고 가정해야 한다.
Side-Channel Aware Scheduler v1 (SCAv1)
SCAv1은 L1TF 및 MDS를 보조하며 가장 안전하지만 가장 느릴 수 있는 프로세스별 보호를 구현한다.
Side-Channel Aware Scheduler v2 (SCAv2)
SCAv2는 VM당 보호를 구현하지만 사용과 관련된 위험에 대한 고려가 필요하다.
vSphere 6.7 CPU Scheduler Advisor 사용
vSphere Central에서 사용할 스케줄러(vSphere 6.7 CPU Scheduler Advisor)를 결정하는 데 도움이 되는 사용하기 쉬운 의사결정 트리를 컴파일했다. 당신이 그것을 방문할 때, 당신은 몇 가지 질문을 받을 것이다.
“Does any VM on this cluster contain data, secrets, or credentials that you would not want leaked to an adversary?”
“이 클러스터의 VM에 상대에게 유출되지 않을 데이터, 비밀 또는 자격 증명이 포함되어 있는가?”
솔직히 말해서, 대부분의 조직에서 이에 대한 대답은 ‘Yes’일 것이다. 상대(adversary)는 무슨 의미일까? 네가 믿지 않는 사람. 이는 귀사의 지적 재산, 재무 기록, 직원 정보 또는 고객 목록 도용에 관심이 있는 비즈니스, 해킹 그룹 또는 국영 APT 그룹에서의 경쟁일 수 있다. 데이터, 비밀 또는 자격 증명을 의미하는 것은? 추가 공격이나 타협을 위해 당신을 열 수 있는 모든 데이터. 로그인 암호, 암호화 키, 디지털 인증서, CFO 데스크탑의 회사에 심각한 재정 또는 법적 문제를 일으킬 수 있는 Excel 스프레드시트의 암호 등.
“Does any VM have multiple users or processes where you do not want to leak secrets between those users or processes? This includes VBS, containers, terminal servers, etc.”
“VM에 사용자나 프로세스 간에 비밀을 누설하지 않을 여러 사용자 또는 프로세스가 있는가? 여기에는 VBS, 컨테이너, 터미널 서버 등이 포함된다.”
사용할 스케줄러를 결정할 때 고려해야 할 중요한 사항 중 하나는 가상 시스템 내의 모든 프로세스가 동일한 보안 요구와 위험을 가지고 있는지 여부다. L1TF와 MDS는 프로세스 사이에 비밀이 새도록 허용하기 때문에, 만약 그러한 프로세스가 다른 사용자, 다른 고객 또는 다른 애플리케이션에 속한다면, 그들은 모두 동일한 보안 범위에 속하게 된다. 이 위험 수준은 문제가 될 수 있으며 오직 당신만이 위험관리 결정을 내릴 수 있다.
VBS(Virtualization-Based Security)는 마이크로소프트 VBS를 가능하게 하는 기능으로, 장치 가드(Device Guard)와 인증 가드(Credential Guard)라고도 한다. vSphere 6.7 이후 ESXi에서는 VBS가 필요한 윈도우즈 VM을 실행하도록 지원한다. 이는 Hyper-V 하위 시스템의 일부를 사용하는 마이크로소프트 Windows 10/2016/2019의 기능을 활성화하여 자격 증명 및 기타 비밀을 위한 격리되고 안전한 공간을 만들 수 있다. VBS는 많은 자격 증명 도난 공격을 방지하고 많은 유형의 악성코드를 파괴하는 데 도움이 된다. 그러나 Default 스케줄러와 SCAv2 스케줄러 모두에서 가능할 수 있는 정보 누출을 원하지 않을 수 있는 프로세스 유형을 나타낸다.
SCAv1을 선택할 수 없더라도 VBS를 실행하는 데에는 여전히 만만찮은 이점이 있지만, 결정시 어떻게 진행해야 하는지에 대해 고려해야 한다. 마찬가지로 사용자가 여러 개인 터미널 서버, 컨테이너 및 기타 형태의 중첩된 가상화가 모두 고려되어야 한다. 단일 대형 VM이 컨테이너 내부에서 실행되는 여러 다른 애플리케이션을 호스팅하는 경우가 많다.
“Does any VM run untrusted code, including Java or Javascript, or from untrusted sources?”
“Java, Javascript, 신뢰할 수 없는 출처등의 신뢰할 수 없는 코드를 실행하는 VM이 있는가?”
여기서의 뻔한 반은 “절대 아니다!”일 수도 있지만, 당신은 데스크탑 OS, 웹 브라우저, 터미널 서버 및 오픈 인터넷에서 이용 가능한 소프트웨어의 사용을 고려하기를 원할 수도 있다. 사용자가 웹 사이트를 탐색하고 제어되지 않는 소스에서 잠재적으로 Javascript를 실행할 수 있는가? 공개 레지스트리에서 가져온 컨테이너 이미지를 사용하는가? NPM, CPAN, PowerShell 갤러리와 같은 리포지토리의 소프트웨어 모듈을 사용하는가? 또는 공공 기부를 허용하는 다른 곳에서 사용하십니까? 모든 소프트웨어 업데이트 저장소(WSUS, SCCM, Yum 저장소 등)가 암호화된 서명, 확인 및 공급업체의 지원을 받고 있는가? 이것들은 판단이 아니라, 단지 신뢰할 수 없는 코드가 어떻게 환경에 몰래 침투하여 이 질문에 대한 해답에 영향을 미칠 수 있는지에 대해 생각해 볼 뿐이다.
“Do you have CPU capacity headroom in the cluster?”
“클러스터에 CPU 용량 여유분이 있는가?”
이러한 교정조치의 성능 영향은 모든 워크로드에 서로 다르게 영향을 미친다. 즉, SCAv1 최악의 경우 성능 손실은 일반적으로 30%로 간주되고, SCAv2는 일반적으로 10%다. 클러스터에 추가 CPU 여유분이 없는 경우 문제가 발생할 수 있다. 그렇다고 가정할 때, 더 느린 워크로드를 허용할 수 없다고 가정할 때 고려해야 할 옵션이 있다.
첫째, 다른 호스트에서 서로 다른 스케줄러를 사용하도록 설정할 수 있지만, 그렇게 하는 것은 좋은 생각이 아니다. 항상 클러스터의 모든 호스트에서 동일한 스케줄러를 사용하도록 설정한다. 다른 스케줄러를 갖는 것은 혼란(confusion), 오류, 보안, 성능 문제에 대한 해결책이다. 즉, 별도의 클러스터에서 SCAv1의 프로세스별 보호가 필요한 워크로드를 격리하고 워크로드 위험과 호환되는 다른 클러스터에서 SCAv2를 실행하는 것이 유효한 접근방식일 수 있다.
둘째, SCAv2를 활성화하면 SCAv1의 완전한 보호는 아니지만 몇 가지 보호 기능이 제공된다. SCAv1이 필요한 경우 SCAv1을 목표로 해야 하지만 SCAv2는 미봉책일 수 있다.
셋째, 클러스터에서 EVC(향상된 vMotion Compatibility)를 사용하도록 설정한 경우 추가 용량을 쉽게 추가할 수 있다. 추가 용량을 확보한 후 클러스터에 추가한다. EVC는 가상 머신이 이전 하드웨어와 새로운 하드웨어 사이에서 원활하게 vMotion을 수행할 수 있도록 CPU 세대 간의 차이를 감추기 때문에 클러스터를 구축할 때 종종 간과되는 엄청난 “미래 방지” 툴이다. 18개월마다 새로운 CPU를 사용할 수 있게 되며, 이러한 새로운 CPU는 항상 vMotion이 서버 간에 VM을 이동할 수 없도록 하는 새로운 지침과 기능을 가지고 있다. EVC는 vMotion이 계속 작동할 수 있도록 하는 새로운 명령어를 “마스크아웃”한다. 나중에 전체 클러스터를 업그레이드하고 이전 장비를 폐기하면 EVC 레벨을 변경하여 최신 CPU를 지원할 수 있으며 VM은 새로운 CPU 기능을 활용할 수 있다. 실제로 대부분의 엔터프라이즈 워크로드는 새로운 CPU 기능을 활용하지 않으며 EVC가 제공하는 이점은 약간의 성능 차이를 훨씬 능가한다. 지금 EVC를 사용하지 않는 경우 EVC 및 성능에 대한 이전 백서를 검토하기 바란다.
넷째, 하드웨어가 노후화되고 있는 경우 성능 및 시스템 크기 조정 옵션(데이터 센터 공간, 전력, 냉각, 포트 수 및 기타 인프라 비용 절감)으로 인한 서버 수 감소, vSAN 및 유휴 데이터 사용 기회 및 확장된 데이터 등 다른 이점을 고려할 수 있다. 클러스터 기능, NSX, AppDefense, 재해 복구를 위한 VMware Cloud on AWS & HCX 등
vSphere는 소프트웨어 정의 데이터 센터를 구축할 수 있는 매우 성숙하고 안정적이며 믿을 수 없을 정도로 안전한 플랫폼이며, 소프트웨어 정의 데이터 센터는 소유 비용 및 긍정적인 직원 시간 향상 측면에서 엄청난 이점을 가지고 있다.
일반적인 질문
- Q1: VMware 소프트웨어에 문제가 있고 다른 소프트웨어에 문제가 없는가?
A1: VMware의 문제가 아니라 서버나 데스크탑 내부의 프로세서 하드웨어에 문제다. 모든 주요 운영 체제(ESXi, Microsoft Windows, 다양한 Linux 배포)는 이러한 기술을 사용하여 사용자가 이 문제에 대처할 수 있도록 돕는다. 왜냐하면 소프트웨어 치료법이 없다면 실행 가능한 해결책이 전혀 없을 것이기 때문이다. CPU 취약성은 가상 환경뿐만 아니라 전용 물리적 하드웨어에도 영향을 미친다. 운영 체제 벤더가 이러한 문제를 해결하도록 선택하는 방법, 성능에 미치는 영향, 시스템의 설계 또는 운영에 영향을 미칠 수 있는 수정에 대한 절충에 대한 자세한 내용은 해당 운영 체제 벤더의 문서 및 지원을 참조하기 바란다. 예를 들어 성능상의 이유로 일부 운영 체제는 권한 상승으로 실행되는 프로세스에 기본적으로 취약성 완화를 적용하지 않는다. - Q2: 방화벽이 이러한 특정 보안 문제를 잡아낼 수 있는가?
A2: 대부분 아니오. 하지만 공급업체와 함께 확인하십시오. - Q3: EDR/안티바이러스 소프트웨어가 이러한 특정 보안 문제를 잡아낼 수 있는가?
A3: 대부분 아니오. 하지만 공급업체와 함께 확인하십시오. - Q4: vSphere 6.7 업데이트 2에 대해 설명하지만, 우리는 vSphere 6.0에 있다. 무엇을 선택할 수 있나요?
A4: vSphere 6.0 및 6.5에는 기본 및 SCAv1의 두 개의 스케줄러만 있다. 6.7의 아키텍처 변경으로 인해 SCAv2 스케줄러는 하위 버전으로 이동되지 않는다. 6.7 Update 2로 업그레이드하는 프로세스는 매우 쉬우며, 고객들이 새로운 스케줄러와 많은 다른 개선사항에 접근할 수 있도록 업데이트할 것을 권고한다. 이는 vSphere 6.0이 2020년 3월 12일에 지원되지 않기 때문에 vSphere 6.0 이하를 실행하는 고객에게 특히 해당된다. 멀지 않았다. VMware에서 업그레이드에 도움이 되는 리소스에 대한 자세한 정보나 액세스를 원하시면 VMware 계정 팀 또는 기술 계정 관리자에게 문의하십시오. - Q5: 하드웨어 문제인 만큼, 이러한 문제를 해결하는 하드웨어를 구입할 수 있는가?
A5: 답은 부분적으로 그렇다. 최신 Intel CPU는 이러한 취약성에 대한 교정 기능을 제공한다. 또한 AMD와 같은 서로 다른 CPU 벤더의 하드웨어는 서로 다른 영향을 받는다. CPU 및 하드웨어 공급업체 설명서를 참조하기 바란다. - Q6: CPU 스케줄러 이외의 다른 작업은?
A6: 관련 VMware KB의 절차에 따라 새 vSphere CPU 스케줄러를 구현한 후에는 게스트 OS(Microsoft Windows, Linux 배포 등)의 모든 업데이트를 활성화하고 작동하는지 확인하십시오. 여기에는 VM의 전원 사이클도 포함될 수 있다. 또한 하드웨어 펌웨어를 최신 상태로 유지하는 것은 다른 가능한 취약성(관리 컨트롤러 등)을 제거하고 가용성과 성능에 영향을 미칠 수 있는 NIC 및 기타 구성요소를 사용한 버그를 해결하는 데 도움이 되므로 권장한다. - Q7: 클라우드가 영향을 받는가?
A7: 당연하다. 모든 클라우드 공급업체는 이러한 문제에 영향을 받고 있으며, 대부분은 이러한 문제를 해결하기 위해 환경을 개선했다. VMware Cloud on AWS는 완벽하게 사전 예방적으로 개선되었다. VMware Cloud on AWS 고객은 전용 하드웨어에서 실행되고 있기 때문에 교차 고객 오염 및 위협 문제는 적용되지 않는다. - Q8: 내 규정 준수 프레임워크와 지침은 이러한 문제를 전혀 언급하지 않는다. 내가 뭘 해야 하나?
A8: 준수와 보안은 서로 다른 것이지만, 서로 관련이 있다. 규정 준수 지침에 따르면 벤더가 지원하는 소프트웨어 및 하드웨어를 실행하고 벤더가 제공하는 업데이트 및 패치를 최신 상태로 유지해야 한다. 이 문제들은 그러한 범주에 속할 것이다. 의심스러운 경우 규정 준수 감사, VMware 계정 팀 또는 기술 계정 관리자를 관리하는 사람에게 문의하십시오. 컴플라이언스 목표를 단순히 달성하는 대신 항상 진정한 보안 제어와 취약성 교정 조치를 선택할 것을 권장한다. 해커들은 네가 고분고분해도 상관 없다! - Q9: VMware Global Support Services에서 여러 스케줄러를 지원하는가?
A9: 물론, 관련 KB에 모든 변경의 개요가 서술되어 있다. - Q10: 그럼 SCAv2로 전환해서 모든 것이 해결는가?
A10: 아니! 각 환경은 다르고, 각 조직마다 보안 요구와 책임이 다르다. 이는 비즈니스 결정이며, 리스크 대 비용 대 법적 및 홍보의 잠재성 및 기타 문제이므로, 조직 내 많은 그룹(CISO, CFO, CIO, CEO) 간의 대화가 필요하다. 이러한 문제에는 “쉬운 버튼”이 없다. - Q11: 게스트 OS에 업데이트를 적용한 후 가상 시스템을 하드 재부팅해야 하는 이유는?
A11: ESXi 하이퍼바이저 내에서 가상 시스템이 프로세스로 실행된다. Virtual Machine Monitor고 부르는 이 프로세스는 게스트 OS와 서버 하드웨어 사이의 관계를 처리하는 역할을 한다. 이 프로세스를 통해 게스트 OS에 새로운 CPU 취약점 완화를 상속하고 표시하려면 Virtual Machine Monitor를 다시 시작해야 한다. 이렇게 하는 방법은 게스트 OS를 종료하고 VM의 전원이 꺼져 있는지 확인하는 것이다. VM의 전원을 다시 켜면 새 CPU 정보가 포함된 새 가상 시스템 모니터 프로세스가 시작되고 이 정보가 게스트 OS에 전달된다. 이것은 불편하지만 PowerCLI로 쉽게 스크립트를 작성할 수 있다. 또한 가상 시스템 하드웨어 호환성 업그레이드를 하기에 좋은 시점이다! - Q12: vSphere 환경에 업데이트를 적용하는 권장 방법은?
A12: 일반적인 대답은 문서에서 순서를 확인하는 것이다. KB 67577부터 시작하기 바란다. 간단히 설명하면 : 항상 vCenter를 먼저 패치하고 ESXi 호스트를 두 번째로 패치한다. 먼저 vCenter를 패치해서 EVC, DRS 등의 측면에서 ESXi 업데이트를 적절하게 조정할 수 있어야 한다. 잘못된 업데이트로 인해 EVC 오류 및 지원 문제가 발생할 수 있다. vCenter 먼저! - Q13: SCAv1 스케줄러를 사용하여 L1TF에 대한 환경에 이미 업데이트를 적용한 경우, MDS에 대해 더 많은 작업을 수행해야 하는가?
A13: MDS(추가 CPU 명령, MDCLEAR)에 대한 업데이트를 받으려면 관련 vSphere 패치 수준으로 업데이트한 다음, VM 전원 사이클을 포함한 게스트 OS에 대한 업데이트를 적용하기 위한 지침을 따르다. - Q14: 이러한 스케줄러가 성능에 미치는 영향은?
A14: 모든 워크로드는 서로 다르게 영향을 받지만 대부분의 사람들은 SCAv1 성능 손실에 대한 최악의 추정치로 30%를 사용하고, SCAv2 성능 손실에 대해서는 10%를 사용한다. - Q15: MDS에 대한 업데이트를 적용하면 다른 모든 취약성에도 적용할 수 있는가?
A15: 예. vSphere 패치가 누적되어 최신 업데이트를 적용한 다음 게스트 OS에 업데이트를 적용하는 절차에 따라 모든 문제가 해결되지만, 각 게스트 OS에는 각 취약성에 대한 절차가 다를 수 있다. mdsatacks.com에서 사용할 수 있는 도구와 같은 도구를 사용하여 작업을 확인하는 것이 항상 권장된다. 가능하면 전용 테스트 환경에서 업데이트를 테스트하는 것이 좋다(중첩된 ESXi 및 vCenter는 훌륭한 테스트 환경임). - Q16: vSphere 업데이트에 CPU 마이크로코드가 포함된 것으로 알고 있다. BIOS를 업데이트해야 하는가?
A16: 추천한다. VMware는 CPU에 대한 추가 CPU 지침을 얻는 데 필요한 것만 제공한다. 그러나 Dell, HP, Lenovo 등과 같은 하드웨어 공급업체는 관리 엔진, iLO 및 iDRAC와 같은 대역 외 컨트롤러, 호환성 및 가용성을 개선하는 HBA & NIC 펌웨어 업데이트를 추가로 제공한다. - Q17: 이러한 새 패치를 적용하면 vSphere 6.7로 업그레이드할 수 있는가?
A17: 그럴 수도, 아닐 수도 있어. 자세한 내용은 업그레이드 호환성 매트릭스를 확인하십시오. - Q18: VMware의 보안 권장 사항에 대해 알아보려면 어떻게 해야 하는가?
A18: 이메일 알림에 등록할 수도 있는 권장 사항 페이지를 방문하십시오!
참고 : L1TF 관련한 VMware 대응 관련 자료
