Аудитный лог

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

Одна запись в аудитном логе может выглядеть так:

{"@timestamp":"2025-11-03T18:07:39.056211Z","@log_type":"audit","operation":"ExecuteQueryRequest","database":"/my_dir/db1","status":"SUCCESS","subject":"serviceaccount@as","remote_address":"ipv6:[xxxx:xxx:xxx:xxx:x:xxxx:xxx:xxxx]"}

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

  • доступ к данным через DML-запросы;
  • операции управления схемой или конфигурацией;
  • изменения прав или настроек контроля доступа;
  • административные действия пользователей.

Секция audit_config в конфигурации кластера определяет, какие аудит-логи собираются, как они сериализуются и куда доставляются. Подробнее см. в разделе Конфигурация аудитного лога.

Ключевые понятия

Аудитные события

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

Источники аудитных событий

Источник аудитных событий — это служба или подсистема YDB, которая может генерировать аудитные события. Каждый источник имеет уникальный идентификатор (UID) и может предоставлять дополнительные атрибуты, характерные для этого источника. Некоторые источники требуют дополнительной настройки, например включения функциональных флагов, чтобы начать генерировать события. Подробнее см. Обзор источников аудитных событий.

Классы логирования

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

Класс логирования

Описание

ClusterAdmin

Запросы на администрирование кластера.

DatabaseAdmin

Запросы на администрирование баз данных.

Login

Запросы на вход.

NodeRegistration

Регистрация нод.

Ddl

DDL-запросы.

Dml

DML-запросы.

Operations

Асинхронные операции RPC, для отслеживания результата которых требуется опрос.

ExportImport

Операции экспорта и импорта данных.

Acl

Операции с ACL (списками контроля доступа).

AuditHeartbeat

Синтетические heartbeat-сообщения, подтверждающие работу аудитного логирования.

Default

Настройки по умолчанию для любого компонента без собственной секции конфигурации.

На данный момент не все источники аудитных событий группируют события по классам. Чаще всего для их записи будет достаточно базовой конфигурации. Подробности см. в разделе Обзор источников аудитных событий.

Фазы логирования

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

Фаза логирования

Описание

Received

Запрос получен, выполнены начальные проверки и аутентификация. Атрибут status устанавливается в значение IN-PROCESS.
Эта фаза отключена по умолчанию; чтобы включить её, добавьте Received в log_class_config.log_phase.

Completed

Запрос полностью завершён. Атрибут status принимает значение SUCCESS или ERROR. Эта фаза включена по умолчанию, если log_class_config.log_phase не задан.

Направления аудитного лога

Направление аудитного лога — получатель потока аудитного лога.

На данный момент вы можете настроить следующие направления для аудитного лога:

  • файл на каждой ноде кластера YDB;
  • агент, который доставляет метрики Unified Agent;
  • стандартный поток ошибок stderr.

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

Если поток перенаправлен в файл, доступ к аудитному логу определяется правами файловой системы. Сохранение аудитного лога в файл рекомендуется для продуктивных инсталляций.

Для тестовых инсталляций направляйте аудитный лог в стандартный поток ошибок (stderr). Дальнейшая обработка потока зависит от настроек логирования кластера YDB.

Обзор источников аудитных событий

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

Источник / UID

Что фиксирует

Требования к настройке

Schemeshard
schemeshard

Операции со схемой, изменения ACL и действия по управлению пользователями.

Входит в базовую конфигурацию аудита.

gRPC-сервисы
grpc-proxy

Внешние gRPC-запросы YDB.

Включите соответствующие классы логирования и при необходимости фазы логирования.

gRPC-соединение
grpc-conn

События подключения и отключения клиентов.

Включите функциональный флаг enable_grpc_audit.

gRPC-аутентификация
grpc-login

Попытки аутентификации в gRPC.

Включите класс Login в log_class_config.

Сервис мониторинга
monitoring

