Экспресс-аудит

Инфраструктура CRM: закрываем утечку и ускоряем отклик за неделю

Реальный кейс экспресс-аудита CRM на Ubuntu 22.04. За 24 часа убрали внешний доступ к MySQL и Redis, зафиксировали отсутствие ротации binlog и логов, отключили парольный вход и root по SSH. За последующие 7 дней настроили оффсайт-бэкапы, синхронизацию времени, мониторинг, CI/CD-джобы и оптимизировали PHP-FPM/Nginx и индексы MySQL. Итог — ускорение на 40–60% без переписывания кода.

Подготовил Балакирев Д.А.

Дата 19.10.2025

Окно наблюдения 18.10.2025, 12:00–16:30 (CET)

Объект Веб-CRM, отдельный Redis-кэш

Резюме для руководства

3 критичных риска закрыты за 24 часа. За 7 дней — +40–60% к скорости.

P1 — критично

3 риска

За сутки закрыли внешний доступ к БД и Redis, описали отсутствие ротации логов и риск переполнения Nginx-журналов, ужали SSH-контур до ключей и доверенных CIDR.

P2 — важно

3 задачи

Оффсайт-бэкап, синхронизация времени и тюнинг FPM/Nginx/MySQL заняли 3–7 дней и дали стабильный отклик.

P3 — улучшения

4 направления

TLS, мониторинг, почтовая репутация, CI/CD-джобы и авторазвёртывание — плановые доработки на 7–14 дней с прозрачными критериями приёмки.

Сводка

3 критичных риска — устранили за 24 часа

Закрыли внешний доступ к БД/кэшу, описали отсутствие ротации binlog, journald и Nginx-логов, отключили парольный доступ по SSH. Следом настроили оффсайт-бэкап, синхронизацию времени, мониторинг, CI/CD-джобы и оптимизировали FPM/Nginx и MySQL. Эффект — 40–60% ускорения без изменения кода и прозрачный план дальнейших улучшений.

P1 — критично (24 часа)

1. Открытые MySQL и Redis (утечка данных) Ответственный: системный администратор / DBA

Наблюдение: mysqld слушает 0.0.0.0:3306 и :::3306; Redis открыт на 0.0.0.0:6379 и :::6379, аутентификация отсутствует.

Цель: MySQL и Redis доступны только локально через 127.0.0.1 или unix-сокеты и только для приложений.

MySQL: bind-address = 127.0.0.1, внешние порты закрыть на фаерволе. Доступ между хостами — через VPN или SSH-туннели.
Redis: bind 127.0.0.1, requirepass <строгий_пароль>, переименовать опасные команды (rename-command FLUSHALL "", rename-command CONFIG ""), включить protected-mode yes.
Фаервол: разрешить извне только 80/443 tcp, SSH — по ключам с доверенных CIDR.

Критерий приёмки: ss -lntp показывает только 127.0.0.1:3306 и 127.0.0.1:6379.

2. Диск: отсутствие ротации логов и риск остановки Ответственный: системный администратор / DBA

Наблюдение: раздел занят критично: mysql-bin.*, /var/log/journal и архивы Nginx растут без ограничений. Ротация логов Nginx/PHP-FPM не настроена, переполнение логов может остановить запись, MySQL, Nginx/PHP-FPM и саму CRM.

Цель: Свободное место держится с запасом, рост логов ограничен политиками ротации и алертами.

MySQL 8.0: включить binlog_expire_logs_seconds = 604800, очистить старые файлы командой PURGE BINARY LOGS BEFORE NOW() - INTERVAL 10 DAY;
journald: Storage=auto, SystemMaxUse=1G, MaxRetentionSec=30day, очистка journalctl --vacuum-size=1G.
logrotate: включить ежедневную ротацию Nginx/PHP-FPM, сжатие архивов, ограничение ретенции и проверку logrotate -d.

Критерий приёмки: df -h показывает запас свободного места, logrotate -d проходит без ошибок, алерт на рост логов доставляется.

3. SSH-безопасность: пароль и root Ответственный: системный администратор

Наблюдение: PasswordAuthentication yes, PermitRootLogin yes, fail2ban отсутствует.

Цель: Доступ только по ключам, root закрыт, источники ограничены.

SSH: PasswordAuthentication no, PermitRootLogin no, PubkeyAuthentication yes.
UFW: default deny incoming, разрешить 80/443 tcp, 22 tcp только с доверенных CIDR; включить UFW.
fail2ban: джейлы для sshd и nginx-http-auth.

Критерий приёмки: Парольный вход невозможен, root по SSH недоступен, 22/tcp открыт только для белых подсетей.

P2 — важно (3–7 дней)

4. Резервное копирование: только локальные дампы Ответственный: системный администратор

Проблема: mysqldump ежедневно складывается на тот же диск, без шифрования и тестового восстановления. Действия: BorgBackup + rclone в S3-совместимое хранилище, borgmatic для расписаний, ретенции 7d/4w/6m/1y, шифрование, еженедельный тест restore на стенд. Критерий: протокол успешного восстановления, контрольные суммы совпадают.

