Yük dengeleme arkasında SSL nerede sonlandırılmalı?

Yük dengeleme arkasında SSL sonlandırma için performans, güvenlik, sertifika yönetimi ve arka uç sunucu trafiğini dikkate alan pratik karar rehberi.

Reklam Alanı

Yük dengeleme kullanan bir mimaride SSL’in nerede sonlandırılacağı; performans, güvenlik, operasyon kolaylığı ve hata ayıklama süreçlerini doğrudan etkiler. Tek bir doğru her ortam için geçerli değildir. Trafik hacmi, regülasyon gereksinimleri, uygulama mimarisi, sertifika yönetimi ve arka uç sunucu güvenliği birlikte değerlendirilmelidir.

Özellikle kurumsal hosting altyapılarında SSL sonlandırma kararı yalnızca “sertifika nereye kurulacak?” sorusu değildir. Aynı zamanda istemci IP bilgisinin nasıl korunacağı, iç ağda trafiğin şifreli kalıp kalmayacağı, WAF veya IDS gibi güvenlik katmanlarının nerede konumlanacağı ve uygulamanın HTTPS farkındalığının nasıl sağlanacağı da planlanmalıdır.

SSL sonlandırma ne anlama gelir?

SSL sonlandırma, istemci ile sistem arasındaki şifreli HTTPS bağlantısının belirli bir noktada çözülmesi anlamına gelir. Bu nokta çoğunlukla yük dengeleyici, ters proxy, uygulama sunucusu veya bulut sağlayıcının yönetilen ağ katmanı olabilir.

Bağlantı yük dengeleyicide sonlandırıldığında istemci ile yük dengeleyici arasındaki trafik HTTPS olur. Yük dengeleyiciden arka uç sunuculara giden trafik ise tercihe göre HTTP veya yeniden HTTPS olabilir. Bu tercih, mimarinin güvenlik seviyesi ve operasyonel beklentileriyle uyumlu olmalıdır.

SSL’i yük dengeleyicide sonlandırmak ne zaman mantıklıdır?

En yaygın yaklaşım SSL’i yük dengeleyicide sonlandırmaktır. Bunun nedeni sertifika yönetimini merkezileştirmesi, arka uç sunucuların işlem yükünü azaltması ve trafik yönlendirme kurallarını daha esnek hale getirmesidir.

  • Merkezi sertifika yönetimi: Sertifika yenileme ve ara sertifika zinciri tek noktadan yönetilir.
  • Daha düşük sunucu yükü: TLS el sıkışma işlemleri arka uçlara dağıtılmaz.
  • Kolay yönlendirme: Host, path veya header bazlı routing daha pratik uygulanır.
  • Gözlemlenebilirlik: HTTP başlıkları, yanıt kodları ve istek süreleri yük dengeleyici tarafında daha net izlenebilir.

Bu model, özellikle çok sayıda uygulama veya mikroservis barındıran yapılarda operasyonel sadelik sağlar. Ancak iç ağın güvenilir kabul edilmesi risklidir. Veri merkezi içinde yatay hareket, yanlış VLAN yapılandırması veya yetkisiz erişim ihtimali varsa arka uç bağlantılarının da şifrelenmesi gerekir.

Uçtan uca SSL ne zaman tercih edilmeli?

Uçtan uca SSL modelinde trafik istemciden yük dengeleyiciye, oradan da arka uç sunuculara kadar şifreli kalır. Bu yaklaşım finans, sağlık, kamu, e-ticaret ödeme adımları veya hassas kişisel veri işleyen sistemlerde daha uygundur.

Bu modelde yük dengeleyici SSL’i sonlandırabilir ve arka uca yeniden HTTPS ile bağlanabilir. Alternatif olarak passthrough yöntemiyle TLS trafiği hiç çözülmeden doğrudan sunucuya aktarılabilir. Passthrough güvenliği artırabilir ancak L7 seviyesinde yönlendirme, WAF incelemesi ve detaylı HTTP gözlemi gibi avantajları sınırlar.

Yeniden şifreleme ile passthrough arasındaki fark

Yeniden şifreleme modelinde yük dengeleyici istemci bağlantısını çözer, kontrolleri yapar ve arka uca yeni bir HTTPS bağlantısı kurar. Bu yapı çoğu kurumsal senaryoda dengeli bir çözümdür.

