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

Статья
2024-11-05

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

Примечание.

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

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

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

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

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

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

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

Критерии	Описание
Операционные и данные безопасности	Вы можете объединить операционные данные из 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 с контекстом ресурсов для своих ресурсов.
Если требуется детализированный контроль доступа по таблице: предоставление или запрет доступа к определенным таблицам с помощью ролевого управления доступом на уровне таблицы.

Дополнительные сведения см. в статье Управление доступом к данным 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.
Каждый клиент может иметь разные параметры для своей рабочей области, например хранение и ограничение данных.
Изоляция между клиентами для соблюдения нормативных требований и требований соответствия.
Плата за каждое рабочее место входит в счет по подписке клиента.

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

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

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

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