HTTPS セキュアアクセラレーションの設定と使用に関するよくある質問 - CDN

HTTPS は、セキュリティを目的として設計された HTTP チャネルであり、CDN を介したコンテンツ伝送をより強力に保護します。クライアントは、コンテンツに高速でアクセスしながら、ウェブサイトのコンテンツをより安全に閲覧できます。このトピックでは、HTTPS に関するよくある質問にお答えします。

HTTPS の基本と原則

HTTP の一般的な攻撃タイプ

HTTP の一般的な攻撃タイプは以下のとおりです：

SQL インジェクション：攻撃者は、既存のアプリケーションを悪用して悪意のある SQL コマンドをバックエンドのデータベースエンジンに注入し、実行させます。また、Web フォームに悪意のある SQL 文を入力して、設計者が意図した SQL 文を実行する代わりに、セキュリティ上の脆弱性があるウェブサイトのデータベース情報を取得することもあります。
クロスサイトスクリプティング：クロスサイトスクリプティング (XSS) は、ウェブサイトを攻撃するための最も一般的で基本的な方法の 1 つです。攻撃者は、悪意のあるコードを含むデータをウェブページに公開します。ユーザーがそのようなウェブページを閲覧すると、特定のスクリプトが閲覧ユーザーの ID と権限で実行されます。XSS により、ユーザーデータの改ざんやユーザー情報の窃取が比較的容易になります。
クロスサイトリクエストフォージェリ：クロスサイトリクエストフォージェリ (CSRF) も一般的な攻撃の 1 つです。攻撃者は、さまざまな方法でリクエストを偽造してユーザーのフォーム送信行動を模倣し、ユーザーデータを改ざんしたり、特定のタスクを実行したりします。ユーザーになりすますために、CSRF 攻撃と XSS 攻撃は通常連携して使用されますが、攻撃者は悪意のあるリンクをユーザーにクリックさせるなど、他の手段を用いることもあります。
HTTP ヘッダーインジェクション：ブラウザを使用してどのウェブサイトを閲覧する場合でも、使用されている技術やフレームワークに関係なく、HTTP プロトコルが関与します。HTTP プロトコルでは、レスポンスヘッダーとコンテンツの間に空白行、つまり 2 組の CRLF (0x0D 0x0A) 文字が存在します。この空白行はヘッダーの終わりとコンテンツの始まりを示し、攻撃者はこれを利用することができます。攻撃者がヘッダーに任意の文字を注入できる場合、この攻撃が発生する可能性があります。
リダイレクト攻撃：一般的に使用される攻撃としてフィッシングがあります。フィッシング攻撃者は通常、正規に見えるリンクを被害者に送信します。被害者がそのリンクにアクセスすると、悪意のあるウェブサイトにリダイレクトされ、攻撃者は被害者の信頼を得て情報を盗みます。これを防ぐために、すべてのリダイレクト操作は、危険な宛先にリダイレクトされないように検証する必要があります。一般的な解決策はホワイトリストです。正規のリダイレクト URL をホワイトリストに追加し、ホワイトリストにないドメインへのリダイレクトを拒否します。2 つ目の解決策はリダイレクトトークンです。正規の URL にトークンを付加し、リダイレクト時にトークンを検証します。

HTTPS セキュアアクセラレーションを有効にすると、より多くのリソースが消費されたり、アクセスが遅くなったりしますか？

オリジンで HTTPS を有効にすると、オリジンへの HTTP アクセスと比較して、コンピューティングリソースの消費量が増加します。この増加は、主に HTTPS ハンドシェイク中の非対称暗号化と復号化に起因し、リソース消費は同時接続数が多い状況では著しく増大します。対称暗号化と復号化の消費量は HTTP とほぼ同じであるため、セッション再利用率を向上させる必要があります。ただし、HTTPS でオリジンに直接アクセスする方が、HTTP で直接アクセスするよりも時間がかかります。静的コンテンツの場合、エッジ配信は追加のハンドシェイク時間を犠牲にして伝送時間を短縮するため、全体的なアクセス時間は減少します。さらに、静的リソースはオリジンから取得する必要がないため、オリジンとのやり取りが減り、オリジンのリソース消費が低下します。

HTTPS の利用シナリオと判断

