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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Используйте инфраструктуру как код (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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Экспорт журналов действий 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.

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

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