Аудит действий администраторов на 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 запросов в секунду, тогда нужен индивидуальный тюнинг.