Аудит действий администраторов на Linux-серверах: реальный кейс банка под требования ЦБ и PCI DSS

Привет! Меня зовут Семёнов Евгений Сергеевич, и я руковожу компанией АйТи Фреш. За мои пятнадцать лет работы в сфере инфраструктурной безопасности я успел не раз расследовать самые разные инциденты. И знаете, что чаще всего мешало разобраться? Отсутствие элементарного журнала действий! Ситуация до боли знакомая: кто-то на сервере что-то сделал, всё рухнуло, а вот кто именно — попробуй пойми. Сегодня я хочу наглядно, на примере реального кейса, показать вам, как мы решили эту проблему для одного банка, используя обычный, штатный линуксовый механизм auditd.

Зачем компании журнал действий администраторов

Руководителям я обычно объясняю это через простую аналогию. Допустим, у вас в офисе работает уборщица. Вы ей доверяете, ключи выдали. Но камера в коридоре всё равно висит — и не потому что вы не доверяете, а потому что: во-первых, мало ли что; во-вторых, если что-то случится, надо понимать, как именно; в-третьих, без видеозаписи страховая ничего не выплатит.

С нашими любимыми Linux-серверами всё обстоит точно так же. Конечно, системному администратору приходится давать полный доступ, то есть права root — без этого он просто не сможет выполнять свою работу. Однако журнал его действий нам необходим, и вот почему:

• Расследование инцидентов. Если сервер упал или базу удалили, по журналу можно восстановить, кто и что делал в момент происшествия.
• Защита самих администраторов. Когда что-то ломается, виноватым по умолчанию назначают того, кто последний работал. С журналом легко доказать, что ты ничего такого не делал.
• Соответствие требованиям регуляторов. ЦБ для банков (положение 683-П), PCI DSS для всех, кто работает с банковскими картами, ФСТЭК для госструктур, 152-ФЗ для всех с персональными данными — везде требуется аудит.
• Контроль работы подрядчиков. Если вы пускаете на серверы внешних специалистов, без журнала это слепое доверие.
• Обнаружение взломов. Если злоумышленник получил root, он попытается замести следы. Изменения в системных файлах фиксируются и попадают в SIEM, который пришлёт алерт.

Кейс: банк, предписание ЦБ и 14 серверов

В феврале 2026 года к нам обратился банк «БанкИнфо» (название изменено по понятным причинам). Проблема была такая: ЦБ при плановой проверке выписал предписание. На 14 Linux-серверах с платёжными данными нормально настроенного аудита не было. Срок на устранение — 60 дней.

Что мы застали на старте:

• 14 серверов: 4 веб, 3 приложения, 2 базы данных, 3 батч-обработки, 2 управляющих. Ubuntu 22.04 и CentOS 8.
• auditd установлен по умолчанию, но не настроен. Ловит только факт логина в систему.
• Восемь администраторов с правами root. Плюс четыре сервисные учётки.
• Логи хранились локально на каждом сервере и удалялись через 4 недели.
• SIEM-система Wazuh была развёрнута, но логи аудита в неё не передавались.

Задача: настроить полноценный аудит, наладить централизованный сбор логов в защищённое хранилище и завести данные в SIEM. На всё — 60 дней. По прошлым проектам мы понимали, что уложимся за месяц.

Чем мы пользовались и почему

Решить задачу аудита на Linux можно несколькими способами:

Кстати, в самом банке уже был установлен Wazuh — это такой бесплатный SIEM с открытым кодом, очень популярный в финансовом секторе. Поэтому мы решили использовать его возможности по максимуму. Для штатного аудита мы выбрали встроенный auditd, а Wazuh у нас стал выполнять роль агрегатора и системы корреляции событий.

Что именно мы настраивали — без портянок команд

Опишу логику — без перегруза техническими деталями.

1. Настроили auditd на каждом сервере. Главный момент: при заполнении диска для логов сервер должен останавливаться, а не продолжать работу с потерей записей. Это жёсткое требование PCI DSS — лучше остановить машину, чем потерять журнал.
2. Прописали правила для отслеживания критичных файлов. Изменения в /etc/passwd, /etc/shadow, /etc/sudoers, конфигурация SSH, файлы PAM, системный crontab — всё, что может изменить кто-либо с правами администратора.
3. Прописали правила для отслеживания действий root. Каждая команда, выполненная под root, записывается в журнал с указанием реального пользователя, который её запустил через sudo.
4. Настроили правила под требования PCI DSS. Раздел 10 этого стандарта явно перечисляет, какие события должны логироваться. Мы прошлись по чек-листу и составили 67 правил, которые покрывают все требования.
5. Заблокировали отключение аудита. После загрузки правил конфигурация становится неизменной до перезагрузки сервера. Злоумышленник с root не сможет отключить аудит на ходу, чтобы спрятать свои действия.
6. Развернули централизованный сбор логов. С каждого сервера логи в реальном времени уходят на отдельный защищённый сервер. Если злоумышленник стирает локальный лог — копия уже на центральном хранилище.
7. Подключили журналы к Wazuh. SIEM анализирует поток событий, ищет подозрительные паттерны и шлёт алерты в Telegram-канал отдела безопасности.
8. Настроили ежедневные отчёты. Каждое утро начальник службы безопасности получает короткую сводку: сколько входов, сколько неудачных попыток, какие команды выполнялись от root, есть ли аномалии.

