Вопросы безопасности для критически важных рабочих нагрузок в Azure

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

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

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

Выравнивание с моделью "Нулевое доверие"

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

Рекомендации по проектированию

По мере оценки состояния безопасности приложения начните с этих вопросов в качестве основы для каждого рассмотрения.

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

  • Выполняется ли тестирование безопасности в рамках автоматизированных процессов CI/CD?
  • Если нет, как часто выполняется определенное тестирование безопасности?
  • Измеряются ли результаты тестирования относительно желаемого уровня безопасности и модели угрозы?

• Уровень безопасности во всех более низких средах.

  • Имеют ли все среды в жизненном цикле разработки одинаковое состояние безопасности, что и рабочая среда?

• Непрерывность проверки подлинности и авторизации в случае сбоя.

  • Если службы проверки подлинности или авторизации временно недоступны, приложение сможет продолжать работать?

• Автоматическое обеспечение соответствия требованиям безопасности и устранение нарушений.

  • Можно ли обнаружить изменения параметров безопасности ключа?
  • Автоматизированы ли процессы по исправлению несоответствующих изменений?

• Сканирование секретов для обнаружения секретов до фиксации кода для предотвращения утечки секретов через репозитории исходного кода.

  • Возможна ли проверка подлинности в службах без учетных данных в рамках кода?

• Защитите цепочку поставок программного обеспечения.

  • Можно ли отслеживать распространенные уязвимости и угрозы (CVEs) в зависимостях используемого пакета?
  • Существует ли автоматизированный процесс обновления зависимостей пакетов?

• Жизненные циклы ключей защиты данных.

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

• Инструменты CI/CD должны использовать федерацию удостоверений для рабочих нагрузок или управляемые удостоверения с Azure RBAC, настроенным по принципу наименьших привилегий, для доступа к плоскости управления.

  • Когда ресурсы приложений заблокированы в частных сетях, существует ли путь подключения частной плоскости данных, чтобы средства CI/CD могли выполнять развертывания и обслуживание на уровне приложения?
    • Это представляет дополнительную сложность и требует последовательности в процессе развертывания с помощью необходимых частных агентов сборки.

Рекомендации по проектированию

• Используйте Политика Azure для обеспечения безопасности и надежности конфигураций. Дополнительные сведения см. в разделе "Управление на основе политик".

• Используйте Microsoft Entra управление привилегированными пользователями (PIM) в рабочих подписках, чтобы отменить устойчивый доступ уровня управления к рабочим средам. Это значительно уменьшит риск, вызванный сценариями "вредоносных администраторов", с помощью дополнительных "проверок и балансов".

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

• Используйте Azure RBAC для авторизации доступа к данным во всех службах, которые поддерживают эту возможность.

• Используйте библиотеки проверки подлинности платформа удостоверений Майкрософт в коде приложения для интеграции с Microsoft Entra ID.

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

  • Если поставщик не может выдавать новые маркеры доступа, но по-прежнему проверяет существующие, приложения и зависимые службы могут работать без проблем до истечения срока действия маркеров.
  • Кэширование маркеров обычно обрабатывается автоматически библиотеками проверки подлинности (например, MSAL).

• Используйте инфраструктуру как код (IaC) и автоматизированные конвейеры CI/CD для обновления всех компонентов приложения, даже в случае сбоя.

  • Убедитесь, что подключения службы средств CI/CD защищены как критически важные конфиденциальные сведения и не должны быть непосредственно доступны для любой команды службы.
  • Примените детализированный RBAC к производственным конвейерам CD, чтобы уменьшить риски, связанные с вредоносными администраторами.
  • Рассмотрите возможность использования шлюзов утверждения вручную в конвейерах развертывания рабочей среды для дальнейшего устранения рисков вредоносного администратора и предоставления дополнительной технической гарантии для всех рабочих изменений.
    • Дополнительные ворота безопасности могут оказаться в компромиссе с точки зрения гибкости и должны быть тщательно оценены, учитывая, как гибкость может поддерживаться даже с ручными воротами.

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

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

• Включите Microsoft Defender для облака для всех подписок, содержащих ресурсы для критически важной рабочей нагрузки.

  • Используйте политику Azure для обеспечения соответствия требованиям.
  • Включите планы Microsoft Defender для облака для всех служб, которые поддерживают эту возможность.

• Примите DevSecOps и внедрите проверку безопасности в конвейеры CI/CD.

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

• Включите проверку секретов и проверку зависимостей в репозитории исходного кода.

Моделирование угроз

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

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

