Поделиться через

Защита Функций 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 для сбора данных журнала, производительности и ошибок для приложения-функции. Application Insights автоматически обнаруживает аномалии в производительности и содержит мощные аналитические средства, которые помогают диагностировать проблемы и анализировать использование функций. Дополнительные сведения см. в статье Мониторинг Функций Azure.

Функции также интегрируются с журналами Azure Monitor, что позволяет консолидировать журналы приложений-функций с системными событиями для упрощения анализа. С помощью параметров диагностики можно настроить для ваших функций потоковый экспорт журналов и метрик платформы в выбранное место назначения, например в рабочую область Logs Analytics. Дополнительные сведения см. в статье Мониторинг Функций Azure с помощью журналов Azure Monitor.

Для обнаружения угроз и автоматизации реагирования на уровне предприятия можно выполнить потоковую передачу журналов и событий в рабочую область Logs Analytics. Затем к этой рабочей области можно подключить Azure Sentinel. Дополнительные сведения см. в статье Что собой представляет Azure Sentinel.

Дополнительные рекомендации по безопасности, связанные с обеспечением наблюдаемости, см. в статье Базовый план безопасности Azure для Функций Azure.

Защита конечных точек HTTP

Конечные точки HTTP, предоставляемые публично, предоставляют вектор атаки для вредоносных субъектов. При защите конечных точек HTTP следует использовать многоуровневый подход к безопасности. Эти методы можно использовать для уменьшения уязвимости общедоступных конечных точек HTTP, упорядоченных от большинства основных до наиболее безопасных и строгих:

Требование использовать HTTPS

По умолчанию клиенты могут подключаться к конечным точкам функции по протоколу HTTP или HTTPS. Запросы HTTP необходимо перенаправлять на HTTPs, так как HTTPS использует протокол SSL/TLS для обеспечения безопасного подключения, которое в этом случае шифруется и требует прохождения проверки подлинности. Сведения о том, как это сделать, см. в разделе Принудительное использование HTTPS.

Если требуется протокол HTTPS, необходимо также требовать последнюю версию TLS. Сведения о том, как это сделать, см. в разделе Принудительное применение версий TLS.

Дополнительные сведения см. в разделе о безопасных подключениях (TSL).

Ключи доступа к функции

Функции позволяют использовать ключи, чтобы упростить доступ к конечным точкам функции. Если для триггерной функции HTTP не задан anonymousуровень доступа HTTP, запросы должны включать ключ доступа в запрос. Дополнительные сведения см. в статье "Работа с ключами доступа" в Функции Azure.

Хотя ключи доступа могут обеспечить некоторые способы предотвращения нежелательного доступа, единственным способом действительно защитить конечные точки функций является реализация положительной проверки подлинности клиентов, обращаюющихся к вашим функциям. После этого решения об авторизации можно принимать на основе удостоверения.

Для обеспечения высокого уровня безопасности можно также защитить всю архитектуру приложения внутри виртуальной сети с помощью частных конечных точек или выполнения в изоляции.

Включение проверки подлинности и авторизация службы приложений

Платформа Служба приложений позволяет использовать идентификатор 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, таким как два приложения Служба приложений.

Управляемые удостоверения можно использовать вместо секретов для подключений из некоторых триггеров и привязок. См. раздел Подключения на основе удостоверений.

Дополнительные сведения см. в статье Использование управляемых удостоверений в Службе приложений и Функциях 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 в реляционной базе данных, необходимо проверить данные и параметризовать команды, чтобы избежать атак путем внедрения кода SQL.

Не следует рассчитывать на то, что данные, поступающие в функцию, уже проверены или очищены. Кроме того, рекомендуется проверять допустимость данных, записываемых в выходные привязки.

Обработка ошибок

Хотя это и очевидно, не лишним будет напомнить о важности хорошей обработки ошибок в функциях. Необработанные ошибки всплывают на узле и обрабатываются средой выполнения. Различные привязки выполняют обработку ошибок по-разному. Дополнительные сведения см. в статье Обработка ошибок в решении "Функции Azure".

Отключение удаленной отладки

Убедитесь, что удаленная отладка отключена все время, за исключением периода активной отладки функций. Вы можете отключить удаленную отладку на портале в разделе Конфигурация приложения-функции на вкладке Общие параметры.

Ограничение доступа CORS

Функции Azure поддерживают общий доступ к ресурсам независимо от источника (CORS). CORS настраивается на портале и через Azure CLI. Список разрешенных источников CORS применяется на уровне приложения-функции. При включении CORS ответы включают заголовок Access-Control-Allow-Origin. Дополнительные сведения см. в статье об общем доступе к ресурсам независимо от источника.

Не используйте подстановочные знаки в списке разрешенных источников. Вместо этого следует перечислить конкретные домены, из которых предполагается получать запросы.

Хранение данных в зашифрованном виде

Служба хранилища Azure шифрует все данные в неактивных учетных записях хранения. Дополнительные сведения см. в статье Шифрование службы хранилища Azure для неактивных данных.

По умолчанию данные шифруются с помощью ключей, управляемых Майкрософт. Для дополнительного управления ключами шифрования можно предоставить ключи, управляемые клиентом, чтобы зашифровать большие двоичные объекты и данные файлов. Эти ключи должны присутствовать в Azure Key Vault, чтобы Функции Azure могли получить доступ к учетной записи хранения. Дополнительные сведения см. в разделе Шифрование неактивных данных с помощью управляемых клиентом ключей.

Приложение-функция часто зависит от дополнительных ресурсов, поэтому часть защиты приложения обеспечивает защиту этих внешних ресурсов. Как минимум, большинство приложений-функций включают зависимость от Application Insights и служба хранилища 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 service Environment предоставляет выделенную среду размещения, в которой выполняются функции. Эти среды позволяют настроить единый интерфейсный шлюз, который можно использовать для проверки подлинности всех входящих запросов. Дополнительные сведения см. в статье Настройка брандмауэра веб-приложения (WAF) для среды службы приложений.

Использование службы шлюза

Службы шлюза, например Шлюз приложений Azure и Azure Front Door, позволяют настроить брандмауэр веб-приложения (WAF). Правила WAF используются для отслеживания или блокирования обнаруженных атак, что обеспечивает дополнительный уровень защиты функций. Чтобы настроить WAF, приложение-функция должно выполняться в ASE или использовать частные конечные точки (предварительная версия). Дополнительные сведения см. в статье Использование частных конечных точек.

Следующие шаги