Bulut Güvenliği İzleme

Verileri ve uygulamaları buluta taşımak, diğer insanların altyapılarını izlemeye her zaman hazır olmayan kurumsal SOC'ler için yeni bir zorluk teşkil ediyor. Netoskope'a göre ortalama bir kuruluş (görünüşe göre ABD'de) 1246 farklı bulut hizmeti kullanıyor; bu da bir yıl öncesine göre %22 daha fazla. 1246 bulut hizmeti!!! Bunlardan 175'i İK hizmetleri, 170'i pazarlama, 110'u iletişim, 76'sı ise finans ve CRM alanındadır. Cisco “yalnızca” 700 harici bulut hizmetini kullanıyor. Bu yüzden bu rakamlar biraz kafamı karıştırdı. Ancak her halükarda sorun onlarda değil, bulut altyapısını kendi ağlarındakiyle aynı izleme yeteneklerine sahip olmak isteyen giderek artan sayıda şirket tarafından bulutun oldukça aktif olarak kullanılmaya başlanmasıyla ilgili. Ve bu eğilim büyüyor - göre Amerikan Hesaplar Odası'na göre 2023 yılına kadar Amerika Birleşik Devletleri'nde 1200 veri merkezi kapatılacak (6250'si zaten kapanmış durumda). Ancak buluta geçiş sadece "sunucularımızı harici bir sağlayıcıya taşıyalım" demek değildir. Yeni BT mimarisi, yeni yazılımlar, yeni süreçler, yeni kısıtlamalar... Bütün bunlar sadece BT'nin değil, bilgi güvenliğinin çalışmalarına da önemli değişiklikler getiriyor. Ve eğer sağlayıcılar bulutun güvenliğini sağlamayla bir şekilde başa çıkmayı öğrenmişlerse (neyse ki pek çok öneri var), o zaman özellikle SaaS platformlarında bulut bilgi güvenliğinin izlenmesinde önemli zorluklar vardır ve bunlardan bahsedeceğiz.

Diyelim ki şirketiniz altyapısının bir kısmını buluta taşıdı... Durun. Bu taraftan değil. Altyapı aktarıldıysa ve onu nasıl izleyeceğinizi ancak şimdi düşünüyorsanız, o zaman çoktan kaybetmişsiniz demektir. Amazon, Google veya Microsoft olmadığı sürece (ve daha sonra rezervasyon yaptırarak), muhtemelen verilerinizi ve uygulamalarınızı izleme konusunda fazla bir yeteneğiniz olmayacaktır. Günlüklerle çalışma fırsatı verilirse iyi olur. Bazen güvenlik olayı verileri mevcut olabilir ancak bunlara erişemezsiniz. Örneğin Office 365. En ucuz E1 lisansına sahipseniz güvenlik etkinlikleri sizin için hiçbir şekilde mevcut değildir. E3 lisansınız varsa verileriniz yalnızca 90 gün boyunca saklanır ve yalnızca E5 lisansınız varsa günlüklerin süresi bir yıl boyunca kullanılabilir (ancak bunun da ayrı olarak saklanması ihtiyacıyla ilgili kendi nüansları vardır). Microsoft desteğinden günlüklerle çalışmak için bir dizi işlev isteyin). Bu arada, E3 lisansı izleme işlevleri açısından kurumsal Exchange'den çok daha zayıf. Aynı seviyeye ulaşmak için bir E5 lisansına veya ek bir Gelişmiş Uyumluluk lisansına ihtiyacınız vardır; bu, bulut altyapısına geçiş için finansal modelinize dahil edilmeyen ek para gerektirebilir. Ve bu, bulut bilgi güvenliği izlemeyle ilgili sorunların hafife alınmasının yalnızca bir örneğidir. Bu yazıda, tamamlanmış gibi görünmeden, güvenlik açısından bulut sağlayıcı seçerken dikkate alınması gereken bazı nüanslara dikkat çekmek istiyorum. Makalenin sonunda ise bulut bilgi güvenliğinin izlenmesi sorununun çözüldüğünü düşünmeden önce tamamlanması gereken bir kontrol listesi verilecektir.

Bulut ortamlarında, bilgi güvenliği hizmetlerinin yanıt verecek zamanı olmadığı veya hiç göremediği olaylara yol açan birkaç tipik sorun vardır:

• Güvenlik günlükleri mevcut değil. Bu, özellikle bulut çözümleri pazarındaki acemi oyuncular arasında oldukça yaygın bir durumdur. Ancak bunlardan hemen vazgeçmemelisiniz. Küçük oyuncular, özellikle yerli olanlar, müşteri gereksinimlerine karşı daha duyarlıdır ve ürünleri için onaylanmış yol haritasını değiştirerek gerekli bazı işlevleri hızlı bir şekilde hayata geçirebilmektedirler. Evet, bu Amazon'dan GuardDuty'nin bir benzeri veya Bitrix'in "Proaktif Koruma" modülü olmayacak, en azından bir şey olacak.
• Bilgi güvenliği logların nerede saklandığını bilmez veya loglara erişim sağlanamaz. Burada bulut hizmeti sağlayıcısıyla müzakerelere girmek gerekiyor - belki de müşterinin kendisi için önemli olduğunu düşünürse bu tür bilgileri sağlayacaktır. Ancak genel olarak günlüklere erişimin "özel kararla" sağlanması pek iyi değildir.
• Ayrıca bulut sağlayıcının günlükleri vardır, ancak sınırlı izleme ve olay kaydı sağlarlar ve bu da tüm olayları tespit etmek için yeterli değildir. Örneğin, yalnızca bir web sitesindeki değişikliklerin günlüklerini veya kullanıcı kimlik doğrulama girişimlerinin günlüklerini alabilirsiniz, ancak ağ trafiği gibi diğer olayları alamazsınız; bu, bulut altyapınızı hackleme girişimlerini karakterize eden tüm olay katmanını sizden gizleyecektir.
• Günlükler var, ancak bunlara erişimin otomatikleştirilmesi zordur, bu da onların sürekli olarak değil, bir programa göre izlenmesini zorunlu kılar. Günlükleri otomatik olarak indiremiyorsanız, günlükleri örneğin Excel formatında indirmek (bazı yerel bulut çözümü sağlayıcılarında olduğu gibi), kurumsal bilgi güvenliği hizmetinin bunları düzeltme konusunda isteksizliğine bile yol açabilir.
• Günlük izleme yok. Bulut ortamlarında bilgi güvenliği olaylarının oluşmasının belki de en belirsiz nedeni budur. Görünüşe göre günlükler var ve bunlara erişimi otomatikleştirmek mümkün, ancak bunu kimse yapmıyor. Neden?

Paylaşılan bulut güvenliği konsepti

Buluta geçiş, her zaman altyapı üzerindeki kontrolü sürdürme arzusu ile altyapının bakımında uzmanlaşmış bir bulut sağlayıcının daha profesyonel ellerine devredilmesi arasında bir denge arayışıdır. Bulut güvenliği alanında da bu dengenin aranması gerekiyor. Üstelik kullanılan bulut hizmeti sunum modeline (IaaS, PaaS, SaaS) bağlı olarak bu denge her zaman farklı olacaktır. Her durumda, günümüzde tüm bulut sağlayıcılarının ortak sorumluluk ve paylaşılan bilgi güvenliği modeli olarak adlandırılan modeli izlediğini unutmamalıyız. Bulut bazı şeylerden sorumludur ve bazı şeylerden müşteri sorumludur; verilerini, uygulamalarını, sanal makinelerini ve diğer kaynaklarını buluta yerleştirir. Buluta geçerek tüm sorumluluğu sağlayıcıya devretmeyi beklemek umursamazlık olur. Ancak buluta geçerken tüm güvenliği kendiniz oluşturmak da akıllıca değildir. Pek çok faktöre bağlı olacak bir denge gereklidir: - risk yönetimi stratejisi, tehdit modeli, bulut sağlayıcının kullanabileceği güvenlik mekanizmaları, mevzuat vb.

