MappedByteBuffer를 사용하여 Java에서 파일을 안전하게 삭제하려고합니다.
지금까지 제대로 작동하고 FileScavenger와 같은 소프트웨어로 파일을 복구 할 수 없습니다.보안 패스 수 삭제
현재 3 개의 패스를 사용하여 파일을 덮어 쓰고 있습니다. 그러나 나는 35 패스를 사용하는 Gutmann 메서드라는 것을 발견했습니다. 이런 맥락에서 어떤 사람들은 3 번의 패스로 충분하다고 생각합니다.
35 패스 또는 3 패스로 충분합니까?
저널 및 copy-on-write 파일 시스템이 도입 된 이후 은 fs 드라이버를 특별히 지원하지 않고 단일 파일을 안전하게 삭제할 수 없게되었습니다.. 저널은 fs에 쓰기 전에 블록 사본을 보관하여 충돌시 일관성을 보장하고 새 데이터 세트를 작성하고 이전 데이터를 건드리지 않고 내부 포인터를 이전 데이터에서 새 데이터로 변경합니다.
예로는 discussion about the implementation of secure deletion on ext4 및이 question on how to securely delete files on btrfs을 참조하십시오.
그리고 더 나쁜 것은 하드 드라이브가 "삭제 된"블록의 복사본을 운영 체제에 대한 힌트없이 독립적으로 보관할 수 있다는 것입니다. SSD는 이것에 특히 좋지 않지만, HDD는 고장이 났을 때 불량 블록을 (사실상) 교환하는 데 사용할 수있는 백업 블록의 영역이 더 작습니다.
불행히도 삭제에 대한 대안은 없습니다. 파일을 암호화 할 수는 있지만 어딘가에서 지울 수있는 키를 저장해야합니다. 다시 같은 문제가 발생합니다. LUKS (전체 디스크 암호화 소프트웨어)는 소위 안티 포렌식 스트라이프 (anti-forensic-stripes)를 사용하여 관련된 블록 중 적어도 하나가 스왑 아웃되거나 아직 삭제되지 않은 블록에서 복구 될 수 없도록하기 위해 긴 데이터 세트를 통해 주요 정보를 스트레칭합니다. 그러나 파일 시스템에 대해이 동작을 에뮬레이션하는 것은 실제로 좋은 생각이 아닙니다.
보안 삭제가 까다 롭습니다.
하드 디스크 드라이브에서 데이터를 올바르게 덮어 쓰면 NIST에 따라 한 번 덮어 쓰면됩니다. (http://csrc.nist.gov/publications/nistpubs/800-88/NISTSP800-88_with-errata.pdf)
솔리드 스테이트 드라이브 (SSD)가있는 경우 쓰기가 완료된 후 안전하게 데이터를 삭제할 수 없습니다. 여기서 문제는 내부 아키텍처입니다. 플래시 변환 레이어는 데이터를 플래시 셀에 쓰고 배포하는 책임이 있으므로 데이터가 어디에 쓰여 졌는지 확인할 필요가 없습니다. 따라서 삭제할 방법이 없습니다 (해당 셀을 덮어 쓰십시오). 또한 SSD에 따라 최대 20 % 더 많은 용량을 예약 할 수 있습니다.이 공간에는 전혀 액세스 할 수 없지만 일부 데이터는있을 수 있습니다. 따라서 단일 파일을 지우는 것은 불가능합니다. 모든 파일을 삭제하기 위해 개발자가 메커니즘을 내장하고 있습니다 (Secure Erase).
귀하의 질문에 대답하십시오 ... 만약 당신이 HDD를 사용하고 올바르게 삭제한다면, 그렇습니다! 3 배는 충분하다. SSD가 있다면 가능하지 않습니다!
지금은 물론 미래에도 가장 좋은 방법은 암호화를 통한 안전한 삭제입니다. 파일을 저장소에 쓰기 전에 저장소를 암호화하고 키를 사용하여 저장소를 해독 할 수 있습니다. 파일을 안전하게 지우려면 아무도 키를 잃어 버리지 않으면 아무도 다시 해독 할 수 없게됩니다. (물론 그다지 사소하지는 않습니다 ...)
http://superuser.com/questions/215852/is-using-multiple-passes-for-wiping-a-disk-really-necessary – assylias