HTTP-запросы, обрабатываемые эндпоинтом мониторинга.

Включите класс ClusterAdmin в log_class_config.

Heartbeat
audit

Синтетические heartbeat-события, подтверждающие работоспособность аудитного логирования.

Включите класс AuditHeartbeat в log_class_config и при необходимости настройте параметры heartbeat.

BlobStorage Controller
bsc

Изменения конфигурации BlobStorage Controller из консоли.

Входит в базовую конфигурацию аудита.

Distconf
distconf

Обновления распределённой конфигурации.

Входит в базовую конфигурацию аудита.

Web login
web-login

Взаимодействия с виджетом аутентификации веб-консоли.

Входит в базовую конфигурацию аудита.

Console
console

Операции жизненного цикла баз данных и изменения динамической конфигурации.

Входит в базовую конфигурацию аудита.

Атрибуты аудитных событий

Атрибуты делятся на две группы:

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

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

Общие атрибуты

В таблице ниже перечислены общие атрибуты.

Атрибут

Описание

subject

SID источника события, если обязательная аутентификация включена, иначе {none}.

sanitized_token

Частично маскированный токен аутентификации, использованный для выполнения запроса. Позволяет связывать события и при этом скрывать исходные учётные данные. Если аутентификация не выполнялась, значение будет {none}.

operation

Название операции (например, ALTER DATABASE, CREATE TABLE).

component

Уникальный идентификатор источника аудитных событий.

status

Статус завершения операции.
Возможные значения:

  • SUCCESS: операция завершена успешно.
  • ERROR: операция завершилась с ошибкой.
  • IN-PROCESS: операция выполняется.

reason

Сообщение об ошибке.

request_id

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

remote_address

IP-адрес клиента, отправившего запрос.

detailed_status

Статус, который передаёт источник аудитных событий YDB.

database

Путь базы данных (например, /my_dir/db).

cloud_id

Идентификатор облака базы данных YDB.

folder_id

Идентификатор каталога кластера или базы данных YDB.

resource_id

Идентификатор ресурса базы данных YDB.

Schemeshard

UID: schemeshard.
Регистрируемые операции: операции со схемой, инициированные DDL-запросами, изменения ACL и действия управления пользователями.
Как включить: требуется только базовая конфигурация аудита.

Таблица ниже перечисляет дополнительные атрибуты, специфичные для источника Schemeshard.

Атрибут

Описание

Общие атрибуты Schemeshard

>

tx_id

Уникальный идентификатор транзакции. Этот идентификатор помогает различать события разных операций.
Обязательный.

paths

Список путей в базе данных, которые изменяет операция (например, [/my_dir/db/table-a, /my_dir/db/table-b]).
Необязательный.

Атрибуты владения и прав доступа

>

new_owner

SID нового владельца объекта при передаче владения.

acl_add

Список добавленных разрешений в краткой записи (например, [+R:someuser]).

acl_remove

Список отозванных разрешений в краткой записи (например, [-R:someuser]).

Пользовательские атрибуты

>

user_attrs_add

Список пользовательских атрибутов, добавленных при создании объектов или обновлении атрибутов (например, [attr_name1: A, attr_name2: B]).

user_attrs_remove

Список пользовательских атрибутов, удалённых при создании объектов или обновлении атрибутов (например, [attr_name1, attr_name2]).

Атрибуты входа/аутентификации

>

login_user

Имя пользователя, зафиксированное при операциях входа.

login_group

Имя группы, зафиксированное при операциях входа.

login_member

Изменения членства.

login_user_change

Изменения, применённые к настройкам пользователя.

login_user_level

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

Атрибуты операций импорта/экспорта

>

id

Уникальный идентификатор операции экспорта или импорта.

uid

Заданная пользователем метка операции.

start_time

Время начала операции в формате ISO 8601.

end_time

Время завершения операции в формате ISO 8601.

last_login

