რატომ არ არის შესაფერისი ტრადიციული ანტივირუსები საჯარო ღრუბლებისთვის? მერე რა უნდა გავაკეთო?

უფრო და უფრო მეტი მომხმარებელი ატარებს მთელ IT ინფრასტრუქტურას საჯარო ღრუბელში. თუმცა, თუ ანტივირუსული კონტროლი არასაკმარისია მომხმარებლის ინფრასტრუქტურაში, წარმოიქმნება სერიოზული კიბერ რისკები. პრაქტიკა გვიჩვენებს, რომ არსებული ვირუსების 80%-მდე იდეალურად ცხოვრობს ვირტუალურ გარემოში. ამ პოსტში ვისაუბრებთ იმაზე, თუ როგორ დავიცვათ IT რესურსები საჯარო ღრუბელში და რატომ არ არის ტრადიციული ანტივირუსები მთლად შესაფერისი ამ მიზნებისთვის.

დასაწყისისთვის, ჩვენ გეტყვით, როგორ მივედით იმ აზრამდე, რომ ჩვეულებრივი ანტივირუსული დამცავი ხელსაწყოები არ არის შესაფერისი საჯარო ღრუბლისთვის და რომ საჭიროა სხვა მიდგომები რესურსების დასაცავად.

პირველი, პროვაიდერები ზოგადად უზრუნველყოფენ აუცილებელ ზომებს იმის უზრუნველსაყოფად, რომ მათი ღრუბლოვანი პლატფორმები დაცულია მაღალ დონეზე. მაგალითად, #CloudMTS-ში ჩვენ ვაანალიზებთ ქსელის მთელ ტრაფიკს, ვაკვირდებით ჩვენი ღრუბლოვანი უსაფრთხოების სისტემების ჟურნალებს და რეგულარულად ვასრულებთ პენტესტებს. ცალკეული კლიენტებისთვის გამოყოფილი ღრუბლოვანი სეგმენტები ასევე უსაფრთხოდ უნდა იყოს დაცული.

მეორეც, კიბერ რისკებთან ბრძოლის კლასიკური ვარიანტი გულისხმობს ანტივირუსისა და ანტივირუსის მართვის ინსტრუმენტების დაყენებას თითოეულ ვირტუალურ მანქანაზე. თუმცა, ვირტუალური მანქანების დიდი რაოდენობით, ეს პრაქტიკა შეიძლება იყოს არაეფექტური და მოითხოვოს მნიშვნელოვანი რაოდენობის გამოთვლითი რესურსები, რითაც კიდევ უფრო იტვირთება მომხმარებლის ინფრასტრუქტურა და ამცირებს ღრუბლის მთლიან შესრულებას. ეს გახდა მთავარი წინაპირობა მომხმარებელთა ვირტუალური მანქანებისთვის ეფექტური ანტივირუსული დაცვის შესაქმნელად ახალი მიდგომების მოსაძებნად.

გარდა ამისა, ბაზარზე არსებული ანტივირუსული გადაწყვეტილებების უმეტესობა არ არის ადაპტირებული საჯარო ღრუბლოვან გარემოში IT რესურსების დაცვის პრობლემების გადასაჭრელად. როგორც წესი, ეს არის მძიმე EPP გადაწყვეტილებები (Endpoint Protection Platforms), რომლებიც, უფრო მეტიც, არ უზრუნველყოფენ საჭირო პერსონალიზაციას ღრუბლოვანი პროვაიდერის კლიენტის მხარეს.

აშკარა ხდება, რომ ტრადიციული ანტივირუსული გადაწყვეტილებები არ არის შესაფერისი ღრუბელში მუშაობისთვის, რადგან ისინი სერიოზულად იტვირთება ვირტუალური ინფრასტრუქტურა განახლებებისა და სკანირების დროს, ასევე არ გააჩნიათ როლებზე დაფუძნებული მართვისა და პარამეტრების საჭირო დონეები. შემდეგი, ჩვენ დეტალურად გავაანალიზებთ, თუ რატომ სჭირდება ღრუბელს ანტივირუსული დაცვის ახალი მიდგომები.

