İçeriğe geç
Siber Kale by Labris Networks

Çözümleme · Web filtreleme

Şifreli Trafik ve Denetim İkilemi

Labris Networks Mühendislik Ekibi · Son güncelleme 11 Ağustos 2026 · 12 dk

Bu sayfa 14 Ağustos 2026 tarihinde uzman görüşünden geçirildi.

Kısa cevap

Kurumsal trafiğin çoğunluğu artık şifreli. Bu, içerik denetimi yapan her cihazı iki seçenek arasına sıkıştırıyor: trafiği açıp çalışanın banka oturumunun içinden geçeni gören taraf olmak, ya da açmayıp yalnızca bağlantının dış zarfını görmek. Üçüncü bir yol yok.

Bir zamanlar kurumsal ağda içerik denetimi bir tercih meselesiydi. Trafiğin büyük bölümü açıktı. O dönem kapandı. Kurumsal trafiğin ezici çoğunluğu bugün şifreli ve şifreleme bir özellik olmaktan çıkıp varsayılan hâline geldi. Bu kendi başına iyi bir gelişme. Çünkü kullanıcıyı “ortadaki adam” (MitM: Man in the Middle) saldırılarından korumak için tasarlanmış bir mekanizma nihayet her yerde çalışıyor.

Sorun şu ki “ortadaki adam” kümesine kurumun kendi güvenlik cihazı da dahil.

İkilemin Kesin Şekli

Şifreli bir oturumun içine bakmanın tek bir yolu var: bağlantıyı ikiye bölmek. Cihaz istemciyle kendi arasında bir TLS oturumu kurar, sunucuyla kendi arasında ikinci bir oturum kurar, ortadaki açık metni görür. İstemcinin bunu kabul etmesi için cihazın sunduğu sertifikayı tanıması gerekir. Bu yüzden kuruma ait bir kök sertifika, bütün uç noktaların güven deposuna kurulur.

Bu işlemin adı kibarlaştırılabilir ama tarifi değişmez. Yapılan şey, araya girmeye çalışan bir saldırganın yapmaya çalıştığı şeyin aynısıdır. Farkı yaratan, anahtarın kimde olduğu ve o kişinin onunla ne yaptığıdır.

Arada bir yerde durmak isteyenler için ise kötü haber var. Eskiden pasif bir dinleyici en azından sunucu sertifikasını görebiliyor, oradan hedef hakkında bir fikir edinebiliyordu. TLS’in güncel sürümünde sertifika da şifreli akıyor. Yani “açmadan biraz daha fazlasını görme” alanı genişlemiyor, daralıyor. İstemcinin “merhaba”sını da şifreleyen uzantı yaygınlaştığında dış zarftan okunan sunucu adı da kaybolacak.

“Hepsini Açalım” Tarafının Gerçek Maliyeti

Bu tarafın en güçlü savunması operasyoneldir. Kuruma bugün giren zararlı yazılımın önemli bir kısmı şifreli kanaldan geliyor. Şifreyi açmayan bir cihaz, dosya taramasından veri sızıntısı denetimine kadar sahip olduğu yeteneklerin çoğunu hiç kullanamıyor. Lisansı ödenmiş modüller, göremedikleri trafiğin üstünde boşta çalışıyor.

Maliyet tarafı da o kadar ciddi. Birincisi, kurum kendi eliyle tekil bir hata noktası (single point of failure) üretir. O kök sertifikanın özel anahtarı kurumdaki en değerli anahtardır: eline geçiren biri, kurumun bütün uç noktaları için istediği alan adına ait geçerli görünen sertifika üretebilir. Bu anahtar nerede duruyor, kim erişebiliyor, yedeği nerede? Çoğu kurumda hiç sorulmamış sorular.

İkincisi, cihazın TLS’i kullanıcının tarayıcısının TLS’inden iyi olmak zorundadır, çünkü dış bacağı artık o kuruyor. Uygulamada çoğu zaman öyle değildir. Sertifika zinciri doğrulaması, iptal kontrolü, şifre paketi seçimi tarayıcının yıllarca olgunlaştırdığı ve cihazın sıfırdan yeniden yapmak zorunda kaldığı işlerdir. Cihaz zayıf doğrulama yapıyorsa kullanıcı kilidi görmeye devam eder, ama kilidin arkasında kimse yoktur. Denetim ürünlerinin bu işi ne kadar kötü yapabildiği ölçülmüş bir konudur ve aşağıdaki kaynaklarda duruyor.

