Cem Kemal Erbaş Network, Siber Güvenlik ve Teknik Rehberler
Bugün kurumsal trafikte TLS oranı %90+ seviyelerine çıktı. Sadece URL kategorisi/metadata ile yetinince; C2, phishing landing, malware download, data exfiltration gibi tehditler şifreli katmanda kaybolabiliyor. Sonuç: SOC “daha az sinyal + daha çok gürültü” ile uğraşıyor.
Ama gerçek şu: SSL/TLS Decryption = her şeyi decrypt et yaklaşımı değil. En iyi pratik; hedefli kapsam, hukuki/etik istisnalar ve kullanıcıya şeffaf iletişim ile “gizliliğe saygılı görünürlük” kurmaktır. Palo Alto’nun decryption best practice rehberi de özellikle finans/sağlık/devlet gibi hassas kategorilerin decryption kapsamı dışında bırakılmasını açıkça vurgular.
🎯 Hedef: Maksimum görünürlük değil, maksimum anlam
- Risk odaklı decrypt: İş kritik uygulamalar + kurumsal cihazlar
- No-Decrypt: Regülasyon / mahremiyet gerektiren kategoriler
- Teknik istisna: Certificate pinning / decryption’ı kıran özel servisler (ayrı yönetilir)
✅ 3 Adımda Güvenli Devreye Alma
1) Kapsamla başla: “Önce dar, sonra büyüt”
Decrypt ✅
- Kurumsal cihazlar (managed endpoints)
- İş uygulamaları: SaaS / DevOps / Collaboration / IT & Admin
- Riskli kategoriler: “newly registered domains”, “unknown”, “malware”, “phishing” (kurum politikasına göre)
No-Decrypt ❌
- BYOD / kişisel cihazlar (özellikle sertifika push edemiyorsanız)
- Finans / sağlık / devlet / mahremiyet kategorileri
- Üst düzey yöneticilerin özel kapsamları (kurum politikasıyla)
Bu ayrımı “No-Decrypt policy rule” ile yapmak, decryption policy rules’in URL category + source/destination ile granular yönetilebilmesine dayanır.
2) Politika & Sertifika: Forward Trust/Untrust + doğru istisna modeli
🔐 Sertifika yaklaşımı (Forward Proxy mantığı)
Forward Trust / Forward Untrust sertifikaları; firewall’ın “araya girip” istemciye sertifika sunabilmesi için kullanılır. Forward Untrust, upstream sertifika güvenilmezse kullanıcıya uyarı gösterecek şekilde tasarlanmıştır.
Dağıtım kanalı
- MDM / GPO / kurumsal sertifika dağıtımı
- (Varsa) enterprise CA ile Forward Trust kullanımı
🧩 No-Decrypt vs Exclusion List: Karıştırmayın
- No-Decrypt (policy/business/legal/privacy): finans/sağlık/devlet gibi “decrypt etmek istemediğiniz” trafik.
- SSL Decryption Exclusion list (technical reasons): certificate pinning gibi “decrypt edince kırılan” trafik.
Bu ayrım, ileride denetimde “neden decrypt etmiyoruz?” sorusunu net yanıtlar: istek/etik mi, teknik zorunluluk mu?
🧠 Bonus: No-Decryption Profile ile “decrypt etmeden de kontrol”
Decrypt etmeyeceğiniz trafikte bile, No-Decryption profile ile sertifika doğrulama (expired/untrusted issuer vb.) kontrolleri uygulayabilirsiniz.
3) İşletim & Şeffaflık: QUIC, hata panoları, süreli istisna disiplini
🚫 QUIC/HTTP3 gerçekliği
QUIC (HTTP/3) bazı ortamlarda inspeksiyonu zorlaştırır; pratikte birçok kurum, inspeksiyon yapılacak kategorilerde QUIC’i engelleyip HTTPS/TCP’ye düşürür veya endpoint policy ile devre dışı bırakır. (Bu konu pratik deneyimlerde de böyle ele alınıyor.)
📊 Operasyon panosu
- Handshake failure / cert error / decrypt failure trendlerini izleyin
- “En çok kırılan uygulamalar” listesi çıkarın → istisna mı, config mi, endpoint mi?
⏳ İstisna disiplinini standardize edin
İstisna açıyorsanız:
- Owner
- Ticket/Change-ID
- Expiry (EXP)
- Gerekçe
mutlaka olsun.
Örnek standart:[OWN=SecOps][TCKT=CHG-456][EXP=2026-12-31][WHY=CertPinning]
🧾 Şeffaf kullanıcı iletişimi
Palo Alto dokümantasyonu, decryption stratejisinde “hariç tutulan hassas trafik” gibi kararların netleştirilmesini vurgular.
Kurumsal tarafta bunun karşılığı:
- Kullanıcıya nerede/niçin decryption yapıldığı (genel çerçeveyle) açıklanır
- Politika metni + kabul/aydınlatma + rol bazlı istisna süreçleri yazılır
✅ Kazanımlar (doğru uygulandığında)
🎯 Şifreli trafik içinde daha fazla tehdit yakalama
📊 Daha anlamlı log/IOC (SOC gürültüsü düşer)
🔒 Daha küçük saldırı yüzeyi (riskli kategori ve uygulamalar daha iyi kontrol edilir)
🧾 Denetlenebilir süreç (kapsam/istisna/owner/expiry net)
Cem Kemal Erbaş sitesinden daha fazla şey keşfedin
Subscribe to get the latest posts sent to your email.