რა უნდა შეეძლოს ანტივირუსს საჯარო ღრუბელში

ასე რომ, ყურადღება მივაქციოთ ვირტუალურ გარემოში მუშაობის სპეციფიკას:

განახლებების და დაგეგმილი მასობრივი სკანირების ეფექტურობა. თუ ვირტუალური მანქანების მნიშვნელოვანი რაოდენობა, რომლებიც იყენებენ ტრადიციულ ანტივირუსს, ერთდროულად დაიწყებს განახლებას, ღრუბელში მოხდება განახლებების ეგრეთ წოდებული „ქარიშხალი“. ESXi ჰოსტის სიმძლავრე, რომელიც მასპინძლობს რამდენიმე ვირტუალურ მანქანას, შეიძლება არ იყოს საკმარისი იმისათვის, რომ გაუმკლავდეს ნაგულისხმევად გაშვებულ მსგავს ამოცანებს. ღრუბლოვანი პროვაიდერის თვალსაზრისით, ასეთმა პრობლემამ შეიძლება გამოიწვიოს დამატებითი დატვირთვები ESXi ჰოსტებზე, რაც საბოლოოდ გამოიწვევს ღრუბლოვანი ვირტუალური ინფრასტრუქტურის მუშაობის ვარდნას. ამან შეიძლება, სხვა საკითხებთან ერთად, გავლენა მოახდინოს სხვა ღრუბლოვანი კლიენტების ვირტუალური მანქანების მუშაობაზე. მსგავსი სიტუაცია შეიძლება წარმოიშვას მასობრივი სკანირების დაწყებისას: დისკის სისტემის მიერ მრავალი მსგავსი მოთხოვნის ერთდროული დამუშავება სხვადასხვა მომხმარებლისგან უარყოფითად იმოქმედებს მთელი ღრუბლის მუშაობაზე. დიდი ალბათობით, შენახვის სისტემის მუშაობის შემცირება გავლენას მოახდენს ყველა კლიენტზე. ასეთი მკვეთრი დატვირთვები არ მოსწონთ არც პროვაიდერს და არც მის მომხმარებლებს, რადგან ისინი გავლენას ახდენენ ღრუბელში "მეზობლებზე". ამ თვალსაზრისით, ტრადიციულმა ანტივირუსმა შეიძლება დიდი პრობლემა შექმნას.

უსაფრთხო კარანტინი. თუ სისტემაში აღმოჩენილია ვირუსით პოტენციურად ინფიცირებული ფაილი ან დოკუმენტი, ის იგზავნება კარანტინში. რა თქმა უნდა, ინფიცირებული ფაილი შეიძლება დაუყოვნებლივ წაიშალოს, მაგრამ ეს ხშირად მიუღებელია კომპანიების უმეტესობისთვის. კორპორატიული საწარმოს ანტივირუსებს, რომლებიც არ არის ადაპტირებული პროვაიდერის ღრუბელში მუშაობისთვის, როგორც წესი, აქვთ საერთო საკარანტინო ზონა - მასში მოხვდება ყველა ინფიცირებული ობიექტი. მაგალითად, ის, რაც ნაპოვნია კომპანიის მომხმარებლების კომპიუტერებზე. ღრუბლოვანი პროვაიდერის კლიენტები „ცხოვრობენ“ საკუთარ სეგმენტებში (ან მოიჯარეებში). ეს სეგმენტები გაუმჭვირვალე და იზოლირებულია: კლიენტებმა არ იციან ერთმანეთის შესახებ და, რა თქმა უნდა, ვერ ხედავენ რას მასპინძლობენ სხვები ღრუბელში. ცხადია, ზოგადი კარანტინი, რომელზედაც წვდომა ექნება ყველა ანტივირუსის მომხმარებელს ღრუბელში, შესაძლოა მოიცავდეს კონფიდენციალურ ინფორმაციას ან სავაჭრო საიდუმლოს. ეს მიუღებელია პროვაიდერისთვის და მისი მომხმარებლებისთვის. აქედან გამომდინარე, შეიძლება იყოს მხოლოდ ერთი გამოსავალი - პერსონალური კარანტინი თითოეული კლიენტისთვის თავის სეგმენტში, სადაც არც პროვაიდერს და არც სხვა კლიენტებს არ აქვთ წვდომა.

