기존 바이러스 백신이 퍼블릭 클라우드에 적합하지 않은 이유 그래서 내가 무엇을해야하니?

점점 더 많은 사용자가 전체 IT 인프라를 퍼블릭 클라우드로 전환하고 있습니다. 그러나 고객의 인프라에 대한 안티 바이러스 제어가 충분하지 않으면 심각한 사이버 위험이 발생합니다. 실습에 따르면 기존 바이러스의 최대 80%가 가상 환경에서 완벽하게 살고 있습니다. 이 게시물에서는 퍼블릭 클라우드에서 IT 리소스를 보호하는 방법과 기존 바이러스 백신이 이러한 목적에 적합하지 않은 이유에 대해 설명합니다.

우선, 일반적인 바이러스 백신 보호 도구가 퍼블릭 클라우드에 적합하지 않으며 리소스를 보호하기 위한 다른 접근 방식이 필요하다는 생각을 어떻게 갖게 되었는지 알려 드리겠습니다.

첫째, 공급자는 일반적으로 클라우드 플랫폼이 높은 수준으로 보호되도록 하는 데 필요한 조치를 제공합니다. 예를 들어 #CloudMTS에서는 모든 네트워크 트래픽을 분석하고 클라우드 보안 시스템의 로그를 모니터링하며 정기적으로 침투 테스트를 수행합니다. 개별 클라이언트에 할당된 클라우드 세그먼트도 안전하게 보호되어야 합니다.

둘째, 사이버 위험에 대처하기 위한 일반적인 옵션에는 각 가상 머신에 바이러스 백신 및 바이러스 백신 관리 도구를 설치하는 것이 포함됩니다. 그러나 가상 머신 수가 많은 경우 이 방법은 비효율적일 수 있으며 상당한 양의 컴퓨팅 리소스가 필요하므로 고객의 인프라에 추가 부하가 걸리고 클라우드의 전반적인 성능이 저하될 수 있습니다. 이는 고객 가상 머신에 대한 효과적인 안티 바이러스 보호를 구축하기 위한 새로운 접근 방식을 찾기 위한 핵심 전제 조건이 되었습니다.

또한 시중에 나와 있는 대부분의 바이러스 백신 솔루션은 퍼블릭 클라우드 환경에서 IT 리소스를 보호하는 문제를 해결하는 데 적합하지 않습니다. 일반적으로 이는 무거운 EPP 솔루션(엔드포인트 보호 플랫폼)이며, 클라우드 공급자의 클라이언트 측에 필요한 사용자 정의를 제공하지 않습니다.

기존 바이러스 백신 솔루션은 업데이트 및 검사 중에 가상 인프라를 심각하게 로드하고 필요한 수준의 역할 기반 관리 및 설정이 없기 때문에 클라우드 작업에 적합하지 않다는 것이 분명해졌습니다. 다음으로 클라우드에 안티 바이러스 보호에 대한 새로운 접근 방식이 필요한 이유를 자세히 분석하겠습니다.

퍼블릭 클라우드의 바이러스 백신이 수행할 수 있는 작업

이제 가상 환경에서 작업하는 구체적인 사항에 주목해 보겠습니다.

업데이트 및 예약된 대량 검사의 효율성. 기존 바이러스 백신을 사용하는 상당수의 가상 머신이 동시에 업데이트를 시작하면 소위 업데이트의 "폭풍"이 클라우드에서 발생합니다. 여러 가상 시스템을 호스팅하는 ESXi 호스트의 성능은 기본적으로 실행되는 유사한 작업의 공세를 처리하기에 충분하지 않을 수 있습니다. 클라우드 제공자의 입장에서 이러한 문제는 다수의 ESXi 호스트에 추가적인 부하를 발생시킬 수 있으며, 이는 결국 클라우드 가상 인프라의 성능 저하로 이어질 수 있습니다. 이는 무엇보다도 다른 클라우드 클라이언트의 가상 머신 성능에 영향을 미칠 수 있습니다. 대량 스캔을 시작할 때 유사한 상황이 발생할 수 있습니다. 디스크 시스템에서 여러 사용자의 유사한 요청을 동시에 처리하면 전체 클라우드 성능에 부정적인 영향을 미칩니다. 높은 확률로 스토리지 시스템 성능 저하가 모든 클라이언트에 영향을 미칩니다. 이러한 갑작스러운 로드는 클라우드의 "이웃"에 영향을 미치기 때문에 공급자나 고객 모두를 만족시키지 못합니다. 이러한 관점에서 기존의 바이러스 백신은 큰 문제를 일으킬 수 있습니다.

