Fler och fler användare tar med hela sin IT-infrastruktur till det offentliga molnet. Men om antiviruskontrollen är otillräcklig i kundens infrastruktur uppstår allvarliga cyberrisker. Praxis visar att upp till 80 % av befintliga virus lever perfekt i en virtuell miljö. I det här inlägget kommer vi att prata om hur man skyddar IT-resurser i det offentliga molnet och varför traditionella antivirus inte är helt lämpliga för dessa ändamål.
Till att börja med kommer vi att berätta hur vi kom till idén att de vanliga antivirusskyddsverktygen inte är lämpliga för det offentliga molnet och att andra metoder för att skydda resurser krävs.
För det första tillhandahåller leverantörer i allmänhet nödvändiga åtgärder för att säkerställa att deras molnplattformar skyddas på en hög nivå. Till exempel, på #CloudMTS analyserar vi all nätverkstrafik, övervakar loggar av vårt molns säkerhetssystem och utför regelbundet pentester. Molnsegment som allokeras till enskilda klienter måste också vara säkert skyddade.
För det andra innebär det klassiska alternativet för att bekämpa cyberrisker att installera ett antivirus- och antivirushanteringsverktyg på varje virtuell maskin. Men med ett stort antal virtuella maskiner kan denna praxis vara ineffektiv och kräva betydande mängder datorresurser, vilket ytterligare laddar kundens infrastruktur och minskar molnets övergripande prestanda. Detta har blivit en nyckelförutsättning för att söka efter nya metoder för att bygga ett effektivt antivirusskydd för kunders virtuella maskiner.
Dessutom är de flesta antiviruslösningar på marknaden inte anpassade för att lösa problemen med att skydda IT-resurser i en offentlig molnmiljö. Som regel är det tunga EPP-lösningar (Endpoint Protection Platforms), som dessutom inte ger den nödvändiga anpassningen på klientsidan hos molnleverantören.
Det blir uppenbart att traditionella antiviruslösningar är dåligt lämpade för att arbeta i molnet, eftersom de på allvar laddar den virtuella infrastrukturen under uppdateringar och skanningar, och dessutom inte har de nödvändiga nivåerna av rollbaserad hantering och inställningar. Därefter kommer vi att analysera i detalj varför molnet behöver nya tillvägagångssätt för antivirusskydd.
Vad ett antivirus i ett offentligt moln borde kunna göra
Så låt oss vara uppmärksamma på detaljerna för att arbeta i en virtuell miljö:
Effektivitet av uppdateringar och schemalagda massskanningar. Om ett betydande antal virtuella maskiner som använder ett traditionellt antivirus initierar en uppdatering samtidigt, kommer en så kallad "storm" av uppdateringar att inträffa i molnet. Kraften hos en ESXi-värd som är värd för flera virtuella maskiner kanske inte räcker för att hantera mängden liknande uppgifter som körs som standard. Ur molnleverantörens synvinkel kan ett sådant problem leda till ytterligare belastningar på ett antal ESXi-värdar, vilket i slutändan kommer att leda till en nedgång i prestandan för den virtuella molninfrastrukturen. Detta kan bland annat påverka prestandan hos andra molnklienters virtuella maskiner. En liknande situation kan uppstå när man startar en masssökning: samtidig bearbetning av disksystemet av många liknande förfrågningar från olika användare kommer att påverka prestandan för hela molnet negativt. Med en hög grad av sannolikhet kommer en minskning av lagringssystemets prestanda att påverka alla klienter. Sådana plötsliga belastningar behagar varken leverantören eller hans kunder, eftersom de påverkar "grannarna" i molnet. Ur denna synvinkel kan traditionellt antivirus utgöra ett stort problem.
Säker karantän. Om en fil eller ett dokument som potentiellt är infekterat med ett virus upptäcks i systemet, skickas det till karantän. Naturligtvis kan en infekterad fil raderas omedelbart, men det är ofta inte acceptabelt för de flesta företag. Företagsantivirus som inte är anpassade för att fungera i leverantörens moln har som regel en gemensam karantänzon - alla infekterade objekt hamnar i den. Till exempel de som finns på företagsanvändares datorer. Klienter till molnleverantören "bor" i sina egna segment (eller hyresgäster). Dessa segment är ogenomskinliga och isolerade: klienter känner inte till varandra och ser naturligtvis inte vad andra har i molnet. Uppenbarligen kan den allmänna karantänen, som kommer att nås av alla antivirusanvändare i molnet, potentiellt innehålla ett dokument som innehåller konfidentiell information eller en affärshemlighet. Detta är oacceptabelt för leverantören och dess kunder. Därför kan det bara finnas en lösning - personlig karantän för varje kund i sitt segment, där varken leverantören eller andra kunder har tillgång.
Individuella säkerhetspolicyer. Varje klient i molnet är ett separat företag, vars IT-avdelning sätter sina egna säkerhetspolicyer. Till exempel definierar administratörer skanningsregler och schemalägger antivirusgenomsökningar. Följaktligen måste varje organisation ha sitt eget kontrollcenter för att konfigurera antiviruspolicyer. Samtidigt ska de angivna inställningarna inte påverka andra molnklienter och leverantören ska kunna verifiera att till exempel antivirusuppdateringar utförs som normalt för alla virtuella klientmaskiner.
Organisation av fakturering och licensiering. Molnmodellen kännetecknas av flexibilitet och innebär att endast betala för mängden IT-resurser som användes av kunden. Om det finns ett behov, till exempel på grund av säsongsvariationer, kan mängden resurser snabbt ökas eller minskas – allt baserat på nuvarande behov av datorkraft. Traditionellt antivirus är inte så flexibelt - som regel köper klienten en licens för ett år för ett förutbestämt antal servrar eller arbetsstationer. Molnanvändare kopplar regelbundet bort och ansluter ytterligare virtuella maskiner beroende på deras aktuella behov - därför måste antiviruslicenser stödja samma modell.
Den andra frågan är vad licensen exakt kommer att omfatta. Traditionellt antivirus licensieras av antalet servrar eller arbetsstationer. Licenser baserade på antalet skyddade virtuella maskiner är inte helt lämpliga inom molnmodellen. Klienten kan skapa valfritt antal virtuella maskiner som är lämpliga för honom från de tillgängliga resurserna, till exempel fem eller tio maskiner. Detta antal är inte konstant för de flesta kunder, det är inte möjligt för oss, som leverantör, att spåra dess förändringar. Det finns ingen teknisk möjlighet att licensiera med CPU: klienter får virtuella processorer (vCPU) som ska användas för licensiering. Därför bör den nya antivirusskyddsmodellen inkludera möjligheten för kunden att bestämma det erforderliga antalet vCPU:er som han kommer att få antiviruslicenser för.
Efterlevnad av lagstiftning. En viktig punkt, eftersom de lösningar som används måste säkerställa överensstämmelse med regulatorns krav. Till exempel arbetar molninvånare ofta med personuppgifter. I det här fallet måste leverantören ha ett separat certifierat molnsegment som helt uppfyller kraven i personuppgiftslagen. Då behöver inte företagen självständigt "bygga" hela systemet för att arbeta med personuppgifter: köpa certifierad utrustning, ansluta och konfigurera den och genomgå certifiering. För cyberskydd av ISPD för sådana klienter måste antiviruset också uppfylla kraven i rysk lagstiftning och ha ett FSTEC-certifikat.
Vi tittade på de obligatoriska kriterierna som antivirusskydd i det offentliga molnet måste uppfylla. Därefter kommer vi att dela med oss av vår egen erfarenhet av att anpassa en antiviruslösning för att fungera i leverantörens moln.
Hur kan du få vänner mellan antivirus och moln?
Som vår erfarenhet har visat är att välja en lösning utifrån beskrivning och dokumentation en sak, men att implementera den i praktiken i en redan fungerande molnmiljö är en helt annan uppgift vad gäller komplexitet. Vi berättar vad vi gjorde i praktiken och hur vi anpassade antiviruset för att fungera i leverantörens publika moln. Säljaren av antiviruslösningen var Kaspersky, vars portfölj inkluderar antivirusskyddslösningar för molnmiljöer. Vi bestämde oss för "Kaspersky Security for Virtualization" (Light Agent).
Den innehåller en enda Kaspersky Security Center-konsol. Lätt agent och virtuella säkerhetsmaskiner (SVM, Security Virtual Machine) och KSC integrationsserver.
Efter att vi studerat arkitekturen för Kaspersky-lösningen och genomfört de första testerna tillsammans med leverantörens ingenjörer, uppstod frågan om att integrera tjänsten i molnet. Den första implementeringen genomfördes gemensamt på molnplatsen i Moskva. Och det var vad vi insåg.
För att minimera nätverkstrafiken beslutades att placera en SVM på varje ESXi-värd och "knyta" SVM till ESXi-värdarna. I det här fallet får lätta agenter för skyddade virtuella maskiner åtkomst till SVM för den exakta ESXi-värd som de körs på. En separat administrativ hyresgäst valdes ut för huvud-KSC. Som ett resultat av detta finns underordnade KSC:er i hyresgästerna hos varje enskild kund och adresserar den överordnade KSC som finns i förvaltningssegmentet. Detta schema låter dig snabbt lösa problem som uppstår hos klienthyresgäster.
Förutom problem med att höja komponenterna i själva antiviruslösningen, stod vi inför uppgiften att organisera nätverksinteraktion genom att skapa ytterligare VxLAN. Och även om lösningen ursprungligen var avsedd för företagskunder med privata moln, kunde vi med hjälp av den tekniska kunniga och tekniska flexibiliteten hos NSX Edge lösa alla problem i samband med separation av hyresgäster och licensiering.
Vi arbetade nära med Kasperskys ingenjörer. I processen med att analysera lösningsarkitekturen när det gäller nätverksinteraktion mellan systemkomponenter fann man att förutom åtkomst från ljusagenter till SVM också återkoppling är nödvändig - från SVM till ljusagenter. Denna nätverksanslutning är inte möjlig i en multitenant-miljö på grund av möjligheten till identiska nätverksinställningar för virtuella maskiner i olika molnhyresgäster. Därför, på vår begäran, omarbetade kollegor från leverantören mekanismen för nätverksinteraktion mellan ljusagenten och SVM i termer av att eliminera behovet av nätverksanslutning från SVM till ljusagenter.
Efter att lösningen distribuerats och testats på Moskvas molnsajt, replikerade vi den till andra sajter, inklusive det certifierade molnsegmentet. Tjänsten är nu tillgänglig i alla regioner i landet.
Arkitektur av en informationssäkerhetslösning inom ramen för ett nytt tillvägagångssätt
Det allmänna schemat för drift av en antiviruslösning i en offentlig molnmiljö är som följer:
Driftschema för en antiviruslösning i en offentlig molnmiljö #CloudMTS
Låt oss beskriva funktionerna i driften av enskilda delar av lösningen i molnet:
• En enda konsol som tillåter klienter att centralt hantera skyddssystemet: köra skanningar, kontrollera uppdateringar och övervaka karantänszoner. Det är möjligt att konfigurera individuella säkerhetspolicyer inom ditt segment.
Det bör noteras att även om vi är en tjänsteleverantör stör vi inte inställningarna som ställts in av klienter. Det enda vi kan göra är att återställa säkerhetspolicyerna till standard om omkonfigurering är nödvändig. Detta kan till exempel vara nödvändigt om klienten av misstag dragit åt dem eller avsevärt försvagat dem. Ett företag kan alltid få ett kontrollcenter med standardpolicyer, som det sedan kan konfigurera självständigt. Nackdelen med Kaspersky Security Center är att plattformen för närvarande endast är tillgänglig för Microsofts operativsystem. Även om lättviktsagenter kan fungera med både Windows- och Linux-maskiner. Kaspersky Lab lovar dock att KSC inom en snar framtid kommer att fungera under Linux OS. En av KSCs viktiga funktioner är förmågan att hantera karantän. Varje kundföretag i vårt moln har ett personligt företag. Detta tillvägagångssätt eliminerar situationer där ett dokument som är infekterat med ett virus av misstag blir offentligt synligt, vilket kan hända i fallet med ett klassiskt företagsantivirus med allmän karantän.
• Ljusmedel. Som en del av den nya modellen installeras en lätt Kaspersky Security-agent på varje virtuell maskin. Detta eliminerar behovet av att lagra antivirusdatabasen på varje virtuell dator, vilket minskar mängden diskutrymme som krävs. Tjänsten är integrerad med molninfrastrukturen och fungerar genom SVM, vilket ökar tätheten av virtuella maskiner på ESXi-värden och prestandan för hela molnsystemet. Ljusagenten bygger en kö av uppgifter för varje virtuell maskin: kontrollera filsystemet, minnet etc. Men SVM är ansvarig för att utföra dessa operationer, som vi kommer att prata om senare. Agenten fungerar också som en brandvägg, kontrollerar säkerhetspolicyer, skickar infekterade filer till karantän och övervakar den övergripande "hälsan" för operativsystemet som den är installerad på. Allt detta kan hanteras med den redan nämnda enda konsolen.
• Säkerhet virtuell maskin. Alla resurskrävande uppgifter (antivirusdatabasuppdateringar, schemalagda genomsökningar) hanteras av en separat Security Virtual Machine (SVM). Hon ansvarar för driften av en fullfjädrad antivirusmotor och databaser för den. Ett företags IT-infrastruktur kan innehålla flera SVM. Detta tillvägagångssätt ökar systemets tillförlitlighet - om en maskin misslyckas och inte svarar på trettio sekunder börjar agenter automatiskt leta efter en annan.
• KSC integrationsserver. En av komponenterna i huvud-KSC, som tilldelar sina SVM:er till ljusagenter i enlighet med den algoritm som anges i dess inställningar, och kontrollerar även tillgängligheten av SVM:er. Således ger denna mjukvarumodul lastbalansering över alla SVM:er i molninfrastrukturen.
Algoritm för att arbeta i molnet: minska belastningen på infrastrukturen
I allmänhet kan antivirusalgoritmen representeras enligt följande. Agenten kommer åt filen på den virtuella maskinen och kontrollerar den. Resultatet av verifieringen lagras i en gemensam centraliserad SVM domdatabas (kallad Shared Cache), där varje post identifierar ett unikt filexempel. Detta tillvägagångssätt låter dig säkerställa att samma fil inte skannas flera gånger i rad (till exempel om den öppnades på olika virtuella maskiner). Filen skannas om endast om ändringar har gjorts i den eller skanningen har startats manuellt.
Implementering av en antiviruslösning i leverantörens moln
Bilden visar ett allmänt diagram över lösningsimplementeringen i molnet. Kasperskys huvudsäkerhetscenter distribueras i molnets kontrollzon, och en individuell SVM distribueras på varje ESXi-värd med hjälp av KSC-integreringsservern (varje ESXi-värd har sin egen SVM kopplad med speciella inställningar på VMware vCenter Server). Klienter arbetar i sina egna molnsegment, där virtuella maskiner med agenter finns. De hanteras genom individuella KSC-servrar som är underordnade huvud-KSC. Om det är nödvändigt att skydda ett litet antal virtuella maskiner (upp till 5), kan klienten ges åtkomst till den virtuella konsolen för en speciell dedikerad KSC-server. Nätverksinteraktion mellan klient-KSC:er och huvud-KSC:er, såväl som lätta agenter och SVM:er, utförs med hjälp av NAT genom EdgeGW-klientvirtuella routrar.
Enligt våra uppskattningar och resultaten av tester av kollegor hos leverantören, minskar Light Agent belastningen på klienternas virtuella infrastruktur med cirka 25 % (jämfört med ett system som använder traditionell antivirusprogramvara). I synnerhet förbrukar standard Kaspersky Endpoint Security (KES) antivirus för fysiska miljöer nästan dubbelt så mycket server-CPU-tid (2,95 %) som en lätt agentbaserad virtualiseringslösning (1,67 %).
Jämförelsediagram för CPU-belastning
En liknande situation observeras med frekvensen av diskskrivåtkomst: för ett klassiskt antivirus är det 1011 IOPS, för ett molnantivirus är det 671 IOPS.
Jämförelsediagram för diskåtkomsthastighet
Prestandafördelen gör att du kan upprätthålla infrastrukturens stabilitet och använda datorkraft mer effektivt. Genom att anpassa sig för att fungera i en offentlig molnmiljö minskar inte lösningen molnprestanda: den kontrollerar filer centralt och laddar ner uppdateringar, fördelar belastningen. Det innebär att å ena sidan hot som är relevanta för molninfrastrukturen inte kommer att missas, å andra sidan kommer resurskraven för virtuella maskiner att minska med i genomsnitt 25 % jämfört med ett traditionellt antivirus.
När det gäller funktionalitet är båda lösningarna väldigt lika varandra: nedan är en jämförelsetabell. I molnet är det dock, som testresultaten ovan visar, fortfarande optimalt att använda en lösning för virtuella miljöer.
Om taxor inom ramen för det nya upplägget. Vi bestämde oss för att använda en modell som tillåter oss att erhålla licenser baserat på antalet vCPU:er. Detta innebär att antalet licenser kommer att vara lika med antalet vCPU:er. Du kan testa ditt antivirus genom att lämna en begäran .
I nästa artikel om molnämnen kommer vi att prata om utvecklingen av moln-WAF och vad som är bättre att välja: hårdvara, mjukvara eller moln.
Texten utarbetades av anställda hos molnleverantören #CloudMTS: Denis Myagkov, ledande arkitekt och Alexey Afanasyev, produktutvecklingschef för informationssäkerhet.
Källa: will.com