WEBサービスにおけるDBの暗号化について

Question

現在WEBサービスの開発を行っておりまして、ユーザー情報として「氏名、住所、
電話番号、携帯電話番号、Eメールアドレス」などの個人情報を取得しDBに保存します。

個人情報の流出が騒がれる昨今ですが、対策として当サービスでも取得する個人情報を
暗号化するべきか、経験者様のご意見をお聞きしたいと思い質問させて頂きました。

一口にDBの暗号化と言ってもディスク自体の暗号化、テーブルの暗号化、カラムの
暗号化など色々方式はあるかと思いますが、「ウチではこうやってたよ」や
「本当はやらないといけないんだけど手が回ってなくて。。。」など、実際の現場では
どうしているのか？が気になっております。

もちろんSSL通信やSQLインジェクション対策などのWEBサイトとしての対策は
行いますので、DBの暗号化に絞ってご意見を頂けますと幸いです。

Answer 1

参照権限などのアカウント制御も大切ですね。
あとは動的な複合化キーを利用するとかですかね。

Comments

[ariel200]

なるほど個人情報を格納するテーブルはアカウント制御を厳格にする必要がありますね。動的な複合キーについては一度勉強してみます。
早々にご回答頂きありがとうございました。

Answer 2

参考になるか分かりませんが、「データベース暗号化ガイドライン」というのものがあります。
http://www.db-security.org/report/dbsc_cg_ver1.0.pdf

7Pの「脅威と対策のマッピング」は非常に参考になるので一度見ておいても良いと思います。

どういった脅威に対応するためにDBを暗号化するのか。という事をきちんと考えればどのレベルで暗号化すれば良いかがわかってくるはずです。
Webサイトの運用環境や現状実施している対策と掛けあわせて暗号化を検討してみてはいかがでしょうか。

Comments

[ariel200]

このようなガイドラインがあったのですね。
早速「脅威と対策のマッピング」を確認しました。
具体的な脅威が分からないのにやみくもに暗号化しても意味がないというのが
分かりました。あまりにも無知でお恥ずかしい限りです。
本資料を一度通読し、運用環境やサイトの特性を踏まえた上で再考したいと思います。
ご教示頂きありがとうございました。

Answer 3

DB自体の暗号化をしている事はありました。

パスワードなどの不可逆式のハッシュをかけた暗号化部分は別ですが、DBの個別項目の暗号化保存はあまり意味がないように思います。DB自体の参照ができる状況であれば、ソース、または、ビルドされたリソースの参照ができる状況になっていると思われる為、逆コンパイルなどされてソース参照され、復号化部分を読み取られたらアウトです。

暗号化をかけてコンパイルする事は可能ですが、それで問題が発生する事もあり、そこまでやっている所はほとんどないのではないでしょうか？

基本、システム(OS等)の虚弱性に気をつけ、DBやOSのパスワードの定期変更など、アカウントやアクセス管理をしっかりやる事が一番のように思います。

Comments

[ariel200]

確かにDBのデータにアクセスされる状況であれば既に丸裸も同然ですよね。
それ以前に当たり前の事を当たり前にやる、という事ですね。
勉強になりました、ありがとうございました。

Answer 4

最近、同じような悩みに直面しました

システムの完成が優先されたため、本来は最初にやるべきとは思いつつＤＢ暗号化対策は後回しになってしまい、最終的にはシステム完成後に個人情報該当部分のみを暗号化して再格納し、アプリ側に暗号／複合機能を追加しました

これで一応、ＤＢを持ち去られたり、ＤＢサーバに不正侵入されて直接レコードを参照しようとしても内容は判別できないので今のところよしとしています

もっとちゃんとやらないとなぁと思いつつ、なかなか・・・

Comments

[ariel200]

システムの完成が優先されるのは大変よく分かります。
Webで情報収集しても「個人情報は暗号化すべき」といったものばかりで、
実際のところ皆さんがどうしているのかが気になっていました。
実体験に基づく貴重な情報ありがとうございました。