Bulutta Yerel Güvenlik KubeCon/CloudNativeCon 2022 PlatoBlockchain Veri Zekasında Yayındaydı. Dikey Arama. Ai.

Cloud-Native Security, KubeCon/CloudNativeCon 2022'de Yayındaydı

Kendini bir film tutkunu olarak tanımlayan biri olarak, bazı film replikleri yıllar boyunca bir şekilde aklımdan çıkmıyor. Bunlardan biri Ridley Scott'tan. Gladyatör (2000), Romalı bir senatör şöyle dediğinde: "Roma'nın atan kalbi Senato'nun mermeri değil, Kolezyum'un kumudur."

Bu cümle, KubeCon/CloudNativeCon'da ("KubeCon") salonlarda dolaşırken aklımda belirdi. Bulut Yerel Bilişim Vakfı (CNCF). Bana göre bulutta yerel güvenliğin atan kalbi kesinlikle KubeCon'dur.

Etkinliğin bu yılki Kuzey Amerika edisyonu geçen hafta Detroit'te gerçekleşti ve binlerce katılımcıyı yerinde ve pek çok katılımcıyı da uzaktan bir araya getirdi. Üç günlük ana etkinliğe ek olarak, belirli projelere artan ilgi, Bulut Yerel Bilişim Vakfı'nın ana konferans öncesinde çeşitli "ortak konumlu etkinlikler" düzenlemesine yol açtı.

2022 etkinliği için yalnızca iki günlük belirli bir CloudNativeSecurityCon etkinliği değil, aynı zamanda Uygulama Ağ Oluşturma Günü, EnvoyCon, OPA ile Politika Günü, ServiceMeshCon ve daha fazlası dahil olmak üzere diğer etkinliklerde de buluta olan geniş ilgiyi yansıtan çok sayıda güvenlik içeriği vardı. yerel güvenlik konuları. İlginçtir ki CloudNativeSecurityCon etkinliği artık Şubat ayında ayrı olarak düzenlenecek bağımsız bir etkinliğe "geçmiş" oldu.

Bulutta Yerel güvenlik: Geliştirme ve Operasyonlar

Peki, bulutta yerel güvenlik görüşmelerinin mevcut durumu nerede? Omdia'ya göre güçlü bir çatallanma var: kalkınma merkezli kaygılar ve operasyon merkezli kaygılar. Ekip yapısı birçok kuruluşta değişim halinde olduğundan bunları "Geliştirme" ve "Ops" olarak adlandırmak o kadar da yararlı değildir: bazılarının site güvenilirliği mühendisliği (SRE) ekipleri olabilir, bazıları ise bunları operasyonlar, platform ekipleri ve daha fazlası olarak adlandırabilir.

Defterin geliştirme tarafında ilgi duyulan üç konu; kaynak, gürültü ve riske maruz kalmadır.

Provenance temel soruyu sorar: Yazılım hattımıza dahil ettiğimiz harici bileşenin bütünlüğüne güvenebilir miyiz? Pek çok örnek mevcut olsa da 2020 SolarWinds saldırısı, yazılım tedarik zincirinin bütünlüğüne olan ilgi açısından bir dönüm noktasıydı. KubeCon'da yazılım görsellerini imzalama fikrinin arkasında gözle görülür bir ivme vardı: mağaza projenin genel kullanıma sunulduğu duyuruldu ve Kubernetes ve diğer önemli projeler tarafından kullanılıyor.

Gürültü, kullanılan kapsayıcı taban görüntülerinin zayıflatılmasıyla başlayarak, ortamda bulunan güvenlik açıklarının sayısının azaltılması anlamına gelir. Bu, Alpine veya Debian Slim gibi görüntü tabanlarının kullanılmasını veya daha da küçük olan "dağıtımsız" alternatiflerin değerlendirilmesini içerebilir. Avantajı, bu daha küçük görüntülerin minimum ayak izine sahip olması ve dolayısıyla güvenlik açıklarının ortaya çıkma olasılığının azalmasıdır.

Maruziyet: Herhangi bir güvenlik açığına bir kuruluş olarak ne kadar maruz kalıyoruz? Yakın endüstri tarihinde bunun Log4j'den daha iyi bir örneği elbette yok. Bu, yazılım malzeme listeleri (SBOM'lar) hakkındaki tartışmaların alanıdır, çünkü bileşenlerin bir yerde bir kayıt defterinde duran veya üretimde çalışan görüntüler olarak nerede kullanılabileceğini bilmekle ilgilidir. İlginç bir şekilde, bu makalenin yazıldığı sırada, OpenSSL 3.x'teki kritik güvenlik açıkları hakkındaki bilgilerin yakın zamanda açıklanacağına dair önceden bir bildirim var; bu da muhtemelen SBOM'lar için başka bir iyi kullanım örneği olacak - OpenSSL 3.x kuruluşumuzda tam olarak nerede kullanılıyor? SBOM kapsamının hala yaygın olmadığı göz önüne alındığında, Omdia ne yazık ki bu sefer minimum düzeyde SBOM kullanımı bekliyor.

Operasyon ekipleri doğal olarak giderek daha karmaşık hale gelen bir temel platformun sağlanmasına, çalıştırılmasına ve bunu güvenli bir şekilde yapmaya odaklanıyor. "Platform" kelimesi burada özellikle anlamlıdır: Kubernetes'in ve büyüyen CNCF projelerinin çoğunun (bu yazının yazıldığı an itibariyle 140, proje kuluçkasının çeşitli aşamaları arasında: korumalı alan, kuluçka, derecelendirilmiş) daha kolay hale getirilmesine yönelik kayda değer bir ilgi vardı. tüketim platformları. Güvenlik hedef kitlelerinin özellikle ilgisini çeken, ağ oluşturma ve gözlemlenebilirlik için Cilium (temel eBPF işlevini kullanan), SPIFFE/SPIRE (kimlik oluşturmak için), Falco (çalışma zamanı güvenliği için), Açık Politika Aracısı (kod olarak politika için) gibi projeler , Cloud Custodian (yönetim için) ve diğerleri incelenmeye değer. Beklenti, bu projelerin bulut yerelinin "gözlemlenebilirlik" yönleriyle giderek daha fazla işbirliği yapması ve ayrıca GitOps gibi uygulamalar kullanılarak devreye alınmasıdır.

Bulutta Yerel Güvenlik Konusunda İyimserliğin Nedenleri

Buradan nereye gidiyoruz? Bulutta yerel topluluğun güvenliğe derinden önem verdiği ve etrafındaki birçok konuyu ele alarak tam hızla ilerlediği çok açıktı. Güvenlik ekiplerine rehberlik, bu farklı projelerin ve girişimlerin nasıl uygulandığı konusunda hızlı bir şekilde bilgi sahibi olmaktır. Pek çok kuruluş için bunun, topluluk projesinin açıkça kullanılması şeklinde olmayacağını (bazıları bunu yapacak olsa da) bunun yerine Red Hat, SUSE, Canonical ve diğerleri gibi satıcıların paket platformunun bir parçası olarak geleceğini unutmamak önemlidir. veya doğrudan AWS, Google Cloud, Azure, Oracle ve diğerleri gibi bulut sağlayıcılarından.

Açık kaynak kullanımı bağlamında, gerçekten "ücretsiz" diye bir şeyin olmadığını unutmayın; projelerin vanilya yukarı akış versiyonunu kullanmayı seçseniz bile, bu paketlerin bakımının ve topluluk gelişimine katılımın doğal maliyetleri vardır.

Zaman Damgası:

Den fazla karanlık okuma