Waarom traditionele antivirussen niet geschikt zijn voor publieke clouds. Dus wat moet ik doen?

Steeds meer gebruikers brengen hun volledige IT-infrastructuur naar de publieke cloud. Als de antiviruscontrole echter onvoldoende is in de infrastructuur van de klant, ontstaan ​​er ernstige cyberrisico’s. De praktijk leert dat tot 80% van de bestaande virussen perfect in een virtuele omgeving leven. In dit bericht zullen we het hebben over hoe je IT-bronnen in de publieke cloud kunt beschermen en waarom traditionele antivirussen niet helemaal geschikt zijn voor deze doeleinden.

Waarom traditionele antivirussen niet geschikt zijn voor publieke clouds. Dus wat moet ik doen?

Om te beginnen zullen we u vertellen hoe we op het idee zijn gekomen dat de gebruikelijke antivirusbeschermingstools niet geschikt zijn voor de publieke cloud en dat andere benaderingen voor het beschermen van bronnen nodig zijn.

Ten eerste zorgen aanbieders doorgaans voor de nodige maatregelen om ervoor te zorgen dat hun cloudplatforms op een hoog niveau worden beschermd. Bij #CloudMTS analyseren we bijvoorbeeld al het netwerkverkeer, monitoren we logs van de beveiligingssystemen van onze cloud en voeren we regelmatig pentests uit. Cloudsegmenten die aan individuele klanten zijn toegewezen, moeten ook veilig worden beschermd.

Ten tweede bestaat de klassieke optie om cyberrisico’s te bestrijden uit het installeren van antivirus- en antivirusbeheertools op elke virtuele machine. Met een groot aantal virtuele machines kan deze praktijk echter ineffectief zijn en aanzienlijke hoeveelheden computerbronnen vereisen, waardoor de infrastructuur van de klant verder wordt belast en de algehele prestaties van de cloud worden verminderd. Dit is een belangrijke voorwaarde geworden bij het zoeken naar nieuwe benaderingen voor het bouwen van effectieve antivirusbescherming voor virtuele machines van klanten.

Bovendien zijn de meeste antivirusoplossingen op de markt niet aangepast om de problemen van het beschermen van IT-bronnen in een openbare cloudomgeving op te lossen. In de regel zijn het zwaargewicht EPP-oplossingen (Endpoint Protection Platforms), die bovendien niet voor het nodige maatwerk zorgen aan de klantzijde van de cloudaanbieder.

Het wordt duidelijk dat traditionele antivirusoplossingen slecht geschikt zijn voor het werken in de cloud, omdat ze de virtuele infrastructuur ernstig belasten tijdens updates en scans, en bovendien niet over de noodzakelijke niveaus van op rollen gebaseerd beheer en instellingen beschikken. Vervolgens zullen we in detail analyseren waarom de cloud nieuwe benaderingen van antivirusbescherming nodig heeft.

Wat een antivirusprogramma in een publieke cloud zou moeten kunnen doen

Laten we dus aandacht besteden aan de specifieke kenmerken van het werken in een virtuele omgeving:

Efficiëntie van updates en geplande massascans. Als een aanzienlijk aantal virtuele machines die gebruik maken van een traditioneel antivirusprogramma tegelijkertijd een update initiëren, ontstaat er een zogenaamde ‘storm’ aan updates in de cloud. De kracht van een ESXi-host die meerdere virtuele machines host, is mogelijk niet voldoende om het spervuur ​​van vergelijkbare taken die standaard worden uitgevoerd, aan te kunnen. Vanuit het perspectief van de cloudprovider kan een dergelijk probleem leiden tot extra belasting van een aantal ESXi-hosts, wat uiteindelijk zal leiden tot een daling van de prestaties van de virtuele cloudinfrastructuur. Dit kan onder meer de prestaties van virtuele machines van andere cloudclients beïnvloeden. Een soortgelijke situatie kan zich voordoen bij het starten van een massascan: gelijktijdige verwerking door het schijfsysteem van veel vergelijkbare verzoeken van verschillende gebruikers zal de prestaties van de hele cloud negatief beïnvloeden. Met een hoge mate van waarschijnlijkheid zal een afname van de prestaties van het opslagsysteem gevolgen hebben voor alle clients. Dergelijke abrupte belastingen bevallen noch de aanbieder, noch zijn klanten, omdat ze de “buren” in de cloud beïnvloeden. Vanuit dit oogpunt kan traditionele antivirus een groot probleem vormen.

