Вопрос

• Можно ли пересылать контент из одной рабочей области Azure Log Analytics в другую?

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

Окружающая среда и бизнес-кейс

Страж

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

Локальные хосты Windows

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

Невыполненное требование

(Примечание: пусть вас не пугает упоминание SQL Server; оно лишь второстепенно по отношению к рассматриваемому вопросу.)

Некоторые из наших локальных хостов Windows используют SQL Server. У нас есть требования соответствия для аудита определенных событий базы данных. Мы используем аудит SQL Server для записи этих событий в журнал событий безопасности Windows.

Проблема в том, что агент Log Analytics не отправляет интересующие нас события из журнала событий безопасности в рабочую область Log Analytics Workspace Sentinel. Это ожидаемо, исходя из нашей конфигурации ; см. дальше.

Технические нюансы

Концепции

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

Однако в настоящее время Azure допускает только относительно грубые параметры конфигурации. В журнале событий безопасности мы можем хранить ничего, все или одну из двух групп событий: «Минимальные» и «Общие». Microsoft документирует список идентификаторов событий в каждой из этих категорий.

Проблема

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

Параметры

Я вижу несколько вариантов хранения конкретных идентификаторов событий, которые нам нужны, но у каждого есть нетривиальный недостаток:

• Сохраняйте все события . Мы можем изменить конфигурацию рабочей области Sentinel для хранения всех событий из журнала событий безопасности. Проблема в том, что изменение этого параметра повлияет на все наши хосты Windows (нам нужно только увеличить количество журналов для подмножества хостов, на которых работает SQL Server). Если бы мы сделали это, наши затраты на вход и хранение данных резко возросли бы, особенно с учетом наших требований к длительному хранению.

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

• Создайте второй экземпляр Sentinel . Использование второго Sentinel с собственной рабочей областью Log Analytics позволит нам отправлять туда журналы только с серверов баз данных. В свою очередь, мы могли бы настроить рабочую область для хранения всех событий из журнала событий безопасности. Это позволило бы нам хранить нужные нам события с этих нескольких серверов баз данных, не сохраняя при этом огромное количество шума от других серверов Windows. Проблема в том, что теперь у нас будет два независимых экземпляра Sentinel, которые, если я правильно понимаю, потребуют дополнительной настройки (например, межрабочих запросов для правил аналитики, рабочих книг и т. д.) для корреляции событий безопасности между различными уровнями нашей системы. среду (например, базы данных, веб-приложения, операционные системы).

Решение?

Я предполагаю возможное решение, в котором мы будем использовать вторую, «промежуточную» рабочую область Log Analytics только для серверов баз данных. Это рабочее пространство будет настроено для хранения всех событий из журналов событий безопасности, а затем пересылки этих событий в рабочее пространство Sentinel.

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

Разумеется, вторая рабочая область будет хранить повторяющиеся записи, но мы могли бы настроить короткий период хранения, поскольку они будут перенаправлены для долгосрочного хранения в «настоящую» рабочую область, которую использует Sentinel. Дополнительные расходы будут терпимыми.

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

Итак, я надеюсь, что кто-нибудь знает простой способ пересылки записей из одной рабочей области Log Analytics в другую (т. е. исходный вопрос).

Другие идеи?

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

Заранее благодарим вас за ваше время и внимание.