Dijital delil, HMK m.199 uyarınca belge sayılan elektronik veridir. Hukuka uygun elde edildiyse mahkemede ağırlığı dört teknik soruya bağlıdır: Kaynağı gösterilebiliyor mu, elde edildiğinden beri değişmedi mi, zamanı bağımsız kayıtlarla doğrulanıyor mu, bağlamıyla eksiksiz mi? Hash bütünlüğü, e-posta başlığı ve metadata kökeni, sunucu kayıtları zamanı gösterir; itirazda tartışmayı çoğunlukla HMK m.266 vd. uyarınca atanan bilirkişi çözer.
- Elektronik veri HMK m.199 uyarınca belgedir ve hâkimce serbestçe değerlendirilir; yalnızca usulüne göre güvenli elektronik imzayla oluşturulan veri HMK m.205/2 uyarınca senet hükmündedir.
- E-postanın özgünlüğü ekrandaki gönderen adıyla değil, alıcı sunucunun yazdığı Received satırları, DKIM imzası ve kimlik doğrulama sonuçlarıyla tartışılır; iletmek (forward) ve PDF'e yazdırmak bu katmanı siler.
- Metadata tek başına kesin kanıt değildir; belge içi alanlar, dosya sistemi kayıtları ve bulut sürüm geçmişi birbirini tuttuğunda güçlü bir zaman ve köken göstergesine dönüşür.
- Hash yalnızca hesaplandığı andan sonraki değişmezliği gösterir; 5070 sayılı Kanun'daki zaman damgası bu hash'e tarih verir, güvenli elektronik imza ise kimlik ve bütünlüğü birlikte bağlar.
- Bilirkişi ret talebi sebebin öğrenilmesinden itibaren bir hafta, rapora itiraz tebliğden itibaren iki hafta içinde yapılır; bilirkişi raporunda hukuki nitelendirme yapamaz (HMK m.272, 281, 279/4).
İçindekiler

