App Service Certificate の内側
執筆者: Ashish Kurmi (Security Software Engineer II, Azure App Service)
このポストは、4 月 13 日に投稿された Internals of App Service Certificate の翻訳です。
デジタル化が進む今日の世界では、転送中のデータのセキュリティを確保することが、インターネット上で実行されるあらゆるサービスの基本的な要件の 1 つとなっています。一般的には、クライアント (Web ブラウザーなど) とサーバー (App Service など) の間でデータが改ざんされないことを保証する Secure Socket Layer (SSL) エンドポイントでサービスをホストすることで、これが実現されます。App Service プラットフォームでは、カスタム ホスト名に対する SSL バインドをサポートしています。このバインドを作成するには、お客様が最初に PFX 証明書をアップロードする必要があります。証明書を Azure 内で購入して管理する機能は、お客様からの要望が最も多い機能の 1 つです。
信頼された CA からの証明書の購入は、暗号化の知識が必要となるため、簡単な作業ではありません。技術的知識に詳しいお客様であっても、正規の CA から証明書を購入する際、暗号強度が十分に高く、要件に準拠した証明書を生成するための推奨事項を満たすのは難しいと感じるほどです。安全でない証明書を作成してしまっては、証明書がないのも同然となってしまいます。
こうした状況に対応するために、マイクロソフトでは、App Service のお客様が Azure クラウド上で証明書をシームレスに作成、管理、使用できる App Service Certificate (ASC) を導入しました。このサービスは GoDaddy との提携によって実現されています。この記事では、ASC の詳しい概要について説明します。クイック ガイドが必要な場合は、ASC に関する Azure のドキュメント ページ (英語) と Ruslan のブログ記事 (英語) をご覧ください。
App Service Certificate の作成
ASC の目標の 1 つは、すべての暗号化操作を自動的に行い、App Service のお客様が証明書を容易に作成できるようにすることです。現時点では、有効期間 1 年の RSA 方式のシングルおよびワイルド カード ドメイン認証 (DV) 証明書のみをサポートしています。
詳しいシナリオを見てみましょう。このデモでは、appservicecertificatedemo という名前の標準の Web アプリを使用します。このアプリには、appservicecertificatedemo.com と www.appservicecertificatedemo.com というホスト名が関連付けられています。これらのカスタム ホスト名に対して SSL バインドを作成できるように、この Web アプリ用に ASC を購入することにします。
ASC を作成するには、Azure ポータルにアクセスします。左側にある [New] をクリックし、「App Service Certificate」を検索します。検索結果のページで [App Service Certificate] を選択し、[Create] をクリックします。
ユーザー フレンドリ名と、保護するドメインの名前を入力します。サブスクリプションと新規または既存のリソース グループを選択し、[Certificate SKU] をクリックすると、現在サポートされている ASC SKU の一覧が表示されます。
S1 Standard
ルート ドメインと www サブドメインに SSL バインドを作成する場合は、このオプションを選択します。たとえば、appservicecertificatedemo.com に対してこのタイプの ASC を使用すると、appservicecertificatedemo.com と www.appservicecertificatedemo.com を保護できます。
注: このタイプの ASC を作成する場合は、ホスト名にルート ドメインを指定する必要があります。
W1 Wildcard
ルート ドメインとすべての第 1 レベル サブドメインに SSL バインドを作成する場合は、このオプションを選択します。2 つのホスト名にしか使用できない S1 Standard とは異なり、この証明書を使用できるホスト名の数には制限がありません。たとえば、appservicecertificatedemo.com に対してこのタイプの ASC を購入すると、appservicecertificatedemo.com、api.appservicecertificatedemo.com、support.appservicecertificatedemo.com などを保護することができます。ただし、この ASC は第 1 レベルのサブドメインまでにしか使用できません。上記の例であれば、この ASC を使用して subdomain2.subdomain1.appservicecertificatedemo.com を保護することはできません。
注: このタイプの ASC を作成する場合は、ホスト名を *.domainname の形式で指定する必要があります。
このデモでは、ルート ドメインと www サブドメインの SSL バインドのみが必要であるため、S1 Standard を選択することにします。[Legal Terms] をクリックすると、契約条件ブレードが開きます。契約条件に目を通したら、[OK] をクリックして同意します。[Pin to Dashboard] チェック ボックスをオンにして [Create] をクリックすると、証明書作成要求が送信されます。
ASC リソース プロバイダー (RP) に作成要求が届くと、推奨されるセキュリティ構成を使用して RSA キーのペアが生成されます。そのキー ペアと要求に含まれているドメイン名を基にして証明書署名要求 (CSR) が作成され、署名を受けるために CA に送信されます。App Service のお客様は、これらの暗号化操作を気にする必要はありません。すべてが RP によって自動的に処理されます。
この初回のデプロイ要求は、完了までに 5 ～ 10 分かかります。完了すると、Azure ポータルに ASC リソースが表示されます。この時点で、証明書購入ワークフローは既に開始されています。証明書は、この段階では "Pending Issuance" 状態です。証明書の購入要求は送信されていますが、証明書自体はまだ発行されていません。SSL バインドの作成に使用できる証明書を取得するには、さらにいくつかの手順を行う必要があります。
[Essentials] の各種プロパティの下にある [Status] 情報ボックスに、この証明書用に Key Vault の構成が必要であることが記載されています。この情報ボックスには常に、ASC の現在の状態と、準備完了状態に戻す必要がある場合の操作が表示されます。ここをクリックすると、[Certificate Status] ブレードが開きます。このブレードには、準備完了状態に移行するために必要な操作の一覧が表示されます。また、現在が ASC 購入ワークフローのどの段階にあり、どのような手順が残っているかもわかるようになっています。
必要な手順は 3 つあります。
手順 1: 格納
ASC では、PFX 証明書を安全に格納する手段として Azure Key Vault シークレットを使用します。ASC と他の App Service アプリとの関係には、Key Vault シークレットを使用したプロデューサー/コンシューマー モデルが採用されています。証明書の準備ができると、ASC RP によって、ユーザーが指定した Key Vault シークレットに証明書が書き込まれます。他のアプリはこのシークレットを使用します。この領域をクリックすると、サブスクリプションに含まれている Key Vault の一覧が表示されます。
この一覧から任意の Key Vault を選択できます。必要に応じて、Key Vault を新規作成することもできます。Key Vault を新規作成する場合、データ主権要件がある場合は、それを満たす場所を選択します。ASC を格納するための Key Vault が新規作成されると、必要な Azure サービスのみが Key Vault にアクセスするようにアクセス ポリシーが制限されます。このデモでは、米国西部に democertificate という名前の Key Vault を新規作成します。
Key Vault は独立した Azure リソースで、独自の課金モデルが適用されます。Key Vault の詳細については、こちらをご覧ください。
この手順が完了すると、[Step 1] の横に緑色のチェックマークが表示されます。
手順 2: 確認
ASC を取得するには、要求に含まれているドメインを所有していることを確認する必要があります。このボタンをクリックすると、[Domain Verification] ウィンドウが開きます。上部に、Domain Verification Token が表示されます。このトークンは、確認プロセスをスムーズに進めるためにランダムに生成される識別子です。各種オプションを見ていく前に、ドメイン所有権を確認するための一般的な方法について説明しましょう。この方法は 3 つあります。
- HTML ファイル: ドメインをホストしている Web サーバーのルートに HTML ファイルを配置する。
- DNS TXT レコード: ルート ドメインの TXT レコードを作成する。
- 電子メール: ドメインに関連付けられた電子メール アドレスに送信されるメール内の検証用リンクをクリックする。
この点を念頭に置いて、ドロップダウン リストに表示される 4 つのオプションについて見てみましょう。下へ行くほど操作が容易になります。
Manual verification
このオプションには、上記の HTML ファイルと DNS TXT レコードを使用する方法を使用して、手動で確認を実行するための詳細な手順が記載されています。このオプションは、他のオプションが実際の状況には適さない場合にのみ使用してください。
Mail verification
このオプションでは、電子メールを使用する方法で所有権を確認できます。レジストラーからドメインを購入する際、お客様は連絡先メール アドレス一式を提供します。これらのメール アドレスは ICANN によってデータベースで一般公開されており、だれでもインターネットからアクセスできます。
ASC RP は、作成要求を受け取ると、これらのメール アドレスに対して確認のためのメールを送信します。このブレードには、確認メールを受信したメール アドレスの一覧が、メールの送信時刻と共に表示されます。確認メールの再送信が必要な場合は、上部の [Resend Email] ボタンをクリックします。
次の 2 つのオプションは、Azure ポータルを離れずに確認を実行できるため、お勧めの確認方法です。
Domain verification
ここに表示される手順に従って、Azure 内で App Service アプリ用のドメインを購入できます。既に Azure を通じてドメインを購入済みの場合は、このオプションを使用して、必要な DNS レコードをワンクリックでセットアップできます。ドロップダウン リストからこのオプションを選択すると、Azure を通じて購入したドメインが一覧表示されます。このドメイン オブジェクトを確認に使用するには、上部の [Verify] をクリックします。
App Service verification
ドメインが 1 つ以上の App Service アプリにカスタム ホスト名として割り当てられている場合は、このオプションを使用できます。地理分散したアプリの場合に、複数のアプリが表示される場合があります。このオプションを使用する場合は [Verify] ボタンをクリックします。ボタンをクリックすると、HTML ファイルによる確認方法がエミュレートされます。アプリは確認の HTTP 要求に通常どおりに応答します。このオプションは Standard ASC でのみ利用できます。このデモでは、この確認方法を選択することにします。
どのオプションを選択した場合でも、上部の [Refresh] ボタンをクリックすると証明書の状態が更新されます。ドメインの確認が正常に完了すると、この手順の横に緑色のチェックマークが表示されます。
手順 3: 割り当て
ドメインの所有権が確認されてから CA によって証明書が発行されるまで、少し時間がかかります。この時点でユーザー側に必要な操作はありません。画面を更新するには、リソース ブレードにある [Refresh] ボタンをクリックします。CA によって証明書が発行されると、この手順はすぐに自動的に完了します。
その後、ASC は "Issued" 状態になります。これで、ASC を正常に作成できました。
最初の作成要求を送信した後、購入ワークフローを完了しなかった場合、証明書は送信から 7 日間は "Pending Issuance" 状態になります。この期間を過ぎると、証明書は "Denied" 状態に移行します。"Denied" 状態から復帰する方法はありません。購入ワークフローを完了するには、この ASC リソースを削除して、新しい要求を送信する必要があります。ASC RP は証明書が "Issued" 状態に移行した場合にのみ課金イベントを生成するため、上記のように拒否された場合、ASC の料金は請求されません。
App Service アプリへの App Service Certificate の割り当て
作成した ASC を割り当てるには、[Custom Domains and SSL] ブレードを開いて、上部の [Import Certificate] をクリックします。新しいブレードが開き、"Issued" 状態のすべての ASC の一覧が表示されます。作成した ASC を選択すると、証明書が Web アプリにアップロードされます。
[SSL Bindings] セクションで、カスタム ホスト名を 1 つ選択し、[Certificate] 列で証明書を選択して、上部の [Save] ボタンをクリックします。この操作を各ホスト名に対して実行します。
これで、ASC の作成と Web アプリへの割り当てが正常に完了しました。https://www.appservicecertificatedemo.com にアクセスすると、新たに作成した ASC で保護されていることを確認できます。
1 つの ASC を、必要な数の App Service アプリに使用できます。
App Service Certificate の管理
キーの更新と同期
多くの Web 企業では、コンプライアンス状態を維持するために証明書を定期的に入れ替える必要があります。また、証明書の安全性に問題があるとお客様が感じる場合にも、できるだけ早急に証明書を入れ替えて、盗難された証明書が悪意のある目的で使用される可能性を最小限に抑える必要があります。従来の方法でこれを行うには、CA から新しい証明書を取得する必要がありますが、その手順は新たに購入するのと変わらないくらい複雑です。新しい証明書を作成した後も 1 つずつ手動ですべての App Service アプリを更新する必要があります。ASC では、ワンクリックでキーを更新できます。有効期間内であれば何度でも無償で証明書のキーを更新できます。
[Rekey and Sync] オプションをクリックしてみましょう。このブレードには現在の同期状態が表示されます。ASC の捺印が、App Service にリンクされたすべての証明書の捺印と共に表示されます。これらの証明書が同期状態にある場合はすべての捺印が一致し、同期状態にない場合はリンクされた証明書の捺印の 1 つ以上が ASC の捺印と異なっています。
証明書を入れ替えるには、上部の [ReKey] をクリックします。ASC の状態は "Rekey Certificate" に移行します。
RP にキー更新要求が届くと、RSA キーの新しいペアと CSR が生成され、CA に送信されます。ドメイン所有権の確認は ASC の作成時に済んでいるため、今回は行う必要がありません。キー更新操作の完了には、通常 5 ～ 10 分かかります。[ReKey] をクリックして新しい証明書を取得した後は、何もする必要がありません。上部の [Refresh] をクリックすると、キー更新要求の現在の状態を確認できます。
キー更新要求が完了すると、ASC の状態は準備完了状態に戻ります。
この時点では、リンクされた証明書は捺印が新しい捺印と一致しておらず、同期していない状態です。エンドポイント https://www.appservicecertificatedemo.com はまだ古い証明書を提供しています。
新しい証明書で Web アプリを更新するには、[Sync] をクリックします。同期操作が完了すると、エンドポイント https://www.appservicecertificatedemo.com は新しい証明書を提供し始めます。
キー更新操作が完了した後で [Sync] をクリックしなかった場合はどうなるのでしょうか。リンクされた証明書は永久に非同期状態のままなのでしょうか。答えは「いいえ」です。ASC RP には、リンクされた証明書を、対応する ASC と数時間おきに同期する定期的なジョブが用意されています。そのため [Sync] をクリックしなかった場合でも、アプリはこのジョブによって数時間後には新しい証明書に移行されます。
証明書の更新
ASC は 1 年間有効です。ASC の自動更新がオンになっている場合、ASC は有効期間が切れる前に自動的に更新され、キー更新操作のときと同様、リンクされた App Service アプリが新しい証明書に移行されます。設定を変更するには [Auto Renew Settings] をクリックします。既定では、この設定はオンになっています。また、証明書の有効期間が 90 日以下であれば、現在の自動更新設定にかかわらず [Manual Renew] をクリックして証明書を手動で更新することもできます。
今後の予定
このサービスを皆様にお届けできることを大変うれしく感じています。これは v1 リリースです。皆様のフィードバックをもとに今後数か月でさらに新しい機能を追加していく予定です。ぜひご意見、ご感想をお聞かせください。