Örneğin bulutta barındırılan verilerin sınıflandırılması her zaman müşterinin sorumluluğundadır. Bir bulut sağlayıcısı veya harici bir hizmet sağlayıcısı ona yalnızca buluttaki verileri işaretlemeye, ihlalleri tespit etmeye, yasayı ihlal eden verileri silmeye veya şu veya bu yöntemi kullanarak maskelemeye yardımcı olacak araçlarla yardımcı olabilir. Öte yandan fiziksel güvenlik her zaman bulut sağlayıcının sorumluluğundadır ve bunu müşterilerle paylaşamaz. Ancak veri ile fiziksel altyapı arasında kalan her şey tam olarak bu yazının tartışma konusudur. Örneğin, bulutun kullanılabilirliği sağlayıcının sorumluluğundadır ve güvenlik duvarı kurallarını ayarlamak veya şifrelemeyi etkinleştirmek müşterinin sorumluluğundadır. Bu yazıda, bugün Rusya'daki çeşitli popüler bulut sağlayıcıları tarafından hangi bilgi güvenliği izleme mekanizmalarının sağlandığını, bunların kullanım özelliklerinin neler olduğunu ve ne zaman harici yer paylaşımı çözümlerine (örneğin, Cisco E-) bakmaya değer olduğunu incelemeye çalışacağız. e-posta Güvenliği) bulutunuzun siber güvenlik açısından yeteneklerini genişletir. Bazı durumlarda, özellikle çoklu bulut stratejisi izliyorsanız, birden fazla bulut ortamındaki harici bilgi güvenliği izleme çözümlerini aynı anda kullanmaktan başka seçeneğiniz kalmayacaktır (örneğin, Cisco CloudLock veya Cisco Stealthwatch Cloud). Bazı durumlarda, seçtiğiniz (veya size empoze edilen) bulut sağlayıcısının hiçbir şekilde bilgi güvenliği izleme özelliği sunmadığını fark edeceksiniz. Bu hoş olmayan bir durum ama aynı zamanda çok da az değil çünkü bu bulutla çalışmayla ilişkili risk düzeyini yeterince değerlendirmenize olanak tanıyor.

Bulut Güvenliği İzleme Yaşam Döngüsü

Kullandığınız bulutların güvenliğini izlemek için yalnızca üç seçeneğiniz vardır:

• bulut sağlayıcınız tarafından sağlanan araçlara güvenin,
• Kullandığınız IaaS, PaaS veya SaaS platformlarını izleyecek üçüncü tarafların çözümlerini kullanma,
• kendi bulut izleme altyapınızı oluşturun (yalnızca IaaS/PaaS platformları için).

Bu seçeneklerin her birinin hangi özelliklere sahip olduğunu görelim. Ancak öncelikle bulut platformlarını izlerken kullanılacak genel çerçeveyi anlamamız gerekiyor. Buluttaki bilgi güvenliği izleme sürecinin 6 ana bileşenini vurgulayacağım:

• Altyapının hazırlanması. Bilgi güvenliği açısından önemli olayların depolama alanında toplanması için gerekli uygulama ve altyapının belirlenmesi.
• Toplamak. Bu aşamada, güvenlik olayları, işleme, depolama ve analiz amacıyla daha sonra iletilmek üzere çeşitli kaynaklardan toplanır.
• Tedavi. Bu aşamada veriler daha sonraki analizleri kolaylaştırmak için dönüştürülür ve zenginleştirilir.
• Depolamak. Bu bileşen, toplanan işlenmiş ve ham verilerin kısa süreli ve uzun süreli depolanmasından sorumludur.
• Analiz. Bu aşamada olayları tespit etme ve bunlara otomatik veya manuel olarak müdahale etme olanağına sahipsiniz.
• Raporlama. Bu aşama, paydaşlara (yönetim, denetçiler, bulut sağlayıcısı, müşteriler vb.) yönelik, örneğin sağlayıcıyı değiştirmek veya bilgi güvenliğini güçlendirmek gibi belirli kararlar almamıza yardımcı olan temel göstergelerin formüle edilmesine yardımcı olur.

Bu bileşenleri anlamak, gelecekte sağlayıcınızdan neler alabileceğinize ve kendi başınıza veya harici danışmanların katılımıyla ne yapmanız gerektiğine hızlı bir şekilde karar vermenize olanak sağlayacaktır.

Yerleşik bulut hizmetleri

Yukarıda zaten günümüzde birçok bulut hizmetinin herhangi bir bilgi güvenliği izleme yeteneği sağlamadığını yazmıştım. Genel olarak bilgi güvenliği konusuna pek önem vermiyorlar. Örneğin, internet üzerinden devlet kurumlarına rapor göndermeye yönelik popüler Rus hizmetlerinden biri (adını özellikle belirtmeyeceğim). Bu hizmetin güvenliğiyle ilgili bölümün tamamı sertifikalı CIPF kullanımı etrafında dönmektedir. Elektronik belge yönetimine yönelik bir başka yerli bulut hizmetinin bilgi güvenliği bölümü de farklı değil. Açık anahtar sertifikalarından, sertifikalı kriptografiden, web açıklarının ortadan kaldırılmasından, DDoS saldırılarına karşı korumadan, güvenlik duvarlarının kullanılmasından, yedeklemelerden ve hatta düzenli bilgi güvenliği denetimlerinden bahsediyor. Ancak izleme veya bu hizmet sağlayıcının müşterilerinin ilgisini çekebilecek bilgi güvenliği olaylarına erişim sağlama olasılığı hakkında tek bir kelime yok.

Genel olarak bulut sağlayıcının web sitesinde ve dokümantasyonunda bilgi güvenliği sorunlarını anlatmasından bu konuyu ne kadar ciddiye aldığını anlayabilirsiniz. Örneğin, “Ofisim” ürünlerinin kılavuzlarını okursanız, güvenlikle ilgili tek bir kelime bile olmadığını, ancak “Ofisim” ayrı ürününün belgelerinde olduğunu görürsünüz. Yetkisiz erişime karşı koruma sağlamak için tasarlanan "KS3", "Ofisim.KS17" tarafından uygulanan FSTEC'in 3. sırasına ait noktaların olağan bir listesi vardır, ancak bunu nasıl uyguladığı ve en önemlisi nasıl yapılacağı açıklanmamıştır. bu mekanizmaları kurumsal bilgi güvenliğiyle entegre edin. Belki bu tür belgeler mevcuttur, ancak bunu kamuya açık olarak "Ofisim" web sitesinde bulamadım. Her ne kadar bu gizli bilgiye erişimim olmasa da?..

Bitrix için durum çok daha iyi. Belgeler, olay günlüklerinin formatlarını ve ilginç bir şekilde, bulut platformuna yönelik potansiyel tehditlerle ilgili olayları içeren izinsiz giriş günlüğünü açıklar. Buradan IP'yi, kullanıcı veya konuk adını, etkinlik kaynağını, zamanı, Kullanıcı Aracısını, etkinlik türünü vb. çıkarabilirsiniz. Doğru, bu olaylarla bulutun kontrol panelinden çalışabilir veya verileri MS Excel formatında yükleyebilirsiniz. Artık Bitrix loglarıyla çalışmayı otomatikleştirmek zor ve işin bir kısmını manuel olarak yapmanız gerekecek (raporu yüklemek ve SIEM'inize yüklemek). Ancak yakın zamana kadar böyle bir fırsatın bulunmadığını hatırlarsak, bu büyük bir ilerlemedir. Aynı zamanda, birçok yabancı bulut sağlayıcısının "yeni başlayanlar için" benzer işlevler sunduğunu da belirtmek isterim - ya kontrol panelinden günlüklere gözlerinizle bakın ya da verileri kendinize yükleyin (ancak çoğu veriyi . csv biçiminde, Excel değil).