Время последнего успешного входа пользователя в формате ISO 8601.

Атрибуты экспорта

>

export_type

Направление экспорта. Возможные значения: yt, s3.

export_item_count

Количество экспортированных элементов.

export_yt_prefix

Префикс пути для экспорта в YT.

export_s3_bucket

Имя S3-бакета, используемого для экспорта.

export_s3_prefix

Префикс пути для экспорта в S3.

Атрибуты импорта

>

import_type

Тип источника импорта. Всегда s3.

import_item_count

Количество импортированных элементов.

import_s3_bucket

Имя S3-бакета, используемого для импорта.

import_s3_prefix

Префикс источника в S3.

gRPC-сервисы

UID: grpc-proxy.
Регистрируемые операции: все внешние (не внутренние) gRPC-запросы.
Как включить: требуется указать классы логирования в конфигурации аудита.
Классы логирования: зависят от типа RPC-запроса: Ddl, Dml, Operations, ClusterAdmin, DatabaseAdmin и другие классы.
Фазы логирования: Received, Completed.

Таблица ниже перечисляет дополнительные атрибуты, специфичные для источника gRPC services.

Атрибут

Описание

Общие gRPC-атрибуты

>

grpc_method

Имя RPC-метода.
Необязательный.

request

Санитизированное представление входящего запроса.
Необязательный.

start_time

Время начала операции в формате ISO 8601.
Обязательный.

end_time

Время завершения операции в формате ISO 8601.
Необязательный.

Атрибуты транзакций

>

tx_id

Идентификатор транзакции.

begin_tx

Флаг со значением 1, если запрос запускает новую транзакцию.

commit_tx

Показывает, завершается ли транзакция этим запросом. Возможные значения: true, false.

Поля запроса

>

query_text

Санитизированный текст YQL-запроса.

prepared_query_id

Идентификатор подготовленного запроса.

program_text

MiniKQL-программа, отправленная с запросом.

schema_changes

Описание изменений схемы, запрошенных в операции.

table

Полный путь таблицы.

row_count

Количество строк, обработанных пакетной вставкой данных.

tablet_id

Идентификатор таблетки.

gRPC-соединение

UID: grpc-conn.
Регистрируемые операции: изменения состояния соединения (подключение и отключение).
Как включить: активируйте функциональный флаг enable_grpc_audit.

Этот источник использует только общие атрибуты.

gRPC-аутентификация

UID: grpc-login.
Регистрируемые операции: аутентификация в gRPC.
Как включить: требуется указать классы логирования в конфигурации аудита.
Классы логирования: Login.
Фазы логирования: Completed.

Таблица ниже перечисляет дополнительные атрибуты, специфичные для источника gRPC authentication.

Атрибут

Описание

login_user

Имя пользователя. Обязательный.

login_user_level

Уровень привилегий пользователя, записанный в событиях аудита. Это поле принимает значение admin. Необязательный.

Сервис мониторинга

UID: monitoring.
Регистрируемые операции: HTTP-запросы, обрабатываемые сервисом мониторинга.
Как включить: требуется указать классы логирования в конфигурации аудита.
Классы логирования: ClusterAdmin.
Фазы логирования: Received, Completed.

Таблица ниже перечисляет дополнительные атрибуты, специфичные для источника Monitoring service.

Атрибут

Описание

method

HTTP-метод запроса, например POST, GET.
Обязательный.

url

Путь запроса без параметров строки запроса.
Обязательный.

params

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

body

Тело запроса (усечено до 2 МБ с добавлением суффикса TRUNCATED_BY_YDB).
Необязательный.

Heartbeat

UID: audit.
Регистрируемые операции: периодические heartbeat-сообщения аудита.
Как включить: укажите классы логирования в конфигурации аудита.
Классы логирования: AuditHeartbeat.
Фазы логирования: Completed.

Таблица ниже перечисляет дополнительные атрибуты, специфичные для источника Heartbeat.

