2019년 8월 VMware는 2세대 EPYC 서버급 CPU를 발표하면서 AMD에 합류했다. vSphere의 향후 릴리즈에서 이러한 CPU의 AMD Secure Encrypted Virtualization(SEV) 및 Secure Encrypted State(SEV-ES) 고급 보안 기능에 대한 지원을 함께 발표했으며 vSphere 7 업데이트 1은 이러한 기능을 고객에게 제공한다는 약속을 지켜준다.
2018년 1월은 인프라 보안의 전환기였다. 보안 연구자들에게 스펙터 및 멜트다운 취약성 발표는 보안 속성에 대해 조사해야 할 하드웨어 기능의 전혀 새로운 세계에 눈을 떴다. 우리는 지난 몇 년간 그 결과를 보았고, 그것은 인프라 보안에 대한 훨씬 더 넓은 관심에 기여했다.
사람들은 사내 데이터 센터 내에서도 클라우드 보안, 심층 방어, 워크로드 간 격리에 대해 올바른 질문을 던지기 시작했다. 하드웨어를 그렇게 믿어야 하는 거야? 소프트웨어를 그렇게까지 믿어야 하는 거야? 워크로드 내부를 다른 사용자가 파악할 수 없도록 하는 방법은 무엇인가? 어떻게 노출을 제한하고, 더 많은 고립을 더하며, 위험을 제한할 것인가?
좋은 질문이며 워크로드가 액세스할 수 있는 하드웨어의 TE(Trusted Execution Environment) 기능에 대한 더 큰 필요성을 말해준다.
AMD의 대응은 AMD CPU 다이 자체에 통합된 소형 코프로세서인 AMD Secure Processor를 추가해 신뢰의 하드웨어 루트를 가능하게 하고, SEV-ES와 같은 기술을 뒷받침하는 암호화 연산을 지원하는 것이었다. 1세대 EPYC CPU로 보안 프로세서는 15개의 암호화 키만 처리할 수 있었지만, 2세대 EPYC CPU는 이를 500개 이상의 키로 확장한다. 하이퍼바이저용 암호화 키 1개와 나머지는 워크로드에 사용할 수 있다.
ESXi의 격리
여러분은 아마도 “왜 우리는 이것이 필요한가?”라고 생각할 것이다. ESXi는 이미 많은 격리를 겪고 있어!” 가상화된 인프라 내부에는 여러 계층의 격리가 존재하지만, 더 많은 옵션을 갖는 것은 매우 좋은 일이다. 게스트 OS에는 자체 프로세스 보호 및 권한 모델이 있으며(물론 윈도우즈 3.1을 아직 실행 중인 경우는 제외). VM 런타임 또는 VMX는 게스트 VM을 실행하는 ESXi 내부의 프로세스인 만큼 격리 자체의 한 형태입니다. VM Runtime 주위에서는 게스트와 나머지 하이퍼바이저를 격리하는 하드 보호 계층인 샌드박스라고 부른다. 이는 모두 동일한 호스트에 있는 워크로드 간의 격리지만, 물리적으로 분리된 호스트에 있는 워크로드에서도 발생하는 격리도 있다.
그러나 이 모든 것은 소프트웨어, CPU, 메모리 컨트롤러, PCIe 버스 컨트롤러 등에 대한 신뢰 수준을 필요로 한다. 마찬가지로 VM도 하이퍼바이저에 대한 신뢰도가 필요하다. 여기가 바로 SEV & SEV-ES가 들어오는 곳이다. SEV를 지원하는 게스트 OS는 AMD Secure Processor에게 암호화 키 발급을 요청하고 전체 메모리 내, 하드웨어 내 암호화를 활성화할 수 있다. SEV-ES는 CPU 레지스터로도 확장하여 CPU 자체 내에서 사용 중인 데이터를 암호화한다. 이는 하드웨어와 하이퍼바이저 모두에서 전체 취약성 클래스에 대한 매우 강력한 보호 기능이다. VM이 CPU(VM의 전원 끄기가 아닌 컨텍스트 스위치라고 함)에서 실행을 중지하면 CPU 레지스터의 내용이 하이퍼바이저 메모리에 복사된다. 손상된 하이퍼바이저는 데이터 자체를 도용하거나, CPU 레지스터에 저장된 암호화 키와 같은 것들을 도용하거나, VM 자체의 동작을 변경하기 위해 데이터를 등록하는 것을 읽거나 수정할 수 있다. 그것들 중 어느 것도 좋은 것은 없다. SEV-ES를 사용하면 게스트가 명시적으로 허용하지 않는 한 하이퍼바이저는 게스트의 암호화 키에 액세스할 수 없어 공격 표면을 크게 줄일 수 있다.
미래를 보는 것은 항상 어렵지만, 이러한 기술의 주요 이점은 미래의 하드웨어 문제로부터 보호받을 수 있는 기회도 제공한다는 것이다. 지난 3년 동안 우리는 많은 취약점이 어디에 있는지 보아왔고, 위험은 많은 곳에서 발견된다. 이와 같이 vSphere 7은 단순한 SEV가 아닌 전체 SEV-ES 지원을 제공하는 최초의 하이퍼바이저다. 메모리에 있는 데이터를 보호하는 것은 좋다. CPU 내부의 데이터를 보호하는 것은 매우 좋은 일이며, VMware는 SEV-ES의 완벽한 보호가 고객이 지원해야 할 일이라고 생각한다.
고려 사항
보안은 가용성, 성능, 비용, 기회 비용 또는 요인의 조합에 관계없이 항상 절충된다. 나는 “고려사항”이라고 부르기를 좋아한다. 왜냐하면 그것들은 설계점이며 반드시 나쁘다고는 할 수 없기 때문이다. 단지 위험 내성, 규정 준수 및 규제 필요성에 대항하여 거래되어야 할 사항들이다.
첫째, 그리고 가장 분명한 것은 이러한 기술을 사용하기 위해서는 AMD EPYX 7xx2 이상의 CPU가 필요하다.
두 번째, 그리고 어느 정도 예상할 수 있는 것은 SEV-ES를 지원하는 게스트 OS가 필요하다.
이 글을 쓰면서 본래의 지원은 특히 리눅스 배포판과 커널에서 찾아볼 수 있다. 고객 피드백은 매우 강력하며, 게스트 OS 벤더가 AMD CPU와 SEV-ES와 같은 고급 플랫폼 보안 기능을 완벽하게 지원할 계획인 경우 해당 벤더에게 문의하기 바란다.
하이퍼바이저가 보호된 VM의 메모리에 액세스할 수 없다는 점도 고려해야 할 사항이다. 이 경우 하이퍼바이저는 vMotion, 메모리 스냅샷, 디바이스 핫 추가, 일시 중단 및 재개, Fault Tolerance, 핫 클론 등과 같은 특정 작업을 수행할 수 있는 기능을 상실하게 된다. vMotion과 같은 이러한 기능 중 일부는 사용자 환경의 운영에 중요할 수 있다. 또한 애플리케이션 설계가 우수하면 애플리케이션이나 서비스가 호스트를 다시 시작해야 하는 유지 보수 작업에 탄력적일 수 있기 때문에 그렇지 않을 수 있다. 또한 쿠베르네츠 기반의 최신 애플리케이션에는 vMotion이 필요하지 않을 수 있다. Tanzu가 장착된 vSphere는 Kubernetes 워크로드를 vMotion하지 않는다. 그것은 그것들을 새로운 호스트에서 다시 시작하고 유지 보수 모드로 들어가는 호스트에서 복사본을 종료한다. 따라서 이러한 애플리케이션과 무관하게 vMotion을 사용할 수 없으므로 필요 없었던 것을 놓치지 마십시오!
이점
AMD가 SEV-ES를 설계한 방식에는 상당한 위상이 있다.
첫째, 지원되는 게스트 OS에서 실행되는 워크로드는 애플리케이션 자체를 수정하지 않고도 이러한 심층적인 보호 기능을 확보한다. 이는 상용 애플리케이션 공급업체가 이 기술을 지원하기 위해 애플리케이션을 다시 컴파일할 때까지 기다릴 필요가 없다는 것을 의미한다.
둘째, 이 기술은 단일 호스트에서도 전부가 아니거나 전부가 아니다. 특정 작업 부하에 대해 활성화할 수 있고, 다른 작업 부하에 대해 비활성화된 상태로 둘 수 있으며, 모두 평화롭게 공존할 수 있다. 이러한 유연성은 이 기술을 구현하고 구현할 수 있다는 것을 의미한다. 마지막으로 PowerCLI cmdlet을 사용하여 1개 또는 1만 개의 VM에 대해 이 기능을 쉽게 사용하도록 설정한다.
AMD는 이러한 기능을 설계한 방법에 대해 소비자에게 상당한 사려 깊음을 보여 주었으며, vSphere 내부에서 보안을 매우 쉽게 사용할 수 있도록 하기 위한 당사의 작업과 그들의 이상이 잘 맞아떨어진다. 보안 툴박스에 이러한 유형의 툴이 포함되어 위험을 줄이는 데 도움이 되는 것은 언제나 좋은 일이며, VMware는 이러한 툴을 옹호하는 데 있어 업계를 선도하는 것을 자랑스럽게 여긴다.
