Gittikçe daha fazla kullanıcı tüm BT altyapısını genel buluta taşıyor. Ancak müşterinin altyapısında antivirüs kontrolü yetersiz ise ciddi siber riskler ortaya çıkar. Uygulama, mevcut virüslerin %80'e kadarının sanal ortamda mükemmel bir şekilde yaşadığını göstermektedir. Bu yazıda genel bulutta BT kaynaklarının nasıl korunacağından ve geleneksel antivirüslerin neden bu amaçlara tamamen uygun olmadığından bahsedeceğiz.
Başlangıç olarak, alışılagelmiş anti-virüs koruma araçlarının genel bulut için uygun olmadığı ve kaynakları korumaya yönelik başka yaklaşımların gerekli olduğu fikrine nasıl ulaştığımızı anlatacağız.
Öncelikle sağlayıcılar genellikle bulut platformlarının yüksek düzeyde korunmasını sağlamak için gerekli önlemleri sağlıyor. Örneğin #CloudMTS'de tüm ağ trafiğini analiz ediyoruz, bulut güvenlik sistemlerimizin günlüklerini izliyoruz ve düzenli olarak sızma testleri gerçekleştiriyoruz. Bireysel müşterilere tahsis edilen bulut segmentlerinin de güvenli bir şekilde korunması gerekir.
İkinci olarak, siber risklerle mücadeleye yönelik klasik seçenek, her sanal makineye bir antivirüs ve antivirüs yönetim araçlarının kurulmasını içerir. Ancak çok sayıda sanal makine söz konusu olduğunda bu uygulama etkisiz olabilir ve önemli miktarda bilgi işlem kaynağı gerektirebilir, dolayısıyla müşterinin altyapısı daha fazla yüklenebilir ve bulutun genel performansı düşebilir. Bu, müşteri sanal makineleri için etkili anti-virüs koruması oluşturmaya yönelik yeni yaklaşımlar aramak için önemli bir ön koşul haline geldi.
Ayrıca piyasadaki antivirüs çözümlerinin çoğu, genel bulut ortamında BT kaynaklarının korunmasına yönelik sorunları çözecek şekilde uyarlanmamıştır. Kural olarak bunlar, bulut sağlayıcının istemci tarafında gerekli özelleştirmeyi sağlamayan ağır EPP çözümleridir (Uç Nokta Koruma Platformları).
Güncellemeler ve taramalar sırasında sanal altyapıyı ciddi şekilde yükledikleri ve ayrıca gerekli düzeyde rol tabanlı yönetim ve ayarlara sahip olmadıkları için, geleneksel antivirüs çözümlerinin bulutta çalışmaya pek uygun olmadığı açıkça ortaya çıkıyor. Daha sonra, bulutun neden anti-virüs korumasına yönelik yeni yaklaşımlara ihtiyaç duyduğunu ayrıntılı olarak analiz edeceğiz.
Genel buluttaki bir antivirüsün yapabilecekleri
Öyleyse sanal ortamda çalışmanın özelliklerine dikkat edelim:
Güncellemelerin ve planlanmış toplu taramaların verimliliği. Geleneksel bir antivirüs kullanan önemli sayıda sanal makine aynı anda bir güncelleme başlatırsa, bulutta bir güncelleme "fırtınası" meydana gelecektir. Birkaç sanal makineyi barındıran bir ESXi ana bilgisayarının gücü, varsayılan olarak çalışan benzer görevlerin üstesinden gelmek için yeterli olmayabilir. Bulut sağlayıcının bakış açısından böyle bir sorun, bir dizi ESXi ana bilgisayarında ek yüklere yol açabilir ve bu da sonuçta bulut sanal altyapısının performansında bir düşüşe yol açabilir. Bu, diğer şeylerin yanı sıra diğer bulut istemcilerinin sanal makinelerinin performansını da etkileyebilir. Toplu tarama başlatıldığında da benzer bir durum ortaya çıkabilir: Farklı kullanıcılardan gelen birçok benzer isteğin disk sistemi tarafından eşzamanlı olarak işlenmesi, tüm bulutun performansını olumsuz yönde etkileyecektir. Yüksek olasılıkla, depolama sistemi performansındaki düşüş tüm istemcileri etkileyecektir. Bu tür ani yüklemeler, buluttaki "komşuları" etkilediği için ne sağlayıcıyı ne de müşterilerini memnun ediyor. Bu açıdan bakıldığında geleneksel antivirüs büyük bir sorun teşkil edebilir.
Güvenli karantina. Sistemde potansiyel olarak virüs bulaşmış bir dosya veya belge tespit edilirse karantinaya gönderilir. Elbette virüslü bir dosya hemen silinebilir ancak bu çoğu şirket için genellikle kabul edilebilir değildir. Sağlayıcının bulutunda çalışacak şekilde uyarlanmayan kurumsal kurumsal antivirüsler, kural olarak ortak bir karantina bölgesine sahiptir - virüslü tüm nesneler buraya düşer. Örneğin şirket kullanıcılarının bilgisayarlarında bulunanlar. Bulut sağlayıcısının müşterileri kendi segmentlerinde (veya kiracılarında) "yaşarlar". Bu segmentler şeffaf ve izoledir: Müşteriler birbirlerinden haberdar değildir ve elbette başkalarının bulutta ne barındırdığını görmezler. Açıkçası, buluttaki tüm antivirüs kullanıcılarının erişeceği genel karantina, potansiyel olarak gizli bilgiler veya ticari sır içeren bir belge içerebilir. Bu, sağlayıcı ve müşterileri için kabul edilemez. Bu nedenle, yalnızca tek bir çözüm olabilir: kendi segmentindeki her müşteri için, ne sağlayıcının ne de diğer müşterilerin erişemediği kişisel karantina.
Bireysel güvenlik politikaları. Buluttaki her müşteri, BT departmanının kendi güvenlik politikalarını belirlediği ayrı bir şirkettir. Örneğin yöneticiler tarama kurallarını tanımlar ve anti-virüs taramalarını planlar. Buna göre her kuruluşun antivirüs politikalarını yapılandırmak için kendi kontrol merkezine sahip olması gerekir. Aynı zamanda, belirtilen ayarlar diğer bulut istemcilerini etkilememeli ve sağlayıcı, örneğin antivirüs güncellemelerinin tüm istemci sanal makineleri için normal şekilde yürütüldüğünü doğrulayabilmelidir.
Faturalandırma ve lisanslama organizasyonu. Bulut modeli esneklikle karakterize edilir ve yalnızca müşteri tarafından kullanılan BT kaynağı miktarı kadar ödeme yapılmasını içerir. Örneğin mevsimsellik nedeniyle bir ihtiyaç varsa, kaynak miktarı hızlı bir şekilde artırılabilir veya azaltılabilir; bunların tümü, mevcut bilgi işlem gücü gereksinimlerine göre yapılır. Geleneksel antivirüs o kadar esnek değildir - kural olarak müşteri, önceden belirlenmiş sayıda sunucu veya iş istasyonu için bir yıllık lisans satın alır. Bulut kullanıcıları, mevcut ihtiyaçlarına bağlı olarak düzenli olarak ek sanal makinelerin bağlantısını kesip bağlar; buna göre antivirüs lisanslarının aynı modeli desteklemesi gerekir.
İkinci soru ise lisansın tam olarak neyi kapsayacağıdır. Geleneksel antivirüs, sunucu veya iş istasyonu sayısına göre lisanslanır. Korunan sanal makinelerin sayısına dayalı lisanslar, bulut modeline tam olarak uygun değildir. Müşteri, mevcut kaynaklardan kendisi için uygun olan herhangi bir sayıda sanal makine (örneğin, beş veya on makine) oluşturabilir. Bu sayı çoğu müşteri için sabit değildir; sağlayıcı olarak bizim değişiklikleri takip etmemiz mümkün değildir. CPU'ya göre lisanslamanın teknik bir olanağı yoktur: istemciler, lisanslama için kullanılması gereken sanal işlemcileri (vCPU'lar) alır. Bu nedenle, yeni antivirüs koruma modeli, müşterinin antivirüs lisansı alacağı gerekli vCPU sayısını belirleme yeteneğini içermelidir.
Mevzuata uygunluk. Önemli bir nokta, çünkü kullanılan çözümlerin düzenleyicinin gereksinimlerine uygunluğu sağlaması gerekiyor. Örneğin bulut "sakinleri" genellikle kişisel verilerle çalışır. Bu durumda sağlayıcının, Kişisel Veriler Kanunu gerekliliklerine tam olarak uyan ayrı bir sertifikalı bulut segmentine sahip olması gerekir. O zaman şirketlerin kişisel verilerle çalışmak için tüm sistemi bağımsız olarak "kurmasına" gerek kalmaz: sertifikalı ekipman satın alın, bağlayın ve yapılandırın, sertifikasyondan geçin. Bu tür istemcilerin ISPD'sinin siber koruması için antivirüsün ayrıca Rus mevzuatının gerekliliklerine uygun olması ve FSTEC sertifikasına sahip olması gerekir.
Genel buluttaki antivirüs korumasının karşılaması gereken zorunlu kriterleri inceledik. Daha sonra, bir antivirüs çözümünü sağlayıcının bulutunda çalışacak şekilde uyarlama konusunda kendi deneyimimizi paylaşacağız.
Antivirüs ve bulut arasında nasıl arkadaşlık kurabilirsiniz?
Deneyimlerimizin gösterdiği gibi, açıklamaya ve belgelere dayalı bir çözüm seçmek bir şeydir, ancak bunu halihazırda çalışan bir bulut ortamında pratikte uygulamak, karmaşıklık açısından tamamen farklı bir iştir. Size pratikte ne yaptığımızı ve antivirüs yazılımını sağlayıcının genel bulutunda çalışacak şekilde nasıl uyarladığımızı anlatacağız. Antivirüs çözümünün satıcısı, portföyünde bulut ortamları için antivirüs koruma çözümleri bulunan Kaspersky'ydi. “Kaspersky Security for Virtualization” (Light Agent) üzerinde karar kıldık.
Tek bir Kaspersky Security Center konsolu içerir. Hafif aracı ve güvenlik sanal makineleri (SVM, Güvenlik Sanal Makinesi) ve KSC entegrasyon sunucusu.
Kaspersky çözümünün mimarisini inceledikten ve satıcının mühendisleriyle birlikte ilk testleri yaptıktan sonra, hizmetin buluta entegre edilmesiyle ilgili soru ortaya çıktı. İlk uygulama Moskova bulut sitesinde ortaklaşa gerçekleştirildi. Ve biz de bunu fark ettik.
Ağ trafiğini en aza indirmek için her ESXi ana bilgisayarına bir SVM yerleştirmeye ve SVM'yi ESXi ana bilgisayarlara "bağlamaya" karar verildi. Bu durumda, korumalı sanal makinelerin hafif aracıları, üzerinde çalıştıkları ESXi ana bilgisayarının SVM'sine erişir. Ana KSC için ayrı bir idari kiracı seçildi. Sonuç olarak, alt KSC'ler her bir müşterinin kiracılarında bulunur ve yönetim segmentinde yer alan üst KSC'ye hitap eder. Bu şema, müşteri kiracılarında ortaya çıkan sorunları hızlı bir şekilde çözmenize olanak tanır.
Anti-virüs çözümünün bileşenlerinin yükseltilmesiyle ilgili sorunların yanı sıra, ek VxLAN'ların oluşturulması yoluyla ağ etkileşimini organize etme göreviyle de karşı karşıya kaldık. Çözüm başlangıçta özel bulutlara sahip kurumsal müşterilere yönelik olsa da, NSX Edge'in mühendislik bilgisi ve teknolojik esnekliğinin yardımıyla kiracıların ve lisanslamanın ayrılmasıyla ilgili tüm sorunları çözmeyi başardık.
Kaspersky mühendisleriyle yakın işbirliği içinde çalıştık. Böylece, çözüm mimarisini sistem bileşenleri arasındaki ağ etkileşimi açısından analiz etme sürecinde, hafif aracılardan SVM'ye erişimin yanı sıra, SVM'den hafif aracılara geri bildirimin de gerekli olduğu bulundu. Farklı bulut kiracılarındaki sanal makinelerin aynı ağ ayarlarının aynı olması olasılığı nedeniyle, çok kiracılı bir ortamda bu ağ bağlantısı mümkün değildir. Bu nedenle, talebimiz üzerine satıcının meslektaşları, SVM'den hafif aracılara ağ bağlantısı ihtiyacını ortadan kaldırmak amacıyla hafif aracı ile SVM arasındaki ağ etkileşimi mekanizmasını yeniden çalıştı.
Çözüm Moskova bulut sitesinde dağıtılıp test edildikten sonra, onu sertifikalı bulut segmenti de dahil olmak üzere diğer sitelere kopyaladık. Hizmet şu anda ülkenin tüm bölgelerinde mevcuttur.
Yeni bir yaklaşım çerçevesinde bilgi güvenliği çözümünün mimarisi
Genel bulut ortamında bir antivirüs çözümünün genel çalışma şeması aşağıdaki gibidir:
Genel bulut ortamında bir antivirüs çözümünün çalışma şeması #CloudMTS
Buluttaki çözümün ayrı ayrı öğelerinin çalışma özelliklerini açıklayalım:
• İstemcilerin koruma sistemini merkezi olarak yönetmesine olanak tanıyan tek bir konsol: taramaları çalıştırın, güncellemeleri kontrol edin ve karantina bölgelerini izleyin. Segmentiniz içinde bireysel güvenlik politikalarını yapılandırmak mümkündür.
Şunu da belirtelim ki, servis sağlayıcı olmamıza rağmen müşterilerin belirlediği ayarlara müdahale etmiyoruz. Yapabileceğimiz tek şey, yeniden yapılandırma gerekiyorsa güvenlik politikalarını standart olanlara sıfırlamaktır. Örneğin, müşteri yanlışlıkla onları sıktıysa veya önemli ölçüde zayıflattıysa bu gerekli olabilir. Bir şirket her zaman varsayılan ilkelere sahip bir kontrol merkezi alabilir ve daha sonra bunu bağımsız olarak yapılandırabilir. Kaspersky Security Center'ın dezavantajı platformun şu anda yalnızca Microsoft işletim sistemi için mevcut olmasıdır. Hafif aracılar hem Windows hem de Linux makinelerinde çalışabilmesine rağmen. Ancak Kaspersky Lab, yakın gelecekte KSC'nin Linux işletim sistemi altında çalışacağının sözünü veriyor. KSC'nin önemli işlevlerinden biri karantinayı yönetme yeteneğidir. Bulutumuzdaki her müşteri şirketinin kişisel bir şirketi vardır. Bu yaklaşım, genel karantinaya sahip klasik bir kurumsal antivirüs örneğinde olduğu gibi, virüs bulaşmış bir belgenin yanlışlıkla kamuya açık hale geldiği durumları ortadan kaldırır.
• Hafif ajanlar. Yeni modelin bir parçası olarak her sanal makineye hafif bir Kaspersky Security aracısı kuruluyor. Bu, anti-virüs veritabanını her VM'de saklama ihtiyacını ortadan kaldırır ve bu da gereken disk alanı miktarını azaltır. Hizmet, bulut altyapısıyla entegredir ve SVM aracılığıyla çalışır; bu, ESXi ana bilgisayarındaki sanal makinelerin yoğunluğunu ve tüm bulut sisteminin performansını artırır. Hafif aracı, her sanal makine için bir görev sırası oluşturur: dosya sistemini, belleği vb. kontrol edin. Ancak daha sonra konuşacağımız bu işlemlerin gerçekleştirilmesinden SVM sorumludur. Aracı aynı zamanda bir güvenlik duvarının işlevlerini yerine getirir, güvenlik politikalarını kontrol eder, virüslü dosyaları karantinaya gönderir ve kurulu olduğu işletim sisteminin genel "sağlığını" izler. Bütün bunlar daha önce bahsedilen tek konsol kullanılarak yönetilebilir.
• Güvenlik Sanal Makinesi. Yoğun kaynak kullanan tüm görevler (virüsten koruma veritabanı güncellemeleri, zamanlanmış taramalar) ayrı bir Güvenlik Sanal Makinesi (SVM) tarafından gerçekleştirilir. Tam teşekküllü bir anti-virüs motorunun ve bunun için veritabanlarının çalışmasından sorumludur. Bir şirketin BT altyapısı birkaç SVM içerebilir. Bu yaklaşım sistemin güvenilirliğini artırır; bir makine arızalanırsa ve otuz saniye boyunca yanıt vermezse temsilciler otomatik olarak başka bir makine aramaya başlar.
• KSC entegrasyon sunucusu. SVM'lerini ayarlarında belirtilen algoritmaya göre hafif aracılara atayan ve aynı zamanda SVM'lerin kullanılabilirliğini de kontrol eden ana KSC'nin bileşenlerinden biri. Böylece bu yazılım modülü, bulut altyapısının tüm SVM'lerinde yük dengeleme sağlar.
Bulutta çalışmaya yönelik algoritma: altyapı üzerindeki yükün azaltılması
Genel olarak antivirüs algoritması aşağıdaki gibi temsil edilebilir. Aracı, sanal makinedeki dosyaya erişir ve onu kontrol eder. Doğrulamanın sonucu, her bir girişin benzersiz bir dosya örneğini tanımladığı ortak bir merkezi SVM karar veritabanında (Paylaşılan Önbellek adı verilir) saklanır. Bu yaklaşım, aynı dosyanın art arda birkaç kez taranmamasını sağlamanıza olanak tanır (örneğin, farklı sanal makinelerde açılmışsa). Dosya yalnızca değişiklik yapılmışsa veya tarama manuel olarak başlatılmışsa yeniden taranır.
Sağlayıcının bulutunda bir antivirüs çözümünün uygulanması
Resimde buluttaki çözüm uygulamasının genel bir diyagramı gösterilmektedir. Ana Kaspersky Security Center, bulutun kontrol bölgesinde dağıtılır ve KSC entegrasyon sunucusu kullanılarak her ESXi ana bilgisayarına ayrı bir SVM dağıtılır (her ESXi ana bilgisayarının, VMware vCenter Server'da özel ayarlarla eklenmiş kendi SVM'si vardır). Müşteriler, aracıların bulunduğu sanal makinelerin bulunduğu kendi bulut segmentlerinde çalışır. Ana KSC'ye bağlı bireysel KSC sunucuları aracılığıyla yönetilirler. Az sayıda sanal makinenin (5'e kadar) korunması gerekiyorsa, istemciye özel bir KSC sunucusunun sanal konsoluna erişim sağlanabilir. İstemci KSC'ler ile ana KSC'nin yanı sıra hafif aracılar ve SVM'ler arasındaki ağ etkileşimi, EdgeGW istemci sanal yönlendiricileri aracılığıyla NAT kullanılarak gerçekleştirilir.
Tahminlerimize ve satıcıdaki meslektaşlarımızın test sonuçlarına göre Light Agent, müşterilerin sanal altyapısı üzerindeki yükü yaklaşık %25 oranında azaltır (geleneksel anti-virüs yazılımı kullanan bir sistemle karşılaştırıldığında). Özellikle, fiziksel ortamlar için standart Kaspersky Endpoint Security (KES) antivirüsü, hafif aracı tabanlı sanallaştırma çözümüne (%2,95) göre neredeyse iki kat daha fazla sunucu CPU zamanı (%1,67) tüketir.
CPU yükü karşılaştırma tablosu
Disk yazma erişimlerinin sıklığında da benzer bir durum gözleniyor: klasik bir antivirüs için 1011 IOPS, bulut antivirüs için 671 IOPS'dir.
Disk erişim hızı karşılaştırma grafiği
Performans avantajı, altyapı kararlılığını korumanıza ve bilgi işlem gücünü daha verimli kullanmanıza olanak tanır. Çözüm, genel bulut ortamında çalışmaya uyum sağlayarak bulut performansını düşürmez: dosyaları merkezi olarak kontrol eder ve güncellemeleri indirerek yükü dağıtır. Bu, bir yandan bulut altyapısıyla ilgili tehditlerin gözden kaçmayacağı, diğer yandan sanal makinelerin kaynak gereksinimlerinin geleneksel bir antivirüse kıyasla ortalama %25 oranında azalacağı anlamına geliyor.
İşlevsellik açısından her iki çözüm de birbirine çok benzer: aşağıda bir karşılaştırma tablosu bulunmaktadır. Ancak yukarıdaki test sonuçlarının gösterdiği gibi bulutta, sanal ortamlara yönelik bir çözümün kullanılması hala en uygunudur.
Yeni yaklaşım çerçevesinde tarifeler hakkında. vCPU sayısına göre lisans almamıza olanak tanıyan bir model kullanmaya karar verdik. Bu, lisans sayısının vCPU sayısına eşit olacağı anlamına gelir. Bir istek bırakarak antivirüsünüzü test edebilirsiniz. .
Bulut konularıyla ilgili bir sonraki makalede, bulut WAF'lerin evrimi ve neyin seçilmesinin daha iyi olduğu hakkında konuşacağız: donanım, yazılım veya bulut.
Metin, bulut sağlayıcısı #CloudMTS çalışanları tarafından hazırlandı: Önde gelen mimar Denis Myagkov ve bilgi güvenliği ürün geliştirme müdürü Alexey Afanasyev.
Kaynak: habr.com