HTTPS が必要なのはサイトへのログイン時のみですか？

いいえ。これを以下の側面から分析する必要があります。

セキュリティ：一部のページが HTTP で、一部が HTTPS の場合、他のリソース (JS や CSS ファイルなど) が HTTP または安全でない CDN サービスを介して読み込まれると、ウェブサイトには、依然としてユーザー情報が漏洩するリスクがあります。サイト全体の HTTPS 化は、このリスクを防ぐ最も簡単な方法です。
パフォーマンス：ウェブサイトが HTTPS と HTTP の両方をサポートしている場合、2 つのプロトコルを切り替えるには多くのサーバーサイドリダイレクトが必要となり、これらのリダイレクトがトリガーされるとページの読み込みが遅くなります。
ウェブエコシステム：ブラウザは HTTPS を優先的にサポートし、検索エンジンは HTTPS サイトをより適切にインデックス登録します。

オリジンで HTTPS が設定済みの場合でも、CDN で HTTPS を設定する必要がありますか？

HTTPS はクライアントとサーバー間の通信です。CDN を使用する前は、クライアントはオリジンと直接やり取りするため、オリジンで HTTPS を設定する必要があります。CDN を使用した後は、クライアントは CDN とやり取りします。HTTPS を介して CDN にアクセスしたい場合は、CDN で HTTPS 証明書を設定する必要があります。CDN で HTTPS 証明書を設定する方法については、「HTTPS 証明書の設定」をご参照ください。

オリジンの HTTPS 証明書を更新した場合、CDN の証明書もそれに応じて更新する必要がありますか？

いいえ。オリジンサーバーの HTTPS 証明書と CDN の HTTPS 証明書は互いに独立しています。オリジンの証明書を更新しても、CDN の HTTPS 証明書には影響しません。CDN の HTTPS 証明書を更新する必要があるのは、CDN に設定されている証明書がまもなく期限切れになるか、すでに期限切れになっている場合のみです。詳細については、「HTTPS 証明書の設定」をご参照ください。

HTTPS 証明書を設定するとオリジンポートは変更されますか？

高速化ドメイン名に HTTPS 証明書を設定しても、オリジンポートに直接影響はありませんが、プロトコル追従モードでは間接的に影響します。具体的なルールは以下のとおりです：

1. HTTPS 証明書の設定自体はオリジンポートとは無関係です

HTTPS 証明書はクライアントと CDN ノード間の暗号化を提供するだけであり、CDN とオリジン間のオリジンプロトコルやポートを変更するものではありません。オリジンの動作は、オリジンプロトコルの設定によって独立して制御されます。HTTP に設定されている場合、CDN はデフォルトでポート 80 を介してオリジンからコンテンツを取得します。HTTPS に設定されている場合、CDN はデフォルトでポート 443 を介してオリジンからコンテンツを取得します。これは、エッジに証明書が設定されているかどうかとは無関係です。

2. オリジンプロトコルが「追従」に設定されている場合、クライアントのアクセスプロトコルの影響を受けます

HTTPS 証明書を設定して HTTPS セキュアアクセラレーションを有効にすると、CDN は HTTP と HTTPS の両方でのアクセスをサポートします。
オリジンプロトコルがクライアントに追従するように設定されている場合：クライアントが HTTP で CDN にアクセスすると、CDN はポート 80 でオリジンからコンテンツを取得します。クライアントが HTTPS で CDN にアクセスすると、CDN はポート 443 でオリジンからコンテンツを取得します。

3. フルリンク HTTPS 暗号化が必要な場合

エッジ証明書を設定するだけでは不十分です。オリジン設定でオリジンプロトコルを HTTPS に設定し、オリジンが HTTPS アクセスをサポートしていることを確認する必要もあります。

オリジンプロトコルの設定方法については、「オリジンプロトコルポリシーの設定」をご参照ください。

証明書の設定とアップロード

複数の .crt ファイルを含むサードパーティ証明書をアップロードする場合、どのようにアップロードすればよいですか？

中間認証局によって発行された証明書ファイルには、複数の証明書が含まれています。アップロードする前に、サーバー証明書と中間証明書を連結して 1 つの完全な証明書にする必要があります。

