Примеры структур рабочих областей Microsoft Sentinel

  • Статья

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

  • Несколько арендаторов и регионов с требованиями по обеспечению независимости данных в Европе
  • Один арендатор с несколькими облаками
  • Несколько арендаторов с несколькими регионами и централизованной безопасностью

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

Эта статья является частью руководства по развертыванию Microsoft Sentinel.

Пример 1. Несколько арендаторов и регионов

Contoso Corporation представляет собой многонациональное предприятие с головным офисом в Лондоне. У организации Contoso есть офисы по всему миру, а ключевые центры расположены в Нью-Йорке и Токио. Недавно организация Contoso произвела миграцию своего набора средств для обеспечения продуктивной работы в Office 365, при этом многие рабочие нагрузки были перенесены в Azure.

Арендаторы Contoso

Из-за приобретения несколько лет назад Компания Contoso имеет два клиента Microsoft Entra: contoso.onmicrosoft.com и wingtip.onmicrosoft.com. Каждый арендатор имеет собственный экземпляр Office 365 и несколько подписок Azure, как показано на следующем рисунке:

Diagram of Contoso tenants, each with separate sets of subscriptions.

Соответствие требованиям и региональные развертывания в Contoso

В настоящее время Contoso располагает ресурсами Azure, размещенными в трех разных регионах: Восточная часть США, Северная Европа и Западная Япония, и руководствуется строгим требованием по сохранению всех данных, создаваемых в Европе, в европейских регионах.

Оба клиента Microsoft Entra contoso имеют ресурсы во всех трех регионах: восточная часть США, север ЕС и Западная Япония

Требования к типам ресурсов и сбору данных в организации Contoso

Contoso необходимо получать события из следующих источников данных:

  • Office 365
  • Журналы входа и аудита Microsoft Entra
  • Действие Azure
  • События безопасности Windows как из локальной сети, так и из источников виртуальных машин Azure
  • Системный журнал как из локальной сети, так и из источников виртуальных машин Azure
  • CEF с нескольких локальных сетевых устройств, таких как Palo Alto, Cisco ASA и Cisco Meraki
  • Несколько ресурсов Azure PaaS, таких как Брандмауэр Azure, AKS, Key Vault, служба хранилища Azure и Azure SQL
  • Cisco Umbrella

Виртуальные машины Azure находятся в основном в Северной Европе и лишь несколько из них — в восточной части США и Западной Японии. Contoso использует Microsoft Defender для серверов на всех своих виртуальных машинах Azure.

Contoso ожидает, что объем данных, принимаемых из всех источников, составит около 300 ГБ в день.

Требования к доступу Contoso

В среде Azure организации Contoso уже имеется одна рабочая область Log Analytics, используемая операционной группой для мониторинга инфраструктуры. Эта рабочая область находится в клиенте Contoso Microsoft Entra в регионе "Север ЕС" и используется для сбора журналов из виртуальных машин Azure во всех регионах. В настоящее время объем принимаемых данных составляет около 50 ГБ в день.

Операционная группа Contoso должна иметь доступ ко всем журналам, которые в настоящее время находятся в рабочей области, включая несколько типов данных, которые не требуются для SOC, таких как Perf, InsightsMetrics, ContainerLog и др. Команда операций не должна иметь доступа к новым журналам, собранным в Microsoft Sentinel.

Решение организации Contoso

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

  1. В Contoso уже есть рабочая область, поэтому мы можем изучить возможность включения Microsoft Sentinel в этой рабочей области.

    Объем принимаемых данных, не относящихся к SOC, составляет менее 100 ГБ в день, поэтому мы можем перейти к шагу 2 и выбрать соответствующий вариант на шаге 5.

  2. Организация Contoso следует нормативным требованиям, поэтому нам нужна по меньшей мере одна рабочая область Microsoft Sentinel в Европе.

  3. Компания Contoso имеет два разных клиента Microsoft Entra и собирает данные из источников данных на уровне клиента, таких как Office 365 и Журналы аудита Microsoft Entra, поэтому нам нужна по крайней мере одна рабочая область для каждого клиента.

  4. Компания Contoso не требует обратной оплаты, поэтому мы можем продолжить шаг 5.

  5. Организации Contoso требуется собирать данные, не относящиеся к SOC, хотя перекрытие между данными, относящимися и не относящимися к SOC, отсутствует. Кроме того, объем данных SOC составляет приблизительно 250 ГБ в день, поэтому следует использовать отдельные рабочие области из соображений рентабельности.

  6. Большинство виртуальных машин Contoso являются регионом "Север ЕС", где у них уже есть рабочая область. Поэтому в этом случае затраты на пропускную способность не являются проблемой.

  7. Организация Contoso имеет единую группу SOC, которая будет использовать Microsoft Sentinel, поэтому никакое дополнительное разделение не требуется.

  8. Все члены группы SOC в организации Contoso будут иметь доступ ко всем данным, поэтому никакое дополнительное разделение не требуется.

Итоговая структура рабочей области Microsoft Sentinel для Contoso показана на следующем рисунке:

Diagram of Contoso's solution, with a separate workspace for the Ops team.

Предлагаемое решение включает в себя следующее:

  • Отдельная рабочая область Log Analytics для операционной группы Contoso. Эта рабочая область будет содержать только те данные, которые не требуются группе SOC Contoso, например таблицы Perf, InsightsMetrics или ContainerLog.

  • Две рабочие области Microsoft Sentinel, по одному в каждом клиенте Microsoft Entra, для приема данных из Office 365, действия Azure, идентификатора Microsoft Entra и всех служб PaaS Azure.

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

Пример 2. Один арендатор с несколькими облаками

Fabrikam — это организация с офисами по всей территории США, головной офис которой находится в Нью-Йорке. Fabrikam начинает свой переход на облачные технологии и пока собирается развернуть первую целевую зону Azure и перенести первые рабочие нагрузки. Fabrikam уже имеет некоторые рабочие нагрузки в AWS, которые планируется отслеживать с помощью Microsoft Sentinel.

Требования к аренде Fabrikam

Fabrikam имеет один клиент Microsoft Entra.

Соответствие требованиям и региональные развертывания в Fabrikam

У Fabrikam нет требований по соответствию. Fabrikam имеет ресурсы в нескольких регионах Azure, расположенных в США, но затраты на пропускную способность в разных регионах не являются основной проблемой.

Требования к типам ресурсов и сбору данных в организации Fabrikam

Fabrikam необходимо получать события из следующих источников данных:

  • Журналы входа и аудита Microsoft Entra
  • Действие Azure
  • События безопасности как из локальной сети, так и из источников виртуальных машин Azure
  • События Windows как из локальной сети, так и из источников виртуальных машин Azure
  • Данные о производительности как из локальной сети, так и из источников виртуальных машин Azure
  • AWS CloudTrail
  • Журналы аудита и производительности AKS

Требования к доступу для Fabrikam

Операционная группа Fabrikam должна иметь доступ к следующим ресурсам:

  • События безопасности и события Windows как из локальной сети, так и из источников виртуальных машин Azure
  • Данные о производительности как из локальной сети, так и из источников виртуальных машин Azure
  • Журналы производительности и аудита AKS (аналитика контейнеров)
  • Все данные о действиях Azure

Группа SOC Fabrikam должна иметь доступ к следующим ресурсам:

  • Журналы входа и аудита Microsoft Entra
  • Все данные о действиях Azure
  • События безопасности как из локальной сети, так и из источников виртуальных машин Azure
  • Журналы AWS CloudTrail
  • Журналы аудита AKS
  • Полнофункциональный портал Microsoft Sentinel

Решение Fabrikam

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

  1. У Fabrikam нет рабочей области, поэтому перейдите к шагу 2.

  2. У Fabrikam нет нормативных требований, поэтому перейдите к шагу 3.

  3. У Fabrikam есть среда с одним арендатором. Поэтому перейдите к шагу 4.

  4. Fabrikam не нужно разделять расходы, поэтому перейдите к шагу 5.

  5. Fabrikam потребуется отдельные рабочие области для группы SOC и операционной группы:

    Операционная группа Fabrikam должна собирать данные о производительности как с виртуальных машин, так и из AKS. Так как служба AKS основана на параметрах диагностики, они могут выбрать конкретные журналы для отправки в определенные рабочие области. Fabrikam может отправлять журналы аудита AKS в рабочую область Microsoft Sentinel и все журналы AKS в отдельную рабочую область, где Microsoft Sentinel не включена. В рабочей области, в которой Microsoft Sentinel не включена, Fabrikam включает решение container Аналитика.

    Для виртуальных машин Windows Fabrikam может использовать агент Azure Monitor (AMA) для разбиения журналов, отправляя события безопасности в рабочую область Microsoft Sentinel, а события производительности и события Windows — в рабочую область без Microsoft Sentinel.

    Fabrikam решает учесть перекрывающиеся данные, такие как события безопасности и события действий Azure, только в качестве данных SOC и отправляет эти данные в рабочую область с Microsoft Sentinel.

  6. Затраты на пропускную способность не являются основной проблемой для Fabrikam, поэтому продолжайте шаг 7.

  7. Организация Fabrikam уже решила использовать отдельные рабочие области для группы SOC и операционной группы. Дальнейшее разделение не требуется.

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

    События безопасности и события действий Azure не являются пользовательскими журналами, поэтому Fabrikam может использовать RBAC уровня таблицы для предоставления доступа к этим двум таблицам для команды операций.

Итоговая структура рабочей области Microsoft Sentinel для Fabrikam показана на следующем рисунке и для простоты включает в себя только источники журналов ключей:

Diagram of Fabrikam's solution, with a separate workspace for the Ops team.

Предлагаемое решение включает в себя следующее:

  • Две отдельные рабочие области в регионе США: одна для группы SOC с включенным Microsoft Sentinel и другая — для операционной группы без Microsoft Sentinel.

  • Агент Azure Monitor (AMA), который используется для определения журналов, отправляемых в каждую рабочую область из Azure и с локальных виртуальных машин.

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

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

Пример 3. Несколько арендаторов и регионов и централизованная безопасность

Adventure Works — это многонациональная организация с головным офисом в Токио. Adventure Works имеет 10 разных дочерних сущностей, базирующихся в разных странах или регионах по всему миру.

Adventure Works является клиентом Microsoft 365 E5 и уже располагает рабочими нагрузками в Azure.

Требования к аренде Adventure Works

Adventure Works имеет три разных клиента Microsoft Entra, по одному для каждого континента, где они имеют дочерние сущности: Азия, Европа и Африка. Страны и регионы разных субъектов имеют свои удостоверения в клиенте континента, к которому они относятся. Например, японские пользователи находятся у арендатора Азии, немецкие — у арендатора Европы, а египетские — у арендатора Африки.

Требования соответствия и региональные требования Adventure Works

Сейчас Adventure Works использует три региона Azure, каждый из которых соответствует континенту, где находятся подразделения. У Adventure Works нет четких требований к соответствию.

Требования к типам ресурсов и сбору данных в организации Adventure Works

Adventure Works необходимо собирать данные из следующих источников для каждого подразделения:

  • Журналы входа и аудита Microsoft Entra
  • Журналы Office 365
  • Необработанные журналы XDR в Microsoft Defender для конечной точки
  • Действие Azure
  • Microsoft Defender для облака
  • Ресурсы Azure PaaS, такие как Брандмауэр Azure, служба хранилища Azure, Azure SQL и Azure WAF
  • События безопасности и события Windows из виртуальных машин Azure
  • Журналы CEF с локальных сетевых устройств

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

Требования к доступу Adventure Works

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

Adventure Works также имеет три независимых группы SOC — по одной на каждый континент. Группа SOC для каждого из континентов может получить доступ только к данным, создаваемым в пределах ее региона, и не видит данные других континентов. Например, команда SOC Азии должна получать доступ только к данным из ресурсов Azure, развернутых в Азии, входа Microsoft Entra из клиента Азии и журналов Defender для конечных точек из этого клиента Азии.

Группа SOC каждого континента должна иметь доступ к полноценному интерфейсу портала Microsoft Sentinel.

Операционная группа Adventure Works работает независимо и имеет свои рабочие области без Microsoft Sentinel.

Решение Adventure Works

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

  1. Группа операций Adventure Works имеет собственные рабочие области, поэтому продолжайте шаг 2.

  2. У Adventure Works нет нормативных требований, поэтому перейдите к шагу 3.

  3. Adventure Works имеет три клиента Microsoft Entra и должен собирать источники данных на уровне клиента, такие как журналы Office 365. Поэтому Adventure Works нужно создать по меньшей мере по одной рабочей области Microsoft Sentinel для каждого арендатора.

  4. Adventure Works не нужно разделять расходы, поэтому перейдите к шагу 5.

  5. Так как операционная группа Adventure Works имеет собственные рабочие области, все данные, рассматриваемые в этом решении, будут использоваться группой SOC Adventure Works.

  6. Затраты на пропускную способность не являются основной проблемой для Adventure Works, поэтому продолжайте шаг 7.

  7. Adventure Works необходимо разделить данные по праву владения, так как группе SOC, работающей с содержимым, требуется доступ только к данным, относящимся к такому содержимому. Однако группе SOC каждого континента также требуется доступ к полноценному порталу Microsoft Sentinel.

  8. Adventure Works не требует управления доступом к данным по таблице.

Итоговая структура рабочей области Microsoft Sentinel для Adventure Works показана на следующем рисунке и для простоты включает в себя только источники журналов ключей:

Diagram of Adventure Works's solution, with separate workspaces for each Azure AD tenant.

Предлагаемое решение включает в себя следующее:

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

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

  • Центральная команда SOC по-прежнему может работать из отдельного клиента Microsoft Entra, используя Azure Lighthouse для доступа к каждой из разных сред Microsoft Sentinel. Если нет другого клиента, центральная команда SOC по-прежнему может использовать Azure Lighthouse для доступа к удаленным рабочим областям.

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

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

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

Подготовка к нескольким рабочим областям