Ежеквартальный прогон чек-листа безопасности: 20 пунктов за час

MAATRIX

Если в компании уже заведены отдельные регламенты — ревизия пользователей, сверка портов, проверка бэкапа, проверка мониторинга, — к концу квартала это превращается в пять разных задач в календаре, каждая со своим чек-листом, своим временем и своим шансом быть перенесённой «на следующую неделю». На практике из пяти запланированных проверок реально проводятся две-три, а остальные тихо съезжают на полгода. Ниже — не новый регламент, а сборка уже существующих в один прогон на час: 20 пунктов, которые закрывают доступы, сеть, данные, обновления и мониторинг одним заходом, раз в квартал, без пяти отдельных напоминаний.

Почему один час раз в квартал лучше пяти проверок по отдельности

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

Сжатый прогон решает другую задачу, чем глубокая проверка. Это не замена детальным регламентам — ревизии пользователей на getent passwd и /etc/sudoers, сверке портов через ss и nmap, тесту восстановления бэкапа на отдельном окружении. Каждая из этих проверок по-прежнему нужна в своём полном виде, и ссылки на них — ниже. Прогон на час — это верхнеуровневый скан: 20 быстрых пунктов, каждый на 2-3 минуты, которые ловят грубые отклонения от нормы. Если пункт красный — тогда открывается полная процедура по этой теме. Если все 20 зелёные — квартал закрыт без пяти отдельных сессий.

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

Доступы: пользователи, sudo, SSH-ключи

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

# 1. Список пользователей с UID выше системного порога
awk -F: '$3 >= 1000 && $3 < 65534 {print $1, $3, $7}' /etc/passwd

# 2. Кто состоит в группе sudo/wheel
getent group sudo   # Debian/Ubuntu
getent group wheel  # RHEL/AlmaLinux

# 3. Записи в sudoers без запроса пароля — на них смотреть в первую очередь
grep -r NOPASSWD /etc/sudoers /etc/sudoers.d/ 2>/dev/null

# 4. Ключи в authorized_keys для каждого пользователя с shell
for u in $(awk -F: '$3>=1000{print $1}' /etc/passwd); do
  f="/home/$u/.ssh/authorized_keys"
  [ -f "$f" ] && echo "== $u ==" && cat "$f"
done

# 5. Даты последнего входа — молчащие аккаунты видно сразу
lastlog | grep -v "Never logged in"

Чек-лист на этот блок:

• [ ] Нет пользователей с UID выше порога, назначение которых непонятно за 10 секунд
• [ ] В группе sudo/wheel только те, кому реально нужен root прямо сейчас
• [ ] Нет новых NOPASSWD-записей в sudoers, которых не было в прошлом квартале
• [ ] Каждый ключ в authorized_keys подписан комментарием и принадлежит действующему человеку
• [ ] Нет пользователей, которые не логинились полгода и больше, но всё ещё активны

Если по первому пункту нашлась хотя бы одна подозрительная запись — это повод открыть полную ревизию пользователей и sudo и разобрать её до конца, а не гадать в рамках часового прогона.

Сеть: открытые порты и firewall

Второй блок — что сервер показывает наружу. Здесь чаще всего всплывают порты, открытые Docker в обход правил firewall, тестовые сервисы, забытые после отладки, и сами правила firewall, которые кто-то расширил «временно» полгода назад.

# 6. Порты, слушающие снаружи (не 127.0.0.1)
ss -tulpn | grep -v 127.0.0.1

# 7. Статус и правила firewall
ufw status verbose        # если используется ufw
nft list ruleset          # если используется nftables напрямую

# 8. Сверка с docker — контейнеры пробрасывают порты в обход ufw через iptables DOCKER-USER
docker ps --format '{{.Names}}: {{.Ports}}'

# 9. Взгляд снаружи — с другой машины или сервиса вроде Shodan/сканера
nmap -Pn -p- your-server-ip

Чек-лист:

• [ ] Список слушающих портов совпадает с эталонным списком сервисов сервера
• [ ] В правилах firewall нет строк «allow all» или широких диапазонов без комментария
• [ ] Порты, проброшенные через docker -p, тоже учтены в проверке — они не проходят через ufw
• [ ] Сканирование снаружи не показывает ничего, кроме ожидаемых 80/443/22 (или что у вас открыто по плану)

Это ровно тот минимум, который в развёрнутом виде описан в ежемесячной сверке открытых портов — там же лежит скрипт для автоматической сверки с эталонным списком, если хочется, чтобы этот блок вообще не требовал ручных действий каждый квартал.

Данные: бэкапы и права на файлы

Третий блок — про то, что случится, если сервер сгорит завтра, и про то, кто прямо сейчас может прочитать или изменить чужие данные на нём.

# 10. Бэкап действительно создаётся и не старше суток-двух
ls -lh /path/to/backups/ | tail -5

# 11. Реальное восстановление (не просто факт создания файла)
# распаковать последний бэкап на тестовое окружение и сверить контрольную сумму/содержимое
sha256sum backup-latest.tar.gz
tar -tzf backup-latest.tar.gz | head -20

