Проверка регулятора: какие артефакты попросят именно у админа

MAATRIX

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

Что в проверке относится к админу, а что нет

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

Но есть общая закономерность: любая проверка технической инфраструктуры делится на два блока.

• Организационный блок — политики, приказы о назначении ответственных, модель угроз, акты, переписка с регулятором. Этим занимается комплаенс или юрист, администратора обычно просят только подтвердить факты, изложенные в документах.
• Технический блок — то, что можно снять с сервера, коммутатора или системы логирования командой или экспортом. Это ваша зона: журналы событий, конфигурации, список установленного ПО, схема сети, список пользователей с доступом.

Дальше — только про второй блок, то, что реально ложится на плечи администратора инфраструктуры. Общий подход к тому, как готовить сервер к проверке технически (обновления, firewall, SSH, шифрование), разобран в статье как подготовить сервер к аудиту безопасности — здесь же фокус именно на артефактах, которые у вас попросят предъявить.

Журналы событий: что и за какой период спросят

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

• журналы аутентификации — успешные и неуспешные попытки входа по SSH, в панель управления, в VPN;
• журналы действий с повышенными привилегиями — sudo, изменения конфигураций, работа с учётными записями;
• журналы сетевого доступа — кто подключался по VPN, с какого IP, когда сессия закрылась;
• журналы прикладного уровня — access-логи веб-сервера, логи СУБД (кто и когда менял данные), логи систем защиты (fail2ban, IDS/IPS, WAF);
• журналы изменений в самой системе логирования — если журнал можно тихо подчистить, для проверяющего это не журнал, а художественная литература.

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

Практический минимум, который стоит настроить заранее, а не за ночь до визита:

# посмотреть, сколько сейчас реально хранится в journald
journalctl --disk-usage
journalctl -u sshd --since "-30 days" | wc -l

# настроить постоянное хранение и лимит места, а не "пока хватит RAM"
sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal

В /etc/systemd/journald.conf:

[Journal]
Storage=persistent
SystemMaxUse=4G
MaxRetentionSec=1year

Локальный journald — это только часть картины: если сервер скомпрометируют, локальные логи может подчистить сам злоумышленник. Поэтому для журналов, которые реально могут спросить на проверке, нужен отдельный сборщик — rsyslog/syslog-ng на выделенный лог-сервер, или что-то вроде Graylog/Grafana Loki с отдельным правом на запись и без права удаления с рабочих серверов. Что и почему стоит хранить в логах, разобрано отдельно в статье что хранить в логах по закону.

Конфигурации сетевого оборудования и серверов

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

Что обычно входит в этот блок:

• конфигурации firewall/маршрутизации — правила nftables/iptables, ACL на коммутаторах и роутерах;
• конфигурации VPN-шлюзов — какие туннели подняты, кто к ним подключается;
• конфигурации критичных сервисов — sshd_config, конфиги веб-сервера и балансировщика, параметры СУБД, относящиеся к безопасности (кто может подключаться, шифрование соединения);
• конфигурации DNS — зоны, если вы держите свой DNS для внутренних ресурсов.

Снять текущий конфиг — не проблема:

sudo nft list ruleset > /root/audit-export/nftables-$(date +%F).conf
sudo sshd -T > /root/audit-export/sshd-effective-$(date +%F).conf

Проблема в другом: если у вас нет истории изменений, вы не ответите на вопрос «а когда и кто открыл этот порт наружу». Практическое решение — держать конфиги в git-репозитории (даже локальном, без сложной инфраструктуры):

cd /etc
sudo git init
sudo git add nftables.conf ssh/sshd_config nginx/
sudo git commit -m "baseline snapshot before audit prep"

Дальше каждое реальное изменение конфига коммитится с внятным сообщением — и на вопрос «покажите, когда менялось правило firewall» у вас есть git log с датами и авторами, а не воспоминания по памяти. Для сетевого оборудования (коммутаторы, роутеры без полноценной ФС) роль git часто играет отдельный сервер с RANCID или простым cron-скриптом, который раз в сутки снимает show running-config и коммитит diff.

Инвентаризация установленного ПО и версий

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

Минимальный набор, который нужно уметь предъявить:

• версия ОС и ядра на каждом сервере;
• список установленных пакетов с версиями;
• список работающих сервисов (что реально слушает сеть, а не что просто установлено);
• версии СУБД, веб-сервера, интерпретаторов (PHP/Python/Node), контейнерных образов, если используется Docker.

# снимок пакетов Debian/Ubuntu/Astra
dpkg-query -W -f='${Package}\t${Version}\n' > inventory-packages-$(date +%F).txt

# снимок для RPM-based
rpm -qa --qf '%{NAME}\t%{VERSION}-%{RELEASE}\n' > inventory-packages-$(date +%F).txt

# что реально слушает сеть — часто интереснее списка пакетов
ss -tulpn > inventory-listening-$(date +%F).txt

Разовый снимок отвечает на вопрос «что стоит сейчас», но проверяющий может спросить и «что стояло полгода назад, на момент инцидента X». На этот вопрос отвечает только история снимков, а не одна свежая выгрузка. Практика, которая себя окупает: cron-задача раз в неделю кладёт датированный файл инвентаризации в отдельный каталог (или коммитит в тот же git-репозиторий, что и конфиги), а для парка из нескольких серверов — Ansible-плейбук или простая CMDB (даже таблица в NetBox/GLPI лучше, чем ничего), которая собирает это со всех машин в одно место.

Если в инфраструктуре есть российский софт с формальным статусом (реестр отечественного ПО, сертифицированные версии) — держите отдельно список таких компонентов с версиями сертификатов, это почти наверняка спросят отдельным пунктом; за деталями того, что именно нужно фиксировать для конкретного класса системы — к профильному специалисту.

Схема сети и список ответственных с доступом

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

Схема сети. Проверяющего интересует не красивая картинка для презентации, а рабочая схема: сегменты (внешний, внутренний, DMZ, сегмент с чувствительными данными), где стоят firewall и на каких границах, какие VLAN существуют и что в них живёт, где заканчивается зона ответственности вашей компании и начинается зона провайдера/хостера. Если схему рисовали два года назад и с тех пор трижды меняли сеть без обновления картинки — на проверке это будет видно моментально по несовпадению с реальными конфигами.

Практично держать схему не в отдельном файле «где-то в Confluence, который никто не открывал», а как часть того же репозитория, что и конфиги — например, диаграмму в формате Mermaid или draw.io рядом с конфигами, с обязательным пунктом «обновить схему» в чек-листе любого сетевого изменения.

Список ответственных и доступов. Тут спрашивают:

• кто имеет учётные записи с правами администратора/root на каждой системе;
• как выдаётся и как отзывается доступ (в том числе — отозван ли доступ у уволенных сотрудников и подрядчиков, это проверяют почти всегда);
• используется ли персонализация доступа (у каждого свой аккаунт) или общий root-пароль на всех;
• как организован удалённый доступ — VPN, кто подключался и когда.

Таблица того, что стоит держать под рукой в актуальном виде:

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

Как держать это в порядке круглый год, а не собирать в последнюю ночь

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

Практические привычки, которые снимают панику:

• Снимки, а не память. Cron/systemd-таймер раз в неделю снимает конфиги, список пакетов, список открытых портов и коммитит в git с датой. Через полгода у вас не только текущее состояние, но и история — а вопрос «а что было в момент инцидента» перестаёт быть проблемой.
• Доступы — часть процесса найма/увольнения, а не отдельная задача. Отзыв доступа увольняющегося сотрудника должен быть строкой в чек-листе HR-процесса, а не тем, что вспоминают через три месяца, когда готовятся к проверке.
• Схема сети обновляется вместе с изменением сети. Правило «поменял VLAN — обновил диаграмму в том же коммите» стоит одного дня работы и экономит день паники перед проверкой.
• У логов — политика хранения, а не ротация по умолчанию. Настройте retention осознанно (сколько хранить, где, с каким уровнем доступа на запись/удаление), а не полагайтесь на дефолтные 7 дней logrotate, о которых вспомнят только когда журналов за нужный период уже не будет.
• Раз в квартал — самопроверка по тому же списку, что спросит регулятор. Пройтись по пяти категориям (журналы, конфиги, ПО, схема, доступы) самостоятельно за час — дешевле, чем разбирать несостыковки на самой проверке.
• Один человек отвечает за актуальность каждого артефакта. Если ответственность размыта между всеми, за неделю до проверки выясняется, что не отвечал никто.

Ни один из этих пунктов не требует дорогого инструмента — git, cron и таблица с ответственными закрывают большую часть работы. Дальше уже вопрос дисциплины: делать это регулярно, а не «когда будет время».

Частые вопросы