Share via

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

  • Статья

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

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

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

Важно!

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

Логотип GitHubMission-Critical открытый код project

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

Соответствие модели "Никому не доверяй"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Обычно доступ к службам 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.

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

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

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

  • Запись пакетов в 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, настроенного с частным пирингом.

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Резервная копия создает snapshot секрета, ключа или сертификата на определенный момент времени в виде зашифрованного большого двоичного объекта, который нельзя расшифровать за пределами 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 Mission-Critical, убедитесь, что примененная схема тегов предоставляет значимый контекст, чтобы расширить возможности поддержки благодаря глубокому пониманию приложения.

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

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

  • Интеграция управления информационной безопасностью и событиями безопасности с Microsoft Defender for Cloud (ранее известная как Центр безопасности Azure).

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

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

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

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

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

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

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

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

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

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