Introduction

Dijital soruşturmalarda bir dosya orijinal depolama ortamından ayrıldığı anda istenmeyen değişikliklere açık hale gelir. Görünüşte zararsız bir dönüşüm—örneğin bir disk imajını E01’den RAW’a çevirmek, bir günlük dosyasını sıkıştırmak ya da bir PDF’i mahkeme sunumu için yeniden oluşturmak—hash’leri bozabilir, zaman damgalarını sıyırabilir veya daha sonra bir uzman tanıklığında kritik olabilecek gizli öznitelikleri silinebilir. Bu makale, kanıt hazırlamadan son çıktıyı doğrulamaya kadar tüm dönüşüm yaşam döngüsünü, yeniden üretilebilirlik, denetlenebilirlik ve yasal savunulabilirlik odaklı bir şekilde ele alır. Açıklanan prensipler, bir kurumsal ihlal, bir kolluk organı el koyması ya da dahili bir denetim üzerinde çalışıyor olsanız da geçerlidir ve gerektiğinde convertise.app gibi güvenilir, gizlilik odaklı bulut tabanlı hizmetlerin kullanılmasını varsayar.

1. Kontrollü Bir Dönüşüm Ortamı Kurmak

İlk bayt dokunulmadan önce, denetleyiciler dönüşümün gerçekleşeceği ortamı kilitlemelidir. Bu, bir yazma‑engelli iş istasyonu ya da bilinen‑iyi bir forensik imajdan (ör. BitLocker‑korumalı yazma‑bir­kez­lik USB) önyüklenmiş bir adli iş istasyonu ile başlar. Dönüşüm için kullanılan tüm yazılımlar envanter kontrolünden geçirilmeli, dijital imzası doğrulanmalı ve sürüm kontrolüne tabi tutulmalıdır. İkili hash’leri doğrulanabilen açık kaynaklı araçlara öncelik verilmelidir; kapalı kaynak ikili dosyalar belgelenmemiş bir saldırı yüzeyi sunar. İş istasyonu izole edildikten sonra, ayrı bir, şifreli çalışma dizini oluşturulmalı; yolu ve izinleri bir dava‑logunda kaydedilmeli ve mümkün olduğunca yazma‑bir­kez ortamda saklanmalıdır. Bu adımlar, dönüşüm sürecinin dışsal değişkenler eklemediğini göstermek için yeniden üretilebilir bir temel oluşturur.

2. Temel Hash’leri ve Metaverileri Yakalamak

Adli bütünlüğün temel taşı, orijinal kanıt üzerinde DÖNÜŞÜMDEN ÖNCE (BEFORE) hesaplanan hash değeridir (MD5, SHA‑1, SHA‑256 ya da tercihen SHA‑512). Hash hesaplaması, NIST SP 800‑90 standartlarına uyan bir araçla yapılmalı ve elde edilen değer, dosyanın orijinal metaverileriyle birlikte kaydedilmelidir: oluşturulma, değiştirilme ve erişim zaman damgaları; dosya sistemi öznitelikleri; ve disk imajları için bölüm tabloları ve dosya sistemi imzaları gibi sektör‑seviye detaylar. En az iki bağımsız hash aracında hash yakalamak en iyi uygulamadır; herhangi bir tutarsızlık potansiyel manipülasyon kanıtı olarak belgelenmelidir. Kaydedilen hash, sonraki her doğrulama adımının referans noktası olur.

3. Doğru Hedef Formatını Seçmek

Her dönüşüm eşit yaratılmaz. Dönüşüm kararı, soruşturma hedefine göre şekillenmelidir: koruma, analiz veya sunum. Koruma amacıyla, RAW (dd) ya da E01 gibi sektör‑sektör kopya formatları tercih edilir; bu formatlar kaynak medyanın tam bayt dizisini tutar. Analiz araçları yalnızca belirli bir kapsayıcıyı (ör. AFF okuyabilen bir adli paket) kabul ediyorsa, o formata dönüşüm haklıdır, ancak orijinalin dokunulmamış bir kopyası da saklanmalıdır. Sunum için PDF‑/A ya da TIFF dosyaları uygun olabilir; fakat dönüşüm hattı, çıktının metaverilerine kaynağın bir kontrol toplamını (checksum) eklemeli ve böylece iki dosya arasında doğrulanabilir bir bağ oluşturmalıdır. Metaverileri doğu­run destekleyen bir format (ör. AFF) seçmek bu bağı basitleştirebilir.

4. Denetim İzleriyle Dönüşüm Gerçekleştirmek

