Изменить

Поделиться через

Автоматизация интеграции Sentinel с Azure DevOps

Microsoft Entra ID
Azure DevOps
Azure Key Vault
Microsoft Defender для облака
Microsoft Sentinel

В этой статье описывается автоматизация операций интеграции и развертывания Microsoft Sentinel с помощью Azure DevOps. Вы реализуете Azure DevOps с помощью возможностей Microsoft Sentinel для защиты развертывания. Затем вы используете платформу DevSecOps для управления и развертывания артефактов Microsoft Sentinel в масштабе.

Архитектура

На следующей схеме показана настройка Azure DevOps и Microsoft Sentinel IaC.

Схема, показывающая архитектуру для автоматизации инфраструктуры Microsoft Sentinel в качестве конвейера кода.

Скачайте файл Visio для этой архитектуры.

Поток данных

  1. Главный и управление продуктами scrum используют Azure DevOps для определения эпических, пользовательских историй и элементов невыполненной работы продукта в рамках невыполненной работы проекта.
    • Мастер scrum и управление продуктами используют Azure Boards для создания невыполненной работы, планирования работы в спринтах, просмотра доска проекта, создания структуры репозитория и настройки правил безопасности, таких как рабочие процессы утверждения и ветви.
    • Репозиторий Azure Git хранит скрипты и разрешения на управление артефактами Microsoft Sentinel в инфраструктуре в виде кода.
    • Артефакты и управление версиями поддерживают расширения и пакеты обновления или компоненты рабочего процесса DevSecOps, которые используются в решении, например Набор средств шаблонов Azure Resource Manager и PowerShell Pester.
  2. Артефакты Microsoft Sentinel:
    • Политики. Инженеры SIEM используют политики Azure в эталонной архитектуре для настройки и масштабирования параметров диагностики служб Azure. Политики помогают автоматизировать развертывание соединителей данных Microsoft Sentinel, таких как Azure Key Vault. Политики зависят от API OMSIntegration.
    • Соединители. Microsoft Sentinel использует логические соединители, соединители данных Azure для приема данных безопасности, как в аудитах или метриках, из поддерживаемых источников данных, таких как Идентификатор Microsoft Entra, ресурсы Azure, Microsoft Defender или сторонние решения. Основной список соединителей данных управляется API SecurityInsights. Другие используют API OMSIntegration и управляются с помощью параметров диагностики Политика Azure.
    • Управляемое удостоверение. Microsoft Sentinel использует управляемое удостоверение для действий от имени управляемого удостоверения службы (MSI) при взаимодействии с сборниками схем, приложениями логики или модулями Runbook автоматизации и хранилищем ключей.
    • Автоматизация. Команды SOC используют автоматизацию во время исследований. Команды SOC выполняют процедуры получения данных цифровой судебной экспертизы с служба автоматизации Azure, например цепочкой хранения виртуальных машин Azure или обнаружения электронных данных (Премиум) для Microsoft Defender.
    • Аналитика. Аналитики SOC или охотники за угрозами используют встроенные или пользовательские правила аналитики для анализа и сопоставления данных в Microsoft Sentinel или активации сборников схем, если обнаружена угроза и инцидент.
    • Сборники схем. Приложения логики выполняют повторяющиеся действия SecOps, такие как назначение инцидента, обновление инцидента или выполнение действий по исправлению, например изоляция или добавление виртуальной машины, отзыв маркера или сброс пароля пользователя.
    • Поиск угроз. Охотники за угрозами используют упреждающие возможности поиска угроз, которые могут быть связаны с записными книжками Jupyter для расширенных вариантов использования, таких как обработка данных, обработка данных, визуализация данных, машинное обучение или глубокое обучение.
    • Книги. Инженеры SIEM используют панели мониторинга книг для визуализации тенденций и статистики и просмотра состояния экземпляра Microsoft Sentinel и его подкомпонов.
    • Threat Intelligence. Определенный соединитель данных, который использует платформы аналитики угроз, передается в Microsoft Sentinel. Поддерживаются два метода подключения: TAXII и API Graph. Оба метода служат индикаторами tiIndicator или индикаторами аналитики угроз в API безопасности.
  3. Идентификатор Microsoft Entra. Возможности управления удостоверениями и доступом предоставляются компонентам, которые используются в эталонной архитектуре, таких как управляемые удостоверения, субъекты-службы, элементы управления доступом на основе ролей Azure (RBACs) для Microsoft Sentinel, приложения логики и модули Runbook автоматизации.
  4. Azure Pipelines. Инженеры DevOps используют конвейеры для создания подключений к службе для управления различными подписками Azure, такими как песочница и рабочие среды с непрерывной интеграцией и конвейерами непрерывной доставки (CI/CD). Мы рекомендуем использовать рабочие процессы утверждения, чтобы предотвратить непредвиденные развертывания и разделенные субъекты-службы, если вы нацелены на несколько подписок на среду Azure.
  5. Azure Key Vault. Инженеры SOC используют хранилище ключей для безопасного хранения секретов и сертификатов субъекта-службы. Этот компонент архитектуры помогает применить принцип DevSecOps без секретов в коде при использовании подключений службы Azure Pipeline.
  6. Подписка Azure. Команды SOC используют два экземпляра Microsoft Sentinel в этой эталонной архитектуре, разделенные в двух логических подписках Azure для имитации рабочих и изолированных сред. Вы можете масштабировать свои потребности с другими средами, такими как тестирование, разработка, предварительная подготовка и т. д.

Пример потока данных

  1. Администратор добавляет, обновляет или удаляет запись в вилке файла конфигурации Microsoft 365.
  2. Администратор фиксирует и синхронизирует изменения в своем вилку репозитория.
  3. Затем администратор создает запрос на вытягивание (PR), чтобы объединить изменения в основной репозиторий.
  4. Конвейер сборки выполняется на pr.