# 12. Файлы и директории с правами 777
find / -xdev -type f -perm -002 -not -path "/proc/*" 2>/dev/null
find / -xdev -type d -perm -002 -not -path "/proc/*" 2>/dev/null

# 13. SUID-бинарники, которых не должно быть
find / -xdev -perm -4000 -type f 2>/dev/null

Чек-лист:

• [ ] Последний бэкап не старше плана (обычно 24-48 часов) и его размер не «подозрительно маленький»
• [ ] Хотя бы один файл из бэкапа реально распакован и прочитан — не только «процесс завершился без ошибок»
• [ ] Нет файлов и директорий с 777 вне заранее известных исключений
• [ ] Список SUID-бинарников совпадает со списком из прошлого квартала — новых нет

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

Обновления: статус патчей безопасности

Четвёртый блок — короче остальных, потому что здесь достаточно посмотреть на статус, а не проводить полное обновление в рамках часового прогона (это отдельная плановая задача с окном простоя).

# 14. Сколько security-патчей ждёт установки
apt list --upgradable 2>/dev/null | grep -i security   # Debian/Ubuntu
dnf updateinfo list security                            # RHEL/AlmaLinux

# 15. Работает ли автоматическое применение security-патчей, если оно настроено
systemctl status unattended-upgrades   # Debian/Ubuntu
systemctl status dnf-automatic.timer   # RHEL/AlmaLinux

# 16. Дата последнего успешного применения обновлений
grep -a "Packages that will be upgraded" /var/log/unattended-upgrades/unattended-upgrades.log | tail -3

# 17. Версия ядра, на которой реально работает система, против установленной
uname -r

Чек-лист:

• [ ] Список security-патчей, ожидающих установки, не растёт квартал к кварталу
• [ ] Сервис автообновлений (если настроен) действительно запущен, а не «висит failed» полгода
• [ ] Дата последнего применённого патча укладывается в принятый в компании срок (например, правило двух недель для критичных CVE)
• [ ] Работающее ядро совпадает с установленным — иначе после установки патчей нужен перезапуск, который никто не сделал

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

Мониторинг: жив ли тот, кто должен вас разбудить

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

# 18. Процесс мониторинга и экспортёров действительно запущен
systemctl status prometheus node_exporter alertmanager 2>/dev/null

# 19. Тестовая тревога реально доходит до канала уведомлений
# отправить тестовый алерт вручную и засечь, пришло ли сообщение
curl -X POST http://localhost:9093/api/v2/alerts -H "Content-Type: application/json" \
  -d '[{"labels":{"alertname":"test_quarterly_check","severity":"warning"}}]'

# 20. Dead man's switch (если настроен) получал регулярный heartbeat весь квартал
curl -s https://your-dead-mans-switch-provider/status/your-check-id

Чек-лист:

• [ ] Процессы мониторинга и экспортёров запущены на всех серверах, а не только на основном
• [ ] Тестовая тревога, отправленная вручную, дошла до реального канала (Telegram/почта/PagerDuty) за разумное время
• [ ] Dead man's switch не показывает пропусков heartbeat за последние три месяца
• [ ] Список получателей алертов актуален — уволенные не значатся, новые сотрудники добавлены

Логика и полный разбор трёх способов, которыми мониторинг тихо перестаёт работать, — в статье проверка мониторинга на живучесть. Пункт 19 из неё — тестовая тревога — стоит проводить каждый квартал даже в сжатом прогоне, потому что это единственный способ поймать, например, протухший токен бота или неправильно настроенный маршрут алертов.

Как оформить прогон, чтобы он реально проходил каждый квартал

Формат имеет значение больше, чем содержание. Рабочий способ — завести один файл-чек-лист (например, security-checklist.md в репозитории с инфраструктурными скриптами или в внутренней wiki), где 20 пунктов лежат построчно, а рядом — дата и имя того, кто прогонял. Каждый квартал копируется новый блок, а не переписывается старый — так остаётся история: видно, что́ было красным в прошлый раз и починилось ли это к следующему разу.

Q3 2026 — прогон 28.08.2026, провёл: A.Иванов

• [x] 1. Список пользователей UID>=1000 — 3 записи, все объяснены
• [x] 2-3. sudo/NOPASSWD — без изменений с Q2
• [ ] 4. authorized_keys — найден ключ без комментария у user 'deploy', уточняем

...

Отдельный вопрос — кто проводит прогон. Если это один и тот же человек каждый раз, полезно раз в год менять исполнителя: свежий взгляд иногда замечает то, что примелькавшийся глаз пропускает — например, тот же NOPASSWD-доступ, который сам же администратор когда-то и выдал, ему проще не заметить, чем коллеге со стороны. Час на 20 пунктов — реалистичная оценка, если у вас один сервер или небольшой кластер из 2-3 машин с похожей конфигурацией; на десяток разнородных серверов закладывайте по 10-15 минут на каждый после того, как первый прогон отработает как эталон для остальных.

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

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