このシナリオを何度も見てきました。アプリは完成しています。デモは素晴らしい。そしてセキュリティチェックリストが現れます: ストレージをパブリックインターネットから外す、VNet 内で実行する、パートナーのアローリスト用に送信 IP を提供する、正しいサブネットだけが正しいサービスと通信することを証明する。
この時点でアプリケーションモデルとインフラストラクチャモデルが乖離し始め、維持するのが辛くなります。
Aspire の新しい Azure エンタープライズネットワーキングサポートはこれに直接対処します。ネットワークの形状を AppHost 内で、それを使用するリソースの隣に記述します。
構成要素
各 Azure ネットワーキングの概念が何のためのものかを、要約してまとめます:
| 機能 | 使用するとき | 重要な理由 |
|---|---|---|
| 仮想ネットワーク | プライベートアドレス空間が必要なとき | サブネット、プライベートエンドポイント、ルーティングのためのネットワーク境界 |
| サブネット | VNet 内でワークロードを分離する必要があるとき | システムの各部分が独自のアドレス範囲とポリシーサーフェスを取得 |
| 委任サブネット | プラットフォームサービス（ACA など）がサブネットを管理する必要があるとき | サービスが管理されたインフラを VNet に安全に配置できる |
| NAT ゲートウェイ | 予測可能な送信パブリック IP が必要なとき | アローリストと監査のための安定したアドレス |
| プライベートエンドポイント | PaaS リソースをプライベートにアクセスしたいとき | そのサービスのプライベート IP を VNet 内に配置し、公開露出を除去 |
| NSG | サブネットレベルのトラフィックルールが必要なとき | サブネットごとの受信・送信トラフィックの明示的な許可/拒否 |
AppHost での記述
ここでの重要な変化は、ネットワークを使用するリソースの隣にモデル化していることです。時間の経過とともにアプリモデルから離れていく別の Bicep ファイルではありません。
AppHost から以下が可能です:
AddVirtualNetwork()とAddSubnet()で VNet とサブネットを作成- 安定した送信 IP のためにサブネットに NAT ゲートウェイを付加
- ストレージ、Key Vault、SQL、その他の PaaS サービスのプライベートエンドポイントを作成
- 受信・送信セキュリティルールで NSG を定義
- クロスリソースポリシーのためのネットワークセキュリティ境界を構成
結果として azd up を実行すると、インフラストラクチャはアプリモデルが必要と言っているものと一致します。手動で維持されたテンプレートが言うものではありません。
実際のアプリケーションにとって重要な理由
Aspire でネットワークをモデル化すると大幅に楽になるいくつかのこと:
Key Vault とストレージのプライベートエンドポイント — これらのリソースに WithPrivateEndpoint() を記述すると、Aspire が DNS ゾーン設定とエンドポイントの接続を処理します。アプリは変更されません。
一貫した送信 IP — 関連するサブネットに NAT ゲートウェイを追加すると、アプリからのすべての送信リクエストが既知の安定した IP を通過します。パートナーはアローリストに登録できます。監査担当者は追跡できます。
コードからの NSG ルール — ポータルをクリックしたり Bicep スニペットを維持したりする代わりに、セキュリティルールは保護するリソースの隣に AppHost に存在します。
これは、デモを興奮させるものではありませんが、プロダクションシステムを保守可能にする種類の統合です。
まとめ
プロジェクトのライフサイクルの後半にネットワークセキュリティが現れるのは、最初からアプリと一緒にモデル化すれば解決済みの問題です。Aspire のエンタープライズネットワーキングサポートは、別のインフラストラクチャトラックを必要とせずにそれを可能にします。
完全な詳細は元の投稿で: Securing Azure apps with Aspire enterprise networking
