スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

ハードディスクデータの完全消去その3、代替領域

前回、ハードディスクの上書き回数について書いていて、結論が出たくらいのところで突然俺は代替領域という言葉を出しました。代替領域、何なんでしょう?これはWikipediaのデータの完全消去のページのページにも突然何の前触れもなく登場する言葉です。

実はこれとデータの完全消去の問題について警告を発しているサイトがあったのです。そのサイトを読んだ奴が、きっとよくわかっていないくせにWikipediaに書き込んだのでしょう。俺もよくわかっていないくせにこれからいろいろ書きます。これは自分のブログだからね。好きにさせて。

そのサイト、今はもう消えています。消えてはいますが、俺には結構印象深い内容だったので覚えています。その記憶を頼りに書いてみましょう。

ハードディスクには不良セクタの発生に備えた代替領域というものが存在する。不良セクタが発生すると代替領域でカバーするため、少々不良セクタが出たくらいではハードディスクの見かけ容量が減ったりはしない。ただ、この内部処理は全てハードディスクの制御装置内で行われるので、パソコンからは直接制御できない。そのため、この領域に書かれた情報は削除できない。ゼロフィル (つまり全領域への0値の上書き) をしても、この領域に書かれた情報には及ばない。

こういう内容でした。ちなみに昔のNEC独自規格のパソコンPC98の中にはここへの直接アクセスができるものがあるそうで、それを使って直接代替領域に強制的に情報を書き込んだ後、PC/AT互換、つまり通常のパソコンに接続してゼロフィルし、PC98に接続しなおして代替領域を強制的に読み出し、データが変わっていないことを見せて代替領域にはゼロフィルが及ばないことの実証をなさっていました。

ただ、これには自分はちょっと納得いきませんでした。内部処理にはパソコンは直接干渉はできないいとしても、不良セクタの代替として実際に使われるようになった代替セクタについては、直接アクセスできるようになっているのではないでしょうか?つまり、パソコンから代替セクタに直接アクセスは不可能でも、内部的に代替処理されているならば、その不良セクタへの書き込み命令が代替セクタへの書き込みに内部処理され、実質的に代替領域へのアクセスは可能になっているのではないでしょうか。そうでなければ代替領域の意味がないはずです。

よって、ゼロフィルは代替 (のために確保されている) 領域全体には及ばなくても、代替「された」領域には及ぶはずです。そして、消去されるべきは前者ではなく後者でしょう。だから心配することは無いのでは?と。あの実験でも、例えば不良セクタが代替領域を使い切るほどに出たハードディスクで行ったら、強制的に書き込んだデータも消えていたのではないでしょうか。



残念ながら、これは俺の認識不足だったようです (あのサイトの説明も少なすぎたと思うけど) 。どうやら、ハードディスクの代替領域が使われるのはその場合だけではなさそうなのです。

不良セクタ , 不良ブロック とはなにか- ハードディスク 番長

こちらのサイトによると、一旦読み出し不良が生じたとしても直ちにそのセクタを諦めるわけではなく、データの読み出しを何度かリトライするのだとか。そしてなんとか読み出しに成功した場合、その情報を代替領域にコピーしておくのだそう。そしてその不良の疑いのあるセクタに再書込を行い、時間をおいて読み出し再試験をすると。読み出し再試験に失敗した場合そのセクタは不良セクタ扱いとなってコピーされた代替領域のセクタがそのセクタと取って代わり、成功した場合は何事もなかったとされる、のだそうな。

ここなんでしょうね問題は。この不良の疑いのあるセクタの回復ができた場合、不良セクタの代替セクタとして予約されたコピーセクタは放棄されるのだと思われます。不良の発生がなかったのは嬉しいことではありますが、消すことのできない情報の破片が、このとき発生してしまうのでしょう。

これはどうしたらいいんでしょうね…不良セクタとして確定し、代替処理がなされるとSMART情報で確認することができますが、不良セクタからの回復についてはSMART情報に載るものなのでしょうか。196 Reallocated_Event_Count がそれっぽく見えますが、でも残念ながら、ネットでSMART情報を曝してくれている人々の情報を読むに、5 Reallocated_Sector_Ct つまり確定した不良セクタよりもこの数値が低いことが低いものが見られるので、私の求めているものとは違うように思えます。

どうしましょうか。もしSMART情報からそれが行われていないと確認できれば安心なのですが、もしそれをSMART情報からは読み解くのが不可能な場合、あるいは読み解けて、情報待避からの回復が確認できた場合。

んー、まあそれが流出を防ぎたいデータにズバリ当たっている可能性は低い、当たっていたとしてもゼロフィルしてしまえば前後のない4KBのデータの残骸になってしまうわけで、危険は低いと考え無視するか、もう物理的に破壊するか、ですかね…。NSAは現在、ハードディスクの完全消去規格を消磁もしくは物理破壊に切り替えたようですが、本当に流出しちゃいけないデータを扱う場合にはもうそれしかないのかも知れません。ただ、前々回の話に戻りますが、どこまで物理的に破壊すれば復旧不能と言えるのか、まるでわかりません。

