Защита ресурсов Azure от разрушительных кибератак

В этой статье приведены инструкции по применению принципов нулевого доверия для защиты ресурсов Microsoft Azure от разрушительных кибератак следующим образом:

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

• Защита ресурсов Microsoft Azure от разрушительных кибератак.
• Обнаруживайте кибератаки при их возникновении.
• Как реагировать на них.

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

Эталонная архитектура

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

Эта среда Azure включает в себя следующее:

Задачи по защите каждого типа ресурса подробно описаны на шаге 1 этой статьи.

Что такое в этой статье?

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

Шаг 1. Настройка защиты от кибератак

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

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

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

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

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

Администраторы с доступом к удалению блокировок должны быть ограничены и должны включать JIT-доступ, такой как предоставленный microsoft Entra управление привилегированными пользователями. Доступ к блокировкам изменений для ресурсов управляется областью Microsoft.Authorization/locks/* и не должен предоставляться в рамках постоянного доступа.

А. Защита виртуальных машин

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

Сначала необходимо спланировать резервное копирование данных из виртуальных машин, чтобы можно было восстановить потерянные данные при возникновении атаки, которая включает Служба Azure Kubernetes (AKS). Кроме того, необходимо защитить резервные копии данных от атак с помощью элементов управления обратимого удаления. Дополнительные сведения о настройке резервных копий см. в статье:

• Создание и настройка хранилища служб восстановления
• Резервное копирование виртуальной машины в Azure
• Настройка резервного копирования для кластера Служба Azure Kubernetes
• Резервное копирование и восстановление для AKS
• План резервного копирования и восстановления для защиты от программ-шантажистов
• Обратимое удаление для Azure Backup

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

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

B. Защита служб данных

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

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

• Часто содержат собственные средства отработки отказа, такие как возможность реплицировать учетную запись хранения в другой регион в рамках геоизбыточного уровня хранилища (GRS).
• У вас есть собственные рекомендации по защите данных от атак и их повторной доступности в случае атаки.

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

C. Защита инфраструктуры восстановления

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

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

Чтобы повысить безопасность, реализуйте многопользовательскую авторизацию (MUA) для критически важных операций, что требует, чтобы два или более пользователей одобрили критически важные операции перед выполнением. Это добавляет дополнительный уровень безопасности, гарантируя, что ни один пользователь, и, следовательно, злоумышленник с одной учетной записью пользователя может компрометации целостности резервного копирования. Включите и настройте muA для защиты политик резервного копирования от несанкционированных изменений и удалений.

Вы можете защитить Azure Site Recovery с помощью блокировок ресурсов и доступа JEA/JIT, чтобы предотвратить несанкционированный доступ и обнаружение, когда ресурсы находятся под угрозой.

При репликации виртуальных машин с помощью Azure Site Recovery, зашифрованных с помощью Шифрование дисков Azure (ADE) или управляемых клиентом ключей (CMK), убедитесь, что ключи шифрования хранятся в Azure Key Vault для целевого региона. Хранение ключей в целевом регионе упрощает простой доступ к ключам после отработки отказа и обеспечивает непрерывность безопасности данных. Чтобы защитить Azure Key Vault от разрушительных кибератак, включите расширенные функции защиты от угроз, такие как обратимое удаление и очистка защиты.

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

• Репликация защищенных ADE виртуальных машин
• Репликация виртуальных машин с дисками CMK

D. Защита служб на основе конфигурации

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

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

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

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

Е. Защита средств автоматизации платформы и средств DevOps

Если вы используете программные развертывания или другие типы автоматизации, автоматизации платформы и средств DevOps, необходимо также защитить ресурсы. Примеры защиты инфраструктуры развертывания см. в разделе "Защита конвейеров CI/CD DevOps и рекомендаций по защите жизненного цикла разработки".

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

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

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

Шаг 2. Настройка обнаружения кибератак

Для обнаружения атак на инфраструктуру Azure начните с Microsoft Defender для облака, платформы защиты приложений на основе облака (CNAPP), которая состоит из мер безопасности и методик, предназначенных для защиты облачных приложений от различных кибер-угроз и уязвимостей.

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

На следующей схеме показан поток сведений о событиях безопасности из служб Azure через Defender для облака и Microsoft Sentinel.

На рисунке:

• Службы Azure отправляют сигналы в Microsoft Defender для облака.
• Microsoft Defender для облака с дополнительными планами, такими как Defender для серверов, анализирует сигналы для расширенного обнаружения угроз и отправляет данные системы безопасности и управления событиями (SIEM) в Microsoft Sentinel.
• Microsoft Sentinel использует данные SIEM для обнаружения, расследования, реагирования и упреждающего охоты.

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

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

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

Шаг 3. Подготовка планов реагирования на инциденты

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

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

Сборники схем должны:

• Включите процессы для следующих сценариев:

  • Отработка отказа виртуальных машин Azure в дополнительный регион
  • Восстановление данных виртуальной машины Azure в портал Azure
  • Восстановление файлов на виртуальной машине в Azure
  • Восстановление обратимых удаленных данных и точек восстановления с помощью расширенного обратимого удаления в Azure Backup
  • Восстановление состояния кластеров Kubernetes после аварии
  • Восстановление удаленной учетной записи хранения.
  • Восстановление обратимого хранилища ключей
  • Восстановление обратимо удаленных секретов, ключей и сертификатов из хранилища ключей
  • Руководство по аварийному восстановлению для База данных SQL Azure

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

• Периодически тестироваться в рамках процессов обслуживания SecOps.

Рекомендуемое обучение

• Реализация управление привилегированными пользователями
• Разработка решения для резервного копирования и аварийного восстановления
• Улучшение состояния облачной безопасности с помощью Microsoft Defender для облака
• Создание обнаружения и выполнение расследований с помощью Microsoft Sentinel

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

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

Ссылки

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

• Блокировки ресурсов
• Microsoft Entra управление привилегированными пользователями
• Обратимое удаление для резервного копирования Azure
• Многопользовательская авторизация (MUA)
• Bicep
• Microsoft Defender для облака
• Microsoft Sentinel