De plus en plus d’utilisateurs transfèrent l’intégralité de leur infrastructure informatique vers le cloud public. Toutefois, si le contrôle antivirus est insuffisant dans l’infrastructure du client, de graves risques cybernétiques apparaissent. 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 sont pas entièrement adaptés à ces fins.
Pour commencer, nous allons vous raconter comment nous sommes arrivés à l’idée que les outils de protection antivirus habituels ne sont pas adaptés au cloud public et que d’autres approches de protection des ressources sont nécessaires.
Premièrement, les fournisseurs prennent généralement les mesures nécessaires pour garantir que leurs plateformes cloud soient protégées à un niveau élevé. 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 pentests. Les segments cloud alloués à des clients individuels doivent également être protégés de manière sécurisée.
Deuxièmement, l’option classique pour lutter contre les cyber-risques consiste à installer un antivirus et des outils de gestion antivirus sur chaque machine virtuelle. Cependant, avec un grand nombre de machines virtuelles, cette pratique peut s’avérer inefficace et nécessiter des quantités importantes de ressources informatiques, surchargeant ainsi davantage l’infrastructure du client et réduisant les performances globales du cloud. C'est devenu une condition préalable essentielle à la recherche de nouvelles approches permettant de créer une protection antivirus efficace pour les machines virtuelles des clients.
De plus, la plupart des solutions antivirus du 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, il s'agit de solutions EPP (Endpoint Protection Platforms) lourdes, qui, de plus, n'offrent pas la personnalisation nécessaire du côté client du fournisseur de cloud.
Il devient évident que les solutions antivirus traditionnelles ne sont pas adaptées au travail dans le cloud, car elles chargent sérieusement l'infrastructure virtuelle lors des mises à jour et des analyses, et ne disposent pas non plus des niveaux nécessaires de gestion et de paramètres basés sur les rôles. Ensuite, nous analyserons en détail pourquoi le cloud a besoin de nouvelles approches en matière de protection antivirus.
Ce qu'un antivirus dans un cloud public devrait être capable de faire
Alors, prêtons attention aux spécificités du travail dans un environnement virtuel :
Efficacité des mises à jour et des analyses de masse programmées. Si un nombre important de machines virtuelles utilisant un antivirus traditionnel lancent une mise à jour en même temps, une « tempête » de mises à jour se produira dans le cloud. La puissance d'un hôte ESXi qui héberge plusieurs machines virtuelles peut ne pas être suffisante pour gérer le barrage de tâches similaires exécuté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 à terme une baisse des performances de l'infrastructure virtuelle cloud. Cela peut, entre autres, affecter les performances des machines virtuelles d'autres clients cloud. Une situation similaire peut survenir lors du lancement d'une analyse de masse : le traitement simultané par le système de disque de nombreuses requêtes similaires émanant de différents utilisateurs affectera négativement les performances de l'ensemble du cloud. Avec un degré de probabilité élevé, une diminution des performances du système de stockage affectera tous les clients. De tels chargements brusques ne plaisent ni au fournisseur ni à ses clients, car ils affectent les « voisins » dans le cloud. De ce point de vue, les antivirus traditionnels peuvent poser un gros problème.
Quarantaine sûre. Si un fichier ou un document potentiellement infecté par un virus est détecté sur le système, il est envoyé en quarantaine. Bien entendu, un fichier infecté peut être supprimé immédiatement, mais cela n’est souvent pas acceptable pour la plupart des entreprises. En règle générale, les antivirus d'entreprise qui ne sont pas adaptés pour fonctionner dans le cloud du fournisseur ont une zone de quarantaine commune - tous les objets infectés y tombent. Par exemple, ceux que l’on retrouve 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 hébergent dans le cloud. Évidemment, la quarantaine générale, à laquelle auront accès tous les utilisateurs d'antivirus dans le cloud, pourrait potentiellement inclure un document contenant des informations confidentielles ou un secret commercial. Ceci est inacceptable pour le fournisseur et ses clients. Par conséquent, il ne peut y avoir qu'une seule solution : la quarantaine personnelle pour chaque client de son segment, à laquelle ni le prestataire 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 planifient des analyses antivirus. Par conséquent, chaque organisation doit disposer de son propre centre de contrôle pour configurer les politiques antivirus. Dans le même temps, les paramètres spécifiés ne doivent pas affecter les autres clients cloud et le fournisseur doit être en mesure de vérifier 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 implique de ne payer que pour la quantité de ressources informatiques utilisées par le client. S'il existe un besoin, par exemple en raison de la saisonnalité, 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 aussi flexible - en règle générale, le client achète une licence d'un an pour un nombre prédéterminé de serveurs ou de postes de travail. Les utilisateurs du cloud 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 ce que couvrira exactement la licence. Les antivirus traditionnels sont concédés sous licence en fonction du nombre de serveurs ou de postes de travail. Les licences basées sur le nombre de machines virtuelles protégées ne sont pas entièrement adaptées au modèle cloud. Le client peut créer n'importe quel nombre de machines virtuelles qui lui conviennent à partir des ressources disponibles, par exemple cinq ou dix machines. Ce nombre n'est pas constant pour la plupart des clients ; il ne nous est pas possible, en tant que fournisseur, de suivre ses évolutions. Il n'existe aucune possibilité technique d'octroi de licence par CPU : les clients reçoivent des processeurs virtuels (vCPU) qui doivent être utilisés pour l'attribution de licence. Ainsi, le nouveau modèle de protection antivirus devrait inclure la possibilité pour le client de déterminer le nombre requis de vCPU pour lesquels il recevra des licences antivirus.
Respect de la législation. Un point important, puisque les solutions utilisées doivent garantir le respect des exigences du régulateur. Par exemple, les « résidents » du cloud travaillent souvent avec 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 pas besoin de « construire » de manière indépendante l'ensemble du système pour travailler avec des données personnelles : acheter du matériel certifié, le connecter et le configurer, et se soumettre à la certification. Pour la cyberprotection de l'ISPD de ces clients, l'antivirus doit également être conforme aux exigences de la législation russe et disposer d'un certificat FSTEC.
Nous avons examiné les critères obligatoires auxquels doit répondre la protection antivirus dans le cloud public. Nous partagerons ensuite notre propre expérience dans l’adaptation d’une solution antivirus pour qu’elle fonctionne dans le cloud du fournisseur.
Comment se faire des amis entre antivirus et cloud ?
Comme notre expérience l'a montré, choisir une solution basée sur une description et une documentation est une chose, mais la mettre en pratique dans un environnement cloud déjà fonctionnel est une tâche complètement différente en termes de complexité. Nous vous expliquerons ce que nous avons fait en pratique et comment nous avons adapté l'antivirus pour qu'il fonctionne dans le cloud public du fournisseur. Le fournisseur de la solution antivirus était Kaspersky, dont le portefeuille comprend des solutions de protection antivirus pour les environnements cloud. Nous avons opté pour « Kaspersky Security for Virtualization » (Light Agent).
Il comprend une seule console Kaspersky Security Center. Agent léger et machines virtuelles de sécurité (SVM, Security Virtual Machine) et serveur d'intégration KSC.
Après avoir étudié l’architecture de la solution Kaspersky et réalisé les premiers tests avec les ingénieurs de l’éditeur, la question s’est posée de l’intégration du service dans le cloud. La première mise en œuvre a été réalisée conjointement sur le site cloud de Moscou. Et c'est ce que nous avons réalisé.
Afin de minimiser le trafic réseau, il a été décidé de placer une SVM sur chaque hôte ESXi et de « lier » la SVM aux hôtes ESXi. Dans ce cas, les agents légers des machines virtuelles protégées accèdent à la SVM de l'hôte ESXi exact sur lequel ils s'exécutent. Un locataire administratif distinct a été sélectionné pour le KSC principal. En conséquence, les KSC subordonnés sont situés chez les locataires de chaque client individuel et s'adressent au KSC supérieur situé dans le segment de gestion. Ce schéma vous permet de résoudre rapidement les problèmes qui surviennent chez les clients locataires.
En plus des problèmes liés à la montée en puissance 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 même si la solution était initialement destinée aux entreprises clientes disposant de cloud privé, grâce à l'ingénierie et à la flexibilité technologique de NSX Edge, nous avons pu résoudre tous les problèmes liés à la séparation des locataires et aux licences.
Nous avons travaillé en étroite collaboration avec les ingénieurs de Kaspersky. Ainsi, lors du 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é qu'en plus de l'accès des agents légers au SVM, un retour d'information est également nécessaire - du SVM aux agents légers. Cette connectivité réseau n'est pas possible dans un environnement multi-tenant en raison de la possibilité de paramètres réseau identiques des machines virtuelles dans différents locataires 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 en éliminant le besoin de connectivité réseau du 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é. Le service est désormais disponible dans toutes les régions du pays.
Architecture d'une solution de sécurité de l'information dans le cadre d'une nouvelle approche
Le schéma général de fonctionnement d'une solution antivirus dans un environnement cloud public est le suivant :
Schéma de fonctionnement d'une solution antivirus dans un environnement cloud public #CloudMTS
Décrivons les caractéristiques du fonctionnement des éléments individuels de la solution 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 analyses, contrôler 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 est à noter que bien que nous soyons prestataire de services, nous n'intervenons pas sur 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 politiques standard si une reconfiguration est nécessaire. Par exemple, cela peut être nécessaire si le client les a accidentellement serrés ou considérablement affaiblis. Une entreprise peut toujours recevoir un centre de contrôle avec des politiques par défaut, qu'elle peut ensuite configurer indépendamment. L'inconvénient de Kaspersky Security Center est que la plateforme n'est actuellement 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 sous Linux. L'une des fonctions importantes du KSC est la capacité de gérer la quarantaine. Chaque entreprise cliente de notre cloud en a une personnelle. Cette approche élimine les situations dans lesquelles un document infecté par un virus devient accidentellement visible publiquement, comme cela pourrait se produire dans le cas d'un antivirus d'entreprise classique avec quarantaine générale.
• Agents légers. Dans le cadre du nouveau modèle, un agent Kaspersky Security léger est installé sur chaque machine virtuelle. Cela élimine le besoin de stocker la base de données antivirus sur chaque machine virtuelle, ce qui réduit la quantité d'espace disque requis. 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. L'agent léger construit une file d'attente de tâches pour chaque machine virtuelle : vérifier le système de fichiers, la mémoire, etc. Mais le SVM est chargé d’effectuer ces opérations, dont nous parlerons plus tard. L'agent fonctionne également comme un 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é à 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 d'un 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 aux agents légers conformément à l'algorithme spécifié dans ses paramètres, et contrôle également la disponibilité des SVM. Ainsi, ce module logiciel assure l'équilibrage de charge sur toutes les SVM de l'infrastructure cloud.
Algorithme pour travailler dans le cloud : réduire la charge sur l'infrastructure
En général, l'algorithme antivirus peut être représenté comme suit. L'agent accède au fichier sur la machine virtuelle et le vérifie. Le résultat de la vérification est stocké dans une base de données de verdict SVM centralisée commune (appelée Shared Cache), chaque entrée dans laquelle identifie un échantillon de fichier unique. Cette approche permet de s'assurer qu'un même fichier n'est pas analysé plusieurs fois de suite (par exemple, s'il a été ouvert sur différentes machines virtuelles). Le fichier est réanalysé uniquement si des modifications y ont été apportées ou si l'analyse a été lancée manuellement.
Mise en place d'une solution antivirus dans le cloud du fournisseur
L'image montre un schéma général de la 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 une SVM individuelle est déployée sur chaque hôte ESXi à l'aide du serveur d'intégration KSC (chaque hôte ESXi possède sa propre SVM attachée avec des paramètres spéciaux sur VMware vCenter Server). Les clients travaillent dans leurs propres segments cloud, où se trouvent les machines virtuelles avec des agents. Ils sont gérés via 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 KSC dédié spécial. L'interaction réseau entre les KSC clients et le KSC principal, ainsi que les agents légers et les SVM, s'effectue à l'aide de NAT via les routeurs virtuels clients EdgeGW.
Selon nos estimations et les résultats des tests effectués par nos collègues du fournisseur, Light Agent réduit la charge sur l'infrastructure virtuelle des clients d'environ 25 % (par rapport à 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 CPU du serveur (2,95 %) qu'une solution légère de virtualisation basée sur un agent (1,67 %).
Tableau de comparaison de la charge du processeur
Une situation similaire est observée avec la fréquence des accès en écriture sur disque : pour un antivirus classique c'est 1011 IOPS, pour un antivirus cloud c'est 671 IOPS.
Graphique de comparaison du taux d'accès au disque
L'avantage en termes de performances vous permet de maintenir la stabilité de l'infrastructure et d'utiliser la puissance de calcul plus efficacement. En s'adaptant au travail dans un environnement de cloud public, la solution ne réduit pas les performances du cloud : elle vérifie les fichiers et télécharge les mises à jour de manière centralisée, répartissant ainsi la charge. Cela signifie que, d'une part, les menaces liées à l'infrastructure cloud ne seront pas ignorées, et d'autre part, les besoins en ressources des machines virtuelles seront réduits en moyenne de 25 % par rapport à un antivirus traditionnel.
En termes de fonctionnalités, les deux solutions sont très similaires : vous trouverez ci-dessous un tableau comparatif. Cependant, dans le cloud, comme le montrent les résultats des tests ci-dessus, il est toujours optimal d'utiliser une solution pour les environnements virtuels.
À propos des tarifs dans le cadre de la nouvelle approche. Nous avons décidé d'utiliser un modèle qui nous permet d'obtenir des licences en fonction du nombre de vCPU. Cela signifie que le nombre de licences sera égal au nombre de vCPU. Vous pouvez tester votre antivirus en laissant une demande .
Dans le prochain article sur les sujets liés au 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 de cloud #CloudMTS : Denis Myagkov, architecte principal et Alexey Afanasyev, responsable du développement des produits de sécurité de l'information.
Source: habr.com