Modern dönüşüm araçları, kaynak ve hedef yolları, zaman damgaları ve uygulanan dönüşümler (ör. sıkıştırma seviyesi, görüntü yeniden örnekleme) gibi her işlemi kaydeden ayrıntılı bir günlük (log) üretir. Komut satırı aracını kullanıyorsanız --log bayrağı etkinleştirilmeli ve günlük dosyası dönüştürülmüş artefaktın yanına kaydedilmelidir. Dönüşüm bir bulut hizmetinde gerçekleşiyorsa, hizmetin değişmez bir denetim kaydı (zaman damgalı API isteği, kaynak hash’i, hedef format) sağlaması gerekir. Yöntem ne olursa olsun, denetçi dönüşüm tamamlandıktan hemen sonra dönüştürülmüş dosya üzerinde ikinci bir hash almalıdır. Bu ikinci hash, orijinal hash ile birlikte, daha sonra bir inceleyici ya da hâkiye sunulabilecek bir hash‑çifti oluşturur.

5. Dönüşüm Sonrası Bütünlüğü Doğrulamak

Doğrulama, yalnızca basit bir hash karşılaştırmasından daha fazlasıdır. Kayıpsız formatlar için bayt‑bayt karşılaştırma (ör. Unix’taki cmp) yapılabilir ve hedef format izin veriyorsa uygulanmalıdır. Kayıplı ya da dönüştürülmüş formatlar için doğrulama, kanıt değerinin korunmasına odaklanmalıdır: zaman damgalarının, gömülü EXIF ya da NTFS alternatif veri akışlarının ve herhangi bir gizli dosya özniteliğinin dönüşümde ayakta kalıp kalmadığını kontrol edin. exiftool veya fsstat gibi araçlar bu öznitelikleri dönüşüm öncesi ve sonrası çekip karşılaştırabilir. Herhangi bir sapma belgelenmeli, açıklanmalı ve mümkün olduğunca azaltılmalıdır (ör. orijinal hash’i yeni dosyanın metaverisine özel bir XMP etiketiyle ekleyerek).

6. Zincir‑İz (Chain‑of‑Custody) Günlüğünü Süreç Boyunca Belgelemek

Zincir‑iz günlüğü, kanıtı el elen kişilerin kronolojik kaydı, yapılan her işlem ve kanıtın bulunduğu konumların kaydıdır. Dönüşüm adımı bu zincire yeni bir düğüm ekler. Dönüşüm için log girdisi şunları içermelidir:

  • Dönüşümün tarih, saat ve UTC ofseti.
  • Analistin adı ve iş istasyonu kimliği.
  • Kullanılan tam komut satırı ya da API isteği.
  • Dönüşüm öncesi kaynak dosyanın hash’i.
  • Dönüşüm sonrası elde edilen dosyanın hash’i.
  • Dönüşümün nedeni (koruma, analiz, sunum).
  • Uygulanan sıkıştırma ayarları ya da kalite parametreleri.

Bu bilgilerin doğrudan dönüştürülmüş dosyanın içinde, ayrı bir metaveri bloğuna yerleştirilmesi, dış log kaybı durumunda bile dosyanın kendisinin kendi‑tanımlayıcı bir artefakt olmasını sağlar.

7. Büyük Veri Miktarları ve Toplu Dönüşümlerle Baş Etmek

Soruşturmalar genellikle yüzlerce gigabayt kanıt içerir. Toplu dönüşüm betikleri belirleyici (deterministik) ve tekrarlanabilir olmalıdır. Yaygın bir yaklaşım, her kaynak dosya, temel hash’i ve istenen hedef formatı listeleyen bir manifest dosyası (CSV ya da JSON) üretmektir. Betik manifest’i okur, her girdiyi işler, dönüştürülmüş dosyayı kontrollü bir çıkış dizinine yazar ve hem hash’leri, çıkış kodunu hem de uyarıları içeren bir satırı sonuç günlüğüne ekler. Manifestin sürüm‑kontrol altında tutulması, bir mahkeme yeniden çalıştırma talep ettiğinde aynı dönüşümün tekrarlanmasını ve denetçilerin hiçbir dosyanın atlanmadığını ya da iki kez işlenmediğini doğrulamasını sağlar.

8. Şifreli veya Korunmuş Kanıtlarla İlgilenmek

