Повышение безопасности Azure с помощью KQL: архитектура аналитики журналов

Добро пожаловать в нашу третью и последнюю статью из серии об улучшении безопасности Azure. В сегодняшней статье мы рассмотрим архитектуру активности журналов в Log Analytics/Azure Data Explorer, которые являются одними из продуктов, использующих язык запросов Kusto (KQL) для быстрого и эффективного извлечения данных из собранных журналов/телеметрии. На этом этапе мы знаем, как настроить нашу аналитику логов, создать наш первый запрос с помощью редактора запросов, отправить параметры диагностики в нашу аналитику логов. Пришло время углубиться и понять архитектуру аналитики журналов и двух ключевых операторов, которые будут сопровождать нас на протяжении всей серии.

Обзор архитектуры аналитики журналов

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

Во-первых, язык запросов Kusto предназначен не только для анализа журналов. Это язык, используемый большинством продуктов Microsoft Azure для запроса данных (Microsoft имеет глобальное видение — PowerShell никогда не предназначался только для Windows, понимаете?).

Одной из таких служб является Azure Data Explorer, быстрая и масштабируемая служба исследования данных для журналов и телеметрии. Он позволяет использовать несколько источников, таких как Интернет вещей, веб-сайты, приложения и т. д. У нас также есть другие продукты, такие как Azure Data Studio, Power BI и многое другое. Цель состоит в том, чтобы проанализировать данные с помощью языка запросов Kusto.

Обозреватель данных Azure важен, потому что он реализует концепцию сущностей, которая является родной для языков запросов Kusto. При создании с помощью командлетов мы увидим New-AzKustoCluster, а также строку Kusto в командлете для создания службы Azure.

При использовании Azure Data Explorer у нас есть концепция кластера, в котором хранятся базы данных. Кластер может иметь более одной базы данных.

База данных — это место, где выполняются все языки запросов Kusto, а база данных может содержать одну или несколько таблиц. Таблицы можно увидеть с помощью аналитики журналов, и они выделены на изображении ниже.

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

Существует много деталей вокруг сущностей, но вы должны знать, что сущности чувствительны к регистру, включая таблицы и столбцы. Когда вы начнете писать свои первые запросы, вы поймете, что искать данные в таблице «azureActivity» не получится, но тот же запрос при использовании «AzureActivity» будет работать как шарм.

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

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

• Будьте максимально конкретны, и общие вопросы займут больше времени. По результатам требуется очистка.
• Комментарии в KQL — это « // » перед строкой. Добавьте это, и эта строка не будет выполнена.
• При устранении неполадок с вашими запросами вы обнаружите необходимость запуска подмножества вашего запроса. Есть несколько способов справиться с этим. Вы можете выбрать нужный запрос и нажать Shift + Enter. Второй вариант — создать новую вкладку, поместить туда свой код и использовать кнопку «Выполнить».
  
• Используйте отступы — это очень помогает!
• KQL — это не SQL. Вы можете составить несколько строк операторов «где», и следующий оператор будет основан на записях, предоставленных предыдущим оператором (аналогично PowerShell с использованием конвейера). Например, если в вашем первом операторе where вы сужаетесь до последних пяти минут, второй оператор where будет работать с этими значениями. Так что играйте с умом с операторами where, чтобы перейти от более обширных данных к очень конкретной информации, которую вы ищете.
• Теоретически, при использовании нескольких операторов where попытайтесь сузить результаты по первому, используя столбец TimeGenerated.

Начало работы с запросами: поиск материала

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

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

search "RG-CAC-AP6"

Давайте пойдем на нашу игровую площадку, чтобы начать наши запросы. Сначала вы увидите, что временной диапазон определяется вне запроса (элемент 1). У нас есть два отдельных запроса в редакторе (пункт 2). Первый — самый простой оператор и строка. Во втором запросе мы меняем поведение с учетом регистра.

На том же экране у нас есть время и количество записей, которые были получены Пункт 3) из нашего запроса (мы выполняем строку 2). Результаты запроса можно увидеть в нижней части блейда. Поскольку у нас есть точная строка в нескольких таблицах (элемент 5), мы можем видеть, какие это конкретные таблицы. Если мы расширим любую данную запись, у нас будет столбец с именем таблицы (элемент 4), который помогает при поиске чего-либо.

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

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

Азуреактивити | где ResourceGroup== "RG-CAC-AP6"

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

Азуреактивити | где ( ResourceGroup== "RG-CAC-AP6" и ActivityStatusValue=="Start" )

Ваша архитектура аналитики журналов настроена и работает

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