Container Security 101
Container dünyasının getirdiği kolaylıklardan dolayı son yıllarda container kullanımı patladı. Eskiden uygulamaları birbirinden izole etmek istediğimizde farklı makinelere kurulum yapardık. Container çözümleri ise uygulama bağımlılıklarını dert etmeksizin aynı makine içerisinde istediğimiz kadar container çalıştırabilmemizi sağladı. Sonraki adımda ise containerları çalıştıracak bir makine belirlemeksizin, bir cluster içerisinde uygun olan bir yerde çalışmasını otomatize eden Kubernetes gibi Orchestrator araçlarını kullanmaya başladık.
Güvenlik açısından bakarsak, geleneksel deployment yöntemleri ile container ortamları arasında pek bir fark yok. Halen verimizi çalmak, sistem davranışlarını değiştirmek için ataklar mevcut, ancak container lar uygulamaların çalışma yöntemini değiştirdiği için değerlendirmemiz gereken yeni güvenlik riskleri oluşmuş durumda.
Container Dünyasının Karşısındaki Tehditler
Container’ın yaşam döngüsü esnasında karşılaşabileceği pek çok atak noktası mevcut, bu atak noktalarının aşağıdaki görselleştirilmiş şekli potansiyel tehditleri kavramamıza yardım ediyor. Şimdi bunlara biraz daha yakından bakalım.
Güvenlik Açığı Oluşturabilecek Uygulama Kodu (Vulnerable Application Code)
Geliştirilen uygulama kodları ve kodun third-party bağımlılıkları saldırganların yararlanabileceği binlerce güvenlik açığı içerebilirler. Uygulama kodundan oluşturduğumuz imajları güvenlik taramasından geçirmek oluşabilecek atakları önlemenin başlıca adımıdır. Uygulama kodunu geliştirmeye devam ettikçe, yeni potansiyel riskler oluşturabileceğimiz için, imajlar için oluşturduğumuz güvenlik taramasının yaşam döngüsü boyunca devam etmesine ihtiyacımız vardır.
Kötü Konfigüre Edilmiş Container İmajları (Badly configured container images)
Kod geliştirildikten hemen sonra, imaj oluşturmak üzere build edilir. Build aşamasında yapacağımız konfigürasyonlar çok önemlidir. Konfigurasyon YAML dosyalarını internetten indiriyorsak, ihtiyacımız olmayan içerikleri, fazla yetki veren satırları temizlemeye özen göstermemiz gerekir. Çünkü bu aşamadaki konfigürasyon tercihlerimiz, container runtime ı için çok sayıda güvenlik açığı yaratabilir.
Build Ortamı Saldıları (Build machine attacks)
İmajın build olma aşamasında, bir güvenlik açığı varsa imajımızın içinde production ortamında arkada çalışabilecek zararlı kodlar (malicious code) yerleştirilebilir.
Container Registry Saldıları (Supply chain attacks)
Build işlemi bittikten sonra imajımızı container reqistry’de saklarız. Peki container registry’ye attığımız ve oradan çekerek kullandığımız bu imajların aynı olduğundan emin olabilir miyiz? Aşağıdaki görselde, imajımızı container registry’ye gönderir ve oradan kullanırken karşılabileceğimiz attack (saldırı) noktalarının özetini görüyoruz.
Güvenlik Açığı Oluşturabilecek Host lar(Vulnerable Hosts)
Container ların çalıştığı hostların(sanal makinelerin) güvenlik açığı olan imajları, örneğin şu an güvenlik açığı olarak bildiğimiz orchestration bileşenlerinin eski versiyonlarını çalıştırmadığımızdan emin olmamız gerekir.
Secret Dosyaları (Exposed Secrets)
Uygulama kodları ilgili bileşenleri ile konuşabilmek için, şifrelere, tokenlara ve credential bilgilerine ihtiyaç duyar. Container haline getirilen imajlara bu kritik önemdeki bilgileri verirken gözönünde bulundurabileceğimiz çeşitli güvenlik seviyeleri mevcuttur.
Container Network Güvenliği (Insecured Network)
Container lar farklı bileşenler ile network üzerinden konuşur ve buradaki bağlantıları güvenli kurgulamamız da güvenlik açısından büyük öneme sahiptir.
Göz önünde bulundurulması önemli diğer güvenlik noktaları
Container lar için sıraladığımız yukarıdaki güvenlik konularına ek olarak, geleneksel yazılım deploymentlarında önemli olan “Kaynak Kod Güvenliği”, “Hostların Network konfigürasyonları”, “Firewall tanımları”, “Kimlik ve erişim yönetim sistemleri” konuları Cloud Native deploymentlarda da geçerlidir. Ek olarak container ların çalıştığı Kubernetes, Docker Swarm vs gibi orchestrator araçlarının güvenliğini de sağlamamız önemlidir. Eğer orchestrator güvenlik açığı içerecek şekilde konfigüre edildi ise ya da admin yetkileri efektif olarak kontrol edilmedi ise, güvenlik saldıları için bir kapıyı açık bırakmış oluruz.
Güvenlik Araçları
Container ile güvenlik açısından pek çok yeni saldırı noktası oluştuğunu ve bunların kabaca neler olabileceğini değerlendirdik. Güvenlik konusunu, uygulamaları geliştirmeye, container haline getirmeye başladığımız ilk andan itibaren ele almamız önerilir. Güvenliğin yazılım yaşam döngüsünün bir çok aşamasına etkisi vardır. Durum böyle olunca, bu ihtiyacı karşılamak için çeşitli güvenlik araçları geliştirilmiş. Bu araçlardan Prisma Cloud (Eski adıyla Twistlock) ve Aqua diğer araçlardan farklı olarak güvenlik platform çözümü sunuyorlar.
Prisma Cloud
- Görünürlük/İzleme, Yönetim ve Complience
- Tehdit Tespit
- Veri Güvenliği
- Host Güvenliği
- Container Güvenliği
- Serverless Güvenliği
- Web Uygulama ve API Güvenliği
- Kimlik Tabanlı Microsegmentation
- IAM Güvenliği
Aqua
- Build Güvenliği (Vulnerability Tarama, Dinamik Tehdit Analizi, CI/CD Entegrasyonları, DevSecOps Otomasyon)
- Altyapı Güvenliği (Kubernetes Güvenliği, Hybrid ve Multi Cloud Desteği, Complience kontrolleri, Public Cloudlar için Best Practices lere uygun Konfigürasyon Kontrolleri (Cloud Security Posture Management))
- Workload Güvenliği ( Container, VM, Serverless Güvenliği ve Cloud Workload Koruma)
Prisma Cloud ve Aqua güvenlik anlamında tüm ihtiyaçlarımızı karşılamaya yönelik tasarlanmış olsalar da lisans satın alarak kullanabileceğimiz ürünler. Henüz elimizde bir lisansımız yok ise de güvenlik için atabileceğimiz adımlar mevcut. Örneğin, Aqua çatısı altında olan farklı alanlara güvenlik çözümleri sunan Tracee, Trivy, Kube-bench, Kube-Hunter, Cloudspolit, Starboard gibi araçları ücretsiz kullanabiliyoruz.
Sonraki yazılarımda Twistlock, Aqua ürünlerini ve Aqua’nın Vulnerability taraması yapan Trivy ürününü GitHub Actions üzerinden nasıl kolaylıkla kullanabileceğimizi anlatacağım.
