Neden Her Kurumun Bir Golden Image Stratejisine İhtiyacı Var?

Son yıllarda konteyner teknolojileri modern yazılım geliştirme süreçlerinin vazgeçilmez bir parçası haline geldi. Uygulamalar artık daha hızlı geliştiriliyor, daha kolay dağıtılıyor ve bulut ortamlarında daha ölçeklenebilir şekilde çalıştırılıyor.

Container teknolojileri yazılım geliştirme süreçlerini önemli ölçüde kolaylaştırmış olsa da beraberinde birçok kurumun hala mücadele ettiği yeni bir güvenlik sorununu da ortaya çıkardı: zafiyetli base image'lar.

Uygulama geliştirme ekipleri tarafından yazılan kodlar güvenli olsa bile uygulamanın üzerine inşa edildiği işletim sistemi katmanında bulunan paketler ve kütüphaneler yüzünden yüzlerce güvenlik bulgusu oluşabiliyor.

Sonuç olarak aynı OpenSSL zafiyeti onlarca uygulamada tekrar tekrar karşımıza çıkıyor.

Aynı "glibc" zafiyeti yüzlerce farklı container image içerisinde tespit ediliyor.

Aynı güvenlik bulgusu onlarca ekip tarafından ayrı ayrı çözülmeye çalışılıyor.

Bu durum yalnızca güvenlik riskini artırmakla kalmıyor, aynı zamanda kurum içerisinde ciddi operasyonel maliyetler oluşturuyor.Aynı zafiyet farklı uygulamalarda tekrar tekrar inceleniyor, aynı düzeltme çalışmaları farklı ekipler tarafından tekrar tekrar gerçekleştiriliyor ve güvenlik ekipleri giderek büyüyen bir zafiyet havuzunu yönetmek zorunda kalıyor.

Biz de tam olarak bu problemden yola çıkarak farklı bir soru sormaya başladık:

"Eğer aynı zafiyet onlarca uygulamada tekrar ediyorsa neden her uygulamayı tek tek düzeltmeye çalışıyoruz? Sorunu kaynağında çözemez miyiz?"

Bu soru bizi kurumsal ölçekte Güvenli Golden Image yaklaşımını araştırmaya ve kendi güvenli container image'ımızı oluşturmaya yönlendirdi.

Bu yazıda base image kaynaklı zafiyetlerin neden büyük bir problem haline geldiğini, Golden Image yaklaşımının bu soruna nasıl çözüm sunduğunu ve kurumsal bir güvenli container ekosisteminin nasıl oluşturulabileceğini ele alacağız.

Diyagram 1: Problemin Kaynağı

Diyagram 2: Golden Image Yaklaşımı

Diyagram 3: Güvenli Image Üretim üreci

Diyagram 4: Hedef Mimari

Base Image Kaynaklı Zafiyetler Neden Bu Kadar Yaygın?

Bir container image temelde katmanlardan oluşur. Basitleştirilmiş bir örnek:

Application Code
Application Libraries
Runtime Layer
Operating System Packages
Base Image

Application Code
Application Libraries
Runtime Layer
Operating System Packages
Base Image

Geliştiriciler genellikle yalnızca uygulama koduna odaklanırlar. Ancak güvenlik tarama araçları yalnızca uygulama kodunu incelemez.

Aşağıdaki bileşenlerin tamamını analiz eder:

• İşletim sistemi paketleri
• Sistem kütüphaneleri
• Runtime bileşenleri
• OpenSSL
• glibc
• curl
• bash
• Python paketleri
• Java paketleri
• Node.js bağımlılıkları

Dolayısıyla geliştiricinin yazdığı uygulama tamamen güvenli olsa bile image içerisinde bulunan eski bir OpenSSL sürümü yüzünden kritik seviyede bir güvenlik bulgusu oluşabilir.

Güvenlik ekiplerinin sıklıkla karşılaştığı senaryo şöyledir:

Bir tarama sonucunda:

• 50 Kritik
• 150 Yüksek
• 400 Orta

seviyede bulgu tespit edilir.

İlk bakışta ciddi bir güvenlik problemi varmış gibi görünür.

Ancak detaylı inceleme yapıldığında bu bulguların büyük bölümünün yalnızca birkaç ortak paketten kaynaklandığı anlaşılır.

Yani yüzlerce bulgunun temelinde aslında birkaç kök sebep bulunmaktadır.

Ortak Zafiyetlerin Görünmeyen Maliyeti

Şimdi aşağıdaki gibi bir kurum hayal edelim:

• 50 uygulama
• 20 geliştirme ekibi
• 300 container image

Bu uygulamaların tamamının aynı Ubuntu base image'ını kullandığını ve bu image içerisinde kritik seviyede bir OpenSSL zafiyeti bulunduğunu düşünelim.

Bu durumda güvenlik tarama araçları aynı zafiyeti yüzlerce kez raporlayacaktır.

Teknik açıdan bakıldığında aslında yalnızca tek bir kök problem vardır.

Ancak operasyonel açıdan bakıldığında yüzlerce farklı iş kaydı oluşmuştur.

Bu durum kurum içerisinde gereksiz bir iş yüküne neden olur.

Güvenlik ekiplerinin operasyonel yükü katlanarak artarken gerçek risk hala tek bir bağımlılık üzerinde yoğunlaşmaktadır.

İşte Golden Image yaklaşımını benimsemek için en güçlü gerekçelerden biri de budur.

Kurumsal yapılarda güvenlik ekipleri genellikle onlarca hatta yüzlerce uygulamadan sorumludur.

Şöyle bir senaryo düşünelim:

• 100 uygulamanın hepsi aynı base image'dan üretilmiş ve bu image 20 adet zafiyete sahip

Sonuç olarak aynı zafiyet yüzlerce kez raporlanır.

Teknik olarak yalnızca bir problem vardır. Operasyonel olarak ise yüzlerce iş kalemi oluşmuştur. Bu durum güvenlik ekiplerinde şu problemlere yol açar:

Alarm Yorgunluğu (Alert Fatigue)

Aynı tip bulgular sürekli tekrar eder.

Önceliklendirme Problemi

Gerçek risklerin tespiti zorlaşır.

Kaynak İsrafı

Aynı problem onlarca kez incelenir.

Düşük Verimlilik

Güvenlik ekipleri stratejik konular yerine operasyonel işlerle uğraşır.

Golden Image Yaklaşımı Nedir?

Golden Image yaklaşımı aslında oldukça basit bir fikre dayanır.

Kurum içerisinde kullanılacak container image'lar merkezi olarak oluşturulur, güvenlik kontrollerinden geçirilir ve standart hale getirilir.

Böylece geliştiriciler doğrudan internetten image seçmek yerine kurum tarafından sağlanan güvenli image'ları kullanırlar.

Örneğin:

Normal yaklaşım:

FROM ubuntu:22.04

FROM ubuntu:22.04

Golden Image yaklaşımı:

FROM company-secure-base:1.0

FROM company-secure-base:1.0

Bu küçük değişiklik aslında güvenlik açısından çok büyük etkiler yaratır.

Çünkü artık:

• İşletim sistemi seçimi merkezi hale gelir.
• Paket yönetimi merkezi hale gelir.
• Zafiyet yönetimi merkezi hale gelir.
• Güvenlik standartları merkezi hale gelir.

Güvenli Bir Golden Image Nasıl Oluşturulur?

Golden Image oluşturmak yalnızca zafiyetleri temizlemek anlamına gelmez.

Asıl amaç:

• Minimum saldırı yüzeyi
• Maksimum standartlaşma
• Sürekli güncellenebilirlik
• Operasyonel sürdürülebilirlik

sağlamaktır.

1. Doğru İşletim Sistemi Seçimi

İlk adım temel image seçimidir.

Karşımıza genellikle üç seçenek çıkar:

Ubuntu

Avantajlar:

• Geniş ekosistem
• Yüksek uyumluluk
• Kolay kullanım

Dezavantajlar:

• Daha fazla paket
• Daha büyük saldırı yüzeyi

Alpine

Avantajlar:

• Küçük boyut
• Daha az paket

Dezavantajlar:

• Uyumluluk problemleri
• Bazı uygulamalarda çalışma sorunları

Distroless

Avantajlar:

• Son derece küçük saldırı yüzeyi
• Shell bulunmaz
• Paket yöneticisi bulunmaz

Dezavantajlar:

• Hata ayıklama süreçleri zorlaşır

Üretim ortamları için mümkün olduğunca Distroless tabanlı mimarilere geçmek önemli avantajlar sağlayabilir.

2. Gereksiz Paketlerin Temizlenmesi

Bir image içerisinde bulunan her paket potansiyel bir saldırı yüzeyidir.

Sıklıkla gördüğümüz gereksiz bileşenler:

• wget
• curl
• vim
• nano
• ftp istemcileri
• debug araçları

Bu bileşenlerin üretim ortamlarında bulunması çoğu zaman gerekli değildir.

Paket sayısı azaldıkça:

• Zafiyet sayısı azalır.
• Yönetim kolaylaşır.
• Saldırı yüzeyi küçülür.

3. Root Kullanımının Kaldırılması

Container güvenliğinde yapılan en yaygın hatalardan biri root kullanıcı ile çalışmaktır.

Örnek:

USER root

USER root

Yerine:

USER 10001

USER 10001

kullanılması önerilir.

Bu sayede saldırgan container içerisine erişim elde etse bile sistem üzerindeki yetkileri sınırlı kalır.

4. Linux Capability Temizliği

Varsayılan olarak container'lar gereğinden fazla yetki ile çalışabilir.

Özellikle:

• CAP_SYS_ADMIN
• CAP_NET_RAW
• CAP_SYS_PTRACE

gibi capability'ler gereksiz risk oluşturabilir.

İhtiyaç duyulmayan capability'lerin kaldırılması önemli bir güvenlik kazanımı sağlar.

Otomasyon Olmadan Başarı Mümkün Değil

Golden Image programlarının başarısız olmasının en büyük nedenlerinden biri manuel süreçlere bağımlı olmalarıdır.

Kurumsal ölçekte yüzlerce image'ın manuel yönetilmesi mümkün değildir.

Bu nedenle süreç tamamen otomatik hale getirilmelidir.

Örnek süreç:

Kod Değişikliği
        │
        ▼
Container Build
        │
        ▼
Trivy Scan
        │
        ▼
Policy Validation
        │
        ▼
Golden Registry
        │
        ▼
Kubernetes Deployment

Kod Değişikliği
        │
        ▼
Container Build
        │
        ▼
Trivy Scan
        │
        ▼
Policy Validation
        │
        ▼
Golden Registry
        │
        ▼
Kubernetes Deployment

Bu yapı sayesinde güvenlik kontrolleri insan müdahalesi olmadan uygulanabilir.

Registry Yönetimi

Kurum içerisinde merkezi bir registry oluşturulmalıdır.

Örneğin:

• Harbor
• Azure Container Registry
• Google Artifact Registry
• Amazon ECR

Geliştiricilerin doğrudan Docker Hub üzerinden image kullanması engellenebilir.

Böylece tüm image'lar merkezi kontrol altında tutulabilir.

Güvenlik Taramaları Sürekli Çalışmalıdır

Bir image bugün güvenli olabilir. Ancak yarın yeni bir CVE yayınlanabilir.

Bu nedenle taramalar yalnızca build sırasında yapılmamalıdır. Sürekli tarama yaklaşımı uygulanmalıdır.

• Trivy
• Prisma Cloud
• Microsoft Defender for Containers
• Grype

gibi araçlarla yeni yayınlanan CVE'leri düzenli olarak takip ederek mevcut image'ları yeniden değerlendirebilir.

Başarı Nasıl Ölçülür?

Bir Golden Image programının başarısı ölçülebilir olmalıdır.

Takip edilebilecek metrikler:

• Kritik zafiyet sayısındaki azalma
• Yüksek seviye bulgu sayısındaki azalma
• Ortalama düzeltme süresi
• Golden Image kullanım oranı
• Güvenlik ekibinin operasyonel iş yükündeki azalma

Gerçek başarı yalnızca CVE sayısını düşürmek değil, güvenlik süreçlerini sürdürülebilir hale getirmektir.

Sonuç

Container güvenliği çoğu zaman yalnızca bir zafiyet yönetimi problemi olarak görülüyor. Oysa yaşanan problemlerin önemli bir kısmı aslında standartlaşma eksikliğinden kaynaklanıyor.

Her ekibin farklı image'lar kullanması, farklı paketler yüklemesi ve farklı güvenlik yaklaşımları benimsemesi zamanla kontrol edilmesi zor bir yapı oluşturuyor.

Golden Image yaklaşımı bu karmaşıklığı azaltarak kurum genelinde ortak bir güvenlik standardı oluşturulmasını sağlıyor.

Container kullanımının her geçen gün arttığı günümüzde Golden Image yaklaşımı artık yalnızca bir güvenlik iyileştirmesi değil, kurumsal ölçekte sürdürülebilir container güvenliğinin temel gereksinimlerinden biri haline gelmiştir.

Bugünlük bahsedeceklerim bu kadar, sonraki yazımda görüşmek üzere! :)