Azure App Serviceのセキュリティコントロールを実装する
Azure App Serviceには、要求がアプリケーション コードに到達する前に、プラットフォーム レイヤーで動作する組み込みのセキュリティ制御がいくつか用意されています。 Contoso Retail の場合、これらのコントロールを適用すると、侵入テストから最初の 2 つのギャップが解消されます。プラットフォーム レベルの認証の強制なし、およびソース IP アドレスからの無制限の受信トラフィックです。
Microsoft Entra ID による認証を構成する
App Service の組み込みの認証機能 (EasyAuth と呼ばれます) は、アプリケーションに到達する前にすべての受信 HTTP 要求をインターセプトするミドルウェア レイヤーとして実行されます。 ID プロバイダーとして Microsoft Entra ID を使用して EasyAuth を構成し、認証されていない要求アクションを Require authentication に設定すると、認証されていない要求がアプリケーション コードに到達することはありません。 プラットフォームは API クライアントに対して 401 応答を返すか、ブラウザー ユーザーを Microsoft Entra サインイン ページにリダイレクトします。
EasyAuth を構成するときは、次の 3 つの設定に注意が必要です。
- トークン ストア: 認証されたユーザーに代わって App Service が OAuth トークンを格納および管理するように、この設定を有効にします。 アプリケーション コードは、トークン管理自体を実装せずに、挿入された HTTP 要求ヘッダーからトークンを読み取ることができます。
- トークン対象ユーザー: アプリケーションのMicrosoft Entraアプリ登録クライアント ID に設定します。 これにより、信頼された発行者証明書で署名されている場合でも、他のアプリケーションに対して発行されたトークンが拒否されます。
- トークンの更新: 有効期限が切れる前にトークンを更新するまでにプラットフォームが待機する時間を構成します。 既定の動作では、トークンが自動的に更新されます。
Azure ポータルで EasyAuth を構成するには、App Service に移動し、 Settings>Authentication を選択し、 [ID プロバイダーの追加] を選択します。 プロバイダーとして Microsoft を選択し、Microsoft Entraテナントとアプリの登録を指定します。
Note
EasyAuth は認証を処理し、ID を検証します。 アプリケーション内のロールベースのアクセスなど、承認の決定には、アプリケーション コードでの実装が必要です。
マネージド ID を使用して送信呼び出しを認証する
App Service は、他のAzure サービス (Azure SQL Database、Key Vault、Azure Storage、Azure AI サービス、Azure OpenAI エンドポイント) への発信呼び出しを行います。 各接続には認証が必要です。 アプリケーション設定または接続文字列に資格情報を格納することはセキュリティ上のリスクです。設定がログ、パイプライン、またはエラー メッセージで公開されている場合、それらの資格情報も公開されます。
システム割り当てマネージド ID によって、このリスクが排除されます。 App Service でマネージド ID を有効にすると、Azure は、その特定の App Service リソースのライフサイクルに紐付けられた ID を Microsoft Entra ID に作成します。 この ID の資格情報を作成、保存、またはローテーションする必要はありません。Azure がそれらを自動的に管理します。
ダウンストリーム サービスにマネージド ID を使用するには、ターゲット リソースのマネージド ID に適切なロールを割り当てます。 例えば次が挙げられます。
- Key Vault に Key Vault Secrets User を割り当てて、シークレットを取得します。
- ストレージ アカウントに ストレージ BLOB データ 閲覧者 を割り当てて BLOB を読み取ります。
- Azure OpenAI リソースに組み込みロールを割り当てて推論エンドポイントを呼び出します。
Azure ポータルでマネージド ID を有効にするには、
HTTPS と最小トランスポート層セキュリティ (TLS) バージョンを適用する
App Service へのすべてのトラフィックは HTTPS 経由で送信されます。 プラットフォームは既定で HTTP 接続を受け入れます。つまり、資格情報、トークン、アプリケーション データは、追加の構成なしで暗号化されていない接続経由で送信できます。 2 つの設定がこのギャップを埋めます。
HTTPS のみ では、すべての HTTP リクエストがアプリケーションに到達する前に HTTPS にリダイレクトされるよう強制します。 Azure ポータルの Settings>Configuration>General settings で有効にします。 次に、HTTPS Only を On に設定します。
最小 TLS バージョン では、受け入れられるプロトコルの最小バージョンが設定されます。 TLS 1.0 または 1.1 を使用してクライアントからの接続を拒否するには、これを 1.2 に設定します。どちらも脆弱性があり、非推奨と見なされます。 TLS バージョンの最小設定は、同じ [全般設定] ページにあります。
アクセス制限を使用して受信トラフィックを制限する
App Service のアクセス制限により、どのソース IP アドレスとネットワーク範囲がアプリケーションに受信要求を送信できるかが制御されます。 規則は、優先度順の許可/拒否リストで構成します。 リストに少なくとも 1 つのルールが含まれている場合、暗黙的な deny-all は、ルールに一致しないソースに適用されます。
App Service と Application Gateway を統合する場合は、次の 2 種類のルールが役立ちます。
- IP ベースの規則: 特定の IPv4 アドレスまたはクラスレス Inter-Domain ルート (CIDR) 範囲を許可します。 これは、Application Gateway のパブリック IP アドレスが静的で既知の場合に使用します。
-
サービス タグ ルール:
AzureApplicationGatewayなどのサービス タグによって識別されるトラフィックを許可します。 この方法は、Application Gateway の IP アドレスの変更に対する回復性が高くなります。
アクセス制限を構成するには、 設定>Networking>Public ネットワーク アクセスに移動します。 [ 追加] を選択してルールを追加し、[ アクション] を [許可] に設定し、ソースの種類と値を指定します。 ルールは優先度順に評価されます。優先順位が最も低いルールが最初に評価されます。
Important
Application Gateway トラフィックのみを許可するようにアクセス制限を構成することは、攻撃者が App Service ホスト名を直接ターゲットにして WAF をバイパスできないようにする手順です。 Application Gateway をデプロイした後は、この手順をスキップしないでください。
プライベート送信アクセスの仮想ネットワーク統合を有効にする
仮想ネットワーク統合により、App Service は、パブリック エンドポイントを持たないAzure仮想ネットワーク内のリソースへの送信接続を行うことができます。 App Service は、仮想ネットワークのアドレス空間全体で、プライベート Azure SQL Database、パブリック アクセスが無効なKey Vault、またはプライベート API エンドポイントに到達できます。
リージョン VNet 統合 は、App Service を仮想ネットワーク内の委任されたサブネットに参加させることで機能します。 App Service からの送信接続は仮想ネットワークの IP アドレス範囲から発信されるため、プライベート リソースはパブリック IP ではなくサブネットに基づいてアクセスを許可できます。
Azure ポータルの Settings>Networking>VNet 統合で仮想ネットワーク統合を構成します。 [ VNet 統合の追加] を選択し、仮想ネットワークとサブネットを選択します。 サブネットは Microsoft.Web/serverFarms に委任する必要があり、他の App Service リソースには使用しないでください。
完全プライベート受信アクセス用のプライベート エンドポイントをデプロイする
プライベート エンドポイントは、仮想ネットワークのサブネット内のプライベート IP アドレスを App Service に割り当てます。 プライベート エンドポイントがデプロイされ、パブリック ネットワーク アクセスが無効になっている場合、App Service にはインターネットに接続するエンドポイントがありません。 アプリケーションへの唯一のパスは、仮想ネットワーク経由です。
この構成は、パブリック エントリ ポイントとして Application Gateway と自然にペアリングされます。 Application Gateway はパブリック IP でインターネット トラフィックを受信し、WAF は各要求を検査し、承認された要求は仮想ネットワーク経由で App Service プライベート エンドポイントに転送されます。 App Service にインターネットから直接到達することはできません。
設定>Networking>Private エンドポイントに移動してプライベート エンドポイントをデプロイし、[追加] を選択します。 プライベート エンドポイントを作成するサブネットを指定し、Azureが必要なプライベート DNS ゾーン エントリを作成できるようにします。
アプリ設定からKey Vaultシークレットを参照する
接続文字列や API キーなどの機密性の高い値をアプリ設定に直接格納する代わりに、Key Vault参照を使用します。 Key Vault参照は、次の形式のアプリ設定値です。
@Microsoft.KeyVault(SecretUri=https://<vault-name>.vault.azure.net/secrets/<secret-name>)
実行時に、App Service は、前に構成したマネージド ID を使用してKey Vaultを呼び出して参照を解決し、実際のシークレット値に置き換えます。 アプリケーション コードは、アプリ設定を正常に読み取り、シークレット値を受け取ります。アプリケーション コードを変更する必要はありません。
Key Vault参照は、資格情報のセキュリティ以外の 2 つの運用上の利点を提供します。 シークレットがKey Vaultでローテーションされた場合、App Service は 24 時間以内に新しい値を自動的に取得するか、次のアプリの再起動または構成の変更時にすぐに新しい値を取得します。 また、シークレットの値は App Service の構成ブレードやデプロイ成果物には表示されないため、誤って公開することは困難です。
Tip
ネットワーク制限付きコンテナーへのアクセスを構成するための完全な参照文字列の構文と手順については、「 Azure App Service でKey Vault参照をアプリ設定として使用する」を参照してください。