[번역] vSphere 7 – vSGX & Secure Enclaves

출처 : https://blogs.vmware.com/vsphere/2020/04/vsphere-7-vsgx-secure-enclaves.html

가상화는 IT의 다른 문제를 해결하는 데 도움이 되는 소프트웨어 계층을 추가하는 상당히 혁신적인 아이디어 입니다. 그러나 위험의 관점에서 보면 추적할 것이 더 많다. 그렇다고 해서 ESXi가 불안정하다는 것은 아니다. 전혀 그렇지 않다. ESXi는 가장 안전한 하이퍼바이저(예를 들어 Common Criteria 인증은 문제 수정 및 공개에 대한 탁월한 기록과 함께 이를 입증하는 데 도움이 된다). VMware는 고객의 안전을 보장하기 때문에 리스크에 대해 솔직하다. 애플리케이션이 암호키나 개인 식별 정보(PII)와 같은 비밀을 가지고 있을 때, 우리는 그 비밀이 많은 계층에서 볼 수 있다는 점을 지적해야 한다. 첫째, 시스템 메모리와 CPU에 저장된다. 둘째, 하이퍼바이저가 그것을 볼 수 있다. 셋째, 게스트 OS에서 볼 수 있다. 그리고 마지막은 당연히 애플리케이션이다.

Intel-SGX.png

게스트 OS와 하이퍼바이저를 위험 방정식에서 제거할 수 있는 방법이 있다면 어떻게 하시겠습니까? 이것이 인텔의 Software Guard Extensions(SGX)이 하기 위해 노력하는 것이다. SGX는 애플리케이션이 CPU와 "협치(conspire)"하여 게스트 OS와 하이퍼바이저의 비밀을 지킬 수 있도록 하여 리스크를 줄인다. 일부 애플리케이션은 이 기능을 탐색하기 시작했으며 vSphere 7에서는 가상 하드웨어 버전 17을 실행하는 VM에 이 기능을 노출했다. 우리는 이것을 "vSGX"라고 부른다.

SGX 기능이 있는 하드웨어에서 vSphere 7을 실행하는 경우 vSGX를 VM 하드웨어 구성의 일부로 사용하도록 설정할 수 있다:

New-VM-with-vSGX-Zoom-1536x883.png

좋지, 그렇지? 이것은 매우 흥미로운 개념인데, 하드웨어를 사용하여 비밀을 지키는 것을 돕는다. 하지만, 현명한 사람은 공짜 점심 같은 것은 없다고 말한 적이 있다. 항상 함정이 있다. 이 경우에는 몇 가지 있다.

SGX-Restrictions-Zoom.png

첫째, SGX를 지원하는 CPU가 필요하다. Intel CPU일 것이다. AMD는 SEV(Secure Encrypted Virtualization)라는 다른 접근 방식을 가지고 있다. 이 글을 쓰는 시점에 SGX를 지원하는 인텔 서버급 CPU는 많지 않으며, 모두 단일 소켓이다.

둘째, 몇 가지 운영상의 고려사항이 있다. 하이퍼바이저에서 기밀을 유지하면 하이퍼바이저가 vMotion을 사용할 수 없게 된다. 또는 Fault Tolerance, 하이퍼바이저가 메모리를 디스크에 복사할 수 없기 때문에 스냅샷을 일시 중단 및 재개하거나 생성할 수도 없다. 일부 Carbon Black Workload 게스트 무결성 검사도 작동하지 않는다.

이러한 것들 없이 살 수 있다고 생각할 수도 있지만 vMotion을 사용할 수 없다면 환경을 어떻게 패치하시겠습니까? DRS는 어떤가? 이것들은 당신이 자신을 부정하는 근본적인 것이다. SGX는 우리가 보안을 추가할 수 있도록 도와주지만, 보안은 단지 하나의 기능 이상이다. 정보보안 전문가들은 CIA의 3중대, 즉 기밀성, 무결성, 가용성의 관점에서 보안에 대해 생각한다. SGX는 기밀성을 높일 수 있지만, 응용프로그램이 제대로 설계되지 않은 경우 무결성과 가용성을 희생하여 이를 수행할 수 있다.

하드웨어 지원 보안 영역은 매우 흥미롭고 CPU 하드웨어가 우리를 도울 수 있는 것에 관한 한 빙산의 일각에 불과하다. 그러나 IT의 많은 상황과 마찬가지로 인프라와 애플리케이션 간의 협업은 IT의 사용이 최선이다.