Атрибут

Описание

node_id

Идентификатор ноды, на которой произошло событие. Обязательный.

BlobStorage Controller

UID: bsc.
Регистрируемые операции: запросы замены конфигурации (TEvControllerReplaceConfigRequest), отправляемые консолью.
Как включить: требуется только базовая конфигурация аудита.

Таблица ниже перечисляет дополнительные атрибуты, специфичные для источника BlobStorage Controller.

Атрибут

Описание

old_config

Снапшот предыдущей конфигурации BlobStorage Controller в формате YAML.
Необязательный.

new_config

Снапшот конфигурации, которая заменила предыдущую.
Необязательный.

Distconf

UID: distconf.
Регистрируемые операции: изменения распределённой конфигурации.
Как включить: требуется только базовая конфигурация аудита.

Таблица ниже перечисляет дополнительные атрибуты, специфичные для источника Distconf.

Атрибут

Описание

old_config

Снапшот конфигурации, которая была активна до принятия распределённого обновления. Distconf сериализует его в YAML. Обязательный.

new_config

Снапшот конфигурации, который Distconf зафиксировал после изменения. Обязательный.

Web login

UID: web-login.
Регистрируемые операции: отслеживает взаимодействия с виджетом аутентификации веб-консоли YDB.
Как включить: требуется только базовая конфигурация аудита.

Этот источник использует только общие атрибуты.

Console

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

Таблица ниже перечисляет дополнительные атрибуты, специфичные для источника Console.

Атрибут

Описание

old_config

Снапшот конфигурации, которая действовала до применения запроса из консоли. Необязательный.

new_config

Снапшот конфигурации, применённой консолью. Необязательный.

Конфигурация аудитного лога

Включение аудитного лога

Аудитное логирование работает на уровне всего кластера. Для базовой конфигурации добавьте раздел audit_config в конфигурацию кластера и укажите одно или несколько направлений потока (file_backend, unified_agent_backend, stderr_backend):

audit_config:
  file_backend:
    format: audit_log_format
    file_path: "path_to_log_file"
  unified_agent_backend:
    format: audit_log_format
    log_name: session_meta_log_name
  stderr_backend:
    format: audit_log_format

Параметры audit_config

Все поля являются необязательными.

Ключ

Описание

stderr_backend

Перенаправляет аудитный лог в стандартный поток ошибок (stderr). Для тестовых инсталляций направляйте аудитный лог в стандартный поток ошибок (stderr). Дальнейшая обработка потока зависит от настроек логирования кластера YDB. См. структуру настроек backend.

file_backend

Записывает аудитный лог в файл на каждой ноде кластера. Если поток перенаправлен в файл, доступ к аудитному логу определяется правами файловой системы. Сохранение аудитного лога в файл рекомендуется для продуктовых инсталляций. См. структуру настроек backend.

unified_agent_backend

Отправляет аудитный лог в Unified Agent. Дополнительно необходимо задать секцию uaclient_config в конфигурации кластера. См. структуру настроек backend.

log_class_config

Массив правил аудита для разных классов логирования. См. конфигурацию классов логирования.

heartbeat

Необязательная конфигурация heartbeat. См. настройки heartbeat.

Конфигурация направлений

Каждое направление поддерживает следующие поля:

Поле

Описание

format

Формат аудитного лога. Значение по умолчанию — JSON. Подробнее см. раздел Формат логов.
Необязательный.

file_path

Путь к файлу, в который будет записываться аудитный лог. Если путь или файл отсутствуют, они будут созданы на каждой ноде при запуске кластера. Если файл существует, данные будут дозаписываться. Только для file_backend.
Обязательный.

log_name

Метаданные сессии, передаваемые вместе с сообщением. По ним можно перенаправлять поток логов в один или несколько дочерних каналов с условием _log_name: "session_meta_log_name". Только для unified_agent_backend.
Необязательный.

log_json_envelope

