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

Защита Функций Azure

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

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

Дополнительные сведения о безопасности инфраструктуры и платформы в Azure см. в Центре управления безопасностью Azure.

Набор рекомендаций по безопасности, соответствующих эталону безопасности Microsoft Cloud Security Benchmark, смотрите в разделе "Базовые показатели безопасности для Azure Functions".

При планировании безопасной разработки, развертывания и эксплуатации бессерверных функций, процессы в значительной степени совпадают с теми, что применяются для любого веб-приложения или облачного приложения, но бессерверные приложения, скорее всего, уязвимы для различных типов традиционных атак. Дополнительные сведения о потенциальных атаках на бессерверную инфраструктуру см. в статье OWASP Top 10: Бессерверная интерпретация.

безопасная работа

В этом разделе рассказывается о том, как максимально безопасно настроить и запустить приложение-функцию.

Defender для облака

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

Ведение журнала и мониторинг

Один из способов обнаружения атак — постоянный мониторинг действий и анализ журналов. Функции интегрируются с Application Insights для сбора данных журнала, производительности и ошибок для функционального приложения. Application Insights автоматически обнаруживает аномалии производительности и включает мощные средства аналитики, помогающие диагностировать проблемы и понять, как используются функции. Дополнительные сведения см. в разделе Мониторинг функций Azure.

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

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

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

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

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

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

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

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

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

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

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

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

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

Отключите административные конечные точки

Приложения-функции могут обслуживать административные конечные точки по маршруту /admin. Эти конечные точки можно использовать для операций, таких как получение сведений о состоянии узла и выполнение тестовых вызовов. Когда доступ открыт, запросы к этим конечным точкам должны включать главный ключ приложения. Вы также можете получить доступ к административным операциям через API Azure Resource ManagerMicrosoft.Web/sites, который предлагает Azure RBAC. Чтобы отключить /admin конечные точки, установите свойству сайта functionsRuntimeAdminIsolationEnabled в вашем приложении значение true. Дополнительные сведения см. в ссылке по свойству functionsRuntimeAdminIsolationEnabled.

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

Платформа службы приложений позволяет использовать идентификатор Microsoft Entra и несколько поставщиков удостоверений, отличных от Майкрософт, для проверки подлинности клиентов. Используйте эту стратегию для реализации пользовательских правил авторизации для функций. Вы можете работать с данными пользователя из кода функции. Дополнительные сведения см. в статье "Проверка подлинности и авторизация" в Службе приложений Azure и работе с удостоверениями клиентов.

Использование службы Управления API Azure (APIM) для проверки подлинности запросов

APIM предоставляет различные параметры безопасности API для входящих запросов. Дополнительные сведения см. в политиках проверки подлинности службы "Управление API". С помощью APIM вы можете настроить приложение-функцию для приема запросов только из IP-адреса экземпляра APIM. Дополнительные сведения см. в разделе об ограничениях IP-адресов.

Разрешения

Как и в любом приложении или службе, запустите приложение-функцию с минимальными возможными разрешениями.

Разрешения на управление пользователями

Функции поддерживают встроенное управление доступом на основе ролей Azure (Azure RBAC). К поддерживаемым Функциями ролям Azure относятся Участник, Владелец и Читатель.

Разрешения вступают в силу на уровне приложения-функции. Для выполнения большинства задач на уровне приложения необходима роль контрибьютора. Вам также нужна роль участника вместе с разрешением читателя мониторинга для просмотра данных журнала в Application Insights. Удалить функциональное приложение может только пользователь с ролью владельца.

Упорядочивание функций по привилегиям

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

Управляемые идентичности

Управляемая идентификация от Microsoft Entra ID позволяет вашему приложению легко получить доступ к другим ресурсам, защищённым Microsoft Entra ID, например, Azure Key Vault. Платформа Azure управляет идентификацией, поэтому вам не нужно подготавливать или обновлять секреты. Дополнительные сведения об управляемых идентификаторах в Microsoft Entra ID см. в разделе Управляемые идентификаторы для ресурсов Azure.

Вы можете предоставить вашему приложению два типа идентификаций:

  • Удостоверение, назначаемое системой, привязано к приложению и удаляется при удалении приложения. Приложение может иметь только одну системно назначаемую идентичность.
  • назначенная пользователем идентичность является автономным ресурсом Azure, который можно назначить вашему приложению. Приложение может иметь несколько идентификаторов, назначаемых пользователями. Одно назначаемое пользователем удостоверение можно назначить нескольким ресурсам Azure, таким как два приложения App Service.

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

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

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

Приложение-функция часто зависит от других ресурсов, поэтому часть защиты приложения обеспечивает защиту этих внешних ресурсов. Как минимум, большинство приложений-функций имеют зависимость от Application Insights и Azure Storage. Рекомендации по защите этих ресурсов см. в базовом плане безопасности Azure для Azure Monitor и базовом плане безопасности Azure для службы хранилища.

