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

Статья
11/05/2024

Одна рабочая область Log Analytics может быть достаточной для многих сред, использующих Azure Monitor и Microsoft Sentinel. Но многие организации создают несколько рабочих областей для оптимизации затрат и лучше соответствуют различным бизнес-требованиям. В этой статье представлен набор критериев для определения того, следует ли использовать одну рабочую область или несколько рабочих областей. Он также обсуждает конфигурацию и размещение этих рабочих областей в соответствии с вашими требованиями при оптимизации затрат.

Примечание.

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

Ниже приведено видео об основах журналов Azure Monitor и рекомендации и рекомендации по проектированию развертывания журналов Azure Monitor:

Стратегия проектирования

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

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

Критерии проектирования

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

Критерии	Description
Операционные и данные безопасности	Вы можете объединить операционные данные из Azure Monitor в той же рабочей области, что и данные безопасности из Microsoft Sentinel или разделить каждую из них в свою рабочую область. Объединение этих данных обеспечивает более высокую видимость всех данных, в то время как стандарты безопасности могут потребовать разделения, чтобы ваша команда безопасности получила выделенную рабочую область. Вы также можете иметь последствия для каждой стратегии.
Клиенты Azure	Если у вас несколько клиентов Azure, обычно вы создадите рабочую область в каждой из них. Несколько источников данных могут отправлять данные мониторинга только в рабочую область в одном клиенте Azure.
Регионы Azure	Каждая рабочая область находится в определенном регионе Azure. У вас могут быть нормативные или нормативные требования для хранения данных в определенных расположениях.
Владение данными	Вы можете создать отдельные рабочие области для определения владения данными. Например, можно создавать рабочие области дочерними или дочерними компаниями.
Разделение выставления счетов	При размещении рабочих областей в разных подписках счета на оплату могут выставляться разным сторонам.
Хранение данных	Вы можете задать разные параметры хранения для каждой рабочей области и каждой таблицы в рабочей области. Вам нужна отдельная рабочая область, если требуются разные параметры хранения для разных ресурсов, которые отправляют данные в одни и те же таблицы.
Уровни обязательств	Уровни обязательств позволяют сократить расходы на прием данных за счет фиксации минимального ежедневного объема данных в одной рабочей области.
Ограничения устаревших агентов	Устаревшие агенты виртуальных машин имеют ограничения на количество рабочих областей, к которых они могут подключаться.
Управление доступом к данным	Настройте доступ к рабочей области и к разным таблицам и данным из разных ресурсов.
Устойчивость	Чтобы убедиться, что данные в рабочей области доступны в случае сбоя региона, вы можете получать данные в несколько рабочих областей в разных регионах.

Операционные и данные безопасности

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

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

Рабочая область с Microsoft Sentinel получает три месяца свободного хранения данных вместо 31 дней. Этот сценарий обычно приводит к повышению затрат на операционные данные в рабочей области без Microsoft Sentinel. См. статью Сведения о ценах на журналы Azure Monitor.

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

Эта конфигурация может привести к экономии затрат, если она помогает достичь уровня обязательств, который предоставляет скидку на прием. Например, рассмотрим организацию, которая принимает по 50 ГБ рабочих данных и данных безопасности в день. Объединение данных в той же рабочей области позволит обеспечить уровень обязательств в 100 ГБ в день. Этот сценарий обеспечит скидку на 15 % для Azure Monitor и скидку на 50 % для Microsoft Sentinel.

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

Если вы используете Azure Monitor и Microsoft Sentinel: рассмотрите возможность разделения каждой из них в выделенной рабочей области, если это требуется вашей команде безопасности или если это приведет к экономии затрат. Рассмотрите возможность объединения двух для лучшей видимости объединенных данных мониторинга или если это поможет вам достичь уровня обязательств.
Если вы используете Microsoft Sentinel и Microsoft Defender для облака: рассмотрите возможность использования одной рабочей области для обоих решений, чтобы сохранить данные безопасности в одном месте.

Клиенты Azure

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

Если у вас есть один клиент Azure: создайте одну рабочую область для этого клиента.
Если у вас несколько клиентов Azure: создайте рабочую область для каждого клиента. Другие варианты, включая стратегии для поставщиков услуг, см. в разделе "Несколько стратегий клиента".

Регионы Azure

Каждая рабочая область Log Analytics находится в определенном регионе Azure. Возможно, у вас есть нормативные или нормативные требования для хранения данных в определенном регионе. Например, международная компания может найти рабочую область в каждом крупном географическом регионе, например США и Европе.

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

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

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

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

Владение данными

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

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

Раздельное выставление счетов

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

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

Хранение данных

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

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

Уровни обязательств

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

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

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

Ограничения устаревших агентов

Следует избегать отправки повторяющихся данных в несколько рабочих областей из-за дополнительных расходов, но у вас могут быть виртуальные машины, подключенные к нескольким рабочим областям. Наиболее распространенный сценарий — агент, подключенный к отдельным рабочим областям для Azure Monitor и Microsoft Sentinel.

Агент Azure Monitor и агент Log Analytics для Windows могут подключаться к нескольким рабочим областям. Агент Log Analytics для Linux может подключаться только к одной рабочей области.

Если вы используете агент Log Analytics для Linux: перейдите в агент Azure Monitor или убедитесь, что компьютеры Linux требуют доступа только к одной рабочей области.

Управление доступом к данным

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

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

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

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

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

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

Дополнительные сведения см. в статье Управление доступом к данным Microsoft Sentinel по ресурсам.

Устойчивость

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

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

Работа с несколькими рабочими областями

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

Azure Monitor и Microsoft Sentinel включают функции для анализа этих данных в разных рабочих областях. Дополнительные сведения см. в разделе:

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

Стратегии использования нескольких клиентов

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

Примечание.

Log Analytics и Azure Monitor входят в число служб Azure, доступных в рамках подписок Azure CSP для партнеров и поставщиков услуг, работающих по программе "Поставщик облачных решений (CSP)".

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

Распределенная архитектура

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

Существует два способа разрешить администраторам поставщика услуг доступ к рабочим областям в клиентах клиентов:

Используйте Azure Lighthouse для доступа к каждому арендатору клиента. Администраторы поставщика услуг включаются в группу пользователей Microsoft Entra в клиенте поставщика услуг. Эта группа предоставляет доступ во время процесса подключения для каждого клиента. После этого администраторы могут получить доступ к рабочим областям каждого клиента из собственного клиента поставщика услуг, а не выполнять вход в клиент каждого клиента по отдельности. Дополнительные сведения см. в статье Мониторинг ресурсов клиентов при масштабировании.
Добавьте отдельных пользователей из поставщика услуг в качестве гостевых пользователей Microsoft Entra (B2B). Администраторы клиента управляют отдельным доступом для каждого администратора поставщика услуг. Администраторы поставщика услуг должны войти в каталог для каждого клиента в портал Azure для доступа к этим рабочим областям.

Преимущества этой стратегии:

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

Недостатки этой стратегии:

Централизованное визуализация и анализ данных в клиентах с помощью таких средств, как книги Azure Monitor, может привести к замедлению работы. Это особенно касается анализа данных в более чем 50 рабочих областях.
Если клиенты не подключены для делегированного управления ресурсами Azure, администраторы поставщиков услуг должны быть подготовлены в каталоге клиента. Это требование затрудняет одновременное управление многими клиентами клиентов поставщиком услуг.

Централизовано

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