あるいは、最初から全体的に暗号化するべきなんでしょうね、絶対に流出させてはいけない情報を扱う予定のマシンは。



なんかよくわからない話になりましたね。まとめましょう。

・ハードディスクの完全消去は誰にでも必要。社会的立場に差し障る可能性があり、特にマシンを手放すときはやっておくべき
・ゴミ箱に入れ、空にするだけではデータは残る。一般に流通しているアプリケーションソフトで復旧可能
・フォーマットしてもデータは残る。これも一般レベルで復旧可能
・少々の物理的破壊ではプロの手にかかれば復旧可能。NASAが依頼するような業者に、一般人も依頼することが可能。どこまで破壊すれば彼らにも読めなくなるのかはわからない
・無意味なデータでディスクの全領域を上書きすることでデータは消せる
・かつては多重に上書きすることが推奨されていたが、一般人レベルでは一回全領域上書きをすれば復旧はまず不可能。現在はプロの手にかかっても一回の上書きでほぼ復旧不可能とされているようだ
・それでもデータ処理の残骸が、ハードディスクの一部に存在する可能性がある。これは通常の操作では消すことができない。

どうしたらいいか

・全領域の上書きのみ。代替領域の残骸の可能性は無視
・全領域の上書き+可能な限りの物理的破壊、特にプラッタを念入りに+数回に分けてゴミに出す
・最初から全領域を暗号化した上で使う

どれか好きなのを選んでください。

スポンサーサイト

テーマ : セキュリティ
ジャンル : コンピュータ

ハードディスクデータの完全消去その2、多重に上書きをする必要はあるか

ハードディスクから情報を完全消去するための上書きの話の最中でした。

多重に上書きをすることを求められるのはなぜでしょう?ネットに転がっているいくつかの資料を読む限りでは、残留磁気からのデータの復元を防ぐ、みたいな話が見えます。残留磁気ってなんでしょう?前回も言いましたが、もし一回の書き込みで不十分だとしたら、それはただ単に書き込み不良であるはずです。どうもよくわからないのですが、想像するにはこういうことでしょうか。


File:Hdd medalist.jpg - Wikimedia Commons より引用

ハードディスクドライブはこのような四角い箱で、我々はこれに線を繋いで使うだけですが、


File:Hard disk platters and head.jpg - Wikimedia Commons より引用

中はこのようになっていて、磁性体であるディスクが回転し、その上をヘッダが走査して磁気記録を読みこんだり、書き込んだりしています。ディスクの上に乗っているレコード針のアームのようなものの先端がヘッダですね (ちなみにハードディスクは精密機械で塵や埃に弱いと言われており、使用と続けたい場合には開けてはいけません。ハードディスク復旧業者も開けずに復旧できる場合には極力開けないそうで、開ける場合にはクリーンルームでの作業となるそうです) 。要するに、データはディスク上の磁気として存在しているのです。

磁気で記録すると言えば、今の20代以下には馴染みが薄いでしょうが、30以上にはカセットテープが思い出されるのではないでしょうか。カセットテープは音声を、磁気のアナログデータとして保存していたものでした。デジタルの記録メディアには考えにくい話ですが、一回使ったカセットテープを使いまわして録音すると、前に入れた曲が完全に消えておらず、新しく入れた曲に重なって薄っすらと聞こえてきた、なんて話もありました。俺は経験無いですが、人の話としてそういうことを聞いたことがあります。

そう、ここです。デジタル情報としては「0」「1」とはっきり区別できる磁気記録も、ディスク (プラッタ) 上の磁気記録をアナログ的に見れば、0の上に0を上書きしたもの、1の上に0を上書きしたもの、0の上に1を上書きしたもの、1の上に1を上書きしたものは、微妙な磁気の差で区別できる可能性はないとは言えないのでは。この判別ができるとすれば、一回上書きしたくらいではデータの復元は全く可能であることになります。

また、ヘッダが走査するトラックの直下は綺麗になっているとしても、トラックとトラックの間はどうでしょう。全く隙間がないということはないはずです。もし隙間がなければ、あるトラックへの書き込みが、書き込みたくない隣のトラックに影響してしまうでしょう。というわけで物理的に一定の隙間はあると思われるのですが、ここも磁性体があるとすれば、ここに旧データの痕跡が残ってしまう可能性は否定できないでしょう。

というわけでこれらのデータの痕跡を、何度も上書きすることで隠蔽していくのだと思われます。ピーター・グートマン博士という方が書かれた論文では30回以上も上書きをすることが説かれていたということです。俺はその論文そのものは読んでいませんが…

た・だ。通常のハードディスクのヘッダに、その微妙な磁気の差が読み取れるかどうか。これが検出限界以下になっていてくれないようでは、おそらく普段ハードディスクを使っている最中から読み取り・書き込み不良の原因となって問題となるはずです。例えば、何度も上書きを繰り返した結果その微妙な差がノイズとなって蓄積され、運悪くある特定の形となった場合、0と書いたはずなのにそのノイズと合わせて1になってしまうなんてことも考えられるでしょう、そこまで都合のいいことはないとしても読み出し不良レベルなら頻発しそうです。また、いずれにしても制御装置でノイズは不要なものとして捨てているはずです。SATA端子からはデジタルなデータが出力されているはずで、そのノイズは読み出せないと思われます。