Günlük tutmama seçeneğini dikkate almadan, bulut sağlayıcıları genellikle güvenlik olaylarını izlemek için size üç seçenek sunar: kontrol panelleri, veri yükleme ve API erişimi. İlki sizin için birçok sorunu çözüyor gibi görünüyor, ancak bu tamamen doğru değil - eğer birden fazla derginiz varsa, bunları görüntüleyen ekranlar arasında geçiş yapmanız gerekir, bu da genel resmi kaybeder. Ek olarak, bulut sağlayıcısının size güvenlik olaylarını ilişkilendirme ve bunları genel olarak güvenlik açısından analiz etme yeteneğini sağlaması pek olası değildir (genellikle kendinizin anlaması gereken ham verilerle uğraşırsınız). İstisnalar var ve onlar hakkında daha fazla konuşacağız. Son olarak, bulut sağlayıcınız tarafından hangi olayların hangi formatta kaydedildiğini ve bunların bilgi güvenliği izleme sürecinize nasıl karşılık geldiğini sormakta fayda var. Örneğin, kullanıcıların ve misafirlerin tanımlanması ve kimlik doğrulaması. Aynı Bitrix, bu olaylara dayalı olarak olayın tarih ve saatini, kullanıcının veya konuğun adını (“Web Analitiği” modülünüz varsa), erişilen nesneyi ve bir web sitesi için tipik olan diğer unsurları kaydetmenize olanak tanır. . Ancak kurumsal bilgi güvenliği hizmetleri, kullanıcının buluta güvenilir bir cihazdan erişip erişmediğine ilişkin bilgiye ihtiyaç duyabilir (örneğin, kurumsal bir ağda bu görev Cisco ISE tarafından uygulanır). Bir bulut hizmeti kullanıcı hesabının çalınıp çalınmadığını belirlemeye yardımcı olacak geo-IP işlevi gibi basit bir göreve ne dersiniz? Ve bulut sağlayıcı bunu size sağlasa bile bu yeterli değildir. Aynı Cisco CloudLock yalnızca coğrafi konumu analiz etmez, bunun için makine öğrenimini kullanır ve her kullanıcı için geçmiş verileri analiz eder ve tanımlama ve kimlik doğrulama girişimlerindeki çeşitli anormallikleri izler. Yalnızca MS Azure benzer işlevlere sahiptir (uygun aboneliğiniz varsa).

Başka bir zorluk daha var; birçok bulut sağlayıcı için bilgi güvenliği izleme, yeni ele almaya başladıkları yeni bir konu olduğundan, çözümlerinde sürekli bir şeyler değiştiriyorlar. Bugün API'nin bir sürümüne sahipler, yarın başka bir sürüme, yarından sonraki gün ise üçte birine. Buna da hazırlıklı olmanız gerekiyor. Aynı durum, bilgi güvenliği izleme sisteminizde dikkate alınması gereken, değişebilecek işlevsellik için de geçerlidir. Örneğin, Amazon başlangıçta ayrı bulut olay izleme hizmetlerine sahipti: AWS CloudTrail ve AWS CloudWatch. Ardından bilgi güvenliği olaylarını izlemek için ayrı bir hizmet ortaya çıktı - AWS GuardDuty. Bir süre sonra Amazon, GuardDuty, Amazon Inspector, Amazon Macie ve diğerlerinden alınan verilerin analizini içeren yeni bir yönetim sistemi olan Amazon Security Hub'ı başlattı. Başka bir örnek, SIEM - AzLog ile Azure günlük entegrasyon aracıdır. Birçok SIEM satıcısı tarafından aktif olarak kullanıldı, ta ki 2018 yılında Microsoft, geliştirme ve desteğinin durdurulduğunu duyurana kadar, bu aracı kullanan birçok müşteriyi sorunla karşı karşıya bıraktı (nasıl çözüldüğüne daha sonra değineceğiz).

Bu nedenle bulut sağlayıcınızın size sunduğu tüm izleme özelliklerini dikkatle izleyin. Veya SOC'niz ile izlemek istediğiniz bulut arasında aracı görevi görecek harici çözüm sağlayıcılara güvenin. Evet, daha pahalı olacak (her zaman olmasa da), ancak tüm sorumluluğu başkasının omuzlarına yükleyeceksiniz. Yoksa hepsi değil mi?.. Paylaşılan güvenlik kavramını hatırlayalım ve hiçbir şeyi değiştiremeyeceğimizi anlayalım - farklı bulut sağlayıcılarının verilerinizin, uygulamalarınızın, sanal makinelerinizin ve diğer kaynaklarınızın bilgi güvenliğinin izlenmesini nasıl sağladığını bağımsız olarak anlamamız gerekecek bulutta barındırılıyor. Ve Amazon'un bu bölümde sunduklarıyla başlayacağız.

Örnek: AWS'yi temel alan IaaS'de bilgi güvenliği izleme

Evet, evet, bunun bir Amerikan hizmeti olması ve aşırıcılıkla mücadele ve Rusya'da yasaklanan bilgilerin yayılması kapsamında engellenebilmesi nedeniyle Amazon'un en iyi örnek olmadığını anlıyorum. Ancak bu yayında, farklı bulut platformlarının bilgi güvenliği izleme yetenekleri açısından ne kadar farklı olduğunu ve güvenlik açısından önemli süreçlerinizi bulutlara aktarırken nelere dikkat etmeniz gerektiğini göstermek istiyorum. Eğer bazı Rus bulut çözümü geliştiricileri kendileri için yararlı bir şeyler öğrenirse, bu harika olur.

Söylenecek ilk şey Amazon'un aşılmaz bir kale olmadığıdır. Müşterilerinin başına düzenli olarak çeşitli olaylar geliyor. Örneğin 198 milyon seçmenin isimleri, adresleri, doğum tarihleri ​​ve telefon numaraları Deep Root Analytics'ten çalındı. İsrailli şirket Nice Systems, Verizon abonelerinin 14 milyon kaydını çaldı. Ancak AWS'nin yerleşik yetenekleri çok çeşitli olayları tespit etmenize olanak tanır. Örneğin:

• Altyapı üzerindeki etki (DDoS)
• düğüm güvenliği (komut enjeksiyonu)
• hesap güvenliğinin ihlali ve yetkisiz erişim
• Yanlış yapılandırma ve güvenlik açıkları
• güvensiz arayüzler ve API'ler.

Bu tutarsızlık, yukarıda da belirttiğimiz gibi, müşteri verilerinin güvenliğinden müşterinin kendisinin sorumlu olmasından kaynaklanmaktadır. Ve eğer koruyucu mekanizmaları devreye sokma zahmetine girmediyse ve izleme araçlarını devreye sokmadıysa, o zaman olayı yalnızca medyadan veya müşterilerinden öğrenecektir.

Olayları tanımlamak için Amazon tarafından geliştirilen çok çeşitli farklı izleme hizmetlerini kullanabilirsiniz (ancak bunlar genellikle osquery gibi harici araçlarla tamamlanır). Yani AWS'de tüm kullanıcı eylemleri, nasıl gerçekleştirildiklerine bakılmaksızın yönetim konsolu, komut satırı, SDK veya diğer AWS hizmetleri aracılığıyla izlenir. Her AWS hesabının etkinliğine (kullanıcı adı, eylem, hizmet, etkinlik parametreleri ve sonuç dahil) ve API kullanımına ilişkin tüm kayıtlara AWS CloudTrail aracılığıyla ulaşılabilir. Bu olayları (AWS IAM konsolu oturum açma bilgileri gibi) CloudTrail konsolundan görüntüleyebilir, bunları Amazon Athena kullanarak analiz edebilir veya bunları Splunk, AlienVault vb. gibi harici çözümlere "dış kaynaklardan sağlayabilirsiniz". AWS CloudTrail günlükleri AWS S3 klasörünüze yerleştirilir.

Diğer iki AWS hizmeti bir dizi başka önemli izleme özelliği sağlar. Öncelikle Amazon CloudWatch, AWS kaynaklarına ve uygulamalarına yönelik bir izleme hizmetidir ve diğer şeylerin yanı sıra bulutunuzdaki çeşitli anormallikleri tanımlamanıza olanak tanır. Amazon Elastic Compute Cloud (sunucular), Amazon Relational Database Service (veritabanları), Amazon Elastic MapReduce (veri analizi) ve diğer 30 Amazon hizmeti gibi tüm yerleşik AWS hizmetleri, günlüklerini depolamak için Amazon CloudWatch'u kullanır. Geliştiriciler, özel uygulamalara ve hizmetlere günlük izleme işlevselliği eklemek için Amazon CloudWatch'un açık API'sini kullanabilir ve böylece bir güvenlik bağlamında olay analizinin kapsamını genişletebilirler.

İkinci olarak, VPC Akış Günlükleri hizmeti, AWS sunucularınız (harici veya dahili) tarafından ve ayrıca mikro hizmetler arasında gönderilen veya alınan ağ trafiğini analiz etmenize olanak tanır. AWS VPC kaynaklarınızdan herhangi biri ağ ile etkileşime girdiğinde VPC Akış Günlükleri, kaynak ve hedef ağ arayüzünün yanı sıra IP adresleri, bağlantı noktaları, protokol, bayt sayısı ve paket sayısını da içeren ağ trafiğine ilişkin ayrıntıları kaydeder. testere. Yerel ağ güvenliği konusunda deneyimli olanlar bunun iş parçacıklarına benzer olduğunu anlayacaklardır. Net akışanahtarlar, yönlendiriciler ve kurumsal düzeydeki güvenlik duvarları tarafından oluşturulabilir. Bu günlükler, bilgi güvenliği izleme açısından önemlidir çünkü kullanıcıların ve uygulamaların eylemleriyle ilgili olaylardan farklı olarak, AWS sanal özel bulut ortamındaki ağ etkileşimlerini kaçırmamanıza da olanak tanır.

