少し前に Azure CDN か Front Door を利用しているユーザー向けに以下のようなメールが届いていると思います。運用中の CDN / Front Door に関しては影響はないですが、削除する前にそれらをポイントしている DNS レコードを前もって削除しないといけなくなりました。
CNAME レコードとメールには記載されていますが、実際に試したところ A レコード + Alias record set の組み合わせの場合でも、CDN / Front Door 削除時にチェックが走ってエラーとなりました。
何故今回のような変更が行われたかというと、言わずもがな Subdomain Takeover への対策になります。
去年、主に Cloud Services と Traffic Manager に対しての Subdomain Takeover が大規模に行われていることが発見され、結構な大ごとになりました。当時のまとめは以下のエントリに記載しています。
Cloud Services や Traffic Manager と同様に CDN / Front Door は同名のリソースを再取得できるのと、カスタムドメインの追加時に CNAME のチェックしか行われないのでこのままだと攻撃対象にはなりますが、リソースの削除時にチェックを入れることで DNS レコードを確実に削除させる方向での対応になっています。*1
今回のアップデートに関しては Azure における Subdomain Takeover への対策をまとめたドキュメントへは反映されていないようですが、しばらくすればアップデートされると思います。
このドキュメントはちょいちょいアップデートされていて、当時は機能として存在しなかった Azure Defender for App Service を使った方法も紹介されています。Security Center はベストプラクティスを理解するのに有用なので、重要なリソースに対しては有効にしておきたい機能です。
既にカスタムドメインを当てている CDN / Front Door があったので、DNS レコードを削除することなくリソースの削除を試してみると、以下のようにエラーとなりました。
エラーメッセージも分かりやすいものになっているので、今後は CDN / Front Door に関しては Subdomain Takeover を受けるリスクが下がったかと思います。
ちなみに Cloud Services に関しては Extended support でも特に変化はないので、利用者に委ねられているのは変わらずです。早急に App Service などの対策が行われたマネージドサービスへ移行するのが良いです。
Azure Front Door Standard / Premium の場合
若干事情が異なるのが、少し前にプレビューとして公開された Front Door Standard / Premium です。
名前としては Front Door が付いているものの、リソースとしては全くの別物で ARM 的には CDN 寄りという違和感のある命名ですが、完全に新規ということでカスタムドメインの追加周りが大きく変わっています。
具体的には App Service のようにユニークな ID を使った検証が必要になりました。
CDN / Front Door も CNAME レコードを使った検証は必要でしたが、値が CDN / Front Door の FQDN なので Subdomain Takeover 対策としては意味が無いものでした。その点 Standard / Premium ではちゃんと意味のある対策になっています。
実際に適当なドメインを追加して確認してみました。Azure managed DNS というのは Azure DNS に対して自動で必要なレコードを作る機能なので、今回はあえて選びませんでした。
これでドメインを追加すると Validation state が Pending になって、ドメインの検証が追加で要求されます。
Pending 部分をクリックすると必要なレコードの情報が表示されるので、この情報に従って TXT レコードを作成すれば検証が終わります。レコードに設定する値がユニークな ID になっているので、もし削除を忘れていたとしてもチェックが通らないのでドメインを追加できないというわけです。
複数サブスクリプションでの検証はしていないですが、App Service と同様にサブスクリプション単位で TXT レコードに設定する値が変わるのだと思います。
基本的にカスタムドメインを設定可能なサービスに関しては追加時にユニークな ID を使ったチェック、削除時の DNS レコード消し忘れチェック、難しい場合は Azure Defender での保護になるのかと思います。
*1:既存のリソースとの兼ね合いで追加時のチェックを入れるのは難しかったのだと思われます
