Защита развернутых служб PaaS

Эта статья содержит сведения, которые помогут вам:

• понять преимущества безопасности размещения приложений в облаке;
• оценить преимущества безопасности платформы как услуги (PaaS) перед другими моделями облачных служб;
• изменить ориентированную на сеть модель безопасности на модель периметра безопасности на основе удостоверений;
• внедрить общие рекомендации по безопасности PaaS.

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

Преимущества безопасности облака

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

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

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

Преимущества безопасности модели облачных служб PaaS

Используя ту же таблицу ответственности, рассмотрим преимущества развертывания службы PaaS в Azure перед локальным развертыванием.

Начиная с нижней части стека, физической инфраструктуры, корпорация Майкрософт уменьшает распространенных риски и обязанности. Так как корпорация Майкрософт непрерывно наблюдает за облаком Майкрософт, его сложно атаковать. Злоумышленнику нет смысла выбирать в качестве цели облако Майкрософт. Если только у злоумышленника нет множества денежных средств и технических ресурсов, скорее всего он выберет другую цель.

В середине стека нет различий между развернутой службой PaaS и локальным развертыванием. На прикладном уровне и уровне управления учетными записями и доступом риски одинаковы. В разделе дальнейших действий этой статьи мы предоставим вам рекомендации по устранению или минимизации этих рисков.

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

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

Модернизация мышления Defender для облака

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

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

Применение политики удостоверения в качестве основного периметра безопасности

Одной из пяти основных характеристик облачных вычислений является расширенный сетевой доступ, что делает менее уместным подход, ориентированный на сеть. Цель большинства сред облачных вычислений — предоставлять пользователям доступ к ресурсам независимо от расположения. Расположение большинства пользователей будет находиться где-то в Интернете.

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

Первоначально службы PaaS Azure (например, веб-роли и SQL Azure) обеспечивали крайне мало или вообще не обеспечивали традиционных средств защиты периметра сети. Было понятно, что цель элемента должна быть предоставлена в Интернете (веб-роль) и что проверка подлинности предоставляет новый периметр (например, BLOB или Azure SQL).

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

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

Ниже приведены рекомендации по управлению периметром на основе удостоверений.

Рекомендация. Защитите свои ключи и учетные данные, чтобы обеспечить безопасность развертывания PaaS. Сведения. Потеря ключей и учетных данных является распространенной проблемой. Вы можете использовать централизованное решение, в котором ключи и секретные данные могут храниться в аппаратных модулях безопасности (HSM). Azure Key Vault защищает ключи и секреты путем шифрования ключей проверки подлинности, ключей учетной записи хранения, ключей шифрования данных, PFX-файлов и паролей с помощью ключей, защищенных HSM.

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

Рекомендация. Защищайте свои интерфейсы управления виртуальной машиной в гибридных службах PaaS и IaaS, используя интерфейс управления, который позволяет удаленно управлять этими виртуальными машинами напрямую. Сведения. Можно использовать такие протоколы удаленного управления, как SSH и RDP, и также удаленное взаимодействие через PowerShell. Как правило, рекомендуется не включать прямой удаленный доступ к виртуальным машинам из Интернета.

Если это возможно, используйте альтернативные подходы, такие как использование виртуальных частных сетей в виртуальной сети Azure. Если альтернативные подходы невозможны, обязательно используйте сложные парольные фразы и двухфакторную аутентификацию (например, Многофакторную идентификацию Azure AD).

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

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

Используйте двухфакторную аутентификацию. Двухфакторная аутентификация является текущим стандартом аутентификации и авторизации, так как позволяет избежать уязвимостей системы безопасности, присущих разновидностям аутентификации по имени пользователя и паролю. Доступ к интерфейсам управления Azure (портал или удаленный сеанс PowerShell) и службам для клиентов должен быть спроектирован и настроен для использования Многофакторной идентификации Azure AD.

Используйте стандартные протоколы аутентификации, такие как OAuth2 и Kerberos. Эти протоколы внимательно оценены коллегами и скорее всего реализованы в составе библиотек аутентификации и авторизации для вашей платформы.

Использование моделирование угроз во время разработки приложения

Жизненный цикл разработки защищенных приложений (Майкрософт) указывает, что команды должны принимать участие в процессе моделирования угроз на этапе проектирования. Чтобы ускорить этот процесс, корпорация Майкрософт создала средство моделирования угроз SDL. Моделирование архитектуры приложения и перечисление угроз STRIDE на всех границах доверия позволяют обнаружить ошибки на раннем этапе.

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

