既に Azure Pipelines などを使って自動デプロイの環境を構築している場合は、ほぼ全てで Zip Deploy が使われているはずですが、App Service には FTP と Web Deploy がデプロイ方法として提供されているので、塞いでおかないと Visual Studio から手動デプロイされてしまい壊れることがあります。
まだ Visual Studio から本番環境へのデプロイを行っている場合は、速やかに自動デプロイに切り替えましょう。デプロイの安定化とパフォーマンスのために Run From Package を利用するのも良いです。
今の時代、開発中はともかく本番向けデプロイを Visual Studio から行うのは、履歴もバージョン管理も出来ないので速攻で詰みます。
そろそろ Azure Pipelines の Multi-stage pipelines は GA が近いので触っておくのも良いです。
話を戻すと App Service は FTP の無効化は Azure Portal から簡単に行えますが、Web Deploy に関しては設定が存在しないのを何とか無効化しようという話です。
App Service 側を塞いでおくと、どう頑張っても Visual Studio からのデプロイは行えなくなります。
FTP を無効化する
先に FTP をサクッと塞いでおきます。Configuration にある FTP state を Disabled に変えるだけです。
これで FTP での接続が行えなくなるので、ファイルシステムを直接弄られる危険性はなくなりました。
Web Deploy を無効化する
App Service では Web Deploy は Site Extension として実装されているので、App Settings に特殊なキーを追加することで個別に無効化できます。
具体的なキー名は SiteExtensionName_EXTENSION_VERSION となります。Site Extension の名前は Kudu を使ってフォルダ名を調べればよいです。
キー名が示すように Azure Functions ではランタイムバージョンを指定するのに使っていますが、このキーに disabled を設定すると無効化されます。
実際にキーを設定後に Visual Studio からデプロイを試してみるとエラーとなります。
App Service には他にも IIS Manager からの接続を行うための Site Extension などもあるので、必要に応じて無効化しておいても良いかもしれません。
Kudu / API 経由でのアクセスを無効化する
App Service に対してある意味最強の操作が行える Kudu ですが、これを塞ぐことは出来ません。内部の API は Azure 内部でも使われているので、無理やり止めようとすると操作不能に陥ります。
なので現実的な解決策としては RBAC を使って、ユーザーに対して Reader 権限だけ割り当ててしまうことです。これで読み取りのみになるので Kudu へのアクセスがブロックされます。
デプロイ周りの自動化を行うと Azure Portal や ARM API へのアクセスを絞っても問題がなくなるので、いい感じに Azure Pieplines や RBAC を活用して不用意にリソースを弄らせない、そもそも直アクセスする必要がなくなるようにしましょう。