Компоненты

  • Идентификатор Microsoft Entra — это мультитенантная облачная служба для управления удостоверениями и элементами управления доступом.
  • Azure DevOps — это облачная служба для совместной работы над кодом, сборкой и развертыванием приложений или планированием и отслеживанием работы.
  • Azure Key Vault — это облачная служба для безопасного хранения и получения доступа к секретам. Секрет — это то, к чему необходимо строго контролировать доступ, например ключи API, пароли или криптографические ключи.
  • Политика Azure — это служба для создания, назначения и управления определениями политик в среде Azure.
  • Microsoft Sentinel — это масштабируемое, облачное решение, SIEM и оркестрация безопасности, автоматизация и ответ (SOAR).
  • служба автоматизации Azure — это служба для упрощения управления облаком с помощью автоматизации процессов. Используйте служба автоматизации Azure для автоматизации длительных, ручных, ошибок и часто повторяющихся задач. Автоматизация помогает повысить надежность, эффективность и время для ценности вашей компании.

Подробности сценария

Команды центра безопасности (SOC) иногда сталкиваются с проблемами при интеграции Microsoft Sentinel с Azure DevOps. Процесс включает в себя множество шагов, а настройка может занять несколько дней и включать повторение. Эту часть разработки можно автоматизировать.

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

В этой статье описывается автоматизация операций интеграции и развертывания Microsoft Sentinel с помощью Azure DevOps. Вы можете расширить решение для сложных организаций с несколькими сущностями, подписками и различными операционными моделями. Некоторые операционные модели, поддерживаемые этим решением, включают локальный SOC, глобальный SOC, поставщик облачных служб (CSP) и поставщик управляемых служб безопасности (MSSP).

Эта статья предназначена для следующих аудиторий:

  • Специалисты SOC, такие как аналитики и охотники за угрозами
  • Инженеры по управлению безопасностью и событиями (SIEM)
  • Архитекторы кибербезопасности
  • Разработчикам

Потенциальные варианты использования

Ниже приведены типичные варианты использования для этой архитектуры:

  • Быстрое прототипирование и доказательство концепции. Это решение идеально подходит для организаций безопасности и команд SOC, которые хотят улучшить покрытие облачных угроз или модернизировать инфраструктуру SIEM с помощью инфраструктуры в виде кода (IaC) и Microsoft Sentinel.
  • Microsoft Sentinel как услуга. Эта платформа разработки интегрирует принципы управления жизненным циклом службы. Эти принципы подходят для простых или сложных команд, таких как MSSPs, которые выполняют повторяющиеся, стандартизированные действия в нескольких клиентах при сочетании возможностей Azure DevOps и Azure Lighthouse. Например, команда, которая должна публиковать варианты использования Microsoft Sentinel для нового субъекта угроз или текущей кампании, может использовать это решение.
  • Создание вариантов использования SOC для обнаружения угроз. Многие группы и платформы аналитики угроз полагаются на содержимое MITRE Attck и таксономию для анализа их состояния безопасности в отношении расширенных торговых параметров или методов и тактики. Решение определяет структурированный подход для разработки методик обнаружения угроз, включив терминологию MITRE Attck в разработку артефактов Microsoft Sentinel.

На следующем рисунке показан облачный сценарий MITRE Attck.

Схема облачного сценария MITRE Attck.

Скачайте файл Visio для этой архитектуры.

Сценарии атак определения угроз на основе MITRE

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

Элемент данных Description Артефакты Microsoft Sentinel
Заголовок Описательное имя сценария атаки на основе характеристик вектора атаки или описания методов. Манифест MITRE
Тактики MITRE ATT&CK Тактика MITRE ATT&CK, связанная с сценарием атаки Манифест MITRE
Методы MITRE ATT&CK Методы MITRE ATT&CK, включая метод или идентификатор подтехники, связанные с сценарием атаки. Манифест MITRE
Источники соединителя данных Источник информации, собираемой датчиком или системой ведения журнала, которая может использоваться для сбора сведений, относящихся к выявлению выполняемых действий, последовательности действий или результатов этих действий злоумышленником. Соединитель данных Microsoft Sentinel или Пользовательский источник журнала
Description Сведения о технике, о том, что это, что он обычно использует, как злоумышленник может воспользоваться им, и варианты того, как он может быть использован. Содержит ссылки на авторитетные статьи, описывающие технические сведения, связанные с техникой, а также в ссылках на дикое использование соответствующим образом.
Detection Высокоуровневый аналитический процесс, датчики, данные и стратегии обнаружения, полезные при определении техники, используемой злоумышленником. В этом разделе содержатся сведения об обнаружении поведения злоумышленников, таких как сетевые защитники, чтобы они могли предпринять такие действия, как написание аналитики или развертывание датчика. Должно быть достаточно информации и ссылок, чтобы указать на полезные оборонительные методологии. Обнаружение может не всегда быть возможным для определенной техники и должно быть задокументировано таким образом. Поиск угроз аналитики
Исправление Конфигурации, инструменты или процессы, которые препятствуют работе или получению желаемого результата для злоумышленника. В этом разделе содержатся сведения о том, кто несет ответственность за устранение последствий для злоумышленников, таких как сетевые защитники или политики, чтобы позволить им принять меры, такие как изменение политики или развертывание инструмента. Устранение рисков может не всегда быть возможным для определенного метода и должно быть задокументировано как таковое.
Исправление Конфигурации, инструменты или процессы, которые препятствуют работе или получению желаемого результата для злоумышленника. В этом разделе описывается, как уменьшить последствия атак злоумышленников для сетевых защитников или политиков. В ней рассматриваются действия по изменению политики или развертыванию средства. Устранение рисков может не всегда быть возможным для определенной техники и должно быть задокументировано таким образом. Сборники схем, модули Runbook автоматизации

Рекомендации

Эти рекомендации реализуют основные принципы платформы Azure Well-Architected Framework, набор руководящих принципов, которые можно использовать для улучшения качества рабочей нагрузки. Дополнительные сведения см. в статье Microsoft Azure Well-Architected Framework.

Безопасность

Безопасность обеспечивает гарантии от преднамеренного нападения и злоупотребления ценными данными и системами. Дополнительные сведения см. в разделе "Общие сведения о компоненте безопасности".

С точки зрения безопасности автоматизация повышает эффективность операций при экономии времени для более сложных вариантов использования, таких как проектирование обнаружения угроз, аналитика угроз, SOC и варианты использования SOAR. Команды DevOps должны знать, где они могут безопасно использовать IaC в контексте CI/CD Microsoft Sentinel. В этом процессе описывается использование определенных удостоверений, используемых учетными записями, не являющихся людьми, в идентификаторе Microsoft Entra, называемом субъектами-службами и управляемыми удостоверениями.

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

Вариант использования Требования (наименьшие привилегии) Длительность назначения ролей Область разрешений Попечитель Вопросы безопасности
Включение соединителей Microsoft Sentinel Администратор безопасности**

Владелец*

Участник Microsoft Sentinel

Читатель		 JIT (однократная активация)

По назначению (каждый раз при развертывании новой подписки и соединителя)		 Клиент имя участника-службы Используйте хранилище ключей для хранения секретов и сертификатов субъекта-службы.

Включите аудит имени участника-службы.

Периодически просмотрите назначение разрешений (Azure управление привилегированными пользователями для имени участника-службы) или подозрительные действия для имени субъекта-службы.

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

Используйте пользовательские роли Microsoft Entra для более детальной детализации.
Развертывание артефактов Microsoft Sentinel, таких как книги, аналитика, правила, запросы поиска угроз, записные книжки и сборники схем Участник Microsoft Sentinel
Участник Logic Apps		 Постоянный Рабочая область или группа ресурсов Microsoft Sentinel имя участника-службы Используйте утверждение рабочего процесса Azure DevOps (ADO) и проверка для защиты развертывания конвейера с помощью этого имени субъекта-службы.
Назначение политики для настройки функций потоковой передачи журналов в Microsoft Sentinel Участник политики ресурсов ** По назначению (каждый раз при развертывании новой подписки и соединителя) Все подписки для отслеживания имя участника-службы Используйте идентификатор Microsoft Entra, ЦС и MFA при поддержке для привилегированных учетных записей.

* Касается только параметров Microsoft Entra диагностика.
** Для конкретных соединителей требуются дополнительные разрешения, такие как "администратор безопасности" или "участник политики ресурсов", чтобы разрешить потоковую передачу данных в рабочую область Microsoft Sentinel, идентификатор Microsoft Entra ID, Microsoft 365 или Microsoft Defender и платформу как службу (PaaS), такие как Azure Key Vault.

Модель привилегированного доступа

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

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

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

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

Схема многоуровневой архитектуры для модели привилегированного доступа в конвейере.

Субъекты-службы уровня 0

Субъекты-службы уровня 0 имеют самый высокий уровень разрешений. Эти субъекты-службы имеют право на выполнение задач администрирования группы управления на уровне клиента или корневой группы управления в качестве глобального администратора.

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

Храните секрет или сертификат для этой учетной записи безопасно в Azure Key Vault. Мы настоятельно рекомендуем при возможности найти хранилище ключей в выделенной административной подписке.

Субъекты-службы уровня 1

Субъекты-службы уровня 1 — это повышенные разрешения, ограниченные и ограниченные для групп управления на уровне организации. Эти субъекты-службы имеют право на создание подписок в группе управления, которая находится в области.

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

Храните секрет или сертификат для этой учетной записи безопасно в Azure Key Vault. Мы настоятельно рекомендуем при возможности найти хранилище ключей в выделенной административной подписке.

Субъекты-службы уровня 2

Субъекты-службы уровня 2 ограничены уровнем подписки. Эти субъекты-службы имеют право выполнять административные задачи в подписке, выступая в качестве владельца подписки.

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

Храните секрет или сертификат для этой учетной записи безопасно в Azure Key Vault. Настоятельно рекомендуется найти хранилище ключей в выделенной группе административных ресурсов.

Субъекты-службы уровня 3

Субъекты-службы уровня 3 ограничены администратором рабочей нагрузки. В типичном сценарии каждая рабочая нагрузка содержится в одной группе ресурсов. Эта структура ограничивает разрешения субъекта-службы только этой группе ресурсов.

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

Храните секрет или сертификат для этой учетной записи безопасно в Azure Key Vault. Настоятельно рекомендуется найти хранилище ключей в выделенной группе административных ресурсов.

Субъекты-службы уровня 4

Субъекты-службы уровня 4 имеют самые ограниченные разрешения. Эти субъекты-службы имеют право выполнять административные задачи, ограниченные одним ресурсом.

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

Эффективность работы

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

Решения Microsoft Sentinel состоят из трех блоков, которые обеспечивают выполнение и успешное выполнение операций.

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

Второй блок — это развертывание соединителя Microsoft Sentinel, в котором рассматривается тип соединителей, необходимых вашей команде, и требования к безопасности для их включения.

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

Рассмотрим эти зависимости между артефактами:

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

Сборка, тестирование и развертывание инфраструктуры

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

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

  • Размещенные агенты Майкрософт Этот параметр является самым быстрым способом работы с агентами Azure DevOps, так как это общая инфраструктура для всей организации. Дополнительные сведения об использовании размещенных корпорацией Майкрософт агентов в конвейере см. в разделе "Размещенные корпорацией Майкрософт агенты". Размещенные корпорацией Майкрософт агенты могут работать в гибридных сетевых средах, предоставляя доступ к диапазонам IP-адресов. Чтобы скачать диапазоны IP-адресов, к которым эти агенты предоставляют доступ, см. статью "Диапазоны IP-адресов Azure" и теги служб — общедоступное облако.
  • Локальные агенты. Этот параметр предоставляет выделенные ресурсы и больше управления при установке зависимого программного обеспечения для сборок и развертываний. Локальные агенты могут работать над виртуальными машинами, масштабируемыми наборами и контейнерами в Azure. Дополнительные сведения об локальных агентах см. в статье об агентах Azure Pipelines.

GitHub runners

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

Средства выполнения тестов, размещенные в GitHub

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

Локальные средства выполнения тестов

Этот параметр предоставляет вашей компании выделенную инфраструктуру ресурсов. Локальные средства выполнения работают над виртуальными машинами и контейнерами в Azure и поддерживают автоматическое масштабирование.

Рекомендации по выбору runners

При выборе параметров агентов и средств выполнения в решении Microsoft Sentinel рассмотрите следующие потребности:

  • Требуется ли вашей компании выделенные ресурсы для выполнения процессов в средах Microsoft Sentinel?
  • Вы хотите изолировать ресурсы для действий DevOps рабочей среды от остальных сред?
  • Необходимо ли протестировать определенные случаи, требующие доступа к критически важным ресурсам или ресурсам, доступным только во внутренней сети?

Оркестрация и автоматизация процессов выпуска

Процесс развертывания можно настроить с помощью Azure DevOps или GitHub. Azure DevOps поддерживает использование конвейера YAML или конвейера выпуска. Дополнительные сведения об использовании конвейера YAML в Azure DevOps см. в статье "Использование Azure Pipelines". Дополнительные сведения об использовании конвейера выпуска в Azure DevOps см. в разделе "Конвейеры выпуска". Дополнительные сведения об использовании GitHub с GitHub Actions см. в разделе "Общие сведения о действиях GitHub".

Azure DevOps

В развертывании Azure DevOps можно выполнить следующие действия развертывания.

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

GitHub

В развертывании GitHub можно выполнить следующие действия развертывания.

  • Используйте GitHub для создания PR или действий развертывания.
  • Управление учетными данными субъекта-службы с помощью секретов GitHub.
  • Интеграция утверждения развертывания с помощью рабочего процесса, связанного с GitHub.

Автоматическое развертывание с помощью инфраструктуры Microsoft Sentinel

Вы можете развернуть одну или несколько сред Microsoft Sentinel в зависимости от корпоративной архитектуры:

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

Определения физической и логической среды

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

  • Физическое определение — элементы архитектуры Microsoft Sentinel определяются следующими параметрами инфраструктуры в виде кода (IaC):
    • Шаблоны Bicep
    • шаблоны Azure Resource Manager (шаблоны ARM);
    • Terraform
  • Логическое определение — это уровень абстракции для настройки разных команд в группе и определения их сред. Определение устанавливается в конвейере развертывания и рабочих процессах в качестве входных данных для среды сборки с помощью физического уровня инфраструктуры.

При определении логических сред следует учитывать следующие моменты:

  • Соглашения об именах
  • Идентификация среды
  • Соединители и конфигурации

Репозиторий кода

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

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

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

Схема возможной организации кода в GitHub для определения физической среды.

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

Вы можете адаптировать стратегию ветвления и объединения в стратегию развертывания для каждой организации. Если ваша команда должна начать с определения, см . статью "Внедрение стратегии ветвления Git".

Дополнительные сведения о шаблонах ARM см. в статье "Использование связанных и вложенных шаблонов при развертывании ресурсов Azure".

Дополнительные сведения о настройке сред Bicep см. в разделе "Установка средств Bicep". Дополнительные сведения о GitHub см . в потоке GitHub.

Логические определения определяют среды компании. Репозиторий Git собирает различные определения для компании.

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

Схема возможной организации кода в GitHub для определения логической среды.

Репозиторий отражает действия PR, выполненные различными командами. Несколько сред определяются различными командами и утверждены владельцами или утверждателями компании.

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

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

Автоматическая настройка соединителей Microsoft Sentinel

Соединители Microsoft Sentinel являются важной частью решения, которое поддерживает подключение к различным элементам в ландшафте корпоративной архитектуры, таких как Идентификатор Microsoft Entra, Microsoft 365, Microsoft Defender, решения платформы аналитики угроз и т. д.

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

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

Сценарий соединителя Уровень модели привилегированного доступа Минимальные привилегии Azure Требуется утверждение рабочего процесса
Microsoft Entra ID Уровень 0 глобальный администратор или администратор безопасности Рекомендуемая конфигурация
Защита идентификации Microsoft Entra Уровень 0 глобальный администратор или администратор безопасности Рекомендуемая конфигурация
Microsoft Defender для удостоверений Уровень 0 глобальный администратор или администратор безопасности Рекомендуемая конфигурация
Microsoft Office 365 Уровень 0 глобальный администратор или администратор безопасности Рекомендуемая конфигурация
Microsoft Cloud App Security Уровень 0 глобальный администратор или администратор безопасности Рекомендуемая конфигурация
Microsoft Defender XDR Уровень 0 глобальный администратор или администратор безопасности Рекомендуемая конфигурация
Microsoft Defender для IOT Уровень 2 Участник Рекомендуемая конфигурация
Microsoft Defender для облака Уровень 2 Читатель сведений о безопасности Необязательно
Действие Azure Уровень 2 Читатель подписки Необязательно
Платформы аналитики угроз Уровень 0 глобальный администратор или администратор безопасности Рекомендуемая конфигурация
События безопасности Уровень 4 нет Необязательно
Системный журнал Уровень 4 нет Необязательно
DNS (предварительная версия) Уровень 4 нет Необязательно
Брандмауэр Windows Уровень 4 нет Необязательно
события безопасности Windows, использующие AMA; Уровень 4 нет Необязательно

Развертывание артефактов Microsoft Sentinel

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

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

Для развертывания артефактов Microsoft Sentinel и управления ими требуется использование REST API Microsoft Sentinel. Дополнительные сведения см. в разделе REST API Microsoft Sentinel. На следующей схеме показан конвейер Azure DevOps в стеке REST API Azure.

Схема конвейера Azure DevOps в стеке API Microsoft Sentinel.

Вы также можете реализовать репозиторий с помощью PowerShell.

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

Например, если вы создаете новую сборник схему с помощью шаблона Azure ARM и имя файла Playbook.arm.json, добавьте JSON-файл с именем Playbook.arm.mitre.json. Затем метаданные этого файла включают форматы CSV, JSON или YAML, соответствующие тактике или методам MITRE, которые используются.

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

Артефакты сборки

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

Схема процесса сборки Microsoft Sentinel.

Скачайте файл Visio для этой архитектуры.

  • Определение артефакта можно на основе описательной схемы в формате JSON или YAML, а затем проверить схему, чтобы избежать синтаксической ошибки.
    • Проверьте шаблоны ARM с помощью набора средств тестирования шаблонов ARM.
    • Проверьте файлы YAML и JSON для пользовательских моделей с помощью PowerShell.
  • Проверьте параметры списка отслеживания и убедитесь, что записи безклассной маршрутизации между доменами (CIDR), определяемые правильной схемой, например 10.1.0.0/16.
  • Используйте запросы языка запросов ключевых слов (KQL), которые можно проверить на уровне синтаксиса, для аналитических правил, правил охоты и динамических потоковых правил, которые можно проверить на уровне синтаксиса.
  • Выполните локальную проверку KQL одним из вариантов.
  • Интегрируйте средство встроенной проверки KQL в конвейер DevOps.
  • Если вы реализуете логику, основанную на PowerShell для служба автоматизации Azure, можно включить проверку синтаксиса и модульное тестирование с помощью следующих элементов:
  • Создайте отчет метаданных манифеста MITRE на основе файлов метаданных, включенных в артефакты.

Экспорт артефактов

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

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

Схема, на которой показан процесс извлечения артефактов Microsoft Sentinel.

Скачайте файл Visio для этой архитектуры.

Развертывание артефактов

Целями процесса развертывания являются следующие задачи.

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

Команды разработчиков используют этот процесс, чтобы гарантировать, что они могут развертывать, тестировать и проверять варианты использования артефактов, которые находятся в процессе разработки. Команды архитектуры и SOC проверяют качество конвейера в средах QA и работают с тестами интеграции для сценариев атак. В тестовых случаях команда обычно объединяет различные артефакты как аналитические правила, сборники схем исправления, списки наблюдения и т. д. Часть каждого варианта использования включает имитацию атак, в которых вся цепочка оценивается от приема, обнаружения и исправления.

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

Схема, на которой показан процесс развертывания артефактов Microsoft Sentinel.

Скачайте файл Visio для этой архитектуры.

Управление артефактами Sentinel в виде кода предлагает гибкие способы поддержания операций и автоматизации развертывания в конвейере CI/CD DevOps.

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

Артефакт Рабочие процессы автоматизации
Списки отслеживания Проверка кода
Проверка схемы

Развертывание
Создание, обновление, удаление списков отслеживания и элементов
Слияние правил аналитики
Microsoft Security
Аналитика поведения машинного обучения
Аномалия
Запланированные		 Проверка кода
Проверка синтаксиса KQL
Проверка схемы
Pester

Развертывание
Создание, включение, обновление, удаление, экспорт
Поддержка шаблонов оповещений
Правила автоматизации Проверка кода
Проверка схемы

Развертывание
Создание, включение, обновление, удаление, экспорт
Соединители Проверка кода
Проверка схемы

Развертывание
Действия: включение, удаление (отключение), обновление
Правила охоты Проверка кода
Проверка синтаксиса KQL
Проверка схемы
Pester

Развертывание
Действия: создание, включение, обновление, удаление, экспорт
Сборники схем Проверка кода
TTK

Развертывание
Действия: создание, включение, обновление, удаление, экспорт
Workbooks Развертывание
Действия: создание, обновление, удаление
Модули runbook Проверка кода
Проверка синтаксиса PowerShell
Pester

Развертывание
Действия: создание, включение, обновление, удаление, экспорт

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

Схема поддерживаемых возможностей автоматизации.

* Функции разработки, которые еще не описаны
** Методы автоматизации, поддерживаемые API-интерфейсами поставщиков ресурсов Microsoft Operations Insights или Microsoft Insights

Azure Automation

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

Схема упрощения доступа Microsoft Sentinel с помощью управляемого удостоверения службы.

Скачайте файл Visio для этой архитектуры.

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

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

  • Интеграция с сторонними решениями, где требуются различные уровни учетных данных и основаны на идентификаторе Microsoft Entra или пользовательских учетных данных:
    • Учетные данные пользователя Microsoft Entra
    • Учетные данные субъекта-службы Microsoft Entra
    • Проверка подлинности на основе сертификата
    • Пользовательские учетные данные
    • Управляемое удостоверение
  • Реализация решения, которое повторно использует сценарии организации или решения, требующие использования команд PowerShell, чтобы избежать сложного перевода в сборники схем:
    • Решения на основе PowerShell
    • Решения на основе Python
  • Реализация решений в гибридных сценариях, где действия по исправлению могут повлиять на облачные и локальные ресурсы.

Репозитории Microsoft Sentinel

Опытные команды DevOps могут рассмотреть возможность управления Microsoft Sentinel в инфраструктуре как код (IaC) с конвейерами CI/CD, встроенными в Azure DevOps. Группы продуктов понимают проблемы, с которыми сталкиваются клиенты и партнеры при создании архитектуры безопасности Azure DevOps, поэтому следующие две инициативы могут помочь:

  • Документирование эталонной архитектуры
  • Разработка нового решения, объявленного в Ignite 2021, которая называется "Microsoft Sentinel Repositories"

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

Вариант использования и функции Пользовательский подход к Azure DevOps и GitHub Репозитории Microsoft Sentinel
Мы хотим быстро начать развертывание артефактов Microsoft Sentinel без определения компонентов архитектуры Azure DevOps, таких как агенты, конвейеры, Git, панели мониторинга, вики-сайт, субъекты-службы, RBACs, аудит и т. д. Не рекомендуется Рекомендуемая конфигурация
У нас есть небольшие команды и наборы навыков для управления конвейерами CI/CD. Не рекомендуется Рекомендуемая конфигурация
Мы хотим контролировать и управлять всеми аспектами безопасности конвейеров CI/CD. Поддерживается Не поддерживается
Необходимо интегрировать шлюзы и ветвления для контроля интеграции, прежде чем позволить разработчикам запускать конвейеры развертывания, такие как управление версиями, проверка кода, откат, утверждение рабочего процесса и т. д. Поддерживается Частично поддерживается
У нас есть настраиваемая структура Git или репозитория. Поддерживается Поддерживается
Для создания артефактов не используются языки Resource Manager или Bicep IaC. Поддерживается Не поддерживается
Мы хотим централизованно управлять развертыванием артефактов в нескольких рабочих областях Microsoft Sentinel в одном клиенте Microsoft Entra. Поддерживается Поддерживается
Мы хотим интегрировать или расширить конвейеры CI/CD в нескольких клиентах Microsoft Entra. Поддерживается Поддерживается
У нас есть сборники схем с разной параметризацией в зависимости от подписки, расположения, среды и т. д. Поддерживается ТБD, рекомендации, которые необходимо задокументировать
Мы хотим интегрировать различные артефакты в одном репозитории для создания вариантов использования. Поддерживается Поддерживается
Мы хотим, чтобы возможность массового удаления артефактов. Поддерживается Не поддерживается

Доступность, производительность и масштабируемость

При выборе архитектуры для агентов Azure DevOps в вашей компании для сценариев Microsoft Sentinel учитывайте следующие потребности:

  • В рабочей среде может потребоваться выделенный пул агентов для операций в среде Microsoft Sentinel.
  • Непроизводственные среды могут совместно использовать пул агентов с большим количеством экземпляров для обработки различных требований от команд, в частности для практик CI/CD.
    • Сценарии моделирования атак — это особый случай, когда могут потребоваться выделенные агенты. Рассмотрим, необходим ли выделенный пул для тестирования.
  • Организации, работающие в сценариях гибридной сети, могут рассмотреть возможность интеграции агентов в сети.

Организации могут создавать собственные образы для агентов на основе контейнеров. Дополнительные сведения см. в разделе "Запуск локального агента" в Docker.

Управление между клиентами Microsoft Sentinel с помощью Azure DevOps

В качестве глобального SOC или MSSP может потребоваться управлять несколькими клиентами. Azure Lighthouse поддерживает масштабируемые операции в нескольких клиентах Microsoft Entra одновременно, что делает задачи управления более эффективными. Дополнительные сведения см. в обзоре Azure Lighthouse.

Управление между клиентами особенно эффективно в следующих сценариях:

Методы подключения клиентов

У вас есть два варианта подключения клиентов, предложение управляемой службы и шаблон ARM.

Подключение вручную с помощью шаблона ARM

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

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

Фактор предложение управляемой службы; Шаблоны ARM
Требуется учетная запись Центра партнеров Да Нет
Требуется уровень компетенции платформы Silver или Gold для облачной платформы или состояние поставщика управляемых служб Azure Expert (MSP) Да Нет
Доступно для новых клиентов через Azure Marketplace Да Нет
Может ограничить предложение конкретными клиентами Да (только с частными предложениями, которые нельзя использовать с подписками, установленными через торгового посредника программы CSP) Да
Требует принятия клиента на портале Azure Да Нет
Может использовать автоматизацию для подключения нескольких подписок, групп ресурсов или клиентов No Да
Обеспечивает немедленный доступ к новым встроенным ролям и функциям Azure Lighthouse Не всегда (обычно доступно после некоторой задержки) Да

Дополнительные сведения об публикации предложений управляемых служб см. в статье "Публикация предложения управляемой службы в Azure Marketplace".

Дополнительные сведения о создании шаблона ARM см. в статье "Создание и развертывание шаблонов ARM".

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

Схема, показывающая архитектуру управляемого удостоверения службы Microsoft Sentinel.

Скачайте файл Visio для этой архитектуры.

  1. Предложение MSP интегрировано с помощью шаблона ARM или предложения службы Azure Marketplace.
  2. Делегированное управление ресурсами Azure проверяет, является ли запрос от клиента партнера и вызывает поставщика ресурсов управляемой службы.
  3. Поставщик ресурсов управляемой службы использует RBAC для управления доступом MSP.
  4. MSP завершает действия SecOps в ресурсе клиента.
  5. Процесс выставления счетов рассматривает расходы как расходы на клиента. Разделение выставления счетов возможно, если сущности клиента имеют отдельные рабочие области в одном клиенте Microsoft Entra.
  6. Безопасность и суверенитет данных зависят от границы клиента.
Удостоверение между несколькими клиентами

Чтобы управлять Microsoft Sentinel с помощью Azure DevOps, оцените следующие решения по проектированию компонентов.

Вариант использования Плюсы
Глобальное удостоверение для управления действиями DevOps, одним субъектом-службой Этот случай относится к глобальным процессам развертывания, которые включают все клиенты.

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

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

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

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

Для консолидации изменений требуется установить процесс между репозиториями, которые могут потребовать усилий для поддержания.
Процессы сборки и развертывания
Вариант использования Плюсы
Единый процесс сборки для всех клиентов Когда все клиенты работают с одной и той же версией артефактов, это самый простой вариант для реализации создания и пакета.
Процесс сборки по клиенту Для каждого клиента развертывается другая версия кода.
Глобальный процесс развертывания для всех клиентов Новые развертывания и обновления для развертываний применяются ко всем клиентам. Этапы процессов развертывания и обновления используются для всех клиентов.
Глобальный клиент процесса развертывания по клиенту Новые развертывания и обновления для развертываний применяются к одному или нескольким клиентам.
Выделенный процесс развертывания по клиенту Процесс развертывания адаптирован для каждого клиента.

Оптимизация затрат

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

Стоимость решения зависит от следующих факторов:

  • Объем данных, передаваемых вашей компанией в рабочую область Microsoft Sentinel Log Analytics ежемесячно
  • Уровень обязательств или метод выставления счетов, который вы выбираете, например оплату по мере использования (PAYG)
  • Скорость хранения политик данных на уровне таблицы или глобального уровня

Дополнительные сведения см. в статье о хранении типов данных Azure.

Чтобы вычислить цены, см . калькулятор цен Microsoft Sentinel. Дополнительные сведения о дополнительных ценах и примерах см. в разделе "Планирование затрат на Microsoft Sentinel.".

Дополнительные затраты можно нести, если вы расширяете решение следующими компонентами:

  • Сборники схем — среды выполнения для Azure Logic Apps и Функции Azure. Дополнительные сведения см. в разделе о ценах.
  • Экспорт в внешнее хранилище, например Azure Data Explorer, Центры событий или учетную запись служба хранилища Azure.
  • Рабочая область машинного обучения и вычислительные ресурсы, которые использует компонент Jupyter Notebook.

Развертывание этого сценария

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

Создание и выпуск платформы Microsoft Sentinel

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

Если вы работаете с Azure DevOps, вы можете создать веб-канал компонентов для размещения различных пакетов NuGet из платформы Microsoft Sentinel для PowerShell. Дополнительные сведения см. в статье "Начало работы с пакетами NuGet".

Снимок экрана: создание веб-канала компонентов для размещения пакетов NuGet.

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

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

Снимок экрана: создание подключения к службе.

Снимок экрана: изменение подключения к службе.

После настройки веб-канала можно импортировать конвейер для создания платформы PowerShell непосредственно из GitHub в определенном вилке. Дополнительные сведения см. в разделе "Сборка репозиториев GitHub". В этом случае вы создадите новый конвейер и выберите GitHub в качестве источника кода.

Другой вариант — импортировать репозиторий Git в качестве репозитория Azure DevOps, основанного на Git. В обоих случаях для импорта конвейера укажите следующий путь:

src/Build/Framework/ADO/Microsoft.Sentinel.Framework.Build.yml

Теперь конвейер можно запустить в первый раз. Затем платформа создает и освобождает веб-канал NuGet.

Определение среды Microsoft Sentinel

Начиная с Microsoft Sentinel и используя эти примеры, определите среду в вашей компании, например среду как код или EaC. Вы указываете различные элементы, составляющие среду в каждом случае.

Архитектура Microsoft Sentinel включает следующие элементы в Azure:

  • Рабочая область Log Analytics — эта рабочая область формирует основу решения. Сведения, связанные с безопасностью, хранятся здесь, а рабочая область — это механизм язык запросов Kusto (KQL).
  • Решение Microsoft Sentinel в рабочей области Log Analytics. Это решение расширяет функциональные возможности рабочей области Log Analytics, чтобы включить возможности SIEM и SOAR.
  • Key Vault — хранилище ключей сохраняет секреты и ключи, используемые во время процессов исправления.
  • Учетная запись службы автоматизации — эта учетная запись является необязательной и используется для процессов исправления. Используемый процесс исправления основан на модулях Runbook PowerShell и Python. Процесс включает в себя управляемое системой удостоверение, которое работает с различными ресурсами в соответствии с рекомендациями.
  • Управляемое пользователем удостоверение . Эта функция выступает в качестве единого слоя удостоверений Microsoft Sentinel, который управляет взаимодействием между сборниками схем Microsoft Sentinel и модулями Runbook.
  • Подключения приложения логики— это подключения для Microsoft Sentinel, хранилища ключей и автоматизации, использующих управляемое пользователем удостоверение.
  • Подключения к внешнему приложению логики — это подключения для внешних ресурсов, участвующих в процессах исправления и основанных на сборниках схем.
  • Центры событий Azure. Эта функция является необязательной и обрабатывает интеграцию между Microsoft Sentinel и другими решениями, такими как Splunk, Azure Databricks и машинное обучение, и отказоустойчивость.
  • Учетная запись хранения. Эта функция является необязательной и обрабатывает интеграцию между Microsoft Sentinel и другими решениями, такими как Splunk, Azure Databricks и машинное обучение, и отказоустойчивость.

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

В определении литерала указывается имя и элементы для каждого ресурса в среде, как показано в этом примере.

{
    {
        "SubscriptionId": "<subscription-identifier-associated-with-service-connection>",
        "Name": "<environment-name>",
        "NamingConvention": "<naming-convention-template-for-automatic-cases>",
        "Location": "<environment-location>",
        "ResourceGroup": {
            "Type": "Literal",
            "ResourceGroupName": "<resource-group-name>"
         }
    },
    "Resources":
    {
        "Sentinel":
        {
            "Type": "Literal",
            "LogAnalyticsWorkspaceName": "<Log-Analytics-workspace-name>",
            "ManagedIdentityName": "<user-managed-identity-name>",
            "SentinelConnectionName": "<Sentinel-API-connection-name>",
            "KeyVaultName": "<Key-Vault-name>",
            "KeyVaultConnectionName": "<Key-Vault-API-connection-name>"
        },
        "Automation":
        {
            "Type": "Literal",
            "AutomationAccountName": "<automation-account-name>",
            "AutomationAccountConnectionName": "<automation-account-API-connection-name>"
        },
        "Integration":
        {
            "Type": "Literal",
            "EventHubNamespaces": [
                "<Event-Hubs-namespace-1-name>",
                "<Event-Hubs-namespace-2-name>",
                "<Event-Hubs-namespace-3-name>",
                "<Event-Hubs-namespace-4-name>",
                "<Event-Hubs-namespace-5-name>",
                "<Event-Hubs-namespace-6-name>",
                "<Event-Hubs-namespace-7-name>",
                "<Event-Hubs-namespace-8-name>",
                "<Event-Hubs-namespace-9-name>",
                "<Event-Hubs-namespace-10-name>",
            ],
            "StorageAccountName": "<storage-account-name>"
        }
    }
}

В автоматическом определении имена элементов создаются автоматически на основе соглашений об именовании, как показано в этом примере.

{
    {
        "SubscriptionId": "<subscription-identifier-associated-with-service-connection>",
        "Name": "<environment-name>",
        "NamingConvention": "<naming-convention-template-for-automatic-cases>",
        "Location": "<environment-location>",
        "ResourceGroup": {
            "Type": "Automatic"
        }
    },
    "Resources":
    {
        "Sentinel":
        {
            "Type": "Automatic"
        },
        "Automation":
        {
            "Type": "Automatic"
        },
        "Integration":
        {
            "Type": "Automatic",
            "MaxEventHubNamespaces": 5
        }
    }
}

Примеры можно найти в репозитории GitHub в пути к средам Microsoft Sentinel и использовать примеры в качестве ссылки при подготовке вариантов использования.

Развертывание среды Microsoft Sentinel

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

  1. Импортируйте конвейер для создания новой среды, как определено в этом файле.

    src/Release/Sentinel Deployment/ADO/Microsoft.Sentinel.Environment.Deployment.yml

  2. Затем введите имя подключения службы, представляющего среду.

    Снимок экрана: ввод имени подключения к службе.

  3. Выберите ветвь для определения среды в репозитории. 

  4. Введите имя подключения службы Azure DevOps для подписки в поле "Подключение к среде Azure".

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

  6. Выберите действие, применяемое к соединителям.

  7. Выберите " Использовать артефакты предварительной версии PowerShell", если вы хотите использовать предварительные версии компонентов платформы PowerShell.

Конвейер включает следующие шаги в рамках потока развертывания:

  • Развертывание компонентов NuGet.
  • Подключитесь с помощью средств NuGet с репозиторием артефактов.
  • Разрешить веб-канал.
  • Установите необходимые модули.
  • Получите определение среды.
  • Проверьте, какие ресурсы существуют в назначении.
  • Добавьте Log Analytics и Microsoft Sentinel, если они не входят в рабочую область.
  • Если у вас уже есть Log Analytics, добавьте Microsoft Sentinel в экземпляр Log Analytics.
  • Создайте управляемое удостоверение для представления взаимодействия между Microsoft Sentinel и Logic Apps.
  • Создайте Azure Key Vault и задайте назначение роли для управления секретами и ключами управляемого удостоверения.
  • При необходимости создайте учетную запись служба автоматизации Azure и включите управляемое удостоверение, назначаемое системой.
  • Задайте назначение ролей в хранилище ключей для управляемого удостоверения, назначаемого системой.
  • Создайте определения Центров событий, если они не существуют и задают, включает ли определение элементы интеграции.
  • Задайте назначение ролей в хранилище ключей для управляемого удостоверения, назначаемого системой.
  • Создайте определения учетной записи хранения, если они не существуют и задают, включает ли определение элементы интеграции.
  • Задайте назначение ролей в хранилище ключей для управляемого удостоверения, назначаемого системой.
  • Развертывание действий соединителя.
  • Разверните модуль Runbook интеграции в учетной записи службы автоматизации.
  • Разверните подключения Logic Apps, если они определены как часть среды.

Уничтожение среды Microsoft Sentinel

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

src/Release/Sentinel Deployment/ADO/Microsoft.Sentinel.Environment.Destroy.yml

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

Работа с средой Microsoft Sentinel

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

  1. Экспортируйте артефакты из среды, над которой вы работаете, как определено в этом файле.

    src/Release/Artifacts Deployment/ADO/Microsoft.Sentinel.Artifacts.Export.yml

  2. Выберите ветвь для определения среды в репозитории.

    Снимок экрана: выбор ветви для экспорта артефактов.

  3. Введите имя подключения службы Azure DevOps для среды, экспортируемой в поле "Подключение к среде Azure".

  4. Выберите " Использовать артефакты предварительной версии PowerShell", если вы хотите использовать предварительные версии компонентов платформы PowerShell.

  5. Выберите формат для правил аналитики и охоты.

    Выходной файл артефактов доступен в результатах. После создания артефактов можно включить выходной файл в репозиторий Git.

Создание артефактов в среде Microsoft Sentinel

Поместите артефакты в путь использования Microsoft Sentinel MITRE. Настройте структуру папок в соответствии с различными типами артефактов.

  1. Запустите процесс сборки, как определено в этом файле.

    src/Build/Artifacts/ADO/Microsoft.Sentinel.Artifacts.Build.yaml

  2. Выберите ветвь для определения среды в репозитории.

    Схема выбора ветви для создания артефактов.] (./media/build-artifacts-pipeline.png)

  3. Выберите " Использовать артефакты предварительной версии PowerShell", если вы хотите использовать предварительные версии компонентов платформы PowerShell.

Конвейер состоит из следующих шагов:

  • Развертывание компонентов NuGet.
  • Подключите средства NuGet к репозиторию артефактов.
  • Разрешить веб-канал.
  • Установите необходимые модули.
  • Получите платформу средств тестирования для проверки шаблонов ARM.
  • Проверьте шаблоны ARM.
  • Проверьте код Runbook PowerShell и выполните проверку синтаксиса.
  • При необходимости запустите модульные тесты Pester.
  • Проверьте синтаксис KQL в правилах охоты и аналитики.

Развертывание артефактов в среде Microsoft Sentinel

При развертывании артефактов можно использовать репозитории Microsoft Sentinel или примеры конвейера развертывания в этом репозитории. Дополнительные сведения см. в статье Развертывание пользовательского содержимого из репозитория.

Репозитории Microsoft Sentinel

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

Кроме того, можно настроить процессы развертывания, выполняемые репозиториями Microsoft Sentinel на основе методик, описанных в этом документе. Одним из важных аспектов является утверждение выпуска, которое можно настроить следующими способами:

Примеры конвейера развертывания Microsoft Sentinel

С помощью примеров конвейера развертывания Microsoft Sentinel можно настроить процесс выпуска.

  1. Настройте процесс выпуска, как определено в этом файле.

    src/Release/Artifacts Deployment/ADO/Microsoft.Sentinel.Artifacts.Deployment.yml

  2. Выберите ветвь для определения среды в репозитории.

    Снимок экрана: выбор ветви для настройки процесса выпуска.

  3. Введите имя подключения службы Azure DevOps для среды, экспортируемой в поле "Подключение к среде Azure".

  4. Выберите " Использовать артефакты предварительной версии PowerShell", если вы хотите использовать предварительные версии компонентов платформы PowerShell.

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

Автор субъекта:

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

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