Шаблон JSON, который оборачивает каждую запись лога. Шаблон должен содержать плейсхолдер %message%, заменяемый сериализованной аудитной записью. См. раздел Формат конверта.
Необязательный.

Формат логов

Поле format определяет формат сериализации аудитных событий. Поддерживаются следующие форматы:

Формат

Описание

JSON

Каждое аудитное событие сериализуется в однострочный JSON-объект с префиксом из временной метки в формате ISO 8601.
Пример: <time>: {"k1": "v1", "k2": "v2", ...}
k1, k2, …, kn — атрибуты аудитного лога; v1, v2, …, vn — их значения.

TXT

Каждое аудитное событие сериализуется в однострочную строку key=value с префиксом из временной метки в формате ISO 8601.
Пример: <time>: k1=v1, k2=v2, ...
k1, k2, …, kn — атрибуты аудитного лога; v1, v2, …, vn — их значения.

JSON_LOG_COMPATIBLE

Каждое аудитное событие сериализуется в однострочный JSON-объект, совместимый с целями, совместно используемыми с отладочными логами. Объект содержит поле @timestamp с временной меткой ISO 8601 и поле @log_type со значением audit.
Пример: {"@timestamp": "<ISO 8601 time>", "@log_type": "audit", "k1": "v1", "k2": "v2", ...}
@timestamp хранит временную метку ISO 8601; k1, k2, …, kn — атрибуты аудитного лога; v1, v2, …, vn — их значения.

Формат конверта

Backend может оборачивать аудитные события пользовательским конвертом перед отправкой, если указать поле log_json_envelope. Шаблон должен содержать плейсхолдер %message%, который заменяется сериализованной аудитной записью в выбранном формате.

Например, следующая конфигурация выводит аудитные события в stderr в формате JSON, обёрнутые пользовательским конвертом:

audit_config:
  stderr_backend:
    format: JSON
    log_json_envelope: '{"audit": %message%, "source": "ydb-audit-log"}'

Подробнее о выводе см. в разделе Пример с JSON-конвертом.

Настройка классов логирования

Каждый элемент log_class_config поддерживает следующие поля:

Поле

Описание

log_class

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

enable_logging

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

exclude_account_type

Массив типов аккаунтов (Anonymous, User, Service, ServiceImpersonatedFromUser), для которых события исключаются, даже если логирование включено.
Необязательный.

log_phase

Массив фаз обработки запроса, которые нужно логировать. См. раздел Фазы логирования.
Необязательный.

Настройки heartbeat

Heartbeat-события помогают контролировать состояние подсистемы аудитного логирования. Они позволяют настраивать оповещения об отсутствии аудитных событий без ложных срабатываний в периоды без активности.

Параметр heartbeat.interval_seconds задаёт частоту записи heartbeat-событий. Значение 0 отключает сообщения heartbeat.

Примеры конфигураций

Простая конфигурация. Ниже приведена простая конфигурация, сохраняющая аудитный лог в текстовом виде в файле с форматом TXT.

audit_config:
  file_backend:
    format: TXT
    file_path: "/var/log/ydb-audit.log"

Расширенная конфигурация. Ниже приведён расширенный пример конфигурации аудитного лога:

  • YDB отправляет аудитные логи в Unified Agent в формате TXT с меткой audit, а также выводит его в stderr в формате JSON;
  • настройки Default включают логирование всех классов в фазе Completed;
  • дополнительно ClusterAdmin настроен для логирования фазы Received, а DatabaseAdmin — для исключения событий от анонимных пользователей.
audit_config:
  unified_agent_backend:
    format: TXT
    log_name: audit
  stderr_backend:
    format: JSON
  log_class_config:
    - log_class: ClusterAdmin
      enable_logging: true
      log_phase: [Received, Completed]
    - log_class: DatabaseAdmin
      enable_logging: true
      log_phase: [Completed]
      exclude_account_type: [Anonymous]
    - log_class: Default
      enable_logging: true
  heartbeat:
    interval_seconds: 60

