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

Раздел Журналы аудита предназначен для просмотра событий безопасности и действий пользователей, сохраняемых в системе Памир.

Журналы аудита позволяют:

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

Раздел доступен по пути:

Главная / Пользователи / Журналы аудита

Назначение раздела

Журналы аудита используются для:

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

Каждая вкладка раздела отображает отдельный тип журнала.

Типы журналов

В интерфейсе доступны следующие журналы аудита:

• Журнал доступа пользователей к CRUD операциям
• Журнал доступа администраторов к CRUD операциям
• Журнал доступа к корпоративным сервисам
• Журнал доступа к API Системы
• Журнал активности пользователей
• Журнал жизненного цикла данных мониторинга

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

Интерфейс просмотра журнала

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

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

В таблице могут отображаться, например, следующие поля:

• @timestamp — дата и время события;
• metadata — дополнительные данные события;
• user_id — идентификатор пользователя;
• user_role — роль пользователя;
• user_login — логин пользователя;
• event_type — тип события;
• path_parameters — параметры пути запроса;
• endpoint — адрес вызываемого метода;
• payload — тело запроса;
• response_status_code — код ответа.

Состав колонок зависит от конкретного типа журнала.

Поиск и фильтрация

Быстрый поиск

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

• логину пользователя;
• типу события;
• имени endpoint;
• данным из payload.

Фильтры

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

С помощью фильтров можно отбирать записи, например:

• за определённый период;
• по пользователю;
• по роли;
• по коду ответа;
• по типу события;
• по endpoint.

Набор доступных фильтров зависит от структуры конкретного журнала.

Просмотр содержимого записи

В строках журнала могут отображаться сложные поля, например:

• metadata
• path_parameters
• payload

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

Обновление данных

Для получения актуального состояния журнала используйте кнопку Обновить.

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

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

---

Описание журналов

Журнал операций пользователей

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

Может использоваться для:

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

Примеры полезных полей:

• время события;
• логин пользователя;
• роль пользователя;
• тип события;
• endpoint;
• параметры запроса;
• код ответа.

Журнал операций администраторов

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

Журнал доступа к корпоративным сервисам

В разработке. Журнал будет содержать обращения Памир к инфраструктурным сервисам. Например: LDAP, IDP провайдеры.

Журнал доступа к API Системы

В разработке. Журнал будет содержать события вызова API системы Памир.

Журнал активности пользователей

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

Журнал используется для:

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

В журнале могут отображаться, например, следующие поля:

• @timestamp — дата и время события;
• login — логин пользователя;
• reason — причина события или отказа;
• user_id — идентификатор пользователя;
• event_type — тип события, например auth.user.Login или auth.user.Logout;
• attribute_values — значения атрибутов пользователя;
• provider — провайдер аутентификации;
• status — состояние учетной записи;
• login_failed_count — количество неуспешных попыток входа;
• unlockable — признак возможности разблокировки учетной записи.

Журнал жизненного цикла данных мониторинга

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

Журнал используется для:

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

В журнале могут отображаться, например, следующие поля:

• @timestamp — дата и время события;
• audit_transport_request_type — тип транспортного запроса;
• audit_request_privilege — выполняемая привилегия или операция;
• audit_request_body — тело запроса;
• audit_trace_indices — индексы, к которым относится операция;
• audit_trace_resolved_indices — итоговые индексы после разрешения шаблонов;
• audit_request_layer — уровень выполнения запроса;
• audit_request_effective_user — пользователь или сервисная учетная запись, выполнившая операцию.

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

Настройка источников журналов

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

Настройки находятся в разделе:

Главная / Настройки / Система / Глобальные настройки

В системе используются следующие глобальные параметры:

• AUDIT_API_ACCESS_PATTERN — шаблон индекса для журнала доступа к API Системы
• AUDIT_CRUD_ADMIN_LOGS_PATTERN — шаблон индекса для журнала доступа администраторов к CRUD операциям
• AUDIT_CRUD_USER_LOGS_PATTERN — шаблон индекса для журнала доступа пользователей к CRUD операциям
• AUDIT_DATA_LIFECYCLE_PATTERN — шаблон индекса для журнала жизненного цикла данных мониторинга
• AUDIT_EXT_SERVICE_ACCESS_PATTERN — шаблон индекса для журнала доступа к корпоративным сервисам
• AUDIT_USER_ACTIVITY_PATTERN — шаблон индекса для журнала активности пользователей
• MAX_AUDIT_RESPONSE_SIZE — максимальный размер ответа ошибки в мегабайтах

