"Şifreli" kelimesi pazarlama metninde neredeyse hiçbir şey, mühendislik dokümanında ise çok belirli bir şey ifade ediyor. Bir mesajlaşma uygulaması kendini şifreli diye adlandırırken her kelimenizi okuma yeteneğini elinde tutabilir: telefondan sunucuya giden bağlantıyı şifreliyor, sunucudaki diskleri de şifreliyor. İkisi de gerçek önlem, ikisi de çoğu insanın asıl korktuğu tehdide karşı işe yaramıyor. Belirleyici soru şifrelemenin var olup olmadığı değil, düz metnin hangi durakta durduğu ve o durakta anahtarın kimde olduğu.
Bu rehber o soruyu bir karar prosedürüne çeviriyor: bir mesajın geçtiği yedi durağın hangisinde içeriğin okunabilir kaldığı, kanalı güvenli yapan beş özelliğin hangisinin hangi saldırıyı düşürdüğü, güvenlik numarası doğrulamasının nasıl yapıldığı ve numara değiştiğinde ne anlama geldiği, yedeğin ve bağlı cihaz listesinin neden asıl arıza noktası olduğu, grup üyeliğinin kriptografik mi yoksa idari mi uygulandığı, ve işveren tarafında denetimin nerede bittiği. Son bölüm Türkiye'ye özgü: Kişisel Verileri Koruma Kurulu'nun 16 Eylül 2026 tarihli ve 2026/2035 sayılı ilke kararı, kurumsal e-posta ve işin yürütülmesi için kullanılan iletişim kanallarının denetlenmesinde uyulması gereken usulü maddeler hâlinde yazdı ve o metin "kanal bizim, dolayısıyla okuruz" cümlesini kapatıyor.
Şifreli kelimesinin dört vaadi ve düz metin testi
Bir ürün şifreli olduğunu söylediğinde dört çok farklı şeyden biri doğrudur. Birincisi taşıma şifrelemesi: istemci ile sunucu arasındaki trafik TLS üzerinden gidiyor, aynı kablosuz ağdaki biri okuyamıyor. Son on beş yılın neredeyse bütün servislerinde var, güvenlik duruşu olmayanlarda da var, çünkü TLS artık asgari koşul. İkincisi durağan veri şifrelemesi: sağlayıcının diskleri ve yedekleri şifreli, çalınan bir disk ya da yanlış yapılandırılmış bir depolama alanı içeriği açığa çıkarmıyor. İkisi de belirli tehditlere karşı gerçek önlem ve ikisi de sağlayıcının mesajlarınızı okumasını engellemiyor, çünkü çözen uç sağlayıcının sunucusu.
Uzaktan İzleme Teklifleri
Sphnix ile başlayın ve mSpy ile Eyezy'yi karşılaştırın.
Üçüncü vaat uçtan uca şifreleme: anahtarlar yalnızca konuşan cihazlarda var, sunucu açamayacağı şifreli metni iletiyor. Dördüncü ise nadiren açıkça söylenen ama sık sık ima edilen vaat: kanalın güvenli olduğu, yani karşıdaki kişinin arayüzün gösterdiği kişi olduğu, araya kimsenin girmediği, karşı cihazın ele geçirilmediği ve geçmişin bir yerde şifresiz durmadığı. Şifreleme bunların hiçbirini tek başına teslim etmiyor.
| Vaat | Düz metin nerede durur | Anahtar kimde | Hangi saldırıyı düşürür | Neyi düşürmez |
|---|---|---|---|---|
| Taşıma şifrelemesi (TLS) | Sunucuda ve cihazlarda | Sunucu ve istemci | Aynı ağdaki dinleme, yol üstü müdahale | Sağlayıcının okuması, sunucudan sızma, tebligat |
| Durağan veri şifrelemesi | Sunucuda, çalışırken bellekte | Sağlayıcının anahtar yönetimi | Disk hırsızlığı, açık kalan yedek kovası | Sağlayıcının içinden erişim, hesap ele geçirme |
| Uçtan uca şifreleme | Yalnızca iki cihazda | Yalnızca cihazlar | Sağlayıcının okuması, sunucudan sızma, zorunlu teslim | Meta veri, ele geçirilmiş cihaz, kötü niyetli yedek |
| "Kanal güvenli" iddiası | Belirsiz | Doğrulanmamış | Hiçbiri (iddia, önlem değil) | Araya giren, sahte kişi, yedek, ekran görüntüsü |
Aynı mesajı gerçekten geçtiği duraklardan geçirip her durakta tek bir soru sorun: bu baytları benden ve alıcıdan başka okuyabilen var mı? Düzgün kurulmuş bir uçtan uca sistemde aradaki her durağın cevabı hayır. Taşıma ve durağan veri şifrelemesinde sağlayıcı durağının cevabı evet ve o durakta tek bir tebligat, tek bir kötü niyetli çalışan, tek bir yanlış yedek dışa aktarımı bütün geçmişi açar.
Her şifreleme iddiasını kesen dört soru
- Düz metin nerede var? Yalnızca uç cihazlarda mı, yoksa sağlayıcının işlettiği ve açmaya zorlanabileceği bir sunucuda da mı?
- Anahtarı kim tutuyor ve sağlayıcının sakladığı bir şeyden türetilebilir mi? Sunucudaki anahtar yönetim servisiyle sarılmış bir anahtar, fazladan adımı olan sunucu anahtarıdır.
- Sağlayıcı yine ne öğreniyor? Kim kiminle, ne zaman, hangi sıklıkta, hangi ağdan, hangi grupta ve ne kadar süre konuştu. "Asgari" kelimesini değil, gerçek listeyi isteyin.
- Garantinin dışında ne kaldı? Yedekler, grup aramaları, medya dökümü, spam taraması, iş mesajlaşması, botlar, bildirim önizlemeleri ve karşı taraf aynı istemcide değilken devreye giren geri düşme yolu.
Mesajın geçtiği yedi durak
Şifreleme tartışmaları soyut kalıyor çünkü "sunucu" tek bir yer değil. Bir mesajın gerçekte geçtiği durakları yazmak, hangi önlemin neyi kapattığını görünür hâle getiriyor. Aşağıdaki tablo, aynı mesajın yedi durakta kim tarafından okunabildiğini iki mimari için yan yana koyuyor.
| Durak | Kim görür | Uçtan uca şifreli | Yalnızca taşıma + durağan |
|---|---|---|---|
| 1. Gönderen cihaz | Cihazın sahibi, cihaza yerleşmiş yazılım | Okur | Okur |
| 2. Yerel ağ ve internet servis sağlayıcısı | Ağ operatörü, konumdaki dinleyici | Şifreli metin ve üst veri | Şifreli metin (TLS varsa) |
| 3. Sağlayıcının giriş katmanı | Sağlayıcı | Şifreli metin | Düz metin |
| 4. Uygulama sunucusu ve veritabanı | Sağlayıcı, sızma yapan saldırgan, tebligat muhatabı | Şifreli metin | Düz metin |
| 5. Sağlayıcının yedekleri | Sağlayıcı, yedek sağlayıcısı | Uygulamaya bağlı: yedek ayrıca şifrelenmemişse düz metin | Düz metin |
| 6. Bildirim altyapısı (APNs veya FCM) | Apple veya Google | Şifreli yük ve jeton; önizleme açıksa metin | Metin görülebilir |
| 7. Alıcı cihaz | Alıcı, cihaza yerleşmiş yazılım | Okur | Okur |
Tablonun en çok atlanan satırı beşincisi. Bir kanal içerikte uçtan uca şifreleme sunarken yedeği bulut hesabında şifresiz tutuyorsa, o kanalın gerçek güvenlik sınırı bulut hesabının şifresi kadardır; mesajlaşma protokolünün ne kadar iyi olduğu bu satırı değiştirmiyor. Altıncı satır da aynı şekilde: kilit ekranında metni gösteren bir bildirim, şifrelemenin hiç korumak için tasarlanmadığı bir yere düz metin taşımış olur.
Kanalı güvenli yapan beş özellik
Kriptograflar bir mesajlaşma uygulamasını "şifreli mi" diye değerlendirmiyor; protokolün hangi özellikleri sağladığını soruyor, çünkü özellikler hangi saldırıların başarısız olacağını belirliyor. Bir kanal seçerken ya da tedarik şartnamesi yazarken bu beşi yeterli.
| Özellik | Ne demek | Hangi saldırıyı düşürür | Kullanıcı nasıl anlar |
|---|---|---|---|
| Gizlilik | Aradaki hiçbir taraf içeriği okuyamaz | Dinleme, sunucudan sızma | Sağlayıcının şeffaflık raporundaki saklama listesi |
| Bütünlük ve kimlik doğrulama | Her mesaj bir anahtara bağlı; değiştirilemez, taklit edilemez | Araya giren, mesaj değiştirme | Güvenlik numarası veya QR doğrulaması |
| İleriye dönük gizlilik | Uzun ömürlü anahtar ele geçse de geçmiş açılmaz | Sonradan el konulan cihaz, zorla teslim | Cihaz değişiminde eski mesajların taşınmaması |
| Ele geçirme sonrası toparlanma | Oturum anahtarı çalınsa bile protokol okunamaz duruma döner | Anahtar hırsızlığı sonrası kalıcı erişim | Ratchet'in her mesajda ilerlemesi |
| Meta veri asgarisi | Kim kime ne zaman bilgisi de toplanmaz | Trafik analizi, ilişki haritası çıkarma | Saklama listesi ve mühürlü gönderici |
İlk dördü protokolün mekanik özellikleri ve matematikle tartışılabilir. Beşincisi bir politika özelliği ve politikalar kriptografiyi sessizce iptal edebiliyor: içeriği kusursuz şifreleyen ama kimin kimi saat kaçta aradığını kaydeden bir kanal, hijyeni iyi bir gözetim sistemidir. Signal protokolünün çift ratchet yapısı ilk dördünü şöyle teslim ediyor: Diffie-Hellman ratchet'i konuşmanın yönü her değiştiğinde anahtarı ilerletiyor, simetrik ratchet her mesajda ilerletiyor; böylece çalınan bir anahtar arşivi değil tek bir pencereyi açıyor.
Anahtar doğrulama: 60 haneli numara ne işe yarıyor
Uçtan uca şifrelemenin tek başına çözemediği tek şey, karşıdaki genel anahtarın gerçekten o kişiye ait olduğu. Sağlayıcı iki tarafa da kendi ürettiği anahtarları verirse her iki tarafla ayrı ayrı şifreli konuşabilir ve ikisi de arayüzde bir kilit simgesi görür. Bunu kapatan mekanizma, iki cihazın ortak anahtar parmak izlerinden türetilen güvenlik numarası: Signal ve WhatsApp'ta 60 hane, beşerli gruplar hâlinde gösterilir ve iki tarafta aynı çıkmalıdır. Numarayı QR kod ile okutmak aynı işi yapıyor.
Numaranın uzunluğu tesadüf değil. 60 ondalık hane 1060 olası değer demek ve bu 199,3 bitlik bir uzay; bir milyar kullanıcıda oluşan çift sayısı yaklaşık 5 × 1017, yani rastgele iki kullanıcının numarasının çakışma olasılığı 5 × 10-43 mertebesinde. Buna karşılık numaranın yalnızca ilk 8 hanesini karşılaştırmak 108 değer, yani 26,6 bit bırakıyor ve araya girmek isteyen birinin doğru haneleri tutturma şansı 10-8. Kısaltılmış karşılaştırma, kolaylık ile güvenlik arasında 172,7 bitlik bir fark yaratıyor; bu yüzden doğrulamayı ekranda görünen numaranın tamamıyla ya da QR ile yapmak gerekiyor.
Numara değiştiğinde uygulama uyarı gösteriyor ve bu uyarı çoğu zaman panikle karşılanıyor. Değişimin tek bir anlamı yok; nedeni bilinmeden verilecek karar yanlış olur.
| Değişim nedeni | İyi huylu mu | Ne yapılır |
|---|---|---|
| Karşı taraf uygulamayı yeniden kurdu | Evet | Farklı bir kanaldan (yüz yüze veya arama) doğrula, sonra devam |
| Karşı taraf yeni telefon aldı | Evet | Aynı: yeni cihazın numarasını karşılaştır |
| Karşı taraf yedekten geri döndü | Genellikle evet | Doğrula; kritik konuşmada geçmişin taşınmadığını teyit et |
| SIM kart kopyalandı veya numara taşındı | Hayır | Doğrulamayı reddet, operatörle numara geçmişini incele |
| Hesap ele geçirildi, yeni cihaz bağlandı | Hayır | Oturumları kapat, iki adımlı doğrulamayı yenile, olay kaydı aç |
| Doğrulanmamış uzun sessizlik sonrası ilk mesaj | Belirsiz | Aynı gün doğrula; doğrulanana kadar hassas içerik gönderme |
Pratik kural şu: numara değişimi bir saldırı kanıtı değil, bir doğrulama borcu. Borç kapanana kadar o kanaldan sözleşme, kimlik bilgisi, müşteri verisi veya ödeme talimatı geçirmemek gerekiyor. Kurumsal tarafta bu borcu takvime bağlamak şart, çünkü kimse hatırlamıyor: en hassas 12 kişiyle doğrulama, kişi başına 90 saniye ile 18 dakika; 40 kişilik bir ekipte 12 saat. Bu 12 saat, araya giren bir saldırganın bir yıl boyunca okuduğu yazışmanın karşılığı.
Protokoller: aynı soruyu çözen dört farklı mühendislik
"Uçtan uca şifreli" tek bir protokol değil. Aynı güvenlik hedefine ulaşan dört farklı yapı var ve aralarındaki fark, günlük kullanımda hissedilen yerlerde ortaya çıkıyor: grup ne kadar büyük olabiliyor, yeni üye eklendiğinde ne oluyor, cihaz değişince geçmiş taşınıyor mu, ve bir anahtar sızarsa ne kadarı açılıyor.
| Yapı | Nerede kullanılıyor | Grup modeli | İleriye dönük gizlilik | Zayıf noktası |
|---|---|---|---|---|
| X3DH / PQXDH + çift ratchet (Signal protokolü) | Signal, WhatsApp, Google Messages | İkili: her mesajda; grup: Sender Keys | Mesaj başına | Grup anahtarı üye sayısıyla yönetilir, üye listesi idari değişir |
| Sender Keys | WhatsApp grupları | Her üye kendi gönderim zincirini dağıtır | Gönderim zinciri başına | Üye çıkarıldığında anahtar yenilenmeli; yenilenmezse eski üye okumaya devam eder |
| MLS (RFC 9420) | Kurumsal mesajlaşma, kimi toplantı ürünleri | Ratchet ağacı, üye başına logaritmik güncelleme | Devir (epoch) başına | Uygulama desteği az; sunucu yine üye listesini görür |
| PQ3 | iMessage (iOS 17.4 ve sonrası) | İkili ve grup | Mesaj başına, kuantum sonrası anahtarlarla düzenli yeniden tohumlama | Yalnızca Apple cihazları arasında |
| SPQR | Signal (Ekim 2025'te duyurulan seyrek kuantum sonrası ratchet) | İkili | Mesaj başına, kuantum sonrası | Yeni; saha verisi sınırlı |
Grup modeli farkı sayıyla görünür hâle geliyor. Her üyenin her üyeyle ayrı ikili oturum kurduğu bir tasarımda 1.000 kişilik grup 1.000 × 999 / 2 = 499.500 kanal demek; ağaç tabanlı MLS'te bir üyenin anahtarını değiştirmek ağacın yüksekliği kadar, yani logaritma 2 tabanında 1.000 ≈ 10 seviye iş demek. Aradaki fark, grup büyüdükçe kapanmayan bir uçurum: 10.000 kişide ikili tasarım 49.995.000 kanal isterken ağaç 14 seviyede kalıyor. Kurumsal bir kanal seçerken "kaç kişilik gruba kadar gerçekten çalışıyor" sorusu bu yüzden protokol sorusu.
Kuantum sonrası hazırlık 2026 itibarıyla teorik değil. NIST'in Ağustos 2024'te yayımladığı ML-KEM (FIPS 203) anahtar kapsülleme standardı, iki büyük istemcide üretimde: Signal'in PQXDH anlaşması ve iMessage'ın PQ3 katmanı. Kalan soru "protokol kuantuma dayanıklı mı" değil, hangi mesajların bugün toplanıp yarın çözülebileceği.
Kuantum: hasat et, sonra çöz
Bugün kaydedilen şifreli trafik yarın açılabilir; buna hasat et ve sonra çöz deniyor. Riski büyüklük sırası tahminiyle değil, üç süreyi karşılaştırarak hesaplamak gerekiyor: verinin kaç yıl gizli kalması gerektiği (raf ömrü), kuantum sonrası geçişin kaç yıl süreceği (geçiş süresi) ve kriptografik olarak ilgili bir kuantum makinesinin kaç yıl sonra gerçekçi olduğu. Mosca eşitsizliği bunu tek satırda söylüyor: raf ömrü + geçiş süresi, tehdit ufkunu aşıyorsa veri bugün risk altında.
| Veri türü | Raf ömrü | Geçiş süresi | Toplam | Tehdit ufku 12 yıl varsayımıyla |
|---|---|---|---|---|
| Günlük operasyon yazışması | 1 yıl | 2 yıl | 3 yıl | Rahat |
| Müşteri sözleşmesi görüşmeleri | 5 yıl | 3 yıl | 8 yıl | Rahat |
| Sağlık ve özel nitelikli veri | 10 yıl | 3 yıl | 13 yıl | Sınırda: geçişi öne almak gerekir |
| Devlet sırrı niteliğinde veya 25 yıl saklanan kayıt | 25 yıl | 5 yıl | 30 yıl | Bugün risk altında |
Tabloyu kendi verinizle doldurmanın tek yolu tek bir soru: bu yazışma on yıl sonra açığa çıkarsa kime ne olur? Cevap "hiçbir şey" ise geçişi aceleye getirmenin anlamı yok. Cevap "müşteri kaybı, dava, itibar" ise raf ömrü uzun olan veri için kuantum sonrası anahtar anlaşması sunan kanalı seçmek, bugün verilebilecek en ucuz karar; çünkü alternatif, on yıl boyunca kaydedilmiş ve yarın açılacak bir arşiv.
Yedek, çok cihaz ve kurtarma: gerçek arıza burada
Uygulamaların şifreleme mimarisi bir saldırganın okumasını zorlaştırıyor; kullanıcıların çoğunun verisi ise yedekte, yani mimarinin dışında açılıyor. Üç senaryo birbirinden ayrılmadan yedek tartışması yapılamaz: yedek şifreli mi, anahtarı kimde, ve anahtar kaybolduğunda ne oluyor.
| Kanal | Yedek nerede durur | Kim açabilir | Anahtar kaybında |
|---|---|---|---|
| WhatsApp, uçtan uca şifreli yedek açık | Kullanıcının bulut hesabında, şifreli | Yalnızca 64 haneli anahtarı, parolayı veya geçiş anahtarını bilen cihaz | Yedek açılmaz; 64 hane kaybolduysa sohbet geçmişi geri gelmez |
| WhatsApp, yedek şifreleme kapalı | iCloud veya Google Drive yedeğinde | Bulut sağlayıcısı ve hesaba erişen herkes | Hesap şifresiyle açılır: şifreleme protokolü devre dışı |
| Signal | Cihazda veya Signal'in yedek altyapısında, yedek anahtarıyla | Yalnızca yedek anahtarını bilen | Geri yükleme yok; yeni cihaz boş başlar |
| iMessage | iCloud yedeğinin içinde | Gelişmiş Veri Koruması açıksa yalnızca cihazlar; kapalıysa Apple | Gelişmiş Veri Koruması yoksa yedek anahtarı kullanıcıda değil |
| Telegram | Sunucuda, sohbet türüne göre | Bulut sohbetleri hesap şifresiyle; gizli sohbetler yalnızca cihazda | Gizli sohbet cihazla birlikte gider, bulut sohbeti gelir |
İkinci satır bütün mimariyi iptal eden satır ve varsayılan durum olabiliyor. Bir kurum uçtan uca şifreli bir kanal kullanıp yedek şifrelemesini açmadığında, kanalın güvenlik sınırı bulut hesabının şifresi oluyor; üstelik bu, kullanıcıların çoğunun fark etmediği bir arayüz ayarı. Kurumsal politikada yedek şifrelemesi "önerilir" değil, zorunlu madde olmalı ve cihaz kaydı sırasında bir kez denetlenmeli.
Anahtar kaybının bedeli de aynı maddeye bağlı. Uçtan uca şifreli bir yedeğin anahtarını kaybeden kullanıcı için geri dönüş yok; bu bir hata değil, tasarımın kendisi. Kurumun bu gerçeği iki şekilde karşılaması gerekiyor: kritik yazışmaların kanalda değil kayıtlı bir sistemde tutulması, ve yedek anahtarının kurumsal parola kasasında çalışan başına değil, sorumlu rolünde saklanması. Aksi hâlde cihaz kaybı, veri kaybıyla aynı şey olur.
Grup üyeliği ve bağlı cihaz listesi
Şifreleme anahtarları matematikle korunuyor; bir kanala kimin dahil olduğu ise idari bir kararla belirleniyor. Saldırganların en çok kullandığı yol, anahtarı kırmak değil, listeye eklenmek. Bu yüzden iki liste her ay okunmalı: bağlı cihazlar ve grup üyeleri.
| Yüzey | Kim değiştirir | Denetim yolu | Sıklık |
|---|---|---|---|
| Bağlı cihazlar (masaüstü, web, tablet) | Hesap sahibi veya hesabı ele geçiren kişi | Uygulama içindeki bağlı cihazlar listesi; tanınmayanı kaldır | Aylık, ayrıca cihaz değişiminden sonra |
| Grup üye listesi | Grup yöneticisi | Üye listesini dışa aktar, kurumsal dizinle karşılaştır | Aylık, ayrıca işten ayrılma sonrası |
| Numara ve iki adımlı doğrulama | Kullanıcı, operatör | PIN veya uygulama tabanlı doğrulama açık mı | Çeyrekte bir |
| Yedek şifrelemesi | Kullanıcı | Ayar ekranı; anahtar kasada mı | Cihaz kurulumunda ve yılda bir |
İşten ayrılma senaryosu bu listenin en zayıf halkası. Bir çalışan ayrıldığında hesabı kapatmak yetmiyor: o kişi hâlâ üyesi olduğu gruplardaki yazışmayı okumaya devam eder, çünkü grup anahtarı kriptografik olarak yenilenene kadar geçerli. Bu yüzden ayrılış prosedüründe iki adım var: gruptan çıkarma ve kritik gruplarda anahtar yenileme talebi. Sender Keys tabanlı bir grupta çıkarma tek başına yeterli olmayabilir; MLS tabanlı bir grupta üye değişimi anahtarı kriptografik olarak döndürür. Şartnameye yazılması gereken cümle tam olarak bu; ayrılış kontrol listesinin tamamı işe alım ve ayrılış güvenlik kontrolü rehberinde.
Meta veri: şifrelemenin hiç dokunmadığı kısım
İçerik şifrelenirken zarfın üstündeki yazı açık kalıyor. Kim kime, ne zaman, hangi sıklıkta, hangi ağdan, hangi grupta ve ne kadar uzun konuştu: bu bilgi şifreleme protokolünün kapsamı dışında ve çoğu zaman içerikten daha değerli. Bir ilişki haritası çıkarmak için mesajları okumak gerekmiyor.
| Veri | Kimde kalır | Ne kadar | Azaltılabilir mi |
|---|---|---|---|
| Telefon numarası ve kayıt tarihi | Sağlayıcı | Hesap açık olduğu sürece | Numara gizleme veya kullanıcı adı desteğiyle |
| Son bağlantı zamanı | Sağlayıcı | Dakikalar mertebesinde | Hariç tutma ayarıyla |
| IP adresi ve bağlantı zamanlaması | Ağ operatörü, sağlayıcı | Günler ile aylar arası | Yalnızca trafik gizleme araçlarıyla kısmen |
| Bildirim jetonu ve teslim zamanı | Apple, Google | Kısa, ama teslim kaydı olarak | Önizleme kapatılarak içerik sızıntısı önlenir |
| Gönderen kimliği (zarf) | Sağlayıcı | Mühürlü gönderici varsa yok | Mühürlü gönderici destekleyen kanal seçilerek |
| Kişi listesi eşleştirmesi | Sağlayıcı | Eşleştirme anında | Numara yüklemeyen istemciyle |
Tablodan çıkan karar basit: meta veri asgarisi bir protokol özelliği değil, sağlayıcının saklama politikası. Aynı protokolü kullanan iki uygulamadan biri kim kime bilgisini otuz gün, diğeri hiç tutmuyorsa güvenlik duruşları aynı değil. Tedarik değerlendirmesinde istenmesi gereken belge, şifreleme beyanı değil, tutulan veri listesi ve saklama süresi tablosu.
İş yeri: 2026/2035 ilke kararı denetimin sınırını çiziyor
Kurumsal mesajlaşma tartışması Türkiye'de teknik bir soru olmaktan çıkıp hukuki bir soruya dönüşüyor: işveren, çalışana tahsis ettiği iletişim kanalını denetleyebilir mi? Kişisel Verileri Koruma Kurulu bu soruya 16 Eylül 2026 tarihli ve 2026/2035 sayılı ilke kararıyla cevap verdi; karar 8 Ekim 2026 tarihli Resmî Gazete'de yayımlandı. Metnin özü tek cümlede: iletişim aracının işverene ait olması veya iş yerinde kullanılması, işverene çalışanların iletişim faaliyetleri üzerinde sınırsız bir denetim yetkisi sağlamıyor.
Karar, kurumsal e-posta hesaplarını ve işin yürütülmesi amacıyla kullanılan diğer iletişim kanallarını kapsıyor; yani yalnızca e-posta değil, iş için kullanılan mesajlaşma uygulamaları da kapsam içinde. Kurul, şikâyetler üzerine yaptığı incelemelerde içerik erişimi, trafik ve log kayıtlarının incelenmesi, filtreleme ve rutin denetim uygulamaları ile elde edilen verilerin disiplin süreçlerinde kullanılmasını tespit etmiş, ancak çalışanların bu işleme faaliyeti hakkında yeterli, açık ve somut biçimde bilgilendirilmediğini kaydetmiş.
| Kurulun belirlediği esas | Pratikte ne demek | Kurumda kim yapar |
|---|---|---|
| İş amaçlı ve özel amaçlı kullanım ayrımı | Kanal hangi amaçla tahsis edildi, kullanım kuralları yazılı mı | İK ve bilgi işlem, politika metni |
| Teknik erişim yetkisi ile hukuki erişim yetkisinin ayrılması | Cihazda veya sistemde yönetici olmak, çalışanın kişisel hesabındaki yazışmayı okuma yetkisi vermez | Bilgi işlem, yetki matrisi |
| Önceden bilgilendirme ve aydınlatma | Genel bir "e-posta denetlenebilir" notu yeterli değil; amaç, kapsam, yöntem, erişim hâlleri, saklama süresi ve md.11 hakları yazılı olmalı | Hukuk ve uyum |
| Açık rızanın değerlendirilmesi | İş ilişkisindeki bağımlılık nedeniyle rıza her durumda öncelikli dayanak sayılamaz; rıza varsa özgür irade ayrıca değerlendirilir | Hukuk |
| Kademeli denetim ve ölçülülük | Aynı amaca daha az müdahaleci yöntemle ulaşılabiliyorsa ağır yönteme başvurulmaz | Bilgi işlem ve hukuk birlikte |
| İçerik denetiminin sınırı | İçerik incelemesi kural olarak yalnızca somut şüphe veya belirli bir olayla bağlantılı meşru amaç varsa ve o amaçla sınırlı yapılır; kapsamı belirsiz, genel ve sürekli içerik incelemesinden kaçınılır | Disiplin soruşturması yürüten birim |
| Özel nitelikli veri ve üçüncü kişi verisi | İncelenen içerikte sağlık, inanç gibi özel nitelikli veri ve karşı tarafın kişisel verisi bulunabilir; bu kişilerin etkisi de hesaba katılır | Hukuk |
| Erişim yetkilendirmesi ve veri güvenliği | Elde edilen veriye erişim görev tanımıyla sınırlı sayıda kişide kalır, erişim kayıtları tutulur, gizlilik yükümlülüğü güvenceye bağlanır | Bilgi işlem |
| İş ilişkisinin sona ermesi | Ayrılan çalışanın hesabı ve verisi süresiz erişilebilir kalmaz; hukuki dayanak yeniden değerlendirilir | İK ve bilgi işlem |
Bu tablodaki en sert satır üçüncüsü, çünkü uygulamada en çok atlanan satır: genel nitelikli bildirim yeterli sayılmıyor. Kurul, çalışana yalnızca kurumsal e-posta hesabının denetlenebileceğine dair genel bir bildirimde bulunulmasının somut olayın özelliklerine göre önceden bilgilendirme bakımından yeterli olmayacağını, aydınlatma yükümlülüğünü de kendiliğinden yerine getirmediğini açıkça yazıyor. Aydınlatmada bulunması gereken unsurlar da sayılmış: hukuki sebep, amaç, kapsam, yöntem, iletişim içeriklerine hangi hâllerde erişilebileceği, saklama süresi ve ilgili kişinin Kanun'un 11. maddesindeki hakları. Bir mesajlaşma politikası metninin ilk sayfası bu yedi başlığı içermiyorsa, Kurul'un ölçütünü karşılamıyor.
Karar, teknik erişim ile hukuki erişimi ayırırken kişisel mesajlaşma uygulamalarını adıyla anıyor: işverenin belirli bir cihaz, oturum, ağ veya kurumsal sistem üzerinde teknik erişim imkânına sahip olması, çalışanın kişisel e-posta hesabı, kişisel anlık mesajlaşma uygulaması veya sosyal medya hesabındaki yazışma içeriklerine serbestçe erişebileceği anlamına gelmiyor. Kurumsal telefonda kişisel WhatsApp yazışmasını okumak, cihazın mülkiyeti ne olursa olsun bu çizginin öte tarafında kalıyor.
Bunun pratik karşılığı mimari bir tercih: iş yazışması, çalışanın kişisel hesabıyla karışmayan ayrı bir kurumsal kanalda yürütülmeli. Ayrım hem hukuki riski hem de teknik riski düşürüyor, çünkü kişisel hesapla iş hesabının aynı cihazda ve aynı numarada birleştiği kurulumlarda işten ayrılma, cihaz kaybı ve yedek yönetimi tek tek çözülmesi gereken sorunlara dönüşüyor. Kanun'un 12. maddesindeki teknik ve idari tedbirler yükümlülüğü de bu mimariye bağlı; KVKK teknik tedbirler ve kanıt rehberi bu yükümlülüğün hangi belgeyle kanıtlanacağını anlatıyor.
Yurt dışında barındırılan bir mesajlaşma altyapısı kullanılıyorsa ikinci bir katman devreye giriyor: müşteri veya çalışan verisinin yurt dışına aktarımı Kanun'un 9. maddesine tabi ve Kurul'un standart sözleşme rejimi 1 Eylül 2024'ten itibaren yürürlükte. Teknik olarak uçtan uca şifreli olmak, veri sorumlusunun aktarım yükümlülüğünü ortadan kaldırmıyor; şifreli metin de kişisel veri taşıyor. Uyulmadığı tespit edilirse Kanun'un 18. maddesi kapsamında işlem tesis edileceği kararda ayrıca belirtiliyor. Kurumsal e-posta tarafındaki alan adı sahteciliği savunması ayrı bir konu ve SPF, DKIM ve DMARC denetimi rehberinde adım adım anlatılıyor; o rehber gönderenin kimliğini doğruluyor, bu rehber içeriğin kimden başka okunabildiğini kapatıyor.
Hangi kanal ne için: ürün sıralaması değil gereksinim listesi
Doğru soru "en güvenli uygulama hangisi" değil, "bu iş için hangi gereksinimler vazgeçilmez". Aynı kurumda yönetim kurulu yazışması, müşteri destek hattı ve saha ekibi için farklı cevaplar doğru olabilir; tek bir ürünü her üçüne zorlamak ya gereksiz maliyet ya da karşılanmamış gereksinim üretir. Aşağıdaki liste bir şartname taslağı olarak kullanılabilir.
| Gereksinim | Nasıl test edilir | Neden önemli |
|---|---|---|
| Uçtan uca şifreleme, varsayılan açık | Yeni sohbet açıp arayüzdeki göstergeyi ve sağlayıcının şeffaflık belgesini birlikte kontrol et | Kapalı varsayılan, kullanıcı hatası bekleyen bir tasarımdır |
| Kriptografik anahtar doğrulama | Güvenlik numarası veya QR doğrulaması var mı, değişimde uyarı veriyor mu | Araya giren saldırıya karşı tek kullanıcı tarafı savunma |
| Yedekte şifreleme ve anahtarın kullanıcıda olması | Yedek ayarını aç, anahtarın nerede saklandığını yazılı olarak al | Yedek, mimarinin en zayıf halkası |
| Bağlı cihaz yönetimi | Cihaz listesi görünüyor mu, tek tıkla kaldırılabiliyor mu | Ele geçirilmiş hesabın ilk izi burada görünür |
| Meta veri saklama beyanı | Kim kime, ne zaman verisinin ne kadar tutulduğunu yazılı iste | İçerik şifreli olsa da ilişki haritası çıkarılabilir |
| Kurumsal kayıt ve saklama (legal hold) | Kayıt gereksinimi olan roller için ayrı arşiv var mı | Uçtan uca şifreleme ile e-arşiv yükümlülüğü çatışabilir; çözüm ayrı kanal |
| Kimlik yönetimi entegrasyonu | Tek oturum açma, cihaz kaydı, ayrılışta otomatik kapatma | Ayrılan çalışanın erişimi idari süreçle değil sistemle kesilmeli |
| Veri ikametgâhı ve aktarım dayanağı | Sunucu bölgesi ve standart sözleşme durumu | Kanun'un 9. maddesi şifreli metin için de geçerli |
Bu listenin altıncı satırı çoğu kurumda gözden kaçıyor. Uçtan uca şifreleme ile bazı sektörlerdeki kayıt saklama yükümlülüğü aynı kanalda çözülmüyor; çözüm, şifreli kanalı operasyonel iletişimde tutup kayıt gerektiren yazışmayı kurumsal arşive akan ayrı bir kanalda yürütmek. Aynı mesajı hem uçtan uca şifreli hem merkezî arşivde tutmayı vaat eden ürünler genellikle üçüncü bir tarafta anahtar tutuyor; o durumda şifreleme, sağlayıcının okuma yeteneğinin adı değişmiş hâlidir. Tedarikçi değerlendirmesinde bu iddiayı yazılı olarak sormak gerekiyor; tedarikçi risk rehberi bu soruların sözleşmeye nasıl yazılacağını anlatıyor.
30 günlük geçiş programı
Bir kanal değişimi duyuruyla olmuyor; ölçülebilir bir takvim gerekiyor. Aşağıdaki program 1.000 kişilik bir kurum için saatleriyle birlikte 876 saatlik bir iş yükü çıkarıyor; daha küçük kurumda süreler düşer, sıra değişmez.
| Hafta | İş | Saat |
|---|---|---|
| 1 | Kanal envanteri ve tehdit modeli: hangi iş hangi kanaldan yürüyor, hangi veri özel nitelikli | 24 |
| 2 | Politika ve aydınlatma metni: 2026/2035 kararının saydığı yedi unsur, saklama süreleri, erişim hâlleri | 32 |
| 3 | Kanal seçimi ve 50 kişilik pilot: doğrulama tatbikatı, yedek şifrelemesi, bağlı cihaz denetimi | 40 |
| 4 | Yedek ve cihaz politikası: anahtar saklama, kayıp cihaz prosedürü, ayrılış kontrol listesi | 18 |
| Sürekli | Eğitim ve doğrulama: 1.000 kişi × 45 dakika | 750 |
| 4 | Ölçüm ve rapor: yedek şifrelemesi oranı, doğrulanmış kişi sayısı, tanınmayan bağlı cihaz sayısı | 12 |
| Toplam | 876 | |
Eğitimin 750 saati toplamın yüzde 86'sı ve bu bir hata değil: kanal değişiminde en pahalı kalem lisans değil, insanların yeni alışkanlığı edinmesi. Eğitimin içeriği de "şifreli uygulamayı kur" değil, üç davranış olmalı: güvenlik numarasını doğrula, bağlı cihaz listesine ayda bir bak, yedek anahtarının nerede olduğunu bil. Farkındalık eğitimi programı bu üç davranışı ölçülebilir hâle getirmenin yolunu anlatıyor.
Üç tatbikat: bir öğleden sonrada ölçülebilir güvenlik
Politika metni olmayan güvenlik, olmayan güvenliktir; tatbikatı yapılmayan politika da öyle. Üç tatbikat bir öğleden sonraya sığıyor ve her biri tek bir sayı üretiyor.
| Tatbikat | Adımlar | Süre | Ürettiği ölçü |
|---|---|---|---|
| Güvenlik numarası doğrulama | En hassas 12 kişiyle numaraları karşılaştır, QR ile okut, sonucu kaydet | Kişi başına 18 dakika | Doğrulanmış çift sayısı ve doğrulanmamış kalan |
| Cihaz kaybı | Aşağıdaki 60 dakikalık zaman çizelgesini uygula | 60 dakika | Saat kaçta erişim kesildi |
| Yedek geri yükleme | Test cihazında yedeği geri yükle, anahtarın kasada çalıştığını doğrula | 45 dakika | Geri yükleme başarılı mı, kaç dakika sürdü |
Cihaz kaybı tatbikatının zaman çizelgesi, gerçek olayda saniyelerin değil dakikaların önemli olduğunu gösteriyor:
| Dakika | Adım | Kim |
|---|---|---|
| 0 – 5 | Bağlı cihazlar listesinden kayıp cihazı kaldır, uzaktan oturumu kapat | Cihaz sahibi |
| 5 – 15 | Operatöre SIM bildirimi, numara taşıma kilidi, iki adımlı doğrulama yenileme | Cihaz sahibi ve İK |
| 15 – 30 | Kritik kişilere güvenlik numarasının değişeceğini duyur, yeni cihazdan doğrulama iste | Bilgi işlem |
| 30 – 50 | Yedek anahtarını döndür, eski anahtarı geçersiz kıl, kasayı güncelle | Bilgi işlem |
| 50 – 60 | Olay kaydı aç, eksik adımı not et, prosedürü güncelle | Olay sorumlusu |
Toplam 60 dakika ve bu süre boyunca kurumun gerçek yazışması açık kalıyor. Bir hesap ele geçirildiğinde ilk saat içinde yapılmayan her adım saldırganın lehine işliyor; WhatsApp hesabı çalındığında ne yapılmalı rehberi aynı zinciri tek kullanıcı ölçeğinde, olay müdahale planı rehberi ise kurum ölçeğinde tamamlıyor.
Maliyet ve ceza aritmetiği
Geçişin maliyeti hesaplanabilir ve tahmin edilebilir; cezanın ve olayın maliyeti değil. 1.000 kişilik kurumda 876 saatlik programı iki saatlik ücretle çarpalım: eğitim için 750 saat × 450 TL = 337.500 TL, politika ve teknik işler için 126 saat × 500 TL = 63.000 TL, toplam 400.500 TL. Kanun'un 18. maddesindeki veri güvenliği yükümlülüğü ihlalinin 2026 tarifesindeki aralığı 256.357 TL ile 17.092.242 TL arasında; üst sınır, programın tek seferlik maliyetinin 42,7 katı, üç yıllık maliyetin (1.201.500 TL) ise 14,2 katı. Bu bir ceza beklentisi hesabı değil, sadece ölçek karşılaştırması: bir kerelik iş, bir yıllık idari para cezası aralığının altında kalıyor.
Asıl kalem ceza değil, birikim. 1.000 çalışan günde ortalama 60 mesaj yazarsa yılda 21,9 milyon mesaj, üç yılda 65,7 milyon mesaj eder. Mesaj başına 2 kilobayt ortalama ile bu 134,6 gigabaytlık metin; sunucu tarafında düz metin tutan bir kanalda üç yıllık, okunabilir, aranabilir bir arşiv. Uçtan uca şifreli bir kanalda aynı hacim, sızsa bile okunamayan şifreli metin. İki mimari arasındaki fark, depolama maliyeti değil, tek bir sızmanın kapsamı.
Doğrulama tarafında maliyet daha da küçük: 40 kişilik bir ekipte en hassas 12 kişiyle yapılan doğrulama 12 saat. Bir araya giren saldırganın bir yıl boyunca okuduğu yazışmanın, sözleşme değişikliğinin ve ödeme talimatının karşılığı 12 saatlik bir takvim bloğu. Ölçek büyüdükçe tablo kurumun lehine dönüyor, çünkü saldırının maliyeti kurumun büyüklüğüyle artarken doğrulamanın maliyeti kişi sayısıyla doğrusal.
Hukuki sınır: şifreli kanal içeriği hukuka uygun yapmaz
Son ve en çok yanlış anlaşılan nokta: şifreli bir kanal kullanmak, o kanaldan geçen içeriği hukuka uygun hâle getirmiyor. Türk Ceza Kanunu'nun 132. maddesi haberleşmenin gizliliğini ihlal etmeyi, 133. maddesi kişiler arasındaki konuşmaların dinlenmesini ve kayda alınmasını, 134. maddesi özel hayatın gizliliğini ihlal etmeyi, 136. maddesi kişisel verilerin hukuka aykırı olarak ele geçirilmesini veya yayılmasını suç olarak düzenliyor. Anayasa'nın 20. ve 22. maddeleri özel hayatın gizliliğini ve haberleşme hürriyetini güvence altına alıyor. Şifreleme bu hükümlerin yerine geçmiyor; yalnızca ihlalin teknik zorluğunu artırıyor.
Aynı şekilde, bir kişinin rızasıyla başka bir kişi arasındaki yazışmayı okumak veya kaydetmek de kural olarak hukuka uygun değil; karşı tarafın kişisel verisi ve haberleşme özgürlüğü ayrı ayrı korunuyor. Yetkili mercilerin iletişimin denetlenmesi Ceza Muhakemesi Kanunu'nun 135. maddesi kapsamında ve hâkim kararıyla yürür. Bu rehberdeki bütün yöntemler, kendi hesabınızı ve kurumunuzun kendi kanalını korumak için; başkasının hesabına erişmek, cihazına yazılım yerleştirmek veya şifrelemesini kırmak için değil. Şifreleme kırma hizmeti vaat eden hiçbir yöntem bu metnin kapsamında değil ve hiçbir meşru güvenlik çalışması böyle bir vaatle başlamaz.
Sphnix izleme paneli
Mesajları, konumu, sosyal medya ve etkinlik sinyallerini yetkili bir panelden takip edin.
Sphnix’i dene →İlgili Sphnix özellikleri:
Sorularınız mı var? Uzmanlarımız yardıma hazır.
Ücretsiz danışma için bize ulaşın →Sık sorulan sorular
Hayır. Uçtan uca şifreleme içeriği sağlayıcıdan ve aradaki herkesten korur; ele geçirilmiş bir cihazı, şifresiz tutulan yedeği, kilit ekranında metni gösteren bildirimi, ekran görüntüsünü veya meta veriyi korumaz. Ayrıca karşı tarafın gerçekten o kişi olduğu ancak güvenlik numarası doğrulandığında garanti altına alınır. Bu yüzden "tamamen güvenli" değil, "belirli bir tehdit listesine karşı etkili" demek daha doğru: sağlayıcının okumasına, sunucudan sızmaya ve zorunlu teslime karşı içerik korunur; cihaz ve yedek tarafındaki hatalar açık kalır.
Varsayılan olarak her zaman değil; ayarı açmanız gerekiyor. Uçtan uca şifreli yedekleme açıkken yedek 64 haneli bir anahtar, parola veya geçiş anahtarıyla korunuyor ve bu anahtar olmadan yedek açılmıyor. Ayar kapalıyken yedek iCloud veya Google Drive hesabınızda duruyor; bulut sağlayıcısı yedeği kendi anahtarlarıyla koruyor, yani teknik olarak erişebilir. Kurum açısından bu fark, kanalın güvenlik sınırını belirliyor: yedek şifrelemesi kapalıysa mesajlaşma protokolünün gücü ne olursa olsun geçmiş, bulut hesabının şifresi kadar korunmuş oluyor.
Tek başına bu bir kanıt değil. Numara, karşı taraf uygulamayı yeniden kurduğunda, yeni telefon aldığında veya yedekten geri döndüğünde de değişir. Saldırı ihtimali, SIM kopyalama, numara taşıma ve hesaba yeni cihaz bağlanması durumlarında öne çıkar. Doğru hareket, aynı kanaldan yazışmak yerine farklı bir yolla (yüz yüze, sesli arama veya kurumsal dizinden bulunan numara) karşı tarafa ulaşıp yeni numarayı karşılaştırmak. Doğrulama tamamlanana kadar o kanaldan sözleşme, kimlik bilgisi veya ödeme talimatı geçirmemek gerekiyor.
Gizli sohbetler uçtan uca şifreli ve cihaza bağlı; başka bir cihazdan okunamıyor, bulutta yedeklenmiyor. Bulut sohbetleri ise istemci ile sunucu arasında şifreli ama sunucu tarafında çözülebilir; bu sohbetler cihazlar arasında senkronize olurken sunucuda da duruyor. Aynı uygulamada iki farklı güvenlik modeli yan yana çalıştığı için, kullanıcı arayüzde hangi sohbetin hangi modda olduğunu bilmeden "Telegram şifreli" sonucuna varmamalı. Kurumsal kullanımda bu ayrım yazılı politikaya girmesi gereken bir madde.
Kişisel Verileri Koruma Kurulu'nun 16 Eylül 2026 tarihli ve 2026/2035 sayılı ilke kararına göre sınırsız biçimde hayır. Karar, iletişim aracının işverene ait olmasının sınırsız denetim yetkisi doğurmadığını, teknik erişim yetkisi ile hukuki erişim yetkisinin ayrı olduğunu, içerik incelemesinin kural olarak somut şüphe veya belirli bir olayla bağlantılı meşru amaçla sınırlı yapılabileceğini, genel nitelikli bildirimin aydınlatma yükümlülüğünü karşılamadığını yazıyor. Çalışanın kişisel anlık mesajlaşma uygulamasındaki yazışmaları karar metninde ayrıca anılıyor.
Kaldırmıyor. Şifreleme Kanun'un 12. maddesindeki teknik tedbirlerin bir parçası, yükümlülüğün tamamı değil. Aydınlatma (md.10), veri güvenliği (md.12), yurt dışına aktarım (md.9) ve ihlal bildirimi yükümlülükleri şifreli metin için de geçerli; şifreli metin kişisel veri taşımaya devam ediyor. Ayrıca tedbirlerin varlığını kanıtlamak gerekiyor: politika metni, erişim kayıtları, eğitim kayıtları ve tatbikat çıktıları olmadan "şifreli bir uygulama kullanıyoruz" savunması belgeye dönüşmüyor.
Bugün okunabilen bir şey yok; risk kaydetme ve sonra çözme senaryosunda. Şifreli trafik bugün kaydedilip yeterince güçlü bir kuantum makinesi erişilebilir olduğunda açılmaya çalışılabilir. Karar üç süreyle veriliyor: verinin gizli kalması gereken yıl sayısı, kuantum sonrası geçişin süresi ve böyle bir makinenin gerçekçi olacağı ufuk. Toplam ilk ikisi tehdit ufkunu aşıyorsa veri bugün risk altında. Uzun saklanan sağlık, sözleşme ve müşteri yazışmaları için kuantum sonrası anahtar anlaşması sunan kanalı seçmek, bugün verilebilecek en ucuz kararlardan biri.
Tek bir cevap yok, çünkü güvenlik gereksinimlere göre tanımlanıyor. Bir kurum için uçtan uca şifrelemenin varsayılan açık olması, anahtar doğrulamasının bulunması, yedeğin kullanıcı anahtarıyla şifrelenmesi, bağlı cihazların yönetilebilmesi, meta veri saklama beyanının yazılı olması ve kayıt saklama yükümlülüğüyle çatışmayan bir arşiv çözümünün bulunması belirleyici. Bu altı maddeyi karşılayan birden çok ürün var ve seçim kurumun tehdit modeline, veri ikametgâhına ve mevcut kimlik yönetimi altyapısına bağlı. Ürün adı yerine şartname yazmak, hem tedarik hem denetim açısından daha savunulabilir.
