Karşılıklı TLS (mTLS) Uygulama Kalıpları

Standart TLS, bir sertifika aracılığıyla istemcinin sunucuyu doğrulamasını sağlar. Karşılıklı TLS (mTLS) bunu genişletir: her iki taraf da sertifika sunar ve doğrular. Sunucu bunu istediğinde istemci, TLS el sıkışması sırasında CertificateRequest aracılığıyla bir istemci sertifikası sunar. Sunucu, istemci sertifikasını güvenilir bir CA'ya göre doğrular. mTLS, sıfır güvenli ağ iletişiminin temelidir: hizmetler, ağ çevresi güvenliğine güvenmek yerine her bağlantıda birbirlerinin kimliğini kriptografik olarak doğrular. Istio, Linkerd ve Consul Connect gibi hizmet ağları, mikro hizmetler arasındaki mTLS'yi şeffaf biçimde uygular.

mTLS el sıkışması, TLS 1.3'ü şu şekilde genişletir: ServerHello ile sunucu sertifikası ve tamamlama iletisinden sonra sunucu, kabul edilebilir sertifika yetkililerini ve imza algoritmalarını belirten bir CertificateRequest iletisi gönderir. İstemci, Sertifika iletisiyle (istemci sertifika zinciri) ve istemcinin özel anahtarını kullanarak ileti dökümü üzerinde oluşturulan bir imza olan CertificateVerify ile yanıt verir. Sunucu, istemci sertifika zincirini güvenilir CA deposuna göre doğrular ve CertificateVerify imzasını geçerli kılar. Her iki doğrulama da başarılı olursa bağlantı karşılıklı olarak doğrulanmış olur. İstemci, sertifikaya karşılık gelen özel anahtar olmadan bir CertificateVerify oluşturamaz.

Hizmet ağı ortamlarında istemci sertifikaları genellikle kurum içi bir CA tarafından verilir. Istio, SPIFFE (Herkes için Güvenli Üretim Kimliği Çerçevesi) SVID'lerini kullanır: her iş yükü, spiffe://cluster.local/ns/default/sa/payment-service gibi bir SPIFFE URI SAN'ına (Konu Alternatif Adı) sahip bir sertifika alır. Bunlar kısa ömürlüdür (24 saat) ve ağın denetim düzlemi (istiod) tarafından otomatik olarak yenilenir. Kullanıcıya yönelik mTLS'de (örneğin kurumsal VPN veya API istemcilerinde) sertifikalar, daha uzun geçerlilik süreleriyle kurumsal bir CA tarafından verilebilir ve çalışanların cihazlarına MDM (Mobil Cihaz Yönetimi) aracılığıyla gönderilebilir.

Sunucu tarafında mTLS doğrulaması birkaç adımdan oluşur: (1) Zincir doğrulaması — istemci sertifikasının, sunucunun istemci CA deposundaki güvenilir bir kök CA'ya kadar uzandığı doğrulanır. (2) Geçerlilik süresi denetimi — sertifikanın süresinin dolmadığından ve henüz geçerli olmaması gereken bir zamana ait olmadığından emin olunur. (3) İptal denetimi — sertifikanın iptal edilmediği OCSP veya CRL aracılığıyla doğrulanır. (4) SAN/CN eşleştirmesi — kimlik bilgisi, sertifikanın SAN alanından (SPIFFE URI'si, DNS adı veya e-posta) çıkarılır. (5) Yetkilendirme — doğrulanmış kimliğin istenen kaynağa erişmeye yetkili olup olmadığı denetlenir. 4. ve 5. adımlar, temel TLS yapılandırmasının ötesinde uygulama düzeyinde mantık gerektirir.