5. Несинхронизированное время (NTP/chrony) Ответственный: системный администратор

Проблема: рассинхронизация ≈4 мин 12 сек, TLS и JWT-подписи «протухают». Действия: chrony или systemd-timesyncd, проверка timedatectl, источники — pool.ntp.org или корпоративный NTP. Критерий: chronyc tracking в норме, отметки времени совпадают на хостах.

6. Узкие места PHP-FPM и Nginx Ответственные: системный администратор / разработчик

Проблема: очередь php-fpm, 502/504 под пиками, pm.max_children не соответствует памяти, slowlog выключен, gzip/http2 не везде, статика без cache-control.

Действия: пересчитать пул (pm = dynamic, pm.max_children по RSS, pm.max_requests = 500–1000), включить opcache 256–512 MiB, revalidate, gzip/http2, кэш статики с Cache-Control: public, max-age=31536000, immutable, включить slowlog и разбор медленных функций.

Критерий: p95 TTFB ↓ ≥30%, HTTP 5xx < 0.1% за сутки.

7. MySQL 8.0: тяжёлые запросы Ответственные: DBA / разработчик

Проблема: по pt-query-digest 35% времени — FULL SCAN на vtiger_* и modtracker, подготовленные запросы пересоздаются.

Действия: добавить покрывающие индексы: ALTER TABLE vtiger_waybill ADD INDEX idx_wb_customer_status (customer_id, status, modifiedtime); ALTER TABLE vtiger_crmentity ADD INDEX idx_crm_deleted_mod (deleted, setype, modifiedtime); включить performance_schema, innodb_monitor_enable=all, закрепить планы.

Критерий: топ-10 slow-log < 2 с, доля FULL SCAN < 5%.

P3 — плановые улучшения (7–14 дней)

8. TLS-гигиена и Certbot

Обновить Certbot до актуальной версии (snap/pipx), протестировать certbot renew --dry-run, включить OCSP stapling и HSTS (max-age=31536000; includeSubDomains; preload), проверить цепочки поддоменов. Критерий: срок сертификатов > 60 дней, SSL Labs ≥ A.

9. Redis как кэш

Задать maxmemory по объёму горячего набора и политику allkeys-lru, мониторить evicted_keys. Критерий: отсутствие OOM и предсказуемая латентность.

10. CI/CD и контейнеризация

Сейчас нет воспроизводимых CI/CD-джоб, автосборки и авторазвёртывания: релиз зависит от ручных действий и плохо откатывается. Ввести Docker Compose (app, web, db-socket, redis) в приватной сети, секреты через env/vault; Git-потоки main/develop, теги vX.Y.Z, автосборку образов, staging-деплой по merge, ручной промоушн в prod с health-check и откатом ≤5 минут. Критерий: джобы build/test/deploy зелёные, staging обновляется автоматически, релиз воспроизводится ≤15 минут, откат ≤5 минут.

11. Мониторинг и оповещения

Сейчас нет полноценного мониторинга и подтверждённых алертов: команда узнаёт о переполнении диска, падении Nginx/MySQL/Redis, сбое cron или бэкапа уже постфактум. Настроить Zabbix + Telegram: триггеры на RAM>90% (3 мин), Disk>90% (10 мин), рост Nginx/journald/binlog, CPU>90% (3 мин), Swap<10% (3 мин), HTTP/MySQL/Redis недоступны >1 мин, TLS <10 дней, cron >30 мин, HTTP 5xx >25 за 5 мин, бэкап >24 ч. Критерий: тестовый алерт доставлен, action-лог подтверждает получение, дежурный видит runbook.

12. Почтовая доставляемость

Настроить SPF (с include провайдера), DKIM и DMARC (p=quarantine) с отчётами. Критерий: Gmail/Postmark/Яндекс — «не спам», mail-tester ≥ 9/10.

Проверка состояния после исправлений

Acceptance checklist

ДоступMySQL/Redis закрыты извне, сервисы доступны только локально или через VPN.
Диск и логиСвободное место держится с запасом, Nginx/PHP-FPM/binlog/journald ограничены ротацией и алертами.
SSHТолько ключи, root выключен, fail2ban активен, CIDR-фильтр настроен.
БэкапыОффсайт, шифрование, ретенции 7d/4w/6m/1y, еженедельный тест restore.
Производительностьp95 TTFB ↓ ≥30%, HTTP 5xx < 0.1% за сутки.
MySQLДоля FULL SCAN < 5%, топ-10 slow-log < 2 секунд.
TLSCertbot продлевает сертификаты без ошибок, оценка TLS ≥ A.
МониторингZabbix/Telegram доставляют алерты по диску, Nginx, MySQL, Redis, cron, бэкапам и CI/CD.

План действий и SLA

10 задач с конкретными критериями

