Teknik Rehber · Siber Güvenlik
Servisler Arası mTLS: Kimlik, Güven Zinciri ve Yetkilendirme
mTLS, TLS bağlantısında hem sunucunun hem istemcinin sertifika ile doğrulanmasıdır. Servis A sertifikasıyla ödeme servisine bağlanabilir; bu, her ödeme işlemini yapmaya yetkili olduğu…
Teknik gözden geçirme:
Mimari ve çalışma modeli
mTLS, TLS bağlantısında hem sunucunun hem istemcinin sertifika ile doğrulanmasıdır. Servis A sertifikasıyla ödeme servisine bağlanabilir; bu, her ödeme işlemini yapmaya yetkili olduğu anlamına gelmez. Sertifika kimliğini uygulama rolüne bağlayan ayrı bir yetkilendirme kararı gerekir.
TLS bir yük dengeleyicide sonlanıyorsa arka uç doğrudan istemci sertifikasını görmeyebilir. Doğrulanmış kimlik güvenli bir kanal üzerinden aktarılmalı; dışarıdan gelen aynı isimli HTTP başlıkları temizlenmelidir. Aksi halde kimlik başlığı sahteciliği güven sınırını aşabilir.
OAuth istemci doğrulaması ile sertifikaya bağlı erişim belirteci farklı mekanizmalardır. İkincisinde kaynak sunucusu belirteçteki sertifika bağını da doğrular. Sertifika yenilenirken eski ve yeni kimliğin geçiş penceresi, mevcut bağlantılar ve belirteç süreleri birlikte değerlendirilir.
- 1İstemci sertifikası
- 2TLS zincir doğrulama
- 3Servis kimliği ve rol
- 4Uygulama kararı
Tasarım parametreleri
- SAN kimliği
- Servis adını veya URI kimliğini açık eşleştirin; sertifika zincirinin geçerli olması tek başına uygulama erişimi vermez.
- Güven kökü
- İstemci ve sunucu için gerekli CA listesini sınırlayın; tüm kurumsal kökleri otomatik kabul etmeyin.
- Anahtar koruması
- Özel anahtarı imaj içine koymayın. İş yükü kimliği, dosya izinleri ve dağıtım rotasyonu için ayrı sorumlular belirleyin.
- İptal ve yenileme
- Kısa ömür, iptal kontrolü ve acil kesme ayrı ihtiyaçlardır; istemcinin CRL/OCSP davranışını ürün sürümünde test edin.
Hesap ve uygulama örneği
Laboratuvarda orders.example.test sunucusu ve inventory-client adlı istemci kullanın. Önce güvenilen sertifikayla yalnız GET /stock işlemini açın; POST /payment isteği TLS başarılı olsa da uygulama politikasında reddedilsin.
Bir saatlik sertifika yenileme pilotunda bağlantı havuzunu da gözleyin. Yeni sertifika yeni bağlantıda çalışırken eski açık bağlantı hâlâ aktif olabilir. Yetki iptali testini hem yeni hem mevcut oturum için kaydedin.
Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.
openssl s_client -connect orders.example.test:443 -servername orders.example.test -CAfile ca.pem -cert client.pem -key client.key -verify_return_errorHata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| unknown ca | Eksik ara CA veya yanlış güven deposu. | Sunulan zinciri ve istemcinin kullandığı CA dosyasını karşılaştırın. |
| TLS başarılı, HTTP 403 | Kimlik doğrulanmış ama rol eşleşmemiş. | Sertifika SAN değeri ile politika kararını aynı istek kimliğinde eşleştirin. |
| Yenileme sonrası kesinti | Eski kök, önbellek veya bağlantı havuzu. | Yeni süreç ve yeni bağlantıda aynı isteği tekrar edin. |
Kabul ve doğrulama kontrolleri
- Kimlik doğrulama ile uygulama yetkisini ayrı test edin.
- Sertifikasız istemciyi reddedin.
- Yanlış CA ile bağlantıyı sınayın.
- SAN uyuşmazlığını engelleyin.
- Anahtar yenilemede pilot isteği doğrulayın.
- Olay kaydında kimliği ve karar gerekçesini gösterin.
İlgili kavramlar
TLS ve sertifika doğrulaması
TLS iletişimin gizliliğini ve bütünlüğünü sağlar; sertifika doğrulaması karşı taraf kimliğinin kontrolüne yardımcı olur. Sertifika adı, zincir, geçerlilik süresi ve güvenilen kökler birlikte değerlendirilmelidir. Bir bağlantının şifreli olması uygulamanın yetkilendirmesinin doğru olduğu anlamına gelmez. Reverse proxy veya inspection kullanılıyorsa TLS oturumunun hangi noktada sonlandırıldığını çizimde açıkça gösterin. Hata teşhisinde sertifika kontrolünü kapatmak kalıcı çözüm değildir; yanlış hostname, eksik ara sertifika ve cihaz saatini ayrı inceleyin.
Kimlik doğrulama ve oturum
Kimlik doğrulama kullanıcının veya iş yükünün kim olduğunu kanıtlar; yetkilendirme ise bu kimliğin ne yapabileceğini belirler. Başarılı oturum açma, bütün kaynaklara erişim izni anlamına gelmez. Kullanıcı oturumları, servis kimlikleri, API belirteçleri ve cihaz sertifikaları farklı yaşam döngülerine sahiptir. İlk giriş kadar oturum süresi, belirteç yenileme, işten ayrılma, kayıp cihaz ve acil erişim senaryolarını da tasarlayın. Kimlik sağlayıcı erişilemez olduğunda hangi oturumların süreceğini ve hangi yeni erişimlerin engelleneceğini ölçün.
Güven sınırı ve hata alanı
Güven sınırı, aynı erişim kararlarını paylaşan bileşenleri ayırır; hata alanı ise tek bir olayın birlikte etkileyebileceği kaynakları tanımlar. İki VLAN kullanmak, aralarında serbest yönlendirme varsa güçlü bir güven sınırı kurmaz. İki yedek aynı yönetici hesabıyla silinebiliyorsa da farklı klasörlerde bulunmaları ayrı hata alanı sağlamaz. Tasarımda fiziksel yer, kimlik sağlayıcı, yönetim hesabı, ağ yolu ve enerji kaynağını ayrı ayrı değerlendirin. Bir bileşen kaybedildiğinde hangi erişimlerin ve kurtarma seçeneklerinin ayakta kalacağını sınayın.
En az ayrıcalık ve görev ayrımı
En az ayrıcalık, bir görevin gerektirdiği izinlerin belirli kaynak ve süreyle sınırlandırılmasıdır. Herkese aynı yönetici rolünü vermek, erişim incelemesini ve olay araştırmasını zorlaştırır. Günlük kullanıcı hesabı ile ayrıcalıklı hesabı ayırın; servis hesaplarının etkileşimli kullanımını ve gereksiz ağ erişimini kısıtlayın. Yetki matrisi, kimliğin kaynağa hangi işlemle eriştiğini göstermelidir. Bir izin kaldırıldığında uygulamanın çalışmayı sürdürmesi de test kapsamına girer: gereksiz yetkiler bazen yalnız kontrollü azaltma sırasında ortaya çıkar.
Sürüm ve destek yaşam döngüsü
Bir ürünün kurulabilir olması üretim için desteklendiğini kanıtlamaz. İşletim sistemi, uygulama, sürücü, eklenti ve yönetim aracının uyumluluk zincirini birlikte kontrol edin. Güncelleme planında paket sürümü, destek bitişi, yeniden başlatma gereksinimi ve geri alma yöntemi bulunmalıdır. Test ortamı üretimdeki bağımlılıkları temsil etmezse sonuç yanıltıcı olabilir. Değişiklik sonrası yalnız sürüm numarasını değil, hizmet sağlığını ve önceki iş akışlarını doğrulayın. Bir sürümü sabitlemenin gelecekteki güvenlik düzeltmelerini engelleyebileceğini de dikkate alın.
Telemetri ve zaman eşleştirmesi
Telemetri, sistemin ne yaptığını açıklayan log, metrik ve olay kayıtlarının bütünüdür. Log bir olayın ayrıntısını, metrik zaman içindeki davranışı, dağıtık iz ise isteğin bileşenler arasındaki yolunu gösterir. Saat farkları aynı olayı farklı zamanlarda olmuş gibi gösterebilir. Merkezi zaman senkronizasyonu, kaynak kimliği ve tutarlı saat dilimi kullanın. Alarm tasarımında yalnız eşik değil, ne kadar sürdüğü ve kullanıcıya etkisi de değerlendirilmelidir. Kayıtların kesildiği durum ayrıca izlenmeli; log yokluğu, olay yokluğu şeklinde yorumlanmamalıdır.
Birincil teknik dokümantasyon
Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.