データの安全性について考える (3)

ディザスターに備える

前回、前々回とデータの安全性について触れてきました。前々回は物理攻撃に対する対策として全てのストレージの暗号化を、前回は不正アクセスからシステムを守るための対策として基本的なセキュリティ設定と未知の脅威への対策を紹介しました。さて、果たしてこれで本当に重要なデータが保護されるには十分でしょうか。答えは否です。どんなに堅牢な保護がなされた計算機であろうとも、たとえば大規模な災害だとか、競合他社や対立勢力による襲撃、敵対国家による侵略、人為的な事故や内部関係者の犯行等によって、脆くも破壊される可能性があります。これではせっかく厳重に保護した貴重な分析用データが失われてしまうことになりかねません。今回はこのような脅威にどう備えデータの保全を実現したら良いかという話をします。

多重管理

最も基本的な備えとして、たとえば東京と大阪のように地理的に離れた拠点に多重にデータをレプリケーションするという考えがあります。東西で同一のシステムを稼動させておき、たとえば cron で一日一回 rsync することで、片方のシステムが災害に見舞われてももう片方のデータを基に復旧させることができるようになります。これは単純な rsync でも良いですし、もう少し作りこまれたソリューションを利用することもできます。

世代バックアップをする

単純に rsync で遠隔地にデータを複製するだけでは、たとえば毎日レプリケーションしていたとして二日後に何らかの問題が発覚したときに復旧ができなくなります。そこで毎日の差分から履歴を取得、何日前の時点にもデータを戻せるようにしておくべきでしょう。前述のソリューションでもそれは可能ですし、たいていのバックアップソフトウェアには世代バックアップの機能が備わっています。純粋に rsync コマンドを利用する場合でも世代バックアップは可能です。

三ヶ所以上の拠点を確保する

たとえば東京と大阪のように二ヶ所の拠点では、たまたま同時に大規模な災害が発生しないとも限りませんし、同時多発テロの標的となって爆破されるといった可能性もあります。そこで関東、関西に加え、九州や北海道のように本州以外のバックアップ拠点を確保しておくとだいぶ安全性が高まります。また可能であれば海外に拠点を確保するのも良いでしょう。ただし海外拠点の場合、関連法規が現地のものとなりますから思わぬところでトラブルにならないよう良く確認しておいたほうが良いでしょう。たとえば強力な暗号が禁止されていたり、政府や軍事組織の介入や圧力によってデータの開示を強制されるといった恐れが無いとも限りません。たとえばひとつの例として英国にサーバーを設置した場合、英国警察に復号用鍵の提出を求められこれを拒否すると犯罪扱いになってしまうという問題があります。

オフラインメディアで退避する

すべてがオンラインバックアップのみですと、万が一にもシステムの全操作系統を攻撃者に掌握されたり、あるいは何らかのミスや事故で全データが喪失してしまった場合に復旧ができなくなります。定期的にスナップショットを取得し、オフラインのメディアにデータを退避、これを遠隔地へ護送すれば直近の状態までデータをリカバリーできる可能性が高まります。

信頼できる業者を選定する

大切なのはバックアップしたメディアの取り扱いです。これを奪われ攻撃されると、当然全データを暗号化しているとはいえ、いずれは解読されてしまう可能性が出てきます。現段階では事実上不可能でも、たとえば将来量子コンピュータが実用化されたときに現代の暗号強度では耐えられないといったことも有り得ます。そこで記憶媒体の取り扱いとしては記憶媒体専用の金庫に厳重に施錠して梱包格納し、信頼できる専門の業者に委託して、安全な場所で保存管理してもらう必要性があります。業者の選定まではこの記事では触れませんが、データ保管サービスを提供している会社は複数ありますのでデータの重要度にもよりますが基本的にはこういったサービスを利用すると良いでしょう。またこのときも保管場所が都心などではなく地理的に離れた安全な拠点であるかどうか確認しましょう。

障害からの回復をする

記憶媒体の障害は突然やってきます。たとえ定期的に S.M.A.R.T. の情報を監視していたとしても完璧ではありません。障害が発生すると当然そのデータは喪失してしまいますので直ちに障害対応が必要となります。ここでは前々回説明した暗号化 LVM でデータを利用している際に障害が発生したケースを仮定して障害対応について追っていきます。またファイルシステムは ext4 とします。記憶媒体が LVM の一部として利用されている場合、まずは LVM から離脱させなければなりません。

状況を確認する

障害の起こった記憶媒体上の位置を確認します。これは S.M.A.R.T. のレポートあるいはシステムのログメッセージなどから把握します。

# ファイルシステムの状態を確認する
df -h
# vg を確認する
vgscan
# lv を確認する
lvscan
lvdisplay
# tune2fs でパラメータを確認する
tune2fs -l /dev/vg-hoge/lv_fuba

計算機のハードウェアの性質にもよりますが、新しい記憶媒体を追加可能であればそちらにデータを移動すれば良いのですから、記憶媒体を追加して pvmove すれば大丈夫です。何らかの事情で障害の発生した記憶媒体を取り外さないと新規の記憶媒体を追加できない場合、後述の作業が必要になります。

アンマウントする

ext4 の場合、オンラインリサイズはファイルシステムの拡張のときのみ可能です。縮小する場合はアンマウントする必要があります。そこで必要な分だけデータを減らした上で該当のパーティションをアンマウントします。

sudo umount /data

ファイルシステムを縮小する

定石として resize2fs の前にはまず e2fsck しなければなりません。

e2fsck -f /dev/vg-hoge/lv_fuba
resize2fs /dev/vg-hoge/lv_fuba 500G # 新しいサイズを指定する
lvreduce -L 515G /dev/vg-hoge/lv_fuba # LV を縮小する

LVM から切り離す

LV が十分に縮小されていれば pvdisplay したときに使用エクステント数が 0 の PV が観測されるはずです。この状態になれば該当の PV を LVM から切り離せます。あとは物理的にディスクそのものを取り外せば良いです。

pvremove /dev/vg-hoge/lv_fuga # PV から抹消する
vgreduce vg-hoge /dev/mapper/sdb_crypt # VG から切り離す

次に新しいディスクを換装して前々回の暗号化パーティションの生成からやり直せば完了です。

まとめ

前々回の物理攻撃の対策、前回の侵入者による不正アクセスの対策と続いて、今回は不意の障害や思わぬ災害への対策を説明しました。貴重なデータが失われたり漏洩しないよう、様々な角度から考えなければならないことが改めて認識されたかと思います。