mcpField
A
azure-app-service-security

azure-app-service-security

github.com/vinayaklattheセキュリティ17876 回インストール19 週間前に更新
リポジトリ

azure-app-service-security について

azure-app-service-security は、Azure App Service 上の Web アプリや API のセキュリティ対策を計画するガイダンススキルです。ID、シークレット、ネットワーク公開、通信保護、監視を扱います。

主な機能

  1. 01マネージド ID と最小権限アクセス
  2. 02Easy Auth によるサインイン設定
  3. 03Key Vault のシークレット参照
  4. 04プライベートエンドポイントと VNet 統合
  5. 05HTTPS、TLS、WAF の強化
  6. 06ログと Defender による監視

活用シーン

  1. 01App Service の Web アプリや API の強化
  2. 02プライベートエンドポイントによる受信制限
  3. 03平文のアプリシークレットを Key Vault 参照へ置換
  4. 04WAF 配下の公開アプリの露出状況を確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/vinayaklatthe/microsoft-security-skills --skill azure-app-service-security

インストール後、Claude Code で/azure-app-service-securityを入力して読み込まれたか確認します。

詳細

Azure App Service のセキュリティ

Azure App Service は、Web アプリや API をマネージド PaaS としてホストします。セキュリティを確保するには、構成内のシークレットをなくし、可能な限りパブリックな公開をなくし、最新の通信方式を適用し、パブリックに公開する必要がある場合は WAF を前段に配置します。

使用する場面

Azure App Service でホストされる Web アプリや API を強化する場合に使用します。このスキルを使用して、Web App／API App の ID、ネットワーク、シークレット、通信方式に関するセキュリティ方針を計画します。

このスキルは使用しないでください。 Azure Functions のみ（類似していますが、別のプラットフォームです）、AKS ワークロード、または VM でホストされる Web アプリには使用しないでください。

公開パターンに応じた構成の選択

公開範囲インバウンドアウトバウンドフロントエンド
内部専用アプリ（イントラネット、VNet ワークロード向け API）プライベートエンドポイント、パブリックアクセス無効スポークへの VNet 統合内部 Application Gateway
機密データを扱うパブリック Web アプリパブリック公開、WAF のみにアクセス制限VNet 統合WAF を Prevention モードにした Front Door または App Gateway
基本的なパブリック Web アプリパブリック公開、既定なし／VNet 統合WAF を備えた App Gateway
パートナーが利用する APIプライベートエンドポイント、前段に APIM を配置VNet 統合APIM（パブリック公開する場合は APIM に WAF を適用）
バックグラウンドワーカー／インバウンドなしパブリックアクセス無効VNet 統合なし

経験則： インターネット上に公開する必要がない場合は、プライベートエンドポイントを使用して、パブリックネットワークアクセスを無効にします。インターネット上に公開する必要がある場合は、WAF を Prevention モードにした Front Door／App Gatewayを前段に配置し、WAF の IP 範囲またはサービス タグからのトラフィックのみをアプリが受け入れるように制限します。

