- ベストアンサー
SSLの効果についての疑問
- 「○○情報センター?」という国運営のサイトでSSL(暗号)送信が数時間もの間効いていなかった事件があったのか疑問があります。
- SSLを導入しているにも関わらず、費用を支払っているにもかかわらず効果がない場合があるのか疑問です。
- 認証機関によってエラーの出やすさや信頼性が異なるのか、またサーバの違いでも効力に差があるのか疑問です。
- みんなの回答 （5）
- 専門家の回答
質問者が選んだベストアンサー
- ベストアンサー
acidendさん、こんばんは。 ＞＞送信フォームからウェブ注文頂き、その送信先が同じドメインのメールアドレスになっていて、受信をメールソフトで受信し、… ↓ メールサーバーは同じレンタル・サーバー会社内のもの（ノード）なのでしょうか？ そうだとすれば、そこからacidendさんの会社のローカル・マシンのメーラー（正確にはアナログ化される場所）までの経路は暗号化など、セキュリティー対策がされているでしょうか？（対策済みであれば、以下しばらくは読み飛ばしてください。） ご存知かと思いますが、現状のメール送/受信プロトコル（SMTP・POP3）は基本的に平文（正確にはASCIIコード）でデータ-をやりとりする”仕様”（*）ですから、公衆回線など不特定多数が接続できる通信路では、盗聴・改ざんといった危険に対し、まったくセキュリティーは確保されません。 （*）レンタル・サーバー利用環境でのメール利用のセキュリティーについては、参考URLにて解説されています。 何れにしても、完全に排他的ではない通信経路で秘匿データをメールで扱う場合、「PGP」、「SSL+Webメール」などを利用しメールのデータを暗号化するか、「VPN」や「SSH・トンネリング」などで、通信経路そのものを排他的に（トンネル化）する対策が必須でしょう。 もちろんメール受信用のメーラーが利用する技術に対応している必要もあります。 また、排他的な（トンネリングされた）経路ではあるが、通信内容そのものは秘匿されない「IP-VPN」環境や、ローカル（社内）でのデータ移動の際、無線LANを暗号化（WEP）しない状態で安易に利用してしまうと、盗聴の危険が非常に高まってしまいます。 要は、メールのデータが安全にアナログ化されるまで（アナログ化後もですが）保護されれば良いわけで、利用されているレンタル・サーバー会社に相談してみて、ご自分の環境に最適な手段を選べばよいと思います。 ＞＞送信フォームで必要になるCGIも、SSLかどうかは関係しないので普通につくっておけば良いでしょうし。 ↓ CGIプログラムには、SSLの有無に関係なく、「クロスサイト・スクリプティング」という脆弱性を生んでしまう可能性があります。 くわしいことは、http://www.atmarkit.co.jp/fsecurity/special/30xss/xss01.html など、Web上に多くの情報があるので参考にしていただきたいのですが、要するに「フォームの入力フィールドに特殊な文字列を入力されると、顧客が悪意あるサイトに誘導されてしまったり、個人情報を盗まれたりといった被害を受けてしまう。」というものです。 これについては、プログラムそのもので対策（サニタイジング）するか、安全と確認できたものを利用しない限り、抜本的な対処法がありません。 運用する側から見れば、診断ツールを利用するか、セキュリティー・ベンダーなどによる「診断サービス」を利用し、安全性を確認する位しか手が無いでしょう。 これらの条件が整えば、「個人情報の保護」という意味でのセキュリティー・レベルはかなり向上すると思います。 ここからは余談ですが、acidendさんがシステム管理者のお立場にない場合は、なるべく足を突っ込まなくてすむ方向で調整されることをおすすめします。 セキュリティー対策（システム管理）には終わりがないので、下手に頼られると深みにはまっていくのではないかと、心配です。 自己防衛としてのセキュリティー知識は役に立つと思いますが、自分なら普段は”死んだフリ”したいところです。 予算がおりる限り、レンタル・サーバー会社のサービスを最大限に利用したいところですね。 場当たり的に構築した特殊なシステムにしてしまうと、人事異動などで混乱が起きがちです。（人の苦労も知らず、上司からも社員からも非難の嵐とい悲しい結末が待っていそうな気がします。） また、”セキュリティーにうるさい顧客”としてレンタル・サーバー会社にプレッシャーをかけ続ければ、セキュリティー対策の優先順位を上げてもらえるかもしれませんし…。（すいません、何の根拠もありません。） 余計なお世話な上、大変な長文になりました、すみません。 それでは。
その他の回答 (4)
私の知っているかぎりでは、以下の様な人為的ミスがあります。 ●＜＜暗号化の機能に関して＞＞ ↓ ・フォームでの注文完了（顧客←→Webアプリケーション間）はSSLで暗号化されているが、発注の段階で同じ内容のデータを関連企業へメールで平文送信し、盗聴された。 ・フォーム内の個人情報を同じサーバー上でバックエンドのデータベースソフトと連携させているが、Webアプリケーション自体に「SQL・インジェクション」等の脆弱性があるため、結果的に顧客情報が丸見えになった。 ・OpenSSL+Apacheを利用しているが、脆弱性に対するパッチ適用や必要なバージョンアップを怠ったため、不正侵入の被害を受け、業務（営業）がストップした。 要するに、業務の流れにおいて、個人情報や機密情報が通過する経路すべてを安全にするということでしょうか。 必要であれば、SSL以外の手段も併用するべきでしょう。 ●＜＜なりすましに関して＞＞ ・SSLを導入しているが、クロスサイト・スクリプティングの脆弱性を放置し、悪意あるサイト（攻撃者）にクレジットカード番号など重要な個人情報を盗まれた。 ・証明書（CA）の管理がいい加減で、長期間偽造（なりすまし）に気がつかなかった。 「こんなの当たり前だろ！」と言われそうですが、意外なところに落とし穴があるものだと思います。 また、お客から見れば、加害者は利用したECサイトであり、「日本ベリサインが…」というハナシは通用しませんからね。 その他、注意するべき点としては、以下のものがあると思います。 ●＜＜SSL+Webアプリケーション運用するマシンのスペックについて＞＞ ↓ 結構見落としがちなのが、SSL通信の「重さ」です。 最近のマシンは強力になってきていますから、通常の運用ではまず問題は起きないと思いますが、万が一DDOS攻撃の標的にでもなってしまうと、一発の重さ（データ量）が大きいだけに、「結果としてSSLを入れて落ちた。」ということにもなりかねないと思います。 運用形態やトラフィック量にもよるので、具体的にどれくらいとは言えませんが、運用するマシンのスペックには十分余裕を持たせるべきでしょう。 ●＜＜インシデント対策マニュアルの作成など、万が一に備える。＞＞ ↓ 後ろ向きなハナシかもしれませんが、どんなに気をつけていても、ミスは起こります。 ただし、万が一の際の「初期対応」「顧客ケア」「復旧」「原因究明と再発防止」などのスピードとレベルは非常に重要な問題だと思います。 特に業務委託などを行っている場合は、自組織での対策にも限界があるでしょうから、有事でも担当者レベルが即初動対応できるよう、連絡先や対応一覧などを作成しておくべきでしょう。 あまりまとまりの無い内容になってしまい、恐縮です。 それでは。
お礼
Jzamrai様、再度非常に詳しく有難うございました！ やはりというべきか、予想以上というべきか、しっかり導入しようと思ったらこんなに色々とある訳ですね。 ならば、私のところの現状のように、サーバはレンタルサーバ会社を利用し、そのSSL機能を費用を別途支払い導入してもらい、注文情報をSSLが稼動した送信フォームからウェブ注文頂き、その送信先が同じドメインのメールアドレスになっていて、受信をメールソフトで受信し、あとはデータベースを使用せずメールで受け取った内容をアナログ的に出荷情報へまわすようなやり方の場合、レンタルサーバ会社がJzamrai様がご指摘の内容を守っていればOKということでしょうね。 Jzamrai様がご指摘されている項目の中で、データベースと連携している部分は今回関連しないので、それ以外は今回のケースで言えば、レンタルサーバ会社の設定の部分になると考えて良いのでしょうね。 送信フォームで必要になるCGIも、SSLかどうかは関係しないので普通につくっておけば良いでしょうし。 また質問になってしまい、こちらこそ恐縮ですが、もしよろしかったらまた教えてください。お忙しいようならお手間でしょうから無理にお願いするのは気が引けてしまうので。 それでは宜しくお願い致します。
どんなに強固といわれるシステムでも、運用を誤れば危険です。 システムで守ろうとするのではなく、「守るものの重要性」「コスト」「運用」といった判断をもとに、採用するシステムを決めるべきでしょう。（これが難しいのですが…。） あくまで一般論ですが、SSLも正しく運用すれば十分安全だと思いますよ。（もちろん、絶対ではありませんが。）
お礼
Jzamrai様、ありがとうございました。 SSLが正しく運用されるには、どういったチェック項目があるでしょうか？ 思いつくのは、 [1]送信フォームが送信される先は同じドメインのメアドにする。abc.co.jpでありながらxxx@xyz.co.jpなどと、違うサーバへ送らなければならない送信先へ設定すると暗号化が効かない(?) [2]当然ながらサーバの設定はバッチリおこなう(期限を切らさない) というくらいなのですが、他にどんなことがありますか？
>SSL(暗号)送信を導入している「○○情報センター?」とかいう国運営のサイトで、数時間もの >間暗号化されてなかったという事件があったと人から聞いたのですが、本当でしょうか？ > 本当です。 しかも、なんと！情報処理技術者試験センターの「情報処理技術者試験」の「インターネット受験申込」において起こってしまいました。 失礼ながら、ニュースを聴いた時は笑わずにはいられませんでした。 「委託事業者の不手際」という事ですから技術的な問題によるものではなかったのではないでしょうか？
お礼
mura2717588様、投稿有難うございます。 何とまぁ、本当に笑うしかない条件が揃っていますね！ 本当にあったんですね。参考URLも拝見しました。 一番やってはいけない団体と内容ですねぇ。 実際のサイトを教えて頂けたので、とても良かったです。 「委託事業者の不手際」ということなら、サーバに設定したところがミスったということなのでしょうか。
- XxXxXxXxXx
- ベストアンサー率8% (18/212)
SSLで暗号化できるかどうかは、サーバの設定しだいです。 認証局は暗号化には関係なく、サーバ認証（成りすましの防御）です。 国運営サイトの事件については知りませんが、もしあったとすれば、設定ミスでしょう。情けない話です。
お礼
ご返事有難うございます。なるほど、サーバの設定の問題ということですか。ならばレンタルサーバを利用していて、そのサービスで費用さえ払えばSSL導入・初期設定を代行してもらえるといったケースだと、レンタルサーバ会社の設定がミスされなければこのような事件は起こりえないということですかね。 それと、こちらの方で、キッチリ設定されていて間違いなく稼動しているというのは調べることはできないのでしょうか。
お礼
Jzamrai様、再度しかも大変沢山の内容を入力頂き、また、詳しくご案内頂き、有難うございます。また、私の説明が足りず、自社サーバのケースにまで考えを及ばせてしまい申し訳ないです。 さて、本当はご案内頂いた内容にそれぞれ答えたいのですが、お礼文がただでさえ長くなってしまっていけないので割愛させて頂きます。 Jzamrai様がおっしゃっているとおり、自社サーバでは運営・管理が大変なのでレンタルサーバのサービスを最大限利用するつもりです。SSLがしっかり稼動するかが気になり投稿した経緯です。 eEgg79、以前サーバ候補の上位にあったところです。PGP Form Mail、ありましたね。しかしお恥ずかしい話、業者によってこの辺りの内容への考え方がまちまちで何が本当に正しいものなのかわからず、採用するに至っていませんでした。危惧されていますとおり、知り合いから聞いて大丈夫とのことだったのでメールソフトでの受信対策は考えていませんでした。やはりPGP対応フォームと、ご指摘のXSSに代表されるセキュリティホール対策をとった送信フォームが必要なのですか・・・。 でも私が以前調べた限りですが、レンタルサーバ会社のサービスにあるCGI送信フォームプログラム(無料・有料共に)でここまでおこなっているところは見たことがないです。一方でいかにも簡単なように「SSL導入可」と見せておきながら、PGPにしても送信プログラムにしても説明がなかったり未対応というレンタルサーバ会社が多いのは非常に困ったことです。最初からSSL導入は色々と大変であるとわかっていれば今導入の検討をしないで済んだ気がします。失礼、ちょっと愚痴になってしまいました。 ひょっとしたらSSL導入の前にXSSなどのセキュリティホール対策の方が先なのですかね。いや、結局どちらも同等なのかな・・・。わからなくなってきました。 こうなってくるとSSL導入については今回は見送りにするかも知れません。 とにかく非常に重要な情報と考えております。ご教授頂き本当に有難うございました。-感謝-