Mikroservislerde Zero-Trust Mimarisi: Taşıma Katmanında mTLS mi, Uygulama Katmanında JWT mi? Karar Çerçevesi

Giriş

Mikroservis mimarilerinde “network içindeyse güvenlidir” varsayımı, 2010’ların ortalarından itibaren geçerliliğini tamamen yitirdi. Geleneksel perimeter (çevre) güvenliği, bir saldırganın ağa sızdığı anda (lateral movement) tüm sistemde yatayda hareket edebilmesine olanak tanıyordu. Bu zafiyet, bizi hiçbir aktöre, servise veya ağ segmentine varsayılan olarak güvenmeyen Zero-Trust (Sıfır Güven) mimarisine itti.

Production ortamında Zero-Trust inşa ederken mimarların karşısına çıkan en kritik ikilem şudur: Servisler arası yetkilendirmeyi taşıma katmanında (mTLS) mı yapmalıyız, yoksa uygulama katmanında (JWT/OAuth2) mı? Her iki yaklaşımın da işlemci döngüleri (CPU cycles), p99 gecikme süreleri (latency) ve operasyonel karmaşıklık açısından ciddi maliyetleri vardır. Kubernetes üzerinde 1500+ pod koşturan bir altyapıda yanlış güvenlik modeli seçimi, sadece güvenlik açıklarına değil, aynı zamanda %30’a varan CPU israfına ve timeout zincirlerine yol açar.

Bu rehberde, 15 yıllık production tecrübelerinden süzülmüş, SPIFFE tabanlı mTLS ile RFC-7519 standartlarındaki JWT’nin hangi senaryolarda tercih edilmesi gerektiğini, trade-off analizlerini ve karar ağaçlarını inceleyeceğiz.

İçindekiler

• Taşıma Katmanı ve Uygulama Katmanı Güvenlik İkilemi
• Karar Matrisi ve Kriterler
• Karar Ağacı: Eğer X İse -> Y
• Pratik Bir Vaka: Finansal Servislerde Hibrit Model
• Konfigürasyon ve Kod Örnekleri
• Pratik Öneriler / Production Notları
• Sık Sorulan Sorular
• Sonuç

Taşıma Katmanı ve Uygulama Katmanı Güvenlik İkilemi

mTLS (Mutual TLS): Taşıma Katmanı Güvenliği

mTLS, TLS protokolünün iki yönlü olarak işletilmesidir. Sadece istemci sunucuyu (X.509 sertifikası ile) doğrulamaz, sunucu da istemciden geçerli bir sertifika talep eder. Istio veya Linkerd gibi service mesh yapıları kullanıldığında, proxy’ler (örneğin Envoy 1.28.0) bu işlemi uygulama kodundan bağımsız olarak yönetir.

