İç Hizmetler İçin TLS Sertifikaları: Doğru Yöntemle Güvenliği Sağlayın Windows

İç Hizmetler İçin TLS Sertifikaları: Doğru Yöntemle Güvenliği Sağlayın

İç hizmetlerde TLS sertifikalarını yönetmek zor olabilir. Bu makalede, split-horizon DNS ve WAF ile doğru ve güvenli çözümü adım adım anlatıyoruz.

İç ağlarda çalışan hizmetler için TLS sertifikası yönetimi, birçok ekip için kabusa dönüşebilir. Özellikle VPN arkasındaki uygulamalarda (Grafana gibi), hem güvenlik hem de kullanıcı deneyimi arasında denge kurmak zorlaşır. Bu yazıda, split-horizon DNS, ACME istemcisi ve ters proxy'de WAF kullanarak bu sorunu nasıl çözebileceğinizi gösteriyoruz. Yöntem, hem ölçeklenebilir hem de yönetimi kolay bir yapı sunuyor.

Pek çok ekip, iç hizmetler için .internal gibi özel üst seviye alan adları kullanıyor. Örneğin, grafana.tuxnet.internal gibi bir DNS kaydı oluşturup özel bir IP'ye yönlendiriyor. Ancak bu durumda TLS sertifikası için ya kendinden imzalı sertifika kullanmak ya da her istemciye güven sertifikası yüklemek gerekiyor. Her iki yöntem de pratikte büyük zorluklar çıkarıyor: kendinden imzalı sertifikalar her istemcide ayrı ayrı yapılandırılmalı, aksi halde tarayıcılar güvenlik uyarısı veriyor. Bu da özellikle büyük ekiplerde yönetilemez hale geliyor.

Doğru yöntem ise 'split-horizon DNS' konfigürasyonu. Bu yöntemde, aynı alan adı (örneğin grafana.tuxnet.dev) genel DNS'te herkese açık bir IP'ye, VPN içindeki özel DNS'te ise özel IP'ye çözümleniyor. Böylece, genel IP üzerinden Let's Encrypt gibi herkese açık bir CA'dan sertifika alabiliyoruz. Tabii bu durumda VPN dışından gelen trafiği engelleyecek bir WAF (Web Application Firewall) kurmak şart. Ancak bu, her istemciye sertifika yüklemekten çok daha kolay: tek bir noktada (sunucuda) WAF yapılandırması yeterli.

Uygulamaya geçmeden önce ihtiyacımız olan araçlar: VPN ve DNS çözümleyici özelliği için NetBird, ACME istemcisi olarak acme.sh ve ters proxy/WAF olarak nginx. NetBird'in Custom Zones özelliği sayesinde split-horizon DNS kurulumu oldukça basit. Belirli kullanıcı veya cihaz gruplarına özel DNS bölgeleri atayarak, sunucunun kendisinin genel DNS kullanmasını sağlayabiliriz. Bu, http-01 doğrulaması için önemli: sunucu, sertifika alırken genel IP üzerinden erişilebilir olmalı.

Sertifika almak için acme.sh'in standalone modunu kullanıyoruz: `acme.sh --issue -d grafana.tuxnet.dev --server letsencrypt --standalone`. Bu mod, nginx'in 80. portta dinlemesine gerek kalmadan çalışır; acme.sh, sertifika alırken geçici olarak 80. portu açar. Ardından nginx konfigürasyonunda, VPN arayüzüne bağlanarak yalnızca VPN üzerinden gelen istekleri kabul ediyoruz. Örneğin `listen our-server.netbird.cloud:443 ssl;` ile sadece VPN IP'sinden gelen trafiğe izin veriyoruz. Bu, WAF görevi görüyor ve genel internetten gelen istekleri otomatik olarak reddediyor.

Nasıl Önlem Alınmalı?

Son olarak, sertifika yenileme işlemini otomatikleştirmek için bir cron job oluşturuyoruz. acme.sh'in --cron flag'i ile günlük olarak yenileme kontrolü yapılıyor. Yenilenen sertifikaları nginx'in beklediği yere kopyalayıp nginx'i yeniden yüklemek gerekiyor. Örnek bir cron job, sertifika ve anahtar dosyalarının checksum'ını karşılaştırarak değişiklik varsa kopyalama ve nginx reload işlemini yapıyor. Bu sayede süreç tamamen otomatik hale geliyor.

Sonuç olarak, iç hizmetlerinizde TLS kullanmak zor olmak zorunda değil. Split-horizon DNS ile herkese açık bir CA'dan sertifika alabilir, WAF ile de güvenliği katmanlı hale getirebilirsiniz. Bu yöntem, özellikle birden fazla iç hizmeti olan ve VPN kullanan ekipler için ideal. Deneyin, farkı görün!

Kaynak: tuxnet.dev

Paylaş: