Dijital Kanıt Bütünlüğü Nasıl Korunur?

Yayın: 26 Ekim 2026 · Son güncelleme: 26 Ekim 2026

Dijital kanıt bütünlüğü, bir dijital delilin elde edildiği andan mahkemeye sunulduğu ana kadar değiştirilmediğinin kriptografik yöntemlerle ispatlanmasıdır. SHA-256 gibi hash fonksiyonları tek bir bitlik değişikliği bile ortaya çıkarır, RFC 3161 zaman damgası delilin belirli bir tarihte var olduğunu bağımsız bir otoriteyle kanıtlar, delil zinciri (chain of custody) ise her erişimi kayıt altına alır. 26 Ekim 2026 itibarıyla bu üç mekanizma, NIST SP 800-86 ve ISO/IEC 27037:2012 rehberlerinin ortak temelini oluşturur.

İlgili Rehberler

Memory Forensics ile RAM Analizi
Volatility ile bellek imajı inceleme ve saldırı tespiti.

Veri İhlali Müdahale Planı
İlk 60 dakikada izolasyon ve delil toplama önceliği.

Cloud Incident Response
AWS, Azure ve GCP’de adli delil toplama iş akışları.

Dijital Kanıt Bütünlüğü Nedir ve Neden Önemlidir?

Dijital kanıt bütünlüğü, bir verinin elde edilme anındaki durumuyla inceleme ve sunma anındaki durumunun birebir aynı olduğunun kanıtlanabilir biçimde gösterilmesidir. Dijital veriler iz bırakmadan kopyalanabilir ve değiştirilebilir; bu yüzden bütünlüğü ispatlanamayan bir delile karşı taraf kolayca itiraz edebilir ve delilin hükme esas alınması zorlaşır.

Uygulamada bütünlük üç soruya cevap verir. Delil gerçekten iddia edilen cihazdan mı alındı (özgünlük)? Alındığı andan beri tek bir bit bile değişti mi (değişmezlik)? Toplama ve saklama adımları başka bir uzman tarafından tekrarlanıp aynı sonuca ulaşılabilir mi (güvenilirlik)?

Türkiye’de 5271 sayılı Ceza Muhakemesi Kanunu (CMK) Md. 134, bilgisayar ve bilgisayar kütüklerinde arama, kopyalama ve elkoymayı hâkim kararına bağlar. Aynı maddenin 4. fıkrası elkonulan sistemdeki bütün verilerin yedeklenmesini, 5. fıkrası ise bu yedekten bir kopyanın talep halinde şüpheliye verilip tutanağa geçirilmesini öngörür. Yedeğin ve kopyanın asılla aynı olduğunu göstermenin pratik yolu, tutanağa işlenen hash değeridir.

Kriptografik Hash Fonksiyonları Kanıt Doğrulamada Nasıl Kullanılır?

Kriptografik hash fonksiyonu, herhangi bir boyuttaki veriyi sabit uzunlukta bir dijital parmak izine dönüştürür. Girdideki tek bir bit değiştiğinde çıktı tamamen farklı olur. Adli bilişimde bu özellik, orijinal medya ile adli kopyanın bit düzeyinde aynı olduğunu göstermek için kullanılır ve delilin kabul edilebilirliği büyük ölçüde buna dayanır.

Hash doğrulama süreci

1. Orijinal medyanın hash değeri hesaplanır: Yazma engelleyici (write blocker) üzerinden bağlanılan orijinal diskin SHA-256 değeri, medyaya yazma yapılmadan hesaplanır.
2. Adli kopya (imaj) alınır: Bit düzeyinde birebir kopya oluşturulur.
3. Kopyanın hash değeri hesaplanır: İmajın hash değeri orijinalle karşılaştırılır.
4. Eşleşme doğrulanır: Değerler birebir aynıysa kopya orijinalin değiştirilmemiş yansımasıdır; farklıysa süreç tekrarlanır.
5. Raporlama: Her iki hash değeri, algoritma, UTC tarih-saat ve işlemi yapan kişi adli rapora işlenir.

Somut örnek: komut satırında doğrulama

# Linux — ham (raw) imaj ve kaynak disk
sha256sum /dev/sdb                 # write blocker arkasındaki orijinal disk
sha256sum CASE-2026-0042-HDD-001.dd

# E01 imajında edinim sırasında gömülen hash ile karşılaştırma
ewfverify CASE-2026-0042-HDD-001.E01

# Windows PowerShell
Get-FileHash .\CASE-2026-0042-HDD-001.dd -Algorithm SHA256

Hangi Hash Algoritması Tercih Edilmelidir?

Adli bilişimde birincil doğrulama algoritması olarak SHA-256 veya daha güçlü bir algoritma kullanılmalıdır. MD5’te 2004’te, SHA-1’de 2017’de pratik çarpışma (collision) saldırıları gösterilmiştir. NIST, SP 800-131A ile 2013’ten sonra SHA-1’in dijital imza üretiminde kullanılmasına izin vermemekte ve 2022’de algoritmayı 2030 sonuna kadar tamamen emekliye ayırma kararını duyurmuştur.

Birçok laboratuvar aynı veriye hem SHA-256 hem de MD5 uygular. Buradaki MD5 bir güvence değil, eski araçlarla ve önceki vaka kayıtlarıyla karşılaştırma yapabilmek için tutulur. İspat yükünü SHA-256 taşır.

Zaman Damgası Nasıl Çalışır ve Hukuki Geçerliliği Nedir?

RFC 3161 zaman damgası, bir verinin belirli bir tarih ve saatte var olduğunu bağımsız bir zaman damgası otoritesi (TSA) aracılığıyla kriptografik olarak kanıtlayan protokoldür. Hash değeri delilin değişmediğini, zaman damgası ise ne zaman var olduğunu ispatlar. Biri eksik kaldığında elde ya tarihi belirsiz bir delil ya da tarihi belli ama doğrulanmamış bir kopya kalır.

RFC 3161 zaman damgası süreci

1. Delilin SHA-256 hash değeri hesaplanır.
2. Yalnızca hash değeri TSA sunucusuna gönderilir; verinin kendisi gönderilmez.
3. TSA, hash’i güvenilir zaman kaynağından aldığı tarih-saatle birleştirir.
4. TSA bu birleşimi kendi özel anahtarıyla imzalar.
5. İmzalı zaman damgası jetonu (timestamp token) delilin yanında saklanır.

openssl ts -query -data CASE-2026-0042-HDD-001.dd -sha256 -cert -out talep.tsq
# talep.tsq, TSA'nın HTTP uç noktasına "application/timestamp-query" olarak gönderilir; yanıt yanit.tsr
openssl ts -verify -data CASE-2026-0042-HDD-001.dd -in yanit.tsr -CAfile tsa-zinciri.pem

Hukuki geçerlilik

Delil Zinciri (Chain of Custody) Nasıl Oluşturulur?

Delil zinciri, dijital delile kimin, ne zaman, nerede ve hangi amaçla eriştiğinin elde edilme anından mahkemeye sunuluşa kadar kesintisiz biçimde belgelendiği kayıt sistemidir. ISO/IEC 27037:2012, delilin tanımlanması, toplanması, edinimi ve muhafazası boyunca bu kaydın tutulmasını öngörür; kayıtta tek bir günlük boşluk bile karşı tarafın delilin o arada değiştirildiğini öne sürmesine yeter.

Delil zinciri kayıt formu bileşenleri

Her erişim ve transferde hash değeri yeniden hesaplanır ve önceki kayıtla karşılaştırılır. Formdaki imzalar kimin eriştiğini, hash değerleri ise bu erişimde verinin değişmediğini gösterir.

Adli İmaj Alma Sürecinde Bütünlük Nasıl Korunur?

