Когда инфраструктура растет, команды множатся, а сервисы переходят на распределенную архитектуру, специалистам становится сложнее отслеживать события, которые происходят в системе. Рано или поздно наступает момент, когда кто-то произносит фразу: «А кто это сделал?» Иногда она звучит спокойно, а иногда — с легкой дрожью в голосе, например, когда исчезла виртуальная машина, изменились права доступа или сбились настройки сети. 

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

Привет! Меня зовут Кристина, я старший менеджер продуктов клиентских сервисов в Selectel. В этой статье расскажу, как устроен сервис, какие задачи решает, из чего состоят логи, а также — как интегрировать их с системами безопасности и аналитики.

Как устроен сервис в Selectel

Аудит-логи отвечают на три простых, но фундаментальных вопроса: кто, что и когда сделал. Без них нельзя говорить ни о безопасности, ни о комплаенсе, ни о доверии. 

Мы в Selectel разработали сервис, который позволяет вам, вашей службе безопасности и аудиторам всегда иметь под рукой все необходимые ответы. Инструмент обрабатывает действия пользователей в панели управления и через публичные API, после чего превращает их в прозрачную историю изменений.

Это такой «черный ящик» для инфраструктуры — с той разницей, что в него можно заглядывать еще до катастрофы.

Чтобы аудит-логи помогали в расследованиях и комплаенсе, их нужно не просто записывать, а записывать правильно — в нужном формате, с нужными полями и в нужный момент. Для этого в Selectel реализована цепочка из четырех шагов: сбор → нормализация → хранение → доступ.

Сбор

Каждый продукт и сервис в инфраструктуре Selectel формирует события об изменениях: кто выполнил действие, где, когда, над каким объектом и с каким результатом. Эти события передаются в централизованный сервис аудит-логов.

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

В аудит-логах на данный момент присутствуют следующие сервисы-источники: 

• IAM — аутентификация, управление пользователями, работа с токенами, ролями, политиками доступа, проектами и т. д;

• Облачные сервисы — мутирующие события с ВМ, дисками, сетями, квотами, сертификатами, секретами, балансировщиками и т. д;

• Биллинг — финансовые сигналы и отсрочка платежа.

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

Нормализация

В разных сервисах могут быть разные форматы логов, из-за чего конечному пользователю трудно с ними работать. Чтобы данные можно было анализировать единообразно, мы приводим их к общей схеме данных.

JSON-структура события:

[
 {
   "event_saved_time": "2025-09-29T13:13:25.196Z",
   "event_id": "string",
   "event_type": "string",
   "event_time": "2025-09-29T13:13:25.196Z",
   "status": "string",
   "error_code": "string",
   "request_id": "string",
   "subject": {
     "id": "string",
     "type": "string",
     "name": "string",
     "auth_provider": "string",
     "is_authorized": true,
     "authorized_by": [
       "string"
     ],
     "credentials_fingerprint": "string"
   },
   "resource": {
     "id": "string",
     "type": "string",
     "name": "string",
     "account_id": "string",
     "project_id": "string",
     "location": "string",
     "details": {},
     "old_values": {
       "additionalProp1": {}
     },
     "new_values": {
       "additionalProp1": {}
     }
   },
   "source_type": "string",
   "request": {
     "remote_address": "string",
     "user_agent": "string",
     "type": "string",
     "path": "string",
     "method": "string",
     "parameters": "string"
   },
   "schema_version": "string"
 }
]

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

Ниже приведу наиболее важные поля.

event_type — тип события

В аудит-логах типы событий сгруппированы по сервисам, которые отвечают за разные части продуктов. Полный список можно посмотреть в подразделе Типы событий в документации. 

Нейминг событий построен на принципе единообразия: первая часть — всегда сервис-источник, вторая — бизнес-сущность, третья — произведенное действие. Такой подход позволяет легко ориентироваться по названию лога и определять, что за событие произошло, над чем и где.

event_time и event_saved_time — время события

В логах есть два поля времени: event_time и event_saved_time. Зачем два? Чтобы исключить потерю событий.

• event_time — когда действие реально произошло в сервисе.

• event_saved_time — когда событие было получено и сохранено в системе аудит-логов.

Иногда между ними возникает разница во времени: из-за сетевых задержек, «ретраев» или временной недоступности сервисов. В таких случаях событие появляется в аудит-логах позже, чем произошло. Если при регулярной выгрузке ориентироваться только на event_time, можно пропустить задержавшиеся события.

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

Для реконструкции цепочки действий во время расследования или проверки фактов удобнее использовать event_time.

status — статус события 

Поле позволяет с легкостью понимать, с каким результатом завершилось действие — успешно или с ошибкой. 

Возможные значения:

• success — успешно;

• fail — ошибка;

• accepted — принято;

• NA (not applicable) — к событию не применим ни один из статусов.

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

subject — тот, кто совершил действие

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

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

resource — то, над чем произошло действие

Объект действия — сущность, над которой выполнил операцию субъект. Объектом может быть ресурс (сервер, диск), пользователь, роль, аккаунт и т. д. 

У ресурса имеется развернутое описание, помимо его UUID и имени. Также в аудит-логах часто отображается, какие именно изменения произошли с ресурсом: changes_old — прошлое состояние, new_values — новое состояние.

request — информация о запросе 

Информация крайне полезна при расследовании инцидентов безопасности. Она включает  такие важные параметры, как:

• IP-адрес, с которого пришел запрос;

• User Agent субъекта события; 

• путь к ресурсу, над которым было совершено действие. 

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

Хранение

