Din ce în ce mai mulți utilizatori își transferă întreaga infrastructură IT în cloud-ul public. Totuși, în cazul în care controlul antivirus în infrastructura clientului este insuficient, apar riscuri cibernetice serioase. Practica arată că până la 80% din virusurile existente se descurcă de minune în medii virtuale. În această postare, vom discuta despre cum să ne protejăm resursele IT în cloud-ul public și de ce soluțiile antivirus tradiționale nu sunt întotdeauna adecvate pentru aceste scopuri.
În primul rând, vom explica cum am ajuns la concluzia că instrumentele tradiționale de protecție antivirus nu sunt potrivite pentru cloud-ul public și că sunt necesare alte abordări pentru a proteja resursele.
În primul rând, în general, furnizorii oferă măsurile necesare pentru a garanta protecția platformelor lor cloud la un nivel înalt. De exemplu, noi, la #CloudMTS, analizăm întregul trafic de rețea, monitorizăm jurnalele sistemelor de securitate ale cloud-ului nostru și derulăm regulat teste de penetrare. Segmentele de cloud, alocate clienților individuali, trebuie, de asemenea, să fie protejate eficient.
În al doilea rând, varianta clasică de combatere a riscurilor cibernetice implică instalarea antivirusului și a instrumentelor de gestionare pe fiecare mașină virtuală. Totuși, în cazul unui număr mare de mașini virtuale, această practică poate fi ineficientă și poate necesita resurse computaționale semnificative, suprasolicitând astfel infrastructura clientului și reducând performanța generală a cloud-ului. Aceasta a devenit o premisă esențială pentru căutarea de noi abordări pentru construirea unei protecții antivirus eficiente pentru mașinile virtuale ale clienților.
În plus, majoritatea soluțiilor antivirus disponibile pe piață nu sunt adaptate pentru a răspunde cerințelor de protecție a resurselor IT în medii cloud publice. De regulă, acestea sunt soluții EPP (Endpoint Protection Platforms) greu de gestionat, care, în plus, nu oferă posibilitățile de personalizare necesare din partea clienților furnizorului de cloud.
Devine că soluțiile antivirus tradiționale nu sunt potrivite pentru lucrul în cloud, deoarece acestea suprasolicită serios infrastructura virtuală în timpul actualizărilor și scanărilor și nu dispun de nivelurile necesare de control al rolurilor și setărilor. În continuare, vom analiza în detaliu motivele pentru care cloud-ul are nevoie de noi abordări în protecția antivirus.
Ce trebuie să știe un antivirus în cloud-ul public
Deci, să ne concentrăm asupra specificului lucrului în medii virtuale:
Eficiența efectuării actualizărilor și verificărilor masive programate. Dacă un număr semnificativ de mașini virtuale care folosesc un antivirus tradițional inițiază simultan o actualizare, în cloud va avea loc așa-zisul „furtună” de actualizări. Capacitatea gazdelor ESXi pe care sunt găzduite mai multe mașini virtuale poate să nu fie suficientă pentru a gestiona fluxul de sarcini similare, lansate implicit. Din perspectiva furnizorului de cloud, o astfel de problemă poate duce la încărcări suplimentare pe un număr întreg de gazde ESXi, ceea ce în cele din urmă va duce la scăderea performanței infrastructurii virtuale a cloud-ului. Aceasta poate afecta, de asemenea, performanța mașinilor virtuale ale altor clienți ai cloud-ului. O situație similară poate apărea atunci când se lansează o scanare masivă: procesarea simultană a unui număr mare de cereri similare de către diferiți utilizatori va afecta negativ performanța întregului cloud. Este foarte probabil ca scăderea performanței sistemului de stocare să afecteze toți clienții. Astfel de încărcări bruște nu bucură nici furnizorul, nici clienții săi, deoarece influențează „vecinii” în cloud. Din acest punct de vedere, antivirusul tradițional poate reprezenta o problemă considerabilă.
Carantină sigură. Dacă în sistem este detectat un fișier sau document care ar putea fi infectat cu un virus, acesta este trimis în carantină. Desigur, fișierul infectat poate fi șters imediat, dar aceasta nu este adesea acceptabilă pentru majoritatea companiilor. Antivirusurile enterprise corporative, care nu sunt adaptate pentru a funcționa în cloud-ul furnizorului, au, de obicei, o zonă de carantină comună — în care ajung toate obiectele infectate. De exemplu, cele detectate pe computerele utilizatorilor din companie. Clienții furnizorului de cloud „trăiesc” în segmente proprii (sau în teneo). Aceste segmente sunt opace și izolate: clienții nu știu unii despre alții și, desigur, nu văd ce plasează în cloud alții. Este evident că în carantina comună, la care vor avea acces toți utilizatorii antivirusului în cloud, poate ajunge un document care conține informații confidențiale sau secrete comerciale. Acest lucru este inacceptabil pentru furnizor și clienții săi. Prin urmare, soluția poate fi doar una – un sistem personal de carantină pentru fiecare client în segmentul său, la care nu are acces nici furnizorul, nici ceilalți clienți.
Politicile de securitate individuale. Fiecare client din cloud este o companie separată a cărei departament IT stabilește politicile sale de securitate. De exemplu, administratorii stabilesc regulile de scanare și programul verificărilor antivirus. În consecință, fiecare organizație trebuie să aibă propriul său centru de gestionare pentru configurarea politicilor antivirus. În același timp, setările stabilite nu trebuie să afecteze ceilalți clienți ai cloud-ului, iar furnizorul trebuie să aibă posibilitatea de a se asigura că, de exemplu, actualizările antivirus se desfășoară normal pentru toate mașinile virtuale ale clientului.
Organizarea facturării și licențierea. Modelul cloud se caracterizează prin flexibilitate și presupune plata doar pentru volumul de resurse IT utilizat de client. Dacă este necesar, de exemplu, din cauza factorului sezonal, volumul resurselor poate fi crescut sau redus rapid — totul în funcție de nevoile curente în materie de putere de calcul. Antivirusul tradițional nu este atât de flexibil — de obicei, clientul achiziționează o licență pe un an pentru un număr prestabilit. servere sau stații de lucru. Utilizatorii din cloud de obicei deconectează și conectează mașini virtuale suplimentare în funcție de nevoile lor actuale — prin urmare, licențele antivirus trebuie să susțină aceeași model.
A doua întrebare se referă la ceea ce va acoperi exact licența. Antivirusul tradițional este licențiat în funcție de numărul de servere sau stații de lucru. Licențele pe baza numărului de mașini virtuale protejate nu se potrivesc prea bine în cadrul modelului de cloud. Clientul poate crea orice număr de mașini virtuale convenabil din resursele disponibile, de exemplu, cinci sau zece mașini. Acest număr nu este constant pentru cei mai mulți clienți, iar urmărirea modificărilor acestuia nu este posibilă pentru noi, ca furnizor. Licențierea pe CPU nu este o opțiune tehnică: clienții primesc procesoare virtuale (vCPU), pe baza căror ar trebui să se facă licențierea. Astfel, noul model de protecție antivirus ar trebui să presupună capacitatea clientului de a determina numărul necesar de vCPU pentru care va obține licențele antivirus.
Conformitatea cu legislația. Este un punct important, deoarece soluțiile aplicate trebuie să asigure respectarea cerințelor regulatorului. De exemplu, adesea 'rezidenții' din cloud lucrează cu date personale. În acest caz, furnizorul trebuie să dispună de un segment de cloud certificat, care să respecte pe deplin cerințele legei 'Privind datele personale'. Astfel, companiile nu trebuie să 'construiască' singure întregul sistem pentru a lucra cu datele personale: să achiziționeze echipamente certificate, să le conecteze și să le configureze, să treacă prin certificare. Pentru protecția cibernetică a sistemelor informatice de date personale ale acestor clienți, antivirusul trebuie de asemenea să respecte cerințele legislației rusești și să aibă certificat FSTEC.
Am analizat criteriile obligatorii pe care trebuie să le îndeplinească protecția antivirus în cloud-ul public. În continuare, vom împărtăși propria noastră experiență în adaptarea soluției antivirus pentru a funcționa în cloud-ul furnizorului.
Cum putem integra antivirusul cu cloud-ul
Așa cum a arătat experiența noastră, a alege o soluție în funcție de descriere și documentație este un lucru, iar a o implementa în practică într-un mediu cloud deja funcțional este cu totul altă sarcină ca nivel de complexitate. Vă vom povesti ce am realizat în practică și cum am adaptat antivirusul pentru a funcționa în cloudul public al furnizorului. Vendorul soluției antivirus a fost Kaspersky, care are în portofoliu soluții pentru protecția antivirus în medii cloud. Ne-am oprit la „Kaspersky Security pentru medii virtuale” (Agent ușor).
Acesta include o consolă unificată Kaspersky Security Center. Agentul ușor și mașinile virtuale de securitate (SVM, Security Virtual Machine) și serverul de integrare KSC.
După ce am studiat arhitectura soluției Kaspersky și am efectuat primele teste împreună cu inginerii vendorului, s-a pus problema integrării serviciului în cloud. Prima implementare a fost realizată prin eforturi comune pe platforma cloud din Moscova. Și iată ce am înțeles.
Pentru a minimiza traficul de rețea, s-a decis ca pe fiecare gazdă ESXi să fie amplasat SVM și să fie „legat” SVM-urile de gazdele ESXi. Astfel, agenții ușori ai mașinilor virtuale protejate se conectează la SVM-ul exact al gazdei ESXi pe care sunt rulate. Pentru KSC principal a fost ales un tenant administrativ separat. Ca rezultat, KSC-urile subordonate se află în tenantii fiecărui client și se conectează la KSC-ul superior, situat în segmentul de management. Această schemă permite rezolvarea rapidă a problemelor care apar în tenantii clienților.
Pe lângă problemele legate de ridicarea componentelor soluției antivirus, ne-am confruntat cu sarcina de a organiza interacțiunea de rețea prin crearea de VxLAN suplimentare. Și deși soluția a fost inițial destinată clienților enterprise cu clouduri private — cu ajutorul ingeniozității inginerilor și flexibilității tehnologice a NSX Edge, am reușit să rezolvăm toate sarcinile legate de separarea tenantilor și licențiere.
Am colaborat strâns cu inginerii Kaspersky. Astfel, în procesul de analiză a arhitecturii soluției în ceea ce privește interacțiunea de rețea între componentele sistemului, s-a stabilit că, pe lângă accesul din partea agenților ușori la SVM, este necesară și o comunicare înapoi – de la SVM la agenții ușori. Această conectivitate de rețea este imposibilă într-un mediu multitenant, având în vedere posibilitatea existenței unor setări de rețea identice pentru mașinile virtuale în diferite tenanțe ale cloud-ului. Prin urmare, la cererea noastră, colegii din partea furnizorului au reproiectat mecanismul de interacțiune de rețea între agentul ușor și SVM, în ceea ce privește eliminarea necesității conectivității de rețea de la SVM la agenții ușori.
După ce soluția a fost implementată și testată pe platforma din Moscova a cloud-ului, am replicat-o pe celelalte platforme, inclusiv segmentul certificat al cloud-ului. Acum, serviciul este disponibil în toate regiunile țării.
Arhitectura soluției de securitate informațională în cadrul noului concept
Schema generală de funcționare a soluției de antivirus într-un mediu cloud public arată astfel:
Schema de funcționare a soluției de antivirus într-un mediu cloud public #CloudMTS
Să descriem caracteristicile de funcționare ale unor elemente ale soluției în cloud:
• Consolă unificată, care le permite clienților să gestioneze centralizat sistemul de protecție: să inițieze verificări, să monitorizeze actualizările și să observe zonele de carantină. Există posibilitatea de a configura politici individuale de securitate în cadrul segmentului său.
Trebuie menționat că, deși suntem furnizori de servicii, nu intervenim în setările stabilite de clienți. Singurul lucru pe care îl putem face este să resetăm politicile de securitate la cele standard, dacă este necesară o reconfigurare. De exemplu, acest lucru poate fi necesar dacă clientul le-a întărit din greșeală sau le-a slăbit semnificativ. Compania poate obține întotdeauna un centru de gestionare cu politicile implicite, pe care apoi îl poate ajusta singură. Un dezavantaj al Kaspersky Security Center este că, deocamdată, platforma este disponibilă doar pentru sistemul de operare Microsoft. Cu toate acestea, agenții ușori pot funcționa atât cu mașini Windows, cât și cu Linux. Totuși, la „Laboratorul Kaspersky” promit că în curând KSC va funcționa și pe sistemul de operare Linux. Una dintre funcțiile importante ale KSC este capacitatea de gestionare a carantinei. Fiecare companie-client din norul nostru are carantina sa personală. Această abordare exclude situațiile în care un document infectat cu un virus ajunge accidental la dispoziția tuturor, așa cum s-ar putea întâmpla în cazul unui antivirus corporativ clasic cu carantină comună.
• Agenții ușori. În cadrul noului model, pe fiecare mașină virtuală se instalează un agent ușor Kaspersky Security. Acest lucru permite evitarea stocării bazei de date antivirus pe fiecare VM, reducând astfel volumul de spațiu pe disc ocupat. Serviciul este integrat cu infrastructura cloud și funcționează prin SVM, ceea ce îmbunătățește densitatea mașinilor virtuale pe gazda ESXi și performanța întregului sistem cloud. Agentul ușor construiește o coadă de sarcini pentru fiecare mașină virtuală: verificarea sistemului de fișiere, memorie etc. Însă, pentru îndeplinirea acestor operațiuni răspunde deja SVM, despre care vom vorbi mai departe. De asemenea, agentul îndeplinește funcții de firewall, controlează politicile de securitate, trimite fișierele infectate în carantină și monitorizează „sănătatea” generală a sistemului de operare pe care este instalat. Toate acestea pot fi gestionate prin consola unificată menționată anterior.
• Mașina virtuală de securitate. Toate sarcinile consumatoare de resurse (actualizările bazelor de date antivirus, verificările programate) sunt gestionate de o Mașină Virtuală de Securitate (SVM) separată. Aceasta se ocupă de funcționarea motorului antivirus complet și a bazelor aferente. Infrastructura IT a companiei poate include mai multe SVM. Această abordare crește fiabilitatea sistemului: dacă o mașină eșuează și nu răspunde timp de treizeci de secunde, agenții încep automat să caute alta.
• Serverul de integrare KSC. Una dintre componentele principale ale KSC, care alocă agenților săi SVM conform algoritmului stabilit în setările sale, precum și monitorizează disponibilitatea SVM. Astfel, acest modul software asigură echilibrarea încărcării pe toate SVM-urile infrastructurii cloud.
Algoritmul de lucru în cloud: reducerea sarcinii asupra infrastructurii
În general, algoritmul de lucru al antivirusului poate fi reprezentat astfel. Agentul accesează un fișier de pe mașina virtuală și îl verifică. Rezultatul verificării este salvat într-o bază centralizată de verdicturi SVM (numită Shared Cache), fiecare înregistrare identificând un exemplu unic de fișier. Această abordare permite monitorizarea pentru a evita verificarea aceluiași fișier de mai multe ori consecutiv (de exemplu, dacă este deschis pe diferite mașini virtuale). Fișierul este scannează din nou doar dacă au fost efectuate modificări sau verificarea a fost inițiată manual.
Implementarea soluției antivirus în cloud-ul furnizorului
Imaginea de mai sus ilustrează schema generală de implementare a soluției în cloud. În zona de gestionare a cloud-ului este desfășurat principalul Kaspersky Security Center, iar pe fiecare gazdă ESXi, prin serverul de integrare KSC, este desfășurată o SVM individuală (fiecare gazdă ESXi are o SVM asociată prin setări speciale în VMware vCenter Server). Clienții operează în segmentele lor de cloud, unde sunt găzduite mașini virtuale cu agenți. Acestea sunt gestionate prin servere KSC individuale, subordonate principalului KSC. În cazul în care este necesară protecția unui număr mic de mașini virtuale (până la 5), clientului i se poate oferi acces la consola virtuală a unui server KSC dedicat special. Interacțiunea de rețea între KSC-urile clienților și principalul KSC, precum și între agenții ușori și SVM, se realizează prin NAT prin intermediul routerelor virtuale EdgeGW ale clienților.
Conform estimărilor și rezultatelor testelor colegilor de la furnizor, agenții ușori reduc sarcina pe infrastructura virtuală a clienților cu aproximativ 25% (în comparație cu sistemul care utilizează software antivirus tradițional). În special, antivirusul standard Kaspersky Endpoint Security (KES) pentru medii fizice consumă aproape de două ori mai mult timp procesor în server (2,95%) decât soluția de virtualizare bazată pe agenți ușori (1,67%).
Grafica comparativă a sarcinii pe procesor
O situație similară se observă cu frecvența accesării discului pentru scriere: pentru antivirusul clasic aceasta este de 1011 IOPS, în timp ce pentru antivirusul de cloud — 671 IOPS.
Grafica comparativă a frecvenței accesării discului
Câștigul de performanță permite menținerea stabilității infrastructurii și o utilizare mai eficientă a resurselor de calcul. Datorită adaptării pentru a funcționa în medii cloud publice, soluția nu reduce performanța cloud-ului: efectuează verificări centralizate ale fișierelor și descarcă actualizări, distribuind sarcina. Aceasta înseamnă că, pe de o parte, nu vor fi omise amenințările relevante pentru infrastructura cloud, iar pe de altă parte, cerințele de resurse pentru mașinile virtuale se vor reduce, în medie, cu 25% în comparație cu antivirusul tradițional.
În ceea ce privește funcționalitatea, ambele soluții se aseamănă foarte mult: mai jos este un tabel comparativ. Totuși, în cloud, așa cum arată rezultatele testărilor de mai sus, este mai optim să folosești o soluție pentru medii virtuale.
Despre tarifarea în cadrul noului model. Am decis să folosim un model care permite obținerea de licențe în funcție de numărul de vCPU. Asta înseamnă că numărul de licențe va fi egal cu numărul de vCPU. Poți testa antivirusul printr-o cerere. .
În următorul material dedicat cloud-ului, vom vorbi despre evoluția WAF-urilor în cloud și ce este mai bine să alegi: hardware, software sau cloud.
Text pregătit de angajații furnizorului de servicii cloud #CloudMTS: Denis Miagkov, arhitect principal și Alexey Afanasev, manager de dezvoltare a produselor de Securitate informațională.
Sursa: habr.com
