SSL とサブドメインの落とし穴 — SSL の安全性と範囲

本 Lesson では、Web 上の「安全」を支える SSL の話を中心に、現場でよく見るトラブルを整理していきます。 SSL の話だけで終わらせず、その隣にあるセキュリティ話題まで地続きで扱うのは、現場では SSL だけで完結しないからです。

1. SSL とは何か?

通信情報を守ってくれる SSL

SSL(Secure Sockets Layer)とは、ブラウザとサーバの間でやりとりされる通信を暗号化し、第三者に盗み見られないようにする仕組みのことです。 URL が「https://」で始まり、ブラウザに鍵マークが付いているサイトは、この SSL という仕組みで守られています。 逆に SSL が無い場合は URL が「http://」で始まり、ブラウザとサーバの間でやりとりされる通信情報を第三者に盗み見られる恐れがあります。 現在は、このような状態を良しとしないため、ブラウザ側でも注意喚起のために、サイトを開くと Chrome や Safari では 「保護されていません」 という警告が表示されるようになっています。

SSL の有無による SEO 順位への影響

Google も、Web サイトにおいて SSL はユーザーを保護する観点でも重要であると判断しているため、https(SSL の有無)は Google 検索の順位に影響する と公式に表明しています。 現在では、SSL が無いことが明確なマイナスになることに間違いありません。

SSL はあって当たり前

SSL が無いサイトは、見た目が普通でも、通信が丸見えの「危ないサイト」です。 入力した個人情報やパスワードが途中で盗み見られたり、ページが改ざんされたりするリスクがあります。 2010 年代までは「SSL を入れるかどうか」が選択肢でしたが、いまや SSL はあって当然のもの。 無いと、訪問者にもブラウザにも検索エンジンにも「危険」と判断される、というのが前提条件になっています。

2. SSL / TLS / https

SSL? TLS? https? それぞれの関係

SSL の話をするときに、SSL と言う人もいれば、TLS と言う人も、https と言う人もいたりして混乱しがちですが、わかってしまえばそれぞれの関係はシンプルです。 前述しているとおり、SSL は通信を暗号化する仕組みです。 TLS とは、その SSL を改良した新しい規格で、いま使われているのはほとんどが実はこの TLS なのです(古い SSL は弱点が見つかり使われなくなりました)。ただ、「SSL」という呼び名だけが定着していて、TLS であっても通称の SSL と呼ぶことが多くなっています。 http とは、ブラウザとサーバがデータをやりとりするときの基本的な通信方式のことです。その http 通信を SSL/TLS で暗号化して安全にしたものが https です。

• SSL：昔の暗号化の仕組み
• TLS：今の暗号化の仕組み(でも SSL と呼ばれがち)
• https：http 通信を SSL で暗号化した通信方式

とまとめられます。

通信の暗号化とは

通信の暗号化ってどういうことなの? と思う方に向けて簡単に説明します。郵便に例えるとイメージしやすいかもしれません。 暗号化のない http は、普通のハガキ のようなものです。ハガキなので配達がちょっと目を離した隙に、ハガキの内容を盗み見ることができてしまいます。 一方、暗号化された https は、封書 のようなもので、封がしてあることで、内容を盗み見ることはできず、受け取った相手(サーバ)だけが封を開けて読むことができます。 つまり SSL は、大切な情報を「ハガキ」ではなく「封書」で送るための仕組み、というわけです。

「TLS」と言うべきか

厳密には、現在広く使われているのは TLS(SSL の後継)です。 でも業者も自社のスタッフも「SSL 入れますか?」とか「SSL 切れてます」というように、「SSL」で会話します。 担当者も普段は SSL で話して問題ありません。 逆に「TLS」と言ってもスムーズに会話にならない可能性があるので、無難に「SSL」を使用しましょう。

3. どの SSL を選べばいい?

3 種類の証明書

SSL/TLS 通信を成立させるために、証明書が使われます。この証明書とは、このサーバは SSL 通信するのに信頼してよいかを証明するものです。この証明書があるからこそ、SSL 通信を行うことができるのです。