Kısa ömürlü sertifikalar, açıkça iptal işlemi yapılması gereğini ortadan kaldırır: bir sertifikanın süresi 24 saat içinde doluyorsa ele geçirilmenin etkisi sınırlı bir zaman aralığında kalır. Yenileme şunları gerektirir: (1) Önceden yenileme — eski sertifikanın süresi dolmadan önce yeni bir sertifika verilir (ömrün %80'inde yenileyin). (2) Kesintisiz değiştirme — geçiş süresi boyunca hizmet hem eski hem de yeni sertifikaları kabul etmelidir. (3) Kesintisiz yeniden yükleme — TLS yığını, mevcut bağlantıları kesmeden kimlik bilgilerini yeniden yüklemelidir (nginx: nginx -s reload; Envoy: dinamik xDS sertifika güncellemesi). SPIFFE Workload API'si (SPIRE tarafından uygulanır), sertifika teslimini ve yenilemesini Unix etki alanı soketi API'si aracılığıyla otomatikleştirir.

Istio, her pod'a enjekte edilen Envoy yan araç vekilleri aracılığıyla mTLS'yi şeffaf biçimde uygular. Denetim düzlemi (istiod), servis ağı kök CA'sı tarafından imzalanmış bir ara sertifika kullanarak CA görevi görür. Her pod'un yan aracı, SDS (Gizli Bilgi Keşfi Hizmeti) API'si aracılığıyla bir SPIFFE SVID alır. PeerAuthentication ilkeleri mTLS kipini yapılandırır: STRICT (mTLS zorunlu), PERMISSIVE (geçiş için hem mTLS hem de düz metin kabul edilir) veya DISABLE. AuthorizationPolicy kaynakları, hangi hizmetlerin iletişim kurabileceğini tanımlar; bu iletişim istemci sertifikasındaki SPIFFE kimliğine göre denetlenir. Böylece uygulama kodunda değişiklik yapmadan küme içinde sıfır güven yaklaşımı uygulanır.

Harici API istemcileri için mTLS, API anahtarlarından veya OAuth belirteçlerinden daha güçlü kimlik doğrulaması sağlar. İstemci, özel anahtarı güvenli bir depolamada (HSM, OS anahtar deposu veya parolayla korunan yazılım anahtarı) tutar. İstemci sertifikası, API uç noktasının beklenen CA'sına sabitlenir. Her API isteğinin kimliği TLS katmanında doğrulanır; ayrı bir yetkilendirme üst bilgisi gerekmez. Cloudflare API Shield, AWS API Gateway istemci sertifikaları ve Google Cloud hizmet hesabı mTLS'si bu modelin uygulamalarıdır. Ele geçirilmiş bir API anahtarı her yerden kullanılabilir; ele geçirilmiş bir mTLS özel anahtarının kullanılabilmesi için istemciyi çalıştıran cihazın da çalınması gerekir.

mTLS dağıtımları çeşitli işletimsel zorluklarla karşılaşır. (1) Sertifika dağıtımı — özellikle pod'ların dinamik ortamlarda çoğalıp azalabildiği durumlarda, istemci sertifikalarının tüm hizmetlere güvenli biçimde ulaştırılması. (2) CA'nın ele geçirilmesi — dahili CA yüksek değerli bir hedeftir; ele geçirilirse tüm hizmet sertifikaları geçersiz kılınır. HSM destekli CA'lar ve çevrimdışı kök CA'lar bu riski azaltır. (3) Hata ayıklama — şifrelenmiş mTLS trafiği standart hata ayıklama araçları tarafından görülemez; servis ağı gözlemlenebilirliği için Jaeger ve Kiali gerekir. (4) Ara cihaz uyumluluğu — TLS inceleme vekilleri, istemci sertifikalarını iletecek şekilde açıkça yapılandırılmadıkça mTLS'yi bozar. (5) Sertifika süresinin dolmasından kaynaklanan olaylar — yenileme işleminin başarısız olması, tüm hizmetin kullanılamaz duruma gelmesine yol açabilir.

SPIFFE (Herkes İçin Güvenli Üretim Kimliği Çerçevesi), X.509 SVID'lerini kullanarak iş yükü kimliği için bir standart tanımlar. SPIRE (SPIFFE Çalışma Ortamı), bu standardın referans uygulamasıdır. SPIRE Server, kayıt yetkilisi ve CA görevi görür. SPIRE Agent'ları her düğümde çalışır; düğüm doğrulayıcılarını (AWS örnek kimliği, Kubernetes hizmet hesabı JWT'si, TPM) ve iş yükü doğrulayıcılarını (Unix PID'si, kapsayıcı çalışma zamanı üst verileri) kullanarak iş yükü kimliğini kanıtlar. Workload API, SVID'leri basit bir gRPC API'si kullanarak Unix etki alanı soketi üzerinden iş yüklerine ulaştırır. SPIRE, bir sertifika kaynağı olarak Envoy, Nginx ve başlıca servis ağlarıyla bütünleşir.

Yüksek güvenlikli mTLS dağıtımlarında özel anahtarlar yazılım anahtarı depoları yerine Donanım Güvenlik Modüllerinde (HSM'lerde) tutulmalıdır. TLS kitaplığı (OpenSSL, BoringSSL), özel anahtarı PKCS#11 arayüzü aracılığıyla yükler; bu arayüz imzalama işlemlerini HSM'ye yönlendirir. Özel anahtar, HSM sınırlarının dışına hiçbir zaman düz metin olarak çıkmaz. Bulut HSM seçenekleri arasında AWS CloudHSM, Azure Dedicated HSM ve Google Cloud HSM bulunur. Cihaz düzeyinde mTLS için (IoT, kurumsal dizüstü bilgisayarlar) TPM 2.0 benzer bir işlev sağlar: TLS istemci anahtarı TPM'ye bağlanır ve imzalama işlemi TPM yetkilendirmesi gerektirir; bu da anahtarın ele geçirilmiş bir cihazdan çıkarılmasını son derece zorlaştırır.

mTLS sınaması, istemci sertifikası sunumunu destekleyen araçları gerektirir. OpenSSL s_client: openssl s_client -connect host:443 -cert client.pem -key client.key -CAfile server-ca.pem. curl: curl --cert client.pem --key client.key --cacert server-ca.pem https://host. Servis ağı sınaması için istioctl proxy-config secret pod/name komutu geçerli sertifikayı ve sertifikanın sona erme zamanını gösterir. Bir pod'a kubectl exec ile girip yan aracının yönetici uç noktasına (localhost:15000) curl uygulayarak etkin dinleyicileri ve bunların mTLS yapılandırmasını inceleyebilirsiniz. Otomatik sertifika yenileme sınaması, sertifika yenileme olayları boyunca bağlantıların kararlı kaldığını doğrulamalıdır.

Standart TLS'ye kıyasla mTLS hangi ek adımı ekler?

mTLS, TLS'ye istemci sertifikası kimlik doğrulamasını ekler; her iki taraf da birbirinin sertifikalarını doğrular. SPIFFE SVID'leri, sertifikaların konu alternatifi adı (SAN) alanlarındaki SPIFFE URI'leri aracılığıyla standartlaştırılmış iş yükü kimliği sağlar. Istio, STRICT/PERMISSIVE kipleriyle Envoy yan araçları üzerinden mTLS'yi şeffaf biçimde uygular. Kısa ömürlü sertifikalar (24 saat), iptal gereksinimini ortadan kaldırır ve ele geçirilme sürelerini sınırlar. SPIRE, Workload API aracılığıyla sertifika yayımlama ve yenileme işlemlerini otomatikleştirir. Yüksek güvenlikli dağıtımlarda mTLS özel anahtarları HSM'lerde veya TPM'lerde tutulmalıdır. İşletimsel zorluklar arasında CA anahtarının korunması, ara cihaz uyumluluğu ve kesinti olmadan yenileme bulunur.