De plus en plus d'utilisateurs déplacent l'intégralité de leur infrastructure informatique vers le cloud public. Cependant, en cas de contrôle antivirus insuffisant dans l'infrastructure du client, de sérieux risques cybernétiques peuvent surgir. La pratique montre que jusqu'à 80 % des virus existants prospèrent très bien dans un environnement virtuel. Dans cet article, nous expliquerons comment protéger les ressources informatiques dans le cloud public et pourquoi les antivirus traditionnels ne sont pas tout à fait adaptés à ces objectifs.
Pour commencer, nous allons expliquer comment nous en sommes arrivés à la conclusion que les outils de protection antivirus habituels ne conviennent pas au cloud public et qu'il faut adopter d'autres approches pour protéger les ressources.
Tout d'abord, en règle générale, les fournisseurs mettent en place les mesures nécessaires pour garantir un haut niveau de protection de leurs plateformes cloud. Par exemple, chez #CloudMTS, nous analysons tout le trafic réseau, surveillons les journaux des systèmes de sécurité de notre cloud, et effectuons régulièrement des tests de pénétration. Les segments de cloud attribués à des clients spécifiques doivent également être protégés de manière fiable.
D'autre part, la méthode classique de lutte contre les risques cybernétiques implique l'installation d'antivirus et de moyens de gestion sur chaque machine virtuelle. Cependant, avec un grand nombre de machines virtuelles, cette pratique peut être inefficace et exiger d'importantes ressources informatiques, surchargeant ainsi l'infrastructure du client et réduisant la performance générale du cloud. Cela a constitué une motivation clé pour rechercher de nouvelles approches de mise en place d'une protection antivirus efficace pour les machines virtuelles des clients.
De plus, la plupart des solutions antivirus disponibles sur le marché ne sont pas adaptées pour protéger les ressources informatiques dans un environnement cloud public. En général, elles représentent des solutions EPP (Endpoint Protection Platforms) lourdes, qui n'offrent pas non plus la possibilité de personnalisation nécessaire du côté du client du fournisseur de cloud.
Il devient évident que les solutions antivirus traditionnelles ne sont pas bien adaptées au travail dans le cloud, car elles surchargeaient sérieusement l'infrastructure virtuelle pendant les mises à jour et les analyses, et ne disposent pas des niveaux nécessaires de gestion des rôles et des réglages. Nous examinerons ensuite en détail les raisons pour lesquelles le cloud a besoin de nouvelles approches en matière de protection antivirus.
Quelles sont les capacités essentielles d'un antivirus dans le cloud public
Examinons donc les particularités du fonctionnement dans un environnement virtuel :
Efficacité des mises à jour et des contrôles de masse programmés. Si un grand nombre de machines virtuelles utilisant un antivirus traditionnel initient une mise à jour en même temps, cela provoquera un soi-disant « orage » de mises à jour dans le cloud. Les capacités de l'hôte ESXi, sur lequel plusieurs machines virtuelles sont hébergées, peuvent ne pas suffire à traiter ce torrent de tâches identiques lancées par défaut. Du point de vue du fournisseur de cloud, ce type de problème peut entraîner une charge supplémentaire sur plusieurs hôtes ESXi, ce qui finit par dégrader la performance de l'infrastructure virtuelle du cloud. Cela peut également affecter la performance des machines virtuelles d'autres clients du cloud. Une situation similaire peut se produire lors du lancement d'un scan de masse : le traitement simultané par le système de stockage de nombreuses requêtes identiques de différents utilisateurs aura un impact négatif sur la performance de l'ensemble du cloud. Avec une forte probabilité, la réduction de la performance du système de stockage affectera tous les clients. De telles charges abruptes ne ravissent ni le fournisseur, ni ses clients, car elles influencent les « voisins » dans le cloud. Dans ce sens, un antivirus traditionnel peut représenter un problème majeur.
Quarantaine sécurisée. Si un fichier ou un document potentiellement infecté par un virus est détecté dans le système, il est envoyé en quarantaine. Bien sûr, le fichier infecté peut être supprimé immédiatement, mais cela est souvent inacceptable pour la plupart des entreprises. Les antivirus d'entreprise qui ne sont pas adaptés pour fonctionner dans le cloud d'un fournisseur ont généralement une zone de quarantaine commune – tous les objets infectés y sont regroupés. Par exemple, ceux détectés sur les ordinateurs des utilisateurs de l'entreprise. Les clients de ce fournisseur cloud « vivent » dans leurs propres segments (ou « tenants »). Ces segments sont opaques et isolés : les clients ne se connaissent pas et ne voient bien sûr pas ce que les autres mettent dans le cloud. Il est évident qu'un document contenant des informations confidentielles ou un secret commercial peut potentiellement se retrouver dans une quarantaine commune, à laquelle tous les utilisateurs de l'antivirus cloud ont accès. Cela est inacceptable tant pour le fournisseur que pour ses clients. La seule solution possible est donc une quarantaine personnelle pour chaque client dans son segment, à laquelle ni le fournisseur ni d'autres clients n'ont accès.
Politiques de sécurité individuelles. Chaque client dans le cloud est une entreprise distincte dont le département informatique établit ses propres politiques de sécurité. Par exemple, les administrateurs définissent les règles de scan et le calendrier des vérifications antivirus. Par conséquent, chaque organisation doit disposer de son propre centre de gestion pour configurer les politiques de l'antivirus. Les paramètres définis ne doivent pas affecter les autres clients du cloud, et le fournisseur doit être en mesure de s'assurer que, par exemple, les mises à jour de l'antivirus se déroulent normalement pour toutes les machines virtuelles du client.
Organisation de la facturation et des licences. Le modèle cloud se caractérise par sa flexibilité et implique un paiement uniquement pour le volume de ressources informatiques effectivement utilisé par le client. Si nécessaire, par exemple en raison de la saisonnalité, le volume des ressources peut être rapidement augmenté ou réduit – tout en fonction des besoins actuels en puissance de calcul. Un antivirus traditionnel n'est pas aussi flexible : en règle générale, le client achète une licence d'un an pour un nombre prédéterminé. serveurs ou des postes de travail. Les utilisateurs du cloud se déconnectent et se reconnectent régulièrement à des machines virtuelles supplémentaires en fonction de leurs besoins actuels — par conséquent, les licences antivirus doivent soutenir ce même modèle.
La deuxième question concerne la portée de la licence. Un antivirus traditionnel est licencié par le nombre de serveurs ou de postes de travail. Les licences basées sur le nombre de machines virtuelles protégées ne conviennent pas tout à fait dans le cadre du modèle cloud. Le client peut créer autant de machines virtuelles qu'il le souhaite à partir des ressources disponibles, par exemple cinq ou dix machines. Ce nombre n'est pas constant pour la plupart des clients, il nous est donc impossible, en tant que fournisseur, de suivre son évolution. Il n'est pas techniquement possible de licencier par CPU : les clients reçoivent des processeurs virtuels (vCPU), sur lesquels la licence doit être basée. Ainsi, le nouveau modèle de protection antivirus devrait permettre au client de déterminer le nombre nécessaire de vCPU pour lequel il recevra des licences antivirus.
Conformité légale. C'est un point important, car les solutions appliquées doivent garantir le respect des exigences réglementaires. Par exemple, les « résidents » du cloud traitent souvent des données personnelles. Dans ce cas, le fournisseur doit disposer d'un segment de cloud certifié séparé, qui respecte entièrement les exigences de la loi sur les « données personnelles ». Les entreprises n'ont alors pas besoin de « construire » elles-mêmes tout le système pour travailler avec des données personnelles : acquérir du matériel certifié, le connecter et le configurer, passer une certification. Pour la cybersécurité des systèmes d'information contenant des données personnelles de ces clients, l'antivirus doit également répondre aux exigences de la législation russe et posséder un certificat du FSTEC.
Nous avons examiné les critères obligatoires que la protection antivirus doit remplir dans un cloud public. Nous partagerons ensuite notre propre expérience dans l'adaptation de la solution antivirus pour fonctionner dans le cloud du fournisseur.
Comment allier antivirus et cloud
D'après notre expérience, choisir une solution sur la base de sa description et de sa documentation est une chose, mais la mettre en œuvre dans une infrastructure cloud existante en est une autre beaucoup plus complexe. Nous allons expliquer ce que nous avons fait en pratique et comment nous avons adapté l'antivirus pour fonctionner dans le cloud public d'un fournisseur. Le fournisseur de la solution antivirus est Kaspersky, qui propose des solutions de protection antivirus pour les environnements cloud. Nous avons opté pour « Kaspersky Security pour environnements virtuels » (Agent léger).
Cela inclut la console unique Kaspersky Security Center. L'agent léger et les machines virtuelles de sécurité (SVM, Security Virtual Machine) ainsi que le serveur d'intégration KSC.
Après avoir étudié l'architecture de la solution Kaspersky et effectué les premiers tests en collaboration avec les ingénieurs du fournisseur, la question de l'intégration du service dans le cloud s'est posée. La première mise en œuvre a été réalisée avec succès sur la plateforme cloud de Moscou. Et voici ce que nous avons compris.
Pour minimiser le trafic réseau, il a été décidé de placer un SVM sur chaque hôte ESXi et de « lier » le SVM aux hôtes ESXi. Ainsi, les agents légers des machines virtuelles protégées se connectent au SVM de l'hôte ESXi sur lequel ils sont exécutés. Un tenant administratif distinct a été choisi pour le KSC principal. En conséquence, les KSC secondaires sont situés dans les tenants de chaque client individuel et se connectent au KSC supérieur, situé dans le segment de gestion. Ce schéma permet de résoudre rapidement les problèmes survenant dans les tenants des clients.
Outre les questions concernant le déploiement des composants de la solution antivirus elle-même, nous avons dû organiser l'interaction réseau en créant des VxLAN supplémentaires. Bien que la solution ait été initialement destinée aux clients d'entreprise avec des clouds privés, grâce à l'ingéniosité des ingénieurs et à la flexibilité technologique de NSX Edge, nous avons pu résoudre tous les problèmes liés à la séparation des tenants et à la gestion des licences.
Nous avons travaillé en étroite collaboration avec les ingénieurs de Kaspersky. Ainsi, au cours de l'analyse de l'architecture de la solution en ce qui concerne l'interaction réseau entre les composants du système, il a été établi que, outre l'accès des agents légers au SVM, un retour d'information était également nécessaire - du SVM vers les agents légers. Cette connectivité réseau est impossible dans un environnement multitenant en raison de la possibilité d'existence de configurations réseau identiques de machines virtuelles dans différents tenants du cloud. Par conséquent, à notre demande, les collègues du fournisseur ont retravaillé le mécanisme d'interaction réseau entre l'agent léger et le SVM afin d'éliminer la nécessité de la connectivité réseau du SVM vers les agents légers.
Après que la solution a été déployée et testée sur le site cloud de Moscou, nous l'avons dupliquée sur d'autres sites, y compris le segment cloud certifié. Le service est maintenant disponible dans toutes les régions du pays.
Architecture de la solution de sécurité dans le cadre de la nouvelle approche
Le schéma général de fonctionnement de la solution antivirus dans un environnement cloud public est le suivant :
Schéma de fonctionnement de la solution antivirus dans un environnement cloud public #CloudMTS
Décrivons les particularités de fonctionnement des différents éléments de la solution dans le cloud :
• Une console unique qui permet aux clients de gérer centralement le système de protection : démarrer des analyses, contrôler les mises à jour et surveiller les zones de quarantaine. Il est possible de définir des politiques de sécurité individuelles au sein de son segment.
Il convient de noter que, bien que nous soyons un fournisseur de services, nous n'intervenons pas dans les paramètres définis par les clients. La seule chose que nous pouvons faire est de réinitialiser les politiques de sécurité aux paramètres par défaut si une reconfiguration est nécessaire. Par exemple, cela peut être nécessaire si un client les a accidentellement renforcées ou considérablement affaiblies. La société peut toujours accéder à un centre de gestion avec des politiques par défaut qu'elle peut ensuite ajuster elle-même. Un inconvénient du Kaspersky Security Center est qu'il n'est pour l'instant disponible que pour le système d'exploitation Microsoft. Bien que les agents légers puissent fonctionner à la fois avec des machines Windows et Linux. Cependant, chez Kaspersky Lab, ils promettent que KSC sera opérationnel sous Linux dans un avenir proche. Une des fonctionnalités importantes de KSC est la possibilité de gérer la quarantaine. Chaque entreprise cliente dans notre cloud dispose de sa propre quarantaine. Cette approche évite les situations où un document infecté détourne accidentellement l'attention, comme cela pourrait survenir dans le cas d'un antivirus d'entreprise classique avec une quarantaine commune.
• Agents légers. Dans le cadre du nouveau modèle, un agent léger Kaspersky Security est installé sur chaque machine virtuelle. Cela permet de ne pas stocker la base de données antivirus sur chaque VM, ce qui réduit l'espace disque utilisé. Le service est intégré à l'infrastructure cloud et fonctionne via SVM, ce qui augmente la densité des machines virtuelles sur l'hôte ESXi et optimise les performances de l'ensemble du système cloud. L'agent léger établit une file d'attente de tâches pour chaque machine virtuelle : vérifier le système de fichiers, la mémoire, etc. Cependant, SVM est chargé de l'exécution de ces opérations, dont nous parlerons plus tard. L'agent remplit également des fonctions de pare-feu, contrôle les politiques de sécurité, envoie les fichiers infectés en quarantaine et surveille la « santé » globale du système d'exploitation sur lequel il est installé. Tout cela peut être géré via la console unifiée déjà mentionnée.
• Machine Virtuelle de Sécurité. Toutes les tâches gourmandes en ressources (mises à jour des bases antivirus, vérifications programmées) sont gérées par une Machine Virtuelle de Sécurité (MVS) distincte. Elle est responsable du fonctionnement du moteur antivirus complet et de ses bases. L'infrastructure informatique de l'entreprise peut inclure plusieurs MVS. Cette approche améliore la fiabilité du système : si une machine tombe en panne et ne répond pas pendant trente secondes, les agents commencent automatiquement à en chercher une autre.
• Serveur d'Intégration KSC. L'un des composants principaux du KSC, qui attribue aux MVS de légers agents selon l'algorithme défini dans ses paramètres, tout en surveillant la disponibilité des MVS. Ainsi, ce module logiciel assure une répartition équilibrée de la charge sur toutes les MVS de l'infrastructure cloud.
Algorithme de fonctionnement dans le cloud : réduction de la charge sur l'infrastructure
En général, l'algorithme de fonctionnement de l'antivirus peut être représenté de la manière suivante. L'agent accède à un fichier sur la machine virtuelle et l'examine. Le résultat de l'examen est enregistré dans une base de verdicts centralisée partagée des MVS (appelée Shared Cache), chaque enregistrement identifiant un échantillon unique de fichier. Cette approche permet de s'assurer qu'un même fichier n'est pas vérifié plusieurs fois de suite (par exemple, s'il a été ouvert sur différentes machines virtuelles). Le fichier est scanné à nouveau uniquement s'il a été modifié ou si l'examen a été lancé manuellement.
Mise en œuvre de la solution antivirus dans le cloud du fournisseur
L'image présente un schéma général de mise en œuvre d'une solution cloud. Dans la zone de gestion du cloud, le serveur principal Kaspersky Security Center est déployé, et sur chaque hôte ESXi, une SVM individuelle est déployée par le biais du serveur d'intégration KSC (chaque SVM est liée à son hôte ESXi par des paramètres spéciaux sur VMware vCenter Server). Les clients fonctionnent dans leurs segments cloud où des machines virtuelles avec des agents sont hébergées. Elles sont gérées via des serveurs KSC individuels soumis au serveur KSC principal. En cas de besoin de protéger un petit nombre de machines virtuelles (jusqu'à 5), un accès à la console virtuelle d'un serveur KSC dédié peut être fourni au client. L'interaction réseau entre les KSC clients et le KSC principal, ainsi que les agents légers et les SVM, s'effectue via NAT à travers les routeurs virtuels EdgeGW des clients.
Selon nos estimations et les résultats des tests de nos collègues chez le fournisseur, l'Agent léger réduit la charge sur l'infrastructure virtuelle des clients d'environ 25 % (comparé à un système utilisant un logiciel antivirus traditionnel). En particulier, l'antivirus standard Kaspersky Endpoint Security (KES) pour environnements physiques consomme presque deux fois plus de temps processeur du serveur (2,95 %) que la solution de virtualisation basée sur des agents légers (1,67 %).
Graphique comparatif de la charge processeur
Une situation similaire est observée avec la fréquence des accès disque en écriture : pour l'antivirus classique, elle est de 1011 IOPS, pour l'antivirus cloud — 671 IOPS.
Graphique comparatif de la fréquence des accès disque
Le gain de performance permet de maintenir la stabilité de l'infrastructure et d'utiliser plus efficacement les capacités de calcul. Grâce à son adaptation pour le travail dans un environnement cloud public, la solution ne diminue pas les performances du cloud : elle effectue une vérification centralisée des fichiers et le téléchargement des mises à jour, répartissant la charge. Cela signifie que, d'une part, aucune menace pertinente pour l'infrastructure cloud ne sera ignorée, et d'autre part, les exigences en ressources des machines virtuelles diminueront en moyenne de 25 % par rapport à un antivirus traditionnel.
En termes de fonctionnalités, les deux solutions se ressemblent fortement : ci-dessous se trouve un tableau comparatif. Cependant, dans le cloud, comme le montrent les résultats des tests ci-dessus, il est tout de même préférable d'utiliser une solution pour les environnements virtuels.
Concernant la tarification dans le cadre de la nouvelle approche. Nous avons décidé d'utiliser un modèle permettant d'obtenir des licences en fonction du nombre de vCPU. Cela signifie que le nombre de licences sera égal au nombre de vCPU. L'antivirus peut être testé en soumettant une demande. .
Dans le prochain article sur le thème du cloud, nous parlerons de l'évolution des WAF cloud et de ce qu'il est préférable de choisir : matériel, logiciel ou cloud.
Le texte a été préparé par les employés du fournisseur cloud #CloudMTS : Denis Miagkov, architecte principal, et Alexey Afanasiev, responsable du développement des produits de sécurité informatique.
Source : habr.com
