| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
shred: セキュリティを向上させたファイルの削除shred はデバイスやファイルを上書きして、
非常に高価な装置を使用しても、データの復元ができないようにする。
通常、ファイルを削除しても (see section rm: ファイルやディレクトリを削除する)、データが実際に消去されるわけではない。
単に、ファイルが格納されている場所をリストしたインデックスが破棄されるだけであり、
そうすることで、そのデータの格納場所が再利用可能になるのである。
世の中には、インデックスの再構築を試みる復元ソフト (undelete utilities)
というものが存在する。そうしたものは、ファイルの存在したスペースが再利用されていなければ、
ファイルを復元することができるのだ。
頻繁に使われているシステムで、ディスクがほとんど一杯になっている場合、 スペースは数秒のうちに再利用されるかもしれない。だが、それを確実に知る方法は全くない。 また、他人に見られては困るデータがあったところで、 見られても構わないデータでそのファイルを上書きしてしまえば、 復元は絶対不可能だと考えたいかもしれない。
しかしながら、そういうことをした後でも、ディスクを研究所に持ち込んで、 高感度の (そして高価な) 装置を山ほど使用すれば、 上書きされたデータの下にある元のデータのかすかな「痕跡 (echoes)」を検出することが可能なのだ。 もし、データがたった一回しか上書きされていなかったら、それはさほど難しいことでもない。
データを復元できないように消去する最善の方法は、
それが載っているメディアを酸で破壊するとか、熱で溶かすとかすることである。
フロッピーディスクのような廉価なリムーバブル・メディアの場合、それがよく使われる方法だ。
だが、ハードディスクは高価だし、熱で溶かすのも難しい。
そこで、shred ユーティリティは、物質的な破壊以外の方法で、
同様の効果を実現しようとするのである。
そのためには、元のデータに与える損傷を最大にするように選ばれたデータパターンで繰り返し上書きするという方法が採られる。
この方法は、フロッピーディスクにも効果があるものの、パターンはハードディスクで最も効果を上げるように工夫されたものだ。
詳細については、ソースコードや、第 6 回 USENIX セキュリティ・シンポジウム
(San Jose, California, July 22–25, 1996) の議事録にある
Peter Gutmann の次の論文をご覧になっていただきたい。
Secure Deletion of Data from Magnetic and Solid-State Memory
ここで心に銘記してしていただきたいのは、shred には非常に重要な前提があるということである。
すなわち、ファイルシステムはデータを、それが存在する場所で上書きするものでなければならない。
それは、こうした操作を行うときの伝統的な方法であるが、
最近のファイルシステムの設計には、この前提を満たさないものが多い。
そうした例外には、次のようなものがある。
data=journal モードの場合),
BFS, NTFS などが、「データ」のジャーナリングをするように設定されている場合もこれに当たる。
特に ext3 ファイルシステムについて言うと、上記の例外に当てはまるのは
(その結果、shred が限定された効果しか持たないのは)、data=journal
モードの場合だけである。これは、メタデータだけでなく、
ファイルデータもジャーナリングするモードだ。data=ordered (デフォルト)
と data=writeback の両モードでは、shred は通常どおり役に立つ。
ext3 のジャーナリング・モードを変更するには、mount のマニュアルに書いてあるように
(man mount)、‘/etc/fstab’ ファイルで問題のファイルシステムのマウントオプションに
data=something オプションを追加すればよい。
ファイルシステムがどういう動作をしているか、よくわからない場合は、
データをそれが存在する場所で上書きしていないと考えておいた方がよい。
すなわち、そのファイルシステムでは、通常ファイルに対する shred
の動作は、信頼できないということである。
一般的に言って、shred は、ファイルよりデバイスに対して使った方が信頼できる。
そうすれば、上に述べたファイルシステムの設計の問題を回避できるからだ。
しかしながら、shred のデバイスに対する使用も、必ずしも全面的に信頼できるわけではない。
たとえば、ほとんどのディスクが、バッドセクターを使用に割り当てる領域から外して、
アプリケーションから見えないようにしている。
そこで、バッドセクターに他人に見られたくないデータがある場合、shred
はそれを破壊できないことになる。
shred は、バックアップに対して何の対処も行おうとしないが、
バッドセクターの問題についても全く同様で、検知しようともしないし、通知しようともしない。
それでも、shred はファイルに対して行うより、デバイスに対して行う方が信頼できるので、
デフォルトでは、出力ファイルをサイズ 0 に短縮したり、削除したりしないようになっている。
このデフォルトは、ファイルよりデバイスに適した動作だ。
デバイスは一般に短縮できないし、削除するべきでもないからである。
最後になったが、バックアップやミラーの持つリスクも考慮した方がよい。
削除することのできないファイルのコピーが、ファイルシステムのバックアップやリモートのミラーに残っているかもしれないのだ。
そして、そうしたものが残っていれば、shred
で破壊したファイルを後日復元することが可能になる。
だから、後で shred を使って破棄したくなりそうなデータがある場合には、
そのバックアップやミラーがないことを確認すべきなのである。
shred [option]… file[…] |
このプログラムでは以下のオプションが使用できる。参照: 共通オプション.
必要ならば、ファイルの許可属性を無視して、上書きできるようにする。
デフォルトで shred は、上書きを 3 回する。
時間を節約するために、回数を減らすこともできるし、
その方がよいと思えば、回数を増やすこともできる。
25 回上書きすると、プログラムが内部に持っている上書き用のパターンのすべてが、
少なくとも一回は使われたことになる。
上書きに使用するランダムデータのソースとして file を使用する。 また、このランダムデータは、上書きパターンの順番を決めるのにも使用される。
ファイルの最初の bytes バイトを shred 処理する。デフォルトは、 ファイル全体の shred である。bytes の後ろには、その何倍かを示すために ‘K’, ‘M’, ‘G’ といった、サイズの指定を付けることができる。 See section ブロックサイズ.
shred 処理したファイルを (可能ならば) サイズ 0 に短縮し (truncate)、その上で削除する。ファイルが複数のリンクを持っている場合に、 削除されるのは名前を指定されたリンクだけである。 ファイルの名前は、ファイルの内容ほど秘密性を必要としないことも多い。 そうした場合は、長い書式のオプションでサポートされている how パラメータを付けることで、各ディレクトリエントリのより効率的な削除法を指定することができる。 how パラメータに ‘unlink’ を指定した場合は、標準の unlink 呼び出しをするだけだが、 ‘wipe’ を指定すると、unlink する前にファイル名を構成するバイトの難読化を行う。 ‘wipesync’ を指定した場合は、ファイル名を難読化するだけでなく、 それを 1 バイトづつディスクに sync することまで行う。 留意していただきたいのは、‘wipesync’ はデフォルトの方法だが、 すべてのファイル名のすべての文字ごとに sync を行うことになるので、 負荷が重くなるかもしれないということである。 ファイル数が多い場合には、無視できない負荷になるかもしれない。 また、使用しているシステムがメタデータの同期アップデートを提供している場合には、 やらないでもよいことかもしれない。
shred 処理が進行する間、更新される進行状態の情報のすべてを標準エラーに表示する。
デフォルトでは、shred は、
通常ファイルのサイズを、ファイルシステムのブロックサイズの倍数に切り上げて、
ファイルの最後のブロックの不使用領域まで完全に抹消する。
この領域には、システムによっては、たとえば、現在のシステムメモリの一部が入っているかもしれない。
この動作を抑制するには、‘--exact’ オプションを使用すればよい。
すなわち、デフォルトでは、1 ブロック 512 バイトのシステムで
10 バイトの通常ファイルを shred すると、結果として 512 バイトのファイルが出来上がる。
だが、このオプションを使えば、shred はファイルの見かけのサイズを増加させないのだ。
通常、shred は、最後の 1 回でもランダムデータを書き込む。
そんなファイルがハードディスクにあると、(たとえば、暗号化されたデータに見えて)
目立ってしまうのではないかと思うのなら、あるいは、単にそっちの方がもっとすっきりしていると思うのなら、
‘--zero’ オプションを指定して、もう一回、 すべて 0 ビットで上書きさせればよい。
これは、‘--iterations’ オプションで指定した上書き回数のほかに、もう一回ということである。
第 1 ドライブのフロッピーディスクに作成したファイルシステムを跡形もなく消し去るには、 次のコマンドを使えばよいだろう。このコマンドで “1.44MB” (実際には 1440 KiB) のフロッピーを消去するには、約 20 分かかる。
shred --verbose /dev/fd0 |
同様に、ハードディスクの選択したパーティションからすべてのデータを消去するには、 以下のコマンドを打ち込めばよい。
shred --verbose /dev/sda5 |
最近のディスクでは、1 回の書き込みで十分なはずだ。 それならば、書き込みを 3 回行うデフォルトの 3 分の 1 の時間ですむ。
# 擬似ランダムデータを 1 回書き込む。デフォルトより 3 倍速い。 shred --verbose -n1 /dev/sda5 |
念のため、少なくとも 1 回は擬似ランダムデータで上書きをした方がよい。 言い換えると、つい使いたくなっても、‘-n0 --zero’ を使ってはいけない。 ディスク・コントローラの中には、すべてが 0 のブロックを書き込む際に、処理の最適化を行っているものがあり、 そのため、ブロック中のバイトすべてがクリアされない恐れがあるからである。 SSD の中には、まさにそういうことをするものがある。
‘-’ という file は、標準出力を表している。 これの使い道は、削除したテンポラリ・ファイルを shred することである。 たとえば、次のようにだ。
i=$(mktemp) exec 3<>"$i" rm -- "$i" echo "Hello, world" >&3 shred - >&3 exec 3>&- |
しかしながら、‘shred - >file’ というコマンドを使っても、ファイルの内容を
shred することにはならない。なぜなら、シェルは shred
を呼び出す前に、ファイルをサイズ 0 に短縮 (truncate) してしまうからである。
‘shred file’、あるいは (Bourne 互換シェルをお使いなら) ‘shred - 1<>file’
というコマンドを、代わりに使った方がよい。
終了ステータス 0 は成功を示し、0 以外の値は失敗を示す。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document was generated on June 7, 2022 using texi2html 1.82.