Üçüncüsü, tarayıcının kullanıcıyı koruyan bazı mekanizmaları, kuruma ait bir kök devreye girdiği anda sessizce devre dışı kalır. Herkese açık sertifikalar için zorunlu tutulan şeffaflık kaydı denetimi, işletim sistemine kurum tarafından eklenmiş köklere uygulanmaz. Arayüz aynı görünür, ama arkadaki kontrol listesi kısalmıştır.

Dördüncüsü ve en az konuşulanı ise kurumun hiç istemediği verinin sorumluluğunu üstlenmesi gerekliliğidir. Çalışanın öğle arasında girdiği bankacılık oturumu da, sağlık portalı da, kişisel postası da bir cihazın belleğinden geçer. Log satırına ne yazıldığı, o logun nereye aktığı, kayıt sisteminde ne kadar durduğu ve kimin okuyabildiği artık teknik değil hukuki bir sorudur. “Kurumun ağı, kurumun hakkı” cümlesi bir izin verir ama veriyi koruma planı vermez. İzinle plan aynı şey değildir. Kişisel veriyi görmek ve kaydetmek kuruma yükümlülük yükler.

Şifreli Trafiği Açmanın İşletme Tarafı

Şifre açan bir cihazın darboğazı bant genişliği değil, oturum kurma hızıdır. Her yeni bağlantı için asimetrik kripto işi yapılır ve bu işin maliyetini belirleyen şey, aktarılan bayt sayısı yerine saniyede kurulan oturum sayısıdır. Kapasite planlamasındaki en yaygın hata buradan doğar. Cihaz, çıktı (throughput) rakamına bakılarak seçilir, ama onu dize getiren şey sabah dokuzda aynı anda açılan yüzlerce tarayıcı sekmesidir. Grafikte bant genişliği rahat görünürken kullanıcı “internet yavaş” der ve iki gözlemi kimse birbirine bağlayamaz. Halbuki sorun oturum kurma ve asimetrik kripto hızıdır.

İkinci işletme yükü listelerdir. Denetim açıldığı gün bir trafiği açılacaklar istisna listesi doğar ve o liste yalnızca büyür. Her arıza kaydı listeye bir satır ekler, hiçbir arıza kaydı satır silmez. İki yıl sonra listeye bakan kimse satırların neden orada olduğunu bilmez. Bir kısmı çoktan gereksizdir, bir kısmı da denetimin asıl gerekçesini boşa çıkaran yerlerdedir. İstisna listesinin bir sahibi ve gözden geçirme takvimi yoksa, denetim politikasını yardım masası yazıyor demektir.

“Hiçbirini Açmayalım” Tarafının Gerçek Maliyeti

Bu tarafın savunması da güçlü. Uçtan uca şifrelemenin değeri istisnasız olmasından gelir. Bir kere “meşru araya girme” diye bir kategori açıldığında, o kategorinin sınırını kimin çizeceği tartışması bitmez.

Açmayan bir kurumun elinde kalanlar da sanıldığı kadar az değil. Hedef adres, bağlantı kurulurken açıkta giden sunucu adı, akışın boyutu, süresi ve zamanlaması, DNS sorguları. Alan adı seviyesinde kategori filtrelemesi bunlarla çalışır. Politikaya aykırı bir hizmeti, bilinen bir zararlı yazılım altyapısını, kumar sitesini bu bilgiyle engellersiniz. Pek çok kurumun ihtiyacının büyük kısmı zaten burada bitiyor.

Kaybedilen şey nokta atışı. Bir bulut depolama hizmetine tümden izin verir ya da tümden yasaklarsınız. Kurumun kendi hesabıyla çalışanın kişisel hesabını ayıramazsınız. Web postada ekin ne olduğunu bilemezsiniz. Büyük bir yüklemenin yapıldığını görürsünüz, içinde ne gittiğini göremezsiniz. Komuta kanalını meşru bir barındırma sağlayıcısının üstüne kurmuş bir zararlı yazılım (malware) ise, dış zarf açısından o sağlayıcıya giden herhangi bir istekten ayırt edilemez.

Üstelik dış zarfın kendisi de sabit durmaz. Uç noktalar DNS sorgularını şifreli kanaldan taşımaya başladığında, şifreli trafiği açmamayı tercih eden bir kurumun en ucuz görü kaynağı elinden gider. Kurumlar buna genellikle uç noktayı kendi çözümleyicisine zorlatarak cevap verirler. Şifreli trafiği açmayan tarafın elindeki bilgi kümesi her yıl biraz daha küçülüyor. Bu tarafı seçen kurum, bugünkü görünürlüğünün kalıcı olduğunu varsayamaz.

