Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этой статье приведены инструкции по применению принципов нулевого доверия для защиты ресурсов Microsoft Azure от разрушительных кибератак следующим образом:
| Принцип нулевого доверия | Определение |
|---|---|
| Явная проверка | Всегда выполняйте аутентификацию и авторизацию на основе всех доступных точек данных. |
| Использование доступа с минимальными привилегиями | Ограничьте доступ пользователей с помощью технологий Just-In-Time и Just-Enough-Access (JIT/JEA), адаптивных политик на основе риска и защиты данных. |
| Предполагайте наличие бреши в системе безопасности | Минимизируйте радиус поражения и ограничьте доступ к сегментам. Проверьте сквозное шифрование и используйте аналитику для получения видимости, обнаружения угроз и улучшения защиты. Улучшена защита с помощью блокировок ресурсов, резервных копий и аварийного восстановления для виртуальных машин, служб защиты данных и доступности данных, а также защиты инфраструктуры восстановления, служб на основе конфигурации и средств автоматизации платформы и средств DevOps. Для обнаружения угроз используйте Microsoft Sentinel и расширенное многоэтапное обнаружение и подготовьте планы реагирования на инциденты для ресурсов Azure. |
В этой статье содержатся рекомендации по использованию следующих способов.
- Защита ресурсов Microsoft Azure от разрушительных кибератак.
- Обнаруживайте кибератаки при их возникновении.
- Как реагировать на них.
Эта статья предназначена для технических специалистов для поддержки сценария внедрения инфраструктуры предотвращения нарушений безопасности и восстановления в рамках концепции нулевого доверия.
Эталонная архитектура
На следующем рисунке показана эталонная архитектура для этого руководства по нулю доверия с группами для каждой категории защиты.
Эта среда Azure включает в себя следующее:
| Компонент | Описание |
|---|---|
| а | Виртуальные машины и их файлы |
| Б | Службы данных и их данные |
| C | Инфраструктура восстановления, включая файлы и шаблоны и скрипты автоматизации |
| D | Службы, основанные на конфигурации |
| E | Автоматизация платформы и средства DevOps (не показаны) |
Задачи по защите каждого типа ресурса подробно описаны на шаге 1 этой статьи.
Что такое в этой статье?
В этой статье описаны шаги по применению принципов нулевого доверия в эталонной архитектуре.
| Шаг | Задача |
|---|---|
| 1 | Настройте защиту от кибератак. |
| 2 | Настройте обнаружение кибератак. |
| 3 | Подготовьте планы реагирования на инциденты. |
Шаг 1. Настройка защиты от кибератак
Многие организации реализуют решения резервного копирования и аварийного восстановления для виртуальных машин Azure в рамках усилий по миграции. Например, вы можете использовать собственные решения Azure или использовать собственные сторонние решения для облачной экосистемы.
Хотя защита виртуальных машин и их приложений и данных важна, важно также расширить область защиты за пределами виртуальных машин. В этом разделе представлена разбивка соображений и рекомендаций по защите различные типы ресурсов в Azure от разрушительной кибератаки.
Помимо учета специфики службы, следует рассмотреть возможность использования блокировки ресурсов, чтобы предотвратить удаление служб путем защиты их управляющей панели. Вы также можете использовать блокировки ресурсов, чтобы сделать ресурсы доступными только для чтения. Блокировки ресурсов работают с контролируемым доступом, чтобы снизить вероятность уничтожения ресурсов Azure в кибератаке, предотвращая их изменение или уничтожение.
Чтобы запретить блокировкам ресурсов создавать непредвиденные результаты, необходимо ознакомиться с рекомендациями перед применением блокировок , чтобы убедиться, что блокировки применяются к соответствующим ресурсам таким образом, что они по-прежнему позволяют им работать. Например, блокировка виртуальной сети вместо всей группы ресурсов может предотвратить слишком ограничительную блокировку для других ресурсов в группе ресурсов. Из-за этих соображений следует определить приоритет блокировки ресурсов, которые при изменении или удалении могут привести к наибольшему нарушению.
Блокировки также могут учитывать показатели целевого времени восстановления при переключении рабочих нагрузок. План аварийного восстановления должен учитывать блокировки, и у вас должна быть проверенная процедура удаления блокировок контролируемым образом. Вам потребуется обучить администраторов и сотрудников SecOps по управлению блокировками в рамках повседневных операций и чрезвычайных ситуаций.
Администраторы с доступом к удалению блокировок должны быть ограничены и должны включать JIT-доступ, такой как предоставленный Microsoft Entra управление привилегированными пользователями. Доступ к блокировкам изменений для ресурсов управляется областью Microsoft.Authorization/locks/* и не должен предоставляться в рамках постоянного доступа.
А. Защита виртуальных машин
Для рабочих нагрузок на основе виртуальных машин, включая масштабируемые наборы и кластеры Kubernetes, необходимо запланировать два уровня защиты в дополнение к использованию блокировок ресурсов в плоскости управления.
Сначала необходимо спланировать резервное копирование данных из виртуальных машин, чтобы можно было восстановить потерянные данные при возникновении атаки, которая включает Служба Azure Kubernetes (AKS). Также необходимо защитить сами резервные копии данных от атак с помощью механизмов обратимого удаления. Дополнительные сведения о настройке резервных копий см. в статье:
- Создание и настройка хранилища служб восстановления
- Резервное копирование виртуальной машины в Azure
- Настройка резервного копирования для кластера Служба Azure Kubernetes
- Резервное копирование и восстановление для AKS
- План резервного копирования и восстановления для защиты от программ-шантажистов
- Мягкое удаление для Azure Backup
Во-вторых, необходимо запланировать возможность восстановления сервера в новом расположении при атаке базовой инфраструктуры в вашем регионе. Сведения о настройке репликации на виртуальных машинах см. в статье "Настройка аварийного восстановления для виртуальных машин Azure". Это включает конфигурацию приложений и параметров для ресурсов, используемых при переключении на резерв.
Внимание
При использовании Azure Site Recovery для виртуальных машин, входящих в масштабируемый набор виртуальных машин, можно реплицировать состояние виртуальной машины. Однако реплицированные устройства не поддерживают масштабирование.
Для некоторых рабочих нагрузок на основе виртуальных машин, таких как кластеры Kubernetes, фактическое состояние серверов невозможно реплицировать через Azure Site Recovery. Вам могут потребоваться другие решения, такие как активная или пассивной конфигурация.
B. Защита служб данных
Службы данных — это неформальная коллекция служб, содержащих данные, необходимые для операций, но сам ресурс не так важен. Например, между двумя учетными записями хранения, настроенными одинаковым образом и содержащими одни и те же данные, почти нет разницы.
Службы данных отличаются от виртуальных машин, которые могут иметь конфигурации операционной системы отдельно от работающих приложений, и от конфигурации плоскости управления. В результате эти службы:
- Часто содержат собственные инструменты аварийного восстановления, такие как возможность репликации данных в другой регион в рамках геоизбыточного уровня хранения (GRS).
- Имеют свои собственные соображения по защите данных от атак и восстановлению данных в случае атаки.
В следующей таблице приведены ссылки на защиту данных и ссылки на доступность для часто используемых служб, но следует изучить документацию по продукту каждой службы, чтобы понять доступные варианты.
Предупреждение
Некоторые сценарии восстановления учетной записи хранения не поддерживаются. Дополнительные сведения см. в статье о не поддерживаемом восстановлении хранилища.
C. Защита инфраструктуры восстановления
Помимо защиты ресурсов на рабочих нагрузках, необходимо также защитить ресурсы, используемые для восстановления функциональных возможностей после сбоя, таких как документация по процедурам восстановления и скрипты конфигурации и шаблоны. Если злоумышленники могут атаковать и нарушить функционирование инфраструктуры восстановления, вся среда может быть скомпрометирована, что приведет к значительным задержкам в восстановлении после атаки и оставит вашу организацию уязвимой для сценариев программ-шантажистов.
Для данных, защищенных с помощью Azure Backup, использование функции мягкого удаления позволяет восстановить данные резервного копирования даже после удаления. Кроме того, расширенное мягкое удаление включает в себя принудительное применение мягкого удаления и позволяет определить период хранения.
Чтобы повысить безопасность, реализуйте многопользовательскую авторизацию (MUA) для критически важных операций, что требует, чтобы два или более пользователей одобрили критически важные операции перед выполнением. Это добавляет дополнительный уровень безопасности, гарантируя, что ни один пользователь, а значит, злоумышленник с одной лишь учетной записью, не может компрометировать целостность резервного копирования. Включите и настройте muA для защиты политик резервного копирования от несанкционированных изменений и удалений.
Вы можете защитить Azure Site Recovery с помощью блокировок ресурсов и доступа JEA/JIT, чтобы предотвратить несанкционированный доступ и обнаружение, когда ресурсы находятся под угрозой.
При репликации виртуальных машин с помощью Azure Site Recovery, зашифрованных с помощью Шифрование дисков Azure (ADE) или управляемых клиентом ключей (CMK), убедитесь, что ключи шифрования хранятся в Azure Key Vault для целевого региона. Хранение ключей в целевом регионе упрощает доступ к ключам после аварийного переключения и обеспечивает сохранение уровня безопасности данных. Чтобы защитить Azure Key Vault от разрушительных кибератак, включите расширенные функции защиты от угроз, такие как обратимое удаление и очистка защиты.
Пошаговые инструкции по репликации зашифрованных виртуальных машин см. в следующих статьях:
D. Защита служб на основе конфигурации
Службы на основе конфигурации — это службы Azure, которые не имеют данных, кроме их конфигурации в плоскости управления. Эти ресурсы обычно основаны на инфраструктуре и являются базовыми службами, поддерживающими рабочие нагрузки. Примерами являются виртуальные сети, подсистемы балансировки нагрузки, сетевые шлюзы и шлюзы приложений.
Поскольку эти службы являются без состояния, не существует операционных данных, которые нужно защищать. Лучший вариант защиты этих служб — иметь infrastructure as code (IaC) deployment шаблоны, такие как 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
Следующие шаги
Продолжайте реализовывать инфраструктуру предотвращения нарушений безопасности и восстановления.
Ссылки
Ознакомьтесь с этими ссылками, чтобы узнать о различных службах и технологиях, упомянутых в этой статье.