Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этой статье содержатся сведения, которые помогут вам:
- Общие сведения о преимуществах безопасности размещения приложений в облаке
- Оценка преимуществ безопасности платформы как службы (PaaS) и других моделей облачных служб
- Измените фокус безопасности с ориентированного на сеть на ориентированный на удостоверение подход к безопасности периметра.
- Реализация общих рекомендаций по обеспечению безопасности PaaS
Разработка безопасных приложений в Azure — это общее руководство по вопросам безопасности и элементам управления, которые следует учитывать на каждом этапе жизненного цикла разработки программного обеспечения при разработке приложений для облака.
Преимущества облачной безопасности
Важно понимать разделение ответственности между вами и корпорацией Майкрософт. Локально вы владеете целым стеком, но при переходе в облако некоторые обязанности передаются в Корпорацию Майкрософт.
Существуют преимущества безопасности для того, чтобы быть в облаке. В локальной среде организации, скорее всего, имеют неуправляемые обязанности и ограниченные ресурсы, доступные для инвестиций в безопасность, которая создает среду, в которой злоумышленники могут использовать уязвимости на всех уровнях.
Организации могут улучшить время обнаружения угроз и реагирования с помощью облачных возможностей безопасности поставщика и облачной аналитики. Переключив обязанности на поставщика облачных служб, организации могут получить больше покрытия безопасности, что позволяет им перераспределить ресурсы безопасности и бюджет на другие бизнес-приоритеты.
Преимущества безопасности модели облачной службы PaaS
Давайте рассмотрим преимущества безопасности развертывания Azure PaaS и локальной среды.
Начиная с нижней части стека, физической инфраструктуры, корпорация Майкрософт снижает распространенные риски и обязанности. Так как облако Майкрософт постоянно отслеживается корпорацией Майкрософт, трудно атаковать. Нет смысла для злоумышленника выбирать облако Microsoft в качестве цели. Если злоумышленник не имеет большого количества денег и ресурсов, злоумышленник, скорее всего, перейдет к другому целевому объекту.
В середине стека нет разницы между развертыванием PaaS и локальной средой. На уровне приложений и на уровне управления учетными записями и доступом есть аналогичные риски. В следующем разделе этой статьи мы рассмотрим рекомендации по устранению или минимизации этих рисков.
На верхнем уровне стека управлений данными и правами, вы сталкиваетесь с риском, который можно смягчить с помощью управления ключами. Хотя управление ключами является дополнительной ответственностью, у вас есть области в развертывании PaaS, которым больше не нужно управлять, чтобы можно было переместить ресурсы в управление ключами.
Платформа Azure также обеспечивает надежную защиту от атак DDoS с помощью различных сетевых технологий. Однако все типы сетевых методов защиты от атак DDoS имеют свои ограничения по каждой связи и на каждый дата-центр. Чтобы избежать влияния крупных атак DDoS, вы можете воспользоваться основными облачными возможностями Azure для быстрого и автоматического масштабирования для защиты от атак DDoS.
Удостоверение в качестве основного периметра безопасности
При развертывании PaaS происходит сдвиг в общем подходе к безопасности. Вы переходите от необходимости контролировать все, чтобы поделиться ответственностью с корпорацией Майкрософт.
Еще одно значительное различие между PaaS и традиционными локальными развертываниями — это новое представление о том, что определяет основной периметр безопасности. Исторически основной локальный периметр безопасности был вашей сетью, и большинство локальных проектов безопасности используют сеть в качестве основной точки безопасности. Для развертываний PaaS вам лучше рассматривать идентификацию как основной периметр безопасности.
Одним из пяти основных характеристик облачных вычислений является широкий доступ к сети, что делает сетево-ориентированное мышление менее актуальным. Цель большого количества облачных вычислений — разрешить пользователям получать доступ к ресурсам независимо от расположения. Для большинства пользователей их расположение будет где-то в Интернете.
На следующем рисунке показано, как периметр безопасности развивался от периметра сети к периметру удостоверений. Безопасность становится меньше о защите сети и больше о защите ваших данных, а также управлении безопасностью ваших приложений и пользователей. Ключевое различие заключается в том, что вы хотите обеспечить безопасность ближе к тому, что важно для вашей компании.
Изначально службы Azure PaaS (например, Служба приложений Azure и SQL Azure) предоставляли мало или нет традиционных средств защиты периметра сети. Было понятно, что элемент предназначен для взаимодействия через Интернет (веб-роль) и что проверка подлинности обеспечивает новый периметр (например, Azure SQL).
Современные методики безопасности предполагают, что злоумышленник нарушил периметр сети. Поэтому современные методы обороны перешли к идентификации. Организации должны установить периметр безопасности на основе удостоверений с строгой проверкой подлинности и гигиеной авторизации.
Рекомендации по управлению идентификацией
Ниже приведены лучшие практики по управлению периметром идентификации.
Рекомендуется сначала использовать управляемые удостоверения для ресурсов Azure для безопасного доступа к другим службам без хранения учетных данных. Сведения.Управляемые удостоверения автоматически предоставляют удостоверение для приложений, работающих в службах Azure, что позволяет им проходить проверку подлинности в службах, поддерживающих идентификатор Microsoft Entra, не требуя учетных данных в файлах кода или конфигурации. Это снижает риск компрометации учетных данных и упрощает управление идентификацией ваших приложений.
Рекомендуется защитить ключи и учетные данные для защиты развертывания PaaS. Подробные сведения. Потеря ключей и учетных данных является распространенной проблемой. Централизованное решение можно использовать, где ключи и секреты можно хранить в аппаратных модулях безопасности (HSM). Azure Key Vault защищает ключи и секреты путем шифрования ключей проверки подлинности, ключей учетной записи хранения, ключей шифрования данных, PFX-файлов и паролей с помощью ключей, защищенных HSM.
Рекомендация. Не помещайте учетные данные и другие секреты в исходный код или GitHub. Подробности: единственное, что хуже, чем потеря ключей и учетных данных, заключается в том, что у неавторизованной стороны есть доступ к ним. Злоумышленники могут воспользоваться технологиями бота для поиска ключей и секретов, хранящихся в репозиториях кода, таких как GitHub. Не помещайте ключи и секреты в эти репозитории общедоступного кода.
Рекомендации. Использование надежных платформ проверки подлинности и авторизации. Сведения: Используйте идентификатор Microsoft Entra для проверки подлинности вместо кастомных хранилищ пользователей. При использовании Microsoft Entra ID вы применяете подход, основанный на платформе, и делегируете управление авторизованными идентификациями. Подход к использованию Microsoft Entra ID особенно важен, когда сотрудники увольняются, и эта информация должна отражаться в нескольких системах идентификации и авторизации.
Используйте механизмы проверки подлинности и авторизации, предоставляемые платформой, вместо пользовательского кода. Причина заключается в том, что разработка пользовательского кода проверки подлинности может быть подвержена ошибкам. Большинство разработчиков не являются экспертами по безопасности и вряд ли будут знать о тонкостях и последних разработках проверки подлинности и авторизации. Коммерческий код (например, от Корпорации Майкрософт) часто тщательно проверяется.
Используйте многофакторную проверку подлинности (MFA) и убедитесь, что методы MFA, устойчивые к фишингу, такие как passkeys, FIDO2 или Certificate-Based Authentication (CBA), применяются с помощью политик условного доступа. Как минимум, требуйте этого для всех администраторов, а для оптимальной безопасности реализуйте это в масштабе арендатора. Для доступа к интерфейсам управления Azure (портал/удаленный PowerShell) и клиентским сервисам следует настроить и сконфигурировать их на использование многофакторной аутентификации Microsoft Entra.
Для входа в приложение используйте OpenID Connect (OIDC) и OAuth 2.0 через Microsoft Entra ID. Эти протоколы были тщательно проверены и, скорее всего, реализованы как часть библиотек платформы для проверки подлинности и авторизации.
Использование моделирования угроз во время разработки приложения
Жизненный цикл разработки безопасности Майкрософт указывает, что команды должны участвовать в процессе, называемом моделированием угроз на этапе разработки. Чтобы упростить этот процесс, корпорация Майкрософт создала средство моделирования угроз SDL. Моделирование архитектуры приложения и перечисление угроз STRIDE через все границы доверия позволяет выявлять ошибки проектирования на ранних стадиях.
В следующей таблице перечислены угрозы STRIDE и приведены некоторые примеры устранения рисков, использующих функции Azure. Эти меры по устранению рисков не будут работать в каждой ситуации.
| Угроза | Свойство безопасности | Потенциальные способы устранения рисков платформы Azure |
|---|---|---|
| Подделка | Аутентификация | Требовать подключения HTTPS. |
| Фальсификации | Целостность | Проверка TLS/SSL-сертификатов. |
| Отказ от признания | Неотрекаемость | Включите мониторинг и диагностику Azure. |
| Раскрытие информации | Конфиденциальность | Шифруйте неактивные конфиденциальные данные, используя сертификаты службы. |
| Отказ в обслуживании | Доступность | Отслеживайте метрики производительности для потенциальных условий отказа в обслуживании. Реализуйте фильтры подключений. |
| Повышение привилегий | Авторизация | Используйте управление привилегированными удостоверениями. |
Служба приложений Azure
служба приложений Azure — это предложение PaaS, которое позволяет создавать веб-приложения и мобильные приложения для любой платформы или устройства и подключаться к данным в любом месте в облаке или локальной среде. Служба приложений включает возможности интернета и мобильных устройств, которые ранее были доставлены отдельно как веб-сайты Azure и мобильные службы Azure. Он также включает новые возможности для автоматизации бизнес-процессов и размещения облачных API.
Ниже приведены рекомендации по использованию службы приложений.
Рекомендация.Проверка подлинности с помощью идентификатора Microsoft Entra. Сведения: Служба приложений предоставляет службу OAuth 2.0 для вашего поставщика удостоверений. OAuth 2.0 ориентирован на упрощение процесса для разработчиков клиентов, предоставляя определенные потоки авторизации для веб-приложений, настольных приложений и мобильных телефонов. Идентификатор Microsoft Entra использует OAuth 2.0, чтобы разрешить доступ к мобильным и веб-приложениям.
Рекомендуется: ограничить доступ на основе необходимости знать и принципы безопасности с минимальными привилегиями. Подробные сведения. Ограничение доступа является обязательным для организаций, которые хотят применить политики безопасности для доступа к данным. Azure RBAC можно использовать для назначения разрешений пользователям, группам и приложениям в определенной области.
Рекомендация. Защита ключей. Сведения. Azure Key Vault помогает защитить криптографические ключи и секреты, используемые облачными приложениями и службами. С помощью Key Vault можно шифровать ключи и секреты (например, ключи проверки подлинности, ключи учетной записи хранения, ключи шифрования данных, ). PFX-файлы и пароли с помощью ключей, защищенных аппаратными модулями безопасности (HSM). Для добавления гарантии можно импортировать или создать ключи в HSM. Дополнительные сведения см. в Azure Key Vault. Вы также можете использовать Key Vault для управления сертификатами TLS с автоматическим продлением.
Рекомендуется ограничить входящие IP-адреса источника. Сведения. Среда службы приложений имеет функцию интеграции с виртуальной сетью, которая помогает ограничить входящие IP-адреса с помощью групп безопасности сети. Виртуальные сети позволяют размещать ресурсы Azure в не интернет-маршрутизируемой сети, к которым вы управляете доступом. Дополнительные сведения см. в статье Интеграция приложения с виртуальной сетью Azure. Кроме того, можно также использовать приватный канал (частная конечная точка) и отключить общедоступную сеть для принудительного подключения частной сети между службой приложений и другими службами.
Наилучшая практика: обеспечить использование только HTTPS и требовать TLS 1.2 или выше для всех подключений. Отключите доступ к FTP, если это возможно; Если требуется передача файлов, используйте FTPS для обеспечения безопасной, зашифрованной передачи. Подробные сведения. Настройка службы приложений для приема только трафика HTTPS гарантирует, что данные шифруются при передаче, защищая конфиденциальную информацию от перехвата. Требование TLS 1.2 или более поздней версии обеспечивает более надежную защиту от уязвимостей, обнаруженных в более ранних версиях протокола. Отключение FTP снижает риск передачи учетных данных или данных в незашифрованном виде. Если требуется передача файлов, включите только FTPS, который шифрует учетные данные и данные во время передачи.
Рекомендуется отслеживать состояние безопасности сред службы приложений. Подробные сведения. Используйте Microsoft Defender для облака для мониторинга сред службы приложений. Когда Defender для облака идентифицирует потенциальные уязвимости безопасности, он создает рекомендации, которые помогут вам выполнить настройку необходимых элементов управления. Microsoft Defender для службы приложений обеспечивает защиту от угроз для ресурсов службы приложений.
Дополнительные сведения см. в Microsoft Defender для службы приложений.
Межсетевой экран для веб-приложений
Веб-приложения все чаще предназначены для вредоносных атак, которые используют распространенные известные уязвимости. Распространенными среди этих эксплойтов являются SQL-инъекции и межсайтовый скриптинг. Предотвращение таких атак в коде приложения может быть сложным и может потребовать строгого обслуживания, исправления и мониторинга на многих уровнях топологии приложений. Централизованный брандмауэр веб-приложения значительно упрощает управление безопасностью и помогает администраторам защищать приложение от угроз вторжения. Решение WAF также может быстрее реагировать на угрозы безопасности, исправив известную уязвимость на центральном сервере, вместо защиты каждого отдельного веб-приложения.
Брандмауэр веб-приложений Azure (WAF) обеспечивает централизованную защиту веб-приложений от распространенных эксплойтов и уязвимостей. WAF доступен через Шлюз приложений Azure и Azure Front Door.
Защита от атак DDoS
Azure предлагает два основных уровня защиты от атак DDoS: защита IP-адресов DDoS и защита сети DDoS. Эти варианты охватывают различные сценарии и имеют различные функции и цены.
- Защита IP-адресов DDoS: лучше всего защитить определенные общедоступные IP-адреса, идеально подходит для небольших или целевых развертываний, требующих существенного устранения рисков DDoS на уровне IP-адресов.
- Защита сети DDoS: охватывает все виртуальные сети с расширенными средствами устранения рисков, аналитикой и интеграцией; подходит для более крупных или корпоративных сред, требующих более широкой безопасности.
Выберите защиту IP-адресов DDoS для ориентированных, дорогостоящих случаев; Выберите защиту сети от атак DDoS для комплексного охвата и расширенных функций.
Защита от атак DDoS защищается на сетевом уровне (3/4). Для защиты уровня приложений (7) добавьте WAF. См. защиту приложения от атак DDoS.
Мониторинг производительности приложения
Azure Monitor собирает, анализирует и действует на данные телеметрии из облачных и локальных сред. Эффективная стратегия мониторинга помогает понять подробную работу компонентов приложения. Это помогает увеличить время простоя, уведомив вас о критически важных проблемах, чтобы устранить их, прежде чем они становятся проблемами. Это также помогает обнаружить аномалии, которые могут быть связаны с безопасностью.
Используйте Application Insights для мониторинга доступности, производительности и использования приложения, будь то размещено в облаке или локальной среде. С помощью Application Insights вы можете быстро выявлять и диагностировать ошибки в приложении, не ожидая, когда пользователь сообщит о них. Используя собранные сведения, вы можете сделать обоснованные варианты обслуживания и улучшения приложения.
Application Insights предоставляет широкие средства для взаимодействия с собранными данными. Application Insights хранит свои данные в общем репозитории. Он может воспользоваться общими функциями, такими как оповещения, панели мониторинга и глубокий анализ с помощью языка запросов Kusto.
Тестирование на проникновение безопасности
Проверка защиты безопасности является столь важной, как тестирование любых других функций. Сделайте тестирование на проникновение стандартную часть процесса сборки и развертывания. Запланируйте регулярные тесты безопасности и сканирование уязвимостей в развернутых приложениях и отслеживайте открытые порты, конечные точки и атаки.
Дальнейшие шаги
В этой статье мы сосредоточились на преимуществах безопасности развертывания Azure PaaS и рекомендаций по обеспечению безопасности облачных приложений. Затем ознакомьтесь с рекомендациями по защите веб-решений PaaS и мобильных устройств с помощью определенных служб Azure. Начнем со службы приложений Azure, Базы данных SQL Azure и Azure Synapse Analytics и службы хранилища Azure. По мере того как статьи о рекомендуемых рекомендациях для других служб Azure становятся доступными, ссылки будут предоставлены в следующем списке:
Ознакомьтесь с разделом "Разработка безопасных приложений в Azure" для вопросов безопасности и элементов управления, которые следует учитывать на каждом этапе жизненного цикла разработки программного обеспечения при разработке приложений для облака.
Ознакомьтесь с рекомендациями и шаблонами безопасности Azure для получения дополнительных рекомендаций по обеспечению безопасности при разработке, развертывании и управлении облачными решениями с помощью Azure.
Ниже приведены ресурсы, с помощью которых можно получить общие сведения о службах безопасности Azure и связанных службах Майкрософт.
- Документация по безопасности Azure для получения комплексных рекомендаций по безопасности
- Microsoft Security Response Center. Это место, куда можно сообщать об уязвимостях, в том числе о проблемах Azure. Это также можно сделать по почте, отправив сообщение по адресу [email protected].