【Azure】「アプリ名.azurewebsites.net」じゃない？　App ServiceのFQDNが変わった理由と対策：Tech TIPS

　本Tech TIPSでは、「一意の既定のホスト名（Unique Default Host）」と呼ばれるこの機能が導入された理由と、その使い方や注意点について説明する。

【Azureポータル】「一意の既定のホスト名」を有効化／無効化するには

　「一意の既定のホスト名」の導入理由については後にして、先に「一意の既定のホスト名」の仕様や設定方法を見ていこう。

　AzureポータルからApp ServiceでWebアプリを作成する場合、執筆時点では「一意の既定のホスト名」が最初から有効になっている。

【Azureポータル】「一意の既定のホスト名」を有効化または無効化する

　［安全な一意の既定のホスト名……］スイッチを「オン」にした場合、デフォルトのFQDNは以下のようになる。

　高度なツールのサイト（SCM）のFQDNも以下のように変わる。

　上記のスクリーンショットでは、＜ハッシュ値＞が「gbasfddrbjbmawdu」、＜リージョン名＞が「japaneast」（東日本リージョン）、＜数値＞が「01」となっていた。これらの値はいずれも自動的に決定される。任意の値を指定することはできない。＜ハッシュ値＞については、同じテナント内でアプリ名を変えずにApp Serviceを作り直す限り、同じ値が割り当てられる。

　［安全な一意の既定のホスト名……］スイッチを「オフ」にすると、2023年以前と同じ以下のFQDNがデフォルトで割り当てられる。

　既に作成済みのApp Serviceで、ハッシュなしのFQDNからハッシュ付きFQDNへ、あるいはその逆に変更することはできないので注意してほしい。

【Bicep】「一意の既定のホスト名」を有効化／無効化するには

　BicepやARMテンプレートからApp Serviceをデプロイ（生成）する場合、「一意の既定のホスト名」を有効化または無効化するには、以下のように「Microsoft.Web/sites」リソースの［properties］−［autoGeneratedDomainNameLabelScope］プロパティを設定する必要がある。

　「一意の既定のホスト名」を無効化して2023年以前と同じ「＜アプリ名＞.azurewebsites.net」というデフォルトのFQDNを割り当てるには、「autoGeneratedDomainNameLabelScope: null」と指定すればよい（「null」は引用符で括らないこと）。「autoGeneratedDomainNameLabelScope」を記述していない場合も、執筆時点では「null」と同じ結果が得られる。

　前述したAzureポータルの場合と同じルールで割り当てたいなら、「autoGeneratedDomainNameLabelScope: 'TenantReuse'」と指定すればよい。アプリ名を変えずにApp Serviceを作り直したとき、それが同一テナント内のことであれば、どのサブスクリプションやリソースグループでも、生成／付加されるハッシュ値は常に一定となる。「'SubscriptionReuse'」なら同一テナント／サブスクリプション内、「'ResourceGroupReuse'」なら同一テナント／サブスクリプション／リソースグループ内で、同じことが当てはまる。

　一方、「autoGeneratedDomainNameLabelScope: 'NoReuse'」と指定すると、たとえ同じテナント／サブスクリプション／リソースグループ／アプリ名でも、アプリ（App Serviceのリソース）を作り直すたびに異なるハッシュ値が生成／付加される。

なぜ「一意の既定のホスト名」が導入されたのか？

　「一意の既定のホスト名」が導入された理由をひと言で説明するなら、「乗っ取り防止」といえるだろう。

　2023年以前のApp Serviceでは、下図のような攻撃が可能だった。

削除し忘れていたDNSレコードを悪用した攻撃手法

　App Serviceをはじめとする多くのAzureリソースでは、以前に誰かが作成するも削除したリソースの名称を、それとは全く関係のない別の誰かが新たに作ったリソースに付けることができる。つまり、悪意を持つ攻撃者が、以前にAzureユーザーが作成して削除したのと同じ名前のApp Serviceを作成できるということだ。

　そして2023年以前のApp Serviceでは、アプリ名が同じならデフォルトのFQDNも同じになる。

　ここで、正規のユーザーがApp Serviceを生成してカスタムドメインを割り当て、しばらく運用した後、App Serviceは削除したけど、カスタムドメインをApp Serviceにひも付けるDNSリソースレコードはうっかり残したままだったとしよう（これは筆者もしたことがある）。

　この状況で、攻撃者が同じアプリ名でApp Serviceを作成できれば、エンドユーザーを（以前は信頼されていた）カスタムドメイン経由であっさりとそのApp Service上の（悪意のある）サイトに誘導できるようになっていた。カスタムドメインの乗っ取りといえる。

　こうした攻撃を防ぐ対策の一つとして導入されたのが「一意の既定のホスト名」である。App Service作成者が任意の値を指定できないハッシュ値をデフォルトのFQDNに挿入することで、攻撃者が同一のデフォルトFQDNを持つApp Serviceを作成することを困難にさせるわけだ。

App ServiceのデフォルトのFQDNを確認するには

　「一意の既定のホスト名」を有効化すると、アプリ名だけからデフォルトのFQDNを特定できなくなる。デプロイ時のスクリプトなどでデフォルトのFQDNが必要な場合には、何らかの方法でそれを取得する必要がある。

　それには、App Serviceのオブジェクトの「DefaultHostName」プロパティを参照すればよい。以下にAzure PowerShellのコード例を記す。

これからどのように「一意の既定のホスト名」に対処すべきか？

　ここからは筆者の推測になる。

　「一意の既定のホスト名」はセキュリティ対策なので、致命的な不具合などよほどのことがない限り推進されるだろう。実際、Microsoftはこの機能を有効にすることを強く推奨している。

　前述の通り、AzureポータルからApp Serviceを作成する場合、すでに「一意の既定のホスト名」はデフォルトで有効になる。Bicep／ARMテンプレートの場合は執筆時点で無効とはいえ、近い将来、デフォルトで有効になる可能性は十分にある。

　実際、Tech TIPS「【Azure】App ServiceのFTPサーバにアクセスできなくなった場合の対処方法」で説明したように、App ServiceのFTPの基本認証はセキュリティ対策のため、デフォルトで有効だったのが無効に変わり、デプロイのコードの修正が必要になった。

　「一意の既定のホスト名」に対応しないまま古いデプロイのコードを使い続けていると、ある日、デプロイし直した時にデフォルトのFQDNがハッシュ付きに変わり、DNSの名前解決などに致命的な不具合が生じる、といった事態を招きかねない（事前にMicrosoftからデフォルトの変更について警告が発せられるとは思うが）。

　ならば、早めに「一意の既定のホスト名」を有効にするようにデプロイのコードを修正するなどの対処をした方が、運用とセキュリティの両面でもっと安全になるのではないだろうか。

　すぐに対処するのが難しいなら最低限、「autoGeneratedDomainNameLabelScope: null」を追記して明示的に無効化しておいた方がよいだろう。

「Tech TIPS」