Специалист по аудиту кибербезопасности

Отчёт по аудиту кибербезопасности

ООО «Ключ-Маркет» — региональный онлайн-ритейлер

Дата: 24.09.2026 | Класс аудита: комплексный (VA + policy review + сценарий PT) | Периметр: согласно ТЗ (авторизованные активы)

⚠️ Правовая рамка. Все технические действия, включая разведку и тестирование, выполняются только по подписанному письменному разрешению владельца активов (Rules of Engagement), в согласованное окно, на перечисленных в scope целях. Тестирование платёжного контура согласуется с ЮKassa и не затрагивает боевые платёжные данные.

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

Компания обрабатывает персональные данные ~2500 клиентов и проводит онлайн-платежи, что автоматически подводит её под требования ФЗ-152 и PCI DSS v4.0. Текущее состояние ИБ создаёт высокий совокупный риск — реалистичный сценарий утечки клиентской базы, компрометации админ-панели и остановки продаж.

Пять главных рисков простым языком:

1. Нет второго фактора (MFA) для админки и CRM. Одного украденного пароля (а фишинг у вас уже был) достаточно, чтобы получить полный доступ к заказам и данным клиентов.
2. Старые пароли администраторов (>1 года) и необновлённые серверы. Это как оставить входную дверь на старом замке, к которому давно гуляют копии ключей, плюс известные «отмычки» (публичные уязвимости) для непропатченных систем.
3. Резервные копии лежат на том же сервере. При шифровальщике или отказе оборудования вы теряете и данные, и бэкап одновременно — восстановиться будет нечем.
4. Неполное логирование действий в админке. При инциденте вы не сможете понять, кто, что и когда сделал — это и операционная слепота, и прямое нарушение PCI DSS.
5. Разрывы в соответствии PCI DSS и ФЗ-152. Часть обязательных мер отсутствует, что грозит штрафами, санкциями банка-эквайера и репутационными потерями.

Что делать в первую очередь (30 дней): включить MFA везде, сменить и упорядочить пароли, вынести бэкапы за пределы сервера, обновить критичные системы. Это недорогие меры с максимальным эффектом.

2. Оценка уязвимостей и таблица находок

Оценки CVSS приведены по методике v3.1, ориентировочно (финальный балл уточняется после инструментальной проверки).

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

3. Анализ политик и процессов

Контроль доступа. Нет MFA, устаревшие пароли, вероятно отсутствует принцип наименьших привилегий и регулярный пересмотр прав. → Внедрить RBAC, ежеквартальный access review, отзыв доступа при увольнении, отдельные учётки для админ-задач.

Защита данных. ПДн клиентов и платёжные операции требуют: шифрования при передаче и хранении, минимизации данных, сегментации PCI-контура. Проверить, не хранятся ли карточные данные (в идеале — токенизация на стороне ЮKassa, чтобы не попадать в полный scope PCI DSS).

Реагирование на инциденты (IR). Фишинг июля 2026 показал, что план IR либо отсутствует, либо не отработан. → Разработать и протестировать IR-план (роли, эскалация, уведомление РКН при утечке ПДн, взаимодействие с банком), проводить table-top учения.

Обучение сотрудников. Разовых мер недостаточно. → Программа security awareness минимум 2 раза в год + симуляции фишинга + онбординг-обучение.

4. Сценарий тестирования на проникновение (концептуально, для авторизованного периметра)

Методология: PTES / OWASP WSTG / OSSTMM. Модель: серый ящик для API/админки, чёрный ящик для внешнего периметра.

Этап 1 — Разведка (Recon). Пассивный сбор (DNS, поддомены, публичные утечки), затем активное картирование сервисов и версий по scope. Цель — карта поверхности атаки.

Этап 2 — Идентификация уязвимостей. Сканирование веб-приложения и API (аутентификация, авторизация/IDOR, инъекции, некорректные конфиги, заголовки безопасности), проверка TLS, выявление устаревших компонентов.

Этап 3 — Эксплуатация (контролируемо). Проверка подтверждённых слабых мест в согласованных рамках, без разрушающих действий и без доступа к боевым платёжным данным. Приоритет — подтверждение возможности доступа к данным клиентов и админ-функциям.

Этап 4 — Пост-эксплуатация. Оценка глубины воздействия: возможность горизонтального перемещения, доступ к бэкапам/секретам, эскалация привилегий, потенциальное закрепление — на модельном уровне для оценки риска, с немедленным откатом изменений.

Этап 5 — Отчётность и повторная проверка. Документирование, оценка по CVSS, рекомендации, re-test после исправлений.

5. Примеры команд разведки

# ============================================================
# ⚠️ ТОЛЬКО ДЛЯ АВТОРИЗОВАННЫХ ЦЕЛЕЙ ИЗ SCOPE.
# Требуется письменное разрешение (RoE) и согласованное окно.
# Запуск против чужих систем — незаконно.
# ============================================================

TARGET="keymarket.example.ru"   # цель строго из авторизованного scope