1. Платформа Azure с базовыми возможностями безопасности и элементами управления.
2. Архитектура приложения и проектирование безопасности.
3. Функции безопасности, встроенные, включенные и развертываемые для защиты ресурсов Azure.
4. Код приложения и логика безопасности.
5. Операционные процессы и DevSecOps.

Рекомендации по проектированию

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

• Подделка личности: выдача себя за лиц с властью. Например, злоумышленник, выдающий себя за другого пользователя с помощью:
  • Идентичность
  • Аутентификация
• Изменение входных данных: изменение входных данных, отправленных приложению, или нарушение границ доверия для изменения кода приложения. Например, злоумышленник, использующий SQL-инъекцию для удаления данных в таблице базы данных.
  • Целостность данных
  • Ратификация
  • Блокировка и список разрешений
• Отказ от действий: способность опровергать уже принятые действия, а также способность приложения собирать доказательства и управлять ответственностью. Например, удаление критически важных данных без возможности отследить действие до злонамеренного администратора.
  • Аудит и ведение журнала
  • Подписывание
• Раскрытие информации: получение доступа к ограниченной информации. Например, злоумышленник получает доступ к ограниченному файлу.
  • Шифрование
  • Утечка данных
  • Атака типа "человек посредине"
• Отказ в обслуживании: нарушение вредоносных приложений для снижения взаимодействия с пользователем. Например, атака ботнета DDoS, например Slowloris.
  • DDoS-атаки
  • ботнеты;
  • Возможности CDN и WAF
• Повышение привилегий: получение привилегированного доступа к приложению с помощью эксплойтов авторизации. Например, злоумышленник управляет строкой URL-адреса для получения доступа к конфиденциальной информации.
  • Удаленное выполнение кода
  • Авторизация
  • Изоляция

Рекомендации по проектированию

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

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

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

Защита от вторжений в сеть

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

Рекомендации по проектированию

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

  • Расширенная реализация сети нулевого доверия использует микросегментацию и распределенные входящие/исходящие микропериметры.

• Используйте частное подключение для служб Azure PaaS там, где это поддерживается, и учитывайте доступ CI/CD к частным плоскостям данных. Дополнительные сведения см. в разделе "Интеграция виртуальной сети".

  • Требуется подключение к частным агентам сборки из средств CI/CD.
  • Используйте jump-серверы для задач разработки и администрирования, требующих доступа к плоскости данных.

• Используйте подключения службы Azure DevOps с федерацией удостоверений рабочей нагрузки, чтобы использовать Azure RBAC, не сохраняя секреты.

• Теги служб можно применять к группам безопасности сети, чтобы упростить подключение к службам Azure PaaS. Дополнительные сведения см. в руководстве по службе виртуальная сеть.

• Группы безопасности приложений не охватывают несколько виртуальных сетей.

Рекомендации по проектированию

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

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

• При работе с частными агентами сборки никогда не открывайте порт RDP или SSH непосредственно в Интернет.

  • Используйте Бастион Azure для обеспечения безопасного доступа к Виртуальные машины Azure. Дополнительные сведения см. в руководстве по службе Виртуальные машины.

• Используйте Azure защиту от атак DDoS для защиты общедоступных IP-адресов, которым требуется защита от атак DDoS на уровне сети.

• Используйте Azure Front Door с политиками брандмауэра веб-приложений для глобальных рабочих нагрузок HTTP/S-трафика. Дополнительные сведения см. в разделе "Службы доставки приложений".

• Если дополнительные встроенные средства сетевой безопасности, такие как глубокая проверка пакетов или TLS-инспекция, требуют использования Брандмауэр Azure Premium или виртуального сетевого устройства (NVA), убедитесь, что они настроены для обеспечения максимально возможной высокой доступности и избыточности.

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

• Используйте группы безопасности сети и группы безопасности приложений для микросегментации трафика приложений. Дополнительные сведения см. в разделе Микросегментация и сетевые политики Kubernetes и в руководстве по службе виртуальная сеть.

• Включите журналы потоков виртуальной сети и перенаправьте их в аналитику трафика , чтобы получить аналитические сведения о внутренних и внешних потоках трафика.

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

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

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

• Для сценариев гибридных приложений обеспечьте доступ к службам Azure PaaS из локальной инфраструктуры через ExpressRoute с частным пирингом.

Защита целостности данных

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

Рекомендации по проектированию

• Azure Key Vault имеет ограничения транзакций для ключей и секретов, при этом регулирование применяется для каждого хранилища в течение определенного периода.

