Кристина Свечинская

Когда инфраструктура растет, команды множатся, а сервисы переходят на распределенную архитектуру, специалистам становится сложнее отслеживать события, которые происходят в системе. Рано или поздно наступает момент, когда кто-то произносит фразу: «А кто это сделал?» Иногда она звучит спокойно, а иногда — с легкой дрожью в голосе, например, когда исчезла виртуальная машина, изменились права доступа или сбились настройки сети. Здесь и начинается расследование. Если у компаний нет централизованных логов, анализ действий напоминает детектив без улик: много версий, мало фактуры. Чтобы со всем этим разобраться, мы создали сервис аудит-логов — это те самые факты, с помощью которых можно найти первопричину инцидента. Привет! Меня зовут Кристина, я старший менеджер продуктов клиентских сервисов. В этой статье расскажу, как устроен сервис, какие задачи решает, из чего состоят логи, а также — как интегрировать их с системами безопасности и аналитики. Как устроен сервис в Selectel Аудит-логи отвечают на три простых, но фундаментальных вопроса: кто, что и когда сделал. Без них нельзя говорить ни о безопасности, ни о комплаенсе, ни о доверии. Мы в Selectel разработали сервис, который позволяет вам, вашей службе безопасности и аудиторам всегда иметь под рукой все необходимые ответы. Инструмент обрабатывает действия пользователей в панели управления и через публичные API, после чего превращает их в прозрачную историю изменений. Это такой «черный ящик» для инфраструктуры — с той разницей, что в него можно заглядывать еще до катастрофы. Чтобы аудит-логи помогали в расследованиях и комплаенсе, их нужно не просто записывать, а записывать правильно — в нужном формате, с нужными полями и в нужный момент. Для этого в Selectel реализована цепочка из четырех шагов: сбор → нормализация → хранение → доступ. Сбор Каждый продукт и сервис в инфраструктуре Selectel формирует события об изменениях: кто выполнил действие, где, когда, над каким объектом и с каким результатом. Эти события передаются в централизованный сервис аудит-логов. На этом этапе критично обеспечить надежность и последовательность данных, а именно — залогировать все события и сделать так, чтобы ничего не потерялось. Это полезно при расследованиях: корректная цепочка действий позволяет достоверно восстановить последовательность произошедшего. А механизмы на стороне сервисов-источников логов и сервиса аудит-логов предотвращают потерю событий в случае разрыва соединения или иных инцидентов. В аудит-логах на данный момент присутствуют следующие сервисы-источники: IAM — аутентификация, управление пользователями, работа с токенами, ролями, политиками доступа, проектами и т. д; Облачные сервисы — мутирующие события с ВМ, дисками, сетями, квотами, сертификатами, секретами, балансировщиками и т. д; Биллинг — финансовые сигналы и отсрочка платежа. Список событий постоянно пополняется — постепенно логируются все ключевые действия в инфраструктуре Selectel. Отслеживать изменения можно в в документации. Нормализация В разных сервисах могут быть разные форматы логов, из-за чего конечному пользователю трудно с ними работать. Чтобы данные можно было анализировать единообразно, мы приводим их к общей схеме данных. JSON-структура события: У каждого события есть ряд обязательных полей, наличие которых не только необходимо для расследования инцидентов и проведения проверок, но и гарантирует соответствие требованиям ИБ при прохождении аудитов и сертификаций. Ниже приведу наиболее важные поля. 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 изначально строились с учетом требований международных и российских стандартов. Это означает, что: логи неизменяемы и защищены от редактирования; фиксируются не только действия клиентов, но и внутренние операции; каждая запись включает точное время, контекст, результат и информацию по субъекту действия. Перечисленные пункты делают их пригодными для внутренних расследований, выполнения требований 152-ФЗ, ГОСТ 57580.1, ISO 27001 и PCI DSS. В отдельной статье подробно расскажем, как аудит-логи помогают выполнять требования стандартов безопасности и проходить аудиты. Интеграция с системами безопасности и аналитики SIEM-системы помогают строить цепочки событий, искать аномалии и формировать алерты. Например, три неудачные попытки входа подряд могут сигнализировать о возможном подборе паролей. Массовое удаление ресурсов от одного пользователя выглядит как подозрительная активность, на которую, как минимум, стоит повесить алерт. Изменение ролей вне рабочего времени — повод проверить доступы. Сервис аудит-логов уже готов для интеграции с SIEM (Wazuh, ruSIEM, Kaspersky, Splunk и другими) благодаря готовому публичному API с возможностям детальной фильтрации и разумными рейт-лимитами на количество запросов в единицу времени. Единая структура полей позволяет интеграции работать из коробки, без сложного парсинга. В отдельной статье покажем, как именно подключить аудит-логи Selectel к SIEM и использовать их для реагирования на инциденты. Как использовать аудит-логи Сервис уже работает для всех клиентов автоматически — вы можете бесплатно его использовать. Чтобы начать, выполним несколько шагов. Откройте сервис. В панели управления в верхнем меню нажмите Аккаунт и перейдите в раздел Аудит-логи. Настройте фильтры и экспорт. Выберите период, необходимые сервисы и события. Подробнее все типы событий описаны в документации. Выгрузите логи. Нажмите Выгрузить логи, подтвердите скачивание файла. Когда выгрузка будет готова, система отправит уведомление. Автоматизируйте выгрузку. Используйте API, чтобы интегрировать аудит-логи с SIEM-системами. Найти расшифровку по каждому событию можно в документации. При появлении вопросов вы можете обратиться в техническую поддержку, чтобы получить консультацию как по самим логами, так и по интеграции с вашими аналитическими системами. Планы на будущее Мы продолжаем развивать сервис и расширяем набор логируемых событий во всех продуктах. В планах — интеграция с S3 для возможности более длительного хранения логов и с сервисом логов для расширения возможностей анализа. В мире, где инфраструктура становится все сложнее, прозрачность — это не роскошь, а инструмент выживания. Аудит-логи позволяют понимать, какие события происходят и почему, а также не гадать, кто нажал на ту самую кнопку.