Avantajları: Uygulama kodunda değişiklik gerektirmez. Trafik şifrelenir (confidentiality) ve manipülasyona karşı korunur (integrity). Kimlik (Identity), SPIFFE ID formunda (örneğin: spiffe://cluster.local/ns/billing/sa/payment-processor) sertifikanın SAN (Subject Alternative Name) alanına gömülür.

Dezavantajları: Sadece “Hangi makine/servis benimle konuşuyor?” sorusuna cevap verir. “Bu isteği başlatan son kullanıcı kim?” sorusu taşıma katmanının umrunda değildir.

JWT (JSON Web Token): Uygulama Katmanı Güvenliği

JWT, RFC 7519 standardına dayalı, Base64Url ile encode edilmiş ve kriptografik olarak imzalanmış (RS256, ES256) JSON objeleridir. İstemci, genellikle HTTP Authorization: Bearer <token> header’ı ile bu token’ı iletir.

Avantajları: Son kullanıcı bağlamını (user context) taşır. sub (subject), roles, tenant_id gibi claim’ler sayesinde, uygulamanın spesifik bir kayda (örneğin, /api/v1/orders/8842) erişim yetkisini (authorization) milisaniyeler içinde kontrol etmesini sağlar.

Dezavantajları: JWT, HTTP header’larında plaintext (Base64) taşınır. Taşıma katmanı şifrelenmemişse (düz HTTP), token kolayca çalınabilir (replay attack). Ayrıca, asimetrik imza doğrulama işlemleri (örneğin RSA-2048) yüksek RPS altındaki servislerde ciddi CPU yükü yaratır.

Karar Matrisi ve Kriterler

Aşağıdaki matris, mimari tasarım aşamasında hangi teknolojinin hangi probleme yanıt verdiğini netleştirmektedir:

Kriter	mTLS (Taşıma Katmanı)	JWT (Uygulama Katmanı)
Kimlik Granülaritesi	Servis / Workload bazlı (Makine Kimliği)	Kullanıcı / İşlem bazlı (İnsan/Aktör Kimliği)
Performans Maliyeti	Bağlantı kurulumunda handshake (Envoy pool ile amorti edilir)	Her HTTP isteğinde imza (signature) doğrulaması
İptal (Revocation)	Zor. Kısa ömürlü sertifikalar (TTL 1-24 saat) gerekir.	Zor. Kısa ömürlü token’lar (TTL 5-15 dk) + Redis blocklist.
Veri Gizliliği (Encryption)	Var (AES-256-GCM / ChaCha20-Poly1305)	Yok (JWE kullanılmadığı sürece sadece imza doğrulanır)
Altyapı Bağımlılığı	Service Mesh (Istio/Linkerd) veya PKI altyapısı şarttır.	Kimlik sağlayıcı (OIDC/Keycloak/Auth0) şarttır.

Karar Ağacı: Eğer X İse -> Y

Karmaşık mimarilerde tek bir doğru yoktur. Ancak belirli pattern’ler kendini kanıtlamıştır. İşte karar çerçevesinin özeti:

• Eğer servisler arası iletişimde sadece makine kimliği (örneğin; “Inventory servisi, Database servisine bağlanabilir mi?”) doğrulanacaksa -> Sadece mTLS kullanın. JWT’nin getireceği CPU maliyetinden kaçının.
• Eğer Edge/Gateway üzerinden gelen bir isteğin içindeki son kullanıcı kimliği (User ID, Tenant ID) 3-4 katman derindeki bir servise kadar iletilecekse ve bu servis veri tabanı seviyesinde Row-Level Security uygulayacaksa -> JWT kullanın. (Ancak trafiği dışarıdan izlenmeye karşı korumak için altta mTLS’i varsayılan olarak açık tutun).
• Eğer sistem dışı entegrasyonlar (Third-party API’ler, Webhook’lar) servisinize doğrudan erişiyorsa -> JWT (veya OAuth2 Token) kullanın. Dış aktörlere internal PKI altyapınızdan sertifika dağıtmak operasyonel bir kabustur.
• Eğer regülasyonlar (PCI-DSS 4.0, HIPAA) veri iletiminde uçtan uca (end-to-end) şifreleme ve makine doğrulamasını zorunlu kılıyorsa -> Mutlaka mTLS kullanın, kullanıcı bazlı yetkilendirme gerekiyorsa Hibrit (mTLS + JWT) modele geçin.

Pratik Bir Vaka: Finansal Servislerde Hibrit Model

2022 yılında, saniyede ortalama 22.000 işlem (RPS) işleyen bir ödeme ağ geçidinin (Payment Gateway) mikroservis dönüşümünde karşılaştığımız darboğazı inceleyelim.

İlk mimaride, Zero-Trust prensibi gereği her servis birbirini JWT ile doğruluyordu. İstemciden gelen JWT, Gateway tarafından alınıyor, ardından Fraud, Ledger ve Notification servislerine sırayla iletiliyordu. Her servis, gelen isteğin HTTP header’ından JWT’yi okuyor, OIDC sağlayıcısının JWKS (JSON Web Key Set) endpoint’inden aldığı public key ile RSA-256 doğrulamasını uygulama katmanında (Node.js ve Go process’leri içinde) yapıyordu.

Sorun: Yük testlerinde, 22.000 RPS seviyesinde, sırf JWT imza doğrulama işlemleri nedeniyle Go tabanlı servislerde p99 gecikme süresi 18ms’den 115ms’ye fırladı. Node.js servislerinde Event Loop bloklandığı için timeout zincirleri oluştu.

Çözüm (Hibrit Model):
Uygulama kodunun içindeki JWT doğrulama kütüphanelerini tamamen kaldırdık. Istio (Service Mesh) entegre ettik.
1. Servisler arası tüm iletişim Envoy proxy’ler üzerinden mTLS ile şifrelendi. (Makine kimliği güvenceye alındı).
2. Kullanıcı kimliğini taşıyan JWT’nin doğrulanma işlemini Istio’nun RequestAuthentication kaynağına devrettik. Envoy, C++ tabanlı optimize edilmiş kriptografi kütüphaneleriyle token’ı proxy katmanında doğruladı.
3. Geçerli olan isteği, payload (claim’ler) çözülmüş olarak (örneğin X-User-Id header’ı ekleyerek) localhost üzerinden bizim uygulama konteynerine iletti.

Sonuç: CPU kullanımında %32 düşüş sağlandı. P99 gecikmesi 115ms’den 24ms seviyesine geriledi. Uygulama geliştiricileri artık kriptografik anahtar rotasyonu düşünmek zorunda kalmadı.

Konfigürasyon ve Kod Örnekleri

Yukarıda bahsedilen hibrit modeli Istio üzerinde hayata geçirmek için gereken YAML konfigürasyonları aşağıdadır.

1. Adım: Tüm Namespace için mTLS’i Zorunlu Kılmak (STRICT Mod)

Aşağıdaki PeerAuthentication kuralı, payments namespace’indeki tüm servislerin yalnızca mTLS bağlantılarını kabul etmesini sağlar. Plaintext (şifresiz) trafik anında reddedilir.

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default-mtls
  namespace: payments
spec:
  mtls:
    mode: STRICT

2. Adım: Envoy Proxy Üzerinde JWT Doğrulama

Aşağıdaki RequestAuthentication kuralı, Istio Ingress veya belirli bir servis üzerinden gelen HTTP isteklerindeki JWT’yi doğrular. Geçersiz bir token doğrudan HTTP 401 döndürür, istek uygulama koduna (Pod’a) asla ulaşmaz.

apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
  name: jwt-auth
  namespace: payments
spec:
  selector:
    matchLabels:
      app: ledger-service
  jwtRules:
  - issuer: "https://auth.sirketiniz.com"
    jwksUri: "https://auth.sirketiniz.com/.well-known/jwks.json"
    forwardOriginalToken: true

Pratik Öneriler / Production Notları

Zero-Trust teoride kusursuz görünse de, pratik uygulamada en ufak bir konfigürasyon hatası tüm cluster’ı erişilemez hale getirebilir (Cascading failure).

• JWT Şişmesi (Token Bloat): JWT’lerin içine gereksiz claim’ler doldurmayın. Envoy ve Nginx gibi proxy’lerin varsayılan HTTP header boyut limiti genellikle 8KB veya 16KB’dır. Eğer Active Directory gruplarını JWT içine gömerseniz, token boyutu 10KB’ı aşabilir ve proxy katmanında HTTP 431 (Request Header Fields Too Large) hataları almaya başlarsınız.
• JWKS Caching Hayat Kurtarır: Uygulama katmanında JWT doğruluyorsanız, public key’leri barındıran JWKS endpoint’ini her istekte çağırmayın. JWKS verisini in-memory veya Redis üzerinde minimum 300 saniye (5 dakika) TTL ile önbelleğe (cache) alın. Aksi takdirde Identity Provider (IdP) servisinizi kendi iç trafiğinizle DDoS etmiş olursunuz.
• Algoritma Seçimi: Eğer JWT oluşturma ve doğrulama sizin kontrolünüzdeyse, RSA yerine Elliptic Curve (ES256 veya EdDSA) algoritmalarını tercih edin. ES256, RS256’ya kıyasla imza boyutunda çok daha küçüktür ve CPU maliyeti ciddi oranda düşüktür.
• Sertifika Rotasyonu: mTLS altyapısında uzun ömürlü (1 yıl) sertifikalar kullanmayın. Istio Citadel veya cert-manager kullanıyorsanız, sertifika TTL sürelerini 24 saat, hatta mümkünse 1 saat olarak ayarlayın. Bir private key sızdırılırsa, saldırganın penceresi sadece dakikalarla sınırlı kalmalıdır.

Sık Sorulan Sorular

mTLS kullanıyorsam, servisler arası yetkilendirme (Authorization) yapamaz mıyım?

Yapabilirsiniz. mTLS size Authentication (Kimlik Doğrulama) sağlar. SPIFFE ID’yi aldıktan sonra, Istio AuthorizationPolicy veya OPA (Open Policy Agent) kullanarak “Servis A, Servis B’nin /delete endpoint’ine POST atabilir mi?” kontrolünü yapabilirsiniz. Ancak bu, kullanıcı (User) bazlı değil, servis bazlı bir yetkilendirmedir.

Service Mesh kullanmadan mTLS uygulayabilir miyim?

Evet, uygulamalarınızın (örneğin Java Spring Boot veya Go) kendi içlerinde TLS handshake’ini yönetecek kod blokları yazabilir ve sertifikaları Kubernetes Secrets üzerinden mount edebilirsiniz. Ancak bu yöntem, sertifika rotasyonunu ve policy yönetimini manuel hale getireceği için 10’dan fazla servisin olduğu ortamlarda operasyonel olarak yönetilemez bir hal alır.

Hem mTLS hem JWT kullanmak (Hibrit Model) performansı ne kadar etkiler?

Doğru yapılandırılmış bir sistemde (Envoy bağlantı havuzu kullanımı ve JWT’nin C++ proxy katmanında doğrulanması) ekstra gecikme p50’de 1-2ms, p99’da ise maksimum 5-8ms civarında olacaktır. Bu maliyet, Zero-Trust’ın sağladığı güvenlik kalkanı için fazlasıyla kabul edilebilirdir.

Token iptali (Revocation) mTLS’te mi yoksa JWT’de mi daha kolaydır?

Her ikisinde de anlık iptal zordur. JWT tarafında token’ın süresinin (Expiration Time – exp) dolması beklenir veya kritik işlemler için bir veritabanı/Redis tabanlı blocklist kontrolü yapılır. mTLS’te ise iptal için CRL (Certificate Revocation List) veya OCSP kullanılabilir ancak bulut tabanlı modern (cloud-native) mimarilerde bunun yerine sertifika ömrünü (TTL) çok kısa tutmak (örneğin 1 saat) tercih edilen yöntemdir.

Sonuç

Zero-Trust mimarisinde mikroservis iletişimini güvence altına alırken “mTLS mi yoksa JWT mi?” sorusunun cevabı bir tercih değil, mimari bir konumlandırma meselesidir. Taşıma katmanı ve uygulama katmanı güvenlikleri birbirinin rakibi değil, tamamlayıcısıdır. mTLS, ağ üzerindeki makine iletişimini dış etkenlere karşı izole ederken, JWT (veya OAuth2), iş mantığını barındıran katmanlara “bu işlemi kim, hangi yetkiyle yapmak istiyor?” bilgisini taşır.

Aksiyon planı olarak: Altyapınızda henüz hiçbiri yoksa, ilk adım olarak Service Mesh (Istio/Linkerd vb.) ile servisler arası varsayılan bir mTLS ağı kurun. Bu sayede kod değişikliği yapmadan veri sızıntılarını (packet sniffing) engellemiş olursunuz. İkinci adımda, dışarıdan gelen ve kullanıcı bağlamı taşıyan JWT’leri proxy katmanında doğrulayarak, güvenli bir şekilde backend servislerinize indirin.