ログインフォームがない場合、サイトにはSSLが必要ですか？
私たちは、次の目的で使用されるサイトを運営しています。
- ほんの一部の情報と連絡先情報である私たちのホームページ。
- 求人応募も当サイトで取り扱っております。
ただし、ログインできる場所はありません。
私たちがソフトウェアエンジニアリングを行う会社であることを確認し、私たちのサイトにSSL証明書があり、サイトにアクセスするユーザーのブラウザーに自動的にSSLを適用すると、潜在的なクライアントにより良い印象を与えると経営陣に話しました。
また、GoogleのビジネスGmailを使用していても、メールと同じドメイン名をウェブサイトに使用しています。言い換えると、 [email protected]そして私たちのサイトはcompany.comです。言い換えると、潜在的なクライアントも、SSL証明書がないことに気付いた場合、電子メールサーバーがTLSを介して送信していないと考えて、悪い印象を与えることになります。
暗号化する必要のある「機密」または「重要」データがサイトから送信または取得されない場合でも、SSL証明書は必要ですか？
SSLを使用して達成または軽減しようとしていることのすべてです。インターネット上のランダムな人々はあなたの会社の情報を評価することができません。したがって、これを覚えておく必要があります。それはすべて、リスク、リスクの確率、およびそのリスクを軽減するためにどこまで進むかによって異なります。
@ apsillers は、求職者の申請書に良い意味をもたらします。候補者は、意図した受信者に行くことを確信して個人情報を送信するからです。安全なWebサイトの外観についてのポイント、および潜在的な顧客にその南京錠を点滅させるときのより専門的な態度、特にIT企業がセキュリティ相談を提供している場合、 HTTPSを使用することをお勧めします。
個人的には、ハローキティのWebサイトでも、常にHTTPSを使用する傾向があります。
Webサイトに求人応募フォームがある可能性があるという事実は、SSLを使用する十分な理由です。特に、ユーザーexpectは個人情報をウェブサイトに入力するが、正確には知らないwhat情報。
盗聴者に求人応募の内容を読ませることは悪いことですが、さらに悪化します。アプリケーションフォームに非常に機密性の高い情報（名前、住所、公開履歴情報）がない場合でも、アクティブな攻撃者がフォームを書き換えて、より包括的にすることができます。フォームで社会保障番号を尋ねることはないかもしれませんが、ユーザーはそれを知りません。攻撃者が変更したフォームに、もう少し煩わしいデータリクエストを入力することで、彼らは完全に満足するかもしれません。
サイトで直接アプリケーションを処理せず、人事部門の連絡先番号のみを提供する場合も、それはかなり悪いことです。攻撃者は連絡先情報を自分の携帯電話番号に簡単に書き換えて、被害者の個人情報を電話で盗む可能性があります。 （もちろん、SSLストリッピングにより、ここではSSLの有用性が低くなる可能性があります。ユーザーが安全でない接続を介して個人情報を送信することを躊躇するかもしれませんが、合理的に論争のあるユーザーでさえ、安全でない接続を介して提供された電話番号を受け入れることについて2度考えないかもしれません。緩和することができます。 HTTP Strict Transport Security を使用したSSLストリッピング。これは、ユーザーのブラウザに特定のソースからの安全でない接続を受け入れないように指示します。）
つまり、機密情報は次の両方の方法で機能します。
ユーザーが送信する機密情報あなたのサイトには暗号化する必要があります。 「機密情報」には、ログインフォームやセッションCookieが含まれる場合がありますが、個人情報や、サイトからリクエストすることを選択したどのページが含まれる場合もあります。 （たとえば、特定の機密トピックについてIRSから tax-helpリソースを検索すると、 は、最近の大量購入、主要なライフイベントなどに関する情報を明らかにする可能性があります。）
サイトが送信するすべての情報ユーザーに情報が変更されることにより重大な損害が発生する可能性がある場合は、暗号化する必要があります。特に、上記のように、攻撃者に連絡先番号を書き換える能力を与えることは大きなリスクです。たぶん、この要件しないが適用される唯一のケースは、Webサイトに価値のある情報が含まれておらず、ユーザーがだまされるべきだと考えて騙されそうにない場合です。
SSLには、データのプライバシーだけでなく、いくつかの利点があります。適切に署名されたSSL証明書を提示することにより、クライアントが接続するサーバーが実際に自分のものであることが保証されます（CAが過失ではないと仮定しましょう）。
SSLはデータの整合性を提供します。テキスト、ホワイトペーパー、画像、パッチなどのすべての文字列について、ユーザーは、表示されている情報が実際に提示しているものであると確信することができます（サーバーがハッキングされていないと想定しましょう）。
ブラウザでのSSLセッションの視覚的な識別子は、会社が真剣に取り組んでいることを示すPRレベルのインジケータを提供します。メッセージを正しく聞いてもらいたい。同社が顧客/顧客データにも同様に注意を払うことになるという含意があります。
機密情報を受け入れるWebサイトは暗号化する必要があることは明らかですが暗号化する価値がある他のいくつかの利点があります。
個人的には、SSL暗号化は十分に安価であり、現時点ではデフォルトで有効にする理由がないことはほとんどないという考え方です。少なくとも、ビジネスモデルを変更して情報をオンラインで取得し始めれば、何も改造する必要はありません。
私はどこでもSSLのファンです。あなたは今敏感であるかもしれない何かを送信していないかもしれません、しかしそれが変わるかもしれないかどうかあなたは決してわかりません。
私の意見では、SSLを使用しない正当な理由は本当にありません。
無料のSSL証明書に関する以下のコメントに関して、EFFは信頼できる無料のSSL証明書を提供する Let's Encrypt プログラムを立ち上げました。
はい、サイトにはSSLが必要です。
- SSLとその証明書は、現時点ではそれほど高価ではありません。確かにあなたは非常に高価な証明書を買うことができますが、エントリーレベルはかなり低いです
- あなたはクライアント側で個人情報を収集し、それをサーバーに送信しています（なぜ、真ん中の誰かがそれを知っている必要があるのですか？）
特に強い理由がない限り、デフォルトは「SSL」にする必要があります（例：クライアントデータが返されない、ニューヨークタイムズのフロントページに公開されている場合、サーバーとクライアント間のデータは問題ありません）。
HTTPSを実装するだけでなく、デフォルトで有効にする必要があります。これは、EFFから次のような引用があったことを思い出します。「理想的な世界では、すべてのWebリクエストはSSL/TLS経由で送信されます。」セキュリティとプライバシーはデフォルトでオンになっているはずです。オプションにすることはできません。プライバシーが疑わしいものにならないようにするには、誰もが自分の役割を果たさなければなりません。他の人がすでに言ったように、機密データ（個人情報）を取得するので、ユーザーに注意してください。
SSLはある種のファイアウォールまたは何かであるという大きな誤解がありますが、これは単に真実ではありません。 SSLは、中間者攻撃から、またはホストまたはクライアントが機密情報を送信しているときにゲートウェイトラフィックが監視されている場合から保護します。
あなたが持っている最大のリスクは：
- クライアントの接続が侵害された場合、サイト情報が変更されているように見える
- クライアントが傍受を再開する
- 変更されたクライアントの履歴書を受け取る
これはあなたの問題ではないと思います。
SSLはXSSやインジェクション攻撃を阻止しませんが、優れたプログラミングは阻止します。