HTTPS および SSL による Windows Azure Web サイト (WAWS) のセキュリティ保護

このポストは、12 月 14 日に投稿された Securing your Windows Azure Web Sites (WAWS) with HTTPS and SSL の翻訳です。

編集メモ : 今回は、Windows Azure Web サイト チームでプログラム マネージャーを務める Erez Benari による記事をご紹介します。

ID の盗難やさまざまな形態でのサイバー犯罪が急速に増加していることから、Secure Socket Layer (SSL) によって Web サイトのセキュリティを保護することが、重要かつ一般的になってきました。Web サイトを Windows Azure Web サイト (WAWS) 上でホストしているお客様は、HTTPS を使用した設定をご検討されているのではないでしょうか。この記事では、その方法について説明します。

最初のステップは、デジタル証明書を取得することでしょうか。いいえ、必ずしもそうではありません。実際には最初に、お客様独自のカスタム ドメインを所有するのか、または Azure の既定のドメインである Azurewebsites.net を使用してサイトを運用するのかを決定します。これを最初のステップとするのは、Windows Azure Web サイトが SSL で動作するように事前設定されているため、独自のドメインが不要な場合は、すぐに SSL を使用できるからです。ただ単にブラウズするだけでよいのです。お使いのブラウザーで、プレフィックスを https:// から HTTPS:// に変更すれば完了です。サイトが応答し、そのサイトへの安全な接続が確保されます。ただし、セキュリティを重視するコンテンツやアプリケーションにこの方法を使用するのはお勧めしません。使用されるワイルドカード認証は、すべての Azure Web サイトに汎用的であるからです。

独自のドメインで SSL を使用する場合は、設定時にいくつかのステップが追加で必要となります。作業を行う前に、カスタム ドメインでの SSL の使用は標準モードのサイトでのみサポートされていることにご注意ください。現在、無料または共有モードでサイトを運用している場合は、標準に切り替える必要があり、追加費用がかかります。見込まれるコストを調べるには、Windows Azure の Web サイトの料金詳細や料金計算ツールを参照してください。

ドメインを選択し、それを使用するようにサイトを設定したら、次のステップはドメインに一致するデジタル証明書を取得することです。証明書の購入には、次の 3 つの選択肢があります。

1. Web サイトの URL に一致する単純な証明書を購入します。これは最も安価な方法で、次のようなストアで年間わずか 8 ドルほどしかかかりません。 https://www.thesslshop.com (英語)
2. SAN (サブジェクトの別名) 証明書を購入します。これは同一ドメイン配下の複数の URL に一致する証明書であり、複数の Web サイトを持つ企業にとって経済的な方法です。複数の証明書を URL ごとに購入する代わりに、複数に対応する証明書を 1 つ購入することで、費用が少なくて済みます。
3. ワイルドカード証明書を購入します。これは、お使いのドメイン配下のすべてのサブドメインと照合する証明書であり、最も高価なタイプであるとはいえ、多数の Web サイトを持つ企業にとっては、財務面で最も合理的な方法です。たとえば、30 個の Web サイトを持つ企業の場合、ワイルドカード証明書に 79 ドル支払うのは、30 個の証明書に 240 ドル支払うよりもかなり安く済みます。

実際に証明書を購入するには、プロバイダーを選択し、所定のプロセスを経てから、証明書を PFX ファイルの形式で生成する必要があります。このプロセスについてはこちらの記事 ( 英語) で概説しています。

証明書を入手したら、SSL を有効にするのは非常に簡単です。手順は以下のとおりです。

第 1 段階 : サイトを標準モードに切り替える

切り替えを行う前に、設定している使用制限の削除をご検討ください。これは必須要件ではありませんが、商用サイトを使用制限付きで運用するのは、一般的に適切ではありません。制限に達してしまうと、次の請求サイクルまでサイトがオフラインになってしまうからです。サイトを標準に切り替える手順は以下のとおりです。

1. Azure 管理ポータルにログインします。
2. 該当する Web サイトをクリックします。
3. [Scale] タブに切り替えます。
4. [ General ] セクションで [ Standard ] ボタンをクリックし、サイトを標準に切り替えます。
   
5. [Save] をクリックします。

第 2 段階: SSL を構成する

SSL を構成するには、証明書をアップロードし、それをサイトにバインドします。手順は次のとおりです。

1. Azure 管理ポータルにログインします。
2. 該当する Web サイトをクリックします。
3. [Configure] タブに切り替えます。
4. [Certificate] セクションで、 [Upload a certificate] をクリックします。
   