ინდივიდუალური უსაფრთხოების პოლიტიკა. ღრუბელში თითოეული კლიენტი არის ცალკე კომპანია, რომლის IT დეპარტამენტი ადგენს უსაფრთხოების საკუთარ პოლიტიკას. მაგალითად, ადმინისტრატორები განსაზღვრავენ სკანირების წესებს და გეგმავენ ანტივირუსულ სკანირებას. შესაბამისად, თითოეულ ორგანიზაციას უნდა ჰქონდეს საკუთარი კონტროლის ცენტრი ანტივირუსული პოლიტიკის კონფიგურაციისთვის. ამავდროულად, მითითებულმა პარამეტრებმა არ უნდა იმოქმედოს სხვა ღრუბლოვან კლიენტებზე და პროვაიდერს უნდა შეეძლოს დაადასტუროს, რომ, მაგალითად, ანტივირუსული განახლებები ჩვეულებრივ ხორციელდება ყველა კლიენტის ვირტუალური აპარატისთვის.

ბილინგისა და ლიცენზირების ორგანიზაცია. ღრუბლოვანი მოდელი ხასიათდება მოქნილობით და გულისხმობს მხოლოდ იმ IT რესურსების ოდენობის გადახდას, რომელიც გამოიყენა მომხმარებელს. თუ არსებობს საჭიროება, მაგალითად, სეზონურობის გამო, მაშინ რესურსების რაოდენობა შეიძლება სწრაფად გაიზარდოს ან შემცირდეს - ეს ყველაფერი ეფუძნება გამოთვლითი სიმძლავრის მიმდინარე საჭიროებებს. ტრადიციული ანტივირუსი არც ისე მოქნილია - როგორც წესი, კლიენტი ყიდულობს ლიცენზიას ერთი წლის განმავლობაში სერვერების ან სამუშაო სადგურების წინასწარ განსაზღვრული რაოდენობისთვის. ღრუბლოვანი მომხმარებლები რეგულარულად წყვეტენ და აკავშირებენ დამატებით ვირტუალურ მანქანებს მათი ამჟამინდელი საჭიროებიდან გამომდინარე - შესაბამისად, ანტივირუსულ ლიცენზიებს უნდა ჰქონდეს იგივე მოდელის მხარდაჭერა.

მეორე საკითხია, კონკრეტულად რას მოიცავს ლიცენზია. ტრადიციული ანტივირუსი ლიცენზირებულია სერვერების ან სამუშაო სადგურების რაოდენობის მიხედვით. დაცული ვირტუალური მანქანების რაოდენობაზე დაფუძნებული ლიცენზიები მთლიანად არ არის შესაფერისი ღრუბლის მოდელში. კლიენტს შეუძლია შექმნას მისთვის მოსახერხებელი ნებისმიერი რაოდენობის ვირტუალური მანქანა ხელმისაწვდომი რესურსებიდან, მაგალითად, ხუთი ან ათი მანქანა. ეს რიცხვი არ არის მუდმივი კლიენტების უმრავლესობისთვის, ჩვენ, როგორც პროვაიდერს, შეუძლებელია თვალყური ადევნოთ მის ცვლილებებს. არ არსებობს CPU-ს მიერ ლიცენზირების ტექნიკური შესაძლებლობა: კლიენტები იღებენ ვირტუალურ პროცესორებს (vCPU), რომლებიც უნდა გამოიყენონ ლიცენზირებისთვის. ამრიგად, ანტივირუსული დაცვის ახალი მოდელი უნდა შეიცავდეს მომხმარებელს შესაძლებლობას განსაზღვროს vCPU-ების საჭირო რაოდენობა, რომლებისთვისაც ის მიიღებს ანტივირუსულ ლიცენზიებს.

