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

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

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

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

  • Ресурсы приложения защищены от ресурсов Azure других клиентов.
  • Экземпляры виртуальной машины и программное обеспечение среды выполнения регулярно обновляются для обнаружения новых уязвимостей.
  • Обмен секретами (например, строками подключения) между приложением и другими ресурсами Azure (например , базой данных SQL Azure) остается в Azure и не пересекает границы сети. При сохранении секретные данные всегда шифруются.
  • Все сообщения, передаваемые с помощью функций подключения службы приложений, например гибридного подключения, шифруются.
  • Подключения с такими средствами удаленного управления, как Azure PowerShell, Azure CLI, пакеты SDK Azure и REST API, шифруются.
  • 24-часовое управление угрозами защищает инфраструктуру и платформу от вредоносных программ, распределенных атак типа "отказ в обслуживании" (DDoS), "злоумышленник в середине" и других угроз.

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

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

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

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

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 не задан anonymousуровень доступа HTTP, запросы должны включать ключ доступа в запрос. Дополнительные сведения см. в статье "Работа с ключами доступа" в Функции Azure.

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

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

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

Приложения-функции могут обслуживать административные конечные точки в маршруте /admin , который можно использовать для операций, таких как получение сведений о состоянии узла и выполнение тестовых вызовов. Когда доступ открыт, запросы к этим конечным точкам должны включать главный ключ приложения. Административные операции также доступны через Microsoft.Web/sites Azure Resource Manager, который предлагает Azure RBAC. Отключить конечные /admin точки можно, задав значение functionsRuntimeAdminIsolationEnabled для свойства сайта true. Это свойство нельзя задать для приложений, работающих в конфигурации Linux Consumption SKU, и его нельзя задать для приложений, работающих на версии 1.x функций Azure. Если вы используете версию 1.x, сначала необходимо перейти на версию 4.x.

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

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

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

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

Разрешения

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

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

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

Разрешения действуют на уровне приложения-функции. Для выполнения большинства задач на уровне приложения необходима роль контрибьютора. Вам также потребуется роль Contributor вместе с разрешением Monitoring Reader для просмотра журнальных данных в 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 Functions можно настроить для доступа к службам с помощью соединений на основе идентификации. Дополнительные сведения см. в разделе «Настройка подключения на основе идентификационных данных».

Настройка квот на использование

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

Проверка данных

Триггеры и привязки, используемые вашими функциями, не обеспечивают дополнительную проверку данных. Код должен проверять любые данные, полученные от триггера или входной привязки. На случай компрометации вышестоящей службы следует позаботиться о том, чтобы через функцию не проходили непроверенные входящие данные. Например, если функция хранит данные из очереди службы хранилища 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. Эти учетные данные можно использовать для развертывания в Службе приложений для любого приложения в любой подписке, к которым у учетной записи Azure есть разрешение на доступ. Этот набор учетных данных — это значение по умолчанию, которое отображается в графической среде портала, например в разделе "Обзор " и "Свойства " на панели ресурсов приложения. Если пользователю предоставлен доступ к приложению с помощью управления доступом на основе ролей (RBAC) или разрешения соадминистратора, они могут использовать свои учетные данные на уровне пользователя, пока не будет отменен доступ. Не делитесь этими учетными данными с другими пользователями 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 или использовать частные конечные точки (предварительная версия). Дополнительные сведения см. в разделе "Использование частных конечных точек".

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