Adli imaj alma, orijinal medyanın bit düzeyinde birebir kopyasını oluşturma işlemidir ve temel kural orijinale tek bir bit bile yazılmamasıdır. Yazma engelleyici kullanılmadan alınan imajlarda işletim sistemi diske kendiliğinden yazabilir. NIST SP 800-86 adli süreci toplama, inceleme, analiz ve raporlama olmak üzere dört aşamada tanımlar; imaj alma toplama aşamasının parçasıdır.

Adli imaj alma adımları

1. Hazırlık: Steril (sıfırlanmış) hedef medya hazırlanır. Kullanılacak araçların (dd, dc3dd, FTK Imager, Guymager) sürümleri ve hash değerleri kaydedilir.
2. Yazma engelleme: Donanım tabanlı yazma engelleyici bağlanır. Yazılım tabanlı engelleme yalnızca donanım yoksa ve gerekçesi yazılarak kullanılır.
3. İmaj alma: Bit düzeyinde kopya oluşturulur. E01 (EnCase) veya AFF4 formatı tercih edilir; raw (dd) format da kabul görür.
4. Hash doğrulama: Orijinal ve imaj için SHA-256 değerleri hesaplanıp karşılaştırılır.
5. Belgeleme: Araçlar, hash değerleri ve zaman bilgileri delil zinciri formuna işlenir.

RAM imajlarının Volatility ile incelenmesi ve doğrulanması için memory forensics ile RAM analizi rehberimize bakabilirsiniz.

Bellek (RAM) Delillerinde Bütünlük Nasıl Sağlanır?

RAM delilleri uçucu olduğundan disk delillerinden farklı bir bütünlük yaklaşımı gerektirir. Sistem kapandığında bellek içeriği kaybolur ve toplama aracı çalışırken belleğe kendi izini bırakır. Bu nedenle RAM’de hash, orijinalle eşitliği değil, alınan imajın inceleme ve raporlama aşamalarında değişmediğini kanıtlar.

• Şüpheli sistem kapatılmaz; ağdan izole edilir ama enerjisi kesilmez.
• Kullanılan aracın (WinPMEM, LiME, DumpIt) adı, sürümü ve bellekte kapladığı alan kaydedilir; bu alan analizde ayrıca değerlendirilir.
• RAM imajının hash değeri toplama biter bitmez hesaplanır.
• Başlangıç ve bitiş zamanları saniye hassasiyetinde yazılır. 64 GB gibi büyük belleklerde toplama dakikalar sürer ve bu sürede bellek içeriği değişmeye devam eder.

Olay müdahalesinin ilk saatinde bellek toplamanın hangi sırada yapılacağını veri ihlali müdahale planı rehberimizde bulabilirsiniz.

Bulut Ortamında Dijital Delil Toplama Nasıl Farklılaşır?

Bulut ortamında fiziksel diske erişim olmadığından delil, sağlayıcının API’leri üzerinden sanal disk anlık görüntüleri (snapshot), log kayıtları ve meta veriler biçiminde toplanır. Verinin hangi ülkede tutulduğu (data residency), hangi yargı yetkisine girdiği ve logların ne kadar saklandığı en baştan bilinmelidir. Örneğin AWS CloudTrail olay geçmişi, ayrı bir trail kurulmadıysa yalnızca 90 gün tutulur.

• AWS EBS, Azure Managed Disk veya GCP Persistent Disk üzerinden snapshot alınır. Snapshot’tan bir birim oluşturulur, ayrı bir inceleme sunucusuna bağlanır, imajı alınıp hash’lenir.
• AWS CloudTrail, Azure Activity Log ve GCP Cloud Audit Logs kayıtları dışa aktarılır. CloudTrail’de log file validation açıksa her saat için SHA-256 ve RSA imzalı bir özet (digest) dosyası üretilir; bu dosya logların sonradan değiştirilmediğini gösterir.
• Konteyner ve sunucusuz (serverless) kaynaklar kısa ömürlüdür. Log akışı olaydan önce yapılandırılmamışsa kaynak silindiğinde delil de kaybolur.
• Hangi API çağrısının hangi kimlikle ve ne zaman yapıldığı kaydedilir. Bu kayıt, delil zincirinin bulut tarafını oluşturur.

