De plus en plus d'utilisateurs déploient l'intégralité de leur infrastructure informatique sur le cloud public. Cependant, en cas de contrôle antivirus insuffisant, de graves cyber-risques surviennent dans l'infrastructure du client. La pratique montre que jusqu'à 80% des virus existants vivent parfaitement 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 conviennent pas tout à fait à ces fins.
Tout d'abord, nous vous expliquerons comment nous sommes arrivés à la conclusion que les outils de protection antivirus habituels ne sont pas adaptés à un cloud public et que d'autres approches de protection des ressources sont nécessaires.
Premièrement, en règle générale, les fournisseurs fournissent les mesures nécessaires pour garantir la protection de leurs plates-formes cloud à un niveau élevé. Par exemple, chez #CloudMTS, nous analysons tout le trafic réseau, surveillons les journaux de sécurité de notre cloud et effectuons régulièrement des pentests. Les segments de cloud attribués à des clients individuels doivent également être protégés de manière fiable.
Deuxièmement, la version classique de la lutte contre les cyber-risques implique l'installation d'un antivirus et de ses contrôles sur chaque machine virtuelle. Cependant, avec un grand nombre de machines virtuelles, cette pratique peut être inefficace et nécessiter des quantités importantes de ressources informatiques, ce qui charge en outre l'infrastructure du client et réduit les performances globales du cloud. Cela est devenu une condition préalable essentielle pour trouver de nouvelles approches pour la création 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 résoudre les problèmes de protection des ressources informatiques dans un environnement de cloud public. En règle générale, ce sont des solutions EPP lourdes (Endpoint Protection Platforms), qui, en outre, ne fournissent pas les options de personnalisation nécessaires du côté des clients du fournisseur de cloud.
Il devient évident que les solutions antivirus traditionnelles sont mal adaptées au travail dans le cloud, car elles chargent sérieusement l'infrastructure virtuelle lors des mises à jour et des analyses, et n'ont pas non plus les niveaux nécessaires de gestion des rôles et de paramètres. Ensuite, nous analyserons en détail pourquoi le cloud a besoin de nouvelles approches de protection antivirus.
Que devrait faire un antivirus dans un cloud public
Alors, prêtons attention aux spécificités du travail dans un environnement virtuel:
Efficacité des mises à jour et des contrôles planifiés en masse. Si un nombre important de machines virtuelles utilisant un antivirus traditionnel lancent une mise à jour à la fois, la soi-disant «tempête» de mises à jour se produira dans le cloud. La capacité de l'hôte ESXi, qui héberge plusieurs machines virtuelles, peut ne pas être suffisante pour gérer une rafale du même type de tâches lancées par défaut. Du point de vue du fournisseur de cloud, un tel problème peut entraîner des charges supplémentaires sur un certain nombre d'hôtes ESXi, ce qui entraînera finalement une baisse des performances de l'infrastructure virtuelle du cloud. Cela peut affecter, entre autres, les performances des machines virtuelles d'autres clients cloud. Une situation similaire peut se produire lors du démarrage d'une analyse de masse: le traitement simultané par le système de disques de nombreuses demandes du même type provenant d'utilisateurs différents affectera négativement les performances de l'ensemble du cloud. Avec un degré de probabilité élevé, une diminution de la capacité de travail des systèmes de stockage affectera tous les clients. De telles charges spasmodiques ne plaisent ni au fournisseur ni à ses clients, car elles affectent les «voisins» dans le cloud. De ce point de vue, un antivirus traditionnel peut être un gros problème.
Quarantaine sûre. 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, un fichier infecté peut être supprimé immédiatement, mais cela n'est souvent pas acceptable pour la plupart des entreprises. Les antivirus d'entreprise qui ne sont pas adaptés pour fonctionner dans le cloud du fournisseur ont généralement une zone de quarantaine commune - tous les objets infectés y tombent. Par exemple, trouvé sur les ordinateurs des utilisateurs de l'entreprise. Les clients du fournisseur de cloud "vivent" dans leurs propres segments (ou locataires). Ces segments sont opaques et isolés: les clients ne se connaissent pas et, bien sûr, ne voient pas ce que les autres placent dans le cloud. Il est évident que dans la quarantaine générale, à laquelle tous les utilisateurs d'antivirus auront accès dans le cloud, un document contenant des informations potentiellement confidentielles ou des secrets commerciaux peut potentiellement y entrer. Ce n'est pas acceptable pour le fournisseur et ses clients. Par conséquent, il ne peut y avoir qu'une seule solution - il s'agit d'une quarantaine personnelle pour chaque client de son segment, à laquelle ni le fournisseur ni les autres clients n'ont accès.
Politiques de sécurité individuelles. Chaque client dans le cloud est une entreprise distincte, dont le service informatique définit ses propres politiques de sécurité. Par exemple, les administrateurs définissent des règles d'analyse et des planifications d'analyse antivirus. En conséquence, chaque organisation doit avoir son propre centre de contrôle pour configurer les politiques antivirus. Dans le même temps, les paramètres à définir 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 antivirus sont effectuées normalement pour toutes les machines virtuelles clientes.
Organisation de la facturation et des licences. Le modèle cloud se caractérise par sa flexibilité et n'implique le paiement que de la quantité de ressources informatiques utilisées par le client. S'il y a un besoin, par exemple, compte tenu du facteur de saisonnalité, alors la quantité de ressources peut être rapidement augmentée ou réduite - le tout en fonction des besoins actuels en puissance de calcul. L'antivirus traditionnel n'est pas si flexible - en règle générale, un client achète une licence pendant un an pour un nombre prédéterminé de serveurs ou de postes de travail. Les utilisateurs du cloud se déconnectent et connectent régulièrement des machines virtuelles supplémentaires en fonction de leurs besoins actuels.Par conséquent, les licences antivirus doivent prendre en charge le même modèle.
La deuxième question est de savoir à quoi s'appliquera exactement la licence. L'antivirus traditionnel est autorisé par le nombre de serveurs ou de postes de travail. Les licences pour le nombre de machines virtuelles protégées ne correspondent pas tout à fait au modèle cloud. Le client peut créer n'importe quel nombre de machines virtuelles disponibles à partir des ressources disponibles, par exemple, cinq ou dix machines. La plupart des clients ne disposent pas de ce numéro; il nous est impossible, en tant que fournisseur, de suivre son évolution. La licence par CPU n'est pas techniquement possible: les clients reçoivent des processeurs virtuels (vCPU), qui doivent être sous licence. Ainsi, le nouveau modèle de protection antivirus devrait inclure la possibilité pour le client de déterminer le nombre requis de processeurs virtuels pour lesquels il recevra des licences antivirus.
Respect de la loi. Un point important, car les solutions appliquées doivent garantir le respect des exigences du régulateur. Par exemple, les «habitants» du cloud utilisent souvent des données personnelles. Dans ce cas, le fournisseur doit disposer d'un segment cloud certifié distinct, qui respecte pleinement les exigences de la loi sur les données personnelles. Les entreprises n'ont alors plus besoin de «construire» l'intégralité du système pour travailler seules avec des données personnelles: acheter du matériel certifié, le connecter et le configurer, et passer la certification. Pour la cyber protection de l'ISPD pour ces clients, l'antivirus doit également respecter les exigences de la loi russe et avoir un certificat FSTEC.
Nous avons examiné ces critères obligatoires auxquels la protection antivirus doit répondre dans un cloud public. Ensuite, nous partagerons notre propre expérience dans l'adaptation d'une solution antivirus pour travailler dans le cloud du fournisseur.
Comment puis-je me faire des amis antivirus et cloud
Comme notre expérience l'a montré, en choisir un pour la description et la documentation est une chose, et le mettre en pratique dans un environnement cloud déjà en cours d'exécution est une tâche complètement différente en termes de complexité. Nous vous expliquerons ce que nous avons fait dans la pratique et comment nous avons adapté l'antivirus pour qu'il fonctionne dans le cloud public du fournisseur. Le fournisseur de solutions antivirus était Kaspersky, qui propose des solutions de protection antivirus pour les environnements cloud dans son portefeuille. Nous avons opté pour Kaspersky Security for Virtualization (Light Agent).
Il comprend une seule console pour Kaspersky Security Center. Light Agent et Security Virtual Machine (SVM) et KSC Integration Server.
Après avoir étudié l'architecture de la solution de Kaspersky et effectué les premiers tests avec les ingénieurs du fournisseur, la question s'est posée d'intégrer le service dans le cloud. La première implémentation a été réalisée conjointement sur le site cloud de Moscou. Et voici ce que nous avons compris.
Afin de minimiser le trafic réseau, il a été décidé de placer SVM sur chaque hôte ESXi et de «lier» SVM aux hôtes ESXi. Dans ce cas, les agents légers des machines virtuelles protégées accèdent au SVM de l'hôte ESXi particulier sur lequel ils s'exécutent. Un locataire administratif distinct a été sélectionné pour le KSC principal. En conséquence, les subordonnés de KSC sont situés dans les locataires de chaque client individuel et se tournent vers le KSC supérieur situé dans le segment de la gestion. Un tel schéma vous permet de résoudre rapidement les problèmes survenant chez les locataires des clients.
En plus des problèmes liés à l'augmentation des composants de la solution antivirus elle-même, nous avons été confrontés à la tâche d'organiser l'interaction réseau via la création de VxLAN supplémentaires. Et bien que la solution ait été à l'origine destinée aux entreprises clientes disposant de clouds privés - grâce à l'ingéniosité technique et à la flexibilité technologique de NSX Edge, nous avons pu résoudre tous les problèmes liés à la séparation des locataires et à l'octroi de licences.
Nous avons travaillé en étroite collaboration avec les ingénieurs de Kaspersky. Ainsi, dans le processus d'analyse de l'architecture de la solution en termes d'interaction réseau entre les composants du système, il a été constaté que, en plus de l'accès des agents légers au SVM, une rétroaction est également nécessaire - du SVM aux agents légers. Cette connectivité réseau n'est pas possible dans un environnement multi-locataire en raison de la possibilité de l'existence de paramètres réseau identiques de machines virtuelles dans différents locataires du cloud. Par conséquent, à notre demande, des collègues du fournisseur ont repensé le mécanisme d'interaction réseau entre l'agent léger et SVM en termes d'élimination du besoin de connectivité réseau de SVM aux agents légers.
Une fois la solution déployée et testée sur le site cloud de Moscou, nous l'avons répliquée sur d'autres sites, y compris le segment cloud certifié. Maintenant, le service est disponible dans toutes les régions du pays.
L'architecture de la solution IB dans le cadre d'une nouvelle approche
Le schéma général de la solution antivirus dans un environnement de cloud public est le suivant:
Le schéma de fonctionnement de la solution antivirus dans un environnement de cloud public #CloudMTSNous décrivons les caractéristiques du travail des éléments de solution individuels dans le cloud:
• Une console unique qui permet aux clients de gérer de manière centralisée le système de protection: exécuter des vérifications, surveiller les mises à jour et surveiller les zones de quarantaine. Il est possible de configurer des politiques de sécurité individuelles au sein de votre segment.
Il convient de noter que bien que nous soyons un fournisseur de services, nous n'interférons pas avec 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 normes si une migration est nécessaire. Par exemple, cela peut être nécessaire si le client les resserre accidentellement ou les affaiblit considérablement. Une entreprise peut toujours obtenir un centre de contrôle avec des stratégies par défaut, qu'elle peut ensuite configurer par elle-même. L'inconvénient de Kaspersky Security Center est que la plate-forme n'est disponible que pour le système d'exploitation Microsoft. Bien que les agents légers puissent fonctionner avec les machines Windows et Linux. Cependant, Kaspersky Lab promet que dans un avenir proche, KSC fonctionnera également sous Linux. L'une des caractéristiques importantes de KSC est la capacité de gérer la quarantaine. Chaque entreprise cliente dans notre cloud est personnelle. Cette approche élimine la situation lorsqu'un document infecté par un virus tombe accidentellement dans le domaine public, comme cela pourrait être le cas avec un antivirus d'entreprise classique avec quarantaine générale.
• Agents légers. Dans le cadre du nouveau modèle, un agent léger Kaspersky Security est installé sur chaque machine virtuelle. Cela élimine le besoin de stocker une base de données antivirus sur chaque machine virtuelle, ce qui réduit la quantité d'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 les performances de l'ensemble du système cloud. Un agent léger crée une file d'attente de travaux pour chaque machine virtuelle: vérifiez le système de fichiers, la mémoire, etc. Mais SVM est responsable de l'exécution de ces opérations, dont nous parlerons plus tard. L'agent agit également comme un pare-feu, surveille 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 contrôlé à l'aide de la console unique déjà mentionnée.
• Machine virtuelle de sécurité. Toutes les tâches gourmandes en ressources (mises à jour des bases de données antivirus, analyses planifiées) sont gérées par une machine virtuelle de sécurité (SVM) distincte. Elle est responsable du fonctionnement du moteur antivirus à part entière et de ses bases de données. L'infrastructure informatique d'une entreprise peut comprendre plusieurs SVM. Cette approche augmente 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 du KSC principal, qui attribue ses SVM conformément à l'algorithme spécifié dans ses paramètres aux agents légers, et contrôle également la disponibilité des SVM. Ainsi, ce module logiciel fournit un équilibrage de charge sur toutes les infrastructures cloud SVM.
Algorithme cloud: réduire la charge d'infrastructure
En général, l'algorithme de l'antivirus peut être représenté comme suit. L'agent accède au fichier dans la machine virtuelle et le vérifie. Le résultat de la vérification est stocké dans une base de données centralisée commune des verdicts SVM (elle est appelée cache partagé), chaque entrée dans laquelle identifie un fichier échantillon unique. Cette approche vous permet de vous assurer que le même fichier n'est pas analysé plusieurs fois de suite (par exemple, s'il a été ouvert sur différentes machines virtuelles). Un fichier n'est à nouveau analysé que s'il a été modifié ou si une analyse a été lancée manuellement.
Implémentation d'une solution antivirus dans le cloud du fournisseurL'image montre le schéma général de mise en œuvre de la solution dans le cloud. Le Kaspersky Security Center principal est déployé dans la zone de contrôle du cloud et un SVM individuel est déployé sur chaque hôte ESXi à l'aide du serveur d'intégration KSC (chaque hôte ESXi possède son propre SVM associé à des paramètres spéciaux sur VMware vCenter Server). Les clients travaillent dans leurs segments cloud, qui hébergent des machines virtuelles avec des agents. Ils sont gérés par des serveurs KSC individuels subordonnés au KSC principal. S'il est nécessaire de protéger un petit nombre de machines virtuelles (jusqu'à 5), le client peut avoir accès à la console virtuelle d'un serveur dédié KSC dédié. La mise en réseau entre les KSC clients et le KSC principal, ainsi que les agents légers et les SVM, se fait à l'aide de NAT via les routeurs virtuels client EdgeGW.
Selon nos estimations et les résultats des tests des collègues du fournisseur, Light Agent réduit la charge sur l'infrastructure virtuelle des clients d'environ 25% (par rapport à un système qui utilise un logiciel antivirus traditionnel). En particulier, l'antivirus standard Kaspersky Endpoint Security (KES) pour les environnements physiques consomme presque deux fois plus de temps processeur du serveur (2,95%) qu'une solution de virtualisation basée sur un agent léger (1,67%).
Graphique de comparaison de charge CPU
Une situation similaire est observée avec la fréquence d'accès en écriture sur le disque: pour l'antivirus classique, il s'agit de 1011 IOPS, pour l'antivirus cloud - 671 IOPS.
Graphique comparant les taux d'accès au disque
Les gains de performances aident à maintenir la stabilité de l'infrastructure et à tirer parti de la puissance de calcul. En s'adaptant pour fonctionner dans un environnement de cloud public, la solution ne réduit pas les performances du cloud: elle effectue une vérification centralisée des fichiers et met à jour les téléchargements, répartissant la charge. Cela signifie que, d'une part, les menaces pertinentes pour l'infrastructure cloud ne seront pas manquées, d'autre part, les besoins moyens en ressources pour les machines virtuelles diminueront de 25% par rapport aux antivirus traditionnels.
En termes de fonctionnalité, les deux solutions se ressemblent fortement: le tableau comparatif est donné ci-dessous. Cependant, dans le cloud, comme le montrent les résultats des tests ci-dessus, il est toujours plus optimal d'utiliser la solution pour les environnements virtuels.
À propos de la tarification dans le cadre d'une nouvelle approche. Nous avons décidé d'utiliser un modèle qui vous permet d'obtenir des licences par le nombre de vCPU. Cela signifie que le nombre de licences sera égal au nombre de vCPU. L'antivirus peut être testé en laissant une demande
sur le site .
Dans le prochain article sur les sujets liés au cloud, nous parlerons de l'évolution des WAF basés sur le cloud et de ce qu'il y a de mieux à choisir: le matériel, les logiciels ou le cloud.
Le texte a été préparé par les employés du fournisseur de cloud #CloudMTS: Denis Myagkov, architecte principal et Alexey Afanasyev, responsable du développement de produits IB.