また、トラックとトラックの間をヘッダに読み取らせるためには、どういう制御信号を送ったらよいのでしょう。そして、そのアナログなデータをどうやって読み出すのか。先ほどと同じように、SATA端子からはできない作業が必要だと思われます。それに特化した特別製のヘッダと制御装置を用意すれば可能ではあるでしょうが、グートマン博士が論文を書いたのは20年前、当時のハードディスクと現在のそれとではデータの密度が全く違います。当時一般用のハードディスクは3GB程度、現在は云TBのレベルですからね。その特別製の機械に要求される精度も全く異なってきているはずです。

よって、通常のデータ削除は一回で十分ではないかというのが私の思うところです。それだけの技術を用いる価値のある情報を扱っているのでなければ。米NISTも2001年以降の15GB以上の高密度なハードディスクは一回上書きすれば十分と発表しています。また、このような記事もありました…

“迷探偵”ハギーのテクノロジー裏話:デジタル・フォレンジックにおけるデータの完全消去と復元の「微妙な関係」 (1/2) - ITmedia エンタープライズ から引用-----

理系の大学院生からこういう質問を受けた。

 「グートマン論文(ピーター・グートマン博士が1996年に発表したデジタルデータの消去方法に関する論文)では元のビット列が分からないようにするために、35回とか、36回とかデータを上書きしないといけないわけですよね。それなら、数回くらいの上書きならフォレンジック調査で復元できるのではないですか? 上書きされたものは復元をしないのですか?」

 筆者は「復元はしません。と言うよりできません」と答えている。結論を言うと、今のHDDは材質や磁気の記録方式、その他ありとあらゆる部分において、一度でも上書きしてしまうと復元はほぼ不可能になっている。しかし、昔のものであればある程度は可能だった。

 この10年ほどの間に製造されたほとんどのHDD製品、最近なら記録容量が2テラバイトや3テラバイトもあるHDDでは絶対に不可能である。最新のHDDの外観は昔のHDDとたいして変わらないが、筆者が初めて自費購入したPCのHDDの記録容量は170Mバイトだった。つまりは見た目が同じでも、最新のHDDは昔のHDDの何万倍という記録密度を実現している。前述の通り、材質も記憶方式も、ファームウェアもソフトウェアもハードウェアもそれらの全てがとても復元可能な状態にないのだ。

 なお非常にまれではあるが、1回の上書きでは正確にデータが上書きされないケースがあった。ビット列を精査すると分かるのだが、ビット列が指定通りに上書きされないのだ。だが、そのことがHDDの同じ場所で起きる確率を考慮しても、現実的には2回の上書きで復元は不可能だと断言してもいい。もし企業で完全消去ソフトをお使いの場合、上書き回数を3回以上に設定されているならそれは意味が無い。1回でも通常は十分なのだ。国家機密レベルのデータでも2回で十分と考えて差し支えない。

-----引用ここまで

だそうです。

ちなみに代替領域が問題だという話も前に見つけ、書きました。これについては長くなってしまいそうなので次回に

テーマ : セキュリティ
ジャンル : コンピュータ

ハードディスクデータの完全消去その1、必要性とその方法

さて、ハードディスクの完全削除をこの前やったわけですが。これについて、俺はちょっとどうしても色々考えてしまいます。前にも何度か書いたことですが、もう一度まとめさせてください。


そんなものは必要か?

誰にでも必要だと思います。自分のパソコンにはそんな大事なデータは入れていないって言う人もいるでしょうが、例えば仕事で使うデータやらなにやらを、一切自分のPCに保存していないと言い切れる人はいるでしょうか?あなたがPC上でそのデータを開いていたら、どこかに一時ファイルが保存される可能性はあります。かなり高いと思います。それが流出したら問題になるものなら、消さなきゃいけませんよね。

また、メールソフトの設定ファイルとか。これも流出したら困るものです。流出して中身覗かれても困らないよって一瞬は思うかも知れませんが、じゃあやり取りした相手のメールアドレスは?あるいは、スマホでもそのメールアカウントを使っていたとしたら、そのアカウント上にはアドレス帳そのものがアップされているかも知れませんね。それらは、あなたが責任を持って管理しなければならない、他人様の情報です。また、そのアカウントが迷惑メールの送信に使われたら?あなたの社会的信用に関わりますね。社会的信用に関わるような事態にならなかったとしても、それでメールアカウントを乗っ取られたら困るのは間違いないでしょう。

だから誰もがするべきことです。問題はその方法。どうしたらいいのでしょう。



1. ゴミ箱に入れ、空にする ×

漏らしてはいけない情報の入っているファイルを、ゴミ箱に入れ、空にするコマンドで消す方法です。これは実は全く効果がありません。というのも、実際には削除していないからです。どういうことなのか、昔のパソコン入門書にあったような解説をしますと…

