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

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

Необходимые компоненты

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

Необходимые условия	Description
Нормативные требования, связанные с местонахождением данных Azure	Microsoft Sentinel может работать в рабочих областях в большинстве, но не во всех регионах, поддерживаемых в общедоступной версии Log Analytics. Недавно поддерживаемые регионы Log Analytics могут занять некоторое время для подключения службы Microsoft Sentinel. Данные, созданные Microsoft Sentinel, такие как инциденты, закладки и правила аналитики, могут содержать некоторые данные клиента, полученные из рабочих областей Log Analytics клиента. Дополнительные сведения см. в статье Географическая доступность и место расположения данных.
Источники данных	Узнайте, какие источники данных необходимо подключить, включая встроенные соединители для решений Майкрософт и сторонних производителей. Чтобы подключить источники данных к Microsoft Sentinel, вы также можете использовать общий формат событий, Syslog или REST API. Если вам нужно получать журналы с виртуальных машин Azure в нескольких расположениях Azure и для вас важны расходы на исходящий трафик, эти расходы можно рассчитать с помощью калькулятора цен для пропускной способности для каждого расположения Azure.
Роли пользователей, уровни доступа к данным и разрешения	Microsoft Sentinel использует управление доступом на основе ролей (Azure RBAC) с несколькими встроенными ролями, которые можно назначать пользователям, группам и службам в Azure. Все встроенные роли Microsoft Sentinel предоставляют доступ на чтение данных в рабочей области Microsoft Sentinel. Поэтому необходимо выяснить, требуется ли управлять доступом к данным для каждого источника данных или уровня строк, так как это повлияет на решение о проектировании рабочей области. Дополнительные сведения см. в статье Пользовательские роли и расширенные роли Azure RBAC.
Ежедневный объем приема данных	Ежедневный объем приема данных (обычно измеряется в ГБ/день) является одним из ключевых факторов, связанных с управлением затратами и планированием, а также проектированием рабочих областей для Microsoft Sentinel. В большинстве облачных и гибридных сред основной объем принимаемых данных приходится на сетевые устройства, такие как брандмауэры или прокси, а также серверы Windows и Linux. Для получения наиболее точных результатов Майкрософт рекомендует провести полную инвентаризацию источников данных. Кроме того, в калькуляторе затрат в Microsoft Sentinel есть таблицы, помогающие оценить объемы для источников данных. Важно! Эти оценки являются отправной точкой, и разные параметры детализации журнала и рабочих нагрузок будут требовать адаптации. Для отслеживания изменений рекомендуется регулярно наблюдать за системой. Регулярный мониторинг рекомендуется вести в зависимости от конкретного сценария. Дополнительные сведения см. в разделе Azure Log Analytics.*

Дерево принятия решений

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

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

Примечание 1 | Примечание 2 | Примечание 3 | Примечание 4 | Примечание 5 | Примечание 6 | Примечание 7 | Примечание 8 | Примечание 9 | Примечание 10

Шаг 1. Новая или существующая рабочая область?

У вас есть рабочая область, которую можно использовать для Microsoft Sentinel?

• Если нет, и вы планируете в любом случае создавать новую рабочую область, сразу перейдите к шагу 2.

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

  • Если вы будете принимать более 100 ГБ в день, рекомендуется для экономии использовать отдельную рабочую область.

  • Если вы будете принимать менее 100 ГБ в день, перейдите к шагу 2 для дальнейшей оценки. Продумайте этот вопрос снова, когда он возникает на шаге 5.

Шаг 2. Храните данные в разных географических регионах Azure?

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

• Если вам не нужно размещать данные в разных географических регионах Azure, перейдите к шагу 3.

Шаг 3. Несколько арендаторов Azure?

• Если у вас только один арендатор, сразу перейдите к шагу 4.

• Если у вас несколько клиентов Azure, рассмотрите ли вы сбор журналов, относящихся к границе клиента, например Office 365 или Microsoft Defender XDR.

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

  • Если вы собираете журналы для конкретного клиента, используйте отдельную рабочую область Microsoft Sentinel для каждого клиента Microsoft Entra. Другие факторы рассматриваются на шаге 4.

    Примечание 1 по дереву принятия решений. Журналы, относящиеся к пограничным арендаторам, например Office 365 и Microsoft Defender для облака, могут храниться только в рабочей области в том же арендаторе.

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

    • Данные, собираемые настраиваемыми соединителями, будут приниматься в настраиваемые таблицы. Поэтому использовать все встроенные правила и книги будет нельзя.
    • Пользовательские таблицы не рассматриваются некоторыми встроенными функциями, такими как UEBA и правила машинного обучения.
    • Для настройки пользовательских соединителей потребуются дополнительные затраты и усилия, связанные, например, с использованием Функций Azure и Logic Apps.

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

Шаг 4. Нужно разделение счетов и возврат средств?

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

• Если вам не нужны разделение счетов и возврат средств, переходите к шагу 5.

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

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

  • Если не будете использовать отчеты об использовании и перекрестную оплату вручную, разверните отдельную рабочую область Microsoft Sentinel для каждого владельца затрат.

  Примечание 2 по дереву принятия решений. Дополнительные сведения см. в статье Затраты и выставление счетов для Microsoft Sentinel.

Шаг 5. Вы будете собирать данные, не относящиеся к SOC?