На всё про всё, от начала и до конца, у нас ушло 16 рабочих дней. Наш старший инженер занимался настройкой auditd и интеграцией со SIEM-системой. Тем временем средний инженер корпел над правилами под стандарт PCI DSS и тщательно обкатывал их на отдельном стенде.

Что начали ловить в первый месяц после запуска

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

• Один из админов раз в неделю заходил под root в нерабочее время и редактировал конфиги «по-быстрому» без согласований. После разговора с руководителем — перестал.
• Сервисная учётка deploy_bot с правами на запись в /etc раз в день что-то меняла — оказалось, забытый старый скрипт CI/CD, который никто не помнил.
• Был обнаружен нелегитимный SSH-ключ в /root/.ssh/authorized_keys на одном из серверов — оставленный полгода назад уволенным сотрудником. Удалили.
• Два раза за месяц система отметила неудачные попытки входа с одного IP-адреса 30+ раз подряд. Это автоматический брутфорс из интернета, fail2ban забанил, но именно auditd показал, что попытки были.

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

Что показала проверка ЦБ

Через 47 дней после внедрения банк прошёл повторную проверку. Аудиторы проставили галочки по всем пунктам предписания. Отдельно они проверяли вот что:

• Журналирование действий привилегированных пользователей — есть.
• Защита логов от изменения и удаления — есть, конфигурация auditd иммутабельна, копии уходят на центральный сервер.
• Хранение логов 90+ дней — есть.
• Журналирование изменений системных файлов — есть.
• Журналирование событий аутентификации (успешных и неуспешных) — есть.
• Корреляция событий и алертинг — есть, через Wazuh.

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

Сколько это стоит для среднего бизнеса

Цены за апрель 2026 года, с НДС, под типичные размеры инфраструктуры:

Наше сопровождение включает в себя еженедельную проверку, чтобы убедиться, что всё работает корректно. Мы разбираем все алерты от Wazuh, оперативно корректируем правила, если в инфраструктуре что-то меняется, и, конечно, готовим ежемесячный отчёт для руководства. А ещё у нас есть отдельный пакет услуг — «реагирование на инциденты». Стоит он 12 000 руб./мес, и в него входит наша круглосуточная поддержка, готовая прийти на помощь в любой тревожной ситуации, которую зафиксирует система безопасности.

Подводные камни, о которых редко пишут

• Логи быстро занимают много места. При полном наборе правил каждый сервер генерирует около 200 МБ в сутки. За 90 дней — 18 ГБ. На центральном сервере для 15 машин нужно минимум 300 ГБ под годовой архив.
• Шум — главный враг полезности. Без правильных исключений аудит ловит каждое движение мониторингового агента и забивает журнал тысячами однотипных записей. Найти что-то полезное в этом потоке невозможно. Тюнинг исключений — половина работы.
• Auditd без SIEM почти бесполезен. Сами по себе логи никто не читает. Их должна разбирать корреляционная система, которая выдаёт уже готовые алерты «сработало правило X на сервере Y».
• Жёсткое поведение «остановить сервер при заполнении диска» страшит руководство. Я всегда обсуждаю это отдельно с клиентом. Для PCI DSS нужно именно так. Для не-финансовых компаний можно мягче — переход в read-only или просто алерт.
• Попытка отключить аудит — сама по себе подозрительное событие. Если кто-то с root пытался что-то сделать с auditd — это сразу алерт высокого уровня.

FAQ — частые вопросы

Зачем нужен аудит действий, если есть пароли и SSH-ключи?

Пароли защищают от чужих, а аудит — от своих. По статистике страховых компаний, более 60 % инцидентов в IT-инфраструктуре происходят по вине внутренних сотрудников. Без журнала действий невозможно расследовать, кто что сделал, и привлечь виновного к ответственности.

Только ли банкам это нужно?

Нет. Любая компания, работающая с персональными данными клиентов (152-ФЗ), любой государственный подрядчик (ФСТЭК), любая компания с собственной разработкой и ценным кодом — все обязаны вести аудит. Просто в банках за нарушение прилетает быстрее всего.

Сколько стоит внедрение аудита на десяток серверов?

Развёртывание auditd на 10–15 серверов с централизованным сбором логов и интеграцией с SIEM — от 95 000 руб. Дальше — поддержка в составе абонентки от 6 000 руб./мес.

Сколько места на диске занимают логи?

При полном наборе правил для PCI DSS — около 200 МБ в сутки на сервер. С хранением 90 дней получается около 20 ГБ. На центральном сервере для 15 машин нужно около 300 ГБ под архивы за год.

Auditd замедляет работу серверов?

При 60–70 правилах прирост нагрузки на CPU составляет 2–4 %. Системные вызовы становятся на 0,5–2 микросекунды дольше. Для подавляющего большинства бизнес-приложений это незаметно. Если у вас высоконагруженный сервис на 100 000 запросов в секунду, тогда нужен индивидуальный тюнинг.