アプローチ

  1. マネージド ID を有効にする — 既定ではシステム割り当てマネージド ID を使用します。Azure SQL（SQL DB Contributor は誤りです。AAD 認証と包含ユーザーを使用します）、Storage（Storage Blob Data Reader）、Key Vault（Key Vault Secrets User）で、最小権限のロールを付与します。 確認方法：アプリにマネージド ID が設定されていること。構成にパスワードが埋め込まれた SQL／Storage 接続文字列がないこと。

  2. サインインには Easy Auth を使用する — 組み込みの App Service authentication（Easy Auth） と Microsoft Entra ID を使用して、認証コードを書かずに OIDC サインインを実現します。リダイレクト URI、トークンストア、requireAuthentication = true を構成して、アプリ全体へのアクセスを制限します。 確認方法：匿名リクエストでは Entra サインインへの 302 リダイレクトが返され、認証済みリクエストではユーザーのプリンシパルクレームとともに 200 が返されること。

  3. Key Vault 参照でシークレットを管理する — シークレットを Key Vault に保存し、アプリ設定で @Microsoft.KeyVault(SecretUri=...) として参照します。コードの変更は不要です。マネージド ID が起動時／更新時にシークレットを読み取ります。 確認方法：アプリ設定で Key Vault Reference が Resolved と表示され、構成にプレーンテキストのシークレットがないこと。

  4. ネットワークを分離する — アウトバウンドには VNet 統合 を使用します（アプリがプライベートエンドポイントやゲートウェイ経由のオンプレミス環境にアクセスできるようにします）。機密性の高いアプリのインバウンドには プライベートエンドポイント を使用します。プライベートエンドポイントを使用する場合は、パブリックアクセスを無効にします。 確認方法：アプリのアウトバウンド IP が統合先のサブネット内にあること。プライベートエンドポイント専用アプリに対するパブリックインターネットからのインバウンドテストで、403 または接続拒否が返されること。

  5. トランスポートを強化する — HTTPS のみを必須にし、TLS 1.2 を最小バージョン（TLS 1.3 を推奨）とし、FTP を無効にします（FTPS またはデプロイセンターのみを使用します）。適切な場合は HSTS を有効にします。 確認方法：HTTP リクエストが HTTPS に 301 リダイレクトされること。httpsOnly = true、minTlsVersion = "1.2" 以上であること。FTP が不要な場合は ftpsState = "Disabled" であること。

  6. パブリック公開時は前段に WAF を配置する — Front Door（グローバル）または WAF を備えた App Gateway（リージョナル）を Prevention モードで使用します。WAF のサービス タグ（AzureFrontDoor.Backend）または IP 範囲と X-Azure-FDID ヘッダーを使用した Access Restrictions で、App Service へのインバウンドを WAF に制限します。 確認方法：App Service の URL への直接リクエストでは 403 が返され、WAF の FQDN 経由のリクエストでは 200 が返されること。

  7. 監視と Defender — 診断ログを Log Analytics に送信し、プランで Defender for App Service を有効にし、アプリのテレメトリには App Insights を使用します。異常な認証失敗に対するアラートを設定します。

ガードレール

  • 機密性の高いアプリではプライベートエンドポイントでパブリックからのインバウンド公開をなくし、パブリックアプリには WAF を組み合わせます。 インターネットに直接公開され、WAF がないアプリは常にスキャンされます。
  • マネージド ID と Key Vault 参照を使用して、構成内のシークレットをなくします。 アプリ設定内の接続文字列は、監査で指摘されるのを待つようなものです。
  • HTTPS のみと最新の TLS を必須にし、レガシープロトコルと FTP を無効にします。 TLS 1.0／1.1 と FTP は、ただちに監査不合格となります。
  • Easy Auth は認可の代わりにはなりません。 認証は行いますが、機密性の高い操作については、コード内でロール／クレームを引き続き確認する必要があります。
  • Access Restrictions は裏口にかける鍵です。 App Service へのアクセスを WAF の IP／FDID ヘッダーに制限しないと、攻撃者は App Service の URL に直接アクセスして WAF を回避できます。
  • Defender for App Service は AV では検出できない脅威を検出します。 Webshell のアップロードや異常なアプリの動作を検出するため、プランで有効にします。

よくあるアンチパターン

  • 「アプリの設定に接続文字列を平文で記載する」 - アプリに対する Reader 権限を持つユーザーなら誰でも参照できます。Key Vault 参照を使用してください。
  • 「WAF を後から追加する予定で、App Service の URL を公開する」 - 攻撃者は初日から WAF を迂回できます。WAF を導入する際にアクセス制限を設定してください。
  • 「レガシーなデプロイのために FTP を有効にする」 - 認証情報が平文で送信されます。FTPS またはデプロイ センターを使用してください。
  • 「レガシーなコールバックが 1 つあるため、HTTPS のみを無効にする」 - コールバックを修正してください。アプリ全体のセキュリティレベルを下げないでください。
  • 「Easy Auth を有効にして、/api/* への匿名アクセスを許可する」 - ゲートの意味がなくなります。すべてを認証し、内部で認可してください。
  • 「パブリックアクセスを無効にせずに VNet 統合を設定する」 - セキュリティを追加しても、古い入口を残したままです。

プロンプトの例

  • Easy Auth、マネージド ID、TLS を使用して Azure App Service の Web アプリを強化してください。
  • プライベート エンドポイントと VNet 統合を使用して App Service を制限するにはどうすればよいですか？
  • 平文のアプリ設定の代わりに、App Service のシークレットには Key Vault 参照を使用してください。
  • App Service の前段に WAF を備えた Front Door を配置し、バックドアを閉じてください。
  • FTP を無効にし、HTTPS のみを適用して、TLS 1.2 以上を設定してください。
  • セキュリティ上の問題がないか、App Service のネットワークと認証の構成を確認してください。

Microsoft Learn

コメント

Markdown 対応