5. 証明書の PFXファイルをアップロードし、パスワードを指定します (証明書を PFX にエクスポートする際に作成したパスワード)。
6. [SSL Bindings] で、ドロップダウンからカスタム ドメインを選択します。カスタム ドメインをまだ構成していない場合は、こちらのページで構成方法をご確認ください。
   
7. ドロップダウンから該当する証明書を選択します (ここでは 1 つですが、今後増えても構いません)。
8. 3 番目のドロップダウンから、SNI ( 英語) を有効または無効にすることができます。通常は SNI の使用が好まれますが、非常に古いバージョンのブラウザー (Windows XP 以前) からサイトにアクセスすることが想定される場合は、 [ IP Based SSL ] を選択します。SSL の料金をご覧いただくと、SNI の使用が経済的にも魅力的であることがおわかりいただけるでしょう。
9. [Save] をクリックします。

成功すればこれで完了です。サイトが HTTPS に送信された要求に応答するようになります。

問題への対処方法

可能性として最もよくあるのが、証明書を Azure にアップロードできないという問題です。前述の記事 ( 英語) で証明書の取得方法については説明していますが、ここで再確認していただきたいのは、証明書は、証明書プロバイダーから取得したファイルではなく (それが PFX ファイルであっても)、エクスポートされた PFX 証明書でなければならない点です。その理由は、証明書を Web サイトに割り当てるには、Azure ではその証明書に関連付けられた秘密キーを必要とするからです。証明書生成プロセスは、秘密キーの作成時にお使いのコンピューター上で開始され、次に証明書プロバイダーによって照合されます。プロバイダーによって返されたファイルは、要求が最初に発行されたコンピューターにインポートする必要があります。これによって「完全な」証明書が作成されます。プロバイダーから入手したファイルをアップロードしようとすると、Azure に秘密キーが渡されないため、証明書が無効になります。

この問題の別の原因として、証明書が正常に PFX にエクスポートされていないことが考えられます。エクスポートには秘密キーを含める必要があり (そのためこのプロセスの一部でパスワードの指定が必要)、インポートの実行時にそのボックスにチェックを入れ忘れると、エクスポートが機能しません。

証明書の使用に関する別の一般的な問題は、ユーザーがサイトをブラウズしようとすると、ある種のセキュリティの警告がブラウザーに表示されるというものです。この現象は、ブラウザーが証明書を受け入れなかった場合に発生し、ブラウザーによって現れ方が異なります。警告を表示するだけのブラウザーもあれば、サイトを完全にブロックしてしまうブラウザーもあります。エラーの最も一般的な原因は、URL の不一致です。証明書は特定の URL に対して発行されますが、実際の URL が完全に一致しない場合、セキュリティ上のリスクとなる可能性があります。たった 1 つのスペルミスで 1 日の作業が無駄になりかねないため、正確に記述することが重要です。

ブラウザー内のセキュリティ警告に関して、もう 1 つの一般的な問題は、証明書が信頼されないことです。通常、証明書は商用プロバイダーによって発行、販売されますが、今日のすべてのオペレーティング システムには、そうした主要な商用プロバイダーのルート証明書が事前に設定されています。ただし、プライベートな証明機関 (私的な組織やお客様自身の会社などが所有する CA サーバーなど) から証明書を発行した場合、その証明書は信頼されず、エラーを引き起こす可能性があります。私的な証明書の使用は Azure Web サイトではサポートされていないため、証明書を購入せずに SSL を使用したい場合は、自己署名の証明書を使用するとよいでしょう。

上述したように、すべての主要な商用プロバイダーは既定でサポートされていますが、時として、信頼チェーンの中で中間証明書を使用するプロバイダーに遭遇することがあります。一部の証明書プロバイダーは証明書パスを 2 つの部分に分けているため、ルート CA の代わりに、より低いレベルの「中間」サーバーによって証明書が発行されます。それはプロバイダーのルートによって信頼されます。そのような場合、証明書が原因でクライアント ブラウザーが警告を発行することがあるため、自分の証明書とともに発行元の中間証明書もアップロードする必要があります。証明書を PFX にエクスポートするとき、チェーン全体がその中に含まれる必要がありますが、このオプションは既定で有効にされています。

ただし、このチェックを外すか、あるいは証明書パスを含めない別の方法でエクスポートを実行すると、プロバイダーによっては問題が生じる可能性があります。確信のない場合はエクスポートを再実行し、このオプションが確実に選択された状態にすることをお勧めします。