안전한 격리. 바이러스에 감염되었을 가능성이 있는 파일이나 문서가 시스템에서 탐지되면 검역소로 보내집니다. 물론 감염된 파일은 즉시 삭제할 수 있지만 대부분의 회사에서는 이를 허용하지 않는 경우가 많습니다. 일반적으로 공급자의 클라우드에서 작동하도록 조정되지 않은 기업용 바이러스 백신에는 공통 격리 영역이 있으며 감염된 모든 개체가 여기에 속합니다. 예를 들어, 회사 사용자의 컴퓨터에서 발견된 것입니다. 클라우드 공급자의 클라이언트는 자체 세그먼트(또는 테넌트)에 "실시간"으로 존재합니다. 이러한 세그먼트는 불투명하고 격리되어 있습니다. 클라이언트는 서로에 대해 알지 못하며, 물론 다른 사람이 클라우드에서 호스팅하는 것을 볼 수도 없습니다. 분명히 클라우드의 모든 바이러스 백신 사용자가 액세스할 일반 격리에는 기밀 정보나 영업 비밀이 포함된 문서가 포함될 수 있습니다. 이는 공급자와 고객에게 용납될 수 없는 일입니다. 따라서 공급자나 다른 클라이언트 모두 액세스할 수 없는 해당 세그먼트의 각 클라이언트에 대한 개인 격리라는 하나의 솔루션만 있을 수 있습니다.

개별 보안 정책. 클라우드의 각 클라이언트는 IT 부서가 자체 보안 정책을 설정하는 별도의 회사입니다. 예를 들어 관리자는 검색 규칙을 정의하고 안티 바이러스 검색을 예약합니다. 따라서 각 조직에는 바이러스 백신 정책을 구성하기 위한 자체 제어 센터가 있어야 합니다. 동시에 구성된 설정은 다른 클라우드 클라이언트에 영향을 주어서는 안 되며, 공급자는 예를 들어 바이러스 백신 업데이트가 모든 클라이언트 가상 머신에 대해 정상적으로 수행되는지 확인할 수 있어야 합니다.

청구 및 라이센스 구성. 클라우드 모델은 유연성이 특징이며 고객이 사용한 IT 리소스의 양에 대해서만 비용을 지불합니다. 예를 들어 계절적 요인으로 인해 필요한 경우 리소스 양을 빠르게 늘리거나 줄일 수 있습니다. 이는 모두 현재 컴퓨팅 성능 요구 사항에 따라 결정됩니다. 기존 바이러스 백신은 그다지 유연하지 않습니다. 일반적으로 클라이언트는 미리 결정된 수의 서버 또는 워크스테이션에 대해 XNUMX년 동안 라이센스를 구입합니다. 클라우드 사용자는 현재 필요에 따라 정기적으로 추가 가상 머신의 연결을 끊고 연결합니다. 따라서 바이러스 백신 라이센스는 동일한 모델을 지원해야 합니다.

두 번째 질문은 라이센스가 정확히 무엇을 다루는가입니다. 기존의 바이러스 백신은 서버 또는 워크스테이션 수에 따라 라이선스가 부여됩니다. 보호되는 가상 머신 수를 기반으로 하는 라이센스는 클라우드 모델 내에서 완전히 적합하지 않습니다. 클라이언트는 사용 가능한 리소스(예: XNUMX개 또는 XNUMX개)에서 자신에게 편리한 가상 머신을 원하는 수만큼 생성할 수 있습니다. 이 숫자는 대부분의 고객에게 일정하지 않으므로 공급자로서 당사가 변경 사항을 추적하는 것은 불가능합니다. CPU별로 라이선스를 부여하는 기술적인 가능성은 없습니다. 클라이언트는 라이선스에 사용해야 하는 가상 프로세서(vCPU)를 받습니다. 따라서 새로운 안티바이러스 보호 모델에는 고객이 안티바이러스 라이센스를 받는 데 필요한 vCPU 수를 결정할 수 있는 기능이 포함되어야 합니다.

법률 준수. 사용되는 솔루션은 규제 기관의 요구 사항을 준수해야 하기 때문에 중요한 점입니다. 예를 들어 클라우드 "거주자"는 개인 데이터를 다루는 경우가 많습니다. 이 경우 공급자는 개인정보법의 요구 사항을 완전히 준수하는 별도의 인증된 클라우드 세그먼트를 보유해야 합니다. 그러면 기업은 개인 데이터 작업을 위해 전체 시스템을 독립적으로 "구축"할 필요가 없습니다. 즉, 인증된 장비를 구매하고 연결 및 구성한 후 인증을 받을 필요가 없습니다. 해당 클라이언트의 ISPD 사이버 보호를 위해 바이러스 백신은 러시아 법률 요구 사항을 준수하고 FSTEC 인증서를 보유해야 합니다.

퍼블릭 클라우드에서 바이러스 백신 보호가 충족해야 하는 필수 기준을 살펴보았습니다. 다음으로, 공급자의 클라우드에서 작동하도록 바이러스 백신 솔루션을 적용한 경험을 공유하겠습니다.

바이러스 백신과 클라우드를 어떻게 친구로 만들 수 있습니까?

우리의 경험에서 알 수 있듯이 설명과 문서를 기반으로 솔루션을 선택하는 것은 하나의 일이지만 이미 작동 중인 클라우드 환경에서 실제로 이를 구현하는 것은 복잡성 측면에서 완전히 다른 작업입니다. 실제로 우리가 수행한 작업과 공급자의 공용 클라우드에서 작동하도록 바이러스 백신을 어떻게 적용했는지 알려 드리겠습니다. 안티 바이러스 솔루션 공급업체는 Kaspersky였으며 이 회사의 포트폴리오에는 클라우드 환경을 위한 안티 바이러스 보호 솔루션이 포함되어 있습니다. 우리는 "Kaspersky Security for Virtualization"(라이트 에이전트)을 선택했습니다.

여기에는 단일 Kaspersky Security Center 콘솔이 포함됩니다. 라이트 에이전트 및 보안 가상 머신(SVM, Security Virtual Machine) 및 KSC 통합 서버입니다.

Kaspersky 솔루션의 아키텍처를 연구하고 공급업체의 엔지니어와 함께 첫 번째 테스트를 수행한 후 서비스를 클라우드에 통합하는 것에 대한 의문이 생겼습니다. 첫 번째 구현은 모스크바 클라우드 사이트에서 공동으로 수행되었습니다. 그리고 그것이 우리가 깨달은 것입니다.

네트워크 트래픽을 최소화하기 위해 각 ESXi 호스트에 SVM을 배치하고 SVM을 ESXi 호스트에 "연결"하기로 결정했습니다. 이 경우 보호된 가상 머신의 라이트 에이전트는 실행 중인 정확한 ESXi 호스트의 SVM에 액세스합니다. 주요 KSC에 대해 별도의 관리 테넌트가 선택되었습니다. 결과적으로 하위 KSC는 각 개별 고객의 테넌트에 위치하며 관리 부문에 위치한 상위 KSC를 주소로 지정합니다. 이 체계를 사용하면 클라이언트 테넌트에서 발생하는 문제를 신속하게 해결할 수 있습니다.

안티 바이러스 솔루션 자체의 구성 요소를 높이는 문제 외에도 추가 VxLAN 생성을 통해 네트워크 상호 작용을 구성하는 작업에 직면했습니다. 이 솔루션은 원래 프라이빗 클라우드를 사용하는 기업 고객을 대상으로 했지만 NSX Edge의 뛰어난 엔지니어링 지식과 기술적 유연성 덕분에 테넌트 및 라이센스 분리와 관련된 모든 문제를 해결할 수 있었습니다.

우리는 Kaspersky 엔지니어들과 긴밀히 협력했습니다. 따라서 시스템 구성 요소 간의 네트워크 상호 작용 측면에서 솔루션 아키텍처를 분석하는 과정에서 Light Agent에서 SVM으로의 액세스 외에도 SVM에서 Light Agent로의 피드백도 필요하다는 사실을 발견했습니다. 여러 클라우드 테넌트에 있는 가상 머신의 네트워크 설정이 동일할 가능성이 있으므로 다중 테넌트 환경에서는 이 네트워크 연결이 불가능합니다. 따라서 우리의 요청에 따라 공급업체의 동료들은 SVM에서 라이트 에이전트로의 네트워크 연결 필요성을 제거한다는 측면에서 라이트 에이전트와 SVM 간의 네트워크 상호 작용 메커니즘을 재작업했습니다.

모스크바 클라우드 사이트에 솔루션을 배포하고 테스트한 후 인증된 클라우드 세그먼트를 포함한 다른 사이트에 이를 복제했습니다. 이제 전국 모든 지역에서 서비스를 이용할 수 있습니다.

새로운 접근 방식의 프레임워크 내 정보 보안 솔루션 아키텍처

퍼블릭 클라우드 환경에서 안티바이러스 솔루션의 일반적인 운영 방식은 다음과 같습니다.

퍼블릭 클라우드 환경에서 바이러스 백신 솔루션 운영 방식 #CloudMTS

클라우드에서 솔루션의 개별 요소 작동 기능을 설명하겠습니다.

• 클라이언트가 보호 시스템을 중앙에서 관리할 수 있는 단일 콘솔: 검사 실행, 업데이트 제어, 격리 구역 모니터링. 세그먼트 내에서 개별 보안 정책을 구성할 수 있습니다.

당사는 서비스 제공자이지만 고객이 설정한 설정을 방해하지 않습니다. 우리가 할 수 있는 유일한 일은 재구성이 필요한 경우 보안 정책을 표준 정책으로 재설정하는 것입니다. 예를 들어, 고객이 실수로 나사를 조였거나 크게 약화시킨 경우에 필요할 수 있습니다. 회사는 항상 기본 정책이 포함된 제어 센터를 받을 수 있으며 이를 독립적으로 구성할 수 있습니다. Kaspersky Security Center의 단점은 플랫폼이 현재 Microsoft 운영 체제에서만 사용 가능하다는 것입니다. 경량 에이전트는 Windows 및 Linux 시스템 모두에서 작동할 수 있습니다. 그러나 Kaspersky Lab은 가까운 시일 내에 KSC가 Linux OS에서 작동할 것이라고 약속합니다. KSC의 중요한 기능 중 하나는 검역 관리 능력입니다. 클라우드의 각 고객 회사에는 개인 회사가 있습니다. 이 접근 방식은 일반적인 격리 기능을 갖춘 기존 기업 바이러스 백신의 경우에 발생할 수 있는 것처럼 바이러스에 감염된 문서가 실수로 공개적으로 표시되는 상황을 제거합니다.

• 라이트 에이전트. 새 모델의 일부로 경량 Kaspersky Security 에이전트가 각 가상 머신에 설치됩니다. 이렇게 하면 각 VM에 바이러스 백신 데이터베이스를 저장할 필요가 없으므로 소비되는 디스크 공간이 줄어듭니다. 이 서비스는 클라우드 인프라와 통합되며 SVM을 통해 작동하므로 ESXi 호스트의 가상 머신 밀도와 전체 클라우드 시스템의 성능이 향상됩니다. 라이트 에이전트는 각 가상 머신에 대한 작업 대기열을 구축합니다. 즉, 파일 시스템, 메모리 등을 확인합니다. 그러나 SVM은 이러한 작업을 수행하는 역할을 담당하며 이에 대해서는 나중에 설명하겠습니다. 또한 에이전트는 방화벽 역할을 하고, 보안 정책을 제어하고, 감염된 파일을 격리 장소로 보내고, 에이전트가 설치된 운영 체제의 전반적인 "상태"를 모니터링합니다. 이 모든 것은 이미 언급한 단일 콘솔을 사용하여 관리할 수 있습니다.

• 보안 가상 머신. 리소스를 많이 사용하는 모든 작업(바이러스 백신 데이터베이스 업데이트, 예약 검사)은 별도의 SVM(보안 가상 머신)에 의해 처리됩니다. 그녀는 본격적인 안티 바이러스 엔진과 데이터베이스의 운영을 담당하고 있습니다. 회사의 IT 인프라에는 여러 SVM이 포함될 수 있습니다. 이 접근 방식은 시스템의 신뢰성을 높입니다. 한 시스템이 실패하고 XNUMX초 동안 응답하지 않으면 에이전트는 자동으로 다른 시스템을 찾기 시작합니다.

• KSC 통합 서버. 설정에 지정된 알고리즘에 따라 라이트 에이전트에 SVM을 할당하고 SVM의 가용성도 제어하는 ​​기본 KSC의 구성 요소 중 하나입니다. 따라서 이 소프트웨어 모듈은 클라우드 인프라의 모든 SVM에 걸쳐 로드 밸런싱을 제공합니다.

클라우드 작업을 위한 알고리즘: 인프라 부하 감소

일반적으로 바이러스 백신 알고리즘은 다음과 같이 표현될 수 있다. 에이전트는 가상 머신의 파일에 액세스하여 확인합니다. 확인 결과는 공통 ​​중앙 집중식 SVM 판정 데이터베이스(공유 캐시라고 함)에 저장되며 각 항목은 고유한 파일 샘플을 식별합니다. 이 접근 방식을 사용하면 동일한 파일이 연속해서 여러 번 검사되지 않도록 할 수 있습니다(예: 다른 가상 머신에서 열린 경우). 파일이 변경되었거나 검사가 수동으로 시작된 경우에만 파일이 다시 검사됩니다.

공급자의 클라우드에 바이러스 백신 솔루션 구현

이미지는 클라우드에서의 솔루션 구현에 대한 일반적인 다이어그램을 보여줍니다. 기본 Kaspersky Security Center는 클라우드의 제어 영역에 배포되고 개별 SVM은 KSC 통합 서버를 사용하여 각 ESXi 호스트에 배포됩니다(각 ESXi 호스트에는 VMware vCenter Server의 특수 설정이 연결된 자체 SVM이 있습니다). 클라이언트는 에이전트가 있는 가상 머신이 있는 자체 클라우드 세그먼트에서 작업합니다. 이는 기본 KSC에 종속된 개별 KSC 서버를 통해 관리됩니다. 소수의 가상 머신(최대 5개)을 보호해야 하는 경우 클라이언트에 특수 전용 KSC 서버의 가상 콘솔에 대한 액세스 권한을 제공할 수 있습니다. 클라이언트 KSC와 기본 KSC, 라이트 에이전트와 SVM 간의 네트워크 상호 작용은 EdgeGW 클라이언트 가상 라우터를 통해 NAT를 사용하여 수행됩니다.

우리의 추정치와 공급업체 동료들의 테스트 결과에 따르면 Light Agent는 클라이언트의 가상 인프라에 대한 부하를 약 25% 줄입니다(기존 안티 바이러스 소프트웨어를 사용하는 시스템과 비교 시). 특히, 물리적 환경을 위한 표준 Kaspersky Endpoint Security(KES) 바이러스 백신은 경량 에이전트 기반 가상화 솔루션(2,95%)에 비해 거의 두 배에 달하는 서버 CPU 시간(1,67%)을 소비합니다.

CPU 부하 비교 차트

디스크 쓰기 액세스 빈도에서도 비슷한 상황이 관찰됩니다. 클래식 바이러스 백신의 경우 1011 IOPS이고 클라우드 바이러스 백신의 경우 671 IOPS입니다.

디스크 접근률 비교 그래프

성능상의 이점을 통해 인프라 안정성을 유지하고 컴퓨팅 성능을 보다 효율적으로 사용할 수 있습니다. 솔루션은 퍼블릭 클라우드 환경에 적응함으로써 클라우드 성능을 저하시키지 않습니다. 중앙에서 파일을 확인하고 업데이트를 다운로드하여 부하를 분산시킵니다. 이는 한편으로는 클라우드 인프라와 관련된 위협을 놓치지 않는 반면, 가상 머신에 대한 리소스 요구 사항은 기존 바이러스 백신에 비해 평균 25% 감소한다는 것을 의미합니다.

기능면에서 두 솔루션은 서로 매우 유사합니다. 아래는 비교표입니다. 그러나 클라우드에서는 위의 테스트 결과에서 볼 수 있듯이 여전히 가상 환경용 솔루션을 사용하는 것이 최적입니다.

새로운 접근 방식의 틀 내 관세에 대해. 우리는 vCPU 수에 따라 라이선스를 얻을 수 있는 모델을 사용하기로 결정했습니다. 즉, 라이선스 수가 vCPU 수와 동일하다는 의미입니다. 요청을 남겨 바이러스 백신을 테스트할 수 있습니다. 온라인으로.

클라우드 주제에 대한 다음 기사에서는 클라우드 WAF의 진화와 하드웨어, 소프트웨어 또는 클라우드 중에서 선택하는 것이 더 나은 것에 대해 설명합니다.

이 텍스트는 클라우드 제공업체 #CloudMTS의 직원인 수석 설계자 Denis Myagkov와 정보 보안 제품 개발 관리자인 Alexey Afanasyev가 작성했습니다.

출처 : habr.com