Bunun pratik karşılığı şudur: “göremediğimi engellerim” politikası. Bu politika tutarlıdır ama uygulanamaz. Uygulanmaya kalkışıldığında engellenen şey işin kendisi olur.

Bir şey daha eklemek gerek, çünkü tartışmacıların çoğu bunu atlıyor. Hiç açmama kararı çoğu zaman bir yer değiştirme kararıdır. Ağda bakmayan kurum aynı içeriği uç noktadaki ajanla görür, üstelik daha fazlasını, çünkü orada trafik zaten açıktır. Tartışmayı “bakmak mı, bakmamak mı” diye kurmak yanlış. Doğru soru bakmanın hangi noktada, hangi kapsamda ve kimin denetiminde yapıldığı.

Pinning

“Hepsini açacağız” cümlesi teknik olarak zaten mümkün değil. Kendi güven çıpasını (trust anchor) kendi içinde taşıyan uygulamalar, işletim sistemine kurulmuş kurum kökünü tanımaz. Mobil bankacılık uygulamaları, pek çok kurumsal ajan, yazılım güncelleme mekanizmaları, bazı masaüstü uygulamaları böyle çalışır. Araya giren bir cihaz gördüklerinde uyarı vermez ama bağlantıyı hiç kurmazlar.

Bu bir arıza gibi görünür. Kullanıcı uygulamayı açar, “bağlantı kurulamadı” yazısını görür, tekrar dener, olmaz. Yardım masasına düşen kayıtta güvenlik duvarından söz edilmez, çünkü kullanıcı bir engelleme sayfası görmemiştir. Ağ ekibi haftalarca “bizden kaynaklanmıyor” der. Bunun daha kötü bir varyantı var. Uygulama sessizce daha eski bir yola düşer ya da bir özelliğini kapatır, kimse fark etmez.

QUIC de aynı duvarın başka bir yüzüdür. Denetim cihazlarının çoğu UDP üzerindeki bu trafiği açamadığı için kurumlar pratikte onu engelleyip istemciyi TCP’ye düşürüyor. İşe yarıyor, ama ne yapıldığını doğru adlandırmak gerek. Denetimi sürdürebilmek için istemci daha eski bir yola zorlanıyor.

Pinning’in asıl değeri burada. Kurum, denetim dışı bırakılmış bir istisna listesi tutmak zorunda olduğunu teknoloji dayattığı için öğrenir. Liste bir kere varsa tartışma “istisna olsun mu” olmaktan çıkar, “istisnanın ölçütü ne” olur. Bu çok daha verimli bir tartışmadır.

İncelenecek Trafik Ayrımı Nerededir?

Ölçüt kullanıcı değil, hedefin işle ilişkisi olmalı.

Kişiye ait olan yerler (bankacılık, sağlık, kişisel posta, kamu hizmeti portalları) denetim dışı bırakılmalıdır. Gerekçe bir nezaket kuralı olmaktan çok mantıktır. Oradan elde edilecek güvenlik faydası yok denecek kadar az, üstlenilen sorumluluk ise yönetilemeyecek kadar büyüktür.

Denetimin bedelini ödediği yerler ise şunlardır: sınıflandırılmamış siteler, dosya paylaşım hizmetleri, web posta, yeni kaydedilmiş alan adları. Dosyalar kuruma gerçekten buralardan giriyor ve çıkıyor.

Bir de kapsam kararı var, ki genellikle hiç verilmez. Sunucu ağından çıkan trafikle kullanıcı ağından çıkan trafik aynı politikayı hak etmez. Misafir ağı ile personel ağı da öyle. Bu nedenle trafiği incelenen nesne/kişinin ne olduğu da inceleme seviyesini belirlemede önemlidir.

Söylenmemiş Politika En Kötüsüdür

İnceleme ve denetim yapan kurum bunu çalışanına söylemek zorundadır. Gerekçesi ahlaki olduğu kadar da işlevseldir.

Kaynaklar

  1. The Security Impact of HTTPS Interception (NDSS 2017)zakird.com
  2. US-CERT TA17-075A — HTTPS Interception Weakens TLS Securityus-cert.cisa.gov
  3. RFC 9846 — The Transport Layer Security (TLS) Protocol Version 1.3rfc-editor.org