Spring Boot Güvenlik Sertleştirme: Kurumsal Rehber

Spring Boot güvenlik sertleştirme nedir, neden şimdi?

Güvenlik sertleştirme (security hardening), bir Spring Boot uygulamasının saldırı yüzeyini yapılandırma, kimlik doğrulama, HTTP katmanı ve bağımlılık yönetimi düzeyinde sistematik olarak daraltma sürecidir. Çerçevenin varsayılanları iyi bir başlangıçtır; ancak kurumsal üretim ortamında yeterli değildir, çünkü gerçek ihlallerin büyük bölümü çerçeve açıklarından değil, yanlış yapılandırmadan ve güncellenmeyen bağımlılıklardan doğar.

Riski soyut olmaktan çıkaran üç gerçek olay

Log4Shell (CVE-2021-44228, CVSS 10.0): Aralık 2021'de açıklanan bu zafiyet, Log4j 2 kütüphanesinin JNDI lookup özelliği üzerinden tek bir loglanan girdiyle uzaktan kod çalıştırmaya (RCE) izin veriyordu. Milyonlarca Java uygulaması, kendi kodlarında tek satır hata olmadan savunmasız kaldı.

Spring4Shell (CVE-2022-22965): Mart 2022'de Spring Framework'ün data binding mekanizmasında bulunan bu RCE zafiyeti, JDK 9+ üzerinde ve belirli dağıtım koşullarında (WAR olarak Tomcat'e dağıtım gibi) istismar edilebiliyordu. Ders: çalıştırma ortamı ve dağıtım biçimi de saldırı yüzeyinin parçasıdır.

Text4Shell (CVE-2022-42889): Apache Commons Text kütüphanesinin değişken interpolasyon özelliğindeki bu açık, "zararsız" görünen yardımcı kütüphanelerin bile RCE vektörü olabileceğini gösterdi.

Üç olayın ortak noktası: hiçbiri uygulama geliştiricisinin yazdığı iş mantığından kaynaklanmadı. Sertleştirme bu yüzden yalnızca kod inceleme değil; yapılandırma, bağımlılık ve süreç disiplinidir.

Derinlemesine savunma mimarisi nasıl kurgulanır?

Aşağıdaki şema, bir HTTP isteğinin kurumsal bir Spring Boot uygulamasına ulaşana kadar geçtiği savunma katmanlarını gösterir:

Bu mimaride kritik ilke şudur: WAF bir isteği kaçırsa bile Spring Security yakalamalı; Spring Security aşılsa bile uygulama kodu girdiyi doğrulamalı; kod hata yapsa bile veri katmanında en az yetki ilkesi hasarı sınırlamalıdır.

Actuator: en sık unutulan kapı

Spring Boot Actuator operasyon ekipleri için vazgeçilmezdir; ama yanlış yapılandırıldığında doğrudan bilgi sızıntısı kaynağıdır. Uç nokta bazında risk tablosu:

Uç nokta	Açığa çıkardığı veri	Risk düzeyi	Üretim önerisi
/env	Ortam değişkenleri, yapılandırma değerleri	Kritik	Kapalı veya yetkili erişim
/heapdump	Bellek dökümü — oturum verileri, kimlik bilgileri kalıntıları	Kritik	Kapalı
/threaddump	İş parçacığı durumu, iç sınıf adları	Yüksek	Kapalı veya yetkili erişim
/loggers	Log seviyelerini görüntüleme ve değiştirme	Yüksek	Yetkili erişim
/health, /info	Sağlık durumu, sürüm bilgisi	Düşük	Açık kalabilir (detaylar kısıtlı)

Pratik kural: management.endpoints.web.exposure.include=health,info ile başlayın; operasyonun ihtiyaç duyduğu her ek uç noktayı ayrı bir yönetim portunda ve kimlik doğrulama arkasında açın. health uç noktasının detay seviyesini de management.endpoint.health.show-details=when-authorized ile sınırlayın.

Kimlik doğrulama, CSRF ve parola politikası

CSRF kararını mimariye bağlayın

Oturum çerezine dayanan her uygulamada CSRF koruması açık kalmalıdır; Spring Security bunu synchronizer token deseniyle sağlar. Koruma yalnızca tarayıcı oturumu kullanmayan, tamamen stateless ve token tabanlı API'lerde kapatılabilir. Ara çözüm olarak çerezlerde SameSite=Lax/Strict özniteliği ek bir savunma katmanı oluşturur — ama tek başına CSRF korumasının yerini almaz.

Parola saklamada doğru maliyet

Parolalar için amaç, doğrulamayı kasıtlı olarak yavaşlatmaktır: BCrypt'te iş faktörünü donanımınızda ~250 ms'ye denk gelecek şekilde ayarlayın; yeni projelerde bellek-sert (memory-hard) yapısıyla GPU saldırılarına daha dirençli olan Argon2id'yi değerlendirin. Spring Security'nin DelegatingPasswordEncoder yapısı, mevcut kayıtları bozmadan algoritma geçişine izin verir — eski özetler kullanıcı giriş yaptıkça yenisiyle değiştirilir.

HTTP güvenlik başlıkları: hangi başlık hangi saldırıyı keser?

Başlık	Engellediği saldırı sınıfı	Spring Security varsayılanı
Content-Security-Policy	XSS, izinsiz kaynak yükleme	Yok — manuel tanımlanmalı
Strict-Transport-Security	Protokol düşürme, SSL stripping	HTTPS üzerinde otomatik
X-Content-Type-Options	MIME sniffing	Otomatik (nosniff)
X-Frame-Options / frame-ancestors	Clickjacking	Otomatik (DENY)
Referrer-Policy	URL üzerinden bilgi sızıntısı	Yok — önerilir

En yüksek getiri CSP'dedir ve otomatik gelmez. Content-Security-Policy-Report-Only modunda başlayıp ihlal raporlarını izleyerek kademeli sıkılaştırma, üretimde kırılma riskini ortadan kaldırır.

Tedarik zinciri: SBOM ve otomatik tarama

Log4Shell gecesinde en hızlı aksiyon alan ekipler, hangi servisin hangi kütüphanenin hangi sürümünü kullandığını sorgulayabilenlerdi. Bunun kurumsal karşılığı SBOM'dur (Software Bill of Materials — yazılım malzeme listesi): CycloneDX veya SPDX formatında, her derlemede otomatik üretilir. Üzerine iki otomasyon eklenir: CI hattında OWASP Dependency-Check ile bilinen zafiyet (CVE) taraması ve depo düzeyinde Dependabot/Renovate ile sürüm güncelleme talepleri. Kritik zafiyetler için yama süresi hedefi (ör. 48–72 saat) tanımlayıp bunu bir mühendislik metriği olarak izlemek, süreci "iyi niyetten" ölçülebilir disipline çevirir.

İş etkisi: teknik borç değil, ticari risk

Güvenlik sertleştirme bir maliyet kalemi gibi görünse de karşılığı somuttur. KVKK ve GDPR, kişisel veri ihlallerinde kısa süreli bildirim yükümlülükleri getirir (GDPR'da 72 saat; KVKK uygulamasında Kurul kararıyla benzer bir süre) ve idari para cezaları öngörür. Ödeme verisi işleyen e-ticaret sistemlerinde PCI DSS uyumu zaten sertleştirmenin çoğunu zorunlu kılar. Kurumsal satış süreçlerinde ise güvenlik anketleri ve tedarikçi denetimleri artık standart: sertleştirilmiş altyapıyı belgeleyebilen yazılım tedarikçisi, satış döngüsünü kısaltır. Kısacası bu yatırım yalnızca ihlali önlemez; müşteri güvenini satın alma kararına dönüştürür.

Sık sorulan sorular

CSRF korumasını ne zaman kapatabilirim?

Yalnızca uygulamanız hiçbir uç noktada tarayıcı oturum çerezi kullanmıyorsa — yani kimlik tamamen Authorization başlığındaki token ile taşınıyorsa. Bu karar mimari dokümana yazılmalıdır.

Actuator'ı tamamen kapatmalı mıyım?

Hayır; health ve info operasyonel izleme için değerlidir. Doğru yaklaşım tamamen kapatmak değil, açık uç noktaları bilinçli seçmek ve gerisini ayrı port + kimlik doğrulama arkasına almaktır.

BCrypt mi Argon2 mi?

İkisi de kabul görmüş seçimlerdir. Mevcut sistemlerde BCrypt'i doğru iş faktörüyle kullanmak yeterlidir; yeni projelerde Argon2id, bellek-sert yapısı sayesinde özel donanımla saldırılara karşı ek direnç sağlar.

Sertleştirme performansı olumsuz etkiler mi?

Buradaki önlemlerin çalışma zamanı maliyeti ihmal edilebilir düzeydedir; kasıtlı olarak yavaş olan tek işlem parola doğrulamadır ve o da tasarım gereğidir.

Üretim öncesi kontrol listesi

Actuator: yalnızca health,info açık; detaylar when-authorized
Hata yanıtları: stacktrace ve iç mesajlar kapalı
CSRF: mimariye göre karar verilmiş ve belgelenmiş; çerezlerde SameSite tanımlı
Parola: BCrypt (ayarlı iş faktörü) veya Argon2id; DelegatingPasswordEncoder ile geçiş planı
Başlıklar: CSP (önce Report-Only), HSTS, Referrer-Policy tanımlı
Tedarik zinciri: her derlemede SBOM; CI'da CVE taraması; kritik yama süresi hedefi tanımlı
Loglama: hassas veri maskeleme; log enjeksiyonuna karşı girdi normalizasyonu

SSH Yazılım olarak kurumsal Java/Spring projelerinde güvenlik sertleştirme denetimi ve uygulamasını uçtan uca üstleniyoruz. Mevcut uygulamanızın bu kontrol listesine göre durumunu görmek isterseniz bizimle iletişime geçin.