PHP+MySQLでのデータの暗号化、セキュリティなどについて

Question

###前提・実現したいこと

低価格帯のレンタルサーバー
OSやApacheの細かい設定などは触れないが、phpMyAdminなどは使用可
で
PHP5 + MySQL5
にて若干の個人情報をデータベースに持つようなシステムを構築したいと思ってます。
(ログインして情報を登録、編集、削除、閲覧するようなもの)

そこでセキュリティ面で知識不足ですので、皆さんがどのようにセキュリティ強化されているか、最低限ここまで必須や可能ならここまでしていればOKなどの内容があればお聞きしたいです。

###試したこと

PHP側では、

ログインパスワードの(複数回ストレッチング？)ハッシュ化

for( $i=0; $i<100; $i++ ) {
$hash = hash ( "sha256", $hash . "パスワード" . "キーとなる文字列" );
}

のような形でハッシュ化を試しました。
例えば100回とした場合にこの回数とキーが漏れなければ良い対策なのかなと思ってます。

また、PDOにて、プレースホルダを用いてプリペアドステートメントを実行する、という形を試しました。

$sql = "SELECT * FROM `member` WHERE id = :member_id";
$stmt = $pdo->prepare ( $sql );
$stmt->bindValue ( ':member_id', ( int ) $member_id, PDO::PARAM_INT );

###不明点と不安点

まずは、上記のようなPHP対策での不足点などお聞きできれば幸いです。

加えまして、MySQL側でどうすれば良いかで悩んでます。

データベースで個人情報にあたるものを全部同じようにハッシュ化すれば良い？と思ったのですが、それでは元の文字列にできない…ということで、では暗号化(可逆暗号)？と考えているところです。

//インサート時
INSERT INTO `member` (name) VALUES (encode(name,'暗号化キー'));
//取得時
SELECT decode(name,'暗号化キー') FROM `member`;

このような形にするととりあえずはキーが分からない限りはデータベース情報を全部抜かれたりしても大丈夫…？なのでしょうか…。
(phpMyAdmin上では文字化けしているみたいなデータの見た目になり使いにくいだろうと思うところですが…)

心配なところをあげればキリがないのですが、お詳しい方アドバイス頂けると幸いです。

Answer 1

可逆暗号であれば AES_ENCRYPT(), AES_DECRYPT() を使えばよいです。
キーと初期化ベクトルをきちんと管理すれば安全です。
※暗号化モードを ECB で使うと暗号強度ががた落ちますが

データベースの中身を暗号化してしまうと、特にその項目を検索に使用する場合（個人情報ですから氏名や住所による検索はあるでしょう）、一致ならまだしも LIKE 検索がほとんど使えなくなります（インデックスが効かない）。それによるパフォーマンス低下をどこまで許容できるかの兼ね合いです。

個人的には、データベースへのアクセスをがっつり制限する（特定の接続先からしか接続させない、接続は SSL で行うなど）ことにして、データそのものは暗号化は控えた方が良いかと思います。
※むろんその場合、開発者は生のデータが見れてしまう、という問題はあるのですが…

余談：phpMyAdmin に対するログイン攻撃はよく飛んでくるので、公開サーバで phpMyAdmin を動かすのは避けた方が賢明です

Comments

[s_u_h_i]

コメントありがとうございます。
なるほど、LIKEが確かに使えなさそうですね…。

こちら
http://d.hatena.ne.jp/yamaback/20110819/1313735667
に
SELECT id, AES_DECRYPT(name,'password'), AES_DECRYPT(email,'password') FROM t_test
WHERE AES_DECRYPT(name,'password') LIKE '%naoto%';
のような形だとLIKE使える、みたいに記載されてるのですが、どうでしょうか…？

phpMyAdminはUI的に助かりますので、コマンドのみの操作だと結構辛いですね…。
何か別のオススメのUIツールなどありますでしょうか？
以前、workbenchというのを使ったことありますが、重すぎて使い物になりませんでした…。

[tacsheaven]

LIKE は使えるのですが、インデックスが使われません。
なぜならインデックスは格納されているデータに対して張られていますから、暗号化状態の文字列に対しては効いても、平文には全く効かないからです。
かといって where条件に与えるデータを AES_ENCRYPT() で「暗号化状態で合致判定する」にしても、一致判定ならともかく LIKE だと使えません。元が「あああ」と「ああい」だとして、暗号化したときに暗号化した「ああ」と先頭から一致するわけではないからです（もし一致してたら暗号としては強度が弱く、現代暗号としては落第です）。

[s_u_h_i]

確かにそうなりますよね…。
これまでデータ自体を暗号化した状態で格納はしてこなかった為、あまり周りでもされていないのはこういった事か～と勉強になりました。
ありがとうございます。

Answer 2

PHP自体には明るくないですが、パスワードのハッシュ化とプリペアードステートメントの利用は一般的な対策として十分だと思います。

MySQL側ですが、カラムの暗号化は有効な対策のひとつですが、対象のカラムにおいてSQLでの検索に制限がかかったり索引が効かなくなるデメリットもあります。また、ENCODE関数は強度的に非推奨で将来的に廃止予定となっているのでAES_ENCRYPT関数を使用してください。

12.13 暗号化関数と圧縮関数

MySQLであればテーブル全体に対する透過的暗号化という手段もあります。

MySQL 5.7の透過的データ暗号化

こちらではアプリケーションやSQLで暗号化・複合化を気にせず使うことができます。一方、防御の対象はDISKやファイルへの直接アクセスのみであり、DBに対するアクセス権限を利用された時点でデータの漏洩となってしまいます。（透過的暗号化を使う場合に限りませんが）DBへのアクセス制御やアクセス履歴の監査等と組み合わせて防御することになります。

DBセキュリティに関しては、データベース・セキュリティ・コンソーシアムという団体が各種ガイドラインを公開しているので参考にしてみてください。「データベース暗号化方ガイドライン」で各暗号化方式の比較もなされています。

DataBase Security Consortium

Comments

[s_u_h_i]

コメントありがとうございます。
色々な方法があるのですね…。
ガイドラインは読むのになかなか根気がいりそうな内容でしたので、コツコツと勉強してみます。
ありがとうございました。

Answer 3

セキュリティの専門家ではないのですが質問文をみて気づいたことがあるので回答します。
1, sha256を使うのは避けてパスワードハッシュ関数として、password_hashとpassword_verifyを使ってください。
参考）安全なパスワードハッシュ

2, CSRF(cross-site request forgeries)対策は忘れずにしてくださいー

3, 暗号化データの検索に関しては、「完全一致に関して」はblind indexが使えると思いますが。
そこまでの要件が必要なかったので調査段階の情報です。
参考）
Indexing encrypted data
What's the best way to store and yet still index encrypted customer data?

Comments

[s_u_h_i]

コメントありがとうございます。
sha256はもはや古いのですね…。
password_hash知りませんでした、ありがとうございます。