კანონმდებლობასთან შესაბამისობა. მნიშვნელოვანი პუნქტია, რადგან გამოყენებული გადაწყვეტილებები უნდა უზრუნველყოფდეს მარეგულირებლის მოთხოვნებთან შესაბამისობას. მაგალითად, ღრუბელი „მაცხოვრებლები“ ​​ხშირად მუშაობენ პერსონალურ მონაცემებთან. ამ შემთხვევაში, პროვაიდერს უნდა ჰქონდეს ცალკე სერტიფიცირებული ღრუბლოვანი სეგმენტი, რომელიც სრულად შეესაბამება პერსონალური მონაცემების შესახებ კანონის მოთხოვნებს. მაშინ კომპანიებს არ სჭირდებათ დამოუკიდებლად "აშენონ" მთელი სისტემა პერსონალურ მონაცემებთან მუშაობისთვის: შეიძინონ სერტიფიცირებული აღჭურვილობა, დააკავშირონ და დააკონფიგურირონ და გაიარონ სერტიფიცირება. ასეთი კლიენტების ISPD-ის კიბერ დაცვისთვის ანტივირუსი ასევე უნდა შეესაბამებოდეს რუსეთის კანონმდებლობის მოთხოვნებს და ჰქონდეს FSTEC სერთიფიკატი.

ჩვენ გადავხედეთ სავალდებულო კრიტერიუმებს, რომლებსაც ანტივირუსული დაცვა საჯარო ღრუბელში უნდა აკმაყოფილებდეს. შემდეგი, ჩვენ გაგიზიარებთ საკუთარ გამოცდილებას ანტივირუსული გადაწყვეტის ადაპტაციაში პროვაიდერის ღრუბელში მუშაობისთვის.

როგორ შეგიძლიათ დამეგობრდეთ ანტივირუსსა და ღრუბელს შორის?

როგორც ჩვენმა გამოცდილებამ აჩვენა, აღწერასა და დოკუმენტაციაზე დაფუძნებული გადაწყვეტის არჩევა ერთია, მაგრამ მისი პრაქტიკაში დანერგვა უკვე მომუშავე ღრუბლოვან გარემოში სირთულის თვალსაზრისით სრულიად განსხვავებული ამოცანაა. ჩვენ გეტყვით, რა გავაკეთეთ პრაქტიკაში და როგორ მოვახდინეთ ანტივირუსის ადაპტაცია პროვაიდერის საჯარო ღრუბელში მუშაობისთვის. ანტივირუსული გადაწყვეტის გამყიდველი იყო Kaspersky, რომლის პორტფელი შეიცავს ღრუბლოვანი გარემოს ანტივირუსული დაცვის გადაწყვეტილებებს. ჩვენ გადავწყვიტეთ "Kaspersky Security ვირტუალიზაციისთვის" (Light Agent).

მასში შედის კასპერსკის უსაფრთხოების ცენტრის ერთი კონსოლი. სინათლის აგენტი და უსაფრთხოების ვირტუალური მანქანები (SVM, უსაფრთხოების ვირტუალური მანქანა) და KSC ინტეგრაციის სერვერი.

მას შემდეგ რაც კასპერსკის გადაწყვეტის არქიტექტურა შევისწავლეთ და გამყიდველის ინჟინრებთან ერთად ჩავატარეთ პირველი ტესტები, გაჩნდა კითხვა სერვისის ღრუბელში ინტეგრაციის შესახებ. პირველი განხორციელება ერთობლივად განხორციელდა მოსკოვის ღრუბლის ადგილზე. და ეს არის ის, რაც ჩვენ მივხვდით.

