Amazon Web Services ブログ

Category: Elastic Load Balancing

Application Load BalancerがSNIを利用した複数のTLS証明書のスマートセレクションをサポートしました

本日、我々はApplication Load Balancer (ALB)でServer Name Indication (SNI)を使った複数のTLS/SSL証明書のサポートをリリースしました。これによって、単一のロードバランサの背後に、それぞれ別の証明書を持ったTLSで保護されたセキュアなアプリケーションを複数配置することが可能になります。SNIを利用するためには、複数の証明書をロードバランサの同じセキュアリスナーに紐付ける必要があります。ALBは各クライアントに最適なTLS証明書を自動的に選択します。これらの新機能は追加料金無しでご利用可能です。 もし新しい機能をどうやって使えばいいかを手っ取り早く知りたければ、こちらをクリックして下さい。この機能に興味があり、Transport Layer Security (TLS)について復習したい場合は続きをお読み下さい。 TLS? SSL? SNI? SSLとTLSは技術的には異なるものですが、これらを入れ替え可能な用語として使いがちです。SSLはTLSプロトコルの技術的な祖先にあたります。以下では簡潔さのために、TLSという用語を使っていきます。 TLSはパスワード、クッキー、クレジットカード番号といったデータを安全に伝送するためのプロトコルです。これによって、送信されるデータのプライバシー、認証、完全性が実現されます。TLSは、ウェブサイトのIDカードに相当する証明書を基礎とした認証技術を利用します。もし、その証明書を署名し発行した人、すなわちCertificate Authority (CA)を信用するなら、あなたはその証明書の中のデータは正しいと信用します。あるブラウザがTLSが有効化されたあなたのALBに接続するとき、ALBはあなたのサイトの公開鍵を表示しますが、それはCAによって暗号的に証明されたものになります。この方法によって、クライアントは”本物のあなた”からデータを得ていることと、あなたのサイトの公開鍵を利用して安全な接続を確立可能なことを確実にすることができます。 SNIのサポートによって、同一のALBで1つ以上の証明書をもっと簡単に利用できるようになりました。複数の証明書を使いたい最も一般的な理由は、同一のロードバランサで異なるドメインを捌きたいときです。これは、ワイルドカードやsubject-alternate-name (SAN)署名書をALBで利用することで元々実現可能ですが、いくつかの制約があります。ワイルドカード証明書は単純なパターンに合致する関連するサブドメインでしか使えません。SAN証明書は複数の異なるドメインをサポートできますが、単一の認証局でそれぞれを認証する必要があります。つまり、新しいドメインを追加するときには毎回証明書を再認証して再配布する必要があることを意味しています。 フォーラムやReddit、そして私のメールボックスで最も頻繁に頂いていた要望の1つが、TLSのServer Name Indication (SNI)拡張を利用してクライアント毎に証明書を選択するようにしてほしいというものでした。TLSはHTTPの下のトランスポートレイヤを担当するため、クライアントがリクエストしたホスト名を見ることができません。SNIはクライアントがサーバに”私が欲しい証明書はこのドメインです”というのを初回接続時に伝えることで動作します。これによってサーバはクライアントに返答するための適切な証明書を選択することができます。全てのモダンなウェブブラウザとその他のクライアントの大多数はSNIをサポートしています。実際、CloudFrontに接続しているクライアントの99.5%以上がSNIサポートしていることを今現在確認しています。 ALBの証明書スマートセレクション ALBの証明書スマートセレクションはSNIを越えていきます。正しいドメイン名の配列だけでなく、証明書にはサーバがサポートしている鍵交換方式と暗号、さらに証明書を署名する時に使った署名アルゴリズム (SHA2, SHA1, MD5)が含まれています。TLS接続を確立する時に、クライアントは”ClientHello”メッセージを送ることでTLSのハンドシェイクを開始しますが、そのメッセージにはクライアントが利用可能なプロトコルバージョン、拡張、暗号アルゴリズムの組、そして圧縮方式の概要が含まれています。各クライアントが何をサポートしているかを元に、ALBのスマートセレクションアルゴリズムがその接続のための証明書を選択し、クライアントに送ります。ALBは古典的なRSAアルゴリズムも、より新しくて人気で高速な楕円曲線ベースのECDSAアルゴリズムも両方サポートしています。クライアントのECDSAサポートはSNI程は広まっていませんが、全てのモダンなウェブブラウザではサポートされています。より高速でCPUの利用も少ないので、超低レイテンシなアプリケーションや、モバイルアプリのバッテリ残量の節約には特に有効です。ALBはTLSのハンドシェイクから各クライアントが何をサポートしているかが分かるので、同一ドメインのRSAとECDSA証明書の両方をALBにアップロードすることでALBが各クライアントに最適なものを自動的に選択させることができます。 ALBでSNIを利用する ここではウェブサイトの例として、VimIsBetterThanEmacs.comとVimIsTheBest.comを使います。Amazon Route 53でこれらのドメインを購入しホストしておいて、2つの別々の証明書をAWS Certificate Manager (ACM)で発行しています。もし1つのALBでこれらのサイトを両方とも安全に配信したいと思ったら、コンソールから両方の証明書を追加することができます。 最初に、コンソールから私のロードバランサを選択し、listenerタブに行き、”view/edit cerfiticates”を選択します。 次に、左上の角にある”+”ボタンを使って証明書を幾つか選択して、”Add”ボタンをクリックします。 これ以上の手順はありません。GUI好きな方ではなかった場合も、AWS Command Line Interface (CLI) (またはSDK)経由でももちろん新しい証明書を追加することはできますのでご安心下さい。 aws elbv2 add-listener-certificates –listener-arn <listener-arn> –certificates CertificateArn=<cert-arn> 知っておくべきこと ALBのアクセスログには、クライアントがリクエストしたホスト名と使われた証明書のARNが含まれるようになります。もし”hostname”のフィールドが空 (“-“で表現されます)だったときには、そのクライアントではリクエストにSNI拡張が使われていません。 […]