*.PEM 形式のすべての証明書ファイルをテキストエディタで開きます。最初にサーバー証明書を配置し、その後に中間証明書を続けます。証明書間に空白行があってはなりません。ほとんどの場合、認証局は証明書を発行する際に対応する指示を提供します。その指示に従ってください。

連結された証明書は次のようになります：

HTTPS アクセスの動作と互換性

HSTS を設定する際、[include subdomains] を有効にした後、サブドメインでも HSTS を有効にする必要がありますか？

[include subdomains] を有効にした後、サブドメインで HSTS を有効にする必要はありません。HSTS ポリシーはすべてのサブドメインに適用されます。各サブドメインが通常の HTTPS アクセスをサポートしていることを確認してください。そうでない場合、サブドメインにアクセスできなくなります。

HTTPS を設定済みにもかかわらず、クライアントが HTTP でサイトにアクセスするのはなぜですか？

クライアントが HTTP または HTTPS のどちらでサイトにアクセスするかは、クライアント側の動作によります。クライアントに HTTPS アクセスを強制したい場合は、CDN で HTTPS 強制リダイレクトを有効にすることができます。詳細については、「HTTP/S リダイレクトの設定」をご参照ください。

ほとんどのデバイスは HTTPS で高速化されたドメイン名にアクセスできるのに、一部のデバイスでアクセスできないのはなぜですか？

これは主に、CDN が HTTPS リクエストを処理する際に SNI に依存しているためです。SNI は TLS プロトコルの拡張機能であり、クライアントが HTTPS 接続リクエストを開始する際に、アクセスしたいホスト名を指定できるようにするものです。

しかし、一部の古い、または特別に設定されたクライアント (古いバージョンの Android や iOS、Java 6 以前、一部の IoT デバイスなど) は SNI をサポートしていないか、HTTPS リクエストを開始する際に SNI 情報を送信しない場合があります。この場合、CDN ノードはクライアントがアクセスしようとしているサイトを特定できないため、正しい SSL/TLS 証明書を提供できません。その結果、HTTPS 接続の試行が失敗し、ユーザーはウェブサイトのコンテンツにアクセスできなくなります。

この状況を改善するために、以下の対策を推奨します。

クライアントシステムのアップグレード：使用しているオペレーティングシステムとソフトウェアが、SNI をサポートする最新バージョンであることを確認してください。
IoT デバイスのファームウェアの更新：IoT デバイスについては、製造元から提供される最新のファームウェアアップデートを定期的に確認し、インストールしてください。

HTTPS の課金

CDN で HTTPS セキュアアクセラレーションを有効にすると、追加料金は発生しますか？

はい。CDN で HTTPS セキュアアクセラレーションを有効にすると、実際にはクライアントと CDN エッジノード間のリンクで HTTPS が有効になります。SSL ハンドシェイクとコンテンツの復号化の両方に計算処理が必要となるため、CDN サーバーの CPU リソース消費量が増加します。ただし、オリジンサーバーのリソース消費量はオリジンプロトコルの設定に依存します。オリジンプロトコルが HTTP の場合、オリジンサーバーのリソース消費量は増加しません。一方、オリジンプロトコルを HTTPS に設定した場合は、オリジンサーバー側でもリソースが消費されます。

異なる種類の証明書を購入する場合、追加料金が必要です。Certificate Management Service コンソールにログインして、DV レベルの証明書であるテスト証明書 (無料版) を申請することもできます。高速化ドメイン名ごとに 1 つのテスト証明書を申請できます。証明書の有効期間は 3 か月で、無料で自動更新できます。HTTPS 証明書を設定した後、CDN はそのドメイン名のすべての HTTPS リクエストに対して課金します。静的 HTTPS リクエストの料金については、「静的コンテンツの HTTPS リクエストの課金」をご参照ください。

リクエストが IP ブラックリストや User-Agent ブラックリストにヒットした場合、またはリクエストが 403/404 を返した場合、HTTPS リクエストは課金されますか？

HTTPS リクエストは課金されます。リクエストが特定のポリシールールにヒットし、403 または 404 のステータスコードを返した場合、リクエストに対する応答が正常に行われているため、1 回の HTTPS リクエストとしてカウントされます。このようなリクエストにはリソースコンテンツが含まれないため、課金対象のトラフィックはごくわずかです。