HTTPS でサイトを保護する
HTTPS（Hypertext Transfer Protocol Secure）は、ユーザーのパソコンとサイトの間で送受信されるデータの整合性と機密性を確保できるインターネット接続プロトコルです。ユーザーはウェブサイトにアクセスするとき、安全でプライベートにインターネットを利用していると考えています。サイトのコンテンツを問わず、ユーザーによるウェブサイトへの接続を保護するために、HTTPS を導入することをおすすめします。
HTTPS で送信されたデータは、Transport Layer Security プロトコル（TLS）で保護されます。このプロトコルでは主に 3 つの保護レイヤを提供します。
- 暗号化 - 通信データの暗号化によって、盗聴から保護されます。つまり、ユーザーがウェブサイトを閲覧している間、誰かがそのやり取りを「聞き取る」こと、複数ページにわたるユーザーの操作を追跡すること、情報を盗むことはいずれも阻止されます。
- データの整合性 - データの転送中に、意図的かどうかを問わず、データの改ざんや破壊が検出されずに行われることはありません。
- 認証 - ユーザーが意図したウェブサイトと通信していることが保証されます。中間者攻撃から保護され、ユーザーの信頼を得て、ビジネス上の他の利益につなげることができます。
HTTPS を実装する場合のおすすめの方法
堅固なセキュリティ証明書を使用する
サイトで HTTPS を有効にする際には、セキュリティ証明書を取得する必要があります。証明書は認証局（CA）が発行します。発行には、そのウェブアドレスを自分の組織が実際に所有していることを証明する手続きが必要で、それによって、ユーザーを中間者攻撃から保護します。証明書を設定する際、2,048 ビットの鍵を選択して、高度なセキュリティを確保します。強度が低い鍵（1,024 ビット）の証明書をすでに設定している場合は、2,048 ビットにアップグレードします。サイトの証明書を選択する際の注意事項は次のとおりです。
- 技術サポートを提供している信頼できる CA から証明書を取得します。
- 必要な証明書の種類を判断します。
- 保護するオリジンが 1 つの場合（
www.example.com）は単一の証明書。 - 保護するすでに知られているオリジンが複数ある場合（例:
www.example.com, cdn.example.com, example.co.uk）はマルチドメイン証明書。 - 保護する単一のオリジンと多数の動的サブドメインがある場合（例:
a.example.com, b.example.com）はワイルドカード証明書。
- 保護するオリジンが 1 つの場合（
サーバー側の永続的なリダイレクトを使用する
サーバー側の永続的なリダイレクトを使って、ユーザーと検索エンジンを HTTPS ページまたはリソースにリダイレクトします。
HTTPS ページを Google がクロール、インデックス登録できるかどうか確認する
- URL 検査ツールを使用して、Googlebot がページにアクセスできるかどうかをテストしてください。
- robots.txt ファイルで HTTPS ページをブロックしないでください。
- HTTPS ページに
noindexタグを含めないでください。
HSTS をサポートする
HTTPS サイトでは HTTP Strict Transport Security（HSTS）をサポートすることをおすすめします。HSTS は、ユーザーがブラウザのアドレスバーに http を入力した場合でも自動的に HTTPS ページをリクエストするようブラウザに指示し、Google には検索結果に安全な URL を表示するよう指示します。こうした仕組みにより、保護されていないコンテンツをユーザーに提供するリスクを最小限に抑えます。
HSTS を使用するには、HSTS をサポートするウェブサーバーを使用し、HSTS を有効にします。
HSTS を使用すると安全性は向上しますが、ロールバックの手法が複雑になります。HSTS を次のように有効にすることをおすすめします。
- まず、HSTS をサポートせずに HTTPS ページを公開します。
- 短い
max-ageを指定した HSTS ヘッダーの送信を開始します。ユーザーからのトラフィックと他のクライアントからのトラフィックの両方を確認します。また、依存関係にある広告などの掲載結果も確認します。 - HSTS の
max-ageを徐々に増やします。 - HSTS がユーザーや検索エンジンに悪影響を与えない場合は、主要なブラウザのほとんどで使用されている HSTS プリロード リストにサイトを追加できます。これにより、セキュリティが強化され、パフォーマンスが向上します。
一般的な問題を回避する
TLS を使ってサイトをセキュリティで保護するプロセスでは、次のような誤りを避けるようにします。
| よくある誤りとその解決策 | |
|---|---|
| 証明書の期限切れ | 常に最新の証明書を使用するようにします。 |
| 証明書を間違ったウェブサイト名で登録 | サイトが対応するすべてのホスト名に対し、証明書を取得していることを確認します。たとえば、証明書に記載されているのが www.example.com のみである場合、サイトの読み込みにプレフィックス「www.」を含まない example.com を使用する訪問者は証明書の名前の不一致エラーによりブロックされます。 |
| サーバー名表示（SNI）に対応していない | ウェブサーバーで SNI をサポートし、対応しているブラウザをユーザーに通常使用してもらうようにします。最新のブラウザはすべて SNI に対応していますが、それより古いブラウザをサポートする必要がある場合は、専用の IP が必要です。 |
| クロールでの問題 | HTTPS サイトへのクロールを robots.txt を使用してブロックしないでください。詳細 |
| インデックス登録での問題 | できる限り、検索エンジンがページをインデックス登録できるようにします。noindex タグは使用しないでください。 |
| プロトコルの古いバージョン | 古いバージョンのプロトコルは攻撃を受けやすいため、TLS ライブラリの最新バージョンを使用するようにします。 |
| セキュリティ要素の混在 | HTTPS ページには HTTPS コンテンツのみを埋め込みます。 |
| HTTP と HTTPS でコンテンツが異なる | HTTP サイトと HTTPS サイトの両方のコンテンツを同じにします。 |
| HTTPS での HTTP ステータス コードの誤り | ウェブサイトが正しい HTTP ステータス コードを返すことを確認します。たとえば、アクセス可能なページには 200 OK を返し、存在しないページには 404 または 410 を返します。 |
HTTP から HTTPS への移行
サイトを HTTP から HTTPS に移行すると、Google はこれを URL の変更を伴うサイト移転として処理します。この処理は、トラフィック量に一時的に影響することがあります。詳しくは、サイト移転に関する推奨事項をご覧ください。
Search Console に新しい HTTPS プロパティを追加してください。Search Console では、HTTP と HTTPS を別々に扱うため、Search Console のプロパティ間でデータは共有されません。
サイトで HTTPS ページを使用する場合のその他のヒントについては、HTTPS の移行に関するよくある質問をご覧ください。
TLS の実装に関するその他のリソース
サイトに TLS を実装する方法については、次のリソースもご覧ください。
If you're a Search Console user and are having trouble with persistent or unfixable security issues on your site, you can let us know.