AWS, Azure ve GCP’ye özgü iş akışları için cloud incident response rehberimizi inceleyebilirsiniz. Toplanan logların merkezi olarak saklanması ve korelasyonu için SIEM nedir yazımıza bakabilirsiniz.

Delili Geçersiz Kılan Yaygın Hatalar Nelerdir?

Toplama ve muhafaza sürecindeki usul hataları, teknik olarak doğru bir analizi bile hukuken tartışmalı hale getirebilir. Aşağıdaki yedi hata, delile itiraz edilirken sıkça öne sürülen gerekçelerdir. Çoğu olay anındaki aceleden doğar. Önceden yazılmış bir prosedür ve elde hazır duran bir delil zinciri formu bu hataları büyük ölçüde engeller.

• Yazma engelleyici kullanmamak: Orijinal medyaya doğrudan bağlanmak, işletim sisteminin diske meta veri ve log yazmasına yol açar.
• Yalnızca MD5’e güvenmek: Çarpışma zafiyeti, doğrulamanın tek başına itiraz edilmesine zemin hazırlar.
• Delil zincirinde boşluk bırakmak: Eksik erişim veya transfer kaydı, delilin değiştirildiği iddiasını güçlendirir.
• Sistemi kapatmak: Çalışan süreçler, ağ bağlantıları ve şifreleme anahtarları kalıcı olarak kaybolur.
• Zaman senkronizasyonunu atlamak: Saat dilimi ve sapma kaydedilmezse farklı kaynaklardan gelen deliller tek bir zaman çizelgesinde birleştirilemez.
• Araç doğrulaması yapmamak: Araç adı, sürümü ve hash değeri kaydedilmezse aracın güvenilirliği sorgulanır.
• Bulut log doğrulamasını atlamak: Sağlayıcının bütünlük mekanizması kullanılmazsa logların değiştirildiği iddiası çürütülemez.

Sıkça Sorulan Sorular

Bu bölümde imaj alma ve doğrulama sırasında sahada sık karşılaşılan üç durum yer alıyor: hash değerlerinin eşleşmemesi, zaman damgası alınmamış deliller ve şifreli disklerden imaj alınması. Yanıtlar, bu durumlarla karşılaşıldığında hangi adımın tekrarlanacağını ve rapora ne yazılacağını kısaca anlatıyor.

Yazar: Afra Görgen

Resmi Kaynaklar

• NIST SP 800-86 — Guide to Integrating Forensic Techniques into Incident Response (2006)
• ISO/IEC 27037:2012 — Guidelines for identification, collection, acquisition and preservation of digital evidence
• IETF RFC 3161 — Internet X.509 PKI Time-Stamp Protocol (2001)
• NIST SP 800-131A Rev. 2 — Transitioning the Use of Cryptographic Algorithms (2019)
• NIST — NIST Retires SHA-1 Cryptographic Algorithm (2022)
• SHAttered — SHA-1 çarpışma saldırısı (2017)
• 5271 sayılı Ceza Muhakemesi Kanunu (Mevzuat Bilgi Sistemi)
• 5070 sayılı Elektronik İmza Kanunu (Mevzuat Bilgi Sistemi)
• Regulation (EU) No 910/2014 (eIDAS) — Resmi Metin (EUR-Lex)
• Federal Rules of Evidence, Rule 902 (Cornell LII)
• AWS — Validating CloudTrail log file integrity

Erişim tarihi (tüm kaynaklar): 26 Ekim 2026. Güncelleme tarihçesi: 26 Ekim 2026 — ilk yayın.