Mikroservis İletişiminde Sıfır Güven Mimarisi Uygulama

Kurumsal ağın sınırları uzun zaman önce buharlaşmıştır. Konteynerleştirme ve mikroservislerin yaygınlaşmasıyla uygulamalar birden fazla ortamda dağıtılmaktadır: yerel sunucular, bulut sağlayıcıları ve uç cihazlar. Bu manzarada, geleneksel "kale ve hendek" güvenlik modeli artık geçerliliğini yitirmiştir. Güvenliği ağ konumuna dayalı bir vekil olarak kullanmak tehlikeli bir yanılgıdır. Bunun yerine, kuruluşlar "asla güvenme, her zaman doğrula" ilkesiyle hareket eden bir Sıfır Güven Mimarisi'ni (ZTA) benimsemelidir.

Mikroservislerde Sıfır Güvenin Temel İlkeleri

Sıfır Güven, tek bir ürün veya teknoloji değildir; hibrit kaynakları güvence altına almak için stratejik bir yaklaşımdır. Mikroservisler için üç temel sütun kritiktir:

1. Açıkça Doğrula: Kullanıcı kimliği, hizmet kimliği, konum, cihaz sağlığı ve hizmet davranışı dahil olmak üzere mevcut tüm veri noktalarına dayanarak kimlik doğrulama ve yetkilendirme yapın.
2. En Az Ayrıcalık Erişimini Kullanın: Kullanıcı erişimini Zamanında ve Tam Erişim (JIT/JEA), risk temelli uyarlanabilir politikalar ve veri belirteçleştirme ile sınırlayın.
3. Sızma Varsayın: Patlama yarıçapını minimize edin ve erişimi segmentlere ayırın. Uçtan uca şifrelemeyi doğrulayın ve sızma durumuna ilişkin görünürlük elde etmek için get-analytics kullanın.

Mikroservis ekosisteminde bu, Hizmet A'nın Hizmet B ile aynı kümede veya ad alanında bulunduğu için onunla iletişim kurabileceği anlamına gelmez. Kaynağı ne olursa olsun, her istek kimlik doğrulamasından ve yetkilendirmeden geçmelidir.

Kimliği Uygulama: Hizmetten Hizmete Kimlik Doğrulama

Mikroservislerde Sıfır Güveni uygulamanın en etkili yolu, Karşılıklı Taşıma Katmanı Güvenliği (mTLS) aracılığıyla gerçekleşir. Geleneksel TLS'de sunucunun istemciye kimliğini kanıtlamasının aksine, mTLS her iki tarafın da sertifikalar sunmasını gerektirir. Bu, yalnızca yetkili hizmetlerin iletişim ağına katılmasını sağlar.

Istio ve Kubernetes ile Uygulama

mTLS'yi kod seviyesinde manuel olarak uygulamak karmaşıktır ve hata yapmaya açıktır. Bunun yerine, ağ trafiğini engelleyen ve güvenlik politikalarını otomatik olarak uygulayan Istio gibi bir Hizmet Ağı (Service Mesh) kullanırız. Aşağıda, belirli bir ad alanı için SERTİ mTLS'yi uygulayan bir Istio PeerAuthentication politikası örneği bulunmaktadır.

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT
---
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: strict-mtls
  namespace: sensitive-data
spec:
  mtls:
    mode: STRICT
    portLevelMtls:
      8080:
        mode: PERMISSIVE  # Eski hizmetler için yedek

Bu yapılandırmada, sensitive-data ad alanı içinde geçerli bir istemci sertifikası olmadan 443 veya 8080 portunda iletişim kurmaya çalışan herhangi bir hizmet reddedilecektir. Bu, tüm iç trafik için şifreli ve kimliği doğrulanmış bir tünel oluşturur.

AuthorizationPolicies ile Granüler Yetkilendirme

Kimlik doğrulama "Sen kimsin?" sorusuna, yetkilendirme ise "Ne yapmana izin verilir?" sorusuna cevap verir. Sıfır Güven modelinde, ince taneli erişim kontrolü politikaları tanımlamamız gerekir. Istio, hangi kaynak öncüllerinin hangi hedef yükleri ve yolları erişebileceğini belirtmemize olanak tanır.

Sadece order-service'un payment-service'u çağırabilmesi gerektiği bir senaryoyu ele alalım. Bunu bir AuthorizationPolicy kullanarak uygulayabiliriz.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: payment-restrictions
  namespace: production
spec:
  selector:
    matchLabels:
      app: payment-service
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/production/sa/order-service"]
    to:
    - operation:
        methods: ["POST"]
        paths: ["/pay/*"]

Bu politika, ağın sızdırılması durumunda bile bir saldırganın, halka açık bir web sunucusu veya kötü amaçlı bir konteyner gibi yetkisiz hizmetlerden ödeme uç noktalarını çağıramayacağını garanti eder. En az ayrıcalık ilkesine sıkı sıkıya bağlı kalır.

Gözlemlenebilirlik: Geri Bildirim Döngüsü

Sıfır Güven, ayarla-unut yöntemiyle çalışan bir çözüm değildir. Sürekli izleme gerektirir. Mikroservis mimarisinde gözlemlenebilirlik, güvenliğin omurgasıdır. Prometheus, Grafana veya Jaeger gibi araçlarla entegrasyon yaparak ekipler, trafik akışlarını görselleştirebilir, anormallikleri tespit edebilir ve potansiyel sızma durumlarını gerçek zamanlı olarak belirleyebilir.

Başarısız kimlik doğrulama girişimleri, olağan dışı istek oranları veya iletişim kurmaması gereken hizmetler arasındaki trafik gibi metrikler, sızma durumunun ana göstergeleridir. Güvenlik ekipleri, bu metrikleri uyumluluk durumunun bir parçası olarak ele almalı ve yerleşik Sıfır Güven taban çizgisinden sapmalarda uyarı vermelidir.

Sonuç

Mikroservis iletişimi için Sıfır Güven uygulamak bir varış noktası değil, bir yolculuktur. Sınır tabanlı savunmadan kimlik odaklı güvenliğe bir zihniyet değişikliği gerektirir. Hizmet ağları gibi araçları kullanarak mTLS ve ince taneli yetkilendirme politikalarını uygulamak, kuruluşların saldırı yüzeyini önemli ölçüde azaltmasına olanak tanır. Mikroservisler gelişmeye devam ettikçe, hassas verileri korumak ve giderek daha da dağıtılan dijital dünyada iş sürekliliğini sağlamak için titiz bir Sıfır Güven duruşunu sürdürmek hayati önem taşıyacaktır.