セキュアなWebサイトを運用する際にはSSL（サーバ証明書）を用いることが常識となっていますが、どのページからSSL化(https)するべきかは少し誤認があると思います。
いわゆるWebサイトをSSL対応する意義は、通信の暗号化とサーバ証明の二つの目的を果たすことにあります。前者の暗号化では入力したログイン情報や個人情報などを万が一途中の経路で読み取られても解読できなくします。後者のサーバ証明は、第三者証明機関によって発行された、このサイトが間違いなくオフィシャルなものであることを示す電子証明書をブラウザに送って安全性を担保する役割があります。
こちらはTwitterのサーバ証明書情報(サブジェクト)の例
CN = twitter.com
OU = Twitter Security
O = Twitter, Inc.
STREET = 795 Folsom St, Suite 600
L = San Francisco
S = California
PostalCode = 94107
C = US
したがって、例えばプレゼント応募や会員登録を行う際、利用規約等（個人情報保護方針）のユーザが承諾するページをはさむ場合、SSL対応するページは入力フォームや入力情報を受け取るCGIからではなく、利用規約ページから適用したほうが事前にサーバ証明書を確認できるので望ましいと私は考えています。
他にも重要な情報をユーザに伝える必要があるページはSSL化してサーバ証明書を確認できるようにしておいた方が良いのではないかと思います。
ちなみに通信の暗号化だけが目的であれば高価なサーバ証明書を取得する必要は無く、Webサーバの設定によってはURLをhttpsとするだけで使用できる場合があります。ブラウザから証明書が確認できない旨の警報が出ますが、サーバ管理やコンテンツ管理画面など、管理者やネットワークアクセスが限定されている場合などにリーズナブルにセキュリティを高められます。
いわゆるWebサイトをSSL対応する意義は、通信の暗号化とサーバ証明の二つの目的を果たすことにあります。前者の暗号化では入力したログイン情報や個人情報などを万が一途中の経路で読み取られても解読できなくします。後者のサーバ証明は、第三者証明機関によって発行された、このサイトが間違いなくオフィシャルなものであることを示す電子証明書をブラウザに送って安全性を担保する役割があります。
こちらはTwitterのサーバ証明書情報(サブジェクト)の例
CN = twitter.com
OU = Twitter Security
O = Twitter, Inc.
STREET = 795 Folsom St, Suite 600
L = San Francisco
S = California
PostalCode = 94107
C = US
したがって、例えばプレゼント応募や会員登録を行う際、利用規約等（個人情報保護方針）のユーザが承諾するページをはさむ場合、SSL対応するページは入力フォームや入力情報を受け取るCGIからではなく、利用規約ページから適用したほうが事前にサーバ証明書を確認できるので望ましいと私は考えています。
他にも重要な情報をユーザに伝える必要があるページはSSL化してサーバ証明書を確認できるようにしておいた方が良いのではないかと思います。
ちなみに通信の暗号化だけが目的であれば高価なサーバ証明書を取得する必要は無く、Webサーバの設定によってはURLをhttpsとするだけで使用できる場合があります。ブラウザから証明書が確認できない旨の警報が出ますが、サーバ管理やコンテンツ管理画面など、管理者やネットワークアクセスが限定されている場合などにリーズナブルにセキュリティを高められます。
コメント