Угроза	Свойство безопасности	Потенциальные миграции платформы Azure
Спуфинг	Проверка подлинности	Требуйте HTTPS-подключения.
Незаконное изменение	Целостность	Подтвердите сертификаты TLS/SSL.
Отказ	Невозможность отказа	Включите мониторинг и диагностику в Azure.
Раскрытие информации	Конфиденциальность	Зашифруйте конфиденциальные неактивные данные с помощью сертификатов службы.
Отказ в обслуживании	Доступность	Отслеживайте метрики производительности на наличие признаков атаки типа "отказ в обслуживании". Примените фильтры подключения.
Несанкционированное получение привилегий	Авторизация	Используйте технологию управления привилегированными пользователями.

Разработка в Службе приложений Azure

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

Ниже приведены рекомендации по использованию Службы приложений.

Рекомендация. Выполняйте аутентификацию с помощью Azure Active Directory. Сведения. Служба приложений предоставляет службу OAuth 2.0 для поставщика удостоверений. Служба OAuth 2.0 предназначена упростить разработку клиентов, так как предоставляет определенные процедуры авторизации для веб-приложений, классических приложений и мобильных телефонов. Azure AD использует OAuth 2.0 для авторизации доступа к мобильным приложениям и веб-приложениям.

Рекомендация. Доступ следует ограничивать с учетом возможности использования необходимой информации и минимальных полномочий. Сведения. Ограничение доступа крайне важно для организаций, которые планируют применять политики безопасности для доступа к данным. Вы можете использовать Azure RBAC для назначения разрешений пользователям, группам и приложениям в определенной области. Дополнительные сведения о предоставлении пользователям доступа к приложениям см. в статье Что такое управление доступом на основе ролей (RBAC)?

Рекомендация. Обеспечьте защиту ключей. Сведения. Azure Key Vault помогает защитить криптографические ключи и секреты, используемые облачными приложениями и службами. С помощью Key Vault можно шифровать ключи и секреты (например, ключи аутентификации, ключи учетных записей хранения, ключи шифрования данных, PFX-файлы и пароли), используя ключи, защищенные аппаратными модулями безопасности. Чтобы обеспечить более высокий уровень защиты, ключи можно импортировать или создать в аппаратных модулях безопасности. Чтобы узнать больше, ознакомьтесь с разделом то такое хранилище ключей Azure? Key Vault можно также использовать для управления TLS-сертификатами с автоматическим продлением.

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

Рекомендация. Отслеживайте состояние безопасности сред службы приложений. Сведения: используйте Microsoft Defender для облака, чтобы отслеживать среды Службы приложений. Когда Defender для облака выявляет потенциальные уязвимости в системе безопасности, он создает рекомендации по настройке необходимых элементов управления.

Oблачныe службы Azure

Облачные службы Azure Cloud Services являются примером концепции платформы как услуги (PaaS). Так же как и служба приложений Azure, эта технология предназначена для поддержки масштабируемых, надежных и недорогих в эксплуатации приложений. Облачные службы Azure размещаются так же, как и службы приложений на виртуальных машинах (ВМ). Однако над виртуальными машинами доступен больший контроль. На виртуальных машинах, использующих облачные службы Azure, можно установить собственное программное обеспечение, а затем получить удаленный доступ к нему.

Установка брандмауэра веб-приложения

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

Брандмауэр веб-приложения (WAF) — это компонент Шлюза приложений, обеспечивающий централизованную защиту веб-приложений от распространенных эксплойтов и уязвимостей. Брандмауэр веб-приложения основан на правилах из основных наборов правил OWASP (открытый проект безопасности веб-приложений) версии 3.0 или 2.2.9.

Отслеживание производительности приложений

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

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

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

Тесты на проникновение

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

Тестирование методом Монте-Карло — это метод поиска ошибок программы (ошибок в коде) путем предоставления неправильно сформированных входных данных для программных интерфейсов (точек входа), которые анализируют и потребляют эти данные. Обнаружение угроз безопасности Microsoft Security Risk Detection — это облачное средство, которое можно использовать для поиска ошибок и других уязвимостей безопасности в программном обеспечении перед развертыванием в Azure. Средство предназначено для перехвата уязвимостей перед развертыванием программного обеспечения, поэтому вам не нужно исправлять ошибку, справляться с сбоями или реагировать на атаки после выпуска программного обеспечения.

Дальнейшие действия

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

• Служба приложений Azure
• База данных SQL Azure и Azure Synapse Analytics
• Хранилище Azure
• Oблачныe службы Azure2
• Кэш Azure для Redis
• Служебная шина Azure
• Брандмауэры веб-приложения

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

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

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

• Жизненный цикл продукта Майкрософт — для согласованных и предсказуемых рекомендаций по поддержке на протяжении всего жизненного цикла продукта.
• Microsoft Security Response Center. Это место, куда можно сообщать об уязвимостях, в том числе о проблемах Azure. Это также можно сделать по почте, отправив сообщение по адресу secure@microsoft.com.