elasticsearch-audit

Навык Elasticsearch Audit Logging посвящён настройке журнала событий безопасности через API настроек кластера. Он подходит, когда нужно включить или выключить audit logging, выбрать наблюдаемые события, уменьшить шум фильтрами и затем разбирать инциденты по сохранённым записям. В описании источника отдельно выделены попытки аутентификации, разрешённые и запрещённые обращения, изменения ролей и конфигурации безопасности, операции с API keys, подозрение на несанкционированный доступ и поиск признаков перебора паролей. Это делает карточку полезной для предварительной настройки контроля доступа, расследования отказов и подготовки проверяемых запросов к audit-данным, но не превращает сам навык в аудит защищённости инфраструктуры или в рекомендацию доверять конкретной конфигурации. Перед изменением параметров нужны URL Elasticsearch, действующие учётные данные и кластерная привилегия manage. Источник также указывает лицензионное ограничение: audit logging доступен при Gold, Platinum, Enterprise или trial license. Включение выполняется динамически через xpack.security.audit.enabled, без перезапуска, а текущее состояние можно проверить через cluster settings с включёнными defaults и flat settings. Навык описывает два варианта вывода. Logfile по умолчанию создаёт JSON-файл в каталоге логов Elasticsearch, а index записывает события в индексы .security-audit-*, которые можно запрашивать через API; оба вывода могут работать одновременно. Для программного анализа предпочтителен index, тогда как logfile удобнее для передачи во внешнюю SIEM через Filebeat. При включённом audit logging по умолчанию записываются все события. Источник показывает, как ограничить набор include-событиями вроде authentication_failed, access_denied, access_granted, anonymous_access_denied, tampered_request, run_as_denied и connection_denied либо убрать шумные события через exclude. Фильтры позволяют исключать записи по users, realms, roles, indices и actions; событие отбрасывается, когда в одной политике совпали все заданные поля. Такой подход позволяет исключить системных пользователей или health-check трафик на конкретных индексах, не отключая целый класс событий. Для изменения фильтра источник использует кластерные настройки, а для удаления политики — значение null. После включения index output навык предлагает запросы к .security-audit-* по временному диапазону и типу события: неудачные входы, access_denied на выбранном индексе и security_config_change, включая изменения ролей, пользователей, API keys и role mappings. Для подсчётов используются terms-агрегации по event.action. Для поиска brute-force сценариев предлагается группировать authentication_failed по source.ip и применять min_doc_count 5. Для действий из Kibana предусмотрена отдельная корреляция: Kibana audit logging нужно включать самостоятельно, а общий trace.id, переданный через X-Opaque-Id, является основным ключом связи. Если trace.id нет, остаются корреляция по user.name, source.ip и узкому окну времени. Практическая граница навыка зависит от типа размещения. Для self-managed Elasticsearch и Elastic Cloud Hosted настройка audit через cluster settings доступна; в ECH logfile просматривается через Cloud console, а index output работает как обычно. На Serverless настройка audit пользователем недоступна: события безопасности управляются платформой, поэтому запрос о ручной конфигурации нужно направлять в Elastic Cloud console или команде аккаунта. Источник рекомендует начинать с failure-событий, расширять покрытие при необходимости, контролировать размер .security-audit-* и планировать ILM для хранения и удаления старых индексов. Для полного покрытия действий в Kibana требуется отдельный Kibana audit, а для обычной работы следует использовать выделенного администратора или API key с manage, оставляя superuser для аварийного восстановления.