Bir dosyanın mahkemede işe yaraması için içeriğinin ikna edici olması yetmez; o içeriğin nereden geldiğini, ne zaman oluştuğunu ve o günden bu yana değişmediğini gösteren teknik kayıtların da ayakta kalması gerekir. Dijital delilin mahkemede kabulü bu yüzden çoğu dosyada içerik tartışmasından önce bir köken ve bütünlük tartışmasıdır. Karşı taraf "bu e-postayı ben göndermedim", "bu belge o tarihte yoktu" ya da "bu dosya sonradan değiştirildi" dediğinde cevap ekrandaki görüntüde değil; e-postanın başlık satırlarında, belgenin üst verisinde, sunucunun kayıtlarında ve hash değerlerinde aranır.
Bu rehber o teknik katmana odaklanıyor. Hukuka uygunluk, ilgililik ve zamanlama gibi genel ölçütleri delilin kabul edilebilirliğine ilişkin yedi kriter yazısında ele aldık. Burada imaj alma stratejisi, hash'in neyi kanıtlayıp neyi kanıtlamadığı, 5070 sayılı Elektronik İmza Kanunu ve zaman damgası, e-posta başlığı ve metadata analizi, bulut verisi, ekran görüntüsü ile orijinal veri arasındaki fark, HMK m.266 vd. kapsamındaki bilirkişi süreci ve ceza yargılamasındaki çerçeve anlatılıyor.
Anlatım teknik terimlerden kaçmıyor, ama her terimi ilk geçtiği yerde açıklıyor. Amaç sizi bir adli bilişim uzmanına dönüştürmek değil. Elinizdeki verinin hangi sorulara cevap verebileceğini, hangilerine veremeyeceğini ve avukatınızla birlikte hangi adımı ne zaman atmanız gerektiğini görebilmenizi sağlamak.
Dijital delil nedir? HMK m.199 ve elektronik verinin hukuki niteliği
Dijital delil, uyuşmazlık konusu bir vakıayı ispata elverişli olan ve elektronik, optik veya benzeri yollarla üretilen, taşınan ya da saklanan veridir. Hukuk yargılamasında HMK m.199 bu verileri açıkça belge sayar; bir e-posta, bir PDF, bir sistem kaydı ya da bir bulut klasöründeki sürüm geçmişi, kâğıt bir belge gibi delil olarak sunulabilir.
Belge olmak, kesin delil olmak demek değildir. HMK m.198'e göre kanuni istisnalar dışında hâkim delilleri serbestçe değerlendirir. Sıradan bir e-posta, bir Word dosyası ya da bir ekran kaydı bu serbest değerlendirmeye tabidir; ağırlığını kaynağının ve bütünlüğünün ne kadar iyi gösterildiği belirler. Güvenli elektronik imzalı veri ise senet hükmünde olduğu için, senetle ispat zorunluluğunun bulunduğu işlemlerde de kullanılabilir ve imza inkâr edildiğinde tartışma imzanın teknik doğrulamasına kayar.
| Elektronik veri türü | Hukuki konumu | Özgünlüğü gösteren | Tipik itiraz |
|---|---|---|---|
| Sıradan dosya (Word, PDF, tablo, fotoğraf) | HMK m.199 belge; serbest değerlendirme | Üst veri, kaynak cihaz, hash, bağımsız kayıtlar | "Sonradan hazırlandı", "değiştirildi" |
| E-posta iletisi | Belge; imzasızsa senet değildir | Başlık satırları, DKIM imzası, sunucu kayıtları | "Ben göndermedim", "içerik değişti" |
| Güvenli elektronik imzalı veri | Senet hükmünde (HMK m.205/2) | İmza doğrulaması, nitelikli sertifika | Sertifikanın geçerliliği, temsil yetkisi |
| Kayıtlı elektronik posta (KEP) iletisi | Tacirler arası bazı ihbar ve ihtarların kanuni yollarından biri (TTK m.18/3) | Sağlayıcının gönderim ve teslim kayıtları | İçeriğin yorumu; nadiren gönderimin kendisi |
| Zaman damgalı dosya | Damgalama anında o içerikle var olduğunun kaydı (5070 m.3) | Damgadaki hash ile dosya hash'inin eşleşmesi | "Asıl oluşturma anı başka" |
| Sistem ve sunucu kaydı (log) | Belge; çoğu zaman üçüncü kişinin elindedir | Kaydı tutan sistemin bütünlüğü, saat eşitlemesi | "Saat yanlış", "kayıt eksik" |
| Barkodlu kurum çıktısı | Düzenleyen kurumun kaydına dayanır | Kurumun doğrulama servisinden alınan sonuç | Belgenin güncelliği |
"İncelemeye elverişli" biçim ne demektir?
HMK m.219'daki "incelemeye elverişli" ifadesi, pratikte bilirkişinin üzerinde çalışabileceği biçimi anlatır. Bir e-postanın PDF çıktısı okunabilir, ama incelenemez; içinde başlık satırları, imza bilgisi ve ekin orijinali yoktur. İncelemeye elverişli biçim, verinin doğduğu formattaki hâlidir: e-posta için ham ileti dosyası, belge için orijinal Word ya da PDF dosyası, kayıt için sistemin ürettiği dosya.
Bu yüzden dosyaya genellikle iki katman birlikte konur. Hâkimin ve karşı tarafın okuyacağı açıklamalı çıktılar ile bilirkişinin inceleyeceği orijinal dosyaları içeren bir veri ortamı. İkinci katmanın yanına her dosyanın adını, boyutunu ve hash değerini gösteren bir liste eklenir. Liste, çıktıdaki sayfa ile ortamdaki dosya arasında köprü kurar: "Ek-4'teki çıktı, ortamdaki şu dosyanın görüntüsüdür."
Mahkeme dijital delilde neye bakar? Dört teknik soru
Hukuka uygun elde edilmiş bir dijital delil karşısında hâkim ve bilirkişi dört soruya cevap arar: Veri iddia edilen kaynaktan mı geliyor, elde edildiği andan beri değişmedi mi, iddia edilen zamanda mı oluştu ve bağlamıyla eksiksiz mi sunuluyor? Bu dört soru köken, bütünlük, zaman ve tamlık diye özetlenebilir; her birinin kendine özgü teknik dayanakları vardır.
| Soru | Teknik dayanak | Güçlendiren | Zayıflatan |
|---|---|---|---|
| Köken: Kimden, hangi sistemden? | E-posta başlığı, DKIM, hesap ve cihaz kimlikleri, belge üst verisi | Sunanın kontrol etmediği bağımsız bir kayıt | Yalnızca çıktı veya ekran görüntüsü |
| Bütünlük: Değişti mi? | Hash değeri, imaj, elektronik imza | Edinme anında hesaplanmış hash | Geç hesaplanan hash, orijinal üzerinde çalışma |
| Zaman: Ne zaman oluştu? | Sunucu zaman kayıtları, dosya sistemi, zaman damgası | Birbirinden bağımsız saatlerin örtüşmesi | Tek kaynaklı, cihaz saatine dayalı tarih |
| Tamlık: Bütün mü? | Tam yazışma zinciri, tam dışa aktarma, sürüm geçmişi | Seçim ölçütünün yazılı olması | Seçilmiş parçalar, kesilmiş zincir |
Dört sorunun öncesinde bir ön koşul vardır: Delilin hukuka uygun elde edilmiş olması. Anayasa m.38/6, HMK m.189/2 ve ceza yargılamasında CMK m.206/2-a ile m.217/2 bu kapıyı belirler. Teknik açıdan kusursuz bir veri, başkasının hesabına girilerek elde edilmişse dört sorunun hiçbirine sıra gelmeyebilir.
Bağımsız kaynak ilkesi
Dijital delillerin ağırlığını belirleyen en pratik ölçüt, delili doğrulayan bir kaydın sunan tarafın kontrolü dışında bulunup bulunmadığıdır. Kendi bilgisayarınızda duran bir belgenin tarihi, sonuçta sizin sisteminizin söylediği tarihtir. Aynı belgenin üç ay önce bir müşteriye e-posta eki olarak gittiğini gösteren, alıcı şirketin sunucusundaki kayıt ise sizin değiştiremeyeceğiniz bir tanıktır.
Bu ilke dosya hazırlarken sorulacak soruyu da değiştirir. "Bu dosyayı nasıl daha inandırıcı gösteririm?" yerine "Bu dosyanın varlığını ve tarihini benden bağımsız olarak hangi sistem doğrulayabilir?" diye sormak gerekir. Karşı tarafın sunucusu, bir bulut sağlayıcının sürüm geçmişi, bir bankanın işlem kaydı, bir kargo şirketinin teslim kaydı ya da bir zaman damgası sağlayıcısı bu sorunun tipik cevaplarıdır.
İmaj alma: Tam imaj, hedefli toplama ve canlı edinim
İmaj alma, bir depolama ortamının birebir adli kopyasını çıkarmaktır; ama her dosyada tam disk imajı ne gerekli ne de mümkündür. Edinme yöntemi; verinin nerede durduğuna, cihazın açık ya da kapalı olmasına, şifrelemeye, uyuşmazlığın ağırlığına ve kişisel verilerin ölçülü işlenmesi ilkesine göre seçilir ve gerekçesiyle yazılır.
Yazma engelleyici, adli imaj formatları ve edinme kaydının temel unsurları delil zincirinin dokuz halkasını anlattığımız rehberde ele alındı. Burada seçim mantığına odaklanıyoruz: Hangi durumda hangi edinme stratejisi tercih edilir ve her birinin bedeli nedir?
| Edinme stratejisi | Ne alır? | Ne zaman tercih edilir? | Sınırı |
|---|---|---|---|
| Tam fiziksel imaj | Silinmiş ve kullanılmayan alanlar dahil bütün ortam | Silme şüphesi, kapsamlı kurumsal inceleme, şirket cihazı | Büyük hacim; ilgisiz kişisel veri; şifreli diskte anahtar gerekir |
| Mantıksal imaj | Bir bölüm veya klasördeki görünür dosya sistemi içeriği | Belirli kullanıcı profili veya proje klasörü | Silinmiş alanlar dışarıda kalır |
| Hedefli toplama | Önceden tanımlanmış dosya türleri, tarih aralığı, anahtar kelimeler | Ölçülülüğün öne çıktığı işyeri incelemeleri | Ölçüt dışında kalan delil kaçabilir; ölçüt yazılı olmalıdır |
| Canlı edinim | Bellek, açık oturumlar, ağ bağlantıları, şifresi çözülmüş birimler | Cihaz açık, disk şifreli veya bulut oturumu açık | İşlemin kendisi sistemde iz bırakır; her adım kaydedilir |
| Mobil edinim | Mantıksal veya dosya sistemi düzeyinde telefon verisi | Telefon ve tabletler | Sonuç modele ve yazılım sürümüne bağlıdır |
| Hesap ve bulut edinimi | Sunucudaki içerik, sürümler, erişim kayıtları | Veri cihazda değil, sağlayıcının sunucusunda | Yetki; sağlayıcının dışa aktarma biçimi |
Hedefli toplama ve ölçülülük
Kurumsal bir incelemede çalışanın kullandığı şirket bilgisayarının tamamını imajlamak teknik olarak en güvenli yol gibi görünür. Ama o diskte çoğu zaman çalışanın sağlık raporları, aile fotoğrafları ve özel yazışmaları da vardır. KVKK m.4'teki "işlendikleri amaçla bağlantılı, sınırlı ve ölçülü olma" ilkesi, toplanacak verinin kapsamını uyuşmazlıkla sınırlamayı gerektirir.
Burada iki yaklaşım birlikte kullanılabilir. Tam imaj alınıp mühürlü olarak saklanır, inceleme ise yazılı ölçütlerle sınırlanır; ya da baştan hedefli toplama yapılır ve ölçüt edinme kaydına yazılır. İkinci yolda karşı tarafın "lehime olan dosyalar toplanmadı" itirazı beklenir. Bu itiraza verilecek cevap, ölçütün inceleme başlamadan önce belirlenmiş ve belgelenmiş olmasıdır.
Şifreleme, kapatma kararı ve canlı edinim
Modern dizüstü bilgisayarların ve telefonların çoğunda depolama şifrelidir. Açık ve oturumu açık bir cihazda veriler o anda okunabilir durumdadır; cihaz kapatıldığında ise kurtarma anahtarı veya parola olmadan imaj anlamsız bir veri yığınına dönüşebilir. Bu yüzden "cihazı hemen kapatın" refleksi her dosyada doğru değildir.
Canlı edinim, açık bir sistemden bellek içeriğinin, açık oturumların ve şifresi çözülmüş birimlerin alınmasıdır. Kaçınılmaz olarak sistemde küçük değişiklikler yaratır: araç çalışır, belleğe yüklenir, bazı kayıtlar oluşur. Bu değişiklikler kusur değildir, ama kayıt altına alınmazsa itiraz malzemesine dönüşür. Hangi aracın, hangi sırayla, hangi saatte çalıştırıldığı ve neden canlı edinimin tercih edildiği yazılı olmalıdır.
SSD, telefon ve silinmiş verinin sınırları
Klasik manyetik disklerde silinen bir dosya, üzerine yeni veri yazılana kadar çoğu zaman fiziksel olarak yerinde durur. SSD'lerde ise işletim sistemi, silinen blokları diske bildiren bir komutla temizlenmeye işaretleyebilir ve disk bu alanları kısa sürede boşaltabilir. Şifrelemeli modern telefonlarda silinen dosyanın şifreleme anahtarı da yok edildiği için, içerik çoğu zaman kurtarılamaz.
Bu gerçek, iki yönde beklenti yönetimi gerektirir. Bir tarafta "silinen her şey geri getirilir" vaadi gerçekçi değildir. Öte yandan silinen içeriğe ulaşılamasa bile silme işleminin kendisi; dosya sistemi günlüklerinde, bulut sürüm geçmişinde ya da yazışmanın karşı tarafındaki kopyada iz bırakabilir. Silme davranışının hukuki sonuçlarını ve meşru gizlilik temizliğiyle farkını dijital iz silme ile delil koruma arasındaki denge yazısında ayrıca ele aldık.
Bulutla eşitlenen klasör tuzağı
Bulut depolama istemcilerinin çoğu, disk alanından tasarruf için dosyaların yalnızca yer tutucusunu bilgisayarda bırakır; içerik ancak açıldığında sunucudan indirilir. Böyle bir bilgisayarın imajında dosya adları ve klasör yapısı görünür, ama içeriklerin önemli bir kısmı bulunmaz. Kurumsal incelemelerde bu nedenle cihaz imajı ile bulut hesabının edinimi birlikte planlanır.
Aynı eşitleme, ters yönde de sürpriz yaratabilir. Cihaz incelenmeyi beklerken internete bağlı kalırsa, buluttaki bir silme işlemi cihaza da yansıyabilir. Edinme planı, cihazın ağ bağlantısının ne zaman ve nasıl kesileceğini de içermelidir.
Aracın doğrulanmış ve işlemin tekrarlanabilir olması
Bir adli bilişim raporunun ağırlığı, başka bir uzmanın aynı materyal üzerinde aynı adımları tekrar ederek aynı sonuca ulaşabilmesine bağlıdır. Bunun için kullanılan araçların adı ve sürümü, ayarları ve işlem sırası rapora yazılır. Uluslararası uygulamada araçların doğrulanmasına yönelik test programları ile ISO/IEC 27037 (tanımlama, toplama, edinme ve koruma), ISO/IEC 27041 (yöntemin uygunluğunun güvencesi) ve ISO/IEC 27042 (analiz ve yorumlama) gibi standartlar bu tekrarlanabilirliğin çerçevesini çizer. Bu standartlar Türk mahkemelerini bağlamaz; ama bir raporun yöntem kısmının neyi içermesi gerektiğine dair yaygın kabul görmüş bir ölçüt sunar.
Hash doğrulama ve zaman damgası: Bütünlüğü zamana bağlamak
Hash doğrulama, bir verinin hesaplama anından sonra değişmediğini gösterir; verinin ne zaman oluştuğunu, kimin ürettiğini veya içeriğinin doğru olup olmadığını göstermez. Bu boşluğun bir kısmını 5070 sayılı Elektronik İmza Kanunu kapsamındaki zaman damgası ve güvenli elektronik imza kapatır.
Hash değerinin ne olduğu ve kendi bilgisayarınızda nasıl hesaplanacağı daha önce anlatıldı. Dijital delil açısından asıl ince nokta, hash'in hangi düzeyde alındığıdır. Aynı veri; disk imajı, tek dosya, arşiv paketi ya da tek bir e-posta iletisi düzeyinde farklı sonuçlar verir ve karşılaştırma ancak aynı düzeydeki değerler arasında anlamlıdır.
| Hash düzeyi | Örnek | Neyi güvenceye alır? | Dikkat edilecek nokta |
|---|---|---|---|
| Ortam veya imaj | Bir diskin ya da telefonun imaj dosyası | İmajın bütünü | İmajdan çıkarılan her dosyanın ayrıca kendi değeri hesaplanır |
| Dosya | Tek bir PDF, video veya tablo | O dosyanın içeriği | Dosya adı değişse de değer aynı kalır; ad değil içerik ölçülür |
| Kapsayıcı | ZIP arşivi, posta kutusu dosyası, dışa aktarma paketi | Paketin o kopyası | Aynı içerik yeniden dışa aktarıldığında paketin değeri değişebilir |
| Öğe | Tek bir e-posta iletisi, tek bir sohbet kaydı | İletinin içeriği | Araçların öğe değeri hesaplama yöntemi farklıdır; yöntem yazılmalıdır |
| Kayıt aralığı | Bir sunucu kaydının belirli tarih aralığı | Seçilen aralık | Aralığın nasıl seçildiği ayrıca belgelenir |
Yeniden dışa aktarma neden farklı hash verir?
Bir posta kutusunu bugün ve bir ay sonra aynı ayarlarla dışa aktardığınızda, iki paketin hash değerleri büyük ihtimalle farklı çıkar. Bunun nedeni içerik değişikliği değil, paketin kendisine yazılan dışa aktarma tarihi, sıralama ve sıkıştırma gibi ayrıntılardır. Karşı tarafın uzmanı bu farkı "veri değişmiş" diye sunabilir.
Bu itirazın cevabı, bütünlüğü paket düzeyinde değil öğe düzeyinde de kayda geçirmektir. İletilerin veya dosyaların tek tek hash değerleri ilk edinmede listelenirse, sonraki bir dışa aktarmada paketin değeri farklı çıksa bile her iletinin aynı kaldığı gösterilebilir.
Hash eşleşmesi aynılığı kanıtlar, kimliği değil
Bir çalışanın kişisel belleğinde bulunan bir dosyanın hash değeri, şirketin gizli fiyat listesinin değeriyle eşleşiyorsa, iki dosyanın birebir aynı olduğu kanıtlanmıştır. Dosyayı kimin, ne zaman ve nasıl kopyaladığı ise ayrı bir sorudur ve işletim sistemi kayıtları, bağlantı geçmişi ve diğer delillerle cevaplanır.
Uygulamada hash'in iki ek kullanımı daha vardır. Birincisi, işletim sistemi dosyaları gibi bilinen ve ilgisiz dosyaların hash kümeleriyle elenmesidir; bu, inceleme yükünü azaltır ve kişisel verinin gereksiz yere açılmasını önler. İkincisi, benzerlik hash'i (fuzzy hashing) adı verilen yöntemlerdir. Klasik hash tek bir karakter değişikliğinde tamamen farklılaşırken, benzerlik hash'i bir dosyanın düzenlenmiş sürümlerini "büyük ölçüde benzer" olarak yakalayabilir. Sızıntı soruşturmalarında, adı ve birkaç satırı değiştirilmiş bir belgenin izini sürmek için bu yöntemlerden yararlanılır.
Zaman damgası: Hash'e tarih vermek
5070 sayılı Kanun m.3, zaman damgasını bir elektronik verinin üretildiği, değiştirildiği, gönderildiği, alındığı ve/veya kaydedildiği zamanın tespit edilmesi amacıyla elektronik sertifika hizmet sağlayıcısı tarafından elektronik imzayla doğrulanan kayıt olarak tanımlar. Teknik uygulamada sağlayıcıya dosyanın kendisi değil, hash değeri gönderilir; sağlayıcı bu değeri kendi saatine göre tarihleyip imzalar.
Bu yapı, hash'in tek başına veremediği bir bilgiyi ekler: Bu içerik en geç damgalama anında vardı. Dosyanın ne zaman oluşturulduğunu, kim tarafından üretildiğini ya da damgalamadan önce ne olduğunu ise göstermez. Değerini en yüksek kılan şey, edinmeye en yakın anda uygulanmasıdır. Elektronik sertifika hizmet sağlayıcıları, faaliyete geçmeden önce Kanun'da sayılan güvenlik şartlarını sağladıklarını göstermek ve faaliyetleri boyunca kamu denetimine tabi olmak zorundadır.
Güvenli elektronik imza ve KEP: Kimlik ile bütünlüğü birlikte bağlamak
Tanımdaki son unsur, yani sonradan değişiklik yapılıp yapılmadığının tespiti, hash mantığının hukuka taşınmış hâlidir. İmzalı bir PDF'te imzadan sonra tek bir karakter değiştirilirse, imza doğrulama aracı bunu "imzadan sonra değiştirilmiş" diye gösterir. Bu nedenle güvenli elektronik imzalı bir belgede tartışma çoğunlukla içeriğin değişip değişmediğinden, sertifikanın geçerliliğine ve imzalayanın temsil yetkisine kayar.
Kayıtlı elektronik posta (KEP) ise bir iletinin gönderilmesini ve teslimini, sağlayıcının tuttuğu kayıtlarla belgeleyen bir sistemdir. TTK m.18/3, tacirler arasında temerrüde düşürme, fesih ve sözleşmeden dönmeye ilişkin ihbar ve ihtarların noter aracılığıyla, taahhütlü mektupla, telgrafla veya güvenli elektronik imza kullanılarak KEP ile yapılacağını düzenler. Sıradan e-postada "almadım" itirazı başlık analizine ve sunucu kayıtlarına dayanırken, KEP'te bu tartışma büyük ölçüde baştan kapanır.
| Araç | Neyi gösterir? | Neyi göstermez? | Ne zaman anlamlı? |
|---|---|---|---|
| Hash değeri | Hesaplama anından sonra değişiklik olmadığını | Oluşturma zamanını, yazarı, doğruluğu | Her dijital delilde, edinme anında |
| Zaman damgası | Hash'e sahip içeriğin en geç damgalama anında var olduğunu | Oluşturma anını, yazarı | Uzun sürecek, değeri yüksek dosyalarda |
| Güvenli elektronik imza | İmzalayanın kimliğini ve imzadan sonra değişiklik olup olmadığını | İçeriğin doğru olduğunu, imzalayanın yetkisini | Sözleşme, tutanak, beyan gibi irade açıklamalarında |
| KEP | Gönderim ve teslim anını ve iletilen içeriği | İçeriğin hukuki sonucunu | İhtar, ihbar, fesih gibi süre başlatan bildirimlerde |
E-posta başlığı analizi: Bir iletinin gerçek yolculuğu
E-posta başlığı (header), iletinin hangi sunuculardan, hangi sırayla ve hangi saatlerde geçtiğini ve gönderen alan adı için yapılan kimlik doğrulamalarının sonuçlarını gösteren teknik satırlardır. Ekranda gördüğünüz gönderen adı ve tarih bu satırların en kolay değiştirilebilen kısmıdır; özgünlük tartışması asıl olarak başlığın geri kalanında çözülür.
Bir iletinin başlığında onlarca satır bulunabilir; bunların bir kısmı gönderen tarafın, bir kısmı yoldaki sunucuların, bir kısmı da alıcı tarafın sistemleri tarafından yazılır. Kimin yazdığı, satırın güvenilirliğini belirler: Gönderenin kendi istemcisinin yazdığı bir alan, gönderen tarafından kolayca değiştirilebilir. Alıcı tarafın sunucusunun eklediği bir satırı ise gönderen değiştiremez.
| Başlık alanı | Ne gösterir? | Kim yazar? | Güvenilirliği |
|---|---|---|---|
| From | Görünen ad ve gönderen adresi | Gönderen istemci | Düşük; tek başına kolay taklit edilir |
| Reply-To | Yanıtların gideceği adres | Gönderen istemci | From'dan farklıysa dikkat gerektirir |
| Return-Path | Zarf göndericisi, yani iade adresi | Son alıcı sunucu, zarf bilgisinden | SPF denetimi bu alan adına göre yapılır |
| Date | İletinin yazıldığı iddia edilen an | Gönderen istemci | Düşük; gönderen cihazın saatine bağlıdır |
| Received | Her sunucunun iletiyi kimden ve ne zaman aldığı | Yoldaki her sunucu | Alıcı tarafın kendi sunucularının yazdığı satırlar en güvenilirdir |
| Message-ID | İletinin tekil kimliği | Gönderen sistem | Karşı tarafın posta kutusunda aranabilir |
| In-Reply-To ve References | Yazışma zincirindeki önceki iletiler | Gönderen istemci | Zincirin sırasını ve bütünlüğünü doğrular |
| DKIM-Signature | Gönderen alan adının kriptografik imzası | Gönderen sunucu | Yüksek; içerik değişirse doğrulama bozulur |
| Authentication-Results | SPF, DKIM ve DMARC denetimlerinin sonucu | Alıcı sunucu | Alıcı sistemin teslim anındaki değerlendirmesi |
| ARC alanları | Yönlendirme sırasında doğrulama sonuçlarının taşınması | Ara sunucular | Yönlendirilmiş iletilerde önem kazanır |
Received satırları aşağıdan yukarıya okunur
Her sunucu iletiyi aldığında başlığın en üstüne yeni bir Received satırı ekler. Bu yüzden iletinin yolculuğu aşağıdan yukarıya okunur: En alttaki satır iletinin çıkış noktasına en yakın sunucuyu, en üstteki satır alıcının posta kutusuna teslimi gösterir. Her satırda, iletinin hangi sunucudan alındığı, hangi sunucu tarafından alındığı ve saat dilimiyle birlikte tarih ve saat yer alır.
Analizde iki şeye bakılır. Birincisi zincirin kendi içinde tutarlı olmasıdır: Bir satırdaki "kimden aldım" bilgisi, bir alttaki satırın "ben kimim" bilgisiyle örtüşmelidir ve saatler, saat dilimi dönüşümü yapıldıktan sonra mantıklı bir sıra izlemelidir. İkincisi güven sınırıdır: Alıcı şirketin kendi sunucularının eklediği satırlar güvenilirdir. Bunların altında kalan satırlar ise gönderen tarafından taklit edilebilir; bu yüzden analiz, güvenilir ilk satırın "iletiyi şu adresten aldım" dediği noktadan başlar.
SPF, DKIM ve DMARC: Alan adının kimliği
Gönderen alan adının kimliğini sınayan üç mekanizma vardır. SPF (Sender Policy Framework), iletiyi gönderen sunucunun, zarf göndericisindeki alan adı adına e-posta göndermeye yetkili olup olmadığını denetler. DKIM (DomainKeys Identified Mail), gönderen sunucunun iletiye eklediği kriptografik imzadır; imza, iletinin gövdesinin özetini ve seçilmiş başlık alanlarını kapsar. DMARC ise ekranda görünen From adresindeki alan adının SPF veya DKIM ile doğrulanan alan adıyla uyumlu olup olmadığına bakar ve alan adı sahibinin uyumsuz iletiler için belirlediği politikayı uygular.
Delil açısından en değerli olanı DKIM'dir, çünkü bir tür bütünlük mührü işlevi görür. Gövde veya imzaya dahil edilen başlıklar teslimden sonra değiştirilirse imza doğrulanamaz. Ancak bir sınırı vardır: Doğrulama, gönderen alan adının alan adı sisteminde (DNS) yayımladığı açık anahtara dayanır ve alan adı sahipleri bu anahtarları zaman içinde değiştirebilir. Aylar sonra anahtar kaldırılmışsa imza artık doğrulanamaz. Bu yüzden tartışmalı bir iletinin DKIM doğrulaması mümkün olan en erken anda yapılmalı, sonucu ve o tarihteki DNS kaydı raporda belgelenmelidir.
Orijinal ileti nasıl korunur?
Bir e-postayı avukatınıza "ilet" (forward) seçeneğiyle göndermek, orijinal iletiyi değil sizin sunucunuzdan çıkan yeni bir iletiyi gönderir; orijinalin başlık satırları büyük ölçüde kaybolur. E-postayı yazdırmak veya PDF'e dönüştürmek ise başlığın tamamını siler. Doğru yöntem, iletinin ham hâlini dosya olarak dışa aktarmaktır.
Webmail hizmetlerinin çoğunda ileti menüsünde orijinali gösterme veya ileti kaynağını görüntüleme seçeneği bulunur ve ileti buradan .eml dosyası olarak indirilebilir. Masaüstü e-posta programlarında ileti, başlıklarıyla birlikte .eml ya da .msg dosyası olarak kaydedilebilir. Kurumsal hesaplarda ise yöneticinin dışa aktarma ve arama araçlarıyla, kimin hangi ölçütle aradığını gösteren bir kayıt eşliğinde toplama yapılır. Her durumda dışa aktarılan dosyanın hash değeri hesaplanır ve posta kutusundaki asıl ileti silinmez.
Başlık analizinin sınırları
Başlık analizi iletinin hangi sistemden çıktığını gösterebilir, ama klavyenin başında kimin oturduğunu göstermez. Ele geçirilmiş bir hesaptan gönderilen ileti, bütün kimlik doğrulama denetimlerinden geçer; çünkü gerçekten o hesabın sistemi tarafından gönderilmiştir. Bu durumda tartışma, hesabın oturum kayıtlarına, hangi IP adresinden ve hangi cihazdan oturum açıldığına kayar.
Bazı büyük e-posta hizmetleri, web arayüzünden gönderilen iletilerde göndericinin IP adresini başlığa yazmaz. Sanal özel ağ (VPN) kullanımı da görünen adresi değiştirir. Bir IP adresi bir bağlantıyı gösterir, bir kişiyi değil; aynı ağı paylaşan bir ofis, bir aile ya da halka açık bir kablosuz ağ, tek bir adresin arkasında çok sayıda kişi olabileceğini hatırlatır.
Metadata analizi: Belge, dosya sistemi ve işletim sistemi izleri
Metadata (üst veri), bir dosyanın içeriği dışında kalan ve onu kimin, hangi yazılımla, ne zaman oluşturup değiştirdiğine dair ipuçları taşıyan veridir. Tek başına kesin kanıt değildir, çünkü değiştirilebilir ve yanlış ayarlanmış bir sistemin hatasını da taşır; ama birbirinden bağımsız katmanlardaki üst veriler birbirini tutuyorsa güçlü bir köken ve zaman göstergesine dönüşür.
Fotoğraf ve videolardaki EXIF alanlarını, çekim zamanını ve konum bilgisini fotoğraf ve video kaydının hukuki değeri rehberinde ele aldık. Bu bölüm belgelerin, dosya sisteminin ve işletim sisteminin bıraktığı izler üzerinde duruyor; ticari, kurumsal ve ortaklık uyuşmazlıklarında tartışmanın çoğu bu katmanlarda geçer.
| Katman | Örnek alanlar | Neyi gösterebilir? | Zayıf yanı |
|---|---|---|---|
| Office belgesi içi | Oluşturan, son kaydeden, oluşturma ve değiştirme tarihi, revizyon sayısı, toplam düzenleme süresi, şablon, uygulama sürümü | Belgenin hangi hesapla, kaç oturumda, hangi şablondan hazırlandığı | Kullanıcı adı bilgisayardaki ayara bağlıdır; araçlarla değiştirilebilir |
| PDF belgesi içi | Üreten yazılım, oluşturma ve değiştirme tarihi, belge kimlikleri, artımlı kayıtlar | Dönüştürme zinciri, sonradan yapılan eklemeler | Yeniden kaydetme ve yazdırma bilgileri sıfırlayabilir |
| Dosya sistemi | Oluşturma, değiştirme, erişim ve kayıt değişikliği zamanları | Dosyanın o diskteki yaşam öyküsü | Kopyalama ve arşivleme değiştirir; son erişim tarihi çoğu zaman güvenilmez |
| Dosya sistemi günlükleri | Değişiklik günlüğü kayıtları | Oluşturma, yeniden adlandırma ve silme olaylarının sırası | Sınırlı süre tutulur, üzerine yazılır |
| İndirme izi | Dosyanın indirildiği adresi taşıyan ek bilgi | Dosyanın hangi siteden veya hizmetten geldiği | Bazı taşıma yöntemlerinde kaybolur |
| İşletim sistemi kayıtları | Son açılan dosyalar, kısayol dosyaları, harici bellek bağlantı geçmişi, oturum açma kayıtları | Dosyanın hangi cihazda, hangi bellekten açıldığı | Yorumu uzmanlık ister; sistem ayarlarına bağlıdır |
Office belgelerinde iz: Revizyon, düzenleme süresi ve şablon
Güncel Word, Excel ve PowerPoint dosyaları aslında içinde XML dosyaları bulunan sıkıştırılmış paketlerdir. Paketin içindeki özellik dosyaları; belgeyi oluşturan ve en son kaydeden kullanıcı adını, oluşturma ve son değiştirme zamanını, kaç kez kaydedildiğini gösteren revizyon sayısını, toplam düzenleme süresini, kullanılan şablonu ve uygulama sürümünü taşır. Word ayrıca her düzenleme oturumuna rastgele bir kimlik atar; bu kimlikler, iki belgenin ortak bir kaynaktan türeyip türemediğini anlamaya yardımcı olabilir.
Bu alanların değeri, çelişki yakalamaktır. "Toplantıdan hemen sonra yazıldı" denilen bir tutanağın toplam düzenleme süresi iki dakika, revizyon sayısı bir ise ve belge bir başka dosyadan kopyalanarak oluşturulmuşsa, bu hikâyeyi tek başına çürütmez ama soru işareti doğurur. İddia edilen tarihte henüz kullanılmayan bir şablonun, logonun ya da yazılım sürümünün izi ise daha güçlü bir zaman çelişkisidir.
PDF'te artımlı kayıt ve dönüştürme zinciri
PDF dosyalarında üst veri iki yerde tutulabilir: belge bilgi sözlüğünde ve XMP denilen ayrı bir veri bloğunda. Üreten yazılım alanı, PDF'in doğrudan bir kelime işlemciden mi, bir tarayıcıdan mı, yoksa "PDF'e yazdır" işleviyle mi oluşturulduğunu gösterebilir. İki alan arasındaki tutarsızlık, dosyanın sonradan bir araçla düzenlendiğine işaret edebilir.
PDF'in bir başka özelliği artımlı kayıttır. Bazı programlar bir PDF'te değişiklik yapıldığında dosyayı baştan yazmak yerine değişiklikleri dosyanın sonuna ekler. Bu durumda dosyanın önceki sürümleri teknik incelemeyle görünür hâle gelebilir. İmzalı PDF'lerde de imzanın kapsadığı bayt aralığından sonra eklenen her şey doğrulama aracında ayrıca görünür.
Dosya sistemi tarihleri ve kopyalama paradoksu
Dosya sistemleri her dosya için birkaç zaman bilgisi tutar: oluşturma, son değiştirme, son erişim ve dosya kaydının değiştirilme zamanı. Bunlar kolayca yanlış okunur. Örneğin Windows'ta bir dosya başka bir diske kopyalandığında, yeni kopyanın oluşturma tarihi kopyalama anı olur, ama son değiştirme tarihi orijinalden taşınır. Ortaya "oluşturulmadan önce değiştirilmiş" görünen bir dosya çıkar. Bu tablo sahtecilik değil, kopyalamanın olağan izidir.
Windows'un dosya sistemi her dosya için iki ayrı zaman kümesi tutar ve zaman bilgisini değiştirmeye yarayan araçlar çoğu zaman bunlardan yalnızca birini değiştirir. İki küme ve dosya sisteminin değişiklik günlüğü arasındaki tutarsızlık, bilirkişinin bilinçli tarih değişikliğinden şüphelendiği tipik noktadır. Bu karşılaştırma uzmanlık ister ve yalnızca adli kopya üzerinde anlamlıdır; dosyayı açıp kaydetmek ya da başka bir klasöre taşımak bu izleri kendiliğinden değiştirebilir.
İndirme izi, harici bellek ve son açılan dosyalar
İşletim sistemleri internetten indirilen dosyalara, kaynağına ilişkin ek bilgiler ekler. Windows'ta bu bilgi dosyaya bağlı ayrı bir veri akışında, macOS'ta ise dosyanın genişletilmiş özniteliklerinde tutulur ve çoğu zaman dosyanın indirildiği adresi içerir. "Bu belgeyi rakibe ben göndermedim, internette buldum" savunmasının sınanmasında bu iz değerli olabilir.
Harici bellek bağlantı geçmişi, kısayol dosyaları ve son açılan dosyalar listeleri ise bir dosyanın hangi bellekten, hangi tarihte açıldığını gösterebilir. Bu kayıtlar özellikle kurumsal soruşturma dosyalarında, bir belgenin şirket bilgisayarından kişisel bir belleğe aktarılıp aktarılmadığı sorusunda merkezî rol oynar. Yalnızca şirkete ait ve kullanım kuralları çalışana önceden bildirilmiş cihazlarda, iş hukuku ve KVKK sınırları içinde incelenebilirler.
Metadata çeliştiğinde ne düşünülmeli?
Üst verinin eksik ya da tutarsız olması tek başına sahtelik anlamına gelmez. Eşitleme hizmetleri, biçim dönüştürmeleri, e-posta sistemlerinin ekleri yeniden kodlaması, saat dilimi ayarları ve yazılım güncellemeleri masum tutarsızlıklar üretir. İyi bir rapor bu açıklamaları tek tek sınar ve hangilerinin elendiğini yazar.
Tersi de geçerlidir: Kusursuz görünen bir üst veri, belgenin gerçek olduğunu kanıtlamaz. Bilinçli bir sahtecilik, belge içi alanları tutarlı hâle getirebilir; ama dosya sistemi günlükleri, bulut sürüm geçmişi, e-posta sunucusunun gönderim kaydı ve yedekler gibi sahtecinin kontrol etmediği katmanların hepsini aynı anda tutarlı kılmak çok daha zordur. Bağımsız kaynak ilkesi metadata analizinde de geçerlidir.
Bulut verisi ve sunucu kayıtları: Cihazda olmayan delil
Bulut verisi, bir hizmet sağlayıcının sunucusunda tutulan içerik ile o içeriğe ilişkin sürüm, paylaşım, oturum ve erişim kayıtlarıdır. Delil değeri yüksektir, çünkü zaman bilgisi kullanıcının cihaz saatinden bağımsız olarak üretilir; ama verinin kime ait olduğuna göre edinme yolu tamamen değişir.
Bulutun delil açısından asıl zenginliği içerikte değil, içerik etrafındaki kayıtlardadır. Bir belgenin sürüm geçmişi, belgenin hangi tarihte hangi hesap tarafından değiştirildiğini; paylaşım kayıtları, kime ne zaman erişim verildiğini; oturum kayıtları ise hesaba hangi cihazdan ve hangi IP adresinden girildiğini gösterebilir. Bu kayıtların hiçbiri kullanıcının bilgisayarında değil, sağlayıcının sunucusunda üretilir.
| Kaynak | Ne içerir? | Kim, nasıl edinebilir? | Dikkat edilecek nokta |
|---|---|---|---|
| Kendi kişisel hesabınız | İçerik, sürüm geçmişi, oturum ve cihaz listesi | Hesap sahibi; sağlayıcının veri indirme aracı | İndirme tarihi, kapsam ve arşiv hash'i kaydedilir |
| Şirket hesapları | İleti izleme, denetim kayıtları, paylaşım geçmişi | Şirketin yetkili yöneticisi; şirket politikası ve aydınlatma çerçevesinde | Kayıtların saklama süresi lisansa ve ayara bağlıdır |
| Karşı tarafın veya üçüncü kişinin hesabı | İçerik ve kayıtlar | Yalnızca mahkeme veya savcılık kanalıyla | Kendi başına erişim TCK m.243 vd. kapsamında suç oluşturabilir |
| Türkiye'de hizmet veren yer ve erişim sağlayıcıların trafik bilgisi | Bağlantı zamanı, IP adresi, hizmet kayıtları | Yargı mercilerinin talebiyle | 5651 m.5 ve m.6'daki saklama süreleri |
| Yurt dışındaki sağlayıcılar | İçerik ve abone bilgileri | Uluslararası adli yardım ve sağlayıcının resmî talep süreçleri | Uzun sürer; içerik çoğu zaman yalnızca ceza soruşturmasında |
Kendi bulut verinizi indirirken
Büyük hizmet sağlayıcıların çoğu, hesap sahibine verilerinin bir kopyasını indirme imkânı tanır: Google'ın Takeout aracı, Apple'ın veri ve gizlilik sayfası, Meta'nın "Bilgilerini indir" aracı ve Microsoft'un gizlilik paneli bunların örnekleridir. Bu araçlarla alınan arşiv, sağlayıcının kendi biçiminde hazırlandığı için bilirkişi açısından değerlidir.
İndirme sırasında dört şey not edilmelidir: talebin ve indirmenin tarihi ve saati, hangi hizmetlerin ve hangi tarih aralığının seçildiği, arşiv dosyalarının adları ve hash değerleri ile indirmeyi kimin, hangi cihazla yaptığı. Arşiv bir kez alındıktan sonra açılıp üzerinde çalışılacaksa, bu çalışma her zaman bir kopya üzerinde yapılır.
Kurumsal kayıtlar: Denetim günlüğünün ömrü kısadır
Kurumsal e-posta ve ortak depolama hizmetleri, ileti izleme ve denetim kayıtları tutar: Hangi ileti ne zaman kime gitti, hangi dosya kim tarafından indirildi, hangi hesap hangi IP adresinden oturum açtı? Bu kayıtlar şirketin kendi sistemine ait olduğu için, şirket politikası ve çalışanlara yapılan aydınlatma çerçevesinde şirket tarafından alınabilir.
Ama bu kayıtların saklama süresi çoğu zaman sınırlıdır ve lisans türüne ve ayarlara göre değişir. Bir sızıntı şüphesi doğduğunda ilk haftalarda yapılması gerekenlerden biri, ilgili kayıtların dışa aktarılması ve saklama ayarlarının uzatılmasıdır. Yukarıdaki temsili senaryoda tedarikçinin elinden kaçan şey tam olarak budur.
Saat dilimi: UTC ile Türkiye saati
Sunucu kayıtlarının çoğu eşgüdümlü evrensel zamana (UTC) göre tutulur; Türkiye 2016 sonbaharından bu yana yıl boyunca UTC+3 saatini kullanmaktadır. Bir e-posta başlığında "+0000" ile biten bir saat ile "+0300" ile biten bir saat arasındaki üç saatlik fark, dikkatsiz bir okumada "ileti gönderilmeden alınmış" gibi görünebilir. 2016 öncesine ait kayıtlarda ise yaz ve kış saati uygulaması nedeniyle fark dönemine göre değişir.
İyi bir raporda her zaman bilgisinin hangi saat diliminde olduğu ve nasıl dönüştürüldüğü açıkça yazılır. Farklı kaynaklardan gelen kayıtlar tek bir zaman çizelgesinde birleştirilirken, her kaynağın saatinin neye göre ayarlandığı da sorulur. Ağ üzerinden saat eşitlemesi yapan bir sunucu ile saati elle ayarlanmış eski bir kayıt cihazı aynı güvenilirlikte değildir.
Trafik bilgisi ve yurt dışı sağlayıcılar
5651 sayılı Kanun, yer sağlayıcıların sağladıkları hizmetlere ilişkin trafik bilgilerini bir yıldan az ve iki yıldan fazla olmamak üzere, erişim sağlayıcıların ise altı aydan az ve iki yıldan fazla olmamak üzere yönetmelikte belirlenecek süre kadar saklamasını ve bu bilgilerin doğruluğunu, bütünlüğünü ve gizliliğini sağlamasını öngörür. Bu kayıtlar, bir IP adresinin belirli bir anda hangi aboneye ait olduğu gibi soruların cevabıdır ve yalnızca yargı mercilerinin talebiyle alınabilir.
Hizmet sağlayıcı yurt dışındaysa süreç uzar. Türkiye'nin de taraf olduğu Avrupa Konseyi Siber Suç Sözleşmesi gibi araçlar ve uluslararası adli yardım kanalları kullanılır; birçok sağlayıcı kolluk ve savcılıktan gelen veri koruma ve veri talep başvuruları için ayrı süreçler işletir. İçerik verisine erişim çoğu zaman yalnızca ceza soruşturmasında ve uzun bir takvimle mümkündür. Bu nedenle hukuk davalarında taraflar, mümkün olan her veriyi kendi hesaplarından ve kendi cihazlarından korumaya öncelik vermelidir.
Ekran görüntüsü mü, orijinal veri mi? Kaybolan katmanlar
Ekran görüntüsü, verinin ekrandaki görünümünün bir resmidir; orijinal verinin kendisi değildir. Ekranda görünen içeriği gösterir, ama köken, bütünlük ve zaman sorularını cevaplayan teknik katmanları geride bırakır.
| Katman | Orijinal veride | Ekran görüntüsünde |
|---|---|---|
| Gönderen kimliği | Adres, numara, hesap kimliği, başlık satırları | Rehberdeki ad veya görünen ad |
| Zaman | Sunucu ve cihaz zaman kayıtları, saat dilimi | Ekranda biçimlendirilmiş saat |
| Bütünlük | DKIM, elektronik imza, kaynak dosyanın hash'i | Yalnızca görüntü dosyasının hash'i |
| Bağlam | Tam yazışma zinciri, ekler, önceki ve sonraki iletiler | Yalnızca kadraja giren kısım |
| Düzenleme ve silme izi | "Düzenlendi" ibaresi, sürüm geçmişi, silme kayıtları | Görünmez |
| Bilirkişi incelemesi | Kaynağa ulaşılarak yapılabilir | Çoğu zaman yalnızca görüntünün kendisi incelenebilir |
Tablonun son satırı uygulamada en çok hissedilen farktır. Bilirkişiye yalnızca ekran görüntüsü verildiğinde, rapor çoğu zaman görüntüde düzenleme izine rastlanıp rastlanmadığıyla sınırlı kalır. Görüntünün gösterdiği iletinin gerçekten iddia edilen hesaptan gelip gelmediği ise kaynağa ulaşılmadan cevaplanamaz.
Ekran görüntüsü ne zaman yine de işe yarar?
Ekran görüntüsünün değeri, kalıcı bir kaynağın bulunmadığı ya da kaynağın kaybolma riski taşıdığı durumlarda ortaya çıkar: 24 saat sonra kaybolan bir paylaşım, sonradan değiştirilebilecek bir web sayfası, bir uygulamanın yalnızca ekranda gösterdiği bir bildirim. Bu durumlarda ekran görüntüsü tek başına değil; sayfa adresi, hesabın değişmeyen sayısal kimliği, erişim saati, mümkünse kesintisiz ekran kaydı ve bir web arşivi kopyasıyla birlikte alınmalıdır.
Mesajlaşma uygulamalarında ekran görüntüsü, sohbet dışa aktarma, yedek ve cihazın kendisi arasındaki farkı WhatsApp mesajlarının delil değerini anlattığımız rehberde ayrıntılı olarak ele aldık. Oradaki ilke dijital delilin her türü için geçerlidir: Ekran görüntüsü okumayı kolaylaştıran bir yardımcıdır; delilin ağırlığını ise orijinal veri taşır.
PDF'e yazdırmak ve iletmek de bir tür ekran görüntüsüdür
Bir e-postayı veya web sayfasını "PDF olarak yazdır" işleviyle kaydetmek, ekran görüntüsünden daha düzenli görünür; ama teknik olarak aynı sonucu doğurur. Ortaya çıkan PDF yeni bir dosyadır. Üst verisi yazdırma anını ve yazdırma yazılımını gösterir, orijinalin başlık satırlarını, imzasını ve eklerinin orijinallerini taşımaz.
İletme (forward) ve kopyala-yapıştır da aynı kategoridedir. Bunlar içeriği taşır ama içeriğin kanıt değerini oluşturan bağlamı taşımaz. Pratik kural basittir: Sunumda kullanacağınız her çıktının yanında, onun türetildiği orijinal dosyanın da dokunulmadan saklandığından emin olun.
Bilirkişi süreci: HMK m.266 vd. ile dijital inceleme nasıl işler?
Dijital bir delilin gerçekliği veya içeriği hukuk dışında özel ya da teknik bilgi gerektirdiğinde mahkeme HMK m.266 uyarınca bilirkişiye başvurur. Bilirkişi, bölge kurullarının hazırladığı listelerden ilgili uzmanlık alanına göre seçilir, mahkemenin sevk ve idaresi altında çalışır ve hukuki değerlendirme yapamaz; taraflar sürece ret, itiraz ve uzman görüşü araçlarıyla katılır.
HMK m.266, genel bilgi veya tecrübeyle ya da hâkimlik mesleğinin gerektirdiği hukuki bilgiyle çözülebilecek konularda bilirkişiye başvurulamayacağını da söyler. Ayrıca hukuk öğrenimi görmüş kişiler, hukuk alanı dışında ayrı bir uzmanlığa sahip olduklarını belgelendirmedikçe bilirkişi olarak görevlendirilemez. Dijital delil açısından bu, adli bilişim gibi teknik bir uzmanlık alanından bilirkişi seçilmesinin önemini gösterir.
| Aşama | Dayanak | Tarafın dikkat edeceği nokta |
|---|---|---|
| Bilirkişiye başvurma kararı | HMK m.266 | Teknik sorunun açık ve sınırlı biçimde tanımlanması |
| Sayı ve seçim | HMK m.267, m.268; 6754 sayılı Bilirkişilik Kanunu | Uzmanlık alanının dijital incelemeye uygunluğu; gerekirse gerekçeli olarak tek sayıda kurul |
| Yasaklılık ve ret | HMK m.272 | Ret talebi, sebebin öğrenilmesinden itibaren en geç bir hafta içinde |
| İnceleme | HMK m.276–278 | Bilirkişinin görevi bizzat yapması; materyalin eksiksiz teslimi; tarafın bilgisine mahkemenin uygun bulmasıyla başvurulması |
| Rapor süresi | HMK m.274 | En çok üç ay; bilirkişinin talebi ve gerekçeli kararla en çok üç ay uzatma; basit yargılamada bu süreler iki ay |
| Raporun içeriği | HMK m.279 | Gözlem ve inceleme konusu vakıalar, gerekçe ve sonuç; hukuki nitelendirme yasağı |
| Rapora itiraz | HMK m.281 | Tebliğden itibaren iki hafta; teknik çalışma gerekiyorsa süre içinde başvuruyla bir defaya mahsus en çok iki hafta ek süre |
| Uzman görüşü | HMK m.293 | Tarafın kendi aldığı bilimsel mütalaa; uzman çağrıldığı duruşmaya geçerli özrü olmadan gelmezse rapor değerlendirilmez |
Bilirkişiye doğru soruyu sormak
Bilirkişi raporunun kalitesi, büyük ölçüde mahkemenin bilirkişiye yönelttiği sorulara bağlıdır. "Dosyadaki e-postalar gerçek mi?" gibi geniş bir soru, geniş ve çoğu zaman kaçamak bir cevap üretir. Avukatınızın mahkemeye önerebileceği soruların teknik olarak sınırlı ve cevaplanabilir olması gerekir. Dijital delilde tipik sorular şöyledir:
- Tartışmalı iletinin başlık bilgileri, gönderen olduğu iddia edilen alan adının e-posta altyapısıyla ve önceki iletilerle uyumlu mu; DKIM imzası doğrulanabiliyor mu?
- Belgenin üst verisindeki oluşturma ve değiştirme bilgileri; dosya sistemi kayıtlarıyla, bulut sürüm geçmişiyle ve belgenin gönderildiği e-postanın tarihiyle tutarlı mı?
- İncelenen dosyaların ve imajların hash değerleri, edinme kayıtlarındaki değerlerle eşleşiyor mu?
- İlgili tarih aralığında cihazda veya hesapta silme, toplu yeniden adlandırma ya da zaman bilgisini değiştirmeye yönelik bir işlem izi var mı?
- Kayıtların saati hangi kaynağa göre ayarlıydı ve saat dilimi dönüşümü nasıl yapıldı?
- Tespit edilen izler, eşitleme, biçim dönüştürme veya otomatik güncelleme gibi başka bir açıklamayla da uyumlu olabilir mi?
Altıncı soru özellikle önemlidir. İyi bir adli bilişim raporu yalnızca bir hipotezi doğrulamaz; rakip açıklamaları da sınar ve hangilerinin neden elendiğini gösterir. Bu soruyu baştan sormak, raporun karşı tarafın itirazlarına dayanıklı olmasını sağlar.
Kontrol listesi: Bir dijital inceleme raporunu okurken
- [ ] İncelenen materyalin listesi, tekil numaraları ve hash değerleri raporda yer alıyor.
- [ ] Edinme yöntemi, kullanılan araçların adı ve sürümü, işlemin tarihi ve saati yazılı.
- [ ] Analize başlamadan önce hash doğrulamasının yapıldığı ve sonucu belirtilmiş.
- [ ] Gözlenen bulgular ile bunlardan yapılan çıkarımlar ayrı ayrı gösterilmiş.
- [ ] Alternatif açıklamalar sınanmış ve neden elendikleri açıklanmış.
- [ ] Saat dilimi ve saat kaynağı açıkça belirtilmiş.
- [ ] İncelenemeyen alanlar ve yöntemin sınırları yazılmış.
- [ ] Başka bir uzmanın aynı adımları tekrar edebileceği ayrıntı düzeyinde.
- [ ] Hukuki nitelendirme yapılmamış; sorular teknik düzeyde cevaplanmış.
Bu listede eksik bulduğunuz her madde, HMK m.281 kapsamındaki itirazın somut gerekçesi olabilir. İtiraz süresi tebliğden itibaren iki haftadır ve teknik bir çalışma gerektiğinde ek süre de bu iki hafta içinde istenmelidir. Bu takvim, rapor tebliğ edildiği gün avukatınızla birlikte not edilmelidir.
Uzman görüşü: Sürecin öbür kanadı
HMK m.293, tarafların dava konusu olayla ilgili olarak uzmanından bilimsel mütalaa alabileceğini düzenler. Uzman görüşü mahkemenin bilirkişisinin yerini tutmaz; ama iki noktada belirleyici olabilir. Birincisi, bilirkişiye sorulacak soruların teknik olarak doğru kurulmasıdır. İkincisi, bilirkişi raporundaki yöntem eksikliklerinin somut olarak gösterilmesidir. Hâkim, talep üzerine veya resen uzmanı dinleyebilir; uzman çağrıldığı duruşmaya geçerli bir özrü olmadan gelmezse raporu değerlendirilmez.
Ceza yargılamasında dijital delil: CMK m.134 ve bilirkişi
Ceza soruşturmasında şüphelinin kullandığı bilgisayar, program ve kütüklerde arama, kopyalama ve el koyma, CMK m.134'teki koşullarla hâkim kararıyla, gecikmesinde sakınca bulunan hâllerde Cumhuriyet savcısının kararıyla yapılır; teknik inceleme ise CMK m.63 vd. uyarınca bilirkişiye yaptırılır. Özel kişiler bu yetkileri kullanamaz.
CMK m.134, somut delillere dayanan kuvvetli şüphe sebeplerinin varlığını ve başka surette delil elde etme imkânının bulunmamasını arar. Savcının kararı yirmi dört saat içinde hâkim onayına sunulur; hâkim de en geç yirmi dört saat içinde karar verir, aksi hâlde çıkarılan kopyalar derhâl imha edilir. El koyma sırasında sistemdeki bütün verilerin yedeği alınır ve bu yedekten bir kopya şüpheliye veya vekiline verilerek tutanağa bağlanır. Bu son kural, savunmanın kendi uzmanıyla aynı veriyi bağımsız olarak inceleyebilmesinin dayanağıdır ve hash değerleri, iki tarafın aynı veriye baktığının teknik kanıtıdır.
Ceza yargılamasında bilirkişi rejimi hukuk yargılamasına paraleldir. CMK m.63, çözümü uzmanlık, özel veya teknik bilgi gerektiren hâllerde bilirkişiye başvurulacağını; CMK m.67/3, bilirkişinin hukuki nitelendirme ve değerlendirme yapamayacağını düzenler. CMK m.67/5 uyarınca taraflara yeni bilirkişi incelemesi isteme ve itirazlarını bildirme için süre verilir. CMK m.67/6 ise savcı, katılan, şüpheli veya sanık ve müdafiinin uzmanından bilimsel mütalaa alabileceğini öngörür; m.68/3'e göre mütalaayı hazırlayan uzman istem üzerine duruşmada dinlenebilir.
Bir IP adresi bir kişi değildir
Ceza dosyalarında dijital delilin en sık tartışılan noktası, verinin bir kişiye bağlanmasıdır. Bir IP adresi, belirli bir anda belirli bir aboneliğe ait bağlantıyı gösterir. O bağlantıyı aynı evde yaşayan başka biri, ofisteki bir çalışma arkadaşı, şifresi paylaşılmış bir kablosuz ağın komşusu ya da ele geçirilmiş bir cihaz da kullanmış olabilir.
Şüpheden sanığın yararlanması ilkesi, bu bağlantı boşluğunu ceza yargılamasında özellikle belirleyici kılar. Dijital iz, cihazın fiziksel olarak kimde olduğu, oturumun hangi hesapla açıldığı, aynı anda başka bir yerde bulunulup bulunulmadığı ve içeriğin yalnızca o kişinin bilebileceği ayrıntılar taşıyıp taşımadığı gibi diğer delillerle birleştiğinde anlam kazanır.
Aynı veri, iki ayrı dosya
Bir dijital delil çoğu zaman hem ceza hem hukuk dosyasında karşımıza çıkar: Bir sızıntı soruşturması ile tazminat davası, bir dolandırıcılık şikâyeti ile alacak davası gibi. Ceza dosyasındaki el koyma tutanakları ve bilirkişi raporları, avukatınızın talebiyle hukuk dosyasına getirtilebilir; ama hukuk hâkimi bu belgeleri kendi dosyasındaki diğer delillerle birlikte değerlendirir.
İki dosyada aynı verinin farklı kopyalarının dolaşması, hash listesinin değerini artırır. Ceza dosyasındaki yedeğin değeri ile sizin elinizdeki dışa aktarmanın değeri farklı düzeylerde olabilir; ama öğe düzeyinde alınmış hash değerleri, iki dosyadaki iletinin aynı ileti olduğunu göstermenin en sade yoludur.
Sık yapılan hatalar
Dijital delillerdeki hataların çoğu kötü niyetten değil, verinin "zaten bilgisayarda duruyor" diye sıradan bir dosya gibi ele alınmasından kaynaklanır. Aşağıdaki hatalar, sağlam bir dijital delilin ağırlığını en sık aşındıran davranışlardır.
- E-postayı avukata iletmek ve sonra orijinali silmek. İletme işlemi başlık satırlarını korumaz; orijinal silinince köken tartışmasının dayanağı da gider.
- E-postayı veya web sayfasını PDF'e yazdırıp orijinal saymak. Yazdırılan dosya yeni bir dosyadır ve yazdırma anının üst verisini taşır.
- Belgeyi "bir bakayım" diye açıp kaydetmek. Otomatik kaydetme özelliği bile son değiştirme tarihini ve son kaydeden kullanıcı bilgisini değiştirebilir.
- Bulut klasöründeki dosyaları düzenlemek için taşımak, yeniden adlandırmak veya silmek. Sürüm geçmişi ve paylaşım kayıtları bu işlemlerle karışır.
- Hash değerini yalnızca arşiv paketi için almak. Yeniden dışa aktarmada paketin değeri değişebilir; öğe düzeyinde liste olmadan bütünlük savunması zayıflar.
- Saat dilimini belirtmemek. UTC ile Türkiye saati arasındaki üç saatlik fark, kronolojide yapay çelişkiler üretir.
- DKIM doğrulamasını aylar sonraya bırakmak. Alan adı sahibi açık anahtarı değiştirmişse imza artık doğrulanamaz.
- Kurumsal denetim kayıtlarının saklama süresini kaçırmak. Kısa saklama ayarı, oturum ve indirme kayıtlarının kendiliğinden silinmesine yol açar.
- Karşı tarafın hesabına "sadece bakmak için" girmek. Bu tek davranış, bütün dosyayı hukuka aykırı delil ve ceza sorumluluğu tartışmasına çeker.
- Tek bir metadata alanından "sahte" sonucu çıkarmak. Masum tutarsızlıklar elenmeden yapılan suçlama, sunanın güvenilirliğini zedeler.
- Bilirkişiyi reddetme ve rapora itiraz sürelerini kaçırmak. Ret için bir hafta, itiraz için iki haftalık süreler dosyanın en kısa takvimidir.
- Bilirkişi raporundan hukuki sonuç beklemek. Bilirkişi teknik vakıayı tespit eder; zararın kimde kalacağına veya kusura hâkim karar verir.
Kanıt Dedektiflik bu süreçte ne yapar?
Kanıt Dedektiflik bilirkişi değildir ve mahkemenin atadığı bilirkişinin yerine geçmez. Rolü, hukuka uygun yollarla elde edilen dijital verinin baştan doğru korunmasını sağlamak ve avukatınızın bilirkişi sürecine güçlü bir materyalle girmesine yardımcı olmaktır. Her dosya, Kanıt Yöntemi'nin ilk adımı olan hukuka uygunluk ön testiyle başlar; başkasına ait hesaba, cihaza veya bulut klasörüne erişim gerektiren talepler kabul edilmez.
Dijital iz ve açık kaynak araştırması bulguları; sayfa adresi, hesabın değişmeyen kimliği, erişim zamanı, arşiv kopyası ve hash değeriyle kayda geçirilir. Müvekkilin kendi hesabından veya şirketin kendi sistemlerinden yapılan dışa aktarmalarda öğe düzeyinde hash listesi tutulur, saat dilimi ve saat kaynağı belgelenir. Cihaz imajı gerektiren kurumsal dosyalarda çalışma, yazma engelleyici kullanan bir adli bilişim uzmanıyla ve tutanakla yürütülür.
Teslim edilen Delil Dosyası; kronolojiyi, yöntem beyanını, bütünlük listesini ve her bulgunun neyi gösterip neyi göstermediğini ayıran açıklamaları içerir. Avukat brifinginde, bilirkişiye önerilebilecek teknik sorular ve ret ile itiraz süreleri ayrıca not edilir. Elinizde zaten bir dijital delil varsa, onu yeniden üretmeye çalışmak yerine orijinalin nasıl dondurulacağı ve hangi bağımsız kaydın onu doğrulayabileceği birlikte planlanır.
Teslimden önce dijital delil envanteri: Bilirkişinin ilk sorularına bugünden cevap
Bir dijital delilin mahkemedeki ağırlığı, büyük ölçüde dava açılmadan önce verilen kararlarla belirlenir. Bilirkişinin ilk soracağı sorular bellidir: Orijinal nerede, ne zaman ve nasıl alındı, hash değeri nedir, saat neye göre ayarlıydı ve bu veriyi sizden bağımsız olarak hangi kayıt doğruluyor? Bu soruların cevabını bugünden yazılı hâle getirmek, aylar sonra hatırlamaya çalışmaktan çok daha güvenlidir.
- Kaynakları listeleyin. Verinin bulunduğu her cihazı, hesabı ve bulut klasörünü ayrı satıra yazın; hangisinin size, hangisinin şirkete, hangisinin başkasına ait olduğunu belirtin.
- Orijinali dondurun. Posta kutusundaki iletileri, bulut klasöründeki dosyaları ve cihazdaki verileri değiştirmeyin; otomatik silme ve temizleme ayarlarını kapatın.
- Ham hâlde dışa aktarın. E-postaları .eml veya .msg olarak, hesap verilerini sağlayıcının indirme aracıyla, belgeleri orijinal formatlarında alın.
- Öğe düzeyinde hash alın. Her dosyanın ve iletinin SHA-256 değerini, dışa aktarma tarih ve saatiyle birlikte listeleyin.
- Saat ve saat dilimini not edin. Her kaynağın saatinin neye göre ayarlı olduğunu ve kayıtlardaki saat diliminin ne olduğunu yazın.
- Bağımsız doğrulayıcıları belirleyin. Karşı tarafın sunucusu, bir bulut sağlayıcının sürüm geçmişi, bir banka ya da kargo kaydı gibi sizden bağımsız kaynakları ve bunlara hangi kanalla ulaşılabileceğini not edin.
- Kaybolma riskini değerlendirin. Kısa süre tutulan kayıtlar için avukatınızla HMK m.400 vd. kapsamında delil tespitini veya gerekirse zaman damgasını konuşun.
Kontrol listesi: Dijital delil envanteriniz hazır mı?
- [ ] Her kaynak cihaz, hesap ve klasör sahibiyle birlikte listelendi.
- [ ] Orijinaller değiştirilmeden duruyor; otomatik silme ve temizleme ayarları kapatıldı.
- [ ] E-postalar başlık bilgileriyle birlikte ham dosya olarak dışa aktarıldı.
- [ ] Her dosya ve ileti için SHA-256 değeri, tarih ve saatle listelendi.
- [ ] Saat kaynakları ve saat dilimleri yazılı.
- [ ] Bağımsız doğrulayıcı kayıtlar ve bunlara ulaşma yolu belirlendi.
- [ ] Kısa süre tutulan kayıtlar için delil tespiti veya zaman damgası ihtiyacı avukatla değerlendirildi.
- [ ] Verinin hukuka uygun yolla elde edildiği avukatla birlikte teyit edildi.
Bu envanter, avukatınızla yapacağınız ilk teknik görüşmenin gündemi, bilirkişiye önerilecek soruların taslağı ve karşı tarafın itirazlarına verilecek cevapların iskeleti olarak işe yarar. Elinizdeki dijital veriyi bu çerçevede gözden geçirmek ya da hukuka uygun bir koruma planı kurmak isterseniz, ücretsiz bir ön görüşme için iletişim sayfasından bize ulaşabilirsiniz.
Kaynaklar ve mevzuat
- 6100 sayılı Hukuk Muhakemeleri Kanunu (m.198, 199, 205, 219, 266–281, 293, 400)
- 5271 sayılı Ceza Muhakemesi Kanunu (m.63, 67, 68, 134, 206, 217)
- 5070 sayılı Elektronik İmza Kanunu (m.3, 4, 5)
- 6754 sayılı Bilirkişilik Kanunu
- 5651 sayılı İnternet Ortamında Yapılan Yayınların Düzenlenmesi Hakkında Kanun (m.5, 6)
- 6102 sayılı Türk Ticaret Kanunu (m.18/3)
Bu konuyla ilgili hizmetler
Dijital İz ve OSINT Araştırması
Kamuya açık dijital izleri hukuka uygun yöntemlerle toplar, doğrular ve avukatınızın kullanabileceği, bütünlüğü kanıtlanabilir bir rapora dönüştürürüz.
İnceleKurumsal Soruşturma
Şüpheyi söylentiden ayırır; iş hukuku ve KVKK sınırları içinde, yönetim kurulunun karar verebileceği ve avukatınızın kullanabileceği bir bulgu raporuna dönüştürürüz.
İncele