SSL の証明書には DV(Domain Validation / ドメイン認証) / OV(Organization Validation / 組織認証) / EV(Extended Validation / 拡張認証) の 3 種類がありますが、暗号通信の強度はすべて同じ です。 暗号化のやり方(技術的な仕組み)はどの種類でも共通なので、種類が違っても通信そのものの安全性は変わりません。 違うのは、証明書を発行するときに「何を」「どれだけ深く」確認するか、の部分です。3 種類について簡単に説明しておきます。

• DV(Domain Validation / ドメイン認証)：ドメインの所有者であることだけを認証します(メール認証や DNS 認証で確認)。無料 SSL はここに該当します。
• OV(Organization Validation / 組織認証)：組織(企業)の実在を認証します。法人登記や第三者データベースで確認するため、発行までに数日かかります。
• EV(Extended Validation / 拡張認証)：組織の厳格な実在認証を行います。法的存在、物理的所在地、運営実態まで認証局が詳細審査します。

「DV だと通信が弱い」とか「EV だと暗号が強い」ということはありません。 違いは「サイトに対する社会的信頼の表示・利用者の安心感」であって、暗号化の安全性そのものではありません。 このポイントを押さえておきましょう。

選ぶときのポイント

繰り返しますが、これらは「社会的信頼の表示が必要な度合い」を測るものです。 暗号通信の安全性は、どの種類でも同等です。 その上で、DV にすべきか、OV にすべきか、はたまた EV なのか、以下のポイントで判断してみてください。

• サイトの種類(コーポレート / EC / 金融 / 会員制)
• 個人情報の取り扱い(あり/なし、量)
• 決済・取引額の大きさ
• 信頼性アピールの必要性(BtoB 大型案件・公的機関)
• 予算とサーバ標準対応の有無

重要なのは、個人情報や決済を扱う場合のサイト全体の安全性自体は、SSL の種類で決まるわけではない という点です。 SSL の種類はあくまでユーザーを安心させるための材料であり、ユーザーの不安を減らすための対応である、ということを押さえておきましょう。

判断の一例紹介

あくまで一例ですが、「こんなときはこの SSL」というケースを挙げます。必ずしも「このケースだからこの SSL」と決まるわけではない、という点だけは念頭に置いてください。

• 個人情報・決済を扱わず、サーバが無料 SSL に対応しているので、DV の無料 SSL にする。
• サーバが無料 SSL に対応していないので、DV の有料 SSL を検討する。
• 上場企業で組織の実在を社会的に示す必要があると考えられるため、OV を検討する。
• 金融・医療など業界慣行として求められるため、OV または EV を専門家と相談して決定する。

4. サブドメインの SSL は別物なので要注意

本体ドメインの SSL は、サブドメインに自動適用されない

ここは多くの人が陥りやすい落とし穴です。 ドメインに対して SSL を設定して安心していたら、サブドメインに SSL が適用されていない、ということがあります。例えば「example.com」で SSL を設定したのに、「blog.example.com」には SSL が適用されていないという状況です。 これは、サブドメインが、技術的には別のドメインとして扱われるからです。 一見「同じドメインだから守られているはず」と思いがちですが、サブドメインにはサブドメインごとに SSL を設定する必要があるので、サブドメインがある場合は、SSL の設定時に注意が必要となります。

後からサブドメインを作ると忘れがち

SSL の設定をするときは、抜け漏れなく SSL を設定しようという意識が働きやすいので、問題は起こりにくいのですが、SSL の設定後、時期が改まってサブドメインを設置するタイミングで、SSL のことが抜けがちになります。 例えば「example.com」に SSL を設定し、2 年くらいしてから「blog.example.com」を作って公開してみたら、SSL が適用されていなくて警告メッセージが出てしまう、というようなことが起こりがちです。

忘れにくい機能を活用しましょう

• 最初からワイルドカード SSL を契約する：「*.example.com(サブドメインを含めたドメイン)」をまとめて保護する証明書です。複数のサブドメインを将来増やす予定があるなら、この設定にしておくと、自動的に SSL の対象にしてくれるので設定し忘れることがなくなります。
• サーバ標準で対応している場合は管理画面から有効化する：レンタルサーバの多くは、サブドメインを作るときに SSL も自動設定する機能を持っています。「自動設定の有無」があれば、設定しておくとワイルドカード SSL 同様に設定し忘れることがなくなるので活用しましょう。

