Steeds meer gebruikers brengen hun volledige IT-infrastructuur naar de publieke cloud. Echter, bij onvoldoende antiviruscontrole in de infrastructuur van de klant ontstaan er ernstige cyberrisico's. De praktijk toont aan dat tot 80% van de bestaande virussen uitstekend gedijen in een virtuele omgeving. In dit artikel zullen we bespreken hoe we IT-resources in de publieke cloud kunnen beveiligen en waarom traditionele antivirusoplossingen hiervoor niet geschikt zijn.
Laten we beginnen met uit te leggen hoe we tot de conclusie zijn gekomen dat de gebruikelijke antivirusbescherming niet geschikt is voor de publieke cloud en dat andere benaderingen voor bescherming van resources nodig zijn.
Ten eerste zorgen providers doorgaans voor de benodigde maatregelen om de bescherming van hun cloudplatformen op een hoog niveau te garanderen. Bijvoorbeeld, wij bij #CloudMTS analyseren al het netwerkverkeer, monitoren de logs van onze cloudbeveiligingssystemen en voeren regelmatig pentests uit. Segmenten van de cloud die aan afzonderlijke klanten zijn toegewezen, moeten ook goed worden beschermd.
Ten tweede houdt de klassieke aanpak van het bestrijden van cyberrisico's in dat een antivirusprogramma en beheertools op elke virtuele machine moeten worden geĆÆnstalleerd. Echter, bij een groot aantal virtuele machines kan deze praktijk ondoeltreffend zijn en aanzienlijke rekenkracht vereisen, waardoor de infrastructuur van de klant extra wordt belast en de algehele prestaties van de cloud worden verlaagd. Dit was een belangrijke aanleiding om nieuwe benaderingen voor effectieve antivirusbeveiliging van de virtuele machines van klanten te zoeken.
Bovendien zijn de meeste antivirusoplossingen op de markt niet aangepast om de beveiligingsbehoeften van IT-resources in een publieke cloudomgeving aan te pakken. Over het algemeen zijn het zware EPP-oplossingen (Endpoint Protection Platforms), die bovendien geen mogelijkheid bieden voor noodzakelijke aanpassing aan de zijde van de cloudproviderklanten.
Het wordt duidelijk dat traditionele antivirusoplossingen slecht geschikt zijn voor gebruik in de cloud, omdat ze de virtuele infrastructuur sterk belasten tijdens updates en scans, en ook niet de noodzakelijke niveaus van rolbeheer en instellingen bieden. Laten we verder ingaan op de redenen waarom de cloud behoefte heeft aan nieuwe benaderingen van antivirusbescherming.
Wat een antivirus in de publieke cloud moet kunnen
Laten we de specifieke kenmerken van werken in een virtuele omgeving bekijken:
De effectiviteit van het uitvoeren van updates en massascans volgens schema. Als een aanzienlijk aantal virtuele machines dat gebruikmaakt van traditionele antivirussoftware gelijktijdig een update initieert, ontstaat er in de cloud een zogenaamd 'update-storm'. De middelen van de ESXi-host waarop meerdere virtuele machines draaien, zijn mogelijk niet voldoende om de golf van identieke taken die standaard wordt uitgevoerd, te verwerken. Vanuit het perspectief van de cloudprovider kan dit probleem leiden tot extra belasting van een aantal ESXi-hosts, wat uiteindelijk de prestaties van de virtuele infrastructuur van de cloud zal aantasten. Dit kan ook gevolgen hebben voor de prestaties van de virtuele machines van andere cloudklanten. Een soortgelijke situatie kan zich voordoen bij het starten van massascans: gelijktijdige verwerking van veel identieke verzoeken van verschillende gebruikers door het opslagsysteem zal een negatief effect hebben op de prestaties van de hele cloud. Er is een grote kans dat de beschikbaarheid van de opslaginfrastructuur van invloed is op alle klanten. Dergelijke fluctuaties in belasting zijn zowel voor de provider als zijn klanten ongewenst, omdat ze de 'buren' in de cloud beĆÆnvloeden. Vanuit dit perspectief kan traditionele antivirussoftware een groot probleem vormen.
Veilige quarantƤne. Als een bestand of document in het systeem wordt gedetecteerd dat mogelijk is geĆÆnfecteerd met een virus, wordt het naar de quarantaine gestuurd. Natuurlijk kan een geĆÆnfecteerd bestand onmiddellijk worden verwijderd, maar dit is vaak onaanvaardbaar voor de meeste bedrijven. Bedrijfsenterprise-antivirusprogramma's die niet zijn aangepast voor gebruik in de cloud van de provider, hebben doorgaans een gezamenlijke quarantainezone ā hierin komen alle geĆÆnfecteerde objecten terecht. Bijvoorbeeld, die ontdekt op de computers van de medewerkers van het bedrijf. Klanten van de cloudprovider ālevenā in hun eigen segmenten (of tenants). Deze segmenten zijn ondoorzichtig en geĆÆsoleerd: klanten weten niet van elkaar en zien natuurlijk ook niet wat anderen in de cloud plaatsen. Het is duidelijk dat in de gezamenlijke quarantaine, die door alle gebruikers van het antivirus in de cloud kan worden geraadpleegd, potentiĆ«le documenten kunnen worden geplaatst die vertrouwelijke informatie of bedrijfsgeheimen bevatten. Dit is onaanvaardbaar voor de provider en zijn klanten. Daarom kan er maar Ć©Ć©n oplossing zijn ā een persoonlijke quarantaine voor elke klant in zijn segment, waar noch de provider, noch andere klanten toegang toe hebben.
Individuele beveiligingsbeleid. Elke klant in de cloud is een afzonderlijk bedrijf, wiens IT-afdeling zijn eigen beveiligingsbeleid instelt. Bijvoorbeeld, de beheerders bepalen de scanregels en het schema voor antiviruscontroles. Dienovereenkomstig moet elke organisatie haar eigen beheerscentrum hebben voor het instellen van het antivirusbeleid. De gegeven instellingen mogen geen invloed hebben op andere cloudklanten, en de provider moet in staat zijn te bevestigen dat bijvoorbeeld de updates van het antivirus soepel verlopen voor alle virtuele machines van de klant.
Organisatie van facturering en licenties. Het cloudmodel kenmerkt zich door flexibiliteit en houdt in dat er alleen betaalt wordt voor de hoeveelheid IT-hulpmiddelen die door de klant is gebruikt. Indien nodig, bijvoorbeeld door seizoensgebonden factoren, kan de hoeveelheid middelen snel worden vergroot of verkleind, afhankelijk van de huidige behoefte aan rekencapaciteiten. Traditionele antivirussoftware is niet zo flexibel ā doorgaans koopt de klant een jaarlicentie voor een vooraf bepaalde hoeveelheid. servers of workstations. Cloud users frequently disconnect and connect additional virtual machines based on their current needs ā accordingly, antivirus licenses must support the same model.
The second question is what exactly the license will cover. Traditional antivirus is licensed per number of servers or workstations. Licenses based on the number of protected virtual machines are not quite suitable within the cloud model. A client can create any number of virtual machines from the existing resources, for example, five or ten machines. For most clients, this number is not constant, and tracking its changes is not feasible for us as a provider. Licensing per CPU is not technically possible: clients receive virtual processors (vCPU), based on which licensing should occur. Thus, the new antivirus protection model should allow the customer to specify the required number of vCPUs for which they will receive antivirus licenses.
Compliance with legislation. This is an important point, as the implemented solutions must meet the regulator's requirements. For example, cloud 'inhabitants' often work with personal data. In such cases, the provider must have a separate certified segment of the cloud that fully complies with the requirements of the 'On Personal Data' law. Then, companies do not need to 'build' the entire system for handling personal data themselves: acquiring certified equipment, connecting it, configuring it, and going through certification. For cybersecurity of personal data processing systems (ISPDn) for such clients, the antivirus must also comply with the requirements of Russian legislation and have a certificate from FSTEC.
We have reviewed the mandatory criteria that antivirus protection in a public cloud must meet. Next, we will share our own experience in adapting the antivirus solution for operation within the provider's cloud.
How to integrate antivirus with the cloud
Uit onze ervaring blijkt dat het kiezen van een oplossing op basis van beschrijvingen en documentatie Ć©Ć©n ding is, maar het praktisch implementeren in een reeds functionerende cloudomgeving een heel andere uitdaging vormt qua complexiteit. We vertellen wat we praktisch hebben gedaan en hoe we de antivirus hebben aangepast voor gebruik in de publieke cloud van de provider. De leverancier van de antivirusoplossing was Kaspersky, die oplossingen voor antivirusbescherming voor cloudomgevingen in zijn portfolio heeft. We kozen voor 'Kaspersky Security voor virtuele omgevingen' (Light Agent).
Het omvat een enkele console van het Kaspersky Security Center. De Light Agent en de Security Virtual Machines (SVM) en de integratieserver KSC.
Nadat we de architectuur van de oplossing van Kaspersky hadden bestudeerd en de eerste tests samen met de ingenieurs van de leverancier hadden uitgevoerd, kwam de vraag naar de integratie van de service in de cloud. De eerste implementatie werd gezamenlijk uitgevoerd op de Moskouse cloudlocatie. En dit is wat we hebben begrepen.
Om het netwerkverkeer te minimaliseren, werd besloten om op elke ESXi-host een SVM te plaatsen en de SVM aan de ESXi-hosts te 'hechten'. In dat geval communiceren de lichte agents van de beschermde virtuele machines met de SVM van die specifieke ESXi-host waarop ze draaien. Voor de hoofd-KSC werd een aparte administratieve tenant gekozen. Hierdoor bevinden de ondergeschikte KSCs zich in de tenants van elke afzonderlijke cliƫnt en communiceren ze met de bovenliggende KSC, die in het managementsegment is geplaatst. Dit schema maakt het mogelijk om snel problemen op te lossen die zich in de tenants van de cliƫnten voordoen.
Naast de vragen over het opzetten van de componenten van de antivirusoplossing kwamen we de uitdaging tegen om netwerken te organiseren door middel van het creƫren van extra VxLANs. En hoewel de oplossing aanvankelijk was bedacht voor enterprise-klanten met private clouds, zijn we met behulp van de ingenieursslimheid en technologische flexibiliteit van NSX Edge erin geslaagd om alle uitdagingen met betrekking tot tenant-scheiding en licentieverlening op te lossen.
We worked closely with Kaspersky engineers. During the analysis of the solution's architecture regarding network interactions between system components, it was established that, in addition to access from lightweight agents to the SVM, feedback was also necessary ā from the SVM to the lightweight agents. This network connectivity is not feasible in a multitenant environment due to the possibility of identical network settings for virtual machines across different cloud tenants. Therefore, at our request, the vendor's team reworked the network interaction mechanism between the lightweight agent and the SVM to eliminate the need for network connectivity from the SVM to the lightweight agents.
After the solution was deployed and tested at the Moscow cloud site, we replicated it to other sites, including the certified cloud segment. The service is now available in all regions of the country.
The architecture of the information security solution within the new approach
The overall operation scheme of the antivirus solution in the public cloud environment is as follows:
Operation scheme of the antivirus solution in the public cloud environment #CloudMTS
Let's describe the features of the operation of individual elements of the solution in the cloud:
ā¢ A unified console that allows clients to manage the protection system centrally: launching scans, monitoring updates, and observing quarantine zones. There is an opportunity to configure individual security policies within their segment.
Het is belangrijk op te merken dat wij, hoewel we een serviceprovider zijn, niet ingrijpen in de instellingen die door klanten worden gemaakt. Het enige wat we kunnen doen, is de beveiligingsbeleid resetten naar de standaarden als er behoefte is aan herconfiguratie. Dit kan bijvoorbeeld nodig zijn als een klant per ongeluk de beveiliging heeft verscherpt of aanzienlijk heeft verlaagd. Elk bedrijf kan altijd toegang krijgen tot een beheerscentrum met standaardbeleid, dat vervolgens naar eigen inzicht kan worden aangepast. Een nadeel van Kaspersky Security Center is dat het platform momenteel alleen beschikbaar is voor Microsoft-besturingssystemen. Hoewel lichte agents zowel met Windows- als Linux-systemen kunnen werken. Echter, in de 'Kaspersky Lab' beloven ze dat KSC binnenkort ook onder Linux zal draaien. Een van de belangrijke functies van KSC is het kunnen beheren van de quarantaines. Elke klant in onze cloud heeft een persoonlijke quarantaines. Deze aanpak voorkomt situaties waarin een door een virus geĆÆnfecteerd document per ongeluk openbaar wordt, zoals bij een traditionele bedrijfsantivirus met een gezamenlijke quarantaines het geval zou zijn.
ā¢ Lichte agents. In het kader van het nieuwe model wordt er een lichte Kaspersky Security-agent op elke virtuele machine geĆÆnstalleerd. Dit elimineert de noodzaak om antivirusdatabases op elke VM op te slaan, wat de hoeveelheid benodigde schijfruimte vermindert. De service is geĆÆntegreerd met de cloudinfrastructuur en werkt via SVM, wat de dichtheid van virtuele machines op een ESXi-host verhoogt en de prestaties van het hele cloud systeem verbetert. De lichte agent stelt een takenqueue op voor elke virtuele machine: systeemcheck van het bestandssysteem, geheugen, etc. Echter, het uitvoeren van deze acties is de verantwoordelijkheid van SVM, waar we het later over zullen hebben. Ook fungeert de agent als een firewall, beheert het beveiligingsbeleid, stuurt geĆÆnfecteerde bestanden naar de quarantaines en monitort de algehele 'gezondheid' van het besturingssysteem waarop het is geĆÆnstalleerd. Al deze functies kunnen worden beheerd via de eerder genoemde centrale console.
ā¢ Beveiligingsvirtuele machine. Alle middelen-intensieve taken (updates van antivirusdatabases, geplande controles) worden uitgevoerd door een aparte beveiligingsvirtuele machine (SVM). Zij is verantwoordelijk voor de werking van de volledige antivirusengine en de bijbehorende databases. De IT-infrastructuur van het bedrijf kan meerdere SVM's omvatten. Deze aanpak verhoogt de betrouwbaarheid van het systeem ā als een machine uitvalt en langer dan dertig seconden niet reageert, beginnen de agents automatisch naar een andere te zoeken.
ā¢ Integratieserver KSC. Een van de componenten van de hoofdkantoren van het KSC, die volgens het gedefinieerde algoritme in zijn instellingen, lichte agents toewijst aan hun SVM's en toezicht houdt op de beschikbaarheid van SVM's. Dit softwaremodule zorgt zo voor de belastingverdeling over alle SVM's in de cloudinfrastructuur.
Werking van het algoritme in de cloud: vermindering van de belasting op de infrastructuur
In het algemeen kan het werkingsmechanisme van de antivirus als volgt worden voorgesteld. De agent benadert een bestand op de virtuele machine en controleert dit. Het resultaat van de controle wordt opgeslagen in een gedeelde gecentraliseerde database van SVM-oordelen (Shared Cache), waarbij elke vermelding een uniek bestandmonster identificeert. Deze aanpak zorgt ervoor dat hetzelfde bestand niet meerdere keren achter elkaar wordt gecontroleerd (bijvoorbeeld als het op verschillende virtuele machines is geopend). Het bestand wordt alleen opnieuw gescand als er wijzigingen zijn aangebracht of als de controle handmatig is opgestart.
Uitvoering van de antivirusoplossing in de cloud van de provider
De afbeelding toont een algemeen schema van de implementatie van de oplossing in de cloud. In de beheerszone van de cloud is het hoofdkantoor van Kaspersky Security Center uitgerold, terwijl op elke ESXi-host een individuele SVM (specifieke instellingen zijn gekoppeld aan elke ESXi-host via VMware vCenter Server) is uitgerold met behulp van de KSC-integratieserver. Klanten werken in hun eigen cloudsegmenten, waar virtuele machines met agents zijn geplaatst. Deze worden beheerd via individuele KSC-servers die ondergeschikt zijn aan het hoofdkantoor van de KSC. Indien nodig kan de klant toegang krijgen tot de virtuele console van een speciaal toegewijde KSC-server voor een klein aantal virtuele machines (tot 5). De netwerkintegratie tussen de klant-KSŠ” en het hoofdkantoor van de KSC, evenals de lichte agents en SVM, gebeurt via NAT via de klantvirtuele edge-routers.
Volgens onze schattingen en de testresultaten van collega's bij de leverancier, vermindert de Lichte agent de belasting van de virtuele infrastructuur van klanten met ongeveer 25% (vergeleken met een systeem dat traditionele antivirussoftware gebruikt). In het bijzonder verbruikt de standaard antivirus Kaspersky Endpoint Security (KES) voor fysieke omgevingen bijna twee keer zoveel serverprocessor tijd (2,95%) als de Virtualisatie-oplossing op basis van lichte agents (1,67%).
Grafiek ter vergelijking van de belasting op de processor
Een vergelijkbare situatie is te zien met de schrijffrequentie naar de schijf: voor traditionele antivirus is deze 1011 IOPS, voor cloud-antivirus is dit 671 IOPS.
Grafiek ter vergelijking van de schrijffrequentie naar de schijf
De prestatie winst helpt bij het ondersteunen van de stabiliteit van de infrastructuur en maakt een efficiƫnter gebruik van rekenkracht mogelijk. Door de aanpassing voor gebruik in een publieke cloudomgeving vermindert de oplossing de prestaties van de cloud niet: deze voert centrale bestandscontroles en update downloads uit, terwijl de belasting wordt verdeeld. Dit betekent dat aan de ene kant actuele bedreigingen voor de cloudinfrastructuur niet worden gemist, en aan de andere kant gemiddeld 25% lager zijn de vereisten voor de bronnen van virtuele machines in vergelijking met traditionele antivirus.
Qua functionaliteit lijken beide oplossingen sterk op elkaar: hieronder staat een vergelijkende tabel. In de cloud, zoals de bovenstaande testresultaten tonen, is het echter optimaler om een oplossing voor virtuele omgevingen te gebruiken.
Over de tarificatie binnen het nieuwe model. We hebben besloten om een model te gebruiken dat licenties toekent op basis van het aantal vCPU's. Dit betekent dat het aantal licenties gelijk zal zijn aan het aantal vCPU's. Antivirus kan worden getest door een aanvraag in te dienen. .
In het volgende deel over de cloud zullen we de evolutie van cloud WAF's bespreken en wat het beste is om te kiezen: hardware, software of de cloud.
De tekst is voorbereid door medewerkers van de cloudprovider #CloudMTS: Denis Myagkov, hoofdarchitect, en Alexey Afanasyev, productontwikkelingsmanager voor IB.
Bron: habr.com