Внимание

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

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

Безопасное развертывание

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

Учетные данные развертывания

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

Существует два вида учетных данных развертывания.

  • Учетные данные уровня пользователя или пользовательские учетные данные предоставляют один набор данных развертывания для всей учетной записи Azure пользователя. Пользователь, которому предоставлен доступ к приложению с помощью управления доступом на основе ролей (RBAC) или разрешения соадминистратора, может использовать свои учетные данные на уровне пользователя, если у них есть эти разрешения.

    Учетные данные области пользователя можно использовать для развертывания любого приложения в Службе приложений через локальный Git или FTP/S в любой подписке, к которой учетной записи Azure разрешен доступ. Вы не делитесь этими учетными данными с другими пользователями Azure. Вы можете сбросить учетные данные, определенные для пользователя, в любое время.

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

    Пользователь должен иметь по крайней мере разрешения на уровень участника приложения, включая встроенную роль участника веб-сайта , для предоставления доступа к учетным данным уровня приложения через RBAC. Роль читателя не может публиковать и не может получить доступ к этим учетным данным.

В настоящее время для учетных данных развертывания Key Vault не поддерживается. Дополнительные сведения об управлении учетными данными развертывания см. в статье Настройка учетных данных развертывания Службы приложений Azure.

Отключение FTP

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

При этом использовать FTP для развертывания кода функции не рекомендуется. Развертывания через FTP выполняются вручную, и для них требуется синхронизация триггеров. Дополнительные сведения см. в статье о развертывании FTP.

Если вы не используете FTP, сохраните его отключенным. Этот параметр можно изменить на портале. Если вы решите использовать FTP, примените FTPS.

Защита конечной scm точки

Каждое приложение-функция имеет соответствующую конечную scm точку службы, которую служба Advanced Tools (Kudu) использует для развертываний и других расширений сайта службы приложений. Конечная точка scm функционального приложения всегда имеет форму URL-адреса https://<FUNCTION_APP_NAME>.scm.azurewebsites.net. При использовании сетевой изоляции для защиты функций необходимо также учитывать эту конечную точку.

При использовании отдельной scm конечной точки вы можете управлять развертываниями и другими функциями расширенных средств для функциональных приложений, изолированных либо работающих в виртуальной сети. Конечная точка scm поддерживает обычную проверку подлинности (с помощью учетных данных развертывания) и единый вход с учетными данными вашей учетной записи в портале Azure. Дополнительные сведения см. в разделе "Доступ к службе Kudu".

Непрерывная проверка безопасности

Так как необходимо учитывать безопасность на каждом шаге процесса разработки, необходимо также реализовать проверки безопасности в среде непрерывного развертывания. Этот подход иногда называется DevSecOps. С помощью Azure DevOps для конвейера развертывания можно интегрировать проверку в процесс развертывания. Дополнительные сведения см. в статье "Защита Azure Pipelines".

Безопасность сети

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

Настройка ограничений доступа

Ограничения доступа позволяют определять списки разрешающих и запрещающих правил для управления трафиком вашего приложения. Правила применяются в порядке приоритета. Если вы не определяете какие-либо правила, приложение принимает трафик из любого адреса. Дополнительную информацию см. в разделе Ограничения доступа к службам Azure App Service.

Защита учетной записи хранения

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

Разверните ваше функциональное приложение в виртуальную сеть

Частная конечная точка Azure — это сетевой интерфейс, который обеспечивает безопасное подключение к службе с помощью Приватного канала Azure. Частная конечная точка использует частный IP-адрес из виртуальной сети, эффективно предоставляя доступ к службе из виртуальной сети.

Вы можете использовать частную конечную точку для функций, размещенных в планах Flex Consumption, Elastic Premium и Выделенной (службы приложений).

Если вы хотите выполнять вызовы к частным конечным точкам, необходимо убедиться, что поиск в DNS разрешается в частную конечную точку. Можно принудительно применить это поведение одним из следующих способов.

  • Настроить интеграцию с частными зонами Azure DNS. Если в виртуальной сети нет настраиваемого DNS-сервера, это выполняется автоматически.
  • Управляйте частной конечной точкой на DNS-сервере, используемом вашим приложением. Чтобы управлять частной конечной точкой, необходимо знать адрес конечной точки и использовать запись A для ссылки на конечную точку, которую вы пытаетесь достичь.
  • Настройка собственного DNS-сервера для перенаправления в частные зоны Azure DNS.

Дополнительные сведения см. в статье Использование частных конечных точек для веб-приложений.

Разверните ваше приложение-функцию в изолированной среде

Azure App Service Environment обеспечивает выделенную среду размещения, в которой выполняются ваши функции. Эти среды позволяют настроить единый интерфейсный шлюз, который можно использовать для проверки подлинности всех входящих запросов. Дополнительные сведения см. в статье "Интеграция среды службы приложений ILB" с шлюзом приложений Azure.

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

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

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

  • Last updated on