あなたはハードディスクという本棚を持っていますが、管理は専門の秘書 (ハードディスク内の制御装置) に任せています。秘書は律儀に目録を作って本棚を管理しています。あなたが秘書にAという資料が要らなくなったから処分しておいてと頼むと、その秘書は直ちに資料Aを目録から消しますが、資料Aそのものはその場で捨てることはありません。本棚が一杯になるなど、新たに保存したい資料のスペースが足りなくなったら、確保したいスペースの分だけ目録から消された資料をを捨て、新たに保存したい資料と入れ替えているのです。

不思議な方法を取っているようですが考えてみればこれは当然のことです。今の世代にはわかり辛い例えでしょうが…テレビがアナログで、録画メディアはテープだった時代。録画した番組を見終わって、もうこれを見ることはないと確信している場合でも、その場で消去なんてことはしなかったですよね。別の番組を録画したい時に、空のビデオテープのストックがなかったら、そのいらないのを使いまわし、上書きするという形ではじめて消していたはずです。そういうことです。

よって、実はゴミ箱を空にしても、データはそのまま残っています。これを復元することは実は簡単なことのようで、復旧業者に頼めば復旧してもらえる他、それを家庭で実現できるソフトさえあります。決して特殊なソフトではなく一般に流通しています。よって安全ではありません。


2. フォーマットをする ×

これもデータが完全に消えるように見えますが、先ほどの秘書と本棚の例えと同じです。秘書の行っていることと言ったら、これまでの目録箱を捨てて、新しいファイルシステムにあった目録箱を新規作成しただけです。多くの場合、本棚の方には基本的に手を付けていません。これも、本棚を空として扱いますが実際に空にはなっていないパターンです。この場合も復旧はほぼ完全に可能とされています。


3. 物理的破壊 △

では、それだけ削除が難しいなら、もういっそ物理的破壊をしてしまえば文句ないだろう!別に捨てるときには壊れてても問題ないわけだし!いや、そのとおりだとは思います、が…

どこまで物理的破壊をすれば復旧不可能か、あなたにはわかりますか?

例えば水バケツに沈めてるよーなんて言っている人がネット上にはいました。残念ながらこれは大した手間もなく復旧出来てしまうと思われます。ハードディスクの復旧業者は、ハードディスクのヘッダやモーター、制御基板などのパーツを大量にストックしているようです。これで故障した部品を置き換えれば、復活できる可能性は十分にあります。水没等で真っ先に破壊されるパーツはモーターや制御基板でしょう。データが磁気記録されている円盤、つまりプラッタが無事なら、そこからデータが抜けてもおかしくはありません。

壊れたHDDなどのデータを復旧する最新設備満載「日本データテクノロジー」新オフィス見学レポート - GIGAZINE
例えばこの記事。有名データ復旧業者に取材されたgigazineさんの記事ですが、「ありとあらゆる部品交換に対応できるよう、2万個のドナーハードディスクをストック」とあります。

実際にこれらの復旧業者さんのウェブサイトでは、東日本大震災の復旧事例として津波で水没したハードディスクからのデータ復旧に成功したと書いているところもあります。

また同じくgigazineさんの記事で、大気圏再突入時に爆発して墜落したスペースシャトルコロンビア号の残骸から焼け焦げたハードディスクが事故6ヶ月後に三つ発見され、民間業者のオントラックによってひとつは99%復元できた、というものがありました。オントラックは別に諜報機関というわけではなく、個人の依頼も受け付けているところです。

空中分解したスペースシャトルから地上にたたきつけられたハードディスクのデータを復元 - GIGAZINE

よって、中途半端な物理的破壊は無意味なのです。どのレベルまで破壊すれば平気なのかわからない以上、破壊だけでは安心できないと言っていいかと思います。またそもそも、一旦データを消した上で引き続き使いたい等の場合にはこの選択肢は取れません。

ただし、故障したハードディスクを修理して情報を抜かれる危険に対処するためには、これしか方法は無いでしょうが…


じゃあどうしたらいいの?

まあ、前の記事で既に答えは出てるんですけれど。要するに全領域に一旦、ゼロやランダム値などの無意味なデータで上書きをしてしまうことです。これをすれば例の秘書も、あなたの指定した無意味なデータで本棚を埋めなければいけなくなるので、データは基本的に全て消えます。それが完全消去の上書きというわけです。

また物理的破壊をするにしても、一旦これをしておけば万が一物理的復旧が可能だったとしても取り出せる情報はないということになります。

しかし、公的機関等が定めた完全消去の規格を見ると、なんと何度も多重に上書きすることを要求するものがあります。これはどういうことなのでしょう。一回上書きして不十分だと言うのなら、それはただ単に書き込み不良ではないでしょうか。

長くなったので記事を分割します。

テーマ : セキュリティ
ジャンル : コンピュータ

ハードディスク自体の暗号化とバックアップその3、増分バックアップのできるバックアップツール

さて、暗号化パーティションの作成とマウントができ、書き込み、アンマウントと再マウントのテストもできたので、今度はバックアップツールです。

