HTTPS でサイトを保護する

サイトとユーザーの保護

HTTPS とは

HTTPS(Hypertext Transfer Protocol Secure)は、ユーザーのパソコンとサイトの間で送受信されるデータの完全性と機密性を確保できるインターネット接続プロトコルです。ユーザーはウェブサイトにアクセスするとき、安全でプライベートにインターネットを利用していると考えています。サイトのコンテンツを問わず、ユーザーによるウェブサイトへの接続を保護するために、HTTPS を導入することをおすすめします。

HTTPS で送信されたデータは、Transport Layer Security(TLS)プロトコルで保護されます。このプロトコルは主に 3 つの保護レイヤを提供します。

  1. 暗号化 - 通信データの暗号化によって、盗聴から保護されます。つまり、ユーザーがウェブサイトを閲覧している間、誰かがそのやり取りを「聞き取る」こと、複数ページにわたるユーザーの操作を追跡すること、情報を盗むことはいずれも阻止されます。
  2. データの完全性 - データの転送中に、意図的かどうかを問わず、データの改ざんや破壊が検出されずに行われることはありません。
  3. 認証 - ユーザーが意図したウェブサイトと通信していることが保証されます。中間者攻撃から保護され、ユーザーの信頼を得て、ビジネス上の他の利益につなげることができます。

HTTPS を実装する場合のおすすめの方法

堅固なセキュリティ証明書を使用する

サイトで HTTPS を有効にする際には、セキュリティ証明書を取得する必要があります。証明書は認証局(CA)が発行します。発行には、そのウェブアドレスを自分の組織が実際に所有していることを証明する手続きが必要で、それによって、ユーザーを中間者攻撃から保護します。証明書を設定する際、2,048 ビットの鍵を選択して、高度なセキュリティを確保します。強度が低い鍵(1024 ビット)の証明書をすでに設定している場合は、2048 ビットにアップグレードします。サイトの証明書を選択する際の注意事項は次のとおりです。

  • 技術サポートを提供している信頼できる CA から証明書を取得します。
  • 必要な証明書の種類を判断します。
    • 保護するオリジンが 1 つの場合(例: www.example.com)は単一の証明書
    • 保護するすでに知られているオリジンが複数ある場合(例: www.example.com、cdn.example.com、example.co.uk)はマルチドメイン証明書
    • 保護する単一のオリジンと多数の動的サブドメインがある場合(a.example.com、b.example.com)はワイルドカード証明書

サーバー側の 301 リダイレクトを使用する

サーバー側の 301 HTTP リダイレクトを使って HTTPS ページまたはリソースにユーザーと検索エンジンをリダイレクトします。

HTTPS ページを Google がクロールインデックス登録できるかどうか確認する

  • robots.txt ファイルで HTTPS ページをブロックしないでください。
  • HTTPS ページに noindex メタタグを含めないでください。
  • Googlebot がサイト内のページにアクセスできるかどうかテストするには、Fetch as Google を使用します。

HSTS をサポートする

HTTPS サイトでは HTTP Strict Transport Security(HSTS)をサポートすることをおすすめします。HSTS は、ユーザーがブラウザのアドレスバーに http を入力した場合でも自動的に HTTPS ページをリクエストするようブラウザに指示し、Google には検索結果に安全な URL を表示するよう指示します。こうした仕組みにより、保護されていないコンテンツをユーザーに提供するリスクを最小限に抑えます。

HSTS を使用するには、HSTS をサポートするウェブサーバーを使用し、HSTS を有効にします。

HSTS を使用すると安全性は向上しますが、ロールバックの手法が複雑になります。HSTS を次のように有効にすることをおすすめします。

  1. まず、HSTS をサポートせずに HTTPS ページを公開します。
  2. 短い max-age を指定した HSTS ヘッダーの送信を開始します。ユーザーからのトラフィックと他のクライアントからのトラフィックの両方を観察します。また、依存関係にある広告などの掲載結果も確認します。
  3. HSTS の max-age を徐々に増やします。
  4. HSTS がユーザーや検索エンジンに悪影響を与えない場合は、必要に応じて主要なブラウザで使用されている HSTS プリロード リストにサイトの登録を依頼することもできます。

HSTS プリロードの使用を検討する

HSTS を有効にする場合は、セキュリティの強化とパフォーマンスの向上を目的に HSTS プリロードをサポートすることもできます。プリロードを有効にするには、hstspreload.org に記載されているサイトの送信要件に準拠する必要があります。

一般的な問題を回避する

TLS を使ってサイトをセキュリティで保護するプロセスでは、次のような誤りを避けるようにします。

問題 対応策
証明書の期限切れ 常に最新の証明書を使用するようにします。
証明書を間違ったウェブサイト名で登録 サイトが対応するすべてのホスト名に対し、証明書を取得していることを確認します。たとえば、証明書に記載されているのが www.example.com のみである場合、サイトの読み込みにプレフィックス「www.」を含まない example.com を使用する訪問者は証明書の名前の不一致エラーによりブロックされます。
サーバー名表示(SNI)に対応していない ウェブサーバーで SNI をサポートし、対応しているブラウザをユーザーに通常使用してもらうようにします。最新のブラウザはすべて SNI に対応していますが、それより古いブラウザをサポートする必要がある場合は、専用の IP が必要です。
クロールでの問題 robots.txt を使用して HTTPS サイトがブロックされずにクロールされるようにします。
インデックス登録での問題 できる限り、検索エンジンがページをインデックス登録できるようにします。noindex メタタグの使用は避けます。
プロトコルの古いバージョン 古いバージョンのプロトコルは攻撃を受けやすいため、TLS ライブラリの最新バージョンを使用するようにします。
セキュリティ要素の混在 HTTPS ページには HTTPS コンテンツのみを埋め込みます。
HTTP と HTTPS でコンテンツが異なる HTTP サイトと HTTPS サイトの両方のコンテンツを同じにします。
HTTPS での HTTP ステータス コードの誤り ウェブサイトが正しい HTTP ステータス コードを返すことを確認します。たとえば、アクセス可能なページには 200 OK を返し、存在しないページには 404 または 410 を返します。

その他のヒント

サイトで HTTPS ページを使用する場合のその他のヒントについては、HTTPS の移行に関するよくある質問をご覧ください。

HTTP から HTTPS への移行

サイトを HTTP から HTTPS に移行すると、Google はこれを URL の変更を伴うサイト移転として処理します。この処理は、トラフィック量に一時的に影響することがあります。詳しくは、サイト移転の概要ページをご覧ください。

Search Console に HTTPS のプロパティを追加します。Search Console では HTTP と HTTPS を別々に扱うため、このプロパティのデータは Search Console で共有されません。そのため、両方のプロトコルのページを用意する場合は、Search Console でそれぞれのプロパティを指定する必要があります。

詳細情報

サイトに TLS を実装する方法について詳しくは以下をご覧ください(リンク先はいずれも英語)。

この記事は役に立ちましたか?
改善できる点がありましたらお聞かせください。