Azure App Service でのサブドメインの引き継ぎを禁止する

サブドメインの引き継ぎは、多くのリソースを定期的に作成および削除する組織にとって一般的な脅威です。 サブドメインの乗っ取りは、プロビジョニング解除された Azure リソースを参照する DNS レコードがある場合に発生する可能性があります。 このような DNS レコードは、"未解決の DNS" エントリとも呼ばれます。 サブドメインの引き継ぎにより、悪意のあるアクターは、悪意のあるアクティビティを実行しているサイトに組織のドメインを対象としたトラフィックをリダイレクトできます。

サブドメインの引き継ぎのリスクは次のとおりです。

  • サブドメインのコンテンツに対する制御の喪失
  • 疑いのない訪問者からのクッキーの収穫
  • フィッシング キャンペーン
  • XSS、CSRF、CORS バイパスなどの従来の攻撃のその他のリスク

サブドメインの引き継ぎの詳細については、「 未解決の DNS エントリを防止し、サブドメインの引き継ぎを回避する」を参照してください。

Azure App Serviceは、サブドメインの引き継ぎを防ぐために、name reservation、domain 検証トークン、および安全な一意の既定のホスト名を提供します。

サブドメインの引き継ぎから App Service リソースを保護する最も効果的な方法は、 セキュリティで保護された一意の既定のホスト名を使用することです。 この機能は、Web Apps、Function Apps、Logic Apps (Standard) で一般提供されています。

セキュリティで保護された一意の既定のホスト名を有効にすると、アプリはランダム化されたハッシュとリージョン識別子を含む既定のホスト名を受け取り、組織に対して一意になります。 この形式により、組織外のユーザーが同じ既定のホスト名を持つリソースを作成できなくなります。これにより、未解決の DNS エントリによるサブドメインの引き継ぎのリスクが排除されます。

どのように機能するのか

従来の App Service リソースでは、グローバルに予測可能な既定のホスト名形式が使用されます。

グローバル (元) 一意 (新規)
既定のホスト名 <AppName>.azurewebsites.net <AppName>-<Hash>.<Region>.azurewebsites.net
SCM エンドポイント <AppName>.scm.azurewebsites.net <AppName>-<Hash>.scm.<Region>.azurewebsites.net

たとえば、米国東部にデプロイ contoso という名前の Web アプリは、次の情報を受け取る可能性があります。

contoso-a6gqaeashthkhkeu.eastus-01.azurewebsites.net

16 文字のハッシュは構成可能なスコープ内で決定論的であるため、必要に応じて、環境間で一貫したホスト名を確保できます。

ハッシュ スコープのオプション

一意の既定のホスト名を持つリソースを作成する場合は、ハッシュの生成方法を決定する スコープ を選択します。

Scope Description
テナントの再利用 Microsoft Entra テナント内のすべてのサブスクリプションで同じアプリ名に対して同じハッシュ。
サブスクリプションの再利用 同じサブスクリプション内の同じアプリ名に対して同じハッシュ。
リソース グループの再利用 同じリソース グループ内の同じアプリ名に対して同じハッシュ。
再利用なし 毎回異なるハッシュ値。 最大限の絶縁。

Tip

環境間で (たとえば、テスト サブスクリプションから同じテナントの運用サブスクリプションに) リソースを定期的に再デプロイする場合は、 テナント再利用 を使用して、サブスクリプション間でホスト名の一貫性を維持します。

デプロイ スロット

デプロイ スロットは運用サイトと同じ形式に従いますが、各スロットは独自の個別のハッシュを受け取ります。

既定のホスト名 スロットのホスト名
フォーマット <AppName>-<Hash>.<Region>.azurewebsites.net <AppName>-<SlotName>-<Hash>.<Region>.azurewebsites.net

スロットは、常に運用サイトと同じスコープで作成されます。

有効にする方法

リソースを作成する際に、セキュリティでユニークなデフォルトホスト名を設定します。 既存のリソースに遡って適用することはできません。 それらの有効化方法は、使用するクライアントによって異なります:

  • Azure ポータル:Azure Portalで作成された新しいWeb Apps、Function Apps、Logic Apps (Standard)は、すべてのサポートされたSKUに対して安全で一意のデフォルトホスト名を自動的に使用します。 追加の構成は必要ありません。
  • Azure CLI、ARMテンプレート、REST API:Create Requestでホスト名スコープを設定して明示的にオプトインする必要があります。 この値を新しいデプロイメントごとに設定し、ポータル外で作成されたリソースはポータル内で作成されたリソースと同じデフォルトのホスト名フォーマットを使います。