なんかもうファイル管理ソフトでの認識と書き込みができたので、ファイル管理ソフトのコピーアンドペースト機能でバックアップを取っても良い気はするのですが…だって、これからするバックアップ第一回はどんな手を使ってもフルバックアップになってしまうわけだし…よーするに心が折れかけていますが、もし今ここで心が折れるに任せてしまえばこれから先バックアップを取るべき時の度に定期的に心が折れることになります。差分バックアップを覚えなければ。

ググッていくつかの情報を仕入れたところによると、Linuxのバックアップツールでよく使われているのはrsyncというソフトだそうな。これはフルバックアップも増分バックアップも可能とか。ちょっと試してみましょうか。使い方の基本は

$ rsync -a コピー元 コピー先

だそう。オプションの-aはディレクトリ構造やファイルの所有者情報などをそのままコピーできるものだそうで、普通はつけるようです。デスクトップに適当なディレクトリ (ここでは~/Desktop/tmpとでもしておきましょうか) を作り、その中にいくつかテキストファイルをぶち込みます。ついでにいくつかディレクトリも作成、その中にも適当にファイルを作成。それで、今度はバックアップ先のディレクトリも作成 (~/Desktop/backup) 。で、

$ rsync -a ~/Desktop/tmp ~/Desktop/backup/

と打ってみると。バックアップツールというから、このツールでしか読めないようなアーカイブファイルになって出力されるのかと思いきや、意外や意外、普通にファイルがコピーされたようです。この~/Desktop/backup/を普通の、nautilusやnemo等の一般的なファイル管理ソフトで開いてみると、tmp/ディレクトリがあり、その中には普通にファイルがあります。なお、上のコマンドでコピー元を~/Desktop/tmpと指定するとtmp/ディレクトリごとのコピー、~/Desktop/tmp/とするとtmp/ディレクトリはなしでその中身のコピーになるようです。

いや、完全に見える形でのバックアップになったのは嬉しいのですが (セキュリティ問題はドライブごとの暗号化ができたので心配ない) 、これでどうやって増分バックアップを取るんだろ…。試しに入れたテキストファイルの一つを適当に書き換えて保存し直し、もう一個ファイルを加えて差分バックアップのコマンドを。

$ rsync -auv ~/Desktop/tmp ~/Desktop/backup/

オプションのuが変更のあったものだけのバックアップという意味で、vは作業状態をコンソールに表示するというもの。すると、見事に変更のあったファイルと追加したファイルのみコピーしてくれたようです。差分 (増分?) バックアップ成功です。これはありがたい。ただ、本当にこれでいいんかな?今回はコピーしたサイズが小さいので問題なかっただけであって、ハードディスクのフルバックアップなんかを取る場合、容量もディレクトリ構造の複雑さもまるで違うわけで、これで本当に差分バックアップができるのかちょっと不安ですが、まあやってみなきゃわからない。

$ mkdir /media/sdb1/backup
$ rsync -av ~/documents /media/sdb1/backup/


コピーがはじまりました。ちなみに自分の場合、ユーザーデータはほぼ全て~/documents/以下に保管していて、一部保存しておきたいアプリケーションの設定データやキャッシュ等 (だいたい「^/.アプリケーション名」もしくは~/.config/や~/.cache/以下にある) も~/documents/以下にコピーしているので、外部にバックアップする場合はここをコピーするだけで済んでしまいますが、それはみなさんの事情とお好みで。ちなみに自分はシステムごとのバックアップはしない主義なので (システムやソフトウェアは再インストールすればいいと思っている) こうですが、それもみなさんのお好みで。

さて、コピーが始まり…終わったわけですが。正確に時間を測ったわけではないものの普通にコピーした場合のだいたい二割増しほどだったように感じます。

…あ、でも、その程度で済むのだったら、高速プロセッサを持て余していて、完全にハードディスクの読み書きがボトルネックになっているようなマシンだったらほとんど差がないってことにもなるのかな。正直俺のマシンはかなり古めです。AthlonX2 BE2350 とかなり古いマシンです。まあそれでもメモリは4GBまで入れ、グラボも安物とはいえNvidiaのものを入れているので普段使いには全く快適なんですが。GNOME3もついこの前まで元気にうちのマシン上で走ってましたよ。Nautilusの頻繁な仕様変更、というか機能削減に俺が耐えかねて今はCinnamonですけれど。

で、そうだ、もれなくコピーができているか。ファイル数と容量を確認してみたところ、全部コピーはできた模様です。長時間バックアップともこれでおさらば。次からは増分バックアップが利くのです。今書いているテキストをユーザーフォルダに保存して

$ rsync -auv ~/documents /media/sdb1/backup

するとものの10秒もしないうちにこのファイルを検知し、バックアップしてくれました。

はい、あとはアンマウントと暗号化設定の消去。

# umount /media/sdb1/
# cryptsetup remove backup1


んで、一応再マウントコマンドをして確認。

# mount /dev/sdb1 /media/sdb1/

はい、エラーが出ました。マウントできません!狙い通りです。

