WEBとメールのセキュリティ
■ このスレッドは過去ログ倉庫に格納されています
0001REP
NGNG個人情報、金がからむサービスを始めようとしてるんですが
WEBにそんな情報を載せるのは危険だと思いましたので、
メールでやりとりをし、オフラインのPCにデータベースを
構築するシステムにしました。
しかしメールの方が危険だという事を聞き、どちらの方が
いいかわからなくなってしまいました。
SSLを使えば、個人情報等の重要なデータをサーバ上に
置いていても安全なのでしょうか？
WEBでデータベースを構築するのと、メールでやりとりして
オフラインのPCでデータベースを構築するのとでは、どちらが
安全なのでしょうか？
0002Five
NGNG書き出し、それぞれのプロセス・マシン・通信経路のセキュリティの
リスクを評価しましょう。
結論を言えば、SSL を使った場合でもメールを使った場合でもセキュリティ上の
問題点はあります。問題はその脅威がどのくらい大きいか（どのくらいのコストで
除去できるか）です。
メールの場合でも暗号化メールを使えばかなり安全にデータを交換することが
できます。問題は、暗号化メールを利用するためにはユーザーにメールソフトの
乗り換えや鍵のやり取りのためのプロセスを強制することが必要な点です。
# 暗号化メールが普及しないのは手間とコストの煩雑さが大きいです。
Web の場合でも、SSL を使って通信する分にはかなり安全です。問題は、
データを蓄えておくデータベースの安全性と、そのデータベースから
データを引き出すときのセキュリティの確保です。SSL などのセキュアな
通信経路を利用できるデータベースソフトはあまりないので、Web の
フォームで一切の処理ができるようにするなどの作りこみが必要でしょう。
また、データベースをおいているサーバーが信頼できるというのも大きな
条件です。Web サーバーの管理者がデータベースのデータを覗き見たら
おしまいですから。
自分なら信頼できるホスティング会社を見つけて Web ベースでサービスを
提供します。メールの場合にはユーザーにメールソフトの選択や送信手順を
強制することになりますが、このような強制は通常受け入れられないから
です。
0003REP
NGNGメールで重要な情報をやりとりする場合に暗号化を
使わないのはやはり無茶でしょうか？
いまいちどうして危険なのかわからないでいます。
プロバイダのメールサーバでしたらハックされることは
ないでしょうし、安全のような気がするんですが。
問題はデータの経路という事でしょうか？
0004名無しさん
NGNGこのへんの感覚から改めたほうがよい。
0005>4
NGNG例えSSLを使っていても、どこかに穴があいてたら同じ。
ありがちな極端な失敗の例はhttpsとhttpのサーバを同じ
ホストに立ててしまうこと。
httpsを使うのなら完全隔離すべし。
0006>5
NGNG0007Five
NGNGセキュリティはどうなります？。何のための SSL なんでしょうか？。
あとありがちなミスは、DocumentRoot の下にデータファイルを置いてしまうこと
ですね。この場合 SSL をしても全く意味がありません。セキュアな通信経路上を
流れてはいけないデータが流れるという皮肉な結果になるだけです。
あと Web Server は完全に防御を固めてもデータベースサーバーの方の防御を
全然していない（共用サーバーの場合にはできない）のでそこがセキュリティホールに
なることも当然ありえます。実際、以前それでクレジットカードの番号をごっそり
盗まれるという事件がおきました。
それから、セキュリティを考える場合には、何一つ信用できないという前提で
考えたほうがいいですよ。
> プロバイダのメールサーバでしたらハックされることはない
その保証は？。
00086
NGNG> https:... とするところを http:... として (不正にか、事故でか)
> アクセスされてしまった場合、セキュリティはどうなります？。
> 何のための SSL なんでしょうか？。
そりはコンテンツを用意する側のミスということになると
思いまするが、「隔離すべし」というほどのことでもない
よーな気がするのは認識不足でござりまするでしょうか。
ええ、もちろんデータの重要性にもよる、と言えばそれま
でかもしれませぬが…
0009Five
NGNGということ自体がセキュリティの問題といえます。つまりセキュリティ
ポリシーの徹底ができていないということです。
もちろん実害の程度はデータの重要性にも依存します。
ただこういうのは結果論になりがちなのであんまり議論しても意味がないと
思います。つまり、
・http でアクセスされてしまったが、たまたま盗聴されても構わない
内容だった
という僥倖が常にあるわけではない、という認識から出発しないと
セキュリティポリシーの議論にならないということです。言い換えれば、
・http でアクセスされたくない（盗聴されたくない）データを守るために
どこでどういう仕組みを作って実装するか
という観点で話をする必要があるということです。
0010名無しさん
NGNG同じホスト上にhttp/80とhttps/443を同時運用してても
http://abc.com/url
https://abc.com/url
の両者が同じリソースを指すようなコンフィギュレーション
はしない（80と443ではrootが違う？）のが普通なような気
がするから、あんまり気にしなくてもいいのでわ？
SSLセッションの最初に大事なデータを流さないようなサイ
トになってれば大丈夫のような…
SSLって（BASIC認証みたく）HTTPリクエストごとにネゴす
る？しない？
0011Five
NGNG4 さんは、https でも http でも等しく見えてしまう構成は駄目じゃん、
ってなことを言っているのだと思っていましたが・・。どこぞの MyID な
サイトがそうだったように。
ただ今読み返してみたら、https サービスを提供するホストと http で
サービスを提供するホストを分離せよ、って言っているようにも見えますね。
というか素直に読むとそうなりますね。
なるほど、話がかみ合わないわけでした。
> 80と443ではrootが違う？
http なサイトは普通に ServerConfig で設定して https は VirtualHost で
設定（またはその逆）するパターンが多いです。
> SSLって（BASIC認証みたく）HTTPリクエストごとにネゴする？
セッションの度に鍵の交換をすると性能の問題が出るので、ある期間は
キャッシュして再利用するようになっているみたいです。
cf. 『Web セキュリティ＆コマース』Gerfinkel ほか著（オライリー）
0012>10
NGNGミスコンフィギュレーションを避けること、それと不用意なシン
ボリックリンク(もちろんハードリンクもですが)によって本来、
アクセスできないはずのものがアクセスできてしまう可能性を極
限まで減らすためです。
例えばSSLを使ってたとしてもtelnetポートが空いていれば覗ける
かもしれないし、ftpが生きていて何かを持ち出せるかもしれない。
すべての穴を叩き潰したところから始めることが必要です。
httpd.confでリソースを異なる構成にしていたとしても、どこかで
間違う可能性は無いわけではない、その意味では私もhttpsとhttp
は別ホストに賛成します。あとは管理者の責任ですよねえ。
0013Five
NGNGFollowSymLinks を禁止すれば Symbolic link は防げるし、パーティションを
別にすれば hard link も防止できますけど、AllowOverride none を
忘れたら・・・とか考えると、確かに別ホストが一番安全でしょうね。
001412
NGNG同じですね。ホストの場合はポカする人が多いのですが、
基本は全部穴を塞いでから、必要なものを開けるに尽き
ると思います。
■ このスレッドは過去ログ倉庫に格納されています