誰が設定すべき?

サブドメインの SSL 設定そのものは技術作業なので、実際に手を動かすのは サーバを管理する業者や社内のシステム担当者 です。Web担当者が自分で設定する必要はありません。 ただし「サブドメインを増やすときは SSL の設定も必要になる」と知っておき、新規構築・リニューアル時やサブドメインを追加するタイミングで、業者へ「SSL の対応も忘れずに」と一声かけられること —— これが担当者の役割です。

5. 有料 SSL の期限切れに要注意

SSL の自動更新

SSL には有効期限があります。 無料 SSL は 90 日ごとに自動更新、有料 SSL は 1 年ごとが一般的です。 どちらも「自動更新」になっていることが多いですが、油断は禁物です。 クレジットカードの期限切れ、契約変更、サーバ移転 — このいずれかで、自動更新が止まることがあります。

誰が監視すべきか

基本的には、サブドメインの SSL 設定と同様に、サーバを管理する業者や社内のシステム担当者です。 逆に、「知っている人全員で監視しましょう」という形で責任を曖昧にしてしまうと、全員が見ているようで見ていない、という状況を生み出してしまいます。 誰が監視をするのかは明確にしておく ほうがよいでしょう。

期限切れは大問題

SSL が切れると、全ブラウザで「保護されていない」どころか 「危険」 という警告が出ます。 訪問者はほぼ全員引き返します。EC サイトの場合は、その日の売り上げが激減する可能性があったり、さらには、メール送信も止まることもあります(SPF/DKIM が SSL/TLS と連動しているため)。 ちょっとした「やり忘れ」が大惨事に繋がるので、期限切れは何としても発生しないように気をつけましょう。

6. 混在コンテンツ(https 内の http)

混在コンテンツとは

https のサイトの中に、http の画像・CSS・JavaScript が混ざっていると、ブラウザは「混在コンテンツ」警告を出します。 例えば、「https://example.com」というドメインのサイト内で「http://nonssl.com」というサイトの画像をそのままサーバから読み込む形で表示させていると、自社のサーバは https という保護されたサイトなのにもかかわらず、Webサイト上で保護されていないサーバへ繋いで画像を表示させている、ということになってしまいます。 この場合、ブラウザの鍵マークが「未保護の鍵」に変わり、せっかく自社サーバは SSL にしているのに、訪問者からの信頼を一気に失います。 Chrome では一部の混在コンテンツは自動で読み込みをブロックする仕様にもなっています。

発生しやすい状況

• サイトリニューアル後、過去の画像のパスが「http://」のままで残っている
• 単純なコードの記載ミスで、https とすべきところを http としてしまった
• 外部サービスの埋め込み(YouTube・SNS・地図など)が http だった

このようなことは、作業者であれば簡単にチェックできることなので、制作業者などには徹底してもらいましょう。 また、CMS などを利用して自身で更新するような場合には、http のパスの画像や動画を誤って利用しないように注意しましょう。

混在コンテンツの検知方法

Chrome で対象のページを開き、F12 キーを押すと、ブラウザの右側にサイトのコードを見るためのツールが開きます。もし対象のページ内に混在コンテンツがある場合は、その中の Console タブを見ると「Mixed Content」という警告が表示されます。 技術寄りの作業に見えますが、難しいことを覚える必要はなく、上記の作業だけで、Web担当者でも混在コンテンツを確認することは可能です。 ただし、CMS などで自身で更新するようなコンテンツでない限り、基本的には制作する側がチェックをするのが一般的です。

7. SSL は万能なセキュリティではない

SSL の話の締めくくりに、避けて通れない話題があります。 SSL があるからといって、サイトが安全になったわけではない ということです。 SSL は「通信が暗号化されている」ことしか示しません。 サイトは通信が暗号化されていれば万全なわけではなく、他にもさまざまな危険があります。 Web担当者として、次の 4 つは知っておくようにしましょう。

WordPress 脆弱性

