[PHP-users 23783] Re: DB の暗号化について

[Yuichi Okabe]

こんばんは、岡部です。

"MORIMOTO, Yoshinori" <ymo ＠ fabrice.co.jp> wrote:

> おはようございます。MORIMOTOです。
> 
> > 極端な例として、レンタルサーバ側の
> > ソーシャルエンジニアリングを懸念しています。
> > 故意ではなくても、向こうのミスにより
> > こちらがレンタルサーバに置いていた情報
> > が漏れても責任は持てないとのことでした。
> 
> ソーシャルエンジニアリング云々は、まあ、おいておいて、「データベース自体
> が故意、あるいはミスで漏洩すること」が対応するべき脅威なのですね。
> 

そうです。
こちらのミスで漏洩するのは仕方がない(ないことはないですが..^^;)
として、向こうのミスをこちらから防ぐことも出来ませんし...
かといって、こちらにデータベースサーバを立てて
サーバ管理するまでにはまだ考えが至っていません。
＃設計が行き詰まればそのような手段も
＃検討していかなければなりませんが..

> > ソーシャルエンジニアリングの場合、同じ場所に秘密鍵がなければ
> > 情報が漏れることは少ないと考えています。
> > もちろん秘密鍵は当方のローカル内で管理します。
> > データベースの中身は暗号化したまま取得し、
> > 当方のローカルサーバで複合化を考えています。
> 
> なるほど。レンタルサーバ上では復号化しない（レンタルサーバでは秘密鍵を使
> わない）という運用が可能なのでしたら、暗号化は有効でしょうね。その場合、
> 言葉としてはデータベースというよりもログに近いと思いますが。

おっしゃるとおり、ほとんどログに近いテーブルです。


> ショッピングサイトで入力された顧客情報が同じ場所で再利用されないとは、
> ちょっと想像できなかったものですから。再利用とは、データベースから暗号化
> された情報を取得して、復号化して、表示する、変更するなどです。

すみません説明不足でした。
上記のテーブルとは別に、お客様の認証に必要な情報として、
ログインIDやパスワードなどを保存するテーブルを用意しています
これらは暗号化対象にはなっておらず、再利用するデータになります。

> レンタルサーバ上で復号化しない＝つまり再利用しないなら、書き込み時に公開
> 鍵で暗号化してしまうのは有効でしょうね。データベースに書き込む必要もない
> ですから、フラットファイルに出力してもいいですね。

そうなんです、フラットファイルに出力することも
考えていますが、楽に構築できるのであればと
思いDBを検討しています。

> うーん、でも、どうにも使いにくいサイトのような気はします。住所変更はどう
> やるんだろう？