Dağıtık sistemler dünyasında geleneksel çevre tabanlı güvenlik modelleri artık geçerli değil. Mikroservisler iç ağlar üzerinden iletişim kurarken, "iç trafiğin güvenli olduğu" varsayımı tehlikeli bir yükümlülük oluşturur. Sıfır Güven Mimarisi (ZTA), asla güvenme, her zaman doğrula ilkesi üzerine çalışır. Karmaşık mikroservis ekosistemlerini yöneten geliştiriciler için ZTA'yı uygulamak artık bir seçenek değil—bir zorunluluktur. Bu rehber, kimlik, şifreleme ve en az ayrıcalık erişimini hizmet ağınıza (service mesh) entegre ederek uygulama güvenliğinizi nasıl güçlendireceğinizi inceler.
Mikroservislerde Sıfır Güvenin Temel İlkeleri
Uygulamaya geçmeden önce, Sıfır Güvenin üç temel direğini anlamak kritik öneme sahiptir: açıkça doğrula, en az ayrıcalık erişimi kullan ve ihlali varsay. Monolitik bir uygulamada ağ segmentlerine güvenebilirsiniz. Ancak mikroservislerde, A Hizmeti ile B Hizmeti arasındaki her istek, küme içinde veya dışında kaynaklanmasından bağımsız olarak kimlik doğrulamasından ve yetkilendirmeden geçmelidir. Bu değişim, güvenlik endişelerini ağ katmanından uygulama ve kimlik katmanlarına taşımamızı gerektirir. Bunu başlıca bir Hizmet Ağı (Service Mesh) ve mTLS (Karşılıklı Taşıma Katmanı Güvenliği) kullanarak gerçekleştireceğiz.Kimliğin Karşılıklı TLS (mTLS) ile Zorlanması
Mikroservis ortamında ZTA'nın temeli kimliktir. Her hizmetin, genellikle bir sertifika ile temsil edilen benzersiz bir dijital kimliği olmalıdır. mTLS, veri alışverişinden önce hem istemcinin hem de sunucunun birbirlerinin kimliklerini doğrulamasını sağlar.
Sertifikaları manuel olarak yönetebilirsiniz ancak Istio veya Linkerd gibi araçlar Kubernetes kümesinde bu süreci otomatikleştirir. Aşağıda, production namespace'indeki tüm trafik için mTLS'i zorlayan bir Istio PeerAuthentication kaynağı örneği bulunmaktadır.
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: production
spec:
mtls:
mode: STRICT
---
# Örnek: Belirli bir hizmet için mTLS zorlaması
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: payment-service
namespace: production
spec:
selector:
matchLabels:
app: payment-service
mtls:
mode: STRICT
Modu STRICT olarak ayarlayarak, hizmet ağı her türlü düz metin (plaintext) trafiği reddedecektir. Bu, bir saldırganın iç ağa erişim sağlasa bile, kümenin Sertifika Otoritesi'nden (CA) geçerli bir sertifika almadan trafiği izole edemeyeceğini veya enjekte edemeyeceğini garanti eder.
Yetkilendirme Politikaları ile Granüler Erişim Kontrolü
Kimlik doğrulaması sadece ilk adımdır. Kimlik kurulduktan sonra, kimin ne yapabileceğini kontrol etmeliyiz. Sıfır Güven, en az ayrıcalık erişimini gerektirir. Varsayılan olarak trafiği açıkça reddeden ve yalnızca gerekli akışlara izin veren Yetkilendirme Politikaları yapılandırmalıyız.
frontend-service'nin inventory-service'i çağırması gerektiğini, ancak başka hiçbir hizmetin buna erişememesi gerektiğini varsayalım. Bunu bir Istio AuthorizationPolicy kullanarak zorlayabiliriz.
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: inventory-access-policy
namespace: production
spec:
selector:
matchLabels:
app: inventory-service
action: ALLOW
rules:
- from:
- source:
principals: ["cluster.local/ns/production/sa/frontend-service"]
to:
- operation:
methods: ["GET", "POST"]
paths: ["/api/v1/items/*"]
Bu politika, yalnızca frontend-service'nin inventory-service üzerindeki belirli uç noktalara erişim sağlayabilmesini garanti eder. payment-service aynı uç noktalara erişmeye çalışırsa, istek reddedilir. Bu mikro-segmentasyon, potansiyel bir ihlalin yayılma çapını (blast radius) büyük ölçüde azaltır.
Gözlemlenebilirlik ve Sürekli İzleme
Sıfır Güven modelinde görünürlük güçtür. Göremediğiniz bir şeyi güvence altına alamazsınız. Kimlik doğrulama hatalarını, olağan dışı trafik desenlerini ve politika ihlallerini izlemek için sağlam günlük kaydı ve izleme uygulamaları kullanın. Prometheus ve Grafana gibi araçlar bu metrikleri görselleştirebilir, böylece anormallikleri gerçek zamanlı olarak tespit etmenize yardımcı olabilir.
Loglarınızda source.identity, destination.service ve authorization.result gibi bağlamsal bilgiler içerdiğinden emin olun. Bu veriler, adli analiz ve uyumluluk denetimi için paha biçilmezdir.
Sonuç
Mikroservisler için Sıfır Güven Mimarisi uygulaması bir varış noktası değil, bir yolculuktur. Güvenlik-mimari (security-by-design) yaklaşımına yönelik kültürel bir değişimi ve mTLS ile granüler yetkilendirme politikaları gibi sağlam teknik uygulamaları gerektirir. Her kimliği doğrulayarak ve en az ayrıcalığı zorlayarak, uygulamanızı hem dış tehditlere hem de iç ihlallere karşı korursunuz. mTLS zorlamasıyla başlayın, ince taneli erişim kontrolüne geçin ve dayanıklı, güvenli bir mimariyi korumak için ortamınızı sürekli olarak izleyin.