Срок хранения логов в клиентском формате — 90 дней, что соответствует требованиям 21 приказа ФСТЭК в части выполнения 152-ФЗ и подходит для расследований, аналитики и подготовки комплаенс-отчетов. Также трех месяцев достаточно для выполнения требований PCI DSS в части оперативного доступа к логам, после чего их можно выгрузить для выполнения требований по хранению. Данные надежно защищены от редактирования: запись в аудит-логе — это как подпись под документом. 

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

Доступ

Все аудит-логи сохраняются с контролем целостности и доступом только по разрешенным каналам. Это значит, что никто не сможет поменять логи и проникнуть к ним без доступа. 

Есть два способа работать с логами. Через панель управления — для выгрузки в формате JSON или CSV. Через API — для автоматизации и интеграций с внешними системами.

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

Облачная инфраструктура для ваших проектов

Виртуальные машины в Москве, Санкт-Петербурге и Новосибирске с оплатой по потреблению.

Подробнее →

Какие логи фиксирует сервис

Когда речь заходит о логировании, многие системы одновременно пишут аудит-логи и технические логи (логи приложений). Их легко перепутать, но это разные инструменты, которые решают разные задачи.

Аудит-логи фиксируют действия пользователей и систем с точки зрения безопасности и контроля доступа. Приведу пример. 

• Пользователь Иван вошел в систему в 10:15.

• Пользователь Мария удалила виртуальную машину 1C в 14:32.

• Пользователь Алексей изменил настройки доступа для группы «Менеджеры» в 09:05.

• Попытка неудачного входа в систему с неправильным паролем в 12:01.

Ключевая функция аудит-логирования — обеспечение прозрачности и соответствие нормам безопасности (ISO 27001, PCI DSS, 152-ФЗ, ГОСТ 57580.1), а также помощь в расследовании инцидентов.

Основные пользователи аудит-логов — это специалисты по ИБ, аудиторы, администраторы, служба поддержки.

Технические (application/system/debug) логи фиксируют то, как система выполнила операцию, что происходило на уровне сервисов и инфраструктуры. Они отвечают на вопросы: какие операции выполнялись в коде, какие параметры передавались между сервисами, какие ошибки и исключения возникали. 

Приведу пример.

• Ошибка подключения к базе данных в 16:05.

• Процесс резервного копирования завершился успешно в 03:00.

• Использование памяти сервером достигло 90% в 11:45.

Ключевая функция технических логов — диагностирование работы системы и устранение проблем. Основными пользователями являются разработчики, DevOps-инженеры и SRE.

В Selectel есть два сервиса для работы с логами: аудит-логи, к которым посвящена статья, и сервис логов, адаптированный для работы с техническими логами. В будущем планируем, что аудит-логи также можно будет использовать в платформе логов, как один из источников информации. Таким образом, пользователи смогут работать с логами разных типов для глубинного анализа в одной системе.

Соответствие стандартам безопасности и аудит-требованиям

Любой аудитор по информационной безопасности может спросить: «Можете ли вы показать, кто, когда и при каких условиях изменил настройки системы?» Если у вас есть аудит-логи, ответ «да» звучит спокойно. Если нет,  начинается долгая переписка, сбор скриншотов и поиски «того самого инженера».

Аудит-логи Selectel изначально строились с учетом требований международных и российских стандартов. Это означает, что:

• логи неизменяемы и защищены от редактирования;

• фиксируются не только действия клиентов, но и внутренние операции;

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

Перечисленные пункты делают их пригодными для внутренних расследований, выполнения требований 152-ФЗ, ГОСТ 57580.1, ISO 27001 и PCI DSS.

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

Интеграция с системами безопасности и аналитики

Логи — это лишь основа. Настоящая польза появляется, когда они становятся частью экосистемы ИБ. Туда входят SIEM (система управления информацией и событиями безопасности), SOC (система управления информацией и событиями безопасности ИБ) и аналитические системы.

SIEM-системы помогают строить цепочки событий, искать аномалии и формировать алерты. Например, три неудачные попытки входа подряд могут сигнализировать о возможном подборе паролей. Массовое удаление ресурсов от одного пользователя выглядит как подозрительная активность, на которую, как минимум, стоит повесить алерт. Изменение ролей вне рабочего времени — повод проверить доступы.

Сервис аудит-логов уже готов для интеграции с SIEM (Wazuh, ruSIEM, Kaspersky, Splunk и другими) благодаря готовому публичному API с возможностям детальной фильтрации и разумными рейт-лимитами на количество запросов в единицу времени. Единая структура полей позволяет интеграции работать из коробки, без сложного парсинга.

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

Как использовать аудит-логи

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

Откройте сервис. В панели управления в верхнем меню нажмите Аккаунт и перейдите в раздел Аудит-логи.

Настройте фильтры и экспорт. Выберите период, необходимые сервисы и события. Подробнее все типы событий описаны в документации.

Выгрузите логи. Нажмите Выгрузить логи, подтвердите скачивание файла. Когда выгрузка будет готова, система отправит уведомление.

Автоматизируйте выгрузку. Используйте API, чтобы интегрировать аудит-логи с SIEM-системами.

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

Планы на будущее

Мы продолжаем развивать сервис и расширяем набор логируемых событий во всех продуктах. В планах — интеграция с S3 для возможности более длительного хранения логов и с сервисом логов для расширения возможностей анализа.

В мире, где инфраструктура становится все сложнее, прозрачность — это не роскошь, а инструмент выживания. Аудит-логи позволяют понимать, какие события происходят и почему, а также не гадать, кто нажал на ту самую кнопку.