そうだ、バックアップからの復元について。これはコピー元とコピー先の指定を入れ替えればいいだけのようです。あるいはファイル単位での破損や誤削除に対しては、いわゆるアーカイブファイルではなく通常のファイルとしてバックアップディスク内には存在しているので、それを手でコピーアンドペーストして戻すという方法もあります。

とりあえずこれで良しとします。もっと高度なバックアップツールもあるでしょうし、人や用途・業種によってはその需要も存在するとは思いますが、俺は今のところそこまでは欲していないので。

まあ、個人的に考えていたのは、日付を付けてバックアップイメージを管理できるグラフィカルユーザーインターフェースのソフトだったんですが…でも、あんまり複雑になると、バックアップが本当に必要になった時、つまりシステムトラブルが起きたときにそれを動かせない可能性が出てきます。それでは意味がないのです。あるいはDebianを、Linuxを見限り、システムを全く別のものにしたいと考える日も来るかも知れません。そのときにはデータの待避場所として使いたいのです。

今回のようにコマンドユーザーインターフェースで生データを扱うシンプルなソフトだと、トラブル時の復旧可能性が高くなると考えられ、また例えこのソフトが動かないとしても別の方法での復旧が考えられるので (先ほど言ったとおり最悪コピペ) そういう点についてはこのソフトにも分があると言ってもいいでしょう。

あともうひとつ考えていたのが圧縮なのですが、まあこれもいいでしょう。ものによっては確かに劇的に容量は減りますが、今日日多くの人のストレージを一番圧迫していると思われる画像や動画は、圧縮の効果が低いとされています。たぶんそれが使えるツールを探して、使い方を勉強したところで、効果は知れたのもでしょう。また、圧縮の方法にもよりますが生データとして扱えなくなる問題も出てくるかも知れません。やめておきます。

テーマ : セキュリティ
ジャンル : コンピュータ

ハードディスク自体の暗号化とバックアップその2、ハードディスク全体の暗号化

前回完全ゼロクリアができたので、満を持してバックアップハードディスクをドライブごと暗号化します。目的をもう一度書きますが、バックアップハードディスクは大変無防備です。パソコンならばアカウントロックがかけられますが、パソコンを分解されてハードディスクを取り出され、USBアダプタ等を付けて別のパソコンに接続されたらおしまいです。外分けハードディスクにバックアップするということは、その分解のひと手間をこちらからわざわざ省いてやっているようなものです。

そんなだいそれたものを保存していないよと思われる方もいるでしょうが、メールソフトにメールアドレスと、各メールサービス用のパスワードを保存している人は多いでしょう。それを抜かれたら、一発でメールアカウントは乗っ取られます。iPhoneのシステムバックアップをしている人は、そのデータが抜かれたらクローンのiPhoneが作られることになります。それはまずいでしょ?意外と皆、流出したら困る情報は何かしら持ってるもんです。

偉そうに言ってますが、まあ本当だったらまずシステム用のハードディスク自体暗号化するべきなんでしょうけれどね…。あるいは、WindowsやMac用の高性能なバックアップソフトを使っていたら、特に意識しなくても暗号化してくれているものなのかも知れません。偉そうなことを言っている自分が一番低レベルなのかも知れません。



まあこのくらいにして、実際にやってみましょう。バックアップに使っていた外分けハードディスクを接続し、gpartedを起動。既にゼロクリアして完全な未割当領域になっているので、ここにパーティションを作る要領で、暗号化ボリュームを…作れない?

あ、そうですね、MBRがないという警告が出ました。これは2TBのハードディスクなので、デバイス→パーティションテーブルの作成で、msdosパーティションテーブルを作成。これでパーティション操作ができるはずです。今度こそ暗号化パーティションを…やっぱり作れない。これでパーティション操作ができるいろいろクリックしてそれらしいものを探してはみましたが見つかりません。Debianをインストール時のパーティション作成ツールのような奴はないのでしょうか。あれで出来てgpartedでできないことがあると?てか俺が何か根本的に勘違いをしている?

いきなり困りました。なんかいい方法がないかと適当なキーワードでぐぐってみると。このようなページを発見。

暗号化ファイルシステムを使ってみる - いますぐ実践! Linuxシステム管理 / Vol.184

他にもいくつかのページを見てみたのですが、どうやらドライブ全体を暗号化するにはcryptsetupというコマンドをコンソールから使うのが通常のようです。

では、そのcryptsetupをインストール。

# apt-get update ; apt-get install cryptsetup

まあもう当たり前ですが、Linuxで使われる大抵のオープンなソフトはDebianが用意してくれています。ありがたいことです。

んで、上記ページによると、cryptsetupで暗号化するのはドライブそのものというよりパーティション単位くさいので、gpartedで未使用領域にext4ファイルシステムを作成。これで/dev/sdb1ができたわけです。



んで、上記ページを読んで大体の使い方を探ると。どうやら流れはこのようです。

cryptsetupで目的のパーティション (今回は/dev/sdb1) を、任意の名前を付け、暗号化方式とパスワードを指定して読み込むと、/dev/mapper/にその名前をつけたファイルが出現。そのファイル上にext4などのファイルシステムを作成するコマンドを打ち、そのファイルをドライブとしてマウントすると、目的の暗号化されたパーティションに普通に読み書きができるようになるそうな。用が済んだらアンマウントして、/dev/mapper/内に生まれた暗号化パーティションへのリンクを取り除くコマンドを打つ、と。