Примеры

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

Формат JSON создаёт записи следующего вида:

2023-03-14T10:41:36.485788Z: {"paths":"[/my_dir/db1/some_dir]","tx_id":"281474976775658","database":"/my_dir/db1","remote_address":"ipv6:[xxxx:xxx:xxx:xxx:x:xxxx:xxx:xxxx]:xxxxx","status":"SUCCESS","subject":"{none}","sanitized_token":"{none}","detailed_status":"StatusAccepted","operation":"MODIFY ACL","component":"schemeshard","acl_add":"[+(ConnDB):subject:-]"}
2023-03-13T20:07:30.927210Z: {"reason":"Check failed: path: '/my_dir/db1/some_dir', error: path exist, request accepts it (id: [OwnerId: 72075186224037889, LocalPathId: 3], type: EPathTypeDir, state: EPathStateNoChanges)","paths":"[/my_dir/db1/some_dir]","tx_id":"844424930216970","database":"/my_dir/db1","remote_address":"ipv6:[xxxx:xxx:xxx:xxx:x:xxxx:xxx:xxxx]:xxxxx","status":"SUCCESS","subject":"{none}","sanitized_token":"{none}","detailed_status":"StatusAlreadyExists","operation":"CREATE DIRECTORY","component":"schemeshard"}
2025-11-03T18:07:39.056211Z: {"@log_type":"audit","begin_tx":1,"commit_tx":1,"component":"grpc-proxy","database":"/my_dir/db1","detailed_status":"SUCCESS","end_time":"2025-11-03T18:07:39.056204Z","grpc_method":"Ydb.Query.V1.QueryService/ExecuteQuery","operation":"ExecuteQueryRequest","query_text":"SELECT * FROM `my_row_table`;","remote_address":"ipv6:[xxxx:xxx:xxx:xxx:x:xxxx:xxx:xxxx]","sanitized_token":"xxxxxxxx.**","start_time":"2025-11-03T18:07:39.054863Z","status":"SUCCESS","subject":"serviceaccount@as"}
2025-11-03T17:41:44.203214Z: {"component":"monitoring","remote_address":"ipv6:[xxxx:xxx:xxx:xxx:x:xxxx:xxx:xxxx]","operation":"HTTP REQUEST","method":"POST","url":"/viewer/query","params":"base64=false&schema=multipart","body":"{\"query\":\"SELECT * FROM `my_row_table`;\",\"database\":\"/local\",\"action\":\"execute-query\",\"syntax\":\"yql_v1\"}","status":"IN-PROCESS","reason":"Execute"}

Формат TXT создаёт записи следующего вида:

2023-03-14T10:41:36.485788Z: component=schemeshard, tx_id=281474976775658, remote_address=ipv6:[xxxx:xxx:xxx:xxx:x:xxxx:xxx:xxxx]:xxxxx, subject={none}, database=/my_dir/db1, operation=MODIFY ACL, paths=[/my_dir/db1/some_dir], status=SUCCESS, detailed_status=StatusSuccess, acl_add=[+(ConnDB):subject:-]
2023-03-13T20:07:30.927210Z: component=schemeshard, tx_id=281474976775657, remote_address=ipv6:[xxxx:xxx:xxx:xxx:x:xxxx:xxx:xxxx]:xxxxx, subject={none}, database=/my_dir/db1, operation=CREATE DIRECTORY, paths=[/my_dir/db1/some_dir], status=SUCCESS, detailed_status=StatusAlreadyExists, reason=Check failed: path: '/my_dir/db1/some_dir', error: path exist, request accepts it (id: [OwnerId: 72075186224037889, LocalPathId: 3], type: EPathTypeDir, state: EPathStateNoChanges)
2025-11-03T18:07:39.056211Z: component=grpc-proxy, tx_id=281474976775656, remote_address=ipv6:[xxxx:xxx:xxx:xxx:x:xxxx:xxx:xxxx]:xxxxx, subject=serviceaccount@as, database=/my_dir/db1, operation=ExecuteQueryRequest, query_text=SELECT * FROM `my_row_table`; status=SUCCESS, detailed_status=StatusSuccess, begin_tx=1, commit_tx=1, end_time=2025-11-03T18:07:39.056204Z, grpc_method=Ydb.Query.V1.QueryService/ExecuteQuery, sanitized_token=xxxxxxxx.**, start_time=2025-11-03T18:07:39.054863Z
2025-11-03T17:41:44.203214Z: component=monitoring, remote_address=ipv6:[xxxx:xxx:xxx:xxx:x:xxxx:xxx:xxxx], operation=HTTP REQUEST, method=POST, url=/viewer/query, params=base64=false&schema=multipart, body={"query":"SELECT * FROM `my_row_table`;","database":"/local","action":"execute-query","syntax":"yql_v1"}, status=IN-PROCESS, reason=Execute