Read More

新しいNetwork Load Balancer – 秒間数百万リクエストに簡単にスケーリング

Elastic Load Balancing(ELB)は、Auto ScalingとAmazon CloudWatchを含む3つの組みの一部としてローンチした2009年以来、AWSの重要な要素になっています。それから、私たちは多数の機能を追加し、そしてApplication Load Balancerをリリースしました。コンテナで稼働するアプリケーションに対するアプリケーションレベルでのコンテンツベースルーティングをサポートする様に設計されており、Application Load Balancer はマイクロサービス、ストリーミング、リアルタイムワークロードと相性が良いです。 長年にわたって、私達のお客様はあらゆる規模のwebサイトや、アプリケーションをサポートする為にELBを利用しています。1, 2台のT2インスタンス上で動くシンプルなサイトや、ハイエンドインスタンスで構成される大きなフリート上で動き大量のトラフィックを捌く複雑なアプリケーションにまで利用されています。ELBはバックグラウンドでトラフィックを監視し、需要に応じる様に自動的にスケールしています。このプロセスには、余裕をもったバッファが含まれていて、長年にわたってより迅速になりより反応性があがってきたことで、生放送やフラッシュセール、ホリデーシーズンををサポートするためにELBを利用しているお客様にとっても、よく動作します。しかしながら、リージョン間の瞬時のフェイルオーバーや急激なワークロードの変動(スパイク)などの状況では予想されるトラフィックの急増に対してELBをプリプロビジョニングをするようお客様と協力して対応してきました。 新しい Network Load Balancer 今日、新しいNetwork Load Balancer(NLB)を発表します。NLBは超低遅延で高いスループットを維持しながら利用者の努力なしに、秒間何百万リクエストを捌く様に設計されています。Network Load Balancerはターゲットグループやターゲットの完全なプログラム制御を含めて、Application Load BalancerとAPI互換性があります。最も重要な機能のいくつかは以下の通りです。 固定IPアドレス – 各Network Load Balancerは 各VPCサブネットの範囲に対して1つの固定IPアドレスを提供します。us-west-2aにあるサブネットにターゲットがあり、他のターゲットがus-west-2cのサブネットにあった場合、NLBは2つのIPアドレス(サブネットあたり1つ)を作成し管理します。そのIPアドレスに対する接続は そのサブネット内のインスタンス全体に分散します。さらに制御をするために、各サブネットに対して既存のElasticIPを割り当てることも可能です。IPアドレスを完全に制御することで、Network Load BalancerはIPアドレスを、DNSレコードやファイアウォールルールなどにハードコードされる必要がある場合でも利用可能です。 ゾーナリティ(Zonality) – サブネット単位のIP機能はパフォーマンスの向上により遅延を減少させ、アイソレーションとフォールトトレランスを通じて可用性を向上させ、Network Load Balancerの利用をクライアントアプリケーションから透過的にします。Network Load Balancerは、自動フェイルオーバーを可能にしながら、特定の送信元からの一連のリクエストを1つのサブネットのターゲットにルーティングします。 送信元アドレスの保持 – Network Load Balancerでは、到達コネクションのオリジナルの送信元IPアドレスと送信元ポートを維持するので、アプリケーションソフトウェアはX-Forwarded-Forやプロキシプロトコルや他のワークアラウンドをサポートする必要がありません。これは、VPC Security Groupsを含む一般的なファイアウォールルールをターゲット上で利用可能であることを意味しています。 長時間の接続 – NLBは組み込まれたフォールトトレランスによりコネクションを扱うため、NLBは何ヶ月も何年にもわたってオープンなコネクションを処理できるため、IoTやゲーム、メッセージングアプリケーションに最適です。 フェイルオーバー – Route53による ヘルスチェックによって、NLBはリージョン内およびリージョン間のIPアドレス間のフェイルオーバーをサポートします。(訳注: NLB単体では複数AZをサポートします) Network […]

Read More