通常なら/dev/sdb1とかをマウントするわけですが、このcryptsetupとやらで生まれる/dev/mapper/内のファイルを通じてフォーマットしたりマウントすることで、暗号化/復号しながらの読み書きができるということでしょうか。まあやってみなきゃわからないのでとりあえず実行。

# cryptsetup create -y -c aes-xts-essiv:sha256 hogehoge1 /dev/sdb1

パスワードの入力を求められたので、例の紙からパスワードをつくりだして入力。すると確かにhogehoge1というファイルが/dev/mapper/に現れました。ここにext4ファイルシステムを作成するコマンドを。

# mkfs.ext4 /dev/mapper/hogehoge1

完了したら、これをマウント。

# mount /dev/mapper/hogehoge1 /media/sdb1/

これでファイルマネージャを立ち上げてみると、確かに「2.0 TB ボリューム」という項目ができていて、中身を見ることができます。なにかここにファイルを移してみようとしてみたところ。あ、書き込みができない。これはファイルの書き込み権限がユーザーに与えられてないというやつですね。単純なミスです。

# chmod 777 /media/sdb1

これで書き込めるようになったはずです。で、適当に何かをファイルを入れてみましょう。んで、

# umount /media/sdb1

アンマウントして、

# cryptsetup remove hogehoge1

/dev/mapper/hogehoge1を除去。

では暗号化されているか。普通に繋いでみましょう。USBケーブルを外し、しばらく待ってもう一度つなぐと。普段は自動でマウントしてくれるはずですが、それがなされませんでした。gpartedで確認したところ接続したドライブは/dev/sdb1のままのようなので、

# mount /dev/sdb1 /media/sdb1/

コマンドで強制マウントしようとしてもみましたがエラーになる様子。そもそも先程のgpartedでも/dev/sdb1のファイルシステムが不明となっています。良いんじゃない良いんじゃない?

では、上記ページの「2回目以降の使い方」より再マウントしてみましょう。

# cryptsetup create -y -c aes-xts-essiv:sha256 hogehoge1 /dev/sdb1

ちなみにこのとき最初に指定した暗号化方式も正確に入力しないといけない模様です。そして最初に入力したパスワードを入力。これが正確に入力できてないとダメなのは当然ですね。

# mount /dev/mapper/hogehoge1 /media/sdb1

んで、ファイルマネージャ内に現れる「2.0 TB ボリューム」にアクセスしてみると。たった今投入したファイルがありました!中身も文字化けしたりはしていません!これで暗号化は大丈夫そうです。なお、暗号方式やパスワードの入力を間違えていた場合、ここでマウント失敗するようです。その前にパスワードが誤っているとか、暗号形式が誤っている等の警告は出ないようです。まあ不便といえば不便ですが、セキュアでもあるのかな。

まあとにかくマウントは無事出来ました。あー、次は簡単に使えて、差分バックアップも簡単にできるバックアップツールか…。なんか頭が痛くなってきたので次回

to do リスト
・外分けハードディスクのオールクリア (済)
・暗号化パーティションの作成 (済)
・バックアップソフトウェアの選択とバックアップ実行

テーマ : セキュリティ
ジャンル : コンピュータ

ハードディスク自体の暗号化とバックアップその1、まずはディスクの完全消去

前に外分けハードディスクの暗号化をしてみたいと書きましたが、それを実践してみます。それに先立ち、もともとこのディスクには生でデータを保存していたので、その情報が抜かれる可能性を考え、データを綺麗に削除しましょう。ddコマンドで全領域を上書きしてしまうのです。

# dd if=/dev/zero of=/dev/sdb

時間はかかりますが、全領域上書きはハードディスクを破壊せずにデータを消す唯一の方法です。ハードディスクはゴミ箱を空にしようが、再フォーマットをしようがデータは消えないのです。というのも、これらの操作はディスク上のインデックスに当たるものを消すだけなので、実データは残ってしまうのです。それら実データが残っている領域は空き領域として扱われ、データを書き込んでいればそのうちに上書きされていきますが、それまではデータが残っています。ので、一度でも使ったハードディスクを新たに暗号化してデータを保護しようと思うなら、その前にオールクリアしておかないと意味が薄いのです。

上記コマンドでは/dev/sdbの全体に一回だけ0を書き込むことになります。これがデータ消去として十分かという話は別記事で書きます (結論を先に言っておけば一応十分だろうと考えています) 。なお、今自分の外分けハードディスクは/dev/sdbで認識されているのでこれですが、それはそれぞれの環境と時によって違うので、よく確認してください。自分はGPartedで確認しています。

ただ、時間はかかります。USB2.0で接続していると、書き込み速度は最大でも30MB/s程度になってしまうので、2TBのハードディスクの全領域を上書きするには18時間以上かかるはずです。ではおやすみなさい…

---丸一日経過---

