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

# セキュリティの重要性を再考する

研究用および分析対象のデータの保全については度々注目が集まります。閉ざされた会社や研究機関、大学などの管理下にあれば比較的安全でしょうが、昨今ではクラウドなどが全盛でありインターネット経由でネットワークアクセスすることもしばしばあります。また侵入者を厳しく検査する堅牢なデータセンターに機器があるとは限らず、オフィスや研究所のフロアなどに計算機が置かれるケースも多々あるでしょう。侵入者がネットワーク経由あるいは直接に物理攻撃を仕掛けてきた場合、これに対する充分なセキュリティ対策が施されていないと、場合によってはセンシティブなデータが広く漏洩し社会問題になってしまうことになってしまいます。こういった事態を防ぐために、データのセキュリティについて今一度考えていきます。

## 物理攻撃への対策

データを格納したストレージが何者かによって直接触れられた場合、データの盗聴、改竄、破壊といった被害を受けることがあります。このリスクを軽減するための策が暗号化です。

昨今では暗号技術基盤も成熟しており、追加の資金を用意しなくとも、無料で堅牢な暗号を施すことができます。

## システム全体を暗号化する

Linux カーネルに備わった [dm-crypt](http://en.wikipedia.org/wiki/Dm-crypt) は [Device-mapper](http://en.wikipedia.org/wiki/Device_mapper) を利用して強力な暗号化ファイルシステムを提供します。最近ではほとんどのディストリビューションでセットアップ時にシステム全体に暗号化 LVM を採択する選択肢が用意されており、重要なデータを扱うシステムであれば必ず採用するべきでしょう。データパーティションのみの暗号化は不十分で、非暗号化領域に攻撃用のプログラムを仕掛けられる可能性があります。必ずシステム全体を暗号化しましょう。

### ストレージの追加について考える

さて、暗号化したシステムにストレージを新しく追加増設した場合、これも暗号化しなければなりません。ここで選択肢としては二つあります。

* システムの暗号化 LVM に追加で組み込む
* サードパーティー製の暗号化プログラムで暗号化して取り扱う

まずは主に前者について説明していきます。

## 暗号化 LVM を利用する

既存の暗号化 LVM に新規に増設する手段としては主に次の通りになります。

既存の LVM に暗号化された LVM を追加する
http://blog.id774.net/post/2014/05/13/481/

あらためてこの記事で追っていきましょう。元記事と同じく新規ストレージを /dev/sdb と仮定します。

### 古いデータの削除

ストレージの新品を購入した場合は良いのですが、既存のデータを上書きする場合は次のように乱数で埋めます。また新品のストレージでもどこまでが暗号化領域として使われているか判明することすら恐れる場合、やはり乱数で上書きしたほうが良いでしょう。

```bash
shred -n 1 -v /dev/sdb
```

### 鍵の生成

システムから自動的に暗号領域をマウントできるよう鍵を生成します。生成した鍵は root だけ読み取れるようにしておきます。この鍵が漏洩すると暗号領域を読み取れてしまいますので、鍵自体も暗号化されたストレージに保管されていなければなりません。

```bash
# 暗号鍵が 256 ビット長なので 32 バイトを指定
dd if=/dev/random of=/etc/lvm/lvm.seckey bs=1 count=32
# 生成した鍵を root だけ読み取れるようにする
chmod 400 /etc/lvm/lvm.seckey
```

### 暗号化パーティションの生成

暗号化パーティションを作ります。まずはパスフレーズで解読できるようにしておき、鍵も追加します。パスフレーズで解読可能にしておくのは万一鍵が失われた場合に障害対応できるようにするためです。

```bash
cryptsetup --cipher aes-cbc-essiv:sha256 --key-size 256 luksFormat /dev/sdb
# 大文字で YES を回答する
# パスフレーズを 2 回入力する
cryptsetup luksAddKey /dev/sdb /etc/lvm/lvm.seckey
# パスフレーズを 1 回入力する
cryptsetup luksDump /dev/sdb
# 暗号化パーティションの情報を確認する
```

きちんと生成されていれば cryptsetup luksDump コマンドで UUID を確認することができます。

### dm-crypt デバイスの生成

次のように dm-crypt デバイスを生成します。これで Device mapper でアクセスできるようになります。

```bash
cryptsetup --key-file /etc/lvm/lvm.seckey luksOpen /dev/sdb sdb_crypt
```

### PV の生成と VG への参加

LVM の基本的な知識や用語については[このあたり](https://access.redhat.com/site/documentation/ja-JP/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/ch-lvm.html)や[このあたり](http://www.tldp.org/HOWTO/LVM-HOWTO/)を読むと良いでしょう。ディストリビューションが異なっても、ほとんどの知識は共通です。

まずは PV を生成します。そして新しく LVM を構成するのではない限り、既存の VG に参加させることになります。

```bash
pvcreate /dev/mapper/sdb_crypt # PV を生成する
vgextend hoge-vg /dev/mapper/sdb_crypt # VG を拡張する
```

vgscan, pvscan, vgdisplay, pvdisplay といったコマンドで追加の状況を確認します。 PV の Free PE に表示されたエクステント数だけ論理ボリュームの拡張が可能です。

新規で LV を生成するなら lvcreate コマンドを、元記事にはありませんが既存の LV を拡張するなら lvextend を利用します。

```bash
lvcreate -l 123456 --name data hoge-vg # data という名前で lV 生成
mkfs -t ext4 /dev/hoge-vg/data # ファイルシステムを作成する
```

または

```bash
lvextend -l +123456 /dev/hoge-vg/home # + 記号を忘れないよう
resize2fs /dev/hoge-vg/home # /home を拡張する
```

ファイルシステムを作成した場合は /etc/fstab に追加します。あらかじめ mount コマンドでマウントできるか確認したほうが安全でしょう。設定が正しければ /etc/fstab に追加後 mount -a で自動マウントされるはずです。

```bash
/dev/mapper/hoge-vg-root /               ext4    relatime,errors=remount-ro 0       1
/dev/mapper/hoge-vg-data /data               ext4    relatime,errors=remount-ro 0       1
```

最後にシステム起動時に自動的に暗号化領域が認識されるよう /etc/crypttab に追加をします。

```bash
sdb_crypt UUID=xxxxxxxx /etc/lvm/lvm.seckey luks
```

### 暗号化 LVM のまとめ

暗号化 LVM を利用する場合、システムの一部としてシームレスにデータ領域を取り扱えるというメリットがあります。その反面、システムの一部であるので、ストレージの障害対応時に少々手順が煩雑となります。また、ストレージを丸ごと取り外して移動させるような可搬性にも劣るというデメリットがあります。そのような用途が無いのなら、システムの一部に統合される暗号化 LVM を利用することは、データの保全性を確保する上でまず第一の選択肢として挙げられるでしょう。


## サードパーティー製暗号化ソフトウェアを利用する

暗号化ソフトウェアとしてはオープンソースでなおかつ強力でバリエーション豊かな暗号方式を利用可能な [TrueCrypt](http://www.truecrypt.org/) がまさに最強のツールです。

TrueCrypt
http://www.truecrypt.org/

最近では[パソコン遠隔操作事件](http://ja.wikipedia.org/wiki/%E3%83%91%E3%82%BD%E3%82%B3%E3%83%B3%E9%81%A0%E9%9A%94%E6%93%8D%E4%BD%9C%E4%BA%8B%E4%BB%B6)でも利用され一部で話題になりましたし、その安全性については [FBI の暗号解読に耐えた](http://www.anlyznews.com/2010/11/truecryptfbi.html)ことでも有名です。

執筆時点では最後に公開されたバージョン 7.1a を最後に約二年ほどバージョンアップが止まっている点がやや不安ではありますが、ソースコードがすべて公開されているという安心感は何者にも替えがたいものがあります。

(5/30 追記)

TrueCrypt の開発継続性に問題が発生しているようです。
http://internet.watch.impress.co.jp/docs/news/20140530_651011.html

(6/6 追記)

TrueCrypt に関する情報がスイス発のプロジェクトである次のサイトに集まってきています。万一 TrueCrypt 本家の継続が困難な場合、有志によって fork & rename されて開発が継続されそうです。
http://truecrypt.ch/

### TrueCrypt のセットアップ

ここでは執筆時点の最新版 7.1a 及び GNU/Linux 64bit 環境を元に説明します。筆者の確認した限りではディストリビューションを選ばず RHEL 及びそのクローン (CentOS, Scientific Linux) と Debian 及びその派生 (Ubuntu) の最近のバージョンで問題なく動作します。

まずダウンロードしてきたファイルを展開します。

```bash
tar xzvf truecrypt-7.1a-linux-console-x64.tar.gz
sudo ./truecrypt-$2-setup-console-x86
```

展開されたバイナリを起動すると対話的にライセンスなどが表示されるのでこれを許諾するとインストールは完了します。

### 暗号化コンテナの生成

まずは暗号化コンテナを生成します。これはデバイスファイル名または通常のファイル名を指定すればあとは対話的に操作できます。下記の例ではデバイス全体を暗号化していますが、通常のファイル名でも問題ありません。通常のファイル名を指定すると、コンテナそのものをファイルとして取り扱えるので可搬性に優れます。

```bash
sudo truecrypt -t -c /dev/sdb
```

ファイルシステムを選択することができますので fat や ext4 を必要に応じて選択します。あとから手動でファイルシステムを生成することも可能です。

fat ですと他の OS から読み込むことが容易になりますが 1 ファイルのサイズに制限があったり、領域そのものに 2TB の壁があったりと、何かと不自由になります。 GNU/Linux のみで扱うのであれば ext4 が推奨です。

また dm-crypt と同じく、パスフレーズと鍵を指定することができます。

### 暗号化コンテナのマウント

次のようにコマンドラインでマウントします。

```bash
sudo truecrypt -t -k "" --protect-hidden=no --fs-options=utf8 /dev/sdb ~/mnt/sdb
```

 -k オプションには鍵を指定します。鍵を生成していれば自動でマウントできますが、無い場合はパスフレーズを応答することになります。また fs-options は fat を取り扱う場合 utf8 を指定するべきでしょう。 ext4 の場合はこれは不要です。また fs-option=ro を指定すると読み取り専用になります。これは暗号化領域のデータを読み取りしかしない場合は保険として指定すると良いでしょう。

### サードパーティー製暗号化ソフトウェアのまとめ

TrueCrypt はクロスプラットフォームですので、生成した暗号化コンテナを Windows や Mac など別の OS でも取り扱えるという利点があります。またコンテナのみを転送すれば別の場所へ移動できるという可搬性に優れているので、遠隔地でのデータ保存にも適しています。サードパーティー製ソフトウェアの導入が許可されているならば、選択肢のひとつとして有力です。

## 総括

今回は重要データ保全の一環として、まずは物理攻撃への対策として暗号化について取り上げてみました。センシティブなデータを扱う機関でも物理攻撃対策がないがしろにされている例は散見されますが、万一のために備えて必ず物理攻撃について対策するべきです。暗号化技術は絶対ではなく単なる難読化にすぎませんが、それでも多くの攻撃者を諦めさせるには十分な障壁となるでしょう。誰でも軍事レベルの暗号技術を無料で利用できる時代なのですから、これを利用しない手はありません。もちろん理想を語るならそれだけでなく計算機への物理的なアクセスそのものを侵入者から守るのが肝要であることは言うまでもありません。