Аудитные логи

Журнал решений о доступе — кто, к какому ресурсу и с каким разрешением обращался, и было ли действие разрешено.

Назначение

Аудитный лог фиксирует решения системы прав доступа (RBAC). Каждая запись — одна проверка доступа: какой пользователь запросил какое разрешение к какому ресурсу, была ли проверка пройдена и по какой причине.

Журнал отвечает на вопросы безопасности и compliance:

кто обращался к настройкам кластера, провайдеров и governance;
какие попытки доступа были отклонены;
какая роль дала пользователю доступ.

В лог попадают обращения к API управления: веб-интерфейс и прямые вызовы API. Не попадают запросы к моделям (inference), вход и выход из системы. Журнал не хранит содержимое изменений: значения «до» и «после» в нём нет.

Как настроить

Запись выключена по умолчанию. Режим задаётся в config.json:

{
  "authz": {
    "access_audit_mode": "fail-only"
  }
}

Режим	Что записывается
`disabled`	Ничего. Значение по умолчанию.
`all`	Все решения о доступе.
`fail-only`	Только отказы.
`success-only`	Только разрешённые обращения.
`cluster-level-only`	Только решения на глобальном уровне — без ресурсов заказчиков, команд, пользователей и виртуальных ключей.

Неизвестное значение — ошибка старта: authz.access_audit_mode: unknown mode …. После изменения перезапустите ноду.

Требования:

Записи хранятся в таблице access_audit_logs базы config store — PostgreSQL или SQLite.
В кластере все ноды пишут в общую базу. Каждая запись помечена именем ноды.

Режим all быстро наполняет таблицу: одна загрузка страницы веб-интерфейса порождает десятки записей. Для production начните с fail-only или cluster-level-only. Автоматической очистки нет — удаляйте старые записи из access_audit_logs по своему регламенту.

Страница Audit Logs

Журнал открывается в Governance → Audit Logs (/workspace/audit-logs).

Для просмотра нужно разрешение audit_log.list на глобальном уровне. Оно есть у глобальных ролей, в том числе у admin и auditor. Привязка роли к заказчику или команде доступа к журналу не даёт.

Фильтры

Фильтр	Назначение
Pick a date	Период: готовые интервалы от 5 минут до 30 дней или произвольный диапазон.
All permissions	Одно или несколько разрешений, например `cluster.config.read`.
All scope types	Уровень ресурса: `global`, `customer`, `team`, `user`, `vk`.
Search resource…	Поиск по части пути ресурса.
All / Allowed / Denied	Решение.

Страница не обновляется сама — нажмите кнопку обновления справа от фильтров.

Колонки

Колонка	Значение
Time	Время проверки.
User	Пользователь. При наведении — его идентификатор.
Permission	Проверенное разрешение.
Resource	Ресурс: путь API или идентификатор сущности.
Scope	Уровень ресурса. Для заказчика или команды — ещё и её имя.
Matched role	Роль, которая дала доступ.
Decision	`allowed` — разрешено, `denied` — отклонено.
Reason	Причина решения.
Node	Нода кластера, которая приняла решение.

Основные причины:

Reason	Значение
`granted`	Доступ дала привязка роли.
`g.admin-fast-path`	Пользователь — глобальный администратор, проверка пропущена.
`legacy-role`	Доступ дала встроенная роль пользователя.
`auth-disabled`	Аутентификация выключена, доступ открыт всем.
`no-binding`	У пользователя нет подходящей привязки роли.
`not-effective`	Разрешение не действует на этом уровне ресурса.
`no-scope`	Не удалось определить уровень ресурса.

На странице по 50 записей, новые сверху. Открытие самой страницы тоже попадает в журнал — как проверка разрешения audit_log.list.

Записи также доступны через API: GET /api/auth/rbac/audit-logs с фильтрами from, to, relative, permission, scope_type, resource и allowed. Подробнее — в справочнике API.