Применение принципов нулевого доверия к периферийной виртуальной сети с помощью Служб PaaS Azure
В этой статье описаны принципы модели безопасности нулевого доверия к рабочей нагрузке PaaS с помощью виртуальных сетей Azure и частных конечных точек следующим образом:
| Принцип нулевого доверия | Определение | Встречалась |
|---|---|---|
| Прямая проверка | Всегда выполняйте аутентификацию и авторизацию на основе всех доступных точек данных. | Используйте обнаружение угроз в Брандмауэр Azure и Шлюз приложений Azure для проверки трафика и проверки допустимости трафика. |
| Использование доступа с минимальными привилегиями | Ограничьте доступ пользователей с помощью технологий JIT/JEA, а также адаптивных политик на основе рисков и средств защиты данных. | Уменьшите входящий трафик и исходящий трафик из служб Azure в частную сеть. Используйте группы безопасности сети, чтобы разрешить только определенные входящий трафик из виртуальной сети. Используйте центральный экземпляр Брандмауэр Azure для предоставления доступа к службе Azure, отличной от виртуальной сети. |
| Предполагайте наличие бреши в системе безопасности | Минимизируйте радиус поражения и возможность доступа к сегменту. Используйте сквозное шифрование и аналитику для обеспечения видимости, обнаружения угроз и усиления защиты. | Ограничить ненужный обмен данными между ресурсами. Убедитесь, что вы выполняете ведение журнала из групп безопасности сети и что у вас есть правильная видимость аномального трафика. Отслеживайте изменения групп безопасности сети. |
Дополнительные сведения о применении принципов нулевого доверия в среде IaaS Azure см. в обзоре принципов применения нулевого доверия к Azure IaaS.
Не доверяйте автономной или периферийной сети для служб PaaS Azure
Многие службы PaaS содержат собственные функции управления входящего трафика и исходящего трафика. Эти элементы управления можно использовать для защиты сетевого доступа к ресурсам службы PaaS без необходимости инфраструктуры, например виртуальных сетей. Например:
- База данных SQL Azure имеет собственный брандмауэр, который можно использовать для разрешения определенных IP-адресов клиента, которым требуется доступ к серверу базы данных.
- Учетные записи хранения Azure имеют параметр конфигурации, разрешающий подключения из определенной виртуальной сети или блокировать доступ к общедоступной сети.
- служба приложение Azure поддерживает ограничения доступа для определения упорядоченного приоритетом списка разрешений и запретов, который управляет сетевым доступом к приложению.
Однако для управляемых реализаций нулевого доверия эти средства управления доступом на основе службы часто не хватает. Это создает распространение средств управления доступом и ведение журнала, которые могут повысить управление и уменьшить видимость.
Кроме того, службы PaaS могут использовать полные доменные имена (FQDN), которые разрешают динамически назначенный общедоступный IP-адрес, выделенный из пула общедоступных IP-адресов в определенном регионе для типа службы. Из-за этого вы не сможете разрешить трафик из определенной службы PaaS или из нее с помощью общедоступного IP-адреса, который может измениться.
Корпорация Майкрософт рекомендует использовать частные конечные точки. Частная конечная точка — это интерфейс виртуальной сети, использующий частный IP-адрес из виртуальной сети. Этот сетевой интерфейс надежно подключается к службе через Приватный канал Azure. Включив частную конечную точку, вы переносите службу в виртуальную сеть.
В зависимости от сценария решения может потребоваться общедоступный входящий доступ к службам PaaS. Но если вы этого не сделаете, корпорация Майкрософт рекомендует, чтобы весь трафик оставался закрытым, чтобы устранить потенциальные риски безопасности.
В этом руководстве приведены инструкции по определенной эталонной архитектуре, но принципы и методы можно применять к другим архитектурам по мере необходимости.
Эталонная архитектура
На следующей схеме показана общая эталонная архитектура для рабочих нагрузок на основе PaaS.
На схеме:
- Периферийная виртуальная сеть включает компоненты для поддержки приложения PaaS.
- Приложение PaaS — это двухуровневое приложение, которое использует службы приложение Azure для веб-приложения или внешнего интерфейса и База данных SQL Azure для реляционных баз данных.
- Каждый уровень содержится в выделенной подсети для входящего трафика с выделенной группой безопасности сети.
- Веб-уровень содержит выделенную подсеть для исходящего трафика.
- Доступ к приложению предоставляется через Шлюз приложений, содержащийся в собственной подсети.
На следующей схеме показана логическая архитектура этих компонентов в подписке Azure.
На схеме все компоненты периферийной виртуальной сети содержатся в выделенной группе ресурсов:
- Одна виртуальная сеть
- Одна Шлюз приложений Azure (Приложение GW), включая Брандмауэр веб-приложений (WAF)
- Три группы безопасности сети (с именем NSG на схеме) для баз данных, приложений и интерфейсных уровней
- Две группы безопасности приложений (с именем ASG на схеме)
- Две частные конечные точки
Кроме того, ресурсы для виртуальной сети концентратора развертываются в соответствующей подписке на подключение.
Что такое в этой статье
Принципы нулевого доверия применяются в архитектуре от уровня клиента и каталога до назначения виртуальных машин группам безопасности приложений. В следующей таблице описаны рекомендации по защите этой архитектуры.
| Шаг | Задача |
|---|---|
| 1 | Используйте Microsoft Entra RBAC или настройте пользовательские роли для сетевых ресурсов. |
| 2 | Изоляция инфраструктуры в собственной группе ресурсов. |
| 3 | Создайте группу безопасности сети для каждой подсети. |
| 4 | Защита трафика и ресурсов в виртуальной сети:
|
| 5 | Защита входящего трафика и исходящего трафика для служб Azure PaaS. |
| 6 | Безопасный доступ к виртуальной сети и приложению. |
| 7 | Включите расширенное обнаружение угроз, оповещение и защиту. |
В этом руководстве предполагается, что у вас уже есть служба приложение Azure и База данных SQL Azure развернуты в собственных группах ресурсов.
Шаг 1. Использование Microsoft Entra RBAC или настройка пользовательских ролей для сетевых ресурсов
Встроенные роли Microsoft Entra RBAC можно использовать для сетевых участник. Однако другим подходом является использование пользовательских ролей. Не требуется полный доступ к сетевым ресурсам, предоставляемым ролью участника сети Microsoft Entra RBAC, но требуется больше разрешений, чем другие распространенные роли. Пользовательская роль может использоваться для область доступа только к необходимым.
Один из простых способов реализации заключается в развертывании пользовательских ролей, найденных в эталонной архитектуре целевой зоны Azure.
Определенная роль, которую можно использовать, — это пользовательская роль управления сетями, которая имеет следующие разрешения:
- Чтение всех в область
- Любые действия с поставщиком сети
- Любые действия с поставщиком поддержки
- Любые действия с поставщиком ресурсов
Эту роль можно создать с помощью скриптов в репозитории эталонной архитектуры GitHub целевой зоны Azure или создать с помощью идентификатора Microsoft Entra с пользовательскими ролями Azure.
Шаг 2. Изоляция инфраструктуры в собственной группе ресурсов
Изолируя сетевые ресурсы от вычислительных ресурсов, данных или ресурсов хранилища, вы снижаете вероятность возникновения разрешений. Кроме того, гарантируя, что все связанные ресурсы находятся в одной группе ресурсов, можно сделать одно назначение безопасности и улучшить управление ведением журнала и мониторингом этих ресурсов.
Вместо того, чтобы ресурсы периферийной сети были доступны в нескольких контекстах в общей группе ресурсов, создайте выделенную группу ресурсов. На следующей схеме архитектуры показана эта конфигурация.
На схеме ресурсы и компоненты в эталонной архитектуре делятся на выделенные группы ресурсов для служб приложений, баз данных SQL Azure, учетных записей хранения, ресурсов виртуальной сети концентратора и периферийных ресурсов виртуальной сети.
С помощью выделенной группы ресурсов можно назначить пользовательскую роль с помощью предоставления пользователю доступа к ресурсам Azure с помощью руководства по портал Azure.
Дополнительные рекомендации:
- Ссылка на группу безопасности для роли вместо именованных лиц.
- Управление доступом к группе безопасности с помощью методов управления корпоративными удостоверениями.
Если вы не используете политики, которые принудительно перенаправляют журналы в группах ресурсов, настройте его в журнале действий для группы ресурсов:
- Найдите группу ресурсов в портал Azure.
- Перейдите к журналу действий —> экспорт журналов действий и нажмите кнопку "Добавить параметр диагностики".
- На экране параметра диагностики выберите все категории журналов (особенно безопасность) и отправьте их в соответствующие источники ведения журнала, например рабочую область Log Analytics для наблюдения или учетную запись хранения для долгосрочного хранения. Приведем пример:
Ознакомьтесь с диагностическими Параметры, чтобы понять, как просматривать эти журналы и оповещать их.
Демократизация подписки
Несмотря на то, что вы не связаны напрямую с сетью, следует запланировать подписку RBAC аналогичным образом. Помимо логического изоляции ресурсов по группе ресурсов, следует также изолировать подписку на основе бизнес-областей и владельцев портфеля. Подписка в качестве единицы управления должна быть узко область.
Дополнительные сведения см. в принципах проектирования целевой зоны Azure.
Шаг 3. Создание группы безопасности сети для каждой подсети
Группы безопасности сети Azure используются для фильтрации сетевого трафика между ресурсами Azure в виртуальной сети Azure. Рекомендуется применить группу безопасности сети к каждой подсети. Это применяется через политику Azure по умолчанию при развертывании целевых зон Azure. В этой группе содержатся правила безопасности, которые разрешают или запрещают исходящий и входящий сетевой трафик нескольких типов ресурсов Azure. Для каждого правила можно указать исходные и конечные IP-адреса, протокол (например, TCP или UDP) и порт.
Для многоуровневых приложений рекомендуется создать выделенную группу безопасности сети (NSG) на следующей схеме для каждой подсети, в которую размещается сетевой компонент.
На схеме:
- Каждый уровень приложения имеет выделенную подсеть входящего трафика, например одну для веб-уровня и другую для уровня данных.
- приложение Azure Services имеет выделенную подсеть исходящего трафика для определенной службы приложений.
- Группа безопасности сети настроена для каждой из этих подсетей.
Настройка групп безопасности сети по-другому, чем на схеме, может привести к неправильной настройке некоторых или всех групп безопасности сети и может создавать проблемы при устранении неполадок. Кроме того, это может затруднить мониторинг и ведение журнала.
См. статью "Создание, изменение или удаление группы безопасности сети Azure" для управления параметрами групп безопасности сети.
Узнайте больше о группах безопасности сети, чтобы понять, как их можно использовать для защиты сред.
Шаг 4. Защита трафика и ресурсов в виртуальной сети
В этом разделе описаны следующие рекомендации.
- Развертывание базовых правил запрета для групп безопасности сети
- Развертывание правил для конкретного приложения
- Планирование трафика управления в виртуальной сети
- Развертывание ведения журнала потоков группы безопасности сети
Развертывание базовых правил запрета для групп безопасности сети
Ключевым элементом нулевого доверия является использование минимального уровня доступа. По умолчанию группы безопасности сети имеют правила разрешения . Добавив базовый план правил запрета, вы можете применить минимальный уровень доступа. После подготовки создайте правило запрета во всех правилах для входящего и исходящего трафика с приоритетом 4096. Это последний пользовательский приоритет, который означает, что оставшиеся область для настройки разрешений действий.
Для этого в группе безопасности сети перейдите в правила безопасности исходящего трафика и нажмите кнопку "Добавить". Укажите следующие сведения.
- Источник: Любой
- Диапазоны исходных портов: *
- Назначение: Любое
- Служба: настраиваемая
- Диапазоны портов назначения: *
- Протокол: Любой
- Действие: Запретить
- Приоритет: 4096
- Имя: DenyAllOutbound
- Описание. Запрещает весь исходящий трафик, если только не разрешено.
Рассмотрим пример.
Повторите этот процесс с правилами входящего трафика, изменив имя и описание соответствующим образом.
На вкладке " Правила безопасности для входящего трафика" отображается предупреждение для правила. Рассмотрим пример.
Щелкните правило и прокрутите вниз, чтобы просмотреть дополнительные сведения. Приведем пример:
Это сообщение дает следующие два предупреждения:
- Azure Load Balancers по умолчанию не сможет получить доступ к ресурсам с помощью этой группы безопасности сети.
- Другие ресурсы в этой виртуальной сети по умолчанию не смогут получить доступ к ресурсам с помощью этой группы безопасности сети.
Для нашей цели в нулевом доверии это то, как это должно быть. Это означает, что только потому, что что-то находится в этой виртуальной сети, не означает, что он будет иметь немедленный доступ к вашим ресурсам. Для каждого шаблона трафика создайте правило явно, разрешающее его, и это необходимо сделать с минимальным количеством разрешений.
Если у вас есть определенные исходящие подключения для управления, например контроллеры домена домен Active Directory служб (AD DS), частные виртуальные машины DNS или определенные внешние веб-сайты, они должны контролироваться здесь.
Альтернативные правила запрета
Примечание.
Рекомендации в этом разделе применяются только к подсети веб-исходящего трафика.
Если вы используете Брандмауэр Azure для управления исходящими подключениями, вместо выполнения запрета на исходящий трафик можно создать альтернативные правила для исходящих подключений. В рамках реализации Брандмауэр Azure вы настроите таблицу маршрутов, которая отправляет трафик по умолчанию (0.0.0.0/0/0) брандмауэру. Это будет обрабатывать трафик за пределами виртуальной сети.
Затем можно создать правило запрета для всех исходящих подключений виртуальной сети или разрешить все правила исходящего трафика, но безопасные элементы с их правилами для входящего трафика.
Ознакомьтесь с Брандмауэр Azure и таблицами маршрутов, чтобы понять, как их можно использовать для дальнейшего повышения безопасности среды.
Развертывание правил для конкретного приложения
Определите шаблоны трафика с минимальным количеством разрешений и только после явно разрешенных путей. Используя подсети в качестве источников, определите шаблоны сети в группах безопасности сети. Рассмотрим пример.
Используйте группы безопасности сети: создайте процесс правила безопасности для добавления правил в группы безопасности сети.
Чтобы защитить этот сценарий, добавьте следующие правила:
| Группа безопасности сети для подсети | Направление | Исходный код | Сведения об источнике | Исходный порт | Назначение | Сведения о назначении | Service | Имя группы безопасности сети | Описание группы безопасности сети |
|---|---|---|---|---|---|---|---|---|---|
| подсеть Служба приложений | Входящий трафик | IP-адреса | Диапазон частных IP-адресов подсети Шлюз приложений | 443 | IP-адреса | Явный IP-адрес частной конечной точки Служба приложений | MS SQL | AllowGWtoAppInbound | Разрешает входящий доступ к Служба приложений из Шлюз приложений. |
| подсеть интеграции Служба приложений | Исходящие | IP-адреса | Диапазон IP-адресов Служба приложений интеграции подсети | 1433 | IP-адреса | Явный IP-адрес частной конечной точки базы данных SQL | MS SQL | AllowApptoSQLDBOutbound | Разрешает исходящий доступ к частной конечной точке SQL из подсети интеграции Служба приложений. |
| Подсеть SQL Azure | Входящий трафик | IP-адреса | Диапазон IP-адресов Служба приложений интеграции подсети | 1433 | IP-адреса | Явный IP-адрес частной конечной точки базы данных SQL | MS SQL | AllowApptoSQLDBInbound | Разрешает входящий доступ к частной конечной точке SQL из подсети интеграции Служба приложений. |
Примечание.
Иногда исходный трафик может поступать из разных портов, и если этот шаблон возникает, можно добавить диапазоны исходных портов в "*", чтобы разрешить любой исходный порт. Конечный порт является более значительным, и некоторые рекомендации всегда используют "*" для исходного порта.
Примечание.
Для приоритета используйте значение от 100 до 4000. Вы можете начать с 105.
Это в дополнение к правилам группы безопасности сети в вашей Шлюз приложений подсети.
С помощью этих правил вы определили шаблон подключения "Нулевое доверие" для одного уровня приложений. Этот процесс можно повторить по мере необходимости для дополнительных потоков.
Планирование трафика управления в виртуальной сети
Помимо трафика, зависящее от приложения, запланируйте трафик управления. Однако, поскольку трафик управления обычно происходит за пределами периферийной виртуальной сети, требуются дополнительные правила. Во-первых, ознакомьтесь с определенными портами и источниками, из которым будет поступать трафик управления. Как правило, весь трафик управления должен передаваться из брандмауэра или другой виртуальной сети (модуль) (NVA), расположенного в центральной сети для периферийной сети.
Общие сведения о полной эталонной архитектуре см. в статье "Применение принципов нулевого доверия к Azure IaaS".
Конфигурация зависит от конкретных потребностей управления. Однако следует использовать правила брандмауэра (модуль) и правила в группе безопасности сети, чтобы явным образом разрешить подключения на стороне сети платформы и рабочей нагрузки.
Планирование развертываний
Так как службы и базы данных приложений теперь используют частные сети, планируйте развертывание кода и данных в этих ресурсах. Добавьте правила, чтобы разрешить частным серверам сборки доступ к этим конечным точкам.
Развертывание ведения журнала потоков группы безопасности сети
Даже если ваша группа безопасности сети блокирует ненужный трафик, он не означает, что ваши цели выполнены. Чтобы обнаружить атаку, необходимо по-прежнему наблюдать за трафиком, который происходит за пределами явных шаблонов.
Трафик к частным конечным точкам не регистрируется, но если другие службы развертываются в подсетях позже, этот журнал поможет обнаружить действия.
Чтобы включить ведение журнала потоков группы безопасности сети, выполните инструкции по журналу потока сетевого трафика в виртуальную машину и из виртуальной машины для существующей группы безопасности сети для частных конечных точек.
Примечание.
Имейте в виду следующие рекомендации:
При необходимости следует ограничить доступ к журналам.
Журналы должны передаваться в Log Analytics и Microsoft Sentinel по мере необходимости.
Шаг 5. Защита входящего трафика и исходящего трафика для служб PaaS Azure
В этом разделе содержатся два шага, необходимых для защиты входящего трафика и исходящего трафика для служб PaaS:
- Разверните частные конечные точки для входящего трафика в службы.
- Разверните интеграцию виртуальной сети, чтобы служба приложений могли взаимодействовать с виртуальной сетью.
Кроме того, следует также рассмотреть конфигурацию DNS, чтобы разрешить разрешение имен.
Развертывание частных конечных точек для входящего трафика
Хотя многие службы позволяют создавать частные конечные точки из колонки конкретного ресурса в портал Azure, более последовательный интерфейс заключается в создании частной конечной точки из собственного создания ресурсов. Для этого ресурсы должны быть развернуты. После развертывания можно создать частную конечную точку.
При развертывании частных конечных точек настройте их следующим образом:
- Поместите их в определенную группу ресурсов, в которой размещаются родительские ресурсы, чтобы сохранить ресурсы с аналогичным жизненным циклом вместе и обеспечить центральный доступ.
- Поместите их в соответствующую подсеть в виртуальной сети на основе их роли.
- Для службы приложение Azure можно настроить частные конечные точки как для обычного внешнего интерфейса, так и для конечной точки SCM, которая используется для развертываний и управления.
Кроме того, в рамках этого развертывания необходимо убедиться, что брандмауэр для конкретной службы должен запретить входящий трафик. Это отклонит любые попытки входящего трафика.
Для базы данных SQL Azure управляйте правилами брандмауэра IP-адресов на уровне сервера. Убедитесь, что для общедоступного сетевого доступа установлено значение Disable from the network panel in the портал Azure.
Для службы приложение Azure добавление частной конечной точки задает брандмауэр уровня обслуживания для блокировки входящего доступа по умолчанию. Дополнительные сведения см. в статье Использование частных конечных точек для приложений Служба приложений.
Развертывание интеграции виртуальной сети для исходящего трафика
Помимо частных конечных точек для входящего трафика, включите интеграцию виртуальной сети. Каждый план Служба приложений может включать интеграцию виртуальной сети, и при этом выделяется вся подсеть для Служба приложений. Дополнительные сведения см. в статье "Интеграция приложения с виртуальной сетью Azure".
Сведения о настройке Служба приложений см. в статье "Включение интеграции виртуальной сети" в службе приложение Azure. Убедитесь, что вы помещаете его в подсеть, назначенную для исходящего трафика.
Рекомендации по DNS
В рамках использования частных конечных точек включите разрешение доменных имен ресурсов DNS для новых частных IP-адресов. Инструкции по реализации этой функции можно использовать различными способами в конфигурации DNS частной конечной точки.
Примечание.
Разрешение DNS должно применяться ко всему трафику. Ресурсы в той же виртуальной сети не смогут разрешаться, если они не используют правильные зоны DNS.
Шаг 6. Безопасный доступ к виртуальной сети и приложению
Защита доступа к виртуальной сети и приложениям включает:
- Защита трафика в среде Azure в приложении
- Использование многофакторной проверки подлинности (MFA) и политик условного доступа для доступа пользователей к приложениям.
На следующей схеме показаны оба режима доступа в эталонной архитектуре.
Безопасный трафик в среде Azure для виртуальной сети и приложения
Большая часть работы трафика безопасности в среде Azure уже завершена. Сведения о настройке безопасных подключений между ресурсами хранилища и виртуальными машинами см. в статье "Применение принципов нулевого доверия к хранилищу Azure".
Ознакомьтесь с принципами применения нулевого доверия к виртуальной сети концентратора в Azure, чтобы защитить доступ от центральных ресурсов к виртуальной сети.
Использование политик MFA и условного доступа для доступа пользователей к приложениям
Принципы применения нулевого доверия к виртуальным машинам рекомендуют защитить запросы доступа непосредственно к виртуальным машинам с помощью MFA и условного доступа. Эти запросы, скорее всего, от администраторов и разработчиков. Следующим шагом является защита доступа к приложениям с помощью MFA и условного доступа. Это относится ко всем пользователям, которые обращаются к приложению.
Во-первых, если приложение еще не интегрировано с идентификатором Microsoft Entra, см. типы приложений для платформа удостоверений Майкрософт.
Затем добавьте приложение в область политик доступа к удостоверениям и устройствам.
При настройке MFA с условным доступом и связанными политиками используйте рекомендуемый набор политик для нулевого доверия в качестве руководства. К ним относятся политики начальной точки , которые не требуют управления устройствами. В идеале устройства, обращающиеся к виртуальным машинам, управляются, и вы можете реализовать корпоративный уровень, который рекомендуется для нулевого доверия. Дополнительные сведения см. в разделе "Общие политики удостоверений нулевого доверия" и политик доступа к устройствам.
На следующей схеме показаны рекомендуемые политики для нулевого доверия.
Шаг 7. Включение расширенного обнаружения угроз и защиты
Виртуальная сеть, созданная в Azure, может быть защищена Microsoft Defender для облака так как другие ресурсы из ИТ-среды, работающей в Azure или локальной среде, также могут быть защищены.
Как упоминание в других статьях из этой серии, Defender для облака — это средство управления posture Cloud Security (CSPM) и Cloud Workload Protection (CWP), которое предлагает рекомендации по безопасности, оповещения и расширенные функции, такие как адаптивная защита сети, чтобы помочь вам в процессе разработки облачной безопасности.
В этой статье подробно не описывается Defender для облака, но важно понимать, что Defender для облака работает на основе политик и журналов Azure, входящих в рабочую область Log Analytics. После включения подписок с периферийной виртуальной сетью и связанными ресурсами вы увидите рекомендации по улучшению их состояния безопасности. Эти рекомендации можно отфильтровать дальше по тактике MITRE, группе ресурсов и другим пользователям. Рассмотрите возможность приоритета для решения рекомендаций, которые оказывают большее влияние на оценку безопасности вашей организации. Рассмотрим пример.
Существуют Defender для облака планы, которые обеспечивают расширенную защиту рабочих нагрузок, включающую рекомендации по адаптивной защите сети для улучшения существующих правил группы безопасности сети. Рассмотрим пример.
Вы можете принять рекомендацию, нажав кнопку "Применить", которая создаст новое правило группы безопасности сети или изменит существующий.
Рекомендуемое обучение
- Защита ресурсов Azure с помощью управления доступом на основе ролей Azure (Azure RBAC)
- Настройка Azure Monitor и управление ими
- Настройка групп безопасности сети
- Проектирование и реализация сетевой безопасности
- Проектирование и реализация частного доступа к службам Azure
Next Steps
Дополнительные статьи о применении принципов нулевого доверия к Azure см. в следующих статьях:
- Для Azure IaaS:
- Виртуальный рабочий стол Azure
- Виртуальная глобальная сеть Azure
- Приложения IaaS в Amazon Web Services
- Microsoft Sentinel и XDR в Microsoft Defender
Ссылки
- Профилактический подход к безопасности на основе модели "Никому не доверяй"
- Защита сетей с помощью модели "Никому не доверяй"
- Сеть для веб-приложений с Брандмауэром Azure и Шлюзом приложений, действующая по принципу “Никому не доверяй”
- Политики целевой зоны Azure
- Общее удостоверение нулевого доверия и устройство между политиками
- Что собой представляет частная конечная точка?
- Конфигурация DNS частной конечной точки
- Интеграция приложения с виртуальной сетью Azure
- Использование частных конечных точек для приложений Служба приложений
- Подключение на сервер SQL Azure с помощью частной конечной точки Azure
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по