Я видел этот сценарий слишком много раз. Приложение готово. Демонстрация великолепна. Затем появляется чеклист безопасности: убрать хранилище из публичного интернета, запустить внутри VNet, предоставить исходящие IP для allowlist партнёра, доказать, что только правильные подсети общаются с правильными сервисами.
В этот момент модель приложения и модель инфраструктуры начинают расходиться способами, которые болезненно поддерживать.
Новая поддержка корпоративных сетей Azure для Aspire решает это напрямую. Вы описываете форму сети рядом с ресурсами, которые её используют, в вашем AppHost.
Строительные блоки
Вот для чего предназначена каждая концепция сети Azure, в кратком изложении:
| Функция | Используйте когда | Почему это важно |
|---|---|---|
| Виртуальная сеть | Вам нужно частное адресное пространство | Сетевая граница для подсетей, частных endpoints и маршрутизации |
| Подсеть | Вам нужно разделить рабочие нагрузки внутри VNet | Каждая часть системы получает свой собственный диапазон адресов и поверхность политики |
| Делегированная подсеть | Платформенный сервис (например, ACA) должен управлять подсетью | Позволяет сервису безопасно размещать управляемую инфраструктуру в вашей VNet |
| NAT-шлюз | Вам нужны предсказуемые исходящие публичные IP | Стабильный адрес для allowlist и аудита |
| Частный endpoint | Вы хотите, чтобы ресурс PaaS был доступен приватно | Помещает частный IP для этого сервиса внутри вашей VNet, убирает публичную экспозицию |
| NSG | Вам нужны правила трафика на уровне подсети | Явное разрешение/запрет для входящего и исходящего трафика на подсеть |
Описание в AppHost
Ключевое изменение здесь состоит в том, что вы моделируете сеть вместе с ресурсами, которые её используют, а не в отдельном файле Bicep, который со временем расходится с моделью приложения.
Из AppHost вы можете:
- Создавать VNet и подсети с
AddVirtualNetwork()иAddSubnet() - Прикреплять NAT-шлюз к подсетям для стабильных исходящих IP
- Создавать частные endpoints для хранилища, Key Vault, SQL и других PaaS-сервисов
- Определять NSG с правилами входящей и исходящей безопасности
- Настраивать периметры сетевой безопасности для межресурсных политик
В результате когда вы запускаете azd up, инфраструктура соответствует тому, что модель приложения говорит, что ей нужно. Не то, что говорит вручную поддерживаемый шаблон.
Почему Это Важно для Реальных Приложений
Несколько вещей, которые становятся значительно проще, как только сеть смоделирована в Aspire:
Частные endpoints для Key Vault и хранилища — вы описываете WithPrivateEndpoint() на этих ресурсах, и Aspire берёт на себя настройку DNS-зон и присоединение endpoints. Приложение никогда не меняется.
Стабильные исходящие IP — добавьте NAT-шлюз к соответствующей подсети, и каждый исходящий запрос вашего приложения проходит через известный, стабильный IP. Партнёры могут добавить его в allowlist. Аудиторы могут его отследить.
Правила NSG из кода — вместо того чтобы кликать по порталу или поддерживать фрагмент Bicep, ваши правила безопасности живут в AppHost рядом с ресурсами, которые они защищают.
Это тот тип интеграции, который не делает демонстрации захватывающими, но делает производственные системы обслуживаемыми.
Итог
Сетевая безопасность, появляющаяся поздно в жизненном цикле проекта, — решённая проблема, если вы моделируете её вместе с приложением с самого начала. Поддержка корпоративных сетей Aspire делает это возможным без необходимости отдельного инфраструктурного трека.
Полные подробности в оригинальном посте: Securing Azure apps with Aspire enterprise networking
