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

Yuichi Okabe yu-1 @ poplar.ocn.ne.jp
2004年 12月 2日 (木) 00:47:48 JST


こんばんは、岡部です。

Tomoyuki Asakawa <tom @ asakawa.ne.jp> wrote:

> 
> あさかわ
> 
> #じぶんのスレにコメントすると、ぐちゃぐちゃになるのでこっちにコメントします.
> 
> > ソーシャルエンジニアリングの場合、同じ場所に秘密鍵がなければ
> > 情報が漏れることは少ないと考えています。
> > もちろん秘密鍵は当方のローカル内で管理します。
> > データベースの中身は暗号化したまま取得し、
> > 当方のローカルサーバで複合化を考えています。
> >
> 
> レンタルサーバは、単に,置き場として、DBを、つかうのですか?
> クライアントプログラムは、ローカルマシンにあるわけですね.
> 
> それならば、データセンターは、遠方の貸金庫みたいな感じになりますから
> 通信を、暗号化することと組み合わせれば、2重に暗号化されることになりますから
> たしかに、有効ですね.

これを実現する手段を知りたいのですが、
OpenSSL辺りが有効そうだということが
見えてきました。
試してみようと思います。

> 
> ただ、データを暗号化すると、indexが使えなくなるので
> データベースをつかう理由の一つである、検索や並べ替えの機能が
> 有効ではなくなってしまうということで
> 単に、置き場としてのDBになってしまいます.

そうですね、そのような利用を考えています。
検索や更新をかけるのは別テーブルで用意し、
ログインIDや、パスワード、商品購入情報など、
個人情報にはならないようものを想定しています。

実際に個人情報として抵触するおそれのあるものについては
ローカルで複合化したいと考えています。

といいますか、いろいろと異常系を考えていると、
これくらいしか安くつく安全策が思いつきませんでした。;-p


> まあ、これも、データ次第だと思うのですが
> オラクルも列単位に暗号化できますが、やはり、クエリの対象にならないので
> 検索対象のフィールドは、暗号化できません.

オラクルの機能の一つとして公開鍵暗号が使えるとかいうことはないでしょうか?
もしあればご教授願えませんでしょうか?

> 
> たとえば、住所,名前,電話番号、信用情報というフィールドがある場合
> 検索対象ではない,信用情報は、暗号化するが、検索対象の、住所と名前と電話番号は、暗号化しない
> などの運用になります.
> 
> ならば、クライアントシステムが、ローカルにあるなら
> 信用情報のフィールドだけ、クライアント側で暗号化・複合化すれば、等価になります.
> 
> また、検索対象でも、パスワードでつかう、md5やDESの様に、暗号化後のデータが一定のものなら
> 暗号化後のデータには、インデックスかけてもOKなので、完全一致の検索なら、暗号化も有効ですね.




PHP-users メーリングリストの案内