• Azure Key Vault поддерживает Azure RBAC и политики доступа для авторизации на уровне плоскости данных.

  • Используйте Azure RBAC для плоскости данных Key Vault, если не требуется устаревшая модель политики доступа.

• После изменения назначения роли подождите, пока изменения распространятся, прежде чем использовать новое разрешение.

  • Существует ограничение на 4 000 назначений ролей Azure для одной подписки.

• Базовые аппаратные модули безопасности Azure Key Vault (HSM) имеют проверку FIPS 140.

  • Выделенный управляемый модуль HSM Azure Key Vault доступен для сценариев, требующих соответствия FIPS 140-2 уровня 3.

• Azure Key Vault обеспечивает высокий уровень доступности и избыточность для обеспечения доступности и предотвращения потери данных.

• Во время аварийного переключения региона может потребоваться несколько минут для переключения службы Key Vault.

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

• Если для подключения к Azure Key Vault используется частное соединение, может потребоваться до 20 минут для повторного создания подключения во время регионального аварийного переключения.

• Резервная копия создает моментальный снимок секрета, ключа или сертификата в качестве зашифрованного большого двоичного объекта, который не может быть расшифрован за пределами Azure. Чтобы получить используемые данные из объекта типа blob, его необходимо восстановить в Key Vault в той же подписке Azure и географическом регионе Azure.

  • Во время резервного копирования секреты могут обновляться, что может вызвать несоответствие.

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

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

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

Рекомендации по проектированию

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

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

• Используйте Azure Key Vault для секретов, сертификатов и ключей, если вам нужны криптографические материалы, управляемые клиентом, или другие секреты. Дополнительные сведения см. в разделе "Управление секретами".

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

  • Используйте выделенный экземпляр Azure Key Vault для глобальных ресурсов приложений.

• Следуйте модели с минимальными привилегиями, ограничив авторизацию для окончательного удаления секретов, ключей и сертификатов специализированными настраиваемыми ролями Microsoft Entra.

• Убедитесь, что ключи шифрования и сертификаты, хранящиеся в Key Vault, создают резервную копию, обеспечивая автономную копию в маловероятном событии Key Vault становится недоступной.

• Используйте Key Vault сертификаты для управления выдачой и продлением сертификата.

• Создайте автоматизированный процесс для смены ключей и сертификатов.

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

• Мониторинг использования ключей, сертификатов и секретов.

  • Настройка оповещений для непредвиденного использования в Azure Monitor.

Управление на основе политик

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

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

Рекомендации по проектированию

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

• Политику Azure можно использовать для управления автоматическими действиями управления, такими как подготовка и настройка.

  • Регистрация поставщика ресурсов.
  • Проверка и утверждение отдельных конфигураций ресурсов Azure.

• Область назначения политики Azure определяет охват и расположение определений политик Azure сообщает о повторном использовании пользовательских политик.

• Политика Azure имеет несколько ограничений, таких как количество определений в любой конкретной области.

• Выполнение политик Deploy If Not Exist (DINE) может занять несколько минут.

• Политика Azure предоставляет критически важные данные для отчетов о соответствии и аудита безопасности.

Рекомендации по проектированию

• Сопоставление нормативных требований и требований к соответствию определениям политики Azure.

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

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

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

Эталонная реализация Mission Critical содержит политики, ориентированные на безопасность и надежность, для определения и обеспечения соблюдения примера общих инженерных критериев.

• Мониторинг смещения конфигурации службы относительно общих критериев проектирования с помощью политики Azure.

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

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

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

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

• Используйте политику Azure для обеспечения согласованной схемы тегов в приложении.
  • Определите обязательные теги Azure и используйте эффект “modify”, чтобы обеспечить их использование.

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

• Экспортируйте журналы аудита Microsoft Entra и журналы входа в глобальную рабочую область Log Analytics, используемую приложением.
  • Убедитесь, что журналы действий Azure архивируются в глобальной учетной записи хранения вместе с операционными данными для долгосрочного хранения. Дополнительные сведения см. в руководстве по службе Хранилище BLOB-объектов.

В зоне развертывания Azure журналы Microsoft Entra также будут поступать в централизованную рабочую область Log Analytics платформы. Оцените, нужно ли хранить их в рабочей области приложения Log Analytics.

• Интеграция Microsoft Defender для облака с платформой управления сведениями о безопасности и событиями, например Microsoft Sentinel.

Рекомендации по работе с IaaS при использовании Виртуальные машины

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

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

Ознакомьтесь с рекомендациями по операционным процедурам для сценариев критически важных приложений.