Veilige quarantaine. Als een bestand of document dat mogelijk met een virus is geïnfecteerd, op het systeem wordt gedetecteerd, wordt het in quarantaine geplaatst. Uiteraard kan een geïnfecteerd bestand direct worden verwijderd, maar voor de meeste bedrijven is dit vaak niet acceptabel. Antivirussen voor bedrijven die niet zijn aangepast om in de cloud van de provider te werken, hebben in de regel een gemeenschappelijke quarantainezone: alle geïnfecteerde objecten vallen erin. Bijvoorbeeld die gevonden op de computers van bedrijfsgebruikers. Klanten van de cloudprovider “wonen” in hun eigen segmenten (of huurders). Deze segmenten zijn ondoorzichtig en geïsoleerd: klanten weten niets van elkaar en zien uiteraard niet wat anderen in de cloud hosten. Het is duidelijk dat de algemene quarantaine, waartoe alle antivirusgebruikers in de cloud toegang zullen hebben, potentieel een document kan omvatten dat vertrouwelijke informatie of een bedrijfsgeheim bevat. Dit is voor de aanbieder en zijn klanten onaanvaardbaar. Daarom kan er maar één oplossing zijn: persoonlijke quarantaine voor elke klant in zijn segment, waar noch de aanbieder, noch andere klanten toegang toe hebben.

Individueel veiligheidsbeleid. Elke klant in de cloud is een afzonderlijk bedrijf, waarvan de IT-afdeling haar eigen beveiligingsbeleid bepaalt. Beheerders definiëren bijvoorbeeld scanregels en plannen antivirusscans. Daarom moet elke organisatie over een eigen controlecentrum beschikken om het antivirusbeleid te configureren. Tegelijkertijd mogen de opgegeven instellingen geen invloed hebben op andere cloudclients en moet de provider kunnen verifiëren dat bijvoorbeeld antivirusupdates normaal worden uitgevoerd voor alle virtuele clientmachines.

Organisatie van facturatie en licentieverlening. Het cloudmodel wordt gekenmerkt door flexibiliteit en houdt in dat alleen wordt betaald voor de hoeveelheid IT-middelen die door de klant zijn gebruikt. Als er behoefte aan is, bijvoorbeeld vanwege seizoensinvloeden, kan de hoeveelheid hulpbronnen snel worden vergroot of verkleind - allemaal op basis van de huidige behoeften aan rekenkracht. Traditionele antivirus is niet zo flexibel: in de regel koopt de klant een licentie voor een jaar voor een vooraf bepaald aantal servers of werkstations. Cloudgebruikers ontkoppelen en verbinden regelmatig extra virtuele machines, afhankelijk van hun huidige behoeften. Daarom moeten antiviruslicenties hetzelfde model ondersteunen.