Özetle, bu üç AWS hizmeti (AWS CloudTrail, Amazon CloudWatch ve VPC Flow Logs) birlikte hesap kullanımınız, kullanıcı davranışınız, altyapı yönetiminiz, uygulama ve hizmet etkinliğiniz ile ağ etkinliğiniz hakkında oldukça güçlü bilgiler sağlar. Örneğin aşağıdaki anormallikleri tespit etmek için kullanılabilirler:

• Siteyi taramaya, arka kapıları aramaya, "404 hataları" patlamaları yoluyla güvenlik açıklarını aramaya çalışır.
• Enjeksiyon saldırıları (örneğin, SQL enjeksiyonu) "500 hata" patlaması yoluyla.
• Bilinen saldırı araçları sqlmap, nikto, w3af, nmap vb.'dir. Kullanıcı Aracısı alanının analizi yoluyla.

Amazon Web Services ayrıca siber güvenlik amaçlı, diğer birçok sorunu çözmenize olanak tanıyan başka hizmetler de geliştirmiştir. Örneğin, AWS'nin politikaları ve yapılandırmaları denetlemeye yönelik yerleşik bir hizmeti vardır: AWS Config. Bu hizmet, AWS kaynaklarınızın ve yapılandırmalarının sürekli denetlenmesini sağlar. Basit bir örnek verelim: Diyelim ki tüm sunucularınızda kullanıcı şifrelerinin devre dışı bırakıldığından ve erişimin yalnızca sertifikalara dayalı olarak mümkün olduğundan emin olmak istiyorsunuz. AWS Config, tüm sunucularınız için bunu kontrol etmenizi kolaylaştırır. Bulut sunucularınıza uygulanabilecek başka politikalar da vardır: “Hiçbir sunucu 22 numaralı bağlantı noktasını kullanamaz”, “Yalnızca yöneticiler güvenlik duvarı kurallarını değiştirebilir” veya “Yalnızca Ivashko kullanıcısı yeni kullanıcı hesapları oluşturabilir ve bunu yalnızca Salı günleri yapabilir. " 2016 yazında AWS Config hizmeti, geliştirilen politikaların ihlallerinin tespitini otomatikleştirecek şekilde genişletildi. AWS Config Kuralları, kullandığınız Amazon hizmetlerine yönelik, ilgili politikaların ihlal edilmesi durumunda olaylar oluşturan sürekli yapılandırma istekleridir. Örneğin, bir sanal sunucudaki tüm disklerin şifrelendiğini doğrulamak için düzenli aralıklarla AWS Config sorguları çalıştırmak yerine, bu koşulun karşılandığından emin olmak amacıyla sunucu disklerini sürekli olarak kontrol etmek için AWS Config Kuralları kullanılabilir. Ve en önemlisi, bu yayın bağlamında, herhangi bir ihlal, bilgi güvenliği servisiniz tarafından analiz edilebilecek olaylara neden olur.

AWS'nin aynı zamanda analiz edebileceğiniz ve analiz etmeniz gereken güvenlik olaylarını da üreten geleneksel kurumsal bilgi güvenliği çözümlerinin eşdeğeri de vardır:

• İzinsiz Giriş Tespiti - AWS GuardDuty
• Bilgi Sızıntısı Kontrolü - AWS Macie
• EDR (buluttaki uç noktalardan biraz tuhaf bahsetse de) - AWS Cloudwatch + açık kaynak osquery veya GRR çözümleri
• Netflow analizi - AWS Cloudwatch + AWS VPC Flow
• DNS analizi - AWS Cloudwatch + AWS Route53
• AD - AWS Dizin Hizmeti
• Hesap Yönetimi - AWS IAM
• SSO - AWS SSO
• güvenlik analizi - AWS Denetçisi
• yapılandırma yönetimi - AWS Config
• WAF - AWS WAF.

Bilgi güvenliği bağlamında faydalı olabilecek tüm Amazon hizmetlerini detaylı olarak anlatmayacağım. Önemli olan, bunların hepsinin bilgi güvenliği bağlamında analiz edebileceğimiz ve analiz etmemiz gereken olaylar üretebileceğini anlamaktır; bu amaçla hem Amazon'un yerleşik yeteneklerini hem de SIEM gibi harici çözümleri kullanabiliriz. Güvenlik olaylarını izleme merkezinize götürün ve bunları diğer bulut hizmetlerinden veya dahili altyapıdan, çevreden veya mobil cihazlardan gelen olaylarla birlikte orada analiz edin.

Her durumda her şey size bilgi güvenliği olaylarını sağlayan veri kaynaklarıyla başlar. Bu kaynaklar aşağıdakileri içerir ancak bunlarla sınırlı değildir:

• CloudTrail - API Kullanımı ve Kullanıcı İşlemleri
• Güvenilir Danışman - en iyi uygulamalara göre güvenlik kontrolü
• Yapılandırma - hesapların ve hizmet ayarlarının envanteri ve yapılandırması
• VPC Akış Günlükleri - sanal arayüzlere bağlantılar
• IAM - tanımlama ve kimlik doğrulama hizmeti
• ELB Erişim Günlükleri - Yük Dengeleyici
• Denetçi - uygulama güvenlik açıkları
• S3 - dosya depolama
• CloudWatch - Uygulama Etkinliği
• SNS bir bildirim hizmetidir.

Amazon, bunların oluşturulması için bu kadar çeşitli olay kaynakları ve araçları sunarken, toplanan verileri bilgi güvenliği bağlamında analiz etme becerisi oldukça sınırlıdır. Mevcut günlükleri bağımsız olarak incelemeniz ve içlerindeki ilgili uzlaşma göstergelerini aramanız gerekecektir. Amazon'un yakın zamanda kullanıma sunduğu AWS Security Hub, AWS için bulut SIEM haline gelerek bu sorunu çözmeyi hedefliyor. Ancak şu ana kadar yolculuğunun yalnızca başında ve hem birlikte çalıştığı kaynakların sayısı hem de Amazon'un mimarisi ve abonelikleri tarafından belirlenen diğer kısıtlamalar nedeniyle sınırlı.

Örnek: Azure'a dayalı IaaS'de bilgi güvenliği izleme

Üç bulut sağlayıcısından hangisinin (Amazon, Microsoft veya Google) daha iyi olduğu konusunda uzun bir tartışmaya girmek istemiyorum (özellikle her birinin hala kendine özgü özellikleri olduğu ve kendi sorunlarını çözmeye uygun olduğu için); Bu oyuncuların sağladığı bilgi güvenliği izleme yeteneklerine odaklanalım. Amazon AWS'nin bu segmentteki ilklerden biri olduğunu ve bu nedenle bilgi güvenliği işlevleri açısından en ileri seviyeye ulaştığını kabul etmek gerekir (her ne kadar çoğu kişi bunların kullanımının zor olduğunu kabul etse de). Ancak bu, Microsoft ve Google'ın bize sunduğu fırsatları görmezden geleceğimiz anlamına gelmiyor.

Microsoft ürünleri her zaman “açıklıkları” ile öne çıkmıştır ve Azure'da da durum benzerdir. Örneğin AWS ve GCP her zaman “izin verilmeyen yasaktır” kavramından hareket ediyorsa Azure'un tam tersi bir yaklaşımı var. Örneğin, bulutta bir sanal ağ ve içinde bir sanal makine oluştururken, tüm bağlantı noktaları ve protokoller açıktır ve varsayılan olarak bunlara izin verilir. Bu nedenle Microsoft'tan buluttaki erişim kontrol sisteminin ilk kurulumuna biraz daha fazla çaba harcamanız gerekecek. Bu aynı zamanda Azure bulutundaki etkinliklerin izlenmesi açısından da size daha sıkı gereksinimler getirmektedir.

