Журнал аудита¶

Что вы сделаете¶

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

кто, когда и кому предоставил или отозвал системное право?

Также вы поймёте границы этого журнала и не будете ошибочно считать его полным журналом всех действий пользователей в ИИ Студии.

1. Что такое журнал аудита в текущей версии¶

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

Он фиксирует такие события, как:

администратор
    ↓
предоставил системное право
    ↓
пользователю / роли / группе

или:

администратор
    ↓
отозвал системное право
    ↓
у пользователя / роли / группы

Это очень важно для расследования изменений административного доступа.

2. Что журнал аудита не означает¶

Наличие раздела «Журнал аудита» не означает, что система автоматически записывает в одну таблицу вообще всё происходящее в Студии.

Текущий журнал системных прав не следует путать с:

журналами контейнеров;
журналом входов веб-сервера;
журналами модели;
журналами интернет-поиска;
журналами работы с Яндекс Облаком;
журналами Billing/FinOps;
историей разговоров;
историей плановых заданий;
журналами внешних корпоративных сервисов.

Например, вопрос:

«Кто предоставил пользователю право управлять пользователями?»

— относится к журналу аудита системных прав.

А вопрос:

«Почему вчера в 15:41 Yandex AI вернул 403?»

— относится к журналам соответствующего шлюза и диагностике интеграции.

Подробнее: Журналы.

3. Какие сведения показывает запись¶

Для события изменения системного права администратору доступны основные поля:

Поле	Что означает
Время	когда произошло изменение
Инициатор	кто выполнил административное действие
Действие	право предоставлено или отозвано
Объект	пользователь, роль или другой субъект доступа
Возможность	какое именно системное полномочие изменено

Эти сведения позволяют восстановить цепочку изменения доступа без догадок.

4. Пример¶

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

Не следует сразу менять все роли и удалять учётные записи.

Сначала установите факт.

Откройте:

Панель администратора
    → Системные права
    → Журнал аудита

Найдите пользователя или соответствующую роль.

Результат может выглядеть логически так:

15.09.2026 10:34
Инициатор: admin@example.org
Действие: Предоставлено
Объект: operators@example.org
Возможность: Управление пользователями

Теперь у вас есть конкретное событие, а не предположение.

5. Как открыть журнал¶

Шаг 1. Войдите в административную панель¶

Используйте учётную запись, которой разрешён просмотр аудита.

Полный статус ADMIN для этого не обязателен, если вашей модели доступа делегировано отдельное системное право просмотра журнала.

Шаг 2. Откройте «Системные права»¶

Перейдите в раздел управления системными полномочиями.

Шаг 3. Откройте вкладку «Журнал аудита»¶

Убедитесь, что отображается список событий.

Шаг 4. Ограничьте выборку¶

Используйте фильтры вместо просмотра тысяч строк вручную.

6. Фильтр по времени¶

Если известно примерное время изменения, сначала ограничьте период.

Например:

С: 2026-09-15 00:00
По: 2026-09-15 23:59

Это особенно полезно после:

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

7. Фильтр по действию¶

Основные действия для текущего журнала:

Предоставлено
Отозвано

Если расследуется неожиданное расширение полномочий, начните с «Предоставлено».

Если сотрудник потерял доступ — с «Отозвано».

8. Фильтр по инициатору¶

Фильтр по инициатору отвечает на вопрос:

кто выполнял изменения?

Он полезен, если:

в организации несколько администраторов;
часть полномочий делегирована службе поддержки;
необходимо проверить действия конкретной административной учётной записи;
обнаружена подозрительная активность.

9. Фильтр по объекту¶

Объект — тот, чьи системные полномочия были изменены.

Это может быть, например:

пользователь;
роль;
группа;
другой поддерживаемый субъект доступа.

При расследовании проблемы конкретного сотрудника поиск по объекту обычно самый быстрый.

10. Фильтр по возможности¶

Если известно, какое право вызывает вопрос, фильтруйте по нему.

Примеры:

Управление пользователями
Управление группами
Управление ролями
Просмотр конфигурации
Изменение конфигурации
Просмотр журнала аудита

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

11. Как расследовать неожиданное право¶

Допустим, сотрудник получил доступ к административной панели.

Действуйте по порядку.

Шаг 1. Проверьте эффективный доступ пользователя¶

Откройте карточку пользователя.

Запишите:

роли;
группы;
назначенные профили;
точечные системные полномочия.

Шаг 2. Проверьте роль¶

Возможно, полномочие пришло не напрямую пользователю, а через роль.

Шаг 3. Проверьте группу¶

Пользователь мог попасть в группу, которая связана с ролью или конфигурацией.

Шаг 4. Откройте журнал аудита¶

Ищите последние предоставления соответствующего системного права.

Шаг 5. Установите инициатора¶

Не делайте вывод только по времени.

Используйте поле «Инициатор».