Назначение шаблонов индексов

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

Например:

• pamir-sec-api-access-*
• pamir-sec-crud-admin-logs-*
• pamir-sec-crud-user-logs-*
• security-auditlog-*
• pamir-sec-ext-service-access-*
• pamir-sec-user-activity-*

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

Ограничение размера ответа

Параметр MAX_AUDIT_RESPONSE_SIZE ограничивает максимальный размер ответа ошибки в мегабайтах.

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

Хранение журналов

Сроки хранения журналов определяются политиками Index State Management (ISM), примененными к индексам OpenSearch. Параметры *_PATTERN определяют источники данных для просмотра журналов, но не управляют сроком их хранения.

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

• остаются открытыми в течение 14 дней;
• после 14 дней закрываются;
• после 90 дней удаляются.

Возраст отсчитывается от времени создания индекса, а не от поля @timestamp отдельной записи. ISM проверяет условия периодически, поэтому действие может выполниться позже указанного срока.

Просмотреть или изменить политики можно в разделе:

OpenSearch Dashboards / Index Management / State management policies

Снапшот перед удалением

При необходимости перед удалением индекса можно создать снапшот — резервную копию индекса в отдельном хранилище. Срок хранения снапшотов настраивается отдельно от срока хранения индексов.

Перед регистрацией файлового хранилища каталог должен быть подключен к каждому узлу OpenSearch и разрешен параметром path.repo. Для OpenSearch в Docker Compose настройка может выглядеть следующим образом:

opensearch:
  environment:
    path.repo: "/mnt/snapshots"
  volumes:
    - /path/on-host:/mnt/snapshots:rw

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

Чтобы зарегистрировать хранилище через интерфейс:

1. Откройте Snapshot Management / Repositories.
2. Нажмите Create repository.
3. Укажите Repository name.
4. В поле Repository type выберите Shared file system.
5. В поле Location укажите каталог внутри path.repo, например /mnt/snapshots/logs.
6. Нажмите Add.

После регистрации измените нужную ISM-политику:

1. Откройте Index Management / State management policies.
2. Выберите политику и нажмите Edit.
3. В редакторе Define policy найдите состояние delete.
4. Замените его действие delete последовательностью open → snapshot → delete.
5. Нажмите Update.

Пример состояния delete:

{
  "name": "delete",
  "actions": [
    {
      "retry": {
        "count": 3,
        "backoff": "exponential",
        "delay": "1m"
      },
      "open": {}
    },
    {
      "retry": {
        "count": 3,
        "backoff": "exponential",
        "delay": "1m"
      },
      "snapshot": {
        "repository": "<repository-name>",
        "snapshot": "{{ctx.index}}"
      }
    },
    {
      "retry": {
        "count": 3,
        "backoff": "exponential",
        "delay": "1m"
      },
      "delete": {}
    }
  ],
  "transitions": []
}

Действие open необходимо, если индекс был закрыт предыдущим состоянием политики. ISM выполняет действия последовательно и удаляет индекс только после успешного завершения снапшота. Если снапшот не создан даже после повторных попыток, действие delete не выполняется.

Применение политики к существующим индексам

Изменение политики в интерфейсе автоматически применяется к новым индексам, но уже управляемые индексы продолжают использовать предыдущую версию. После нажатия Update примените новую версию политики к существующим индексам через Dev Tools:

POST /_plugins/_ism/change_policy/pamir-sec-crud-user-logs-*
{
  "policy_id": "pamir-sec-crud-user-logs-delete"
}

Для остальных журналов укажите соответствующие шаблон индексов и policy_id. Не используйте общий шаблон *: он может затронуть системные и не относящиеся к журналам индексы.

Параметры state и include в запросе не указываются, поэтому индексы сохраняют текущее состояние и получают последнюю версию той же политики. Изменение применяется асинхронно. Успешный ответ содержит "failures": false и количество обновленных индексов в updated_indices.

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

GET /_plugins/_ism/explain/<index-name>?show_policy=true

Связанные разделы

• Глобальные настройки