После переезда в облако аудит логи расходятся по разным местам: часть событий пишет панель управления провайдера, часть — гостевые ОС, 1С и СУБД. Логирование в облаке работает, только если эти потоки сведены в одну схему: события собраны без потерь, хранение логов в S3 защищено от правки задним числом, а SIEM или набор правил помогает быстро найти аномалию. Ниже разобраны все звенья такой схемы.
Какие логи нужны для безопасности и кто их собирает в облаке
Аудит-логи и технические логи: в чём разница
Технический лог нужен разработчику: трассировки, ошибки, время ответа. Через пару недель его обычно удаляют. Аудит-лог фиксирует действия субъектов над ресурсами и служит доказательством, поэтому требует полноты, неизменности, долгого хранения и точного времени.
Каждое событие аудита отвечает на вопросы:
- кто — пользователь, сервисный аккаунт, идентификатор ключа доступа;
- что сделал — тип операции (создание, изменение прав, удаление, вход);
- когда — время в UTC с миллисекундами;
- над чем — идентификатор ресурса;
- с каким результатом и откуда — успех или отказ, IP-адрес, User-Agent, клиент.
Пример нормализованного события:
{
"event_time": "2026-09-14T02:17:43.512Z",
"ingest_time": "2026-09-14T02:17:44.090Z",
"source": "cloud-api",
"actor": {"type": "service_account", "id": "sa-backup-01", "key_id": "AK7F…"},
"action": "vm.snapshot.delete",
"resource": {"type": "snapshot", "id": "snap-4412", "project": "prod-erp"},
"outcome": "success",
"client": {"ip": "185.xx.xx.17", "user_agent": "python-requests/2.32"}
}
Аномалия видна сразу: учётная запись резервного копирования ночью удаляет снапшоты через скрипт с внешнего адреса.
Что журналирует провайдер, а что должен собирать клиент
| Уровень | Кто пишет журнал | Типичные события |
|---|---|---|
| Панель управления и API | Провайдер | вход в консоль, создание и удаление ВМ, снапшоты, сетевые правила |
| Учётные записи и роли облака | Провайдер | выдача ролей, создание ключей доступа, смена MFA |
| Гипервизор и физическая инфраструктура | Провайдер, клиенту напрямую не выдаётся | миграции ВМ, доступ персонала к оборудованию |
| Гостевая ОС | Клиент | auditd, journald, Windows Event Log, Sysmon |
| Приложения, 1С, СУБД | Клиент | входы, изменения данных, выгрузки, изменения прав |
| Сеть внутри ВМ и периметр клиента | Клиент | журналы межсетевого экрана, VPN, прокси |
Чаще всего упускают первую строку: журнал панели управления хранится у провайдера ограниченное время. Регулярно забирайте его через API в собственное хранилище и заранее договоритесь, как запрашивать события гипервизорного уровня при расследовании.
Сбор и доставка событий без потерь
Агенты, форматы и надёжная доставка
Для Linux базовый набор — rsyslog или Fluent Bit, для сложной маршрутизации — Vector. В Windows — Winlogbeat или WEF (Windows Event Forwarding). Для транспорта подходит syslog по RFC 5424, CEF и LEEF понимают почти все SIEM. Для хранения выберите одну схему полей — ECS или OCSF — и приводите к ней все источники до записи в архив.
Потери случаются на стыках: упал канал, перезапустился коллектор, SIEM отклонила пакет событий из-за лицензии. Защищают три меры:
- Буфер на диске у агента (
storage.type filesystemв Fluent Bit, дисковый буфер в Vector) на несколько часов простоя при пиковом потоке. - Доставка с подтверждением: RELP вместо UDP-syslog, HTTP с повторами, Kafka для крупных потоков.
- Два поля времени:
event_timeиingest_time. Выгрузку строят по времени записи, чтобы запоздавшие события не выпали из выборки.
Синхронизация времени через chrony или NTP с одним источником обязательна: расхождение в полминуты ломает хронологию инцидента.
Журнал регистрации 1С как источник событий безопасности
Журнал регистрации 1С часто самый информативный источник, но лежит на том же сервере, что и база, и доступен администратору 1С. Выносите его за пределы сервера как можно быстрее. В первую очередь передавайте:
- «Сеанс. Аутентификация» и «Сеанс. Ошибка аутентификации» — перебор паролей, входы под служебными учётными записями;
- «Пользователи. Изменение» — выдача ролей, особенно полных прав;
- «Информационная база. Изменение параметров журнала регистрации» — снижение уровня журналирования само по себе повод для алерта;
- массовые изменения и удаления данных, выгрузка информационной базы.
Журнал хранится в формате .lgf/.lgp или .lgd, у ряда российских SIEM есть готовые нормализаторы. Настройте контроль молчания для каждого источника: если обычно активный источник 15 минут не прислал ни одного события, это инцидент, пока не доказано обратное.
Хранение логов в S3: архив, который нельзя незаметно изменить
Структура бакета, форматы и защита от изменения
Раскладывайте объекты по префиксам «ключ=значение»:
s3://sec-audit-archive/source=cloud-api/type=iam/dt=2026-09-14/hour=02/part-0001.jsonl.zst
ClickHouse, Trino и DuckDB читают только нужные объекты. Сырые события пишите в JSON Lines со сжатием zstd, для аналитики пересобирайте в Parquet: колоночный формат сжимается сильнее и читается выборочно по полям. Размер объектов — 64–256 МБ: миллионы мелких файлов замедляют и запись, и поиск.
Защита архива строится слоями:
- Отдельный бакет и учётные данные. Агент получает ключ только на запись (PutObject), администраторы инфраструктуры доступа к бакету не имеют.
- Версионирование и Object Lock (WORM). В режиме governance удалить объект до конца срока может только учётная запись с особым правом, в режиме compliance — никто, включая владельца бакета. Это защита и от злоумышленника с правами администратора, и от шифровальщика. Ошибочный срок в compliance отменить нельзя, платить за хранение придётся до его окончания.
- Контроль целостности. Раз в час коллектор формирует манифест с SHA-256 объектов и хэшем предыдущего манифеста — подмена видна при сверке.
- Политики жизненного цикла (lifecycle). Удаление по истечении срока и перевод в холодный класс.
Набор режимов зависит от конкретного хранилища — перед проектированием проверьте, что поддерживает ваш провайдер.
Для такого архива подойдёт объектное хранилище S3 от Cloud4U: оно построено на платформе Cloudian и совместимо с Amazon S3 API, поэтому агенты и движки запросов из этой статьи работают с ним без доработок, а соответствие 152-ФЗ (УЗ-1) закрывает требование локализации журналов с персональными данными.
Сколько весят логи и во что обходится их хранение
Пример: 150 ВМ, 1С на 300 пользователей, периметровый межсетевой экран — около 1500 событий в секунду (EPS) после фильтрации, средний размер события 700 байт.
- В сутки: ≈ 90,7 ГБ сырых данных, за год ≈ 33,1 ТБ.
- Со сжатием 1:8: ≈ 11,3 ГБ в сутки и ≈ 4,1 ТБ за год.
Ориентировочные цены: объектное хранилище — 2 ₽ за ГБ в месяц, SSD под индекс — 10 ₽. В индексе данные занимают 1,1 от сырого объёма в двух копиях.
| Вариант | Занимаемый объём | Хранение в месяц | Хранение за 12 месяцев |
|---|---|---|---|
| Все 12 месяцев только в S3 (сжатые) | 4,1 ТБ | ≈ 8,3 тыс. ₽ | ≈ 99 тыс. ₽ |
| Все 12 месяцев в индексе | 72,8 ТБ | ≈ 728 тыс. ₽ | ≈ 8,7 млн ₽ |
| 30 дней в индексе + 12 месяцев в S3 | 6,0 ТБ SSD + 4,1 ТБ S3 | ≈ 68 тыс. ₽ | ≈ 818 тыс. ₽ |
Суммы не учитывают вычислительные ресурсы и лицензии, но разница на порядок сохраняется. Лицензии SIEM считаются по EPS, поэтому в корреляцию отправляйте то, по чему есть правила, а полный поток — в архив.
Сроки хранения и требования комплаенса
| Требование | Документ | Что хранить | Срок |
|---|---|---|---|
| Защита ПДн в ИСПДн | 152-ФЗ, ПП № 1119, приказ ФСТЭК № 21 (группа мер РСБ) | события безопасности, защита журналов | в приказе не установлен; ориентир — методический документ ФСТЭК 2014 года «Меры защиты информации в ГИС»: не менее 3 месяцев |
| ГИС | приказ ФСТЭК № 117 (с 1 марта 2026 года заменил приказ № 17) | регистрация событий безопасности | по актуальной редакции и методикам ФСТЭК |
| Значимые объекты КИИ | 187-ФЗ, приказ ФСТЭК № 239 (группа АУД) | регистрация событий, мониторинг | определяет субъект КИИ |
| Финансовые организации | ГОСТ Р 57580.1-2017 | регистрация событий защиты информации | задаёт положение Банка России |
| Карточные данные | PCI DSS v4.0.1, требование 10.5.1 | журналы аудита среды карточных данных | не менее 12 месяцев, последние 3 — в немедленном доступе |
| СМИБ | ISO/IEC 27001:2022, меры 8.15 и 8.17 | журналирование, синхронизация времени | определяет организация |
Последние 30–90 дней держите в индексе или SIEM, полный срок — в S3 с Object Lock. PCI DSS фактически описывает эту модель: три месяца в оперативном доступе, двенадцать всего. Срок блокировки выставляйте по самому длинному требованию, удаление по политике жизненного цикла — сразу после него.
Персональные данные внутри логов
Журналы содержат логины, email, ФИО, а IP-адреса в сочетании с ними позволяют установить человека.
- Локализация. Часть 5 ст. 18 152-ФЗ требует хранить ПДн граждан РФ в России — зарубежный архив журналов ей противоречит.
- Минимизация. Не пишите в журналы тела запросов, пароли, токены, паспортные данные.
- Маскирование. В копии для SIEM подрядчика поля можно псевдонимизировать, сохранив исходник в архиве с узким доступом.
- Разграничение доступа. Чтение архива — у узкого круга сотрудников ИБ, и каждое чтение само попадает в журнал.
SIEM и расследование инцидентов в облаке
Когда нужен SIEM, а когда хватит архива с правилами
Среди российских SIEM — MaxPatrol SIEM, KUMA, RuSIEM, Security Vision, из открытых — Wazuh и OpenSearch с правилами Sigma. Критерии выбора: реальный EPS, готовые нормализаторы для ваших источников и специалисты, которые будут разбирать алерты. Если их нет, покупка SIEM проблему не решит.
Для компании до 100–200 ВМ без команды ИБ часто достаточно архива в S3, двух десятков правил поверх потока (в Vector или Wazuh) и движка запросов: ClickHouse, Trino или DuckDB читают Parquet прямо из бакета. Под расследование поднимается выборка за нужные дни, и через несколько минут по ней можно работать SQL-запросами. Для круглосуточного мониторинга без собственных специалистов разумнее подключить внешний SOC.
Облачные сценарии: от первого алерта до хронологии
Типовые сценарии с привязкой к MITRE ATT&CK:
- Скомпрометированный ключ (T1078.004).
actor.key_idс новымclient.ipилиuser_agent, вызовы API вне обычного окна. Первый вопрос: какие операции выполнены этим ключом с момента первого аномального события. - Выдача прав самому себе (T1098). Изменение роли, где
actor.idсовпадает сresource.id; рядом часто отключение MFA и новый ключ. - Массовое удаление ВМ и снапшотов (T1485, T1490). Правило «больше N удалений за 10 минут» от одного субъекта.
- Выгрузка данных из бакета (T1530). Всплеск GetObject с нового IP — без журнала доступа к бакету такой инцидент не расследовать.
- Отключение журналирования (T1562.008). Алерт высшего приоритета.
Хронологию собирайте в единую таблицу со временем в UTC:
| Время (UTC) | Источник | Субъект | Действие | Объект | Результат | Вывод |
|---|---|---|---|---|---|---|
| 02:03:11 | API облака | sa-backup-01 | создание ключа | sa-backup-01 | успех | новый ключ с внешнего IP |
| 02:09:40 | API облака | sa-backup-01 | назначение роли | sa-backup-01 | успех | эскалация прав |
| 02:17:43 | API облака | sa-backup-01 | удаление снапшота | snap-4412 | успех | уничтожение точек восстановления |
| 02:18:05 | auditd, erp-db-01 | root | остановка службы | postgresql | успех | подготовка к шифрованию |
При локализации сначала отзовите ключи и сессии субъекта, затем закройте каналы управления и только потом работайте с ВМ. Раз в квартал проверяйте схему на учебном сценарии: алерт пришёл, события дошли до архива, выборка из S3 поднимается за разумное время.
Главные выводы
Аудит логи приносят пользу, только когда цепочка собрана целиком: журналы API провайдера забираются, агенты пишут в дисковый буфер, у событий два поля времени, молчание источника вызывает алерт. Хранение логов в S3 с Object Lock, ключами только на запись и цепочкой хэшей даёт доказательную базу для комплаенса и обходится на порядок дешевле индекса.
SIEM нужен там, где есть поток, правила и специалисты; в остальных случаях архив с правилами, движок запросов и внешний SOC закрывают задачи расследования не хуже. Сроки хранения: 3 месяца как ориентир ФСТЭК, 12 месяцев по PCI DSS. Персональные данные внутри журналов требуют хранения в России и минимизации. Логирование в облаке по этой схеме позволяет ответить аудитору и восстановить хронологию атаки по одним и тем же данным.