Шаг 6. Сопоставьте изменение с заявкой¶

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

заявкой службы поддержки;
задачей в системе управления работами;
запросом руководителя;
утверждённым изменением;
номером инцидента.

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

12. Почему нужен внешний номер изменения¶

Рекомендуемый процесс:

заявка / изменение CHG-1042
        ↓
одобрение
        ↓
администратор меняет право
        ↓
событие появляется в аудите
        ↓
проверка результата

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

13. Проверка нового административного процесса¶

После внедрения нового порядка выдачи прав проведите контрольный тест.

Создайте тестового пользователя или используйте специальную испытательную учётную запись.

Тест 1. Предоставление¶

откройте системные права;
предоставьте тестовое полномочие;
дождитесь сохранения;
откройте журнал аудита;
найдите новую запись;
проверьте инициатора;
проверьте объект;
проверьте название права.

Тест 2. Отзыв¶

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

Ожидаемый результат:

событие 1: право предоставлено
событие 2: право отозвано

14. Почему старую запись нельзя заменять новой¶

Аудит нужен именно как история изменений.

Неправильная модель:

у пользователя сейчас нет права
→ значит ничего не происходило

Правильная модель:

право было предоставлено
→ использовалось определённый период
→ затем было отозвано

Для расследования важна вся последовательность.

15. Экспорт журнала¶

Текущая административная панель позволяет экспортировать совпадающие записи журнала.

Перед экспортом задайте фильтры, если нужен конкретный период или объект.

Экспорт полезен для:

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

16. Экспорт тоже является чувствительным документом¶

Файл аудита может содержать:

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

Поэтому не следует:

отправлять его в публичный чат;
публиковать по открытой ссылке;
прикладывать к внешней заявке без очистки;
хранить в общедоступном каталоге.

17. Синхронизация времени¶

Аудит теряет большую часть ценности, если часы серверов расходятся.

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

Проверьте:

timedatectl

Обратите внимание на:

текущую дату;
часовой пояс;
состояние синхронизации;
разницу между временем сервера и временем рабочего места администратора.

18. Часовой пояс при расследовании¶

Всегда фиксируйте, в каком часовом поясе указано время.

Плохая запись в отчёте:

ошибка произошла в 10:15

Лучше:

ошибка зафиксирована 15.09.2026 в 10:15 MSK

или используйте другой однозначно обозначенный часовой пояс организации.

19. Аудит и журналы сервисов — разные источники¶

Пример расследования:

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

Эти источники дополняют друг друга.

Подробнее: Журналы.

20. Аудит и история разговоров — тоже не одно и то же¶

История разговоров предназначена для пользовательской работы.

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

Удаление или архивирование разговора не должно менять историю системных полномочий.

21. Что делать при подозрении на компрометацию администратора¶

Если журнал показывает неизвестное изменение от административной учётной записи:

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

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

22. Минимальная периодическая проверка¶

Не реже принятой в организации периодичности просматривайте:

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

Для небольшой установки это может быть ежемесячная проверка.

Для критичной корпоративной среды периодичность определяется политикой безопасности организации.

23. Какие права считать особенно чувствительными¶

В первую очередь контролируйте полномочия на:

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

24. Что журнал текущей версии не должен обещать¶

Не документируйте текущий журнал как доказательство того, что автоматически фиксируются:

все пользовательские сообщения;
полный текст запросов к модели;
каждый прочитанный файл;
каждая найденная веб-страница;
каждый вызов Яндекс Облака;
каждое действие помощника;
каждое изменение модели;
каждое изменение операционной системы.

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

25. Рекомендуемая матрица источников расследования¶

Вопрос	Основной источник
Кто выдал системное право	Журнал аудита
Почему пользователь не входит	Журналы входа/API
Почему модель не отвечает	model-manager / среда модели / API
Почему RAG не находит документ	rag-api / vectordb
Почему интернет-поиск не работает	web-search / web-scraper
Почему Яндекс Облако вернуло 403	yandex-gateway / `yc-doctor`
Почему изменились расходы	FinOps + Billing + журналы интеграции
Кто сейчас состоит в роли	Панель «Доступ»

26. Частые ошибки¶

Ошибка: «В журнале нет события — значит ничего не происходило»¶

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

Ошибка: искать техническую ошибку модели в журнале прав¶

Используйте Журналы.

Ошибка: выгрузить весь аудит и отправить во внешний сервис¶

Сначала оцените чувствительность данных.

Ошибка: забыть часовой пояс¶

Без него трудно сопоставлять несколько журналов.

Ошибка: удалить пользователя до фиксации инцидента¶

Сначала сохраните сведения, необходимые для расследования.

27. Проверка результата¶

Раздел аудита настроен и понятен администратору, если вы можете уверенно ответить на пять вопросов:

кто выполнил изменение;
когда оно произошло;
кому изменили доступ;
какое системное право изменили;
было оно предоставлено или отозвано.

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