AWS'nin, sanal kaynaklarınızı izlediğinizde, farklı bölgelerde bulunuyorlarsa, tüm olayları ve bunların birleşik analizini birleştirmede zorluk yaşamanız ve bunu ortadan kaldırmak için çeşitli hilelere başvurmanız gerektiği gerçeğiyle ilgili bir tuhaflık vardır: Olayları bölgeler arasında aktaracak AWS Lambda için kendi kodunuzu oluşturun. Azure'un bu sorunu yoktur; Etkinlik Günlüğü mekanizması, tüm kuruluştaki tüm etkinlikleri kısıtlama olmaksızın izler. Aynı durum, birçok güvenlik işlevini tek bir güvenlik merkezinde birleştirmek için yakın zamanda Amazon tarafından geliştirilen, ancak yalnızca kendi bölgesi içinde olan ve Rusya ile ilgili olmayan AWS Security Hub için de geçerlidir. Azure, bölgesel kısıtlamalara bağlı olmayan, bulut platformunun tüm güvenlik özelliklerine erişim sağlayan kendi Güvenlik Merkezine sahiptir. Ayrıca, farklı yerel ekipler için, onlar tarafından yönetilen güvenlik olayları da dahil olmak üzere, kendi koruma yeteneklerini sağlayabilir. AWS Security Hub hâlâ Azure Güvenlik Merkezi'ne benzer olma yolunda ilerlemektedir. Ancak merhemin içine bir sinek eklemeye değer - daha önce AWS'de açıklananların çoğunu Azure'dan sıkabilirsiniz, ancak bu en uygun şekilde yalnızca Azure AD, Azure Monitor ve Azure Güvenlik Merkezi için yapılır. Güvenlik olayı analizi de dahil olmak üzere diğer tüm Azure güvenlik mekanizmaları henüz en uygun şekilde yönetilmemektedir. Sorun, tüm Microsoft Azure hizmetlerine nüfuz eden API tarafından kısmen çözüldü, ancak bu, bulutunuzu SOC'nizle entegre etmek için ek çaba göstermenizi ve nitelikli uzmanların varlığını gerektirecektir (aslında bulutla çalışan diğer SIEM'lerde olduğu gibi) API'ler). Daha sonra tartışılacak olan bazı SIEM'ler zaten Azure'u destekliyor ve izleme görevini otomatikleştirebiliyor ancak aynı zamanda kendi zorlukları da var; hepsi Azure'un sahip olduğu tüm günlükleri toplayamıyor.

Azure'da olay toplama ve izleme, Microsoft bulutunda ve onun kaynaklarında (Git depoları, kapsayıcılar, sanal makineler, uygulamalar vb.) veri toplamak, depolamak ve analiz etmek için ana araç olan Azure Monitor hizmeti kullanılarak sağlanır. Azure İzleyici tarafından toplanan tüm veriler iki kategoriye ayrılır: gerçek zamanlı olarak toplanan ve Azure bulutunun temel performans göstergelerini açıklayan ölçümler ve Azure kaynakları ve hizmetlerinin etkinliğinin belirli yönlerini karakterize eden kayıtlar halinde düzenlenmiş verileri içeren günlükler. Ayrıca Azure Monitor hizmeti, Veri Toplayıcı API'sini kullanarak kendi izleme senaryolarını oluşturmak için herhangi bir REST kaynağından veri toplayabilir.

Azure'un size sunduğu ve Azure Portal, CLI, PowerShell veya REST API (ve bazılarına yalnızca Azure Monitor/Insight API aracılığıyla) aracılığıyla erişebileceğiniz birkaç güvenlik olay kaynağı şunlardır:

• Etkinlik Günlükleri - bu günlük, bulut kaynakları üzerindeki herhangi bir yazma işlemine (PUT, POST, DELETE) ilişkin klasik "kim", "ne" ve "ne zaman" sorularını yanıtlar. Okuma erişimiyle (GET) ilgili olaylar, diğerleri gibi bu günlüğe dahil edilmez.
• Tanılama Günlükleri - aboneliğinize dahil edilen belirli bir kaynakla yapılan işlemlere ilişkin verileri içerir.
• Azure AD raporlaması - grup ve kullanıcı yönetimiyle ilgili hem kullanıcı etkinliğini hem de sistem etkinliğini içerir.
• Windows Olay Günlüğü ve Linux Sistem Günlüğü - bulutta barındırılan sanal makinelerden gelen olayları içerir.
• Metrikler - bulut hizmetlerinizin ve kaynaklarınızın performansı ve sağlık durumuna ilişkin telemetriyi içerir. Dakikada bir ölçülür ve saklanır. 30 gün içinde.
• Ağ Güvenliği Grubu Akış Günlükleri - Ağ İzleyici hizmeti ve ağ düzeyinde kaynak izleme kullanılarak toplanan ağ güvenliği olaylarına ilişkin verileri içerir.
• Depolama Günlükleri - depolama tesislerine erişimle ilgili olayları içerir.

İzleme için harici SIEM'leri veya yerleşik Azure İzleyici'yi ve uzantılarını kullanabilirsiniz. Bilgi güvenliği olay yönetimi sistemlerine daha sonra değineceğiz ancak şimdilik güvenlik bağlamında veri analizi için Azure'un bizzat bize neler sunduğuna bakalım. Azure İzleyici'de güvenlikle ilgili her şeyin ana ekranı Log Analytics Güvenlik ve Denetim Kontrol Panelidir (ücretsiz sürüm yalnızca bir hafta boyunca sınırlı miktarda olay depolamayı destekler). Bu kontrol paneli, kullandığınız bulut ortamında olup bitenlerin özet istatistiklerini görselleştiren 5 ana alana bölünmüştür:

• Güvenlik Etki Alanları - bilgi güvenliğiyle ilgili temel niceliksel göstergeler - olayların sayısı, tehlikeye atılan düğümlerin sayısı, yama yapılmamış düğümler, ağ güvenliği olayları vb.
• Önemli Sorunlar - aktif bilgi güvenliği sorunlarının sayısını ve önemini görüntüler
• Tespitler - size karşı kullanılan saldırı modellerini görüntüler
• Tehdit İstihbaratı - size saldıran harici düğümlere ilişkin coğrafi bilgileri görüntüler
• Yaygın güvenlik sorguları - bilgi güvenliğinizi daha iyi izlemenize yardımcı olacak tipik sorgular.

Azure Monitor uzantıları arasında Azure Key Vault (buluttaki şifreleme anahtarlarının korunması), Kötü Amaçlı Yazılım Değerlendirmesi (sanal makinelerdeki kötü amaçlı kodlara karşı korumanın analizi), Azure Application Gateway Analytics (diğer şeylerin yanı sıra bulut güvenlik duvarı günlüklerinin analizi) vb. bulunur. . Olayları işlemeye yönelik belirli kurallarla zenginleştirilmiş bu araçlar, güvenlik de dahil olmak üzere bulut hizmetlerinin etkinliğinin çeşitli yönlerini görselleştirmenize ve operasyondan belirli sapmaları belirlemenize olanak tanır. Ancak çoğu zaman olduğu gibi, herhangi bir ek işlevsellik, karşılık gelen bir ücretli abonelik gerektirir; bu da, önceden planlamanız gereken karşılık gelen finansal yatırımları gerektirir.

Azure, Azure AD, Azure Monitor ve Azure Güvenlik Merkezi ile tümleşik bir dizi yerleşik tehdit izleme özelliğine sahiptir. Bunlar arasında, örneğin, sanal makinelerin bilinen kötü amaçlı IP'lerle etkileşiminin tespiti (Microsoft'un Tehdit İstihbaratı hizmetleriyle entegrasyonun varlığı nedeniyle), bulutta barındırılan sanal makinelerden alarmlar alınarak bulut altyapısındaki kötü amaçlı yazılımların tespiti, şifre, şifre sanal makinelere yapılan "tahmin saldırıları", kullanıcı tanımlama sisteminin yapılandırmasındaki güvenlik açıkları, anonimleştiricilerden veya virüslü düğümlerden sisteme giriş yapılması, hesap sızıntıları, alışılmadık konumlardan sisteme giriş yapılması vb. Bugün Azure, toplanan bilgi güvenliği olaylarını zenginleştirmek için size yerleşik Tehdit İstihbaratı yetenekleri sunan birkaç bulut sağlayıcısından biridir.