Şifreli kapsayıcılar—TrueCrypt hacimleri, BitLocker‑korumalı sürücüler ya da şifre korumalı PDF’ler—benzersiz bir zorluk ortaya koyar. Doğru adli yaklaşım, şifreli kapsayıcıyı ham (raw) biçimde edinmek ve şifreleme parametrelerini (algoritma, anahtar uzunluğu, tuz) şifreyi çözme girişiminde bulunmadan belgelemektir. Çözümleme için şifre çözme gerekli ise, anahtar düzgün bir şekilde belgelenip kimliği doğrulandıktan sonra, izole bir hava‑gözü (air‑gapped) sistemde yapılmalıdır. Şifre çözüldükten sonra ortaya çıkan düz metin dosyası dönüştürülebilir, fakat hem şifreli orijinal hem de şifre çözülmüş kopya, kendi hash’leriyle birlikte saklanmalı, böylece kanıt izinin bütünlüğü korunur.

9. Hukuki Hususlar ve Kabul Edilebilirlik

Mahkemeler dijital kanıtın her dönüşümünü titizlikle inceler. Kabul edilebilirlik standartlarını (ör. Daubert, Frye) karşılamak için dönüşüm süreci şu niteliklere sahip olmalıdır:

  1. Bilimsel olarak sağlam: yaygın kabul gören araç ve yöntemler üzerine kurulmuş.
  2. Şeffaf: tüm adımlar tam olarak belgelenmiş ve yeniden üretilebilir.
  3. Doğrulanmış: aracın çıktısı, bilinen‑iyi örneklerle benchmark yapılmış.
  4. Bağımsız: mümkünse ikinci bir analist ya da dış bir uzman tarafından doğrulanmış.

Üçüncü‑taraf bir bulut hizmeti kullanılıyorsa, araştırmacı veri‑işleme koşullarını içeren bir Hizmet Seviyesi Anlaşması (SLA) edinmeli ve sağlayıcının gizlilik ve bütünlük taahhüdünü gösteren sertifika belgelerini (ISO 27001, SOC 2 vb.) saklamalıdır.

10. Dönüştürülmüş Kanıtın Arşivlenmesi

Dönüşümden sonra artefakt, yazma‑bir­kez, okuma‑çok (WORM) politikalarını zorlayan bir kanıt deposunda tutulmalıdır. Depo, her dosya için hash çiftini saklamalı ve depolama ortamı periyodik olarak bir tutarlılık (fixity) kontrolü (yeniden hashleme) ile bit‑çürümesini tespit etmelidir. Depo sürümleme destekliyorsa, orijinal dosya ve her türetilmiş dönüşüm ayrı sürümler olarak ele alınmalı, her biri değişmez bir metaveri kaydı taşımalıdır. Bu uygulama, gelecekteki incelemecilerin bir artefaktın ham alımından tüm sonraki dönüşümlerine kadar izini sürmesini garanti eder.

11. En‑İyi‑Uygulama Kontrol Listesi Özeti

  • İzolasyon: Dönüşüm iş istasyonunu ayırın ve mümkün olduğunda yazma‑engelleme kullanın.
  • Kayıt: Herhangi bir dönüşümden önce temel hash’leri ve tam metaverileri kaydedin.
  • Seçim: Araştırma hedefine uygun ve kritik öznitelikleri koruyan bir hedef formatı seçin.
  • Günlük: Her dönüşüm komutu ya da API çağrısı için ayrıntılı log veya denetim izi etkinleştirin.
  • Hash: Dönüşüm sonrası bir hash hesaplayın ve önceden tanımlı doğrulama planıyla karşılaştırın.
  • Belgeleme: Zincir‑iz (chain‑of‑custody) kaydına dönüşüm adımını kapsamlı şekilde ekleyin; anahtar detayları dosyanın içine gömün.
  • Manifest: Toplu işleme için deterministik manifestler kullanın ve sürüm kontrolünde tutun.
  • Şifreli Kanıtlar: Şifreli kapsayıcıları ayrı kanıt olarak ele alın; sadece kesin gerektiğinde çözün ve hem şifreli hem de çözülmüş kopyaları hash’leriyle saklayın.
  • Doğrulama: Dönüşüm aracının çıktısını bilinen‑iyi test verileriyle karşılaştırın ve bağımsız bir doğrulama alın.
  • Depolama: Dönüştürülmüş artefaktları WORM‑uyumlu bir depoda saklayın ve düzenli tutarlılık kontrolleri yapın.

Bu adımları izlemek, rutin bir dosya dönüşümünü adli açıdan sağlam bir işlem haline getirir; dijital artefaktların ele geçirildiği andan mahkemede sunulana kadar kanıt ağırlığını korur.