Проектирование развертывания журналов Azure Monitor

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

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

Пример модели данных рабочей области

Рабочая область Log Analytics предоставляет следующие преимущества:

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

В этой статье подробно рассматривается ряд аспектов проектирования и миграции, дается краткий обзор управления доступом и описываются рекомендуемые для вашей ИТ-организации варианты реализации.

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

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

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

Сегодня ИТ-организации моделируются как централизованные, децентрализованные или гибридные (сочетающие в себе то и другое) структуры. В соответствии с этими видами организационной структуры часто используют следующие модели развертывания рабочих областей:

  • Централизованная. Все журналы хранятся в центральной рабочей области и администрируются одной командой, а Azure Monitor предоставляет дифференцированный доступ для каждой команды. Этот сценарий облегчает управление, поиск по всему множеству ресурсов и перекрестное сопоставление журналов. Рабочая область может значительно разрастаться в зависимости от объема данных, собираемых из множества ресурсов в подписке, что влечет дополнительные административные издержки на управление доступом для разных пользователей. Это так называемая "звездообразная" модель.
  • Децентрализованная. У каждой команды есть собственная рабочая область, созданная в группе ресурсов, которой эта команда владеет и управляет, а данные журналов разделяются по ресурсам. В этом сценарии облегчается защита рабочей области, а управление доступом согласуется со способом организации доступа к ресурсам, но при этом затрудняется перекрестное сопоставление журналов. У пользователей, которым нужно иметь общую картину по множеству ресурсов, нет возможности осмысленно анализировать данные.
  • Гибридная. Реализация этого сценария дополнительно затрудняется необходимостью соответствовать требованиям аудита безопасности, поскольку во многих организациях обе перечисленные выше модели реализуются параллельно. В результате обычно получается сложная, дорогостоящая и трудная в сопровождении конфигурация, некоторые аспекты работы которой не отражаются в журналах.

При использовании агентов Log Analytics для получения данных, чтобы спланировать развертывание агента, вам необходимо знать следующее:

Если вы используете System Center Operations Manager 2012 R2 и более поздние версии:

  • каждая группа управления Operations Manager может быть подключена только к одной рабочей области;
  • компьютеры Linux, передающие данные в группу управления, должны быть настроены для отправки отчетов непосредственно в рабочую область Log Analytics; если компьютеры Linux уже отправляют отчеты непосредственно в рабочую область и вы хотите отслеживать их с помощью Operations Manager, следуйте этим указаниям, чтобы отправлять отчеты в группу управления Operations Manager;
  • вы можете установить агент Log Analytics Windows на компьютере Windows и настроить его таким образом, чтобы агент отправлял отчеты как в рабочую область, связанную с Operations Manager, так и в другую рабочую область.

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

С помощью управления доступом на основе ролей Azure (Azure RBAC) можно сделать так, чтобы пользователям и группам предоставлялся доступ только к тем ресурсам, которые им необходимы для работы с данными мониторинга в рабочей области. Это позволяет организовать доступ в соответствии с моделью функционирования вашей ИТ-организации, используя для хранения собранных данных одну рабочую область, включенную для всех ресурсов. Например, если предоставить доступ команде, ответственной за службы инфраструктуры, размещенные на виртуальных машинах Azure, то в результате у этой команды будет доступ только к тем журналам, которые создаются виртуальными машинами. Это соответствует нашей новой модели организации доступа к журналам в контексте ресурсов. Основа этой модели состоит в том, что каждая запись в журнале, порождаемая ресурсом Azure, автоматически связывается с этим ресурсом. Журналы пересылаются в центральную рабочую область, в которой обеспечивается разграничение областей доступа и реализуется Azure RBAC на основе ресурсов.

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

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

Режим доступа

Режим доступа — это способ доступа пользователя к рабочей области Log Analytics. Он определяет область, в пределах которой будут доступны данные.

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

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

    Контекст Log Analytics из рабочей области

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

    Контекст Log Analytics из ресурса

    Примечание

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

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

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

Сравнение режимов доступа

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