Формат JSON_LOG_COMPATIBLE создаёт записи следующего вида:

{"@timestamp":"2023-03-14T10:41:36.485788Z","@log_type":"audit","paths":"[/my_dir/db1/some_dir]","tx_id":"281474976775658","database":"/my_dir/db1","remote_address":"ipv6:[xxxx:xxx:xxx:xxx:x:xxxx:xxx:xxxx]:xxxxx","status":"SUCCESS","subject":"{none}","detailed_status":"StatusAccepted","operation":"MODIFY ACL","component":"schemeshard","acl_add":"[+(ConnDB):subject:-]"}
{"@timestamp":"2023-03-13T20:07:30.927210Z","@log_type":"audit","reason":"Check failed: path: '/my_dir/db1/some_dir', error: path exist, request accepts it (id: [OwnerId: 72075186224037889, LocalPathId: 3], type: EPathTypeDir, state: EPathStateNoChanges)","paths":"[/my_dir/db1/some_dir]","tx_id":"844424930216970","database":"/my_dir/db1","remote_address":"ipv6:[xxxx:xxx:xxx:xxx:x:xxxx:xxx:xxxx]:xxxxx","status":"SUCCESS","subject":"{none}","detailed_status":"StatusAlreadyExists","operation":"CREATE DIRECTORY","component":"schemeshard"}
{"@timestamp":"2025-11-03T18:07:39.056211Z","@log_type":"audit","begin_tx":1,"commit_tx":1,"component":"grpc-proxy","database":"/my_dir/db1","detailed_status":"SUCCESS","end_time":"2025-11-03T18:07:39.056204Z","grpc_method":"Ydb.Query.V1.QueryService/ExecuteQuery","operation":"ExecuteQueryRequest","query_text":"SELECT * FROM `my_row_table`;","remote_address":"ipv6:[xxxx:xxx:xxx:xxx:x:xxxx:xxx:xxxx]","start_time":"2025-11-03T18:07:39.054863Z","status":"SUCCESS","subject":"serviceaccount@as","sanitized_token":"xxxxxxxx.**"}
{"@timestamp":"2025-11-03T17:41:44.203214Z","@log_type":"audit","component":"monitoring","remote_address":"ipv6:[xxxx:xxx:xxx:xxx:x:xxxx:xxx:xxxx]","operation":"HTTP REQUEST","method":"POST","url":"/viewer/query","params":"base64=false&schema=multipart","body":"{\"query\":\"SELECT * FROM `my_row_table`;\",\"database\":\"/local\",\"action\":\"execute-query\",\"syntax\":\"yql_v1\"}","status":"IN-PROCESS","reason":"Execute"}

Шаблон JSON-конверта {"audit": %message%, "source": "ydb-audit-log"} создаёт записи следующего вида:

{"audit":"2023-03-14T10:41:36.485788Z: {\"paths\":\"[/my_dir/db1/some_dir]\",\"tx_id\":\"281474976775658\",\"database\":\"/my_dir/db1\",\"remote_address\":\"ipv6:[xxxx:xxx:xxx:xxx:x:xxxx:xxx:xxxx]:xxxxx\",\"status\":\"SUCCESS\",\"subject\":\"{none}\",\"detailed_status\":\"StatusAccepted\",\"operation\":\"MODIFY ACL\",\"component\":\"schemeshard\",\"acl_add\":\"[+(ConnDB):subject:-]\"}\n","source":"ydb-audit-log"}
{"audit":"2023-03-13T20:07:30.927210Z: {\"reason\":\"Check failed: path: '/my_dir/db1/some_dir', error: path exist, request accepts it (id: [OwnerId: 72075186224037889, LocalPathId: 3], type: EPathTypeDir, state: EPathStateNoChanges)\",\"paths\":\"[/my_dir/db1/some_dir]\",\"tx_id\":\"844424930216970\",\"database\":\"/my_dir/db1\",\"remote_address\":\"ipv6:[xxxx:xxx:xxx:xxx:x:xxxx:xxx:xxxx]:xxxxx\",\"status\":\"SUCCESS\",\"subject\":\"{none}\",\"detailed_status\":\"StatusAlreadyExists\",\"operation\":\"CREATE DIRECTORY\",\"component\":\"schemeshard\"}\n","source":"ydb-audit-log"}
{"audit":"2025-11-03T18:07:39.056211Z: {\"@log_type\":\"audit\",\"begin_tx\":1,\"commit_tx\":1,\"component\":\"grpc-proxy\",\"database\":\"/my_dir/db1\",\"detailed_status\":\"SUCCESS\",\"end_time\":\"2025-11-03T18:07:39.056204Z\",\"grpc_method\":\"Ydb.Query.V1.QueryService/ExecuteQuery\",\"operation\":\"ExecuteQueryRequest\",\"query_text\":\"SELECT * FROM `my_row_table`;\",\"remote_address\":\"ipv6:[xxxx:xxx:xxx:xxx:x:xxxx:xxx:xxxx]\",\"sanitized_token\":\"xxxxxxxx.**\",\"start_time\":\"2025-11-03T18:07:39.054863Z\",\"status\":\"SUCCESS\",\"subject\":\"serviceaccount@as\"}\n","source":"ydb-audit-log"}
{"audit":"2025-11-03T17:41:44.203214Z: {\"component\":\"monitoring\",\"remote_address\":\"ipv6:[xxxx:xxx:xxx:xxx:x:xxxx:xxx:xxxx]\",\"operation\":\"HTTP REQUEST\",\"method\":\"POST\",\"url\":\"/viewer/query\",\"params\":\"base64=false&schema=multipart\",\"body\":\"{\\\"query\\\":\\\"SELECT * FROM `my_row_table`;\\\",\\\"database\\\":\\\"/local\\\",\\\"action\\\":\\\"execute-query\\\",\\\"syntax\\\":\\\"yql_v1\\\"}\",\"status\":\"IN-PROCESS\",\"reason\":\"Execute\"}\n","source":"ydb-audit-log"}

Та же запись аудитного лога, представленная для удобства чтения:

{
  "paths": "[/my_dir/db1/some_dir]",
  "tx_id": "281474976775658",
  "database": "/my_dir/db1",
  "remote_address": "ipv6:[xxxx:xxx:xxx:xxx:x:xxxx:xxx:xxxx]:xxxxx",
  "status": "SUCCESS",
  "subject": "{none}",
  "detailed_status": "StatusAccepted",
  "operation": "MODIFY ACL",
  "component": "schemeshard",
  "acl_add": "[+(ConnDB):subject:-]"
}
Предыдущая
Начальная настройка безопасности
Следующая
Шифрование