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


Что такое безопасность в Службе приложений Azure?

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

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

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

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

В следующих разделах показано, как дополнительно защитить приложение службы приложений от угроз.

HTTPS и сертификаты

Службу приложений можно использовать для защиты приложений через HTTPS. При создании приложения его доменное имя по умолчанию (<app_name>.azurewebsites.net) уже доступно с помощью HTTPS. Если вы настраиваете личный домен для приложения, вы также должны защитить его с помощью TLS/SSL-сертификата , чтобы клиентские браузеры могли сделать защищенные HTTPS-подключения к вашему пользовательскому домену.

Служба приложений поддерживает следующие типы сертификатов:

  • Управляемый сертификат службы бесплатных приложений
  • сертификат Службы приложений;
  • сторонний сертификат;
  • сертификат, импортированный из Azure Key Vault.

Чтобы узнать больше, ознакомьтесь с добавлением TLS/SSL-сертификата в Службу приложений Azure.

Незащищенные протоколы (HTTP, TLS 1.0, FTP)

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

TLS 1.0 больше не считается защищенным отраслевыми стандартами, такими как PCI DSS. Использование службы приложений для отключения устаревших протоколов путем применения TLS 1.1/TLS 1.2.

Служба приложений поддерживает протоколы FTP и FTPS для развертывания файлов. Чтобы повысить безопасность, используйте FTPS вместо FTP, если это возможно. Если один или оба из этих протоколов не используются, их следует отключить.

Ограничения статических IP-адресов

По умолчанию приложение службы приложений принимает запросы со всех IP-адресов из Интернета, но вы можете ограничить доступ небольшим подмножеством IP-адресов. Службу приложений в Windows можно использовать для определения списка IP-адресов, которым разрешен доступ к приложению. Список разрешенных адресов может включать отдельные IP-адреса или диапазон IP-адресов, определенных маской подсети. Дополнительные сведения см. в статье об ограничениях статических IP-адресов службы приложений Azure.

Для службы приложений в Windows можно также динамически ограничить IP-адреса, настроив web.config файл. Дополнительные сведения см. в разделе Dynamic IP Security <dynamicIpSecurity>.

Аутентификация и авторизация клиента

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

Служба приложений поддерживает аутентификацию и авторизацию через несколько поставщиков проверки подлинности, включая Microsoft Entra ID, учетные записи Microsoft, Facebook, Google и X. Дополнительные сведения см. в разделе «Проверка подлинности и авторизация в службе приложений Azure».

Аутентификация между службами

При проверке подлинности в серверной службе служба приложений предоставляет два механизма в зависимости от необходимости:

Подключение к удаленным ресурсам

Возможно, приложению потребуется получить доступ к трем типам удаленных ресурсов:

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

Ресурсы Azure

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

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

Ресурсы в виртуальной сети Azure

Приложение может получить доступ к ресурсам в виртуальной сети Azure через интеграцию виртуальной сети. Интеграция устанавливается с виртуальной сетью с помощью VPN типа "точка — сеть". Затем приложение может получить доступ к ресурсам в виртуальной сети с помощью частных IP-адресов. Тем не менее подключение "точка — сеть" все еще проходит через общие сети в Azure.

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

Локальные ресурсы

Есть три способа безопасного получения доступа к локальным ресурсам, таким как базы данных.

  • Гибридное подключение: используйте гибридное подключение, чтобы установить подключение типа "точка — точка" к удаленному ресурсу через TCP-туннель. Туннель TCP устанавливается с использованием TLS 1.2 и ключей с общей подписью доступа.
  • Интеграция виртуальной сети с VPN типа "сеть — сеть": как описано в разделе "Ресурсы" в виртуальной сети Azure, но в интеграции с виртуальной сетью виртуальная сеть может быть подключена к локальной сети через VPN типа "сеть — сеть". В этой топологии сети приложение может подключаться к локальным ресурсам, таким как он подключается к другим ресурсам в виртуальной сети.
  • Среда службы приложений с VPN типа "от сети к сети": как описано в 'Ресурсы внутри виртуальной сети Azure', но в среде службы приложений виртуальная сеть может быть подключена к локальной сети через VPN типа "от сети к сети". В этой топологии сети приложение может подключаться к локальным ресурсам, таким как он подключается к другим ресурсам в виртуальной сети.

Секреты приложений

Не сохраняйте секреты приложений, такие как учетные данные базы данных, маркеры API и закрытые ключи в файлах кода или конфигурации. Распространенный подход заключается в том, чтобы получить доступ к ним в качестве переменных среды с помощью стандартного шаблона на выбранном языке. В службе приложений определить переменные среды можно с помощью параметров приложения (и, особенно для приложений .NET, строк подключения). Параметры приложения и строки подключения хранятся в зашифрованном виде в Azure. Они расшифровываются только перед внедрением в память процесса приложения при запуске приложения. Ключи шифрования регулярно меняются.

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

Сетевая изоляция

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

Вы можете:

  • Предоставление доступа к приложениям через выделенную общедоступную точку доступа с выделенными внешними интерфейсами.
  • Обслуживайте внутреннее приложение с помощью внутренней подсистемы балансировки нагрузки (ILB), которая разрешает доступ только из виртуальной сети Azure. У балансировщика ILB есть IP-адрес из вашей частной подсети, который обеспечивает полную изоляцию ваших приложений от Интернета.
  • Использовать внутренний балансировщик нагрузки (ILB) позади брандмауэра веб-приложения (WAF). WAF обеспечивает защиту корпоративного уровня для общедоступных приложений, таких как защита от распределенной атаки типа "отказ в обслуживании" (DDoS), фильтрация URI и предотвращение внедрения SQL.

Защита от атак DDoS

Для веб-рабочих нагрузок настоятельно рекомендуется использовать защиту от атак DDoS Azure и WAF для защиты от новых атак DDoS. Другим вариантом является развертывание Azure Front Door с помощью WAF. Azure Front Door обеспечивает защиту на уровне платформы от атак DDoS на уровне сети.

Дополнительные сведения см. в статье Введение в службы приложений Azure.