もっとも有名な CMS である WordPress を使っているサイトは、特に中小企業に多く、その WordPress の最大のリスクとして 脆弱性放置 が挙げられます。 WordPress 本体、テーマ、プラグインそれぞれにセキュリティ更新のアラートが定期的に出ます。 これを放置すると、既知の脆弱性を突かれて改ざんされる事故が起きます。 これは本来、WordPress に限ったことではないのですが、WordPress はその認知度や利用率の高さから狙われやすい対象でもあるため、セキュリティ更新はしっかりと行っていくことが必須となります。

フォームスパム

問い合わせフォームを公開した瞬間、世界中のボット(自動的にスパムメールをフォームから送付するロボット)から大量のスパム送信が始まります。 対策なしのお問い合わせフォームは、1 日で数百件のスパムが届くことも珍しくありません。 メールがスパムだらけになってしまい、本物の問い合わせを見落とすリスクが上がります。 また、昨今では巧妙なやり口で「一般のお問い合わせに成りすますようなスパム」も多く、誤ってリンクをクリックしたら、ウィルスをダウンロードしてしまった、ということもあり得ます。 主な対策としては reCAPTCHA(Google の不正対策ツール)や honeypot(ボット用の見えないフィールドでボットを識別する)などです。 制作会社にお問い合わせフォームを依頼するときは、スパム対策をデフォルトで入れてもらうようにしましょう。

パスワード漏れ・不正ログイン

CMS の管理画面 URL が「/wp-admin/」のような推測可能なパスのまま、管理者のパスワードを使い回し、2 要素認証も未設定 — このセットがそろうと、不正ログインまで一直線です。 対策は単純で、管理画面 URL の変更、パスワードの十分な強度、2 要素認証の有効化、この 3 つです。 担当者本人のアカウント運用に直結する話なので、自分から手をつけられます。

入力フォームやサイト構造の脆弱性

問い合わせフォームや検索窓など、訪問者が文字を入力できる場所は、攻撃の入り口にもなります。 代表的なのが XSS(クロスサイトスクリプティング) と SQL インジェクション です。 XSS は、入力欄に悪意のあるスクリプトを紛れ込ませ、それを見た別の訪問者のブラウザ上で勝手に実行させる攻撃です。 SQL インジェクションは、入力欄から不正な命令(クエリ)を送り込み、データベースの中身を盗んだり壊したりする攻撃です。 どちらも「入力された内容をそのまま信用してしまう」作りになっていると成立します。

これらは プログラムの作り方(実装)で防ぐ 領域なので、担当者が自分でコードを直すわけではありません。 ただし、公開前の セキュリティチェック(脆弱性診断) でもっとも引っかかりやすいのが、この種の項目です。 外部の制作会社に依頼するときに「XSS や SQL インジェクションへの対策はしてありますか?」「公開前に脆弱性診断を行いますか?」と一声かけられるかどうかで、納品物の安全性は大きく変わります。

本 Lesson の射程と、運用設計としてのセキュリティ全体像

ここまでで触れたのは、SSL・混在コンテンツ・WordPress 脆弱性・フォームスパム・パスワード漏れ・入力フォームやサイト構造の脆弱性の 6 領域です。 これは「担当者が現場で意識する最低限」の射程に絞ったものです。 実際の 運用設計としてのセキュリティはもっと広い領域 をカバーします。 ほんの一部であることを認識しておきましょう。

8. 担当者が押さえる「セキュリティ最低限チェックリスト」

最後に、担当者が月次・四半期ごとに自分で点検できるチェックリストを整理しておきます。

• 本体ドメインの SSL が有効か、有効期限はいつか
• サブドメイン(blog / recruit / shop など)それぞれの SSL も有効か
• WordPress 本体・テーマ・プラグインの更新責任者は誰か、更新頻度はどうか
• 問い合わせフォームのスパム対策(reCAPTCHA / honeypot 等)は機能しているか
• CMS 管理画面の URL は推測しにくくなっているか、2 要素認証は有効か
• バックアップは取得されているか、復元テストは過去半年で実施したか
• 個人情報を扱うフォームの取扱責任者・委託先は明確になっているか

SSL まわりは項目が多く見えますが、一度仕組みが分かれば点検は数分で回せます。 完璧を一人で抱え込まず、業者と分担しながら少しずつ整えていけば大丈夫です。 まずはチェックリストを上から眺めて、いま手元で確認できるものから一つずつ進めてみましょう。