Bu Konu Neden Önemli?
SSL/TLS inspection, şifreli trafiğin güvenlik kontrollerinden geçirilebilmesi için oturumun kontrollü biçimde açılıp yeniden şifrelenmesini sağlar; performans, sertifika yönetimi ve istisnalar birlikte planlanmalıdır.
Karar Verirken Kontrol Edilecek Noktalar
Firewall kapasitesini SSL inspection açıkken değerlendirin.
Kurumsal CA dağıtımını ve sertifika güven zincirini planlayın.
Hassas kategoriler için istisna politikasını tanımlayın.
Uygulama uyumluluğunu pilot gruplarla test edin.
Mimari ve çalışma modeli
TLS inspection şifreli oturumu bir kontrol noktasında sonlandırıp hedefe ayrı TLS oturumu kurabilir. Uç cihazın inspection sertifikasına güvenmesi, sertifika doğrulaması ve uygulama uyumluluğu birlikte gerekir. Certificate pinning ve karşılıklı TLS bazı uygulamalarda farklı değerlendirme gerektirir. Gizlilik ve veri işleme kapsamı teknik ekip tarafından tek başına varsayılmamalıdır.
- 1İstemci TLS
- 2Inspection ve doğrulama
- 3Ayrı hedef TLS oturumu
- 4Politika ve istisna
Tasarım parametreleri
- Güven zinciri
- İstemciye dağıtılan CA, anahtar koruması ve sertifika üretimi süreçlerini belgeleyin; inceleme yeni bir güven sınırı oluşturur.
- İstisna ve uyumluluk
- Certificate pinning, karşılıklı TLS ve hassas uygulama davranışını ayrı test edin; istisna gerekçesini kaydedin.
- Kimlik ve kapsam
- Kullanıcı, cihaz ve servis kimliklerini ayırın. Politikanın uygulandığı kaynakları ve dışarıda kalan erişim yollarını listeleyin.
- Politika kararı
- İzin, engelleme ve istisna koşullarını açık yazın. Kural sırası, varsayılan davranış ve oturum yenilenmesi sonucu değiştirebilir.
- Kapasite ve gecikme
- Yoğun saatteki gerçek iş yükünü ölçün. Güvenlik kontrolü açıkken yanıt sürelerini ve kuyrukları kontrolsüz temel ölçümle karşılaştırın.
- Kayıt ve müdahale
- Karar kaydının hangi sistemde tutulduğunu belirleyin. Olay kimliği, zaman, kaynak ve politika gerekçesi araştırmayı mümkün kılmalıdır.
Hesap ve uygulama örneği
Örnek pilotta kurumsal web uygulaması, mTLS uygulaması ve istisna gerektiren hassas servis ayrı sınıflansın. Kontrol açıkken handshake, gecikme ve gerçek sertifika zincirini inceleyin. İstisnanın tüm domaine değil gerektiği kadar dar kapsamda olduğunu doğrulayın.
Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Tarayıcı çalışıyor, uygulama çalışmıyor | Uygulama farklı trust store veya pinning kullanıyor olabilir. | İstemci hata kaydı ve sertifika zincirini inceleyin; bütün incelemeyi kapatmak yerine kapsamı daraltın. |
| İzin verilmesi beklenen işlem engelleniyor | Kural kapsamı veya istisna yanlış eşleşiyor olabilir; kontrolü bütünüyle kapatmak nedeni gizler. | Tek bir test kimliği ve kaynakla karar kaydını inceleyin; aynı koşulu pilotta tekrar üretin. |
| Politika değiştiği halde erişim sürüyor | Mevcut oturum, belirteç veya başka bir erişim yolu farklı kontrol süresine sahip olabilir. | Yeni ve mevcut oturumu ayrı test edin; doğrudan erişimin politika noktasını atlamadığını doğrulayın. |
| Alarm var ancak olay araştırılamıyor | Eksik alan, saat farkı veya veri toplama kesintisi ilişkilendirmeyi engelliyor olabilir. | Kaynak kaydıyla merkezi kaydı eşleştirin; olayın baştan sona izlenebildiğini gösterin. |
Kabul ve doğrulama kontrolleri
- Inspection açıkken geçersiz hedef sertifikasının sessizce kabul edilmediğini test edin.
- İzinli ve reddedilmesi gereken akışları aynı test kimliğiyle ayrı doğrulayın.
- Yeni oturum, süresi dolan oturum ve iptal edilen yetkiyi sınayın.
- İstisnalar için sahip, kapsam ve bitiş tarihi kaydedin.
- Yanlış engelleme sırasında dar kapsamlı geri alma adımını uygulayın.
- Log kesintisi ve politika servisinin erişilememesi için davranışı belgeleyin.
İ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.
Gecikme dağılımı
Gecikme, bir işlemin başlangıcı ile yanıtı arasındaki süredir. Ortalama değer, az sayıdaki çok yavaş işlemi gizleyebilir; medyan ile p95/p99 gibi yüzdelikler farklı sorulara cevap verir. Ağ RTT, disk bekleme, işlemci kuyruğu ve uygulama işlemesi toplam süreye katkıda bulunur. Ölçümün istemci tarafında mı sunucuda mı yapıldığını yazın. Gecikme artışının trafik yükselmesine, bakım işine veya kapasite sınırına denk gelip gelmediğini karşılaştırın. Bir eşik seçmeden önce normal yük ve yoğun saat için temel davranışı kaydedin.
Bant genişliği ve gerçek aktarım
Hat kapasitesi ile uygulamanın taşıdığı yararlı veri miktarı farklıdır. Protokol başlıkları, şifreleme, yeniden iletim, küçük dosyalar ve disk beklemeleri net hızı azaltır. Bit ile byte birimini karıştırmayın: 1 Gbit/s teorik olarak 125 MB/s seviyesindedir; bu bir uygulama performans garantisi değildir. Aktarım süresini veri miktarı / ölçülen net hız şeklinde hesaplayın. Ölçümü aynı anda ağ, kaynak okuması ve hedef yazması üzerinden yaparak sınırlayıcı bileşeni bulun. Ortalama hız kadar kısa süreli düşüşleri ve diğer işlerin rekabetini de değerlendirin.
Politikanın yaşam döngüsü
Bir politika yalnız etkinleştirildiği anda değil, kapsamı değiştikçe de yönetilmelidir. Taslak, gözlem, pilot, uygulama ve periyodik inceleme aşamalarını ayırın. Her istisnanın sahibi, gerekçesi, kapsamı ve sona erme tarihi olmalıdır. Test verileri gerçek kullanıcı davranışını temsil etmezse başarılı pilot üretimde yanlış engellemelere dönüşebilir. Önce kimin ve hangi uygulamanın etkilenebileceğini belirleyin; sonra ölçülebilir kabul koşullarıyla devreye alın. Geri alma yolu yalnız düğme konumunu değil, değişikliğin kim tarafından ve hangi koşulda geri alınacağını da tanımlamalıdır.
Birincil teknik dokümantasyon
Bu İçerik Nasıl Hazırlandı?
Doz Teknoloji Teknik Ekibi
İçerik, Doz Teknoloji’nin kurumsal BT hizmet alanlarında kullandığı teknik değerlendirme yaklaşımı temel alınarak hazırlanmıştır.
Teknik kriterler + birincil kaynaklar
Konu; üretici dokümantasyonu, standart kuruluşları ve ilgili resmî teknik kaynaklarla çapraz kontrol edilmiştir.
Karar kalitesini artırmak
Amaç, teknik bir terimi yalnız tanımlamak değil; satın alma, tasarım veya işletim kararı verirken hangi kriterlerin birlikte değerlendirilmesi gerektiğini görünür hale getirmektir.
İlgili Hizmet ve Rehberler
Bu Rehberle İlgili Kurumsal Çözümler
Teknik konuyu uygulamaya dönüştürmek için ilgili hizmet ve çözüm sayfalarına geçebilirsiniz.
Teknik İhtiyacınızı Birlikte Değerlendirelim
Mevcut altyapınızı, kullanıcı sayınızı veya teknik hedefinizi paylaşın; ürün, lisans veya proje kapsamını ihtiyaca göre netleştirelim.
Teknik Talep Oluşturun