Проблема В контексте рабочей области В контексте ресурса
Для кого предназначена модель? Централизованное администрирование. Администраторы, которым требуется настроить сбор данных, и пользователи, которым необходим доступ к широкому кругу ресурсов. Кроме того, сейчас эта модель обязательна для пользователей, которым требуется доступ к журналам ресурсов, находящихся за пределами Azure. Команды разработки и обслуживания приложений, администраторы отслеживаемых ресурсов Azure.
Что требуется пользователю, чтобы просматривать журналы? Разрешения для рабочей области. См. раздел "Управление доступом на основе разрешений для рабочей области" статьи "Управление доступом к данным журналов и рабочим областям в Azure Monitor". Доступ для чтения к ресурсу. См. раздел "Управление доступом на основе разрешений Azure" статьи "Управление доступом к данным журналов и рабочим областям в Azure Monitor". Разрешения могут наследоваться (например, из содержащей их группы ресурсов) или назначаться ресурсу непосредственно. Разрешение на доступ к журналам для ресурса будет назначено автоматически.
Какова область действия разрешений? Рабочая область. Пользователи с доступом к рабочей области могут запрашивать все журналы в рабочей области из таблиц, на доступ к которым у них есть разрешения. См. раздел "Azure RBAC на уровне таблиц" статьи "Управление доступом к данным журналов и рабочим областям в Azure Monitor". Ресурс Azure. Пользователь может запрашивать журналы конкретных ресурсов, групп ресурсов или подписки, к которым у него есть доступ, из любой рабочей области, но не может запрашивать журналы других ресурсов.
Как пользователь может получить доступ к журналам?
  • Выбрать пункт Журналы в меню Azure Monitor.
  • Выбрать пункт Журналы в разделе Рабочие области Log Analytics.
  • Выбрать пункт Журналы в меню соответствующего ресурса Azure.
  • Выбрать пункт Журналы в меню Azure Monitor.
  • Выбрать пункт Журналы в разделе Рабочие области Log Analytics.

Режим контроля доступа

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

  • Требовать разрешений рабочей области. В этом режиме не поддерживается Azure RBAC с детализацией. Чтобы пользователь получил доступ к рабочей области, ему должны быть предоставлены разрешения для рабочей области или конкретных таблиц.

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

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

  • Использовать разрешения ресурса или рабочей области. В этом режиме поддерживается Azure RBAC с детализацией. Он позволяет ограничить доступ пользователей данными, связанными с ресурсами, которые им разрешено просматривать — для этого необходимо назначить разрешение read Azure.

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

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

    Примечание

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

О том, как изменить режим управления доступом на портале с помощью PowerShell или шаблона Resource Manager, см. в разделе "Настройка режима управления доступом" статьи "Управление доступом к данным журналов и рабочим областям в Azure Monitor".

Ограничение на масштаб и дневной объем принимаемых данных

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

Для защиты и изоляции клиентов Azure Monitor и их серверной инфраструктуры по умолчанию установлено ограничение на скорость приема данных, предназначенное для защиты от пиковых нагрузок и переполнения. Предельная скорость по умолчанию составляет около 6 ГБ/мин — такое значение призвано обеспечить обычный прием данных. Дополнительные сведения об измерении предельного объема принимаемых данных см. в статье "Ограничения службы Azure Monitor".

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

При достижении предельного значения скорости приема данных или достижении уровня 80 % от этого порога в таблицу операций рабочей области вносится соответствующее событие. Рекомендуется отслеживать это событие и создать оповещение на его основе. Дополнительные сведения см. в разделе "Ограничение на объем принимаемых данных в день" статьи "Ограничения службы Azure Monitor".

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

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

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

Все ресурсы, решения для мониторинга и источники аналитических сведений (такие как Application Insights и VM Insights), поддерживающие инфраструктуру и приложения, которые обслуживаются разными командами, настроены для пересылки собранных ими данных журналов в централизованную общую рабочую область ИТ-организации. Пользователям из состава каждой команды доступны журналы тех ресурсов, к которым им предоставлен доступ.

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

Стратегия миграции с консолидацией рабочих областей

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

При планировании перехода на эту модель:

  • узнайте, какие отраслевые нормы и внутренние политики в отношении хранения данных необходимо соблюдать;
  • убедитесь, что ваши команды разработки и обслуживания приложений способны будут работать в пределах существующей функциональности, предоставляемой в контексте ресурсов;
  • определите, какой доступ к ресурсам предоставлен вашим командам разработки и обслуживания приложений, и протестируйте его в среде разработки перед внедрением в рабочей среде;
  • включите для рабочей области режим Использовать разрешения ресурса или рабочей области;
  • отзовите у команды разработки и обслуживания приложений разрешения на чтения и запрос данных в рабочей области;
  • включите и настройте решения для мониторинга, источники аналитических сведений (например, Container Insights) и/или Azure Monitor для виртуальных машин, свои учетные записи службы автоматизации и решения для управления (например, Управление обновлениями, Запуск и остановка виртуальных машин и т. д.), которые были развернуты в исходной рабочей области.

Дальнейшие действия

Чтобы реализовать разрешения и элементы управления безопасностью, рекомендованные в этом руководстве, ознакомьтесь со статьей "Управление доступом к данным журналов и рабочим областям в Azure Monitor".