Din ce în ce mai mulți utilizatori își aduc întreaga infrastructură IT în cloudul public. Cu toate acestea, dacă controlul antivirus este insuficient în infrastructura clientului, apar riscuri cibernetice grave. Practica arată că până la 80% dintre virușii existenți trăiesc perfect într-un mediu virtual. În această postare vom vorbi despre cum să protejăm resursele IT în cloudul public și de ce antivirusurile tradiționale nu sunt pe deplin potrivite pentru aceste scopuri.
Pentru început, vă vom spune cum am ajuns la ideea că instrumentele obișnuite de protecție antivirus nu sunt potrivite pentru cloud-ul public și că sunt necesare alte abordări pentru protejarea resurselor.
În primul rând, furnizorii oferă în general măsurile necesare pentru a se asigura că platformele lor cloud sunt protejate la un nivel înalt. De exemplu, la #CloudMTS analizăm tot traficul de rețea, monitorizăm jurnalele sistemelor de securitate ale cloudului nostru și efectuăm în mod regulat teste de verificare. Segmentele de cloud alocate clienților individuali trebuie, de asemenea, să fie protejate în siguranță.
În al doilea rând, varianta clasică de combatere a riscurilor cibernetice presupune instalarea unui antivirus și instrumente de management antivirus pe fiecare mașină virtuală. Cu toate acestea, cu un număr mare de mașini virtuale, această practică poate fi ineficientă și necesită cantități semnificative de resurse de calcul, încărcând astfel infrastructura clientului și reducând performanța globală a cloud-ului. Aceasta a devenit o condiție prealabilă cheie pentru căutarea unor noi abordări pentru construirea unei protecții antivirus eficiente pentru mașinile virtuale ale clienților.
În plus, majoritatea soluțiilor antivirus de pe piață nu sunt adaptate pentru a rezolva problemele de protecție a resurselor IT într-un mediu cloud public. De regulă, sunt soluții EPP grele (Endpoint Protection Platforms), care, în plus, nu oferă personalizarea necesară pe partea client a furnizorului de cloud.
Devine evident că soluțiile antivirus tradiționale nu sunt potrivite pentru lucrul în cloud, deoarece încarcă serios infrastructura virtuală în timpul actualizărilor și scanărilor și, de asemenea, nu au nivelurile necesare de management și setări bazate pe roluri. În continuare, vom analiza în detaliu de ce cloud-ul are nevoie de noi abordări pentru protecția antivirus.
Ce ar trebui să poată face un antivirus într-un cloud public
Deci, să acordăm atenție specificului lucrului într-un mediu virtual:
Eficiența actualizărilor și a scanărilor în masă programate. Dacă un număr semnificativ de mașini virtuale care folosesc un antivirus tradițional inițiază o actualizare în același timp, în cloud va avea loc o așa-numită „furtună” de actualizări. Puterea unei gazde ESXi care găzduiește mai multe mașini virtuale poate să nu fie suficientă pentru a gestiona barajul de sarcini similare care rulează implicit. Din punctul de vedere al furnizorului de cloud, o astfel de problemă poate duce la încărcări suplimentare pe o serie de gazde ESXi, ceea ce va duce în cele din urmă la o scădere a performanței infrastructurii virtuale cloud. Acest lucru poate afecta, printre altele, performanța mașinilor virtuale ale altor clienți cloud. O situație similară poate apărea la lansarea unei scanări în masă: procesarea simultană de către sistemul de disc a multor solicitări similare de la diferiți utilizatori va afecta negativ performanța întregului cloud. Cu un grad ridicat de probabilitate, o scădere a performanței sistemului de stocare va afecta toți clienții. Astfel de încărcări abrupte nu mulțumesc nici furnizorului, nici clienților săi, deoarece îi afectează pe „vecinii” din cloud. Din acest punct de vedere, antivirusul tradițional poate pune o mare problemă.
Carantină sigură. Dacă în sistem este detectat un fișier sau un document potențial infectat cu un virus, acesta este trimis în carantină. Desigur, un fișier infectat poate fi șters imediat, dar acest lucru nu este adesea acceptabil pentru majoritatea companiilor. Antivirusurile corporative care nu sunt adaptate să funcționeze în cloud-ul furnizorului, de regulă, au o zonă comună de carantină - toate obiectele infectate cad în ea. De exemplu, cele găsite pe computerele utilizatorilor companiei. Clienții furnizorului de cloud „trăiesc” în propriile lor segmente (sau chiriași). Aceste segmente sunt opace și izolate: clienții nu se cunosc unii despre alții și, desigur, nu văd ce găzduiesc alții în cloud. Evident, carantina generală, care va fi accesată de toți utilizatorii de antivirus din cloud, ar putea include un document care conține informații confidențiale sau un secret comercial. Acest lucru este inacceptabil pentru furnizor și clienții săi. Prin urmare, poate exista o singură soluție – carantina personală pentru fiecare client din segmentul său, unde nici furnizorul, nici alți clienți nu au acces.
Politici individuale de securitate. Fiecare client din cloud este o companie separată, al cărei departament IT își stabilește propriile politici de securitate. De exemplu, administratorii definesc regulile de scanare și programează scanări antivirus. În consecință, fiecare organizație trebuie să aibă propriul centru de control pentru a configura politicile antivirus. În același timp, setările specificate nu ar trebui să afecteze alți clienți cloud, iar furnizorul ar trebui să poată verifica, de exemplu, că actualizările antivirus sunt efectuate în mod normal pentru toate mașinile virtuale client.
Organizarea facturarii si licentei. Modelul cloud se caracterizează prin flexibilitate și presupune plata doar pentru cantitatea de resurse IT care au fost folosite de client. Dacă există o nevoie, de exemplu, din cauza sezonului, atunci cantitatea de resurse poate fi crescută sau redusă rapid - totul în funcție de nevoile actuale de putere de calcul. Antivirusul tradițional nu este atât de flexibil - de regulă, clientul cumpără o licență pentru un an pentru un număr predeterminat de servere sau stații de lucru. Utilizatorii cloud se deconectează și conectează în mod regulat mașini virtuale suplimentare în funcție de nevoile lor curente - în consecință, licențele antivirus trebuie să accepte același model.
A doua întrebare este ce anume va acoperi licența. Antivirusul tradițional este licențiat în funcție de numărul de servere sau stații de lucru. Licențele bazate pe numărul de mașini virtuale protejate nu sunt pe deplin adecvate în cadrul modelului cloud. Clientul poate crea orice număr de mașini virtuale convenabil pentru el din resursele disponibile, de exemplu, cinci sau zece mașini. Acest număr nu este constant pentru majoritatea clienților; nu este posibil pentru noi, ca furnizor, să urmărim modificările acestuia. Nu există nicio posibilitate tehnică de licențiere prin CPU: clienții primesc procesoare virtuale (vCPU), care ar trebui să fie folosite pentru licențiere. Astfel, noul model de protecție antivirus ar trebui să includă posibilitatea clientului de a determina numărul necesar de vCPU-uri pentru care va primi licențe antivirus.
Respectarea legislației. Un punct important, deoarece soluțiile utilizate trebuie să asigure conformitatea cu cerințele autorităților de reglementare. De exemplu, „rezidenții” din cloud lucrează adesea cu date personale. În acest caz, furnizorul trebuie să aibă un segment cloud certificat separat, care respectă pe deplin cerințele Legii privind datele cu caracter personal. Apoi, companiile nu trebuie să „construiască” în mod independent întregul sistem de lucru cu datele personale: să achiziționeze echipamente certificate, să-l conecteze și să-l configureze și să fie supuse certificării. Pentru protecția cibernetică a ISPD a unor astfel de clienți, antivirusul trebuie, de asemenea, să respecte cerințele legislației ruse și să aibă un certificat FSTEC.
Am analizat criteriile obligatorii pe care trebuie să le îndeplinească protecția antivirus în cloud public. În continuare, vom împărtăși propria noastră experiență în adaptarea unei soluții antivirus pentru a funcționa în cloud-ul furnizorului.
Cum vă puteți face prieteni între antivirus și cloud?
După cum a arătat experiența noastră, alegerea unei soluții bazată pe descriere și documentare este un lucru, dar implementarea ei în practică într-un mediu cloud deja funcțional este o sarcină complet diferită din punct de vedere al complexității. Vă vom spune ce am făcut în practică și cum am adaptat antivirusul pentru a funcționa în cloud-ul public al furnizorului. Vânzătorul soluției antivirus a fost Kaspersky, al cărui portofoliu include soluții de protecție antivirus pentru mediile cloud. Ne-am stabilit pe „Kaspersky Security for Virtualization” (Agent de lumină).
Include o singură consolă Kaspersky Security Center. Agent de lumină și mașini virtuale de securitate (SVM, Security Virtual Machine) și server de integrare KSC.
După ce am studiat arhitectura soluției Kaspersky și am efectuat primele teste împreună cu inginerii furnizorului, a apărut întrebarea despre integrarea serviciului în cloud. Prima implementare a fost realizată în comun pe site-ul cloud din Moscova. Și asta ne-am dat seama.
Pentru a minimiza traficul de rețea, sa decis să plasați un SVM pe fiecare gazdă ESXi și să „legați” SVM-ul la gazdele ESXi. În acest caz, agenții ușoare ai mașinilor virtuale protejate accesează SVM-ul exact al gazdei ESXi pe care rulează. A fost selectat un chiriaș administrativ separat pentru KSC principal. Ca urmare, KSC-urile subordonate sunt localizate în chiriașii fiecărui client individual și se adresează KSC-ului superior situat în segmentul de management. Această schemă vă permite să rezolvați rapid problemele care apar la chiriașii clienților.
Pe lângă problemele legate de ridicarea componentelor soluției antivirus în sine, ne-am confruntat cu sarcina de a organiza interacțiunea rețelei prin crearea de VxLAN-uri suplimentare. Și deși soluția a fost inițial destinată clienților enterprise cu cloud-uri private, cu ajutorul expertizei în inginerie și a flexibilității tehnologice a NSX Edge am reușit să rezolvăm toate problemele asociate cu separarea chiriașilor și licențierea.
Am lucrat îndeaproape cu inginerii Kaspersky. Astfel, în procesul de analiză a arhitecturii soluției în ceea ce privește interacțiunea în rețea între componentele sistemului, s-a constatat că, pe lângă accesul de la agenții de lumină la SVM, este necesar și feedback-ul - de la SVM la agenții de lumină. Această conectivitate la rețea nu este posibilă într-un mediu cu mai mulți locatari din cauza posibilității de setări de rețea identice ale mașinilor virtuale în chiriași cloud diferiți. Prin urmare, la solicitarea noastră, colegii de la furnizor au reelaborat mecanismul de interacțiune a rețelei dintre agentul de lumină și SVM în ceea ce privește eliminarea nevoii de conectivitate la rețea de la SVM la agenții de lumină.
După ce soluția a fost implementată și testată pe site-ul cloud din Moscova, am replicat-o pe alte site-uri, inclusiv pe segmentul cloud certificat. Serviciul este acum disponibil în toate regiunile țării.
Arhitectura unei soluții de securitate a informațiilor în cadrul unei noi abordări
Schema generală de funcționare a unei soluții antivirus într-un mediu cloud public este următoarea:
Schema de funcționare a unei soluții antivirus într-un mediu cloud public #CloudMTS
Să descriem caracteristicile funcționării elementelor individuale ale soluției în cloud:
• O singură consolă care permite clienților să gestioneze centralizat sistemul de protecție: rulați scanări, controlați actualizările și monitorizați zonele de carantină. Este posibil să configurați politici de securitate individuale în cadrul segmentului dvs.
Trebuie remarcat faptul că, deși suntem un furnizor de servicii, nu interferăm cu setările stabilite de clienți. Singurul lucru pe care îl putem face este să resetați politicile de securitate la cele standard dacă este necesară reconfigurarea. De exemplu, acest lucru poate fi necesar dacă clientul le-a strâns accidental sau le-a slăbit semnificativ. O companie poate primi oricând un centru de control cu politici implicite, pe care apoi le poate configura independent. Dezavantajul Kaspersky Security Center este că platforma este în prezent disponibilă doar pentru sistemul de operare Microsoft. Deși agenții ușori pot lucra atât cu mașini Windows, cât și cu Linux. Cu toate acestea, Kaspersky Lab promite că, în viitorul apropiat, KSC va funcționa sub sistemul de operare Linux. Una dintre funcțiile importante ale KSC este capacitatea de a gestiona carantina. Fiecare companie client din cloudul nostru are una personală. Această abordare elimină situațiile în care un document infectat cu un virus devine accidental vizibil public, așa cum s-ar putea întâmpla în cazul unui antivirus corporativ clasic cu carantină generală.
• Agenți de lumină. Ca parte a noului model, pe fiecare mașină virtuală este instalat un agent ușor Kaspersky Security. Acest lucru elimină necesitatea de a stoca baza de date antivirus pe fiecare VM, ceea ce reduce cantitatea de spațiu pe disc necesară. Serviciul este integrat cu infrastructura cloud și funcționează prin SVM, ceea ce crește densitatea mașinilor virtuale pe gazda ESXi și performanța întregului sistem cloud. Agentul de lumină construiește o coadă de sarcini pentru fiecare mașină virtuală: verifică sistemul de fișiere, memoria etc. Dar SVM este responsabil pentru efectuarea acestor operațiuni, despre care vom vorbi mai târziu. Agentul funcționează și ca un firewall, controlează politicile de securitate, trimite fișiere infectate în carantină și monitorizează „sănătatea” generală a sistemului de operare pe care este instalat. Toate acestea pot fi gestionate folosind consola unică deja menționată.
• Mașină virtuală de securitate. Toate sarcinile care necesită multe resurse (actualizări de baze de date antivirus, scanări programate) sunt gestionate de o mașină virtuală de securitate (SVM) separată. Ea este responsabilă pentru funcționarea unui motor antivirus cu drepturi depline și a bazelor de date pentru acesta. Infrastructura IT a unei companii poate include mai multe SVM-uri. 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 o alta.
• Server de integrare KSC. Una dintre componentele KSC-ului principal, care atribuie SVM-urile sale agenților de lumină în conformitate cu algoritmul specificat în setările sale și, de asemenea, controlează disponibilitatea SVM-urilor. Astfel, acest modul software oferă echilibrarea sarcinii pentru toate SVM-urile infrastructurii cloud.
Algoritm pentru lucrul în cloud: reducerea sarcinii asupra infrastructurii
În general, algoritmul antivirus poate fi reprezentat după cum urmează. Agentul accesează fișierul de pe mașina virtuală și îl verifică. Rezultatul verificării este stocat într-o bază de date comună centralizată de verdicte SVM (numită Shared Cache), fiecare intrare în care identifică un eșantion de fișier unic. Această abordare vă permite să vă asigurați că același fișier nu este scanat de mai multe ori la rând (de exemplu, dacă a fost deschis pe mașini virtuale diferite). Fișierul este rescanat numai dacă i s-au făcut modificări sau dacă scanarea a fost pornită manual.
Implementarea unei soluții antivirus în cloud-ul furnizorului
Imaginea prezintă o diagramă generală a implementării soluției în cloud. Kaspersky Security Center principal este implementat în zona de control a cloud-ului și un SVM individual este implementat pe fiecare gazdă ESXi folosind serverul de integrare KSC (fiecare gazdă ESXi are propriul SVM atașat cu setări speciale pe VMware vCenter Server). Clienții lucrează în propriile lor segmente de cloud, unde sunt amplasate mașinile virtuale cu agenți. Acestea sunt gestionate prin servere individuale KSC subordonate KSC principal. Dacă este necesar să se protejeze un număr mic de mașini virtuale (până la 5), clientului i se poate oferi acces la consola virtuală a unui server KSC special dedicat. Interacțiunea în rețea dintre KSC-urile client și KSC-ul principal, precum și agenții ușoare și SVM-urile, se realizează folosind NAT prin routerele virtuale ale clientului EdgeGW.
Conform estimărilor noastre și a rezultatelor testelor colegilor de la furnizor, Light Agent reduce sarcina asupra infrastructurii virtuale a clienților cu aproximativ 25% (în comparație cu un sistem 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 CPU de server (2,95%) decât o soluție ușoară de virtualizare bazată pe agenți (1,67%).
Diagrama de comparație a sarcinii procesorului
O situație similară se observă cu frecvența acceselor de scriere pe disc: pentru un antivirus clasic este de 1011 IOPS, pentru un antivirus cloud este de 671 IOPS.
Graficul de comparație a ratei de acces la disc
Beneficiul de performanță vă permite să mențineți stabilitatea infrastructurii și să utilizați puterea de calcul mai eficient. Prin adaptarea la lucru într-un mediu cloud public, soluția nu reduce performanța cloud: verifică centralizat fișierele și descarcă actualizări, distribuind încărcarea. Aceasta înseamnă că, pe de o parte, amenințările relevante pentru infrastructura cloud nu vor fi ratate, pe de altă parte, cerințele de resurse pentru mașinile virtuale vor fi reduse în medie cu 25% față de un antivirus tradițional.
Din punct de vedere al funcționalității, ambele soluții sunt foarte asemănătoare între ele: mai jos este un tabel de comparație. Cu toate acestea, în cloud, după cum arată rezultatele testelor de mai sus, este încă optim să folosiți o soluție pentru medii virtuale.
Despre tarife în cadrul noii abordări. Am decis să folosim un model care ne permite să obținem licențe în funcție de numărul de vCPU. Aceasta înseamnă că numărul de licențe va fi egal cu numărul de vCPU. Puteți testa antivirusul lăsând o solicitare .
În următorul articol despre subiecte cloud, vom vorbi despre evoluția WAF-urilor cloud și ce este mai bine să alegeți: hardware, software sau cloud.
Textul a fost pregătit de angajații furnizorului de cloud #CloudMTS: Denis Myagkov, arhitect principal și Alexey Afanasyev, manager de dezvoltare a produselor pentru securitatea informațiilor.
Sursa: www.habr.com