Passthrough modelinde ise yük dengeleyici trafiği içerik seviyesinde görmez. Bu nedenle SNI tabanlı sınırlı yönlendirme yapılabilir, fakat cookie bazlı oturum yapışkanlığı veya path bazlı dağıtım gibi gelişmiş özellikler kullanılamayabilir.

Karar verirken bakılması gereken teknik kriterler

SSL sonlandırma yerini belirlerken yalnızca performansa odaklanmak eksik karar doğurur. Aşağıdaki kriterler birlikte ele alınmalıdır:

  • Uyumluluk: PCI DSS, KVKK, ISO 27001 veya sektör regülasyonları iç ağda şifreleme isteyebilir.
  • Ağ güvenliği: Arka uç ağı paylaşımlıysa veya çok kiracılı yapıdaysa HTTP ile devam etmek risklidir.
  • Uygulama davranışı: Uygulama HTTPS’i doğru algılamazsa yönlendirme döngüsü, yanlış cookie flag’i veya karma içerik hatası oluşabilir.
  • Performans: TLS yükü modern yük dengeleyicilerde verimli yönetilir; fakat çok yüksek trafikte kapasite planlaması yapılmalıdır.
  • Operasyon: Sertifikaların nerede yenileneceği, kimlerin erişeceği ve hata durumunda nasıl geri alınacağı netleşmelidir.

Uygulamada sık yapılan hatalar

En sık hata, SSL yük dengeleyicide sonlandırıldıktan sonra uygulamanın isteği HTTP sanmasıdır. Bu durumda uygulama güvenli cookie üretmeyebilir veya kullanıcıyı sürekli HTTPS’e yönlendirmeye çalışarak döngü oluşturabilir.

Bu sorunu önlemek için yük dengeleyici tarafında X-Forwarded-Proto, X-Forwarded-For ve gerekiyorsa X-Forwarded-Host başlıkları doğru gönderilmelidir. Uygulama veya framework de bu başlıklara güvenecek şekilde yapılandırılmalıdır. Aksi halde gerçek istemci IP’si kaybolabilir ve log analizi yanıltıcı hale gelir.

Bir diğer hata, arka uç sağlık kontrollerinin yanlış protokolle yapılmasıdır. Backend HTTPS beklerken health check HTTP gönderiliyorsa sunucu sağlıksız görünebilir. Tersi durumda da gereksiz sertifika doğrulama hataları yaşanabilir.

Hangi mimari hangi ihtiyaç için uygun?

Basit web sitesi veya düşük riskli uygulama

SSL’i yük dengeleyicide sonlandırıp arka uca HTTP ile devam etmek yönetimi kolaylaştırır. Ancak bu tercih yalnızca izole, güvenilir ve erişimi sıkı kontrol edilen iç ağlarda düşünülmelidir.

Kurumsal uygulama ve hassas veri

Yük dengeleyicide sonlandırma ve arka uca yeniden HTTPS ile iletme daha güvenli ve esnek bir modeldir. WAF, rate limit ve loglama avantajları korunurken iç trafikte de şifreleme sağlanır.

Sertifika uygulama tarafından yönetiliyorsa

TLS passthrough tercih edilebilir. Fakat bu durumda yük dengeleyicinin katman 7 özelliklerinden feragat edileceği unutulmamalıdır. Çok alan adlı yapılarda SNI desteği ayrıca test edilmelidir.

Pratik öneriler

Yeni bir mimari tasarlanıyorsa çoğu hosting ve kurumsal altyapı için en dengeli yaklaşım, SSL’i yük dengeleyicide sonlandırıp arka uçlara yeniden HTTPS ile bağlanmaktır. Böylece sertifika yönetimi merkezileşir, güvenlik kontrolleri uygulanır ve iç ağ trafiği açık metin kalmaz.

Canlıya almadan önce sertifika zinciri, TLS sürümleri, HSTS politikası, güvenli cookie ayarları, yönlendirme kuralları ve gerçek istemci IP logları test edilmelidir. Ayrıca yük dengeleyici üzerinde modern TLS yapılandırması kullanılmalı; zayıf şifre takımları ve eski protokoller devre dışı bırakılmalıdır. Bu kontroller, ileride yaşanabilecek erişim, güvenlik ve performans problemlerini önemli ölçüde azaltır.

Kategori: Donanım
Yazar: Meka
İçerik: 754 kelime
Okuma Süresi: 6 dakika
Zaman: 3 gün önce
Yayım: 13-07-2026
Güncelleme: 13-07-2026