• Если вы не собираете данные, не относящиеся к SOC, например операционные данные, можно сразу перейти к шагу 6.

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

  Если у вас перекрываются области сбора данных SOC и других данных, обрабатывайте перекрывающиеся данные только как данные SOC. Затем подумайте, составляет ли объем приема данных SOC и других данных менее 100 ГБ в день по отдельности, но более 100 ГБ/день в совокупности.

  • Да: перейдите к шагу 6.
  • Нет. Мы не рекомендуем использовать ту же рабочую область для повышения эффективности затрат. Перейдите к шагу 6.

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

  Если перекрывающиеся данные отсутствуют, подумайте, составляет ли объем приема данных SOC и других данных менее 100 ГБ в день по отдельности, но более 100 ГБ/день в совокупности.

  • Да: перейдите к шагу 6. Дополнительные сведения см. в примечании 3.
  • Нет. Мы не рекомендуем использовать ту же рабочую область для повышения эффективности затрат. Перейдите к шагу 6.

Объединение данных SOC и других данных

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

Например, рассмотрим организацию с журналами безопасности с приемом данных 50 ГБ в день, журналами операций с приемом данных 50 ГБ/день и рабочей областью в регионе "Восточная часть США".

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

Примечание.

Затраты и условия, приведенные в следующей таблице, являются вымышленными и используются только в демонстрационных целях. Актуальные данные о затратах см. в калькуляторе цен Microsoft Sentinel.

Архитектура рабочих областей	Description
У команды SOC собственная рабочая область, где включена служба Microsoft Sentinel. У команды сопровождения собственная рабочая область, где выключена служба Microsoft Sentinel.	Команда SOC: Затраты на Microsoft Sentinel для объема 50 ГБ в день составляют 6500 долл. США в месяц. Первые три месяца данные хранятся бесплатно. Команда OPS: – Затраты на Log Analytics для объема 50 ГБ в день составляют около 3500 долл. США в месяц. – 31 день от начала пользования данные хранятся бесплатно. Общая стоимость за обе службы составляет 10 000 долл. США в месяц.
Команды SOC и OPS вместе используют одну рабочую область, где включена служба Microsoft Sentinel.	Объединяя журналы, вы получаете 100 ГБ в день, что соответствует требованиям уровня обязательств (50 % для Sentinel и 15 % для LA). Затраты на Microsoft Sentinel для объема 100 ГБ в день равны 9000 долл. США в месяц.

В этом примере вы экономите 1000 долл. США в месяц, объединив две рабочие области, а группа OPS также получает 3 месяца бесплатного хранения вместо 31 дня.

Этот пример актуален только в том случае, если как для данных SOC, так и для других данных объем будет составлять >=50 и <100 ГБ в день.

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

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

Шаг 6. Несколько регионов?

• Если вы собираете данные журналов виртуальных машин Azure только в одном регионе, сразу переходите к шагу 7.

• Если вы собираете данные журналов виртуальных машин Azure в нескольких регионах, насколько для вас важны затраты на исходящий трафик?

  Примечание 4 по дереву решений. Исходящий трафик учитывается в стоимости пропускной способности, необходимой для перемещения данных из Центра данных Azure. Дополнительные сведения см. в рекомендациях по выбору регионов.

  • Если вы не хотите управлять несколькими рабочими областями, перейдите к шагу 7.

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

    Примечание 5 по дереву решений. Рекомендуется минимизировать число рабочих областей. С помощью калькулятора цен Azure оцените затраты и выясните, какие регионы вам действительно необходимы, а затем объедините рабочие области для регионов с низкими расходами на исходящий трафик. Затраты на пропускную способность могут быть лишь небольшой частью счета За прием Azure по сравнению с отдельными затратами на прием Microsoft Sentinel и Log Analytics.

    Например, ориентировочная стоимость может быть такой:

    • 1000 виртуальных машин, каждая из которых генерирует 1 ГБ/день.
    • Отправка данных из региона США в регион ЕС.
    • Коэффициент сжатия 2:1 в агенте.

    Расчет для такой оценочной стоимости будет иметь следующий вид: 1000 VMs * (1GB/day ÷ 2) * 30 days/month * $0.05/GB = $750/month bandwidth cost

    В этом примере затраты будут намного ниже по сравнению с месячными затратами на отдельные рабочие области Microsoft Sentinel и Log Analytics.

    Примечание.

    Указанные затраты являются вымышленными и используются только для наглядности. Актуальные данные о затратах см. в калькуляторе цен Microsoft Sentinel.

Шаг 7. Нужно разделить данные или границы по признаку владения?

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

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

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

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

  • Если доступ к журналам через Log Analytics без доступа к порталу Microsoft Sentinel — приемлемое решение для всех владельцев, перейдите к шагу 8.

  Дополнительные сведения см. в статье Разрешения в Microsoft Sentinel.

Шаг 8. Управление доступом к данным с помощью источника данных или таблицы?

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

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

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

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

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

Рекомендации по RBAC на уровне контекста ресурсов или таблиц

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

• Примечание дерева принятия решений #7. Чтобы настроить RBAC контекста ресурсов для ресурсов, отличных от Azure, может потребоваться связать идентификатор ресурса с данными при отправке в Microsoft Sentinel, чтобы разрешение можно было область с помощью RBAC с контекстом ресурсов. Дополнительные сведения см. в статьях Явная настройка RBAC в контексте ресурсов и Режимы доступа по развертываниям.

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

• Примечание 9 по дереву решений.RBAC на уровне таблицы позволяет в дополнение к другим разрешениям осуществлять более точный контроль над данными в рабочей области Log Analytics. Эта функция позволяет администратору определить, какие конкретные типы данных доступны для набора пользователей. Дополнительные сведения см. в статье RBAC на уровне таблиц в Microsoft Sentinel.

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

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

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