---丸二日経過---

---三日目の朝---

なげーよ!長いよ!まだ終わりません。これは何かがおかしい。もしかしたらソフトウェアのバグか何かで処理がループしているとか、異常が起きている可能性が高いので、Ctrl+Cキーを押して中断。すると…

なんと恐ろしいことに、書き込み速度が2.2MB/sしか出ていません。そしてまる二日と一晩経っているというのに、500GBも書けていません…どういうことなの?2.2MB/sの書き込み速度と、その進捗具合を計算して確認するとだいたいあっているので、心配した処理がループしたとかそういうことはなさそうです。要するにただ単に速度が異常に遅かったと。

一体何が問題なのか…ググってみるとこんなものが引っかかりました。

dd - 自宅サーバWiki
時間がなくて早く終わらせたい人は
# dd if=/dev/zero of=/dev/sd bs=1024
という風にbsの値を大きくしてあげれば多少早くなる可能性あり。


これ試すか…。でも、なぜ速くなるのでしょう。そしてそれによって問題は生じないでしょうか。人間のレベルで言えば、速く物事を処理しようとすればミスが生じたりするものです。ただ、2.2MB/sは完全に異常ですし、実用的では無いです。これはなんとかしなければいけません。

というわけで、やります。やりますが、ミスが出るかどうかも確認したい。まずは、ここまで処理したハードディスクの内容を確認します。全体をチェックするのは時間がかかるので先頭1GBだけ。

# hexdump -C /dev/sdb -n 1073741824
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
40000000


これだけの出力が得られました。これは全部ゼロだったので省略された結果だと思われます。まあデフォルトなので当然でしょうが、512バイト単位で書き込んでいくことは基本的に遅い以外の問題は生じないと。では、一旦これにランダム値の書き込みをしてみます。これも先頭1GBだけ。

# dd if=/dev/urandom of=/dev/sdb bs=512 count=2097152
2097152+0 レコード入力
2097152+0 レコード出力
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 671.892 s, 1.6 MB/s


同じく512バイト単位の書き込みなので遅いのはわかりきっていましたが、やはり遅いです。まあいい、これも書き込みが成功しているか確認。

# hexdump -vC -n 1073741824 /dev/sdb

-vオプションをつけたのは省略を避けるためですが、はい、出力が大変なことになりましたよね。ざっと見て書き漏らしがなさそうなら、つまり00の値がどこかで異常に固まっていたり、定期的に出ているようでないことがわかれば、Ctrl+Cを打って止めましょう。

では、ここに4096バイト単位でゼロを書き込んでみます。4096としたのは512の倍数であること、あとこのハードディスクの物理セクタが4096バイトであるためです。これなら書き損じが生じるとかの問題は少なかろうと。

# dd if=/dev/zero of=/dev/sdb bs=4096 count=262144
262144+0 レコード入力
262144+0 レコード出力
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 39.0429 s, 27.5 MB/s


あれ?なんだこりゃ。一転めっちゃ速いです。というかUSB2.0の実効速度に近い速度が出ています。では、これを確認してみましょう。

# hexdump -C /dev/sdb -n 1073741824
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
40000000


この通りの出力が得られました。つまり、512バイト単位で書こうと、4096バイト単位で書こうと、直接それが原因で書き損じが生じることはないということです。USB2.0で、実セクタ4096バイトのハードディスクを使っている方は、4096バイトで書き込めばいいと思います (ただ、これはうちの環境でたまたまって可能性もないとは言えないので保証はしません) 。

んー、じゃあ、改めて4096バイト単位で全領域をクリアしましょう。

# dd if=/dev/zero of=/dev/sdb bs=4096
dd: '/dev/sdb' の書き込みエラー: デバイスに空き領域がありません
488378647+0 レコード入力
488378646+0 レコード出力
2000398934016 bytes (2.0 TB, 1.8 TiB) copied, 71693.9 s, 27.9 MB/s


はい、全部書き込まれ、これ以上書けないというエラーが出て終了です。だいたい20時間だからまあこれでよいのでしょう。USB3.xを使っている方はまた事情が違ってくるでしょうが、うちのマシンは化石のごとく古いので3.0には対応していないんですよ。PCIeも1.1なので、ボートを追加してもこれがボトルネックになって意味がないのです。あー、さすがにそろそろマシン買い換えたいなあ…

しかし、マシンを買い換えるにしてもデータの移し替えはしなければならないわけで。バックアップはしなければなりません。というわけで話を先に進めたいのですが、長くなったので一旦ここで切ります。続きは次回

to do リスト
・外分けハードディスクのオールクリア (済)
・暗号化パーティションの作成
・バックアップソフトウェアの選択とバックアップ実行

テーマ : セキュリティ
ジャンル : コンピュータ

プロフィール

ざっぱー

Author:ざっぱー
(この画像について)

当ブログについて
メール
(このメールアドレスへの特定電子メール (迷惑メール) の送信はお断りします)

最新記事
最新コメント
最新トラックバック
月別アーカイブ
カテゴリ
検索フォーム
RSSリンクの表示
リンク
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。