Защита Функций Azure
Планирование безопасной разработки, развертывания и работы бессерверных функций во многом выполняется практически так же, как и для размещенных облачных и веб-приложений. Служба приложений Azure предоставляет инфраструктуру размещения для приложений-функций. В этой статье приводятся стратегии обеспечения безопасности для выполнения кода функций и сведения о том, как Служба приложений может помочь в их защите.
Компоненты платформы службы приложений, включая виртуальные машины Azure, хранилище, сетевые подключения, веб-платформы, функции управления и интеграции, надежно защищены. Служба приложений проходит непрерывные проверки соответствия требованиям, чтобы гарантировать следующее:
- Ресурсы вашего приложения защищены от ресурсов Azure других клиентов.
- Экземпляры виртуальной машины и программное обеспечение среды выполнения регулярно обновляются для обнаружения новых уязвимостей.
- Обмен секретными данными (например, строками подключения) между приложением и другими ресурсами Azure (например, базой данных SQL) остается в пределах Azure и не выходит за рамки сети. При сохранении секретные данные всегда шифруются.
- Все сообщения, передаваемые с помощью функций подключения службы приложений, например гибридного подключения, шифруются.
- Подключения к удаленным инструментам управления, например Azure PowerShell, Azure CLI, пакетам SDK Azure, интерфейсам API REST, шифруются.
- Круглосуточное предотвращение угроз позволяет защитить инфраструктуру и платформу от вредоносных программ, атак типа "отказ в обслуживании" (DDoS), атак типа "злоумышленник посередине" (MITM) и других угроз.
Дополнительные сведения о безопасности инфраструктуры и платформы см. в центре управления безопасностью Azure.
Набор рекомендаций по безопасности, которые соответствуют эталону безопасности Microsoft Cloud Security, см. в разделе "Базовые показатели безопасности Azure" для Функции Azure.
безопасная работа
В этом разделе рассказывается о том, как максимально безопасно настроить и запустить приложение-функцию.
Defender для облака
Defender для облака интегрируется с приложением-функцией на портале. Он бесплатно предоставляет быструю оценку возможных уязвимостей в конфигурации. За отдельную плату для приложений-функций, выполняющихся в выделенном плане, можно также использовать дополнительные возможности защиты Defender для облака. Дополнительные сведения см. в статье Защита веб-приложений и API Службы приложений Azure.
Ведение журнала и мониторинг
Один из способов обнаружения атак — постоянный мониторинг действий и анализ журналов. Функции интегрируются с приложением Аналитика для сбора данных журнала, производительности и ошибок для приложения-функции. Application Insights автоматически обнаруживает аномалии в производительности и содержит мощные аналитические средства, которые помогают диагностировать проблемы и анализировать использование функций. Дополнительные сведения см. в статье Мониторинг Функций Azure.
Функции также интегрируются с журналами Azure Monitor, что позволяет консолидировать журналы приложений-функций с системными событиями для упрощения анализа. С помощью параметров диагностики можно настроить для ваших функций потоковый экспорт журналов и метрик платформы в выбранное место назначения, например в рабочую область Logs Analytics. Дополнительные сведения см. в статье Мониторинг Функций Azure с помощью журналов Azure Monitor.
Для обнаружения угроз и автоматизации реагирования на уровне предприятия можно выполнить потоковую передачу журналов и событий в рабочую область Logs Analytics. Затем к этой рабочей области можно подключить Azure Sentinel. Дополнительные сведения см. в статье Что собой представляет Azure Sentinel.
Дополнительные рекомендации по безопасности, связанные с обеспечением наблюдаемости, см. в статье Базовый план безопасности Azure для Функций Azure.
Требование использовать HTTPS
По умолчанию клиенты могут подключаться к конечным точкам функции по протоколу HTTP или HTTPS. Запросы HTTP необходимо перенаправлять на HTTPs, так как HTTPS использует протокол SSL/TLS для обеспечения безопасного подключения, которое в этом случае шифруется и требует прохождения проверки подлинности. Сведения о том, как это сделать, см. в разделе Принудительное использование HTTPS.
Если протокол HTTPS обязателен, необходимо также требовать, чтобы использовалась последняя версия TLS. Сведения о том, как это сделать, см. в разделе Принудительное применение версий TLS.
Дополнительные сведения см. в разделе о безопасных подключениях (TSL).
Ключи доступа к функции
Служба "Функции" позволяет использовать ключи, чтобы затруднить несанкционированный доступ к конечным точкам функции HTTP во время развертывания. Если уровень доступа HTTP для функции, активируемой HTTP, не имеет значение anonymous, запросы должны содержать ключ доступа API в этот запрос.
Хотя ключи предоставляют механизм безопасности по умолчанию, вы можете рассмотреть другие варианты для защиты конечной точки HTTP в рабочей среде. Например, не рекомендуется распространять общий секрет в общедоступных приложениях. Если ваша функция вызывается из общедоступного клиента, вы можете рассмотреть возможность реализации другого механизма безопасности. Дополнительные сведения см. в разделе Защита конечной точки HTTP в рабочей среде.
При обновлении значений функциональных ключей необходимо вручную повторно распространить обновленные значения ключей для всех клиентов, вызывающих вашу функцию.
Области авторизации (уровень функции)
Существуют две области доступа для ключей уровня функции.
Функция: эти ключи применяются только к определенным функциям, в которых они определены. Если такой ключ используется в качестве ключа API, он предоставляет доступ только к определенной функции.
Узел. Ключи с область узла можно использовать для доступа ко всем функциям в приложении-функции. Если такой ключ используется в качестве ключа API, он предоставляет доступ к любой функции в приложении-функции.
Каждый ключ называется ссылкой и имеется ключ по умолчанию (по умолчанию) на уровне функции и узла. Ключи функций имеют приоритет над ключами узла. Если определены два ключа с одним именем, всегда используется ключ функции.
Главный ключ (уровень администратора)
У каждого приложения-функции также есть ключ узла уровня администратора с именем _master. Кроме предоставления доступа на уровне узла ко всем функциям в приложении, главный ключ также предоставляет административный доступ к REST API среды выполнения. Этот ключ нельзя отменить. При задании уровня доступа admin запросы должны использовать главный ключ. Использование любого другого ключа приведет к ошибке доступа.
Внимание
Из-за повышенных разрешений в приложении-функции, предоставленном главным ключом, этот ключ не следует предоставлять третьим лицам или распространять его в собственных клиентских приложениях. Соблюдайте осторожность при выборе уровня доступа для администратора.
Системные ключи
Для доступа к конечным точкам веб-перехватчика для определенных расширений может потребоваться управляемый системой ключ. Системные ключи предназначены для конечных точек функций, которые вызываются внутренними компонентами. Например, для триггера Сетки событий требуется, чтобы при вызове его конечной точки в подписке использовался системный ключ. Устойчивые Функции также используют системные ключи для вызова API-интерфейсов расширений устойчивых задач.
Область системных ключей определяется расширением, но обычно применяется ко всему приложению-функции. Системные ключи могут создаваться только конкретными расширениями, и вы не можете явно задавать их значения. Как и в случае с другими ключами, новое значение такого ключа можно создать на портале или с помощью API-интерфейсов ключей.
Сравнение ключей
В следующей таблице сравниваются варианты использования различных типов ключей доступа.
| Действие | Область | Действительные клавиши |
|---|---|---|
| Выполнение функции | Конкретная функция | Function |
| Выполнение функции | Любая функция | Функция или узел |
| Вызов конечной точки администрирования | Приложение-функция | Узел (только основной) |
| Вызов API-интерфейсов расширений устойчивых задач | Приложение-функция1 | Система2 |
| Вызов веб-перехватчика для конкретного расширения (внутренний) | Приложение-функция1 | Система2 |
1Область определяется расширением.
2Конкретные имена задаются расширением.
Дополнительные сведения о ключах доступа см. в статье о привязке триггера HTTP.
Репозитории секретов
По умолчанию ключи хранятся в контейнере хранилища BLOB-объектов в учетной записи, указанной в параметре AzureWebJobsStorage. Вы можете использовать параметр AzureWebJobsSecretStorageType, чтобы переопределить эту реакцию на событие и сохранить ключи в другом расположении.
| Расположение | Значение | Описание |
|---|---|---|
| Вторая учетная запись хранения | blob |
Сохраняет ключи в хранилище BLOB-объектов другой учетной записи хранения с привязкой к URL-адресу SAS в AzureWebJobsSecretStorageSas. |
| Файловая система | files |
Ключи сохраняются в файловой системе, которая используется по умолчанию в функциях версии v1.x. |
| Azure Key Vault | keyvault |
Хранилище ключей, заданное в AzureWebJobsSecretStorageKeyVaultUri, используется для хранения ключей. |
| Секреты Kubernetes | kubernetes |
Набор ресурсов в AzureWebJobsKubernetesSecretName используется для хранения ключей. Поддерживается только при запуске среды выполнения Функций в Kubernetes. Набор инструментов Azure Functions Core Tools автоматически создает значения при развертывании в Kubernetes. |
При использовании Key Vault для хранилища ключей необходимые параметры приложения зависят от типа управляемого удостоверения. Среда выполнения функций версии 3.x поддерживает только управляемые удостоверения, назначаемые системой.
| Имя настройки | Назначаемое системой | Назначаемое пользователем | Регистрация приложения |
|---|---|---|---|
| AzureWebJobsSecretStorageKeyVaultUri | ✓ | ✓ | ✓ |
| AzureWebJobsSecretStorageKeyVaultClientId | X | ✓ | ✓ |
| AzureWebJobsSecretStorageKeyVaultClientSecret | X | X | ✓ |
| AzureWebJobsSecretStorageKeyVaultTenantId | X | X | ✓ |
Проверка подлинности и авторизация
Хотя ключи функций могут в определенной мере ограничить нежелательный доступ, единственный способ обеспечить полноценную защиту конечных точек функций — реализовать положительную проверку подлинности клиентов, у которых есть доступ к этим функциям. После этого решения об авторизации можно принимать на основе удостоверения.
Включение проверки подлинности и авторизация службы приложений
Платформа Служба приложений позволяет использовать идентификатор Microsoft Entra и несколько сторонних поставщиков удостоверений для проверки подлинности клиентов. Эта стратегия позволяет реализовать пользовательские правила авторизации для функций и работать с информацией пользователя из кода функции. Дополнительные сведения см. в разделе Работа с удостоверениями клиентов и статье Проверка подлинности и авторизация в службе приложений Azure.
Использование службы Управления API Azure (APIM) для проверки подлинности запросов
APIM предоставляет широкий набор параметров безопасности API для входящих запросов. Дополнительные сведения см. в статье о политиках аутентификации службы "Управление API". С помощью службы "Управление API" можно настроить приложение-функцию на прием запросов только с IP-адреса вашего экземпляра этой службы. Дополнительные сведения см. в разделе Ограничения IP-адресов.
Разрешения
Как и в случае любого другого приложения или службы, приложение-функцию следует по возможности запускать с минимальными разрешениями.
Разрешения на управление пользователями
Функции поддерживают встроенное управление доступом на основе ролей Azure (Azure RBAC). К поддерживаемым Функциями ролям Azure относятся Участник, Владелец и Читатель.
Разрешения действуют на уровне приложения-функции. Для выполнения большинства задач на уровне приложения необходима роль участника. Вам также потребуется роль участника вместе с разрешением читателя мониторинга, чтобы иметь возможность просматривать данные журнала в Application Insights. Удалить приложение-функцию можно только с ролью владельца.
Упорядочивание функций по привилегиям
Строки подключения и другие учетные данные, хранящиеся в параметрах приложения, предоставляют всем функциям в приложении-функции одинаковый набор разрешений в связанном ресурсе. Рекомендуется свести к минимуму количество функций с доступом к определенным учетным данным, переместив те из них, которые не используют такие учетные данные, в отдельное приложение-функцию. Для передачи данных между функциями в различных приложениях-функциях всегда можно использовать такие методы, как связывание функций.
Управляемые удостоверения
Управляемое удостоверение из идентификатора Microsoft Entra позволяет приложению легко получить доступ к другим защищенным ресурсам Microsoft Entra, таким как Azure Key Vault. Удостоверения управляются платформой Azure, и для них не нужно подготавливать или изменять секреты. Дополнительные сведения об управляемых удостоверениях в идентификаторе Microsoft Entra см. в разделе "Управляемые удостоверения" для ресурсов Azure.
Приложению можно предоставить два типа удостоверений:
- Назначаемое системой удостоверение привязывается к приложению и удаляется при удалении приложения. Приложение может иметь только одно назначаемое системой удостоверение.
- Назначаемое пользователем удостоверение — это изолированный ресурс Azure, который можно назначить приложению. Приложение может иметь несколько назначаемых пользователем удостоверений.
Управляемые удостоверения можно использовать вместо секретов для подключений из некоторых триггеров и привязок. См. раздел Подключения на основе удостоверений.
Дополнительные сведения см. в статье Использование управляемых удостоверений в Службе приложений и Функциях Azure.
Ограничение доступа CORS
Общий доступ к ресурсам независимо от источника (CORS) позволяет разрешить веб-приложениям, запущенным в другом домене, отправлять запросы конечным точкам вашего триггера HTTP. Служба приложений предоставляет встроенную поддержку передачи требуемых заголовков CORS в HTTP-запросах. Правила CORS определяются на уровне приложения-функции.
Несмотря на все удобство использования подстановочных знаков, которые позволяют всем сайтам получать доступ к конечной точке, такой подход сводит на нет преимущества технологии CORS, цель которой — предотвратить атаки с использованием межсайтовых сценариев. Вместо этого добавьте отдельную запись CORS для домена каждого веб-приложения, у которого должен быть доступ к конечной точке.
управление секретами;
Чтобы иметь возможность подключаться к различным службам и ресурсам, необходимым для выполнения кода, приложениям-функциям требуется доступ к секретам, например строкам подключения и ключам служб. В этом разделе описывается хранение необходимых для функций секретов.
Никогда не храните секреты в коде функции.
Параметры приложения
По умолчанию строки подключения и секреты, используемые приложением-функцией и привязками, хранятся в виде параметров приложения. Это делает такие учетные данные доступными как для кода функции, так и для различных привязок, которые она использует. Для получения фактического значения, которое является секретом, используется имя параметра приложения (ключа).
Например, для каждого приложения-функции требуется связанная учетная запись хранения, которая используется средой выполнения. По умолчанию данные о подключении к этой учетной записи хранения хранятся в параметре приложения с именем AzureWebJobsStorage.
Параметры приложения и строки подключения хранятся в зашифрованном виде в Azure. Они расшифровываются только перед внедрением в память процесса приложения при запуске приложения. Ключи шифрования регулярно меняются. Если вы предпочитаете организовать безопасное хранение секретов, параметр приложения вместо этого должен ссылаться на Azure Key Vault.
При разработке функций на локальном компьютере можно также зашифровать параметры по умолчанию в файле local.settings.json. Дополнительные сведения см. в разделе "Шифрование локального файла параметров".
Ссылки на Key Vault
Хотя параметров приложения достаточно для большинства функций, иногда одни и те же секреты требуется совместно использовать в нескольких службах. В этом случае избыточное хранение секретов приводит к появлению дополнительных потенциальных уязвимостей. Более безопасный подход — использовать централизованную службу хранения секретов и ссылаться на нее, а не на сами секреты.
Служба Azure Key Vault обеспечивает централизованное управление секретами и полный контроль над политиками доступа и журналами аудита. Ссылку на Key Vault можно использовать вместо строки подключения или ключа в параметрах приложения. Дополнительные сведения см. в статье Использование ссылок на Key Vault в Службе приложений и Функциях Azure.
Подключения на основе удостоверений
Удостоверения могут использоваться вместо секретов для подключения к некоторым ресурсам. Преимущество данного метода состоит в том, что он не требует управления секретом и обеспечивает более детализированное управление доступом и аудит.
При написании кода, создающего подключение к службам Azure, поддерживающим проверку подлинности Microsoft Entra, можно использовать удостоверение вместо секрета или строка подключения. Сведения об обоих методах подключения приведены в документации по каждой службе.
Некоторые расширения триггеров и привязок Функций Azure можно настроить для подключения с помощью удостоверений. В настоящее время это относится к расширениям больших двоичных объектов Azure и очередей Azure. Сведения о том, как настроить эти расширения для использования удостоверения, см. в разделе Настройка подключения на основе удостоверений.
Настройка квот на использование
Рекомендуем установить квоты на использование для функций, выполняемых в плане потребления. Если установить суточное ограничение на объем данных за единицу времени (ГБ/с) для выполнения всех функций в целом в приложении-функции, выполнение останавливается по достижении предельного значения. Это потенциально может помочь предотвратить выполнение функций вредоносным кодом. Сведения о том, как оценить потребление функций, см. в статье Оценка затрат на план потребления.
Проверка данных
Триггеры и привязки, используемые вашими функциями, не предоставляют дополнительную проверку данных. Код должен проверять любые данные, полученные от триггера или входной привязки. На случай компрометации вышестоящей службы следует позаботиться о том, чтобы через функцию не проходили непроверенные входящие данные. Например, если функция хранит данные из очереди службы хранилища Azure в реляционной базе данных, необходимо проверить данные и параметризовать команды, чтобы избежать атак путем внедрения кода SQL.
Не следует рассчитывать на то, что данные, поступающие в функцию, уже проверены или очищены. Кроме того, рекомендуется проверять допустимость данных, записываемых в выходные привязки.
Обработка ошибок
Хотя это и очевидно, не лишним будет напомнить о важности хорошей обработки ошибок в функциях. Необработанные ошибки всплывают на узле и обрабатываются средой выполнения. Различные привязки выполняют обработку ошибок по-разному. Дополнительные сведения см. в статье Обработка ошибок в решении "Функции Azure".
Отключение удаленной отладки
Убедитесь, что удаленная отладка отключена все время, за исключением периода активной отладки функций. Вы можете отключить удаленную отладку на портале в разделе Конфигурация приложения-функции на вкладке Общие параметры.
Ограничение доступа CORS
Функции Azure поддерживают общий доступ к ресурсам независимо от источника (CORS). CORS настраивается на портале и через Azure CLI. Список разрешенных источников CORS применяется на уровне приложения-функции. При включении CORS ответы включают заголовок Access-Control-Allow-Origin. Дополнительные сведения см. в статье об общем доступе к ресурсам независимо от источника.
Не используйте подстановочные знаки в списке разрешенных источников. Вместо этого следует перечислить конкретные домены, из которых предполагается получать запросы.
Хранение данных в зашифрованном виде
Служба хранилища Azure шифрует все данные в неактивных учетных записях хранения. Дополнительные сведения см. в статье Шифрование службы хранилища Azure для неактивных данных.
По умолчанию данные шифруются с помощью ключей, управляемых Майкрософт. Для дополнительного управления ключами шифрования можно предоставить ключи, управляемые клиентом, чтобы зашифровать большие двоичные объекты и данные файлов. Эти ключи должны присутствовать в Azure Key Vault, чтобы Функции Azure могли получить доступ к учетной записи хранения. Дополнительные сведения см. в разделе Шифрование неактивных данных с помощью управляемых клиентом ключей.
Безопасные связанные ресурсы
Приложение-функция часто зависит от дополнительных ресурсов, поэтому часть защиты приложения обеспечивает защиту этих внешних ресурсов. Как минимум, большинство приложений-функций включают зависимость от приложений Аналитика и служба хранилища Azure. Ознакомьтесь с базовыми показателями безопасности Azure для Azure Monitor и базовыми показателями безопасности Azure для служба хранилища для получения рекомендаций по защите этих ресурсов.
Внимание
Учетная запись хранения используется для хранения важных данных приложения, иногда включая сам код приложения. Необходимо ограничить доступ от других приложений и пользователей к учетной записи хранения.
Вы также должны ознакомиться с рекомендациями по любым типам ресурсов, от которой зависит логика приложения, как от триггеров, так и от привязок и кода функции.
Безопасное развертывание
С помощью набора средств решения "Функции Azure" можно легко опубликовать код проекта локальной функции в Azure. При учете вопросов безопасности в топологии Функций Azure важно понимать, как работает развертывание.
Учетные данные развертывания
Для развертываний Службы приложений требуется набор учетных данных развертывания. Эти учетные данные развертывания используются для защиты развертываний приложения-функции. Учетными данными развертывания управляет платформа Службы приложений. Когда они неактивны, то хранятся в зашифрованном виде.
Существует два вида учетных данных развертывания.
Учетные данные на уровне пользователя. Это единый набор учетных данных для всей учетной записи Azure. С его помощью можно развернуть службу приложений для любого приложения и в любой подписке, на доступ к которой у этой учетной записи Azure есть права. Именно это значение по умолчанию отображается на портале графического пользовательского интерфейса (например, в разделах Обзор и Свойства на странице ресурсов приложения). Если пользователь получает доступ к приложению с помощью управления доступом на основе ролей (RBAC) или назначения прав соадминистратора, пользователь может использовать свои собственные учетные данные на уровне пользователя, пока доступ не будет отозван. Не используйте эти учетные данные совместно с другими пользователями Azure.
Учетные данные на уровне приложения. Это единый набор учетных данных для каждого приложения. С его помощью можно развернуть только одно приложение. Учетные данные для каждого приложения автоматически формируются при создании приложения. Их нельзя настроить вручную, но можно сбросить в любое время. Чтобы получить доступ к учетным данным на уровне приложения с помощью RBAC, у пользователя в приложении должна быть роль участника или роль более высокого уровня (включая встроенную роль "Участник веб-сайтов"). У читателей нет прав на публикацию и доступа к этим учетным данным.
В настоящее время Key Vault не поддерживается для учетных данных развертывания. Дополнительные сведения об управлении учетными данными развертывания см. в статье Настройка учетных данных развертывания Службы приложений Azure.
Отключение FTP
По умолчанию для каждого приложения-функции включена конечная точка FTP. Доступ к конечной точке FTP осуществляется с помощью учетных данных развертывания.
При этом использовать FTP для развертывания кода функции не рекомендуется. Развертывания через FTP выполняются вручную, и для них требуется синхронизация триггеров. Дополнительные сведения см. в разделе о развертывании по FTP.
Если вы не планируете использовать протокол FTP, следует отключить его на портале. Если вы решите использовать FTP, следует принудительно применять FTPS.
Защита конечной точки scm
У каждого приложения-функции есть соответствующая конечная точка службы scm, которая используется в службе дополнительных инструментов (Kudu) для развертываний и других расширений сайта Службы приложений. Конечная точка scm для приложения-функции всегда является URL-адресом в форме https://<FUNCTION_APP_NAME.scm.azurewebsites.net>. При использовании сетевой изоляции для защиты функций необходимо также учитывать эту конечную точку.
Используя отдельную конечную точку scm, вы можете управлять развертываниями и другими функциями дополнительных инструментов для приложения-функции, которые изолированы или запущены в виртуальной сети. Конечная точка scm поддерживает как обычную проверку подлинности (с использованием учетных данных развертывания), так и единый вход с использованием учетных данных портала Azure. Дополнительные сведения см. в статье о доступе к службе Kudu.
Непрерывная проверка безопасности
Так как безопасность должна рассматриваться на каждом шаге процесса разработки, необходимо также реализовать проверки безопасности в среде непрерывного развертывания. Иногда этот способ называется DevSecOps. Использование Azure DevOps для конвейера развертывания позволяет интегрировать проверку в процесс развертывания. Дополнительные сведения см. в статье о том, как добавить непрерывную проверку безопасности в конвейер CI/CD.
Безопасность сети
Ограничение сетевого доступа к приложению-функции позволяет контролировать доступ пользователей к конечным точкам функций. Решение "Функции" использует инфраструктуру Службы приложений, чтобы предоставить функциям доступ к ресурсам без использования адресов, маршрутизируемых через Интернет, или ограничения доступа через Интернет к конечной точке функции. Дополнительные сведения об этих сетевых параметрах см. в статье Параметры сети для Функций Azure.
Настройка ограничений доступа
Ограничения доступа позволяют определять списки правил разрешения и запрета для управления трафиком приложения. Правила применяются в порядке приоритета. Если правила не определены, приложение будет принимать трафик с любого адреса. Дополнительные сведения см. в статье Ограничения доступа для Службы приложений Azure.
Защита учетной записи хранения
Когда вы создаете приложения-функции, необходимо создать или привязать учетную запись хранения Azure общего назначения, поддерживающую хранилища BLOB-объектов, очередей и таблиц. Эту учетную запись хранения можно изменить на ту, которая защищена конечными точками службы или частной конечной точкой. Дополнительные сведения см. в разделе Ограничьте учетную запись хранения виртуальной сети.
доступ к частным сайтам;
Частная конечная точка Azure — это сетевой интерфейс, который обеспечивает безопасное подключение к службе с помощью Приватного канала Azure. Частная конечная точка использует частный IP-адрес из виртуальной сети, эффективно предоставляя доступ к службе из виртуальной сети.
Вы можете использовать частные конечные точки для функций, размещенных в планах Службы приложений и Premium.
Если вы хотите выполнять вызовы к частным конечным точкам, необходимо убедиться, что поиск в DNS разрешается в частную конечную точку. Можно принудительно применить это поведение одним из следующих способов.
- Настроить интеграцию с частными зонами Azure DNS. Если в виртуальной сети нет настраиваемого DNS-сервера, это выполняется автоматически.
- Управлением частной конечной точкой на DNS-сервере, используемом приложением. Для этого необходимо узнать адрес частной конечной точки, а затем указать конечную точку, к которой вы пытаетесь связаться по этому адресу, ч помощью записи типа A.
- Настройка собственного DNS-сервера для перенаправления в частные зоны Azure DNS.
Дополнительные сведения см. в статье Использование частных конечных точек для веб-приложений.
Развертывание приложения-функции в изолированной среде
Среда службы приложений Azure (ASE) предоставляет выделенную среду размещения, в которой можно выполнять функции. ASE позволяет настроить один интерфейсный шлюз, который можно использовать для аутентификации всех входящих запросов. Дополнительные сведения см. в статье Настройка брандмауэра веб-приложения (WAF) для среды службы приложений.
Использование службы шлюза
Службы шлюза, например Шлюз приложений Azure и Azure Front Door, позволяют настроить брандмауэр веб-приложения (WAF). Правила WAF используются для отслеживания или блокирования обнаруженных атак, что обеспечивает дополнительный уровень защиты функций. Чтобы настроить WAF, приложение-функция должно выполняться в ASE или использовать частные конечные точки (предварительная версия). Дополнительные сведения см. в статье Использование частных конечных точек.