De tweede vraag is wat de licentie precies zal dekken. Traditionele antivirussoftware wordt gelicentieerd op basis van het aantal servers of werkstations. Licenties op basis van het aantal beveiligde virtuele machines passen niet geheel binnen het cloudmodel. De klant kan uit de beschikbare bronnen een willekeurig aantal virtuele machines creëren die voor hem geschikt zijn, bijvoorbeeld vijf of tien machines. Voor de meeste klanten is dit aantal niet constant; het is voor ons als aanbieder niet mogelijk om de wijzigingen te volgen. Er is geen technische mogelijkheid om licenties per CPU te verkrijgen: clients ontvangen virtuele processors (vCPU's), die voor licentieverlening moeten worden gebruikt. Het nieuwe antivirusbeschermingsmodel moet de klant dus de mogelijkheid bieden om het vereiste aantal vCPU's te bepalen waarvoor hij antiviruslicenties ontvangt.

Naleving van wetgeving. Een belangrijk punt, aangezien de gebruikte oplossingen ervoor moeten zorgen dat aan de eisen van de toezichthouder wordt voldaan. Cloud-‘bewoners’ werken bijvoorbeeld vaak met persoonlijke gegevens. In dit geval moet de aanbieder beschikken over een apart gecertificeerd cloudsegment dat volledig voldoet aan de eisen van de Wet Persoonsgegevens. Dan hoeven bedrijven niet zelf het hele systeem voor het werken met persoonsgegevens ‘te bouwen’: gecertificeerde apparatuur aanschaffen, aansluiten en configureren, en certificering ondergaan. Voor cyberbescherming van de ISPD van dergelijke klanten moet de antivirus bovendien voldoen aan de eisen van de Russische wetgeving en beschikken over een FSTEC-certificaat.

We hebben gekeken naar de verplichte criteria waaraan antivirusbescherming in de publieke cloud moet voldoen. Vervolgens zullen we onze eigen ervaringen delen met het aanpassen van een antivirusoplossing om in de cloud van de provider te werken.

Hoe kun je vrienden maken tussen antivirus en cloud?

Zoals onze ervaring leert is het kiezen van een oplossing op basis van beschrijving en documentatie één ding, maar het in de praktijk implementeren in een reeds werkende cloudomgeving is qua complexiteit een heel andere opgave. We vertellen je wat we in de praktijk hebben gedaan en hoe we de antivirus hebben aangepast om in de publieke cloud van de provider te werken. De leverancier van de antivirusoplossing was Kaspersky, wiens portfolio antivirusbeschermingsoplossingen voor cloudomgevingen omvat. We hebben gekozen voor “Kaspersky Security for Virtualization” (Light Agent).

Het bevat een enkele Kaspersky Security Center-console. Light agent- en beveiligingsvirtuele machines (SVM, Security Virtual Machine) en KSC-integratieserver.

Nadat we de architectuur van de Kaspersky-oplossing hadden bestudeerd en samen met de engineers van de leverancier de eerste tests hadden uitgevoerd, rees de vraag over het integreren van de dienst in de cloud. De eerste implementatie werd gezamenlijk uitgevoerd op de cloudsite in Moskou. En dat is wat wij ons realiseerden.

Om het netwerkverkeer te minimaliseren, werd besloten om op elke ESXi-host een SVM te plaatsen en de SVM aan de ESXi-hosts te ‘koppelen’. In dit geval hebben lichte agenten van beschermde virtuele machines toegang tot de SVM van de exacte ESXi-host waarop ze draaien. Voor het hoofd-KSC is een aparte administratieve huurder geselecteerd. Als gevolg hiervan bevinden zich ondergeschikte KSC's bij de huurders van elke individuele klant en richten zij zich op de hogere KSC's die zich in het managementsegment bevinden. Met deze regeling kunt u snel problemen oplossen die zich voordoen bij huurders van klanten.

Naast problemen met het verhogen van de componenten van de antivirusoplossing zelf, werden we geconfronteerd met de taak om netwerkinteractie te organiseren door het creëren van extra VxLAN's. En hoewel de oplossing oorspronkelijk bedoeld was voor zakelijke klanten met privéclouds, konden we met behulp van de technische kennis en technologische flexibiliteit van NSX Edge alle problemen oplossen die verband hielden met de scheiding van huurders en licenties.

We hebben nauw samengewerkt met de technici van Kaspersky. Bij het analyseren van de oplossingsarchitectuur in termen van netwerkinteractie tussen systeemcomponenten is dus gebleken dat naast toegang van light agents naar SVM ook feedback nodig is - van SVM naar light agents. Deze netwerkconnectiviteit is niet mogelijk in een multitenantomgeving vanwege de mogelijkheid van identieke netwerkinstellingen van virtuele machines in verschillende cloudtenants. Daarom hebben collega's van de leverancier op ons verzoek het mechanisme van netwerkinteractie tussen de light agent en SVM herwerkt in termen van het elimineren van de noodzaak voor netwerkconnectiviteit van SVM naar light agents.

Nadat de oplossing was geïmplementeerd en getest op de cloudsite in Moskou, hebben we deze gerepliceerd naar andere sites, waaronder het gecertificeerde cloudsegment. De service is nu beschikbaar in alle regio's van het land.

Architectuur van een informatiebeveiligingsoplossing in het kader van een nieuwe aanpak

Het algemene werkingsschema van een antivirusoplossing in een openbare cloudomgeving is als volgt:

Waarom traditionele antivirussen niet geschikt zijn voor publieke clouds. Dus wat moet ik doen?
Werkingsschema van een antivirusoplossing in een publieke cloudomgeving #CloudMTS

Laten we de kenmerken van de werking van individuele elementen van de oplossing in de cloud beschrijven:

• Eén enkele console waarmee klanten het beveiligingssysteem centraal kunnen beheren: scans uitvoeren, updates beheren en quarantainezones bewaken. Het is mogelijk om individueel beveiligingsbeleid binnen uw segment te configureren.

Opgemerkt moet worden dat wij, hoewel wij een dienstverlener zijn, ons niet bemoeien met de instellingen van klanten. Het enige dat we kunnen doen is het beveiligingsbeleid opnieuw instellen op het standaardbeleid als herconfiguratie nodig is. Dit kan bijvoorbeeld nodig zijn als de cliënt ze per ongeluk heeft aangedraaid of aanzienlijk heeft verzwakt. Een bedrijf kan altijd een controlecentrum met standaardbeleid ontvangen, dat het vervolgens onafhankelijk kan configureren. Het nadeel van Kaspersky Security Center is dat het platform momenteel alleen beschikbaar is voor het Microsoft-besturingssysteem. Hoewel lichtgewicht agenten met zowel Windows- als Linux-machines kunnen werken. Kaspersky Lab belooft echter dat KSC in de nabije toekomst onder Linux OS zal werken. Een van de belangrijke functies van KSC is de mogelijkheid om quarantaine te beheren. Elk klantbedrijf in onze cloud heeft een persoonlijk bedrijf. Deze aanpak elimineert situaties waarin een met een virus geïnfecteerd document per ongeluk publiekelijk zichtbaar wordt, zoals zou kunnen gebeuren in het geval van een klassiek bedrijfsantivirus met algemene quarantaine.

• Lichte middelen. Als onderdeel van het nieuwe model wordt op elke virtuele machine een lichtgewicht Kaspersky Security-agent geïnstalleerd. Dit elimineert de noodzaak om de antivirusdatabase op elke VM op te slaan, waardoor de benodigde hoeveelheid schijfruimte wordt verminderd. De dienst is geïntegreerd met de cloudinfrastructuur en werkt via SVM, waardoor de dichtheid van virtuele machines op de ESXi-host en de prestaties van het hele cloudsysteem toenemen. De light-agent bouwt voor elke virtuele machine een wachtrij met taken op: controleer het bestandssysteem, het geheugen, enz. Maar de SVM is verantwoordelijk voor het uitvoeren van deze operaties, waarover we later zullen praten. De agent functioneert ook als een firewall, controleert het beveiligingsbeleid, stuurt geïnfecteerde bestanden in quarantaine en bewaakt de algehele ‘gezondheid’ van het besturingssysteem waarop deze is geïnstalleerd. Dit alles kan worden beheerd met behulp van de reeds genoemde enkele console.

• Beveiliging virtuele machine. Alle resource-intensieve taken (updates van antivirusdatabases, geplande scans) worden afgehandeld door een afzonderlijke Security Virtual Machine (SVM). Ze is verantwoordelijk voor de werking van een volwaardige antivirusengine en de databases daarvoor. De IT-infrastructuur van een bedrijf kan meerdere SVM's omvatten. Deze aanpak verhoogt de betrouwbaarheid van het systeem: als een machine uitvalt en dertig seconden lang niet reageert, gaan agenten automatisch op zoek naar een andere.

• KSC-integratieserver. Een van de componenten van de hoofd-KSC, die zijn SVM's toewijst aan lichte agenten in overeenstemming met het algoritme dat is gespecificeerd in de instellingen, en ook de beschikbaarheid van SVM's controleert. Deze softwaremodule zorgt dus voor taakverdeling over alle SVM's van de cloudinfrastructuur.

Algoritme voor werken in de cloud: vermindering van de belasting van de infrastructuur

Over het algemeen kan het antivirusalgoritme als volgt worden weergegeven. De agent heeft toegang tot het bestand op de virtuele machine en controleert het. Het resultaat van de verificatie wordt opgeslagen in een gemeenschappelijke gecentraliseerde SVM-uitspraakdatabase (genaamd Shared Cache), waarbij elke invoer een uniek bestandsvoorbeeld identificeert. Met deze aanpak kunt u ervoor zorgen dat hetzelfde bestand niet meerdere keren achter elkaar wordt gescand (bijvoorbeeld als het op verschillende virtuele machines is geopend). Het bestand wordt alleen opnieuw gescand als er wijzigingen in zijn aangebracht of als de scan handmatig is gestart.

Waarom traditionele antivirussen niet geschikt zijn voor publieke clouds. Dus wat moet ik doen?
Implementatie van een antivirusoplossing in de cloud van de provider

De afbeelding toont een algemeen diagram van de implementatie van de oplossing in de cloud. Het belangrijkste Kaspersky Security Center wordt geïmplementeerd in de controlezone van de cloud, en een individuele SVM wordt geïmplementeerd op elke ESXi-host met behulp van de KSC-integratieserver (elke ESXi-host heeft zijn eigen SVM gekoppeld met speciale instellingen op VMware vCenter Server). Klanten werken in hun eigen cloudsegmenten, waar virtuele machines met agenten staan. Ze worden beheerd via individuele KSC-servers die ondergeschikt zijn aan de hoofd-KSC. Als het nodig is om een ​​klein aantal virtuele machines (maximaal 5) te beschermen, kan de client toegang krijgen tot de virtuele console van een speciale speciale KSC-server. Netwerkinteractie tussen client-KSC's en de hoofd-KSC, evenals light agents en SVM's, wordt uitgevoerd met behulp van NAT via EdgeGW-client virtuele routers.

Volgens onze schattingen en de resultaten van tests van collega's bij de leverancier vermindert Light Agent de belasting van de virtuele infrastructuur van klanten met ongeveer 25% (vergeleken met een systeem dat traditionele antivirussoftware gebruikt). Met name de standaard Kaspersky Endpoint Security (KES)-antivirus voor fysieke omgevingen verbruikt bijna twee keer zoveel server-CPU-tijd (2,95%) als een lichtgewicht agent-gebaseerde virtualisatie-oplossing (1,67%).

Waarom traditionele antivirussen niet geschikt zijn voor publieke clouds. Dus wat moet ik doen?
Vergelijkingstabel CPU-belasting

Een soortgelijke situatie wordt waargenomen met de frequentie van schijfschrijftoegangen: voor een klassieke antivirus is dit 1011 IOPS, voor een cloud-antivirus is dit 671 IOPS.

Waarom traditionele antivirussen niet geschikt zijn voor publieke clouds. Dus wat moet ik doen?
Vergelijkingsgrafiek voor schijftoegangssnelheid

Dankzij het prestatievoordeel kunt u de stabiliteit van de infrastructuur behouden en de rekenkracht efficiënter gebruiken. Door zich aan te passen aan het werken in een openbare cloudomgeving, vermindert de oplossing de cloudprestaties niet: het controleert centraal bestanden en downloadt updates, waardoor de belasting wordt verdeeld. Dit betekent dat enerzijds bedreigingen die relevant zijn voor de cloudinfrastructuur niet zullen worden gemist, anderzijds de resourcevereisten voor virtuele machines met gemiddeld 25% zullen worden verminderd in vergelijking met een traditioneel antivirusprogramma.

Qua functionaliteit lijken beide oplossingen erg op elkaar: hieronder staat een vergelijkingstabel. In de cloud is het echter, zoals de bovenstaande testresultaten laten zien, nog steeds optimaal om een ​​oplossing voor virtuele omgevingen te gebruiken.

Waarom traditionele antivirussen niet geschikt zijn voor publieke clouds. Dus wat moet ik doen?

Over tarieven in het kader van de nieuwe aanpak. We hebben besloten een model te gebruiken waarmee we licenties kunnen verkrijgen op basis van het aantal vCPU's. Dit betekent dat het aantal licenties gelijk is aan het aantal vCPU's. U kunt uw antivirus testen door een verzoek achter te laten online.

In het volgende artikel over cloudonderwerpen zullen we het hebben over de evolutie van cloud-WAF's en wat beter is om te kiezen: hardware, software of cloud.

De tekst is opgesteld door medewerkers van cloudprovider #CloudMTS: Denis Myagkov, toonaangevend architect en Alexey Afanasyev, productontwikkelingsmanager informatiebeveiliging.

Bron: www.habr.com

Voeg een reactie