ქსელის ტრაფიკის მინიმიზაციის მიზნით, გადაწყდა SVM-ის განთავსება თითოეულ ESXi ჰოსტზე და SVM „დაკავშირება“ ESXi ჰოსტებთან. ამ შემთხვევაში, დაცული ვირტუალური მანქანების მსუბუქი აგენტები წვდებიან ზუსტად ESXi ჰოსტის SVM-ზე, რომელზეც ისინი მუშაობენ. მთავარი ქსკ-სთვის შეირჩა ცალკე ადმინისტრაციული დამქირავებელი. შედეგად, დაქვემდებარებული KSC-ები განლაგებულია თითოეული ინდივიდუალური კლიენტის მოიჯარეებში და მიმართავენ მენეჯმენტის სეგმენტში მდებარე ზემდგომ KSC-ს. ეს სქემა საშუალებას გაძლევთ სწრაფად მოაგვაროთ პრობლემები, რომლებიც წარმოიქმნება კლიენტის მოიჯარეებში.

გარდა თავად ანტივირუსული გადაწყვეტის კომპონენტების ამაღლების საკითხებისა, ჩვენ დაგვხვდა ამოცანა ქსელური ურთიერთქმედების ორგანიზება დამატებითი VxLAN-ების შექმნის გზით. და მიუხედავად იმისა, რომ გამოსავალი თავდაპირველად განკუთვნილი იყო კერძო ღრუბლების მქონე საწარმო კლიენტებისთვის, NSX Edge-ის ინჟინერიული ცოდნისა და ტექნოლოგიური მოქნილობის დახმარებით ჩვენ შევძელით გადავჭრათ ყველა პრობლემა, რომელიც დაკავშირებულია მოიჯარეების განცალკევებასთან და ლიცენზირებასთან.

ჩვენ მჭიდროდ ვთანამშრომლობდით კასპერსკის ინჟინრებთან. ამრიგად, გადაწყვეტის არქიტექტურის ანალიზის პროცესში სისტემის კომპონენტებს შორის ქსელური ურთიერთქმედების თვალსაზრისით, აღმოჩნდა, რომ სინათლის აგენტებიდან SVM-ზე წვდომის გარდა, ასევე აუცილებელია უკუკავშირი - SVM-დან სინათლის აგენტებამდე. ეს ქსელური დაკავშირება შეუძლებელია მრავალბინიან გარემოში, ვირტუალური მანქანების იდენტური ქსელის პარამეტრების შესაძლებლობის გამო სხვადასხვა ღრუბლოვან მოიჯარეებში. ამიტომ, ჩვენი მოთხოვნით, გამყიდველის კოლეგებმა გადაამუშავეს ქსელური ურთიერთქმედების მექანიზმი სინათლის აგენტსა და SVM-ს შორის SVM-დან სინათლის აგენტებთან ქსელის დაკავშირების საჭიროების აღმოფხვრის თვალსაზრისით.

მას შემდეგ, რაც გამოსავალი განლაგდა და ტესტირება მოსკოვის ღრუბლოვან საიტზე, ჩვენ გავამრავლეთ იგი სხვა საიტებზე, მათ შორის სერტიფიცირებულ ღრუბლოვან სეგმენტზე. სერვისი უკვე ხელმისაწვდომია ქვეყნის ყველა რეგიონში.

ინფორმაციული უსაფრთხოების გადაწყვეტის არქიტექტურა ახალი მიდგომის ფარგლებში

ანტივირუსული ხსნარის მუშაობის ზოგადი სქემა საჯარო ღრუბლოვან გარემოში ასეთია:

ანტივირუსული ხსნარის მუშაობის სქემა საჯარო ღრუბლოვან გარემოში #CloudMTS

მოდით აღვწეროთ ღრუბელში ხსნარის ცალკეული ელემენტების მუშაობის მახასიათებლები:

• ერთიანი კონსოლი, რომელიც კლიენტებს საშუალებას აძლევს ცენტრალიზებულად მართონ დაცვის სისტემა: აწარმოონ სკანირება, გააკონტროლონ განახლებები და დააკვირდნენ საკარანტინო ზონებს. შესაძლებელია ინდივიდუალური უსაფრთხოების პოლიტიკის კონფიგურაცია თქვენს სეგმენტში.

უნდა აღინიშნოს, რომ მიუხედავად იმისა, რომ ჩვენ ვართ მომსახურების მიმწოდებელი, ჩვენ არ ვერევით კლიენტების მიერ დადგენილ პარამეტრებში. ერთადერთი, რისი გაკეთებაც შეგვიძლია, არის უსაფრთხოების პოლიტიკის გადატვირთვა სტანდარტულზე, თუ საჭიროა ხელახალი კონფიგურაცია. მაგალითად, ეს შეიძლება საჭირო გახდეს, თუ კლიენტმა შემთხვევით გამკაცრდა ისინი ან მნიშვნელოვნად შესუსტდა. კომპანიას ყოველთვის შეუძლია მიიღოს საკონტროლო ცენტრი ნაგულისხმევი პოლიტიკით, რომელიც შემდეგ მას შეუძლია დამოუკიდებლად დააკონფიგურიროს. Kaspersky Security Center-ის მინუსი არის ის, რომ პლატფორმა ამჟამად ხელმისაწვდომია მხოლოდ Microsoft-ის ოპერაციული სისტემისთვის. მიუხედავად იმისა, რომ მსუბუქ აგენტებს შეუძლიათ იმუშაონ როგორც Windows, ასევე Linux მანქანებთან. თუმცა, კასპერსკის ლაბორატორია გვპირდება, რომ უახლოეს მომავალში KSC იმუშავებს Linux OS-ით. KSC-ის ერთ-ერთი მნიშვნელოვანი ფუნქციაა კარანტინის მართვის შესაძლებლობა. თითოეულ კლიენტ კომპანიას ჩვენს ღრუბელში აქვს პირადი. ეს მიდგომა გამორიცხავს სიტუაციებს, როდესაც ვირუსით ინფიცირებული დოკუმენტი შემთხვევით ხდება საჯაროდ ხილული, როგორც ეს შეიძლება მოხდეს კლასიკური კორპორატიული ანტივირუსის შემთხვევაში ზოგადი კარანტინით.

• რბილი აგენტები. როგორც ახალი მოდელის ნაწილი, თითოეულ ვირტუალურ მანქანაზე დამონტაჟებულია მსუბუქი Kaspersky Security აგენტი. ეს გამორიცხავს ანტივირუსული მონაცემთა ბაზის შენახვას თითოეულ VM-ზე, რაც ამცირებს დისკზე საჭირო სივრცის რაოდენობას. სერვისი ინტეგრირებულია ღრუბლოვან ინფრასტრუქტურასთან და მუშაობს SVM-ის მეშვეობით, რაც ზრდის ვირტუალური მანქანების სიმკვრივეს ESXi ჰოსტზე და მთელი ღრუბლოვანი სისტემის მუშაობას. სინათლის აგენტი აყალიბებს ამოცანების რიგს თითოეული ვირტუალური მანქანისთვის: შეამოწმეთ ფაილური სისტემა, მეხსიერება და ა.შ. მაგრამ SVM პასუხისმგებელია ამ ოპერაციების შესრულებაზე, რაზეც მოგვიანებით ვისაუბრებთ. აგენტი ასევე ფუნქციონირებს როგორც firewall, აკონტროლებს უსაფრთხოების პოლიტიკას, აგზავნის ინფიცირებულ ფაილებს კარანტინში და აკონტროლებს ოპერაციული სისტემის მთლიან "ჯანმრთელობას", რომელზეც ის არის დაინსტალირებული. ამ ყველაფრის მართვა შესაძლებელია უკვე აღნიშნული ერთი კონსოლის გამოყენებით.

