CDN SSL/TLS | CDNセキュリティ

脆弱性を軽減するCDN戦略には、適切なSSL/TLS暗号化の実行や特殊な暗号ハードウェアの使用が含まれます。CDNガイドをご覧ください。

Share facebook icon linkedin icon twitter icon email icon

CDNセキュリティ

学習目的

この記事を読み終えると、以下のことができます。

  • CDN SSL/TLSの仕組みを理解する
  • SSL/TLSのCDN最適化を理解する
  • CDNがどのように古いSSL/TLS証明書を改良できるかを確認する
  • CDNがどのようにDDoS攻撃を軽減するかを理解する

CDNに対するセキュリティリスクにはどのようなものがあるか?

インターネットに公開されるすべてのネットワークと同様に、CDNは、中間者攻撃データ漏えいDDoS攻撃を使用したオリジンサーバーを標的としてネットワークを過負荷状態にする試み、などに対して保護策を講じる必要があります。CDNは、適切なSSL/TLS暗号化の実行や特殊な暗号ハードウェアの使用を含む、脆弱性を軽減する複数の戦略を持つことができます。

SSL/TLS暗号とは?

Transport Layer Security(TLS)は、インターネット経由で送信されるデータを暗号化する手順(プロトコル)のことです。TLSは、最初に広く採用されたWeb暗号化プロトコルであるSecure Sockets Layer(SSL)から派生したものであり、初期のプロトコルの多くのセキュリティ上の欠陥を修復したものです。業界では、歴史的経緯から2つの用語を同義語のように使用しています。閲覧しているWebサイトのURLがhttp://ではなくhttps://から始まっている場合は、ブラウザーとサーバー間の通信にTLS/SSLを使用しています。


適切な暗号化を実行することは、悪意のあるアクターが重要なデータにアクセスするのを防ぐのに必要です。インターネットは、データが多くの場所を通って転送するように設計されているため、全世界を移動する際に重要な情報のパケットを傍受することが可能です。暗号化プロトコルを利用することで、正当な受信者のみがデータを解読できるようにして、中間者が転送されたデータの中身を解読できないようにすることができます。

TLSプロトコルは次の3つの構成要素を提供するように設計されています:

  1. 認証 - 提供されたIDの正当性を検証できること
  2. 暗号化 - 1つのホストから別のホストに送信された情報を難読化できること
  3. 完全性 - 偽造と改ざんを検出できること

SSL証明書とは?

TLSを有効にするには、サイトはSSL証明書と対応する鍵を揃える必要があります。証明書は、サイトの所有者に関する情報と非対称鍵ペアの公開鍵の部分が含まれているファイルです。認証局(CA)が、電子署名をして証明書内の情報が正確であることを確認します。証明書を信頼することは、認証局がデューディリジェンスを実施したことを信用することを意味します。

SSL/TLS error graphic

通常、オペレーティングシステムやブラウザーは暗黙的に信頼済みの認証局の一覧を持っています。Webサイトが信頼できない認証局によって署名された証明書を提示した場合、ブラウザーは訪問者に注意を促します。


証明書とその実装方法は、強度、プロトコルサポート、ほかの特性に基づいて個別に評価することもできます。新しいより良い実装が可能になったり、証明書の実装の全体的な安全性を低下するほかの要素が明らかになったりするたびに、評価は変わる可能性があります。オリジンサーバーにグレードの低い古いSSLバージョンが実装されている場合、一般に評価は低くなり侵害を受けやすい可能性があります。


CDNには、CDN提供の証明書を使用して、ネットワーク内でホストされているプロパティの訪問者にセキュリティを提供するという追加のメリットがあります。訪問者はCDNにのみアクセスするため、オリジンサーバーとCDN間で使用される安全性の低い古い証明書はクライアントのパフォーマンスに影響しません。

SSL/TLS self-signed diagram

現実的には、この弱いサーバー・ツー・エッジセキュリティは依然として脆弱性を呈するものであり回避すべきものです。特に、無償のオリジン暗号化を用いることでオリジンサーバーのセキュリティを強化できる可能性がある点を考慮すればなおさらです。

SSL/TLS self-signed diagram

適切なセキュリティはオーガニック検索にとっても重要です。暗号化されたWebプロパティは、Googleの検索順位を上げます。


SSL/TLS接続は、従来のTCP/IP接続とは、異なる動作をします。TCP接続の初期の段階が完了すると、別の交換が行われてセキュアな接続を確立します。この記事では、ユーザーがSSL/TLSで暗号化されたWebページを読み込む場合と同様に、セキュアな接続を要求するデバイスをクライアント、セキュアな接続を提供するデバイスをサーバーと呼びます。

まず、次の3つの手順を経てTCP/IPハンドシェイクが行われます:

  1. 接続を開始するためクライアントがSYNパケットをサーバーに送信します。
  2. その後、通信を認識するために、初回パケットにSYN/ACKパケットでサーバーが応答します。
  3. 最後に、クライアントはACKパケットを返して、サーバーからのパケットの受信を確認します。この一連のパケットの送受信が完了すると、TCP接続が開かれ、データを送受信できるようになります。
TCP 3-way handshake diagram

