# SSD ve NVMe Medya Sanitizasyonu > SSD üzerinde bir dosyanın overwrite edilmesi fiziksel NAND hücrelerinin gerçekten temizlendiğini kanıtlamaz. Wear leveling, over-provisioning ve remapping nedeniyle sanitizasyon cihaz semantiğiyle ele alınmalıdır. - Author: Muhammet Ali Köker - Language: tr - Canonical: https://alikoker.com.tr/ssd-nvme-medya-sanitizasyonu-ve-cryptographic-erase - Published: 2025-09-26T12:00:00+03:00 - Modified: 2026-08-19T16:59:00+03:00 - Verified: 2026-08-19T16:59:00+03:00 - Type: article Manyetik diskte yıllarca öğretilen "dosyanın üzerine birkaç kez veri yaz" yaklaşımı SSD'ye taşındığında varsayım bozulur. Logical block'a yazdığınız yeni byte'ların eski NAND hücresinin üzerine gittiğini garanti edemezsiniz. Adli bilişim açısından silme ile geri getirilemez hale getirme arasındaki fark temel bir konudur. SSD ve NVMe cihazlarda bu fark daha da büyür; çünkü host işletim sistemi fiziksel flash yerleşimini doğrudan kontrol etmez. 2025'te yayımlanan NIST SP 800-88 Rev.2 bu alanı güncel bir sanitization programı çerçevesinde yeniden ele alıyor. ## LBA fiziksel hücre değildir İşletim sistemi diski logical block address üzerinden görür. SSD controller ise logical-to-physical mapping tablosu kullanır. Flash Translation Layer wear leveling, garbage collection, bad block remapping, over-provisioning ve write amplification yönetimi nedeniyle fiziksel yeri değiştirebilir. Dolayısıyla aynı LBA'ya ikinci kez yazmak ilk verinin tutulduğu NAND page'i doğrudan overwrite etmek anlamına gelmeyebilir. Eski page bir süre fiziksel olarak varlığını sürdürebilir. ## Overwrite neden güvence vermez? Klasik secure-delete araçlarının önemli kısmı dosyayı belirli pattern'lerle tekrar yazar. Filesystem ve controller bu yazıları yeni block'lara yönlendirebilir. Eski block host tarafından artık adreslenemiyor olsa bile fiziksel ortamda bulunabilir. Normal kullanıcı açısından bu veri erişilemez olabilir. Laboratuvar seviyesinde chip-off veya controller dışı yöntemler farklı tehdit modeli oluşturabilir. Sanitization kararı bu yüzden "dosyayı geri getiremiyorum" testiyle verilmez. ## TRIM sanitization değildir TRIM, işletim sisteminin artık kullanılmayan logical block'ları cihaza bildirmesidir. Bu bildirim SSD'nin garbage collection yapmasını kolaylaştırır. Performans ve write amplification için önemlidir. Fakat TRIM komutu tek başına "ilgili fiziksel hücreler şu anda güvenli biçimde temizlendi" garantisi değildir. Controller uygulaması, zamanlama ve cihaz davranışı devreye girer. TRIM ile secure erase kavramlarını eş anlamlı kullanmak bu nedenle doğru değildir. ## Clear, Purge ve Destroy NIST medya sanitizasyonu yaklaşımında yöntem seçimi veri hassasiyetine ve tehdit modeline göre yapılır. Genel olarak Clear normal arayüzlerle veri kurtarmayı zorlaştırır; Purge daha ileri kurtarma tekniklerine karşı daha güçlü sanitization hedefler; Destroy ise ortamın tekrar kullanımını ortadan kaldıran fiziksel yöntemleri içerir. Rev.2'nin önemli yönlerinden biri tek tek medya tipi için ezber komut listesi vermekten ziyade güncel standart ve üretici yöntemlerinin doğrulanmasına ağırlık vermesidir. Bu daha doğru bir yaklaşımdır; depolama teknolojisi sabit değildir. ## Cryptographic erase Self-encrypting drive veya controller seviyesinde tüm kullanıcı verisi güçlü bir media encryption key ile şifreleniyorsa anahtarın güvenli biçimde yok edilmesi verinin pratik olarak erişilemez hale gelmesini sağlayabilir. Bu yöntem çok hızlıdır. Terabyte'larca NAND'ı fiziksel olarak overwrite etmek yerine küçük bir anahtar materyali yok edilir. Ancak cryptographic erase yalnız veri baştan beri doğru anahtarla şifrelenmişse, plaintext kopya başka yerde yoksa, key generation yeterliyse, eski key backup'ı kalmamışsa, firmware işlemi doğru uyguluyorsa ve sanitize sonucu doğrulanabiliyorsa güçlüdür. "Disk şifreliydi" tek başına yeterli kanıt değildir. ## NVMe komutları ve cihaz yetenekleri NVMe cihazlarda Format NVM ve Sanitize gibi komutlar farklı secure-erase yetenekleri sunabilir. Destek düzeyi controller'a göre değişebilir. Host yazılımı komutu gönderebildi diye işlem başarılı varsayılmamalıdır. Completion status, device log ve gerekiyorsa vendor dokümantasyonu kontrol edilmelidir. Kurumsal süreçte cihaz modeline göre doğrulanmış sanitization prosedürü tutmak, kullanıcıya rastgele `dd` komutu vermekten çok daha güvenlidir. ## Verification neden ayrı adımdır? Sanitization işleminin uygulanması ile sonucunun doğrulanması ayrı süreçlerdir. Rev.2 bu ayrımı özellikle güçlendiriyor. Doğrulama komutun başarılı tamamlandığının kontrolü, cihazın beklenen sanitization capability'sinin teyidi, logical read, device health/log bilgilerinin incelenmesi ve süreç kaydının tutulmasını kapsayabilir. Her ortamda fiziksel adli laboratuvar doğrulaması yapılması beklenmez. Ama "komut çıktı vermedi, demek ki oldu" seviyesi de yeterli değildir. ## Sanitization kayıt altına alınmalıdır Kurumsal adli bilişim ve güvenlik süreçlerinde hangi diskin ne zaman, hangi yöntemle, hangi tool/firmware sürümüyle temizlendiği kayıt altına alınmalıdır. Özellikle disposal zincirinde asset identity kaybolmamalıdır. Ben bu nedenle sanitization'ı tek bir shell command değil, lifecycle süreci olarak görüyorum: ```text identify -> classify -> choose method -> sanitize -> verify -> document -> reuse/dispose ``` Bu yapı incident sonrası denetlenebilirlik sağlar. ## SSD'de dosya bazlı güvenli silmenin sınırı Bütün cihazı sanitize etmek ile tek bir dosyayı "geri getirilemez" yapmak aynı problem değildir. SSD'de filesystem, FTL, snapshots, backup, journal ve application cache nedeniyle tek dosyanın bütün fiziksel kopyalarını garantiyle temizlemek çok zor olabilir. Hassas geçici veriler için daha güvenli mimari yaklaşım, veriyi baştan encrypted storage içinde tutmak ve lifecycle sonunda anahtar yönetimini doğru yapmaktır. Silme işlemini veri üretildikten sonra eklenen bir güvenlik adımı olarak değil, storage design'ın başında düşünmek gerekir. ## Adli bakışın ters yönü Adli bilişim çoğu zaman veri kurtarmaya odaklanır. Sanitization aynı bilginin ters problemidir: belirli bir saldırganın veriye ulaşmasını hangi maliyet seviyesinde imkansız hale getirdik? Bu soruya cevap vermek için filesystem'in değil, fiziksel depolama mimarisinin davranışını anlamak gerekir. SSD/NVMe dünyasında `rm`, format veya overwrite kelimeleri tek başına güvenlik özelliği değildir. Güvence ancak cihaz semantiği, kriptografi ve doğrulama birlikte ele alındığında oluşur. ## Kaynakça - [NIST SP 800-88 Rev.2 - Guidelines for Media Sanitization](https://csrc.nist.gov/pubs/sp/800/88/r2/final) - [Stack Overflow - Secure file delete in C](https://stackoverflow.com/questions/7757495/secure-file-delete-in-c) ## Bu Çalışmaya Atıf Köker, M. A. (2025). SSD ve NVMe Medya Sanitizasyonu. alikoker.com.tr. https://alikoker.com.tr/ssd-nvme-medya-sanitizasyonu-ve-cryptographic-erase - BibTeX: https://alikoker.com.tr/ssd-nvme-medya-sanitizasyonu-ve-cryptographic-erase.bib - RIS: https://alikoker.com.tr/ssd-nvme-medya-sanitizasyonu-ve-cryptographic-erase.ris - CSL-JSON: https://alikoker.com.tr/ssd-nvme-medya-sanitizasyonu-ve-cryptographic-erase.csl.json