Nginx ile mTLS Tabanlı Servis Kimliği Doğrulama

İç ağda çalışan servislerin birbiriyle sadece ağ segmentine güvenerek konuşması artık yeterli değil. Kubernetes içinde, sanal makinelerde veya hibrit yapılarda aynı segmentte bulunmak; çağrının gerçekten yetkili servisten geldiği anlamına gelmiyor. mTLS, hem trafiği şifreleyip hem de istemci tarafının sertifika ile kimliğini kanıtlamasını sağlayarak bu boşluğu kapatır. Nginx bu modeli küçük ve kontrollü bir başlangıç için oldukça kullanışlıdır.

Ne kuruyoruz?

Amaç, belirli bir iç servisin sadece kurumsal CA tarafından imzalanmış istemci sertifikasına sahip çağrıları kabul etmesi. Basit modelde üç bileşen bulunur:

• Sunucu sertifikası kullanan Nginx
• İstemci sertifikaları üreten bir CA
• Arkada çalışan hedef servis

Nginx istemci sertifikasını doğrular, CN veya SAN alanına göre ek politika uygular ve trafiği arkadaki servise iletir.

Temel Nginx yapılandırması

Örnek blok:

server {
  listen 443 ssl;
  server_name internal-api.example.local;

  ssl_certificate /etc/nginx/tls/server.crt;
  ssl_certificate_key /etc/nginx/tls/server.key;
  ssl_client_certificate /etc/nginx/tls/ca.crt;
  ssl_verify_client on;

  location / {
    proxy_set_header X-Client-DN $ssl_client_s_dn;
    proxy_pass http://backend_service;
  }
}

Bu kurulum istemci sertifikasını zorunlu kılar. Fakat üretim kullanımı için sadece ssl_verify_client on demek yetmez; sertifika yaşam döngüsü ve yetki eşlemesi ayrıca ele alınmalıdır.

Sertifika yaşam döngüsü neden kritik?

mTLS projelerinin büyük kısmı sertifika yenileme sürecinde dağılır. Sağlıklı model için:

1. Kısa ömürlü istemci sertifikaları kullanın
2. Dağıtımı otomatikleştirin
3. İptal veya erişim kaldırma akışını test edin
4. Hangi servis hesabının hangi sertifikayı kullandığını envanterde tutun

Uzun ömürlü istemci sertifikaları, paylaşılan SSH anahtarı probleminin TLS versiyonuna dönüşür.

Uygulamada hangi başlıklar kontrol edilmeli?

Nginx üzerinden mTLS kurarken şu alanlar hızlı değer üretir:

• Sadece belirli CA zincirine güvenmek
• subjectAltName veya distinguished name üzerinden servis eşleme yapmak
• İstemci kimliğini arka servise güvenli başlıklarla iletmek
• Hatalı doğrulamaları ayrı log akışına göndermek

Bu sayede sadece erişim sağlanmaz; aynı zamanda güvenlik görünürlüğü de oluşur.

Loglama ve gözlemlenebilirlik

mTLS hata ayıklaması çoğu zaman zor görünür, çünkü bağlantı TLS katmanında kesilir. Bu yüzden erişim ve hata loglarında en az şu alanlar tutulmalıdır:

• Sertifika doğrulama sonucu
• İstemci DN veya SAN bilgisi
• Hedef upstream
• TLS sürümü ve cipher

Bu kayıtlar güvenlik ekibi için kimlik doğrulama izi, platform ekibi için ise bağlantı sorunlarını çözme aracı olur.

Nerede iyi başlangıç sağlar?

Nginx tabanlı mTLS özellikle şu durumlarda kullanışlıdır:

• Monolith ile mikroservis arasında kontrollü geçiş
• ERP çevresi entegrasyon servisleri
• Sanal makinelerde çalışan iç API’ler
• Servis mesh kurmadan önce dar güvenlik ihtiyacı

Daha büyük ölçekte servis mesh veya merkezi kimlik altyapısı tercih edilebilir; fakat Nginx yaklaşımı kontrollü ve anlaşılır başlangıç sunar.

Sonuç

Nginx ile mTLS tabanlı servis kimliği doğrulama, iç ağ güvenliğini segment sınırından servis kimliği seviyesine taşır. Başarılı uygulama için asıl mesele konfigürasyon satırları değil; CA yönetimi, sertifika ömrü, kimlik eşleme ve log görünürlüğünün birlikte düşünülmesidir. Bu model doğru kurulduğunda, iç servis trafiği çok daha net ve savunulabilir hale gelir.