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

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

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

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

Внимание

Эта статья является частью серии критически важных рабочих нагрузок Azure Well-Architected. Если вы не знакомы с этой серией, рекомендуем начать работу с критически важной рабочей нагрузкой?

Критически важный проект открытый код

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Средства CI/CD должны требовать субъекты-службы Microsoft Entra с достаточным доступом на уровне подписки, чтобы упростить доступ на уровне управления для развертываний ресурсов Azure для всех рассматриваемых подписок среды.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Объявите DevSecOps и реализуйте тестирование безопасности в конвейерах CI/CD.

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

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Частные локальные агенты сборки, развернутые в частной сети, так как ресурс Azure можно использовать в качестве прокси-сервера для выполнения функций CI/CD через частное подключение. Для агентов сборки следует использовать отдельную виртуальную сеть.
    • Требуется подключение к частным агентам сборки из средств CI/CD.
  • Альтернативный подход заключается в изменении правил брандмауэра для ресурса во всплывающем конвейере, чтобы разрешить подключение с общедоступного IP-адреса агента Azure DevOps, а брандмауэр впоследствии удален после завершения задачи.
    • Однако этот подход применим только для подмножества служб Azure. Например, это невозможно для частных кластеров AKS.
  • Для выполнения задач разработчика и администрирования в полях перехода службы приложений можно использовать.

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

• Подключения к службе с соответствующим субъектом-службой Microsoft Entra можно использовать в Azure DevOps для применения RBAC через идентификатор Microsoft Entra.

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

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

• Запись пакетов в Azure Наблюдатель за сетями ограничена не более пяти часов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

• После изменения назначения роли задержка составляет до 10 минут (600 секунд) для применения роли.

  • Существует ограничение в 2000 назначений ролей 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. Чтобы получить доступные данные из большого двоичного объекта, его необходимо восстановить в Key Vault в той же подписке Azure и географическом регионе Azure.

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

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

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

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

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

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

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

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

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

• Разверните отдельный экземпляр 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 сообщает о повторном использовании пользовательских политик.

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

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

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

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

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

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

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

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

Реализация справочника по критически важным задачам содержит широкий спектр политик безопасности и надежности для определения и применения примеров общих критериев проектирования.

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

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

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

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

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

Примечание.

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

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

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

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

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

• Интеграция сведений о безопасности и управления событиями с Microsoft Defender для облака (прежнее название — Центр безопасности Azure).

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

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

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

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

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

• Не разрешайте прямой доступ через общедоступный Интернет Виртуальные машины, предоставляя доступ к SSH, RDP или другим протоколам. Всегда используйте Бастион Azure и прыжки с ограниченным доступом к небольшой группе пользователей.
• Ограничение прямого подключения к Интернету с помощью брандмауэра (Azure) или Шлюз приложений (уровень 7) для фильтрации и ограничения исходящего трафика.
• Для многоуровневых приложений рекомендуется использовать разные подсети и использовать группы безопасности сети для ограничения доступа между ними.
• По возможности определите приоритет использования проверки подлинности с открытым ключом. Храните секреты в безопасном месте, например Azure Key Vault.
• Защита виртуальных машин с помощью проверки подлинности и управления доступом.
• Применяйте те же методики безопасности, что и для сценариев критически важных приложений.

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

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

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

Операционные процедуры