1. Установите профиль аудита
Запишите PostgreSQL major, версию и совместимую ветку pgAudit, экземпляр, базу и период. Для прошлого события нужен действовавший состав pgaudit.log и доступные серверные журналы. Текущее SHOW показывает нынешнюю настройку, а не историческую. Класс ROLE охватывает изменения ролей и привилегий; object auditing и session auditing имеют разные границы.
2. Отберите исходные записи
Ищите AUDIT-сообщения класса ROLE в сохранённом серверном журнале, сохраняя внешний префикс времени, базы, backend и пользователя. CSV-часть pgAudit разбирайте с учётом кавычек и запятых внутри statement; простое разделение по каждой запятой разрушит запись. Сузьте операцию GRANT/REVOKE либо изменение роли, но не запускайте её для проверки.
3. Прочитайте пример
В иллюстрации SESSION,12,1 и ROLE описывают тип аудита, номер statement/substatement и класс. GRANT SELECT касается учебной таблицы и роли demo_read; это предоставление права объекту роли, а не автоматически назначение членства между ролями. Пустое object-name в данной форме не удаляет объект из текста statement. PARAMETER=<not logged> означает отсутствие записанных параметров, а не отсутствие команды.
4. Разделите инициатора и результат
Номера statement локальны для backend и требуют связи с внешним серверным контекстом. Текст GRANT показывает исследуемое действие, но имя DB-role не устанавливает человека за пулом соединений. Дополнительно проверьте исход транзакции: регистрация statement и окончательно сохранённое право не равнозначны. Текущее состояние каталога тоже могло измениться после расследуемого момента.
5. Постройте цепочку изменения доступа
Сопоставьте statement с session_user/current_user, соединением приложения и заявкой на изменение. Выделите получателя, тип права, объект и доступный результат. Затем проверяйте связанные обращения к данным, если нужно установить использование выданного права. Разделите документально подтверждённый grant, эффективный доступ на конкретный момент и факт использования — это три самостоятельных вывода.
6. Если записи ROLE нет
Проверьте, был ли нужный класс включён, совпадает ли ветка расширения и куда уходил серверный журнал. Уточните ротацию, выбранную базу и период. SHOW pgaudit.log в новом сеансе не доказывает, что аудит прежнего пользователя был таким же. При отсутствии истории конфигурации или транзакционного контекста явно отметьте предел восстановления; не утверждайте, что права никто не менял.