№	Задача	Приоритет	Ответственный	Срок	Критерий
1	Закрыть внешние 3306/6379, локальный bind, пароль Redis	P1	Сисадмин/DBA	24 ч	`ss -lntp` → только 127.0.0.1
2	Настроить ротацию binlog/journal/Nginx/PHP-FPM и алерты по заполнению	P1	Сисадмин/DBA	24 ч	`df -h` с запасом, `logrotate -d` OK
3	SSH: запрет пароля и root, UFW+fail2ban	P1	Сисадмин	24 ч	Вход только по ключам, CIDR-фильтр
4	Borg + rclone, ретенции, тест restore	P2	Сисадмин	3 дня	Протокол успешного восстановления
5	Настроить NTP/chrony	P2	Сисадмин	3 дня	`chronyc tracking` OK
6	Тюнинг PHP-FPM/Nginx, slowlog	P2	Сисадмин/Dev	7 дней	p95 TTFB ↓ ≥30%
7	Индексы MySQL, планы, slow-log	P2	DBA/Dev	7 дней	FULL SCAN <5%
8	Certbot + HSTS/OCSP	P3	Сисадмин	7 дней	SSL Labs ≥ A
9	Zabbix + Telegram, алерты по сервисам, логам, cron и deploy	P3	Сисадмин	7 дней	Тест-алерт доставлен
10	SPF/DKIM/DMARC	P3	Сисадмин	14 дней	`mail-tester` ≥ 9/10

Финансовые и репутационные риски

Простой

Переполнение Nginx/PHP-FPM/journald/binlog или компрометация SSH приводят к остановке сервисов и простоям. Каждый час — средний чек × поток заказов.

Утечка

Открытые 3306/6379 = высокий риск утечки, штрафов и потери клиентов.

Потеря данных

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

Итог: за 24 часа снимаем риск утечки и простоя, за 3–7 дней — оффсайт-бэкапы, синхронизация времени, оптимизация FPM/Nginx и индексов. Эффект — ускорение отклика на 40–60% без переписывания кода.

Приложение №1. Технический отчёт

Инвентарь и метрики

Общие сведения

Аппаратно: 8 vCPU, 16 GiB RAM, 512 GiB NVMe (ext4).
ОС: Ubuntu 22.04.4 LTS, ядро 5.15.
Сети/порты: 80/443 (Nginx), 22 (SSH), 3306 (MySQL), 6379 (Redis), 10050 (Zabbix agent).

ПО и данные

ПО: Nginx 1.18, PHP-FPM 8.1, MySQL 8.0.36, Redis 6.2, Node.js 18, Certbot 1.22, Zabbix agent.
Данные: основной объём занимают приложение, база MySQL и журналы. Рост /var/log, binlog и архивов Nginx требует ротации, ретенции и алертов.

Производительность: наблюдения → риск → действия

1. Сети и доступность (P1)

Наблюдение: 3306/6379 слушают на всех интерфейсах (IPv4/IPv6). Доказательства: ss -lntp, netstat -lnpt. Действия: локальный bind, VPN/SSH-туннели, UFW, пароли и запрет опасных команд в Redis.

2. Диск и логи (P1)

Наблюдение: binlog, journald и архивы Nginx растут без ротации; переполнение раздела может остановить запись логов, MySQL, Nginx/PHP-FPM и CRM. Действия: binlog_expire_logs_seconds, journalctl --vacuum-size, корректный logrotate и алерты по скорости роста.

3. SSH-политика (P1)

Наблюдение: пароль и root включены, fail2ban отсутствует. Действия: ключи, запрет root, белый список CIDR, fail2ban.

4. Резервные копии (P2)

Наблюдение: локальные дампы без оффсайта. Действия: Borg+rclone, ретенции, еженедельный тест restore.

5. Время (P2)

Наблюдение: смещение 4:12. Действия: chrony, контроль timedatectl.

6. PHP-FPM/Nginx (P2)

Наблюдение: очередь процессов, 502/504. Действия: тюнинг пула, opcache, gzip/http2, кэш статики, slowlog.

7. MySQL индексы (P2)

Наблюдение: полносканы на vtiger_* и modtracker. Действия: покрывающие индексы, профилирование, валидация планов.

8. TLS/Certbot (P3)

Наблюдение: устаревший Certbot, OCSP/HSTS не везде. Действия: обновление, строгая политика.

9. Мониторинг и почта (P3)

Наблюдение: полноценный мониторинг, алерты по логам/cron/deploy и DMARC отсутствуют. Действия: набор оповещений, Telegram, runbook дежурного, SPF/DKIM/DMARC.

Примечание: данные собраны за окно 18.10.2025 (12:00–16:30 CET). Количественные значения в публичной версии обезличены; выводы фиксируют уязвимые зоны и дорожную карту исправлений. Отчёт не включает полный security-аудит приложений, ревью кода и UX-оценку.

Следующий шаг

Хотите повторить этот сценарий для своей инфраструктуры?

Проведём экспресс-аудит, зафиксируем риски и соберём план внедрения под вашу команду. Подключим DevOps, DBA и разработчиков для быстрого исполнения и проверки результата.

Запросить аудит