• უსაფრთხოების ვირტუალური მანქანა. რესურსზე ინტენსიური ყველა დავალება (ანტივირუსული მონაცემთა ბაზის განახლებები, დაგეგმილი სკანირება) სრულდება უსაფრთხოების ცალკეული ვირტუალური აპარატის (SVM) მიერ. იგი პასუხისმგებელია სრულფასოვანი ანტივირუსული ძრავის მუშაობაზე და მისთვის მონაცემთა ბაზებზე. კომპანიის IT ინფრასტრუქტურა შეიძლება შეიცავდეს რამდენიმე SVM-ს. ეს მიდგომა ზრდის სისტემის საიმედოობას - თუ ერთი მანქანა მარცხდება და არ პასუხობს ოცდაათი წამის განმავლობაში, აგენტები ავტომატურად იწყებენ მეორის ძებნას.

• KSC ინტეგრაციის სერვერი. მთავარი KSC-ის ერთ-ერთი კომპონენტი, რომელიც თავის SVM-ებს ანიჭებს სინათლის აგენტებს მის პარამეტრებში მითითებული ალგორითმის შესაბამისად და ასევე აკონტროლებს SVM-ების ხელმისაწვდომობას. ამრიგად, ეს პროგრამული მოდული უზრუნველყოფს დატვირთვის დაბალანსებას ღრუბლოვან ინფრასტრუქტურის ყველა SVM-ზე.

ღრუბელში მუშაობის ალგორითმი: ინფრასტრუქტურის დატვირთვის შემცირება

ზოგადად, ანტივირუსული ალგორითმი შეიძლება წარმოდგენილი იყოს შემდეგნაირად. აგენტი წვდება ფაილს ვირტუალურ მანქანაზე და ამოწმებს მას. შემოწმების შედეგი ინახება საერთო ცენტრალიზებულ SVM განაჩენის მონაცემთა ბაზაში (ე.წ. Shared Cache), რომელშიც თითოეული ჩანაწერი განსაზღვრავს ფაილის უნიკალურ ნიმუშს. ეს მიდგომა საშუალებას გაძლევთ უზრუნველყოთ, რომ ერთი და იგივე ფაილის ზედიზედ რამდენჯერმე სკანირება არ მოხდეს (მაგალითად, თუ ის გაიხსნა სხვადასხვა ვირტუალურ აპარატზე). ფაილის ხელახლა სკანირება ხდება მხოლოდ იმ შემთხვევაში, თუ მასში ცვლილებები განხორციელდა ან სკანირება დაიწყო ხელით.

ანტივირუსული გადაწყვეტის დანერგვა პროვაიდერის ღრუბელში

სურათი გვიჩვენებს ღრუბელში გადაწყვეტის განხორციელების ზოგად დიაგრამას. მთავარი კასპერსკის უსაფრთხოების ცენტრი განლაგებულია ღრუბლის საკონტროლო ზონაში და ინდივიდუალური SVM განლაგებულია თითოეულ ESXi ჰოსტზე KSC ინტეგრაციის სერვერის გამოყენებით (თითოეულ ESXi ჰოსტს აქვს საკუთარი SVM დამაგრებული სპეციალური პარამეტრებით VMware vCenter სერვერზე). კლიენტები მუშაობენ საკუთარ ღრუბლოვან სეგმენტებში, სადაც განლაგებულია ვირტუალური მანქანები აგენტებით. მათი მართვა ხდება ძირითადი KSC-ს დაქვემდებარებული ინდივიდუალური KSC სერვერების მეშვეობით. თუ საჭიროა ვირტუალური მანქანების მცირე რაოდენობის დაცვა (5-მდე), კლიენტს შეიძლება მიეცეს წვდომა სპეციალური გამოყოფილი KSC სერვერის ვირტუალურ კონსოლზე. ქსელური ურთიერთქმედება კლიენტის KSC-სა და მთავარ KSC-ს, ასევე სინათლის აგენტებსა და SVM-ებს შორის, ხორციელდება NAT-ის გამოყენებით EdgeGW კლიენტის ვირტუალური მარშრუტიზატორების მეშვეობით.

