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ın Taranması
• CI (Continuous Integration) Taraması
• Registry Taraması
• Base İmajların Taranması

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:

• Çevresel Risk Faktörleri:
  • İnternetten erişilebilir olma
  • Konteynerin root yetkisiyle çalışması
  • Dinlediği portun olması
  • Yetkili şekilde çalışan konteyner olması
  • Uygulamanızın kritikliği
• Zafiyet Risk Faktörleri:
  • Zafiyet seviyesi
  • Atak vektörü
  • Atak karmaşıklığı
  • İlgili paketin kullanılması
  • Exploit’in olması ve yeni, sömürülme ihtimali yüksek bir zafiyet olması
  • Uzaktan kod çalıştırma gibi kritik zafiyet olması

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.

• Host Zafiyetleri
  
  Konteynerler bilindiği üzere hostlar üzerinde yaşamaktadır. Bu hostlar üzerindeki zafiyetleri de tıpkı konteynerlerdeki gibi takip edilmesi ve önceliklendirerek kapatılması gereklidir. Böylece yetki yükseltme zafiyetlerinin önüne geçilebilir. Bu noktada konuyu yama yönetimi süreciniz ile de takip edebilirsiniz.
   
• Statik Kod Analizi
  
  Tıpkı geleneksel uygulamalarda olduğu gibi konteyner tabanlı uygulamalarda da statik kod analizi yapılmalı ve bu analizi olabildiğince geliştirme sürecinin başlarına taşıyacak devops tasarımları da yapılmalıdır.
   
• Güvenli Kod Geliştirme Eğitimleri ve Bilgilendirmeler
  
  Olmazsa olmaz eğitimler ve bilgilendirmeleri konteyner altyapılı uygulamalar için de yapılmalıdır. Yazılımcıların konteyner güvenliği ile ne kadar bilgisi olursa, ne kadar riskin farkına varılırsa o kadar faydalı olacaktır.
   
• Docker File, YAML’lardaki Zafiyet Konuları
  
  Güvenli kod geliştirmede Shift-Left artık bildiğimiz bir kavram oldu. Konteyner altyapısında da artık yavaş yavaş konuşmamız gereken bir durum. Çünkü kullandığımız konteyner güvenliği araçları genelde konteynerimiz hazır olduğunda imajdaki zafiyetleri tespit edebilmektedir. Halbuki docker file veya yaml’lardaki olan ve yüklenecek kütüphaneler aslında bizim için birer tehdit olabilmektedir. Burada düzeltebileceğimiz bir durum, çok sonradan karşımıza çıkabilecek büyük sorunları çözecektir. Infrastructure as a service (IaaS), software as a service (SaaS) gibi yöntemleri hayatımızda daha çok gördüğümüzde çok daha önemli olacak bir başlık diyebiliriz.

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.