Yukarıda bahsedildiği gibi, güvenlik işlevselliği ve bunun sonucunda oluşturulan güvenlik olayları, tüm kullanıcılar tarafından eşit şekilde kullanılamamaktadır, ancak bilgi güvenliğinin izlenmesi için uygun olayları üreten, ihtiyacınız olan işlevselliği içeren belirli bir abonelik gerektirir. Örneğin, hesaplardaki anormallikleri izlemeye yönelik önceki paragrafta açıklanan işlevlerden bazıları yalnızca Azure AD hizmetinin P2 premium lisansında mevcuttur. Bu olmadan, AWS'de olduğu gibi, toplanan güvenlik olaylarını "manuel olarak" analiz etmeniz gerekecektir. Ayrıca Azure AD lisansının türüne bağlı olarak tüm olaylar analiz için mevcut olmayacaktır.

Azure portalında hem ilginizi çeken günlüklere yönelik arama sorgularını yönetebilir hem de önemli bilgi güvenliği göstergelerini görselleştirmek için panolar oluşturabilirsiniz. Ayrıca burada, Azure İzleyici günlüklerinin işlevselliğini genişletmenize ve güvenlik açısından olayların daha derin bir analizini almanıza olanak tanıyan Azure İzleyici uzantılarını da seçebilirsiniz.

Yalnızca günlüklerle çalışma yeteneğine değil, aynı zamanda Azure bulut platformunuz için bilgi güvenliği politikası yönetimi de dahil olmak üzere kapsamlı bir güvenlik merkezine ihtiyacınız varsa, o zaman çoğu yararlı işlevi olan Azure Güvenlik Merkezi ile çalışma ihtiyacından bahsedebilirsiniz. Tehdit tespiti, Azure dışında izleme, uyumluluk değerlendirmesi vb. gibi belirli bir ücret karşılığında kullanılabilir. (ücretsiz sürümde yalnızca güvenlik değerlendirmesine ve belirlenen sorunların ortadan kaldırılmasına yönelik önerilere erişebilirsiniz). Tüm güvenlik sorunlarını tek bir yerde birleştirir. Aslında Azure Monitor’ün size sağladığından daha üst seviyede bir bilgi güvenliğinden bahsedebiliriz çünkü bu durumda bulut fabrikanız genelinde toplanan veriler Azure, Office 365, Microsoft CRM online, Microsoft Dynamics AX gibi birçok kaynak kullanılarak zenginleştirilmiştir. , Outlook .com, MSN.com, Microsoft Dijital Suçlar Birimi (DCU) ve Microsoft Güvenlik Yanıt Merkezi (MSRC), çeşitli karmaşık makine öğrenimi ve davranışsal analiz algoritmalarının bir araya getirildiği ve sonuçta tehditleri tespit etme ve bunlara yanıt verme verimliliğini artırması gereken Microsoft Güvenlik Yanıt Merkezi (MSRC) .

Azure'un ayrıca kendi SIEM'i var - 2019'un başında ortaya çıktı. Bu, Azure Monitor'den gelen verilere dayanan ve aynı zamanda entegre olabilen Azure Sentinel'dir. listesi sürekli büyüyen harici güvenlik çözümleri (örneğin, NGFW veya WAF). Ayrıca, Microsoft Graph Security API'nin entegrasyonu aracılığıyla, kendi Tehdit İstihbaratı akışlarınızı Sentinel'e bağlama olanağına sahip olursunuz; bu, Azure bulutunuzdaki olayları analiz etme yeteneklerini zenginleştirir. Azure Sentinel'in, bulut sağlayıcılarından ortaya çıkan ilk "yerel" SIEM olduğu iddia edilebilir (bulutta barındırılabilen aynı Splunk veya ELK, örneğin AWS, hala geleneksel bulut hizmet sağlayıcıları tarafından geliştirilmemiştir). Azure Sentinel ve Güvenlik Merkezi, Azure bulutu için SOC olarak adlandırılabilir ve artık herhangi bir altyapınız yoksa ve tüm bilgi işlem kaynaklarınızı buluta aktardıysanız, bunlarla sınırlı olabilir (belirli rezervasyonlarla) ve bu Microsoft bulut Azure olacaktır.

Ancak Azure'un yerleşik yetenekleri (Sentinel aboneliğiniz olsa bile), bilgi güvenliğini izlemek ve bu süreci diğer güvenlik olayı kaynaklarıyla (hem bulut hem de dahili) entegre etmek amacıyla genellikle yeterli olmadığından, Toplanan verileri SIEM'i de içerebilecek harici sistemlere aktarmanız gerekir. Bu, hem API kullanılarak hem de şu anda resmi olarak yalnızca aşağıdaki SIEM'ler için mevcut olan özel uzantılar kullanılarak yapılır: Splunk (Splunk için Azure Monitör Eklentisi), IBM QRadar (Microsoft Azure DSM), SumoLogic, ArcSight ve ELK. Yakın zamana kadar bu tür SIEM'ler daha fazlaydı, ancak 1 Haziran 2019'dan itibaren Microsoft, Azure'un varlığının başlangıcında ve günlüklerle çalışmanın normal standardizasyonunun yokluğunda (Azure) Azure Günlük Entegrasyon Aracını (AzLog) desteklemeyi bıraktı. Monitör henüz mevcut bile değildi) harici SIEM'i Microsoft bulutuyla entegre etmeyi kolaylaştırdı. Artık durum değişti ve Microsoft, diğer SIEM'ler için ana entegrasyon aracı olarak Azure Event Hub platformunu öneriyor. Birçoğu bu tür bir entegrasyonu zaten uygulamıştır, ancak dikkatli olun; tüm Azure günlüklerini değil, yalnızca bazılarını yakalayabilirler (SIEM'inizin belgelerine bakın).

Azure'a kısa bir gezimizi sonlandırırken, bu bulut hizmeti hakkında genel bir öneride bulunmak istiyorum; Azure'daki bilgi güvenliği izleme işlevleri hakkında herhangi bir şey söylemeden önce, bunları çok dikkatli bir şekilde yapılandırmalı ve belgelerde yazıldığı gibi çalışıp çalışmadığını test etmelisiniz. danışmanların size Microsoft'a söylediği gibi (ve Azure işlevlerinin işlevselliği konusunda farklı görüşlere sahip olabilirler). Mali kaynaklarınız varsa, bilgi güvenliği izleme açısından Azure'dan pek çok yararlı bilgiyi çıkarabilirsiniz. Kaynaklarınız sınırlıysa AWS'de olduğu gibi yalnızca kendi gücünüze ve Azure Monitor'ün size sağladığı ham verilere güvenmeniz gerekir. Ayrıca birçok izleme fonksiyonunun maliyetli olduğunu ve fiyatlandırma politikasını önceden öğrenmenin daha iyi olacağını unutmayın. Örneğin, müşteri başına maksimum 31 GB'a kadar 5 günlük veriyi ücretsiz olarak depolayabilirsiniz - bu değerlerin aşılması, ek para ödemenizi gerektirir (müşteriden gelen her ek GB'yi depolamak için yaklaşık 2 ABD Doları + ve müşteri için 0,1 ABD Doları). her ek ayda 1 GB depolama). Uygulama telemetrisi ve metrikleriyle çalışmak, uyarılar ve bildirimlerle çalışmanın yanı sıra ek fonlar da gerektirebilir (belirli bir limit ücretsiz olarak mevcuttur, bu ihtiyaçlarınız için yeterli olmayabilir).

Örnek: Google Cloud Platform'u temel alan IaaS'de bilgi güvenliği izleme

Google Cloud Platform, AWS ve Azure ile karşılaştırıldığında daha genç görünüyor ancak bu kısmen iyi. Güvenlik yetenekleri de dahil olmak üzere yeteneklerini giderek artıran, merkezileşme konusunda sorunlar yaşayan AWS'den farklı olarak; Azure gibi GCP de merkezi olarak çok daha iyi yönetilir; bu da kuruluş genelinde hataları ve uygulama süresini azaltır. Güvenlik açısından bakıldığında GCP, tuhaf bir şekilde, AWS ile Azure arasındadır. Ayrıca tüm organizasyon için tek bir etkinlik kaydı var ancak eksik. Bazı işlevler hala beta modundadır ancak yavaş yavaş bu eksikliğin giderilmesi ve GCP'nin bilgi güvenliği izleme açısından daha olgun bir platform haline gelmesi gerekmektedir.

GCP'de olayları günlüğe kaydetmeye yönelik ana araç, tüm bulut altyapınızdaki (ve AWS'deki) olayları toplamanıza olanak tanıyan Stackdriver Logging'dir (Azure Monitor'e benzer). GCP'de güvenlik açısından bakıldığında her kuruluşun, projenin veya klasörün dört günlüğü vardır:

• Yönetici Etkinliği - sanal makine oluşturma, erişim haklarını değiştirme vb. gibi yönetim erişimiyle ilgili tüm olayları içerir. Bu günlük, isteğiniz ne olursa olsun her zaman yazılır ve verileri 400 gün boyunca saklanır.
• Veri Erişimi - bulut kullanıcılarının verilerle çalışmasına ilişkin tüm olayları içerir (oluşturma, değiştirme, okuma vb.). Varsayılan olarak bu günlük yazılmaz çünkü hacmi çok hızlı artar. Bu nedenle raf ömrü sadece 30 gündür. Ayrıca bu dergide her şey yazılmıyor. Örneğin, tüm kullanıcıların herkese açık olarak erişebildiği veya GCP'de oturum açmadan erişilebilen kaynaklarla ilgili etkinlikler buraya yazılmaz.
• Sistem Olayı - kullanıcılarla ilgili olmayan sistem olaylarını veya bulut kaynaklarının yapılandırmasını değiştiren bir yöneticinin eylemlerini içerir. Her zaman 400 gün boyunca yazılır ve saklanır.
• Erişim Şeffaflığı, iş görevleri kapsamında altyapınıza erişen Google çalışanlarının (ancak henüz tüm GCP hizmetleri için değil) tüm eylemlerini kaydeden benzersiz bir günlük örneğidir. Bu günlük 400 gün boyunca saklanır ve her GCP müşterisi tarafından kullanılamaz, ancak yalnızca bir dizi koşulun karşılanması durumunda kullanılabilir (Altın veya Platin düzeyinde destek veya kurumsal desteğin bir parçası olarak belirli türde 4 rolün varlığı). Benzer bir işlev, örneğin Office 365 - Kilitli Kutu'da da mevcuttur.

Günlük örneği: Erişim Şeffaflığı

{
 insertId:  "abcdefg12345"
 jsonPayload: {
  @type:  "type.googleapis.com/google.cloud.audit.TransparencyLog"
  location: {
   principalOfficeCountry:  "US"
   principalEmployingEntity:  "Google LLC"
   principalPhysicalLocationCountry:  "CA"
  }
  product: [
   0:  "Cloud Storage"
  ]
  reason: [
    detail:  "Case number: bar123"
    type:  "CUSTOMER_INITIATED_SUPPORT"
  ]
  accesses: [
   0: {
    methodName: "GoogleInternal.Read"
    resourceName: "//googleapis.com/storage/buckets/[BUCKET_NAME]/objects/foo123"
    }
  ]
 }
 logName:  "projects/[PROJECT_NAME]/logs/cloudaudit.googleapis.com%2Faccess_transparency"
 operation: {
  id:  "12345xyz"
 }
 receiveTimestamp:  "2017-12-18T16:06:37.400577736Z"
 resource: {
  labels: {
   project_id:  "1234567890"
  }
  type:  "project"
 }
 severity:  "NOTICE"
 timestamp:  "2017-12-18T16:06:24.660001Z"
}

Bu günlüklere erişim birkaç yolla mümkündür (daha önce tartışılan Azure ve AWS ile hemen hemen aynı şekilde): Günlük Görüntüleyici arayüzü aracılığıyla, API aracılığıyla, Google Cloud SDK aracılığıyla veya projenizin etkinlik sayfası aracılığıyla. olaylara meraklıdır. Aynı şekilde ek analiz için harici çözümlere aktarılabilirler. İkincisi, günlüklerin BigQuery'ye veya Cloud Pub/Sub depolama alanına aktarılmasıyla gerçekleştirilir.

GCP platformu, Stackdriver Logging'e ek olarak, bulut hizmetlerinin ve uygulamalarının temel metriklerini (performans, MTBF, genel sağlık vb.) izlemenize olanak tanıyan Stackdriver Monitoring işlevini de sunar. İşlenen ve görselleştirilen veriler, güvenlik bağlamı da dahil olmak üzere bulut altyapınızdaki sorunların bulunmasını kolaylaştırabilir. Ancak, bugün GCP'nin aynı AWS GuardDuty'nin bir analoguna sahip olmaması ve kayıtlı tüm olaylar arasında kötü olanları tespit edememesi nedeniyle bu işlevselliğin bilgi güvenliği bağlamında çok zengin olmayacağına dikkat edilmelidir (Google, Olay Tehdit Algılama'yı geliştirmiştir, ancak hala beta aşamasındadır ve kullanışlılığı hakkında konuşmak için henüz çok erkendir). Stackdriver Monitoring, anormallikleri tespit etmek için bir sistem olarak kullanılabilir ve daha sonra bu anormalliklerin ortaya çıkış nedenleri araştırılabilir. Ancak pazarda GCP bilgi güvenliği alanında nitelikli personel eksikliği göz önüne alındığında bu görev şu anda zor görünüyor.

Ayrıca GCP bulutunuzda kullanılabilecek ve AWS'nin sunduklarına benzer bazı bilgi güvenliği modüllerinin bir listesini vermek de faydalı olacaktır:

• Cloud Security Command Center, AWS Security Hub ve Azure Security Center'ın bir benzeridir.
• Bulut DLP - 90'dan fazla önceden tanımlanmış sınıflandırma ilkesi kullanılarak bulutta barındırılan verilerin otomatik keşfi ve düzenlenmesi (ör. maskeleme).
• Cloud Scanner, App Engine, Compute Engine ve Google Kubernetes'teki bilinen güvenlik açıklarına (XSS, Flash Injection, yama uygulanmamış kitaplıklar vb.) yönelik bir tarayıcıdır.
• Cloud IAM - Tüm GCP kaynaklarına erişimi kontrol edin.
• Cloud Identity - GCP kullanıcı, cihaz ve uygulama hesaplarını tek bir konsoldan yönetin.
• Cloud HSM - şifreleme anahtarlarının korunması.
• Bulut Anahtar Yönetimi Hizmeti - GCP'deki şifreleme anahtarlarının yönetimi.
• VPC Hizmet Kontrolü - GCP kaynaklarınızı sızıntılardan korumak için çevresinde güvenli bir çevre oluşturun.
• Titan Güvenlik Anahtarı - kimlik avına karşı koruma.

Bu modüllerin çoğu, analiz için BigQuery depolama alanına gönderilebilen veya SIEM dahil diğer sistemlere aktarılabilen güvenlik olayları oluşturur. Yukarıda belirtildiği gibi GCP aktif olarak gelişen bir platformdur ve Google şu anda platformu için bir dizi yeni bilgi güvenliği modülü geliştirmektedir. Bunların arasında, izinsiz etkinliklerin izlerini bulmak amacıyla Stackdriver günlüklerini tarayan Olay Tehdit Tespiti (artık beta sürümünde mevcuttur) (AWS'deki GuardDuty'ye benzer) veya Politika İstihbaratı (alfa sürümünde mevcuttur), GCP kaynaklarına erişim.