TCP/IPハンドシェイクが行われると、TLSで暗号化されたハンドシェイクが始まります。このガイドでは、TLSハンドシェイクの実装の背後にある詳しいプロセスについては取り上げません。代わりに、ハンドシェイクの主な目的とプロセスを行うのに要する時間に焦点を当てます。

大まかに説明すると、TLSハンドシェイクには3つの主な構成要素があります:

  1. クライアントとサーバーが、通信で使用されるTLSバージョンと暗号方式を交渉します。
  2. クライアントとサーバーが、相互に信頼できる通信にするための手順を踏みます。
  3. 今後の暗号化通信で使用される鍵を交換します。

以下の図では、TCP/IPハンドシェイクとTLSハンドシェイクに関する各手順を視覚化しています。それぞれの矢印は、クライアントとサーバー間を物理的に移動する必要がある個別の通信を表しています。送受信されるメッセージの総数はTLSで暗号化すると増えるため、Webページの読み込み時間が長くなります。

SSL/TLS handshake diagram

例示を目的として、TCPハンドシェイクは約50ミリ秒、TLSハンドシェイクは約110ミリ秒かかるとします。これは主に、クライアントとサーバー間の双方向でデータを送信するのにかかる時間です。情報が1つのデバイスと別のデバイスを往復するのにかかる時間であるラウンドトリップタイム(RTT)の概念を使用して、接続を確立するのにかかる「費用」を数量化することができます。最適化もCDNの使用もしない場合、追加のRTTは、エンドユーザーにとってレイテンシーの増加および読み込み時間の増大を意味します。幸い、合計読み込み時間を短縮して往復する回数を削減する最適化策があります。

SSLのレイテンシーを向上させる方法

SSLの最適化により、RTTとページ読み込み時間を短縮できます。TLS接続を最適化するには、次のような3つの方法があります:


TLSセッション再開 - CDNは、同じセッションを追加のリクエストのために再開することで、オリジンサーバーとCDNネットワーク間で接続を維持できます。持続的な接続を維持することで、クライアントがキャッシュされていないオリジンを取得する場合にCDNとオリジンサーバー間の接続を再交渉するのにかかる時間を節約できます。CDNとの接続が維持されている間にオリジンサーバーが追加のリクエストを受信する限り、後続のサイト訪問者のレイテンシーを低減できます。

session resumption real time infographic

セッション再開の全体的なコストは完全なTLSハンドシェイクの50%未満です。これは主に、完全なTLSハンドシェイクが2往復分のコストがかかるのに対して、セッション再開は1往復分のコストで済むからです。また、セッション再開は大きな有限フィールドの計算を必要としない(新規セッションは必要とする)ため、クライアントのCPUコストは完全なTLSハンドシェイクのそれと比べてごくわずかです。モバイルユーザーの場合、セッション再開によるパフォーマンスの向上は、バッテリー寿命を気にせずに極めて応答性の高いネットサーフィンを楽しめることを意味します。

session resumption CPU time infographic

TLS False Startの有効化 - 訪問者が初めてサイトを閲覧するとき、上述のセッション再開は役に立ちません。TLS False Startにより、送信者は完全なTLSハンドシェイクを行わずにアプリケーションデータを送信することができます。

SSL/TLS False Start handshake diagram

False Startは、TLSプロトコル自体を変更するのではなく、データが転送されるタイミングのみを変更します。クライアントが鍵交換を開始すると、暗号化が保証されてデータ転送が始まります。この変更により、ラウンドトリップの総数が減り、レイテンシーを60ミリ秒低減します。


Zero Round Trip Time Resumption(0-RTT) - 0-RTTにより、接続に追加のRTTレイテンシーが加わることなくセッション再開できるようになります。TLS 1.3と0-RTTを使用して再開された接続の場合、接続速度が向上し、ユーザーが定期的に訪問するWebサイトの体験がより高速でスムーズなものになります。この速度向上は、モバイルネットワークで特に顕著です。


0-RTTは、有効な向上策ですが、セキュリティ上のトレードオフがあります。いわゆるリプレイ攻撃のリスクを克服するには、CDNサービスはHTTPリクエストのタイプと許可されるパラメーターを制限する場合があります。詳細については、0-RTT概説を参照してください。

CDNによるDDoS攻撃対策

現代のインターネット上のWebプロパティの最も大きな脆弱性の1つは、分散型サービス妨害(DDoS)攻撃です。時がたつにつれて、DDoS攻撃は規模と複雑さが増し、攻撃者はボットネットを利用して攻撃トラフィックでWebサイトを圧倒させるようになりました。適切に設定された大きなCDNには、DDoS攻撃に対する保護要因としての潜在的なスケールメリットがあります。十分なデータセンターの数と相当な帯域幅機能を備えることで、CDNは、標的とされたオリジンサーバーを簡単に圧倒する攻撃トラフィックの量に持ちこたえて攻撃を軽減することができます。


TLS接続を保護するのにほかの手順を踏むことができます。Cloudflare CDNの詳細を理解してTLS攻撃について把握するには、こちらをご覧くださいCloudflare診断センターで、WebサイトがHTTPSを適切に使用しているかどうか調べることができます。