# --- Пассивная разведка: DNS-записи ---
dig +short A     "$TARGET"
dig +short MX    "$TARGET"
dig +short TXT   "$TARGET"      # проверка SPF/DKIM/DMARC-записей
dig +short NS    "$TARGET"

# --- WHOIS ---
whois "$TARGET"

# --- Проверка почтовых политик (антифишинг) ---
dig +short TXT   "_dmarc.$TARGET"
dig +short TXT   "$TARGET" | grep -i spf

# --- Активное сканирование сервисов (только по разрешению) ---
# верхние порты, определение версий, безопасные скрипты
nmap -sV -sC --top-ports 1000 -oN nmap_scan.txt "$TARGET"

# --- Проверка TLS-конфигурации веб-сервера Nginx ---
nmap --script ssl-enum-ciphers -p 443 "$TARGET"
echo | openssl s_client -connect "$TARGET":443 -servername "$TARGET" 2>/dev/null \
  | openssl x509 -noout -dates -issuer

# --- Проверка HTTP-заголовков безопасности (HSTS, CSP и т.п.) ---
curl -sSI "https://$TARGET" | grep -Ei 'strict-transport|content-security|x-frame|x-content-type'

# --- Веб-технологии и заголовки ---
whatweb "https://$TARGET"

# --- Каталоги/эндпоинты веб-приложения (щадящий режим, свой wordlist) ---
# gobuster dir -u "https://$TARGET" -w /path/to/wordlist -t 10

# --- Проверка внутренних сервисов ТОЛЬКО во внутренней сети по RoE ---
# Redis и PostgreSQL не должны быть доступны извне:
# nmap -p 6379,5432 <internal_host_from_scope>

Для сканирования уязвимостей веб/API используются специализированные сканеры (в пассивном/щадящем режиме) с ручной верификацией находок, чтобы исключить ложные срабатывания и не нарушить работу боевой среды.

6. Матрица рисков

7. Дорожная карта исправлений

🚀 Быстрые победы (0–30 дней)

• Включить MFA для админ-панели, CRM, VPN, GitLab, почты (F-01).
• Сменить все пароли администраторов, внедрить менеджер секретов (F-02).
• Настроить offsite-бэкапы с шифрованием и тестом восстановления (F-04).
• Установить критичные обновления безопасности; включить unattended-upgrades (F-03).
• Закрыть Redis/PostgreSQL от внешнего доступа, проверить firewall (F-11).
• Настроить SPF/DKIM/DMARC (F-06).

🛠 Среднесрочные (1–3 месяца)

• Централизованное логирование + SIEM, хранение 12 мес. (F-05).
• WAF перед сайтом и API; статический анализ кода в CI (F-07, F-10).
• Ревизия авторизации в API на объектном уровне (F-08).
• Усиление TLS/заголовков Nginx, hardening K8s RBAC/NetworkPolicy (F-09, F-12).
• Сегментация сети: отделить PCI-контур и гостевой Wi-Fi (F-13).

🎯 Стратегические (3–12 месяцев)

• Формализовать процессы: патч-менеджмент, IR-план, access review.
• Программа security awareness + регулярные симуляции фишинга.
• Регулярные пентесты и сканирование уязвимостей (для PCI — по расписанию).
• Внедрение управления секретами (Vault) и подписи образов контейнеров.

8. Анализ пробелов в соответствии

PCI DSS v4.0 (ключевые разрывы):

• Треб. 8 (MFA, парольные политики) — не выполнено (F-01, F-02).
• Треб. 6 (управление уязвимостями/патчи) — не выполнено (F-03).
• Треб. 10 (логирование, хранение ≥12 мес.) — частично (F-05).
• Треб. 1/Сегментация — проверить изоляцию карточного контура (F-13).
• Треб. 3/токенизация — подтвердить, что карточные данные не хранятся у вас (передача в ЮKassa).
• Треб. 11 (регулярное тестирование) — внедрить.

ФЗ-152 «О персональных данных»:

• Организационно-технические меры защиты ПДн — усилить (шифрование, доступ, логи).
• Модель угроз и оценка вреда субъектам — актуализировать.
• Порядок уведомления РКН при утечке (в срок 24/72 ч) — регламентировать в IR-плане.
• Согласия, политика обработки ПДн, назначение ответственного — проверить наличие и актуальность.

Внутренняя политика ИБ:

• Привести в соответствие с фактическими процессами: парольная политика, управление доступом, реагирование на инциденты, обучение, резервное копирование.

Уточняющие вопросы для финализации оценки

1. Хранятся ли у вас карточные данные (PAN) или всё через токенизацию ЮKassa? Это определяет объём PCI-scope.
2. Точный перечень необновлённых серверов и их роли (внешние/внутренние)?
3. Есть ли текущая модель угроз ФЗ-152 и приказ о назначении ответственного за ПДн?
4. Настроены ли SPF/DKIM/DMARC сейчас и какой политикой?
5. Разрешено ли тестирование в боевой среде или предоставляется stage-копия?

Готов детализировать любой раздел (например, чек-лист hardening Nginx/K8s или полный шаблон IR-плана и парольной политики).