Popüler bulut platformlarındaki yerleşik izleme yeteneklerine kısa bir genel bakış yaptım. Ancak "ham" IaaS sağlayıcı günlükleriyle çalışabilecek uzmanlarınız var mı (herkes AWS'nin, Azure'un veya Google'ın gelişmiş özelliklerini satın almaya hazır değil)? Ayrıca pek çok kişi, güvenlik alanında her zamankinden daha doğru olan "güven ama doğrula" atasözüne aşinadır. Bulut sağlayıcının size bilgi güvenliği olayları gönderen yerleşik yeteneklerine ne kadar güveniyorsunuz? Bilgi güvenliğine ne kadar odaklanıyorlar?

Bazen yerleşik bulut güvenliğini tamamlayabilecek yer paylaşımlı bulut altyapısı izleme çözümlerine bakmaya değer ve bazen bu tür çözümler, verilerinizin ve bulutta barındırılan uygulamalarınızın güvenliğine ilişkin içgörü elde etmek için tek seçenek olabilir. Ayrıca, farklı bulut sağlayıcılarının farklı bulut hizmetleri tarafından oluşturulan gerekli günlüklerin analiz edilmesine ilişkin tüm görevleri üstlendikleri için daha kullanışlıdırlar. Böyle bir katmanlama çözümünün bir örneği, tek bir göreve odaklanan Cisco Stealthwatch Cloud'dur; yalnızca Amazon AWS, Microsoft Azure ve Google Cloud Platform'u değil, aynı zamanda özel bulutları da içeren bulut ortamlarındaki bilgi güvenliği anormalliklerini izlemek.

Örnek: Stealthwatch Bulutunu Kullanarak Bilgi Güvenliği İzleme

AWS esnek bir bilgi işlem platformu sağlar ancak bu esneklik, şirketlerin güvenlik sorunlarına yol açacak hatalar yapmasını kolaylaştırır. Ve paylaşılan bilgi güvenliği modeli yalnızca buna katkıda bulunur. Bulutta bilinmeyen güvenlik açıklarına sahip yazılım çalıştırmak (bilinen güvenlik açıklarıyla örneğin AWS Inspector veya GCP Cloud Scanner ile mücadele edilebilir), zayıf şifreler, yanlış yapılandırmalar, içeriden öğrenilenler vb. Ve tüm bunlar, bilgi güvenliği izleme ve saldırı tespit sistemi olan Cisco Stealthwatch Cloud tarafından izlenebilen bulut kaynaklarının davranışlarına da yansıyor. genel ve özel bulutlar.

Cisco Stealthwatch Cloud'un temel özelliklerinden biri varlıkları modelleme yeteneğidir. Bununla birlikte, bulut kaynaklarınızın her birinin (AWS, Azure, GCP veya başka bir şey olması fark etmez) bir yazılım modelini (yani gerçek zamanlıya yakın bir simülasyon) oluşturabilirsiniz. Bunlar, sunucuların ve kullanıcıların yanı sıra güvenlik grupları ve otomatik ölçeklendirme grupları gibi bulut ortamınıza özgü kaynak türlerini içerebilir. Bu modeller, girdi olarak bulut hizmetleri tarafından sağlanan yapılandırılmış veri akışlarını kullanır. Örneğin, AWS için bunlar VPC Flow Logs, AWS CloudTrail, AWS CloudWatch, AWS Config, AWS Inspector, AWS Lambda ve AWS IAM olacaktır. Varlık modelleme, kaynaklarınızdan herhangi birinin rolünü ve davranışını otomatik olarak keşfeder (tüm bulut etkinliklerinin profilini çıkarmaktan bahsedebilirsiniz). Bu roller arasında Android veya Apple mobil cihazı, Citrix PVS sunucusu, RDP sunucusu, posta ağ geçidi, VoIP istemcisi, terminal sunucusu, etki alanı denetleyicisi vb. yer alır. Daha sonra riskli veya güvenliği tehdit eden davranışların ne zaman ortaya çıktığını belirlemek için davranışlarını sürekli olarak izler. Parola tahminini, DDoS saldırılarını, veri sızıntılarını, yasa dışı uzaktan erişimi, kötü amaçlı kod etkinliğini, güvenlik açığı taramasını ve diğer tehditleri tanımlayabilirsiniz. Örneğin, kuruluşunuz için alışılmadık bir ülkeden (Güney Kore) bir Kubernetes kümesine SSH aracılığıyla bir uzaktan erişim girişiminin algılanması şöyle görünür:

Daha önce etkileşime girmediğimiz bir ülkeye Postgress veritabanından bilgi sızdırıldığı iddiası da şöyle:

Son olarak, Çin ve Endonezya'da harici bir uzak cihazdan yapılan çok sayıda başarısız SSH girişimi şuna benziyor:

Veya, VPC'deki sunucu örneğinin politika gereği hiçbir zaman uzaktan oturum açma hedefi olmayacağını varsayalım. Ayrıca, güvenlik duvarı kuralları ilkesindeki hatalı bir değişiklik nedeniyle bu bilgisayarda uzaktan oturum açma deneyimi yaşandığını varsayalım. Varlık Modelleme özelliği bu etkinliği ("Olağandışı Uzaktan Erişim") neredeyse gerçek zamanlı olarak algılayacak ve raporlayacak ve belirli AWS CloudTrail, Azure Monitor veya GCP Stackdriver Logging API çağrısına işaret edecektir (diğer ayrıntıların yanı sıra kullanıcı adı, tarih ve saat dahil) ) ITU kuralında değişikliğe yol açtı. Daha sonra bu bilgiler analiz için SIEM'e gönderilebilir.

Cisco Stealthwatch Cloud tarafından desteklenen herhangi bir bulut ortamı için benzer yetenekler uygulanır:

Varlık modelleme, çalışanlarınız, süreçleriniz veya teknolojinizle ilgili önceden bilinmeyen bir sorunu ortaya çıkarabilen benzersiz bir güvenlik otomasyonu biçimidir. Örneğin, diğer şeylerin yanı sıra aşağıdaki gibi güvenlik sorunlarını tespit etmenize olanak tanır:

• Birisi kullandığımız yazılımda bir arka kapı mı keşfetti?
• Bulutumuzda herhangi bir üçüncü parti yazılım veya cihaz var mı?
• Yetkili kullanıcı ayrıcalıkları kötüye mi kullanıyor?
• Uzaktan erişime veya kaynakların başka şekilde istenmeyen kullanımına izin veren bir yapılandırma hatası mı oluştu?
• Sunucularımızdan veri sızıntısı mı var?
• Birisi bize alışılmadık bir coğrafi konumdan mı bağlanmaya çalışıyordu?
• Bulutumuza kötü amaçlı kod mu bulaştı?

Tespit edilen bir bilgi güvenliği olayı, Slack, Cisco Spark ve PagerDuty olay yönetim sistemine karşılık gelen bir bildirim biçiminde gönderilebildiği gibi Splunk veya ELK dahil olmak üzere çeşitli SIEM'lere de gönderilebilir. Özetlemek gerekirse, şirketiniz çoklu bulut stratejisi kullanıyorsa ve herhangi bir bulut sağlayıcıyla sınırlı değilse, yukarıda açıklanan bilgi güvenliği izleme yeteneklerinin kullanılması halinde, birleşik bir izleme seti elde etmek için Cisco Stealthwatch Bulutu kullanmanın iyi bir seçenek olduğunu söyleyebiliriz. Amazon, Microsoft ve Google gibi önde gelen bulut oyuncularının yetenekleri. En ilginç olanı, Stealthwatch Cloud fiyatlarını AWS, Azure veya GCP'deki bilgi güvenliği izleme için gelişmiş lisanslarla karşılaştırırsanız, Cisco çözümünün Amazon, Microsoft'un yerleşik yeteneklerinden bile daha ucuz olacağı ortaya çıkabilir. ve Google çözümleri. Bu paradoksal ama doğru. Ve ne kadar çok bulut ve onların yeteneklerini kullanırsanız, birleştirilmiş bir çözümün avantajı o kadar belirgin olacaktır.

Buna ek olarak Stealthwatch Cloud, örneğin Kubernetes konteynerlerine dayalı olarak veya Netflow akışlarını veya ağ ekipmanındaki (hatta yerel olarak üretilmiş), AD verilerini veya DNS sunucularını vb. yansıtma yoluyla alınan ağ trafiğini izleyerek kuruluşunuzda konuşlandırılan özel bulutları izleyebilir. Tüm bu veriler, siber güvenlik tehdit araştırmacılarından oluşan dünyanın en büyük sivil toplum grubu Cisco Talos tarafından toplanan Tehdit İstihbaratı bilgileriyle zenginleştirilecek.

Bu, şirketinizin kullanabileceği hem genel hem de hibrit bulutlar için birleşik bir izleme sistemi uygulamanıza olanak tanır. Toplanan bilgiler daha sonra Stealthwatch Cloud'un yerleşik yetenekleri kullanılarak analiz edilebilir veya SIEM'inize gönderilebilir (Splunk, ELK, SumoLogic ve diğerleri varsayılan olarak desteklenir).

Böylece, IaaS/PaaS platformlarının bilgi güvenliğini izlemeye yönelik, bulut ortamlarında meydana gelen olayları hızlı bir şekilde tespit edip müdahale etmemizi sağlayan yerleşik ve harici araçları incelediğim yazının ilk bölümünü tamamlamış olacağız. işletmemiz seçti. İkinci bölümde konuya devam edip Salesforce ve Dropbox örneğini kullanarak SaaS platformlarını izlemeye yönelik seçeneklere bakacağız, ayrıca farklı bulut sağlayıcıları için birleşik bir bilgi güvenliği izleme sistemi oluşturarak her şeyi özetlemeye ve bir araya getirmeye çalışacağız.

Kaynak: habr.com