新しいリソースを作成するときに --domain-name-scope パラメーターを使用して、セキュリティで保護された一意の既定のホスト名を有効にします。

リソースの種類 命令 Reference
Web アプリ az webapp create --name <AppName> --resource-group <ResourceGroup> --plan <AppServicePlan> --domain-name-scope TenantReuse az webapp create コマンドは、Azure Web アプリケーションを作成します。
ファンクションアプリ az functionapp create --name <AppName> --resource-group <ResourceGroup> --storage-account <StorageAccount> --consumption-plan-location <Region> --domain-name-scope TenantReuse az functionapp create コマンドを使用して、Function Appを作成します。
Logic Apps(標準) az logicapp create --name <AppName> --resource-group <ResourceGroup> --storage-account <StorageAccount> --domain-name-scope TenantReuse AZ LogicApp Create

--domain-name-scope パラメーターは、NoReuse、ResourceGroupReuse、SubscriptionReuse、TenantReuseの値を受け取ります。

既存のリソースの移行

この機能は作成時にのみ有効にできるため、既存のリソースには次の 2 つのオプションがあります。

  • セキュリティで保護された一意の既定のホスト名が有効になっている新しいアプリに既存のアプリを複製します。
  • セキュリティで保護された一意の既定のホスト名が有効になっている新しいアプリにバックアップから復元します。

どちらのオプションも、Azure ポータルで使用できます。

今すぐ採用する理由

一意の既定のホスト名をセキュリティ で保護すると、既定で保護が提供されます。 継続的な DNS 検疫と手動介入を必要とする他の軽減戦略とは異なり、このアプローチでは、ホスト名構造にセキュリティを直接構築します。 有効な場合:

  • 外部アクターが既定のホスト名を再作成することはできません。
  • 未解決の DNS エントリは、サブドメインの引き継ぎに利用できません。
  • 作成時に機能を有効にする以外に、追加の構成手順は必要ありません。

新しいApp Service展開ごとに、セキュリティの高い固有のデフォルトホスト名を使用してください。 Azureポータルはすでにこの設定を、サポートされたSKUの新しいリソースに対して自動的に適用しています。 Azure CLI、ARMテンプレート、REST APIのデプロイを同じデフォルトのホストネーム形式に合わせることで、推奨されるApp Service設定と一貫したプロビジョニングを保ちます。

Note

ホスト名のリージョン識別子 (たとえば、 eastus-01) では、今後のデプロイで異なる数のサフィックスが使用される場合があります。 正確なリージョン番号の組み合わせに対してハード依存関係を取らないでください。

関連するコンテンツ

App Service がサブドメインの引き継ぎを防止する方法

App Service アプリまたは App Service Environment (ASE) を削除すると、最初に DNS を所有していたサブスクリプションのテナントに属するサブスクリプションを除き、対応する DNS の再利用は禁止されます。 したがって、顧客は、関連付けまたは DNS へのポインターをクリーンアップするか、同じ名前でリソースを再作成して Azure で DNS を再利用する時間があります。 この動作は、 *.azurewebsites.net リソースと *.appserviceenvironment.net リソースに対して Azure App Service で既定で有効になるため、顧客の構成は必要ありません。

シナリオ例

サブスクリプション A とサブスクリプション B は、テナント AB に属する唯一のサブスクリプション です。 サブスクリプション A には、DNS 名がされた App Service Web アプリ test.azurewebsites.netが含まれています。 アプリを削除すると、サブスクリプションAまたはBのみが、test.azurewebsites.netという名前のWebアプリを作成することで、のDNS名をすぐに再利用できます。 リソースの削除直後に、他のサブスクリプションが名前を要求することはできません。

サブドメインの引き継ぎを禁止する方法

Azure App Service の DNS エントリを作成するときは、asuid.{サブドメイン} 検証 ID を持つ TXT レコードを作成します。 このような TXT レコードが存在する場合、他の Azure サブスクリプションは、DNS エントリにトークン検証 ID を追加しない限り、カスタム ドメインを検証または引き継ぐことはできません。

これらのレコードにより、CNAME エントリから同じ名前を使用して別の App Service アプリが作成されなくなります。 ドメイン名の所有権を証明することができない脅威アクターが、トラフィックを受信したりコンテンツを制御したりすることはできません。

サイトを削除する前に DNS レコードを更新して、削除から再作成までの間に無効なアクターがドメインを引き継ぎないようにする必要があります。

ドメイン検証 ID を取得するには、「 Azure App Service で既存のカスタム ドメインを設定する」を参照してください。

  • Last updated on