ჩვენი შეფასებით და გამყიდველის კოლეგების ტესტების შედეგების მიხედვით, Light Agent ამცირებს დატვირთვას კლიენტების ვირტუალურ ინფრასტრუქტურაზე დაახლოებით 25%-ით (როდესაც შედარებულია სისტემასთან, რომელიც იყენებს ტრადიციულ ანტივირუსულ პროგრამას). კერძოდ, სტანდარტული Kaspersky Endpoint Security (KES) ანტივირუსი ფიზიკური გარემოსთვის მოიხმარს თითქმის ორჯერ მეტ სერვერის CPU დროს (2,95%), ვიდრე მსუბუქი აგენტზე დაფუძნებული ვირტუალიზაციის გადაწყვეტა (1,67%).

CPU დატვირთვის შედარების სქემა

მსგავსი სიტუაცია შეინიშნება დისკზე ჩაწერის წვდომის სიხშირით: კლასიკური ანტივირუსისთვის ეს არის 1011 IOPS, ღრუბლოვანი ანტივირუსისთვის ეს არის 671 IOPS.

დისკზე წვდომის სიჩქარის შედარების გრაფიკი

შესრულების უპირატესობა საშუალებას გაძლევთ შეინარჩუნოთ ინფრასტრუქტურის სტაბილურობა და გამოიყენოთ გამოთვლითი ძალა უფრო ეფექტურად. საჯარო ღრუბლოვან გარემოში მუშაობისთვის ადაპტაციით, გამოსავალი არ ამცირებს ღრუბლის მუშაობას: ის ცენტრალიზებულად ამოწმებს ფაილებს და ჩამოტვირთავს განახლებებს, ანაწილებს დატვირთვას. ეს ნიშნავს, რომ, ერთის მხრივ, ღრუბლოვანი ინფრასტრუქტურის შესაბამისი საფრთხეები არ იქნება გამოტოვებული, მეორეს მხრივ, ვირტუალურ აპარატებზე რესურსის მოთხოვნები ტრადიციულ ანტივირუსთან შედარებით საშუალოდ 25%-ით შემცირდება.

ფუნქციონალური თვალსაზრისით, ორივე გამოსავალი ძალიან ჰგავს ერთმანეთს: ქვემოთ მოცემულია შედარების ცხრილი. თუმცა, ღრუბელში, როგორც ზემოთ მოყვანილი ტესტის შედეგები აჩვენებს, მაინც ოპტიმალურია გამოსავლის გამოყენება ვირტუალური გარემოსთვის.

ტარიფების შესახებ ახალი მიდგომის ფარგლებში. ჩვენ გადავწყვიტეთ გამოგვეყენებინა მოდელი, რომელიც გვაძლევს საშუალებას მივიღოთ ლიცენზიები vCPU-ების რაოდენობის მიხედვით. ეს ნიშნავს, რომ ლიცენზიების რაოდენობა იქნება vCPU-ების რაოდენობის ტოლი. თქვენ შეგიძლიათ შეამოწმოთ თქვენი ანტივირუსი მოთხოვნის დატოვებით ონლაინ.

ღრუბლის თემებზე მომდევნო სტატიაში ვისაუბრებთ ღრუბლოვანი WAF-ების ევოლუციაზე და იმაზე, თუ რა არის უკეთესი აირჩიოს: აპარატურა, პროგრამული უზრუნველყოფა თუ ღრუბელი.

ტექსტი მოამზადეს ღრუბლოვანი პროვაიდერის #CloudMTS-ის თანამშრომლებმა: დენის მიაგკოვმა, წამყვანმა არქიტექტორმა და ალექსეი აფანასიევმა, ინფორმაციული უსაფრთხოების პროდუქტების განვითარების მენეჯერმა.

წყარო: www.habr.com