Geleneksel güvenlik modeli güçlü bir ağ çemberine dayanıyordu. Kale duvarlarının içinde her şey güvenilir; dışarıda ise her şey kötü niyetli kabul ediliyordu. Mikroservisler, konteynerleştirme ve çoklu bulut dağıtımları çağında bu "kale ve hendek" yaklaşımı artık geçerliliğini yitirmiştir. Hizmetlerin dinamik ağlar üzerinden, çoğunlukla farklı bulut sağlayıcıları arasında iletişim kurmasıyla çember erimiştir. İşte burada Sıfır Güvenlik Mimarisi (ZTA) devreye girer: Güvenin asla örtük olmaması ve her zaman doğrulanması gerektiği varsayımına dayanan bir güvenlik paradigmaları.
Geliştiriciler ve güvenlik mühendisleri için mikroservis ortamında Sıfır Güvenlik uygulamak yalnızca bir politika değişikliği değil, aynı zamanda temel bir mimari değişikliktir. Bu yazıda, kimlik, en az ayrıcalık ve sürekli doğrulama odaklanarak perimeter savunmasının ötesine nasıl geçileceği ele alınmaktadır.
Mikroservislerde Sıfır Güvenliğin Temel Direkleri
Özü itibarıyla Sıfır Güvenlik üç temel ilkeye dayanır: Açıkça Doğrula, En Az Ayrıcalıklı Erişim Kullan ve Sızma Varsay. Monolitik bir uygulamada bunları merkezi olarak uygulamak daha kolaydır. Mikroservislerde ise, her hizmetten hizmete iletişim, aksi ispatlanana kadar potansiyel olarak düşmanca olarak ele alınmalıdır.
Bu, güvenliği ağ katmanından (IP beyaz listesi) kimlik katmanına kaydırmayı gerektirir. Her hizmetin benzersiz ve doğrulanabilir bir kimliği olmalı ve her istek, nereden geldiğine bakılmaksızın yürütmeden önce kimliği doğrulanmalı ve yetkilendirilmelidir.
Karşılıklı TLS (mTLS) Uygulama
Mikroservislerde Sıfır Güvenliğin en kritik teknik bileşeni Karşılıklı TLS (mTLS)'dir. Standart TLS'te yalnızca sunucunun kimliğini istemciye kanıtlaması gerektiği halde, mTLS her iki tarafın da sertifikaları sunmasını gerektirir. Bu, Hizmet A'nın yalnızca her iki tarafın da geçerli, verilmiş sertifikalara sahip olması durumunda Hizmet B ile iletişim kurabileceğini sağlar.
mTLS'i manuel olarak uygulamak karmaşıktır ve hata yapmaya açıktır. Bu nedenle, TLS sonlandırma ve sertifika yenileme işlemlerini otomatik olarak yönetmek için Hizmet Ağları (örneğin Istio, Linkerd) veya API Ağ Geçitleri gibi altyapıya güveniriz. Uygulama kodu şifreleme hakkında bilgisiz kalırken, sidecar vekil sunucusu güvenli kanalı yönetir.
Örnek: Sıkı Erişim Politikalarını Zorlama
Bir Istio Politika nesnesi kullanarak, yalnızca belirli hizmetlerin iletişim kurmasına izin verildiğini zorlayabilirsiniz. Bu örnek, yalnızca `frontend` hizmetinin `backend` hizmetini çağırabildiği sıkı bir politikayı göstermektedir.
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: backend-policy
namespace: production
spec:
selector:
matchLabels:
app: backend
action: ALLOW
rules:
- from:
- source:
principals: ["cluster.local/ns/production/sa/frontend"]
to:
- operation:
methods: ["GET", "POST"]
paths: ["/api/v1/data"]Bu kod parçasında `principal` alanı, saldırganın `production` ad alanı içindeki bir sunucuyu ele geçirse bile, `frontend` hizmet hesabının belirli kimlik belirtecine sahip olmadıkça arka uca erişemeyeceğini garanti eder.
Kısa Ömürlü Belirteçler ve Kimlik Birleştirme
Perimeter savunması genellikle statik kimlik bilgilerine veya uzun ömürlü API anahtarlarına dayanır. Sıfır Güvenlik modelinde, geçici kimlik bilgileri benimsememiz gerekir. Minimum süresi olan JSON Web Belirteçleri (JWT) gibi kısa ömürlü belirteçler, bir kimlik bilgisini ele geçiren bir saldırgan için fırsat penceresini azaltır.
Ayrıca, kimlik birleştirme hizmetlerin farklı güven alanları arasında kimlik doğrulamasını sağlar. OpenID Connect (OIDC) gibi standartları kullanarak, her iki taraf da aynı Kimlik Sağlayıcısına (IdP) güveniyorsa, AWS'deki bir mikroservis Kubernetes'teki bir mikroservis ile güvenli bir şekilde iletişim kurabilir.
Pratik İpucu: Sertifikaları Otomatik Olarak Yenileyin
mTLS sertifikalarını asla manuel olarak yönetmeyin. Sertifika yayınlama ve yenileme işlemlerini otomatikleştirmek için Vault veya cert-manager gibi bir PKI (Açık Anahtar Altyapısı) ile entegrasyon kurun. Eski sertifikalar ciddi bir güvenlik riski oluşturur ve sıfır-güvenlik uygulamalarında yaygın bir başarısızlık noktasıdır.
Gözlemlenebilirlik Zorluğu
Sıfır Güvenlik uygulaması önemli miktarda günlük oluşturma yükü oluşturur. Her reddedilen istek, her kimlik doğrulama denemesi ve her politika değerlendirmesi izlenmelidir. Güçlü gözlemlenebilirlik (Prometheus, Grafana gibi araçlar ve Jaeger veya Zipkin gibi dağıtık izleme) olmadan, Sıfır Güvenlik politikalarınızın etkili olup olmadığını veya yanlışlıkla meşru trafiği engellemediğini bilemezsiniz.
Loglarınızın hizmet kimliği, istek kimliği ve karar sonucu (izin ver/reddet) hakkında bağlam içermesini sağlayın. Bu veriler denetim ve zamanla en az ayrıcalık politikalarınızı ince ayar yapmak için hayati önem taşır.
Sonuç
Mikroservislerde Sıfır Güvenliğe geçiş bir varış noktası değil, bir yolculuktur. Hizmet ağları benimseme gibi mimari değişikliklerin yanı sıra, sıkı kimlik yönetimi ve otomatik sertifika yenileme gibi operasyonel disiplin gerektirir. İlk kurulum korkutucu görünse de, ödül modern dağıtık sistemlerin karmaşıklığına dayanabilen sağlam bir güvenlik pozisyonudur. Sızma varsayarak ve açıkça doğrulayarak, çember artık mevcut olmasa bile uygulamalarınızın güvenli kalmasını sağlarsınız.