Bloga geri dön
Resim 1. Fiziksel – Sanal – Konteyner Tabanlı Altyapı
Bu yazımızda Konteyner Güvenliği’nin bir alt maddesi olan Zafiyet Yönetimi konusundan bahsedeceğiz. Konteyner konusunda hiç bilgisi olmayanlar için konuyu araştırmalarını tavsiye ediyoruz. Altyapı hakkında bilginiz olursa, güvenlik problemlerini daha iyi anlayabilirsiniz. Konteyner Güvenliği’nde önemli maddelerden olan Runtime Security, Secret Management, Network Security vb. konulara bu yazıda değinmeyeceğiz. Bundan dolayı bu yazı Konteyner Güvenliği konularının tamamı olarak düşünülmemeli, zafiyet yönetimi odaklı değerlendirilmelidir.
Şirketler için zafiyet yönetimi teoride bilinse de pratikte uygulaması zor, meşakkatli bir süreç. Son zamanlarda saldırganların yeni çıkan zafiyetleri kullanmaları saatler mertebesine indiği için bu süreci pratikte de uygulamayan şirketler için büyük riskler doğuyor.
Konteyner tabanlı olmayan altyapılardaki zafiyet yönetiminde iki farklı yöntem ile zafiyet tespiti yapılmaktadır. Bu yöntemler, port taraması ve kimlik doğrulamalı zafiyet taramasıdır. Bu süreçte, zafiyetler çıktıktan sonra ilgili servis sahiplerinin zafiyetleri kapatması için takip yapılır.
Konteyner tabanlı uygulamalarda ise kabaca 4 farklı yolla tarama yapılabilmektedir.
Konteyner İmajların Taranması
Konteyner imajların taranması ücretli veya ücretsiz farklı ürünler ile yapılabilmektedir. Bu tarama otomatize yapılmaktadır ve bilinen zafiyetlere karşı çözüm sağlamaktadır. Ürünler, ilgili konteyner üzerindeki kütüphaneleri ve versiyonlarını çekmektedir. Sonrasında da bu kütüphanelerin zafiyetli sürüm olup olmadığını, internet üzerindeki zafiyet veri tabanlarından karşılaştırmaktadır. Zafiyetli kütüphaneleri de size raporlamaktadır. İşte bu noktada önemli gördüğümüz bir konu var. Konteyner altyapılar küçük ve sayıca fazla olduklarından dolayı, zafiyet önceliklendirme konusu en önemli maddemiz olmaktadır. Bu önceliklendirmeyi aşağıdaki gibi iki farklı risk yönetimi özelinde yaparsak daha iyi sonuçlar alırız.
Risk faktörleri:
Bu iki risk faktörü ile zafiyetleri önceliklendirerek kapattırma yolu, gördüğümüz kadarıyla en efektif yol. Fakat bir dezavantajla hala karşı karşıya durumdayız, önceliklendirsek bile zafiyetlerin sayıca çok fazla olma olasılığı çok yüksek. İşte bu noktada ikinci çözümü çok daha kıymetli buluyoruz.
CI (Continuous Integration) Taraması
Günümüzde çok popüler olan DevOps süreçleri, konteyner altyapısında olan uygulamalara çok daha yakın bir kavramdır. Bu yüzden de genellikle bu uygulamalar, uygulama üretim süreçlerinde bir pipeline’a sahiptirler. Pipeline’a sahip olan uygulamalarda Konteyner Güvenliği ürününüzü kullanmak, uygulamanın pipeline’ına ürününüzü dahil etmek kritik önemdedir.
Resim 2. Örnek DevOps Pipeline
Bu yöntemin en zor tarafı ise Konteyner Güvenliği ürününüzü pipeline’lara tek tek entegre etmeniz gerekmektedir. Ayrıca entegrasyon yapıldıktan sonra firmanızın hassasiyetine göre bir “BLOK” kuralı yazmanız en önemli faydayı yaratacaktır. Blok kuralı yazmakta zorlanıyorsanız, bu sürece en kritik risk profilinde ve seviyesinde olan zafiyetlerden başlanabilir. Örneğin bir konteynerde kritik veya uzaktan kod çalıştırma zafiyeti içeren konteynerlerin production ortamına geçmemesi için bu “BLOK” kuralını yazabilirsiniz. Bu örneği yukarıda paylaştığımız risk profilleri ile zenginleştirebilirsiniz.
Konteyner zafiyetlerini bizim tecrübemizce engellemenin, önüne geçmenin en efektif yolu CI üzerinde durdurucu olmaktan geçiyor. Çünkü bu evren, geleneksel ortamlara göre çok hızlı ve değişken. Zafiyetler production ortamına çıktıktan sonra takip edip kapattırmak çok zor bir hal almaktadır.
Fakat CI taramasının da bir dezavantajı, uygulamaların her ne kadar test ortamları da olsa, uygulamanın hazır olduğu, build edildiği aşamada devreye girmemizdir. Bu noktada yazdığımız “BLOK” kuralı bizi güvenli kılmakta fakat süreci uzatmaktadır. Örneğin bir kütüphanenin bir sürümünde zafiyet çıkarsa ve uygulama da o sürüme bağlı ise tekrar geliştirme maliyeti ortaya çıkabilmektedir. Bu problemleri azaltmak için bir diğer yol ise registry taramasıdır.
Registry Taraması
Şirketler konteyner altyapılarında kullandıkları imajları kendilerine ait private bir registry üzerinde tutması gerekmektedir. Eğer public ortamlardan indirilen imajları kullanıyorsanız ciddi bir risk altındasınızdır demektir, çünkü bu imajlara bir malware bulaştırılmış olabilir. Ve üzgünüz ki yukarıda söylediğimiz zafiyet taramasında bu problem tespit edilemez. Tespiti konusunda bazı yöntemler olmakla birlikte bu yazının direkt konusu değildir.
Yazılımcılar projeleri için kullanacakları konteynerleri şirkete ait private registry üzerinde tutmaktadır ve bir uygulama geliştirmek istediklerinde bu imajlar üzerinde işlemlerini gerçekleştirmektedirler.
Registry taramasının faydası da burada bariz şekilde gözükmektedir. Eğer konteyner taramasını registry özelinde yapar ve buradaki zafiyetleri yine belirlediğimiz risk önceliklendirmeyi de hesaba katarak düzeltirsek bu imajları kullanan yazılımcılar, temiz bir imajdan başladıkları için son noktada çıkacak zafiyetleri daha önce kapatmış oluruz, ayrıca işlemleri tekilleştiririz. Çünkü aynı imaj birçok projede kullanılabilir durumda olabilir. Bu taramanın da zor yanı, registry üzerinde çok fazla sayıda imaj olması ve bu fazla sayıda riski engellemek kolay olmayabilir. Bu zorluğu aşmak için de son yolu deneyebiliriz.
Base İmajların Taranması
Konteynerlarda kullanılan imajların yönetimini kolaylaştırmak için base imaj kullanımı yapılmaktadır. Zafiyet taramasını bu base imajlar üzerinde yapmalı ve bu base imajları en ideal güvenlik durumuna getirmeli, olabildiğince kütüphaneleri güncel ve zafiyetsiz olarak yaşamasını sağlamalıyız.
Diğer Konular
Zafiyet taramasını yapacağımız 4 yolu yukarıda paylaştık. Bunun dışında da bazı önemli konular var. Bunlar için kısa kısa bilgilendirmeler de yapmakta fayda olacaktır.
Yazımızın sonuna doğru gelirken yazdıklarımızı özetlersek, konteyner altyapısı kullanan servislerde zafiyet yönetimini daha efektif sağlamak için zafiyetlerimizi risk profilleri yaparak önceliklendirmeli, uygulamalarımızı CI ile entegre ederek “BLOK” kuralları yazmalıyız. Zafiyetleri production’da oluştuktan sonra takip etmek yerine zafiyetlerin oluşmamasını sağlamalıyız. Ayrıca registry üzerinde imajları ve base imajları zafiyet taramasından düzenli geçirmeli ve takip etmeliyiz. Yazılımcıları bu konuya ne kadar dahil edebilirsek, riskleri ne kadar gösterebilirsek bir o kadar faydalı olacaktır.
