Yönetim API’leri çoğu kurumda ürün trafiği kadar görünür değildir; ama etkileri çok daha büyüktür. Bir config reload uç noktası, operasyon paneli veya iç yönetim servisi yanlış korunursa, küçük bir açıklık tüm platformu etkileyebilir. Bu yüzden yalnızca IP allowlist veya basic auth ile yetinmek zayıf kalır. İstemci sertifikasıyla çalışan mTLS modeli, özellikle operasyonel arayüzlerde güçlü ve net bir güvenlik sınırı oluşturur.
Bu rehberde Nginx’i ters proxy olarak kullanıp yalnızca geçerli istemci sertifikası taşıyan istekleri yönetim API’sine geçireceğiz.
Ne kuruyoruz?
Senaryo basit:
- İç ağda çalışan bir yönetim API var.
- API doğrudan internete açık olmayacak.
- Önünde Nginx olacak.
- İstek yapan istemciler kurum içi CA’den üretilmiş sertifika taşıyacak.
Bu model özellikle bastion arkasındaki iç araçlar, yönetim dashboard’ları ve platform servislerinin admin uç noktaları için uygundur.
Nginx konfigürasyonu
Temel örnek şöyle olabilir:
server {
listen 443 ssl;
server_name admin-api.internal.example;
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;
ssl_verify_depth 2;
location / {
proxy_pass http://127.0.0.1:9000;
proxy_set_header X-Client-Verify $ssl_client_verify;
proxy_set_header X-Client-DN $ssl_client_s_dn;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header Host $host;
}
}Buradaki kritik satır ssl_verify_client on; ifadesidir. Nginx, istemci sertifikasını CA zincirine göre doğrulamadan trafiği iç servise geçirmez.
Sertifika yaşam döngüsünü düşünmeden mTLS kurmayın
mTLS teknik olarak kolay görünür; ama sürdürülebilir olması için sertifika yaşam döngüsü tasarlanmalıdır. Şu soruların cevabı net olmalı:
- İstemci sertifikası kim için üretiliyor?
- Kaç gün geçerli olacak?
- Kaybolur veya sızarsa nasıl iptal edilecek?
- Ekipten ayrılan kullanıcıların sertifikaları nasıl kapanacak?
Özellikle uzun ömürlü istemci sertifikaları, sistem ilk kurulduğunda güvenli görünse de zamanla görünmez bir erişim mirası bırakır.
Uygulama katmanında ne kontrol edilmeli?
Nginx sertifikayı doğrulasa bile uygulama katmanının gelen bilgiyi körlemesine kabul etmemesi gerekir. En azından şu kontroller değer üretir:
X-Client-VerifygerçektenSUCCESSmi?- Sertifika konusu beklenen ekip veya servis adını içeriyor mu?
- Uç nokta bazlı ek yetki kontrolü gerekiyor mu?
Yani mTLS, kimliği kapıda doğrular; fakat içeride yapılacak işlemin yetkisini yine uygulama karar vermelidir.
Operasyonel sertleştirme önerileri
Bu kurulumun sağlam kalması için şu ek adımlar anlamlıdır:
- Yönetim API’sini yalnızca loopback veya iç arayüzde dinletmek
- Nginx erişim loglarında istemci DN bilgisini kaydetmek
- İptal edilen sertifikalar için CRL veya kısa ömürlü sertifika modeli kullanmak
- Başarısız doğrulama denemelerini alarm sinyaline çevirmek
Böylece mTLS yalnızca erişim kapısı değil, aynı zamanda denetlenebilir bir operasyon kontrolüne dönüşür.
Sonuç
Nginx ile mTLS tabanlı yönetim API koruması, iç servisleri yalnızca “güvenilir ağ” varsayımına bırakmaktan çok daha sağlam bir model sunar. Özellikle platform ve operasyon araçlarında, istemci sertifikasıyla çalışan sade bir doğrulama katmanı hem güvenliği güçlendirir hem de erişim niyetini daha okunabilir kılar. Kritik olan kısım, konfigürasyonu yazmak değil; sertifika yaşam döngüsünü ve uygulama içi yetki kararlarını aynı disiplinle yönetmektir.