Cada vez son máis os usuarios que levan toda a súa infraestrutura de TI á nube pública. Non obstante, se o control antivirus é insuficiente na infraestrutura do cliente, xorden serios riscos cibernéticos. A práctica demostra que ata o 80% dos virus existentes viven perfectamente nun ambiente virtual. Neste post falaremos sobre como protexer os recursos informáticos na nube pública e por que os antivirus tradicionais non son totalmente axeitados para estes fins.
Para comezar, contarémosche como chegamos á idea de que as ferramentas habituais de protección antivirus non son adecuadas para a nube pública e que son necesarios outros enfoques para protexer os recursos.
En primeiro lugar, os provedores xeralmente proporcionan as medidas necesarias para garantir que as súas plataformas na nube estean protexidas a un alto nivel. Por exemplo, en #CloudMTS analizamos todo o tráfico da rede, supervisamos os rexistros dos sistemas de seguridade da nosa nube e realizamos con regularidade pentests. Os segmentos de nube asignados a clientes individuais tamén deben estar protexidos de forma segura.
En segundo lugar, a opción clásica para combater os riscos cibernéticos pasa por instalar un antivirus e ferramentas de xestión antivirus en cada máquina virtual. Non obstante, cunha gran cantidade de máquinas virtuais, esta práctica pode ser ineficaz e requirir cantidades significativas de recursos informáticos, cargando así aínda máis a infraestrutura do cliente e reducindo o rendemento xeral da nube. Isto converteuse nun requisito previo clave para buscar novos enfoques para crear unha protección antivirus eficaz para as máquinas virtuais dos clientes.
Ademais, a maioría das solucións antivirus do mercado non están adaptadas para resolver os problemas de protección dos recursos informáticos nun entorno de nube pública. Por regra xeral, son solucións EPP de peso pesado (Endpoint Protection Platforms), que, ademais, non proporcionan a personalización necesaria no lado do cliente do provedor de nube.
Faise obvio que as solucións antivirus tradicionais non son axeitadas para traballar na nube, xa que cargan seriamente a infraestrutura virtual durante as actualizacións e as exploracións, e tampouco teñen os niveis necesarios de xestión e configuración baseadas en roles. A continuación, analizaremos en detalle por que a nube necesita novos enfoques para a protección antivirus.
O que debería ser capaz de facer un antivirus nunha nube pública
Entón, prestemos atención ás características específicas de traballar nun ambiente virtual:
Eficiencia das actualizacións e exploracións masivas programadas. Se un número significativo de máquinas virtuais que usan un antivirus tradicional inician unha actualización ao mesmo tempo, producirase unha "tormenta" de actualizacións na nube. É posible que a potencia dun host ESXi que aloxa varias máquinas virtuais non sexa suficiente para xestionar o aluvión de tarefas similares que se executan por defecto. Desde o punto de vista do provedor de nube, tal problema pode levar a cargas adicionais en varios hosts ESXi, o que finalmente levará a unha caída no rendemento da infraestrutura virtual na nube. Isto pode, entre outras cousas, afectar o rendemento das máquinas virtuais doutros clientes na nube. Unha situación similar pode xurdir ao iniciar unha exploración masiva: o procesamento simultáneo polo sistema de discos de moitas solicitudes similares de diferentes usuarios afectará negativamente ao rendemento de toda a nube. Cun alto grao de probabilidade, unha diminución do rendemento do sistema de almacenamento afectará a todos os clientes. Cargas tan abruptas non agradan nin ao provedor nin aos seus clientes, xa que afectan aos "veciños" da nube. Desde este punto de vista, o antivirus tradicional pode supoñer un gran problema.
Corentena segura. Se se detecta no sistema un ficheiro ou documento potencialmente infectado cun virus, envíase a corentena. Por suposto, un ficheiro infectado pódese eliminar inmediatamente, pero isto moitas veces non é aceptable para a maioría das empresas. Os antivirus corporativos que non están adaptados para funcionar na nube do provedor teñen, por regra xeral, unha zona de corentena común: todos os obxectos infectados caen nela. Por exemplo, os que se atopan nos ordenadores dos usuarios da empresa. Os clientes do provedor de nube "viven" nos seus propios segmentos (ou inquilinos). Estes segmentos son opacos e illados: os clientes non se coñecen uns dos outros e, por suposto, non ven o que os demais están aloxando na nube. Obviamente, a corentena xeral, á que accederán todos os usuarios de antivirus na nube, podería incluír un documento que conteña información confidencial ou un segredo comercial. Isto é inaceptable para o provedor e os seus clientes. Polo tanto, só pode haber unha solución: a corentena persoal para cada cliente do seu segmento, onde nin o provedor nin outros clientes teñen acceso.
Políticas de seguridade individuais. Cada cliente da nube é unha empresa separada, cuxo departamento de TI establece as súas propias políticas de seguridade. Por exemplo, os administradores definen regras de dixitalización e programan análises antivirus. En consecuencia, cada organización debe ter o seu propio centro de control para configurar as políticas antivirus. Ao mesmo tempo, a configuración especificada non debería afectar a outros clientes na nube e o provedor debería poder verificar que, por exemplo, as actualizacións de antivirus se realizan normalmente para todas as máquinas virtuais do cliente.
Organización da facturación e licenzas. O modelo de nube caracterízase pola flexibilidade e implica pagar só pola cantidade de recursos informáticos que utilizou o cliente. Se hai unha necesidade, por exemplo, debido á estacionalidade, entón a cantidade de recursos pódese aumentar ou reducir rapidamente, todo en función das necesidades actuais de potencia informática. O antivirus tradicional non é tan flexible: por regra xeral, o cliente compra unha licenza durante un ano para un número predeterminado de servidores ou estacións de traballo. Os usuarios da nube desconectan e conectan regularmente máquinas virtuais adicionais dependendo das súas necesidades actuais; polo tanto, as licenzas antivirus deben admitir o mesmo modelo.
A segunda pregunta é o que cubrirá exactamente a licenza. O antivirus tradicional ten licenza polo número de servidores ou estacións de traballo. As licenzas baseadas no número de máquinas virtuais protexidas non son totalmente adecuadas dentro do modelo de nube. O cliente pode crear calquera número de máquinas virtuais conveniente para el a partir dos recursos dispoñibles, por exemplo, cinco ou dez máquinas. Este número non é constante para a maioría dos clientes; non é posible para nós, como provedor, rastrexar os seus cambios. Non hai ningunha posibilidade técnica de licenciar por CPU: os clientes reciben procesadores virtuais (vCPU), que deben usarse para a licenza. Así, o novo modelo de protección antivirus debería incluír a posibilidade de que o cliente determine o número necesario de vCPU para as que recibirá licenzas antivirus.
Cumprimento da lexislación. Un punto importante, xa que as solucións utilizadas deben garantir o cumprimento dos requisitos do regulador. Por exemplo, os "residentes" na nube adoitan traballar con datos persoais. Neste caso, o provedor debe ter un segmento de nube certificado separado que cumpra totalmente cos requisitos da Lei de datos persoais. Entón, as empresas non precisan "construír" de forma independente todo o sistema para traballar con datos persoais: comprar equipos certificados, conectarse e configuralos e someterse á certificación. Para a protección cibernética do ISPD destes clientes, o antivirus tamén debe cumprir cos requisitos da lexislación rusa e ter un certificado FSTEC.
Analizamos os criterios obrigatorios que debe cumprir a protección antivirus na nube pública. A continuación, compartiremos a nosa propia experiencia na adaptación dunha solución antivirus para que funcione na nube do provedor.
Como facer amigos entre o antivirus e a nube?
Como demostrou a nosa experiencia, escoller unha solución baseada na descrición e na documentación é unha cousa, pero implementala na práctica nun contorno de nube que xa funciona é unha tarefa completamente diferente en canto á complexidade. Contarémosche o que fixemos na práctica e como adaptamos o antivirus para que funcionara na nube pública do provedor. O provedor da solución antivirus foi Kaspersky, cuxa carteira inclúe solucións de protección antivirus para ambientes na nube. Fixémonos en "Kaspersky Security for Virtualization" (axente de luz).
Inclúe unha única consola de Kaspersky Security Center. Axente de luz e máquinas virtuais de seguridade (SVM, Security Virtual Machine) e servidor de integración KSC.
Despois de estudar a arquitectura da solución de Kaspersky e realizar as primeiras probas xunto cos enxeñeiros do provedor, xurdiu a pregunta sobre a integración do servizo na nube. A primeira implementación levouse a cabo conxuntamente no sitio nube de Moscova. E diso nos demos conta.
Para minimizar o tráfico de rede, decidiuse colocar un SVM en cada host ESXi e "vincular" o SVM aos hosts ESXi. Neste caso, os axentes lixeiros das máquinas virtuais protexidas acceden ao SVM do host ESXi exacto no que se están a executar. Seleccionouse un inquilino administrativo separado para o KSC principal. Como resultado, os KSC subordinados están situados nos inquilinos de cada cliente individual e diríxense ao KSC superior situado no segmento de xestión. Este esquema permítelle resolver rapidamente os problemas que xorden nos clientes inquilinos.
Ademais dos problemas relacionados co aumento dos compoñentes da propia solución antivirus, enfrontámonos á tarefa de organizar a interacción da rede mediante a creación de VxLAN adicionais. E aínda que orixinalmente a solución estaba pensada para clientes empresariais con nubes privadas, coa axuda dos expertos en enxeñaría e da flexibilidade tecnolóxica de NSX Edge puidemos resolver todos os problemas asociados á separación dos inquilinos e a licenza.
Traballamos en estreita colaboración cos enxeñeiros de Kaspersky. Así, no proceso de análise da arquitectura da solución en termos de interacción de rede entre os compoñentes do sistema, comprobouse que, ademais do acceso dos axentes lixeiros a SVM, tamén é necesaria a retroalimentación: desde SVM aos axentes lixeiros. Esta conectividade de rede non é posible nun ambiente de varios arrendatarios debido á posibilidade de que as máquinas virtuais teñan unha configuración de rede idéntica en diferentes arrendatarios da nube. Polo tanto, a nosa solicitude, os compañeiros do provedor reelaboraron o mecanismo de interacción de rede entre o axente de luz e SVM en termos de eliminar a necesidade de conectividade de rede de SVM aos axentes lixeiros.
Despois de que a solución fose implantada e probada no sitio na nube de Moscova, replicámola noutros sitios, incluído o segmento de nube certificado. O servizo xa está dispoñible en todas as rexións do país.
Arquitectura dunha solución de seguridade da información no marco dun novo enfoque
O esquema xeral de funcionamento dunha solución antivirus nun ambiente de nube pública é o seguinte:
Esquema de funcionamento dunha solución antivirus nun entorno de nube pública #CloudMTS
Imos describir as características do funcionamento dos elementos individuais da solución na nube:
• Unha única consola que permite aos clientes xestionar de forma centralizada o sistema de protección: realizar exploracións, controlar actualizacións e supervisar as zonas de corentena. É posible configurar políticas de seguridade individuais dentro do seu segmento.
Cómpre ter en conta que aínda que somos un provedor de servizos, non interferimos coa configuración establecida polos clientes. O único que podemos facer é restablecer as políticas de seguridade ás estándar se é necesaria a reconfiguración. Por exemplo, isto pode ser necesario se o cliente os tentou accidentalmente ou os debilitou significativamente. Unha empresa sempre pode recibir un centro de control con políticas predeterminadas, que despois pode configurar de forma independente. A desvantaxe de Kaspersky Security Center é que actualmente a plataforma só está dispoñible para o sistema operativo Microsoft. Aínda que os axentes lixeiros poden traballar tanto con máquinas Windows como con Linux. Non obstante, Kaspersky Lab promete que nun futuro próximo KSC funcionará baixo o sistema operativo Linux. Unha das funcións importantes de KSC é a capacidade de xestionar a corentena. Cada empresa cliente da nosa nube ten unha persoal. Este enfoque elimina as situacións nas que un documento infectado cun virus se fai visible de forma accidental publicamente, como podería ocorrer no caso dun antivirus corporativo clásico con corentena xeral.
• Axentes luminosos. Como parte do novo modelo, instálase un axente lixeiro de Kaspersky Security en cada máquina virtual. Isto elimina a necesidade de almacenar a base de datos antivirus en cada máquina virtual, o que reduce a cantidade de espazo en disco necesario. O servizo está integrado coa infraestrutura da nube e funciona a través de SVM, o que aumenta a densidade de máquinas virtuais no host ESXi e o rendemento de todo o sistema de nube. O axente lixeiro constrúe unha cola de tarefas para cada máquina virtual: comprobar o sistema de ficheiros, a memoria, etc. Pero a SVM encárgase de realizar estas operacións, das que falaremos máis adiante. O axente tamén funciona como un firewall, controla as políticas de seguridade, envía ficheiros infectados á corentena e supervisa a "saúde" global do sistema operativo no que está instalado. Todo isto pódese xestionar mediante a xa mencionada consola única.
• Máquina Virtual de Seguridade. Todas as tarefas de uso intensivo de recursos (actualizacións de bases de datos antivirus, análises programadas) son xestionadas por unha máquina virtual de seguranza (SVM) separada. É responsable do funcionamento dun motor antivirus completo e das bases de datos para el. A infraestrutura de TI dunha empresa pode incluír varias SVM. Este enfoque aumenta a fiabilidade do sistema: se unha máquina falla e non responde durante trinta segundos, os axentes comezan a buscar outra automaticamente.
• Servidor de integración KSC. Un dos compoñentes do KSC principal, que asigna os seus SVM aos axentes lixeiros segundo o algoritmo especificado na súa configuración, e tamén controla a dispoñibilidade de SVM. Así, este módulo de software proporciona equilibrio de carga en todas as SVM da infraestrutura na nube.
Algoritmo para traballar na nube: reducindo a carga da infraestrutura
En xeral, o algoritmo antivirus pódese representar do seguinte xeito. O axente accede ao ficheiro na máquina virtual e compróbao. O resultado da verificación gárdase nunha base de datos de veredictos SVM centralizada común (chamada Caché compartida), cada entrada na que se identifica unha mostra de ficheiro único. Este enfoque permítelle garantir que o mesmo ficheiro non se escanee varias veces seguidas (por exemplo, se se abriu en diferentes máquinas virtuais). O ficheiro só se analiza de novo se se realizaron cambios ou se iniciou manualmente a exploración.
Implantación dunha solución antivirus na nube do provedor
A imaxe mostra un diagrama xeral da implementación da solución na nube. O Kaspersky Security Center principal está implantado na zona de control da nube e un SVM individual está implantado en cada host ESXi mediante o servidor de integración KSC (cada host ESXi ten o seu propio SVM conectado con configuracións especiais en VMware vCenter Server). Os clientes traballan nos seus propios segmentos de nube, onde se atopan máquinas virtuais con axentes. Xestionanse a través de servidores KSC individuais subordinados ao KSC principal. Se é necesario protexer un número reducido de máquinas virtuais (ata 5), o cliente pode ter acceso á consola virtual dun servidor KSC especial dedicado. A interacción de rede entre os KSC do cliente e o KSC principal, así como os axentes lixeiros e os SVM, realízase mediante NAT a través dos enrutadores virtuais do cliente EdgeGW.
Segundo as nosas estimacións e os resultados das probas dos compañeiros do vendedor, Light Agent reduce a carga da infraestrutura virtual dos clientes en aproximadamente un 25% (en comparación cun sistema que usa software antivirus tradicional). En particular, o antivirus estándar Kaspersky Endpoint Security (KES) para ambientes físicos consome case o dobre de tempo de CPU do servidor (2,95%) que unha solución de virtualización lixeira baseada en axentes (1,67%).
Gráfico comparativo de carga de CPU
Obsérvase unha situación similar coa frecuencia dos accesos de escritura ao disco: para un antivirus clásico é de 1011 IOPS, para un antivirus na nube é de 671 IOPS.
Gráfico comparativo da taxa de acceso ao disco
O beneficio de rendemento permítelle manter a estabilidade da infraestrutura e utilizar a potencia de cómputo de forma máis eficiente. Ao adaptarse para traballar nun ambiente de nube pública, a solución non reduce o rendemento da nube: verifica de forma centralizada os ficheiros e descarga as actualizacións, distribuíndo a carga. Isto significa que, por unha banda, non se perderán as ameazas relevantes para a infraestrutura da nube, por outra banda, os requisitos de recursos para as máquinas virtuais reduciranse nunha media dun 25% en comparación cun antivirus tradicional.
En canto á funcionalidade, ambas solucións son moi similares entre si: a continuación móstrase unha táboa comparativa. Non obstante, na nube, como mostran os resultados das probas anteriores, aínda é óptimo utilizar unha solución para contornas virtuais.
Sobre as tarifas no marco do novo enfoque. Decidimos utilizar un modelo que nos permita obter licenzas en función do número de vCPU. Isto significa que o número de licenzas será igual ao número de vCPU. Podes probar o teu antivirus deixando unha solicitude .
No seguinte artigo sobre temas de nube, falaremos da evolución dos WAF na nube e do que é mellor escoller: hardware, software ou nube.
O texto foi preparado por empregados do provedor de nube #CloudMTS: Denis Myagkov, arquitecto líder e Alexey Afanasyev, xestor de desenvolvemento de produtos de seguridade da información.
Fonte: www.habr.com