Modern dağıtık ortamda, geleneksel çevre tabanlı güvenlik modeli etkili bir şekilde çökmüştür. Kurumlar monolitik uygulamalardan mikroservis mimarilerine geçtikçe, ihlal edilen bir bileşenin patlama yarıçapı katlanarak artar. Bu değişim, Sıfır Güven Mimarisi'ne (ZTA) doğru bir geçişi zorunlu kılar; bu, iç veya dış tüm trafiğin varsayılan olarak güvenilmediği bir işletim modelidir. Mikroservisler için, bu modeldeki en kritik kontrol düzlemi servisler arası iletişimidir ve bu en iyi şekilde Karşılıklı Taşıma Katmanı Güvenliği (mTLS) ile güvence altına alınır.
Neden Mikroservisler İçin Sıfır Güven Müzakere Edilemez?
Geleneksel güvenlik, kurumsal güvenlik duvarının içindeki her şeyin güvenli olduğu varsayımına dayanıyordu. Mikroservis ortamında, servisler güven sınırının etkin olarak "dışında" olan bir ağ üzerinden iletişim kurar. Bir saldırgan bir pod'u veya konteyneri ihlal ederse, iç trafik şifrelenmemiş veya doğrulanmamışsa diğer servislere yanal olarak hareket edebilir. Sıfır Güven, kökeni ne olursa olsun her isteğin doğrulanmasını, yetkilendirilmesini ve şifrelenmesini zorunlu kılar. Bu "asla güvenme, her zaman doğrula" ilkesi, modern uygulama güvenliğunun temel taşıdır.
Kimlik Doğrulamada Karşılıklı TLS (mTLS) Rolü
Standart TLS (HTTPS) şifreleme ve sunucu doğrulaması sağlar. Ancak bir mikroservis ağında, istemci (Servis A) sunucuya (Servis B) kimliğini de kanıtlamak zorundadır. İşte mTLS burada ön plana çıkar. Standart TLS'in aksine, mTLS güvenli bir kanal kurulmadan önce her iki tarafın da (istemci ve sunucu) birbirlerinin kimliğini doğrulamak için X.509 sertifikaları sunmasını gerektirir.
mTLS uygulaması şunları sağlar:
- Şifreleme: Aktarım sırasında veri şifrelenir; bu da dinlemeyi ve ortadaki adam saldırılarını önler.
- Doğrulama: Sadece geçerli ve güvenilir sertifikalara sahip servisler iletişim kurabilir; bu da yetkisiz servislerin ağa katılmasını engeller.
- Bütünlük: Mesajın aktarım sırasında değiştirilmediğini garanti eder.
Pratik Uygulama: Cert-Manager ile Sertifikaları Yönetme
mTLS'yi ölçeklenebilir şekilde uygulamanın en büyük zorluklarından biri sertifika yaşam döngüsü yönetimidir. Onlarca servis için sertifikaları manuel olarak yenilemek insan hatasına ve operasyonel yükümlülüklere açıktır. İşte burada Kubernetes üzerinde cert-manager gibi araçlar vazgeçilmez hale gelir.
Aşağıda, payment-service adlı bir mikroservis için TLS sertifikalarının otomatik olarak verilmesi ve yenilenmesi amacıyla bir Issuer ve Certificate kaynağını nasıl tanımlayacağınıza dair pratik bir örnek bulunmaktadır.
# Adım 1: ClusterIssuer'ı Tanımlayın (gösterim amaçlı Let's Encrypt kullanılıyor)
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-prod
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/directory
email: security@yourcompany.com
privateKeySecretRef:
name: letsencrypt-prod-key
solvers:
- http01:
ingress:
class: nginx
---
# Adım 2: Ödeme servisi için bir sertifika isteyin
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: payment-service-cert
namespace: payment-system
spec:
secretName: payment-service-tls
issuerRef:
name: letsencrypt-prod
kind: ClusterIssuer
duration: 2160h # 90 gün
renewBefore: 360h # 15 gün
commonName: payment-service.payment-system.svc
dnsNames:
- payment-service.payment-system.svc
- payment-service.payment-system.svc.cluster.local
Yan Araç (Sidecar) Proxy'leri ile Sıfır Güveni Zorunlu Kılma
TLS'yi doğrudan uygulama kodu içinde yapılandırmak mümkün olsa da, bu genellikle farklı diller ve çerçeveler arasında karmaşık ve sürdürülmesi zordur. Endüstri standardı yaklaşım, yan araç proxy kalıbını kullanan Istio veya Linkerd gibi bir servis ağı kullanmaktır. Proxy, mTLS el sıkışmasını, sertifika yenilemesini ve trafik şifrelemesini otomatik olarak ele alarak geliştiricilerin iş mantığına odaklanmasına olanak tanır.
Istio ağı içinde mTLS'yi zorunlu kılmak için bir PeerAuthentication ilkesi uygulayabilirsiniz. Bu, ad alanı içindeki tüm trafiğin karşılıklı TLS gerektirmesini sağlar.
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: payment-system
spec:
mtls:
mode: STRICT
Modu STRICT olarak ayarlamak, geçerli bir istemci sertifikası sunmayan herhangi bir trafiği reddeder. Bu, iletişim kanalını etkili bir şekilde kilitler ve yalnızca kayıtlı ve doğrulanmış servislerin etkileşime girmesini sağlar.
Sonuç
Mikroservisleri ölçeklenebilir şekilde çalıştıran kurumlar için Karşılıklı TLS aracılığıyla Sıfır Güven Mimarisi uygulamak artık bir seçenek değil, bir zorunluluktur. Servisler arası iletişimi güvence altına almak, yanal hareket ve yetkisiz erişim risklerini azaltmak için sağlam bir çerçeve sağlar. İlk kurulum, özellikle sertifika yaşam döngüsü yönetimi açısından dikkatli planlama gerektirse de, güvenlik durumu, uyumluluk ve operasyonel dayanıklılık açısından uzun vadeli faydaları büyüktür. Cert-manager ve servis ağları gibi araçlardan yararlanarak geliştiriciler güvenlik kontrollerini otomatikleştirebilir ve modern tehdit ortamına hazır, güvenilmeyen (trustless) sistemler inşa edebilir.