SSL通信で、お客様の個人情報を守る
ヘッドライン
企業にとって、ホームページの存在というのはもはやなくてはならないマーケティングツールとなった。
プログラム技術の進歩により、お客様(エンドユーザ)からの資料請求や、問い合わせ、見積もり依頼をインターネット経由で容易に受け付けることができたり、直接商品を販売したりすることができる。
一方で、そのような応募、登録が行えるということは、お客様に、住所情報や電話番号、商品を直接販売するのであればクレジットカード番号を入力していただく必要がある。
ホームページ、いわゆるHTTP通信上では、入力し送信をしようとした情報はその通信の中に入れ込んだ状態でサーバーに送信することになる。
通信上、読み取られにくくするのがSSLです
勘違いしてほしくないのが、SSL暗号化通信というのはセキュリティが確保されたものだ。と、いうざっくりとした概念で理解し、SSLを導入したから大丈夫、と考える人が多い。
大きな物の考え方としてはそれで間違ってはいないが、気を付けてもらいたいのは何が暗号化されるのかということである。
サーバーでSSLを使えるようにした＝個人情報保護法に適合したということではないということを気を付けてもらいたいということである。
SSL通信は、通信単位で暗号化することなのである。
たとえば、問い合わせフォームをSSL通信を行って表示させたとする。
では、その時点でどうなるのか。
ブラウザに、https://～～という形でアクセスさせることで容易にSSL通信をONにした状態でアクセスさせることができる。
この時点で暗号化通信はONだが、表示されるフォームの部分自体が暗号化され復号化されて表示されているわけではない。SSL通信はその通信内容を秘匿するのであって、URLを秘匿したりするわけではない。
GETメソッドでデータを送信したらどうなるのか
実際は送信したデータ自体は、暗号化され秘匿されるのだが、クライアント側がハッキングされ、アクセスした履歴を見られた場合、URLにクエリ文字列をつけていればそのURLから情報を読み取られる可能性がある。
SSLは、クライアントとサーバーの通信上のパケットを暗号化するので、URL事態の表示を秘匿するわけではないことは注意してほしい。
なので、GETでは、ページ番号などの、URLが漏れてもさして問題にならないような情報は送りつつも、POSTメソッドで個人情報などは送信するようにしたほうがよりよいだろう。
サーバー機がセキュリティで守られるわけではない。
お客様と接していると、時として頓珍漢な回答が返ってくる。
サーバー機自体のセキュリティ対策のことを話しているときに、（SSL証明書を導入したから大丈夫なのでは?）という回答が少なからず帰ってくる。いや、むしろ多いくらい。
セキュリティの確保は様々なケースに合わせて様々な対応をしなければいけなく、一般的によく言われるSSL暗号化通信はhttp通信上における暗号化通信技術。
最近はその通信を応用して、FTP接続やメールでも採用するケースが増えてきたが、証明書の導入という話になってくるとこれは別物の証明書を導入する必要があるときが多い。（証明書によっては万能なもの、特殊なものがある）。
機械自体のセキュリティというのは、通信技術上のセキュリティもさることながら、機械＝ハードウェアであり、そういったことよりも、盗難防止や悪意のある第三者が機械に近づき、電源を切ったり、断線させたりといった意味でのセキュリティの話であったりする。
機械全体の通信上のセキュリティという話であれば、もちろんその中にはSSL通信技術を使った情報保護もあるが、もっと根本的なSSH接続における第三者の接続を防ぐことであったりする。
証明書を一つ導入したくらいですべてが暗号化され安全になるわけではないのだ。
暗号化通信技術を使っても意味がない方もいる
たとえばの話だが、社内で使うソフトをWEB技術を使って展開している企業も多い。
出退勤管理をベースにしたグループウェアを採用している全国に支店を持つような企業の場合、タイムカードはネットにつないで。。。というところも非常に増えてきた。
しかし、その際に、情報漏えいを懸念して、企業はSSL技術を導入したりするが、そもそも、ログインパスワードを推測されやすい簡単なパスワードや、イワユルディクショナリワード（辞書に載っているような言葉をパスワードに設定する）を使うような状況では暗号化してもまったく無意味。
適当にユーザ名とディクショナリワードを入力し続ければいつか的中してログインされる可能性があるのだ。
WordPressに代表されるオープンソースが脆弱性をついたアタックで情報を不正に更新するというアタックが横行しているが、そのほとんどの起点は、簡単なユーザ名とパスワードから総当たりアタックの上に乗っ取られることが起点になっている。
もちろん脆弱性も問題だが、何より大きな問題は簡単なパスワードなのだ。
そのようなことがないように一人一人が気にするべきことだ。
SSL暗号化通信は決して簡単なパスワードでも問題がなくなるという技術ではないことを頭にとどめておいてほしい。
暗号化通信技術を使ったからと、SPAMやウィルスの配信を防ぐことができるわけではない。
これもかなり多いエンドユーザの勘違いだが、【SSLを導入したからサーバーがウィルスやSPAMから守られる】と勘違いされる方も多い。
先述したことと同様、そもそも、そのようなものを大作するために作られた技術ではないため、防ぐことなどできようもない。
説明に書いた通り、通信を暗号化する技術であり、その暗号化された中身がウィルスであったり、SPAMの内容であったりしてもその内容自体を暗号化し復号化してサーバーへ届けるだけのことである。
SPAMやウィルスの対策はまた別のもの(ウィルス検知ソフトやSPAM検知エンジン）で対応しなければいけない。
SSL通信をつかえないという勘違い
もちろん共用サーバーを利用している場合、あえてSSL通信が使えない設定にしてある場合も多いのだが、そのような設定がされていないサーバー(要は既定の設定のままなら）SSL通信技術を使うことはできるはずだ。
なぜか、特殊な設定をしないと使えないと思っている人が多い。
これは逆で、ごく一般的なサーバーのインストールを行い、ごく一般的な設定しかしていない場合はSSL通信は既定の設定で使えるようになっていることが多い(必ずではないので、調べる必要はあるが)。
なぜ、使えないと感じているのか。答えは簡単で、証明書をインストールしてない状態だと、エラー画面が出るので、使えないと感じているのだ。
しかし、そのエラー内容もよく見ると実に簡単なことで、証明書をインストールしていませんよ。でも、SSL通信で暗号化通信ですけどね。というエラーを出力しているのだ。
通信はできるけど、証明書といわれるものをインストールしていないサーバーだから一応画面としてはまずエラー画面出しますね。
ということなのだ。
そこで、それでもOKです。という風に設定してあげると、暗号化された通信を使ったうえで画面表示、情報送信をしてくれるのだ。
SSL証明書とは
もちろん、私は証明書をインストールしなくていいという話をするつもりはなく、WEBサイトで公開するものであれば、証明書はインストールしてSSLを利用するのが”当然だ”と思っている。
重要なのは不特定多数に公開するものにSSLが必要なものが含まれているのかどうかということである。
先述のグループウェアのような特定多数であれば特定される人物に説明してあれば証明書など不必要という考えもある。
さて、話は戻してSSL証明書の件だ。
SSL証明書とは、そのサイトにおいてSSL通信を行っています。お金を払って証明書を購入したサーバーで暗号化通信をやろうとしていますということを証明する証書のようなものだ。
証書といっても印刷された用紙が買ってくるわけではなくて、もちろん暗号化技術を使った鍵を購入して設定することになるのだが。要はお金を払って第三者機関に、このドメインに関してこのサーバーはお金を払ってまで証明書を購入してインストールして使っていますので、”たぶん信頼できる”人が運営しているものだと思います。
ということである。
実は決して暗号化技術を保障しているわけでもなく、サーバー管理者を保障しているわけでもない。
保障しているのはお金を払ったことと、その該当するドメインがどういうドメイン名かということだけを”証明”しているのである。
最近は企業ごと保障する証明書も出てきた
このような不確定な証明書なので、ここ最近は企業情報を持つ情報会社と提携し、企業ごと証明する証明書（EV証明書）も登場してきた。
SSL証明書を取得するときに、企業の謄本などを提出しなければいけないことと、高額であることで、詐欺に使われにくい状態になっている。
証明書には保険がかかっている
実はこの証明書を導入していた場合情報漏えい事件に関して保険がかかっている。
SSL通信技術を使ったにもかかわらず情報が盗まれた場合に導入していた証明書会社から保険金にて損害を補てんしてくれる。
補てん額などはその証明書ブランドや価格によって上限が決められていたりする。
ただし注意してほしいのはSSL通信を使って送った情報が盗まれた場合であり、まったく別要件のハッキング事件などで情報を盗まれたとしてももちろん保障などしてくれない。
私の知る限りで、この保険が適用になったことはないのではないか。
SSL証明書のインストール
ほとんどの安価な共用サーバーの場合、独自ドメイン単位でのSSL証明書の導入はできないことが多い。
これはなぜなのか、実は答えは簡単で、基本的にSSL証明書は1IPアドレスに対し1証明書までしかインストールできないからだ。
いわば、1IP＝1ドメインであれば何の問題もないが、1IPにいくつものドメインをぶら下げる形式が多い共用サーバーにはSSL証明書の導入が基本的に不可能なのだ。
これを回避する方法ももちろんあるのだが、それはそれなりの技術で対応しなければいけなくなり、安価なサーバーではそこまでやっていられないというのが現実だろう。
1IP複数ドメインの場合に証明書をいくつか導入するとしたら、私の知っている限りでは2つの方法がある
ワイルドカードドメインSSL証明書を導入
ワイルドカードドメインSSL証明書とはいくつかのSSL発行認証局が発行し始めたタイプで、1つの証明書で複数のドメインを認証できるように作られた証明書だ。
要は、証明書は1つなのだが、そこの中に複数のドメインを登録することで複数のドメインを1つの証明書で賄うことができるのだ。
ただし、この方法だと、ドメインごとに証明書のブランドを選ぶことはできなくて、管理者が指定した証明書で、しかも、管理者経由でしか依頼できない。
安井証明書を独自に持ち込んで設定することは不可能だということだ。
なので、共用ホスティング事業者でも使っているところは見たことがない。
おそらくあり得るとしたら、たくさんのドメインを取得し様々なホームページを作り展開するような1企業が1つのIPでSSLを集約しコストカットしたいという用件でもない限り使われることはないだろう。
ポート番号を変える
現実的に共用サーバーで独自ドメイン単位で証明書を導入させるかつ、IPを節約したいのであればポート番号を変えながら設置させる方法だろう。
SSL通信（HTTPS通信）の場合、既定では443番ポートを利用する。厳密に言えば、SSL証明書はIPに1つではなく、1つのポートに1つの証明書なのだ。
もっと細かく言うと、1つのIPの1つのポートに対して1つの証明書なので、ポートを同じ443番で違う証明書を入れたければ違うIPを追加していくしかない。
逆に言えば、IPは増やせないのであればポートを変える方法しか残っていない。
ポートを変えて通信するには、
https://example.com:4434
などといったようにコロンの後にポート番号を指定することでそのポート番号を使ったうえで通信を行うようになる。
実はこれでも問題がないのだが、こういう作りにサーバー業者は作り変える必要があるので、安価なサーバーであればあるほどそのような対応もしないのだ。
一番いいのは1IP1ドメインでSSLを導入することだが、もちろんIPアドレスも多少なりとも費用が掛かるので安価なサーバーではなかなか導入させてもらえないのが現実だ。
安価な共用サーバーでよくあるケース【共用SSL】
共用ホスティングサービスで非常によくあるケースが、共用SSLを利用できるという点だ。
これは、あらかじめホスティング事業者が指定するドメインのSSL証明書が導入されていて、SSL通信を行いたい場所だけはドメイン名を変えて通信してもらえるのであればSSL証明書を導入したSSL通信が行えるという使い方である。
説明に書いたように、SSL通信自体は証明書を入れなくてもできるのだが、証明書を入れていない場合、ブラウザがエラー画面を出力させるようになっているのだ、それを回避することだけが目的の技術だが、WEBサイトの場合はそのほとんどのばあい、これで何の問題もなくなるので、共用サーバーの場合は、当たり前のように提供されていたりする。
もちろん企業認証が必要なレベルであるとかという場合にはこれでは足りないが、そもそもそのくらいの証明書を導入する必要があるのにサーバー自体は共有ということ自体にも問題があるのだ。
まとめ
自分でも途中で何を書いているのかわからなくなりそうな記事だったのでまとめをしっかり書いておきたい。
- SSL暗号化通信技術自体を使うのに基本的に費用が掛かるわけではなく、SSL証明書を導入するのに費用がかかる。
- SSL暗号化通信は暗号化通信のソケットがオープンになった場合その中身が暗号化される
- SSLを導入しても、導入した箇所は暗号化されるが、パスワードが読み取られやすかったら違う意味でクラックされる可能性がある
- 証明書にはいろんなブランドがあり、中には企業自体を証明してくれるような証明書も出てきた
- 共用サーバーでは”ふつうは”独自のSSLの導入は難しい（IPアドレス・ポートの問題から安価なサーバーでは導入させにくい）
- 共用サーバーの場合は、同様に共用SSLをサービスとして導入していることも多い
- 証明書のブランドはたくさんある（ピンキリ）であるが、基本的にどこの証明書を使っても技術的な面やセキュリティ面が違ってくるわけではない
とこんなところか。