Анализ защищенности: сканируем инфраструктуру, чтобы злоумышленник не прошёл первым

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

Что такое анализ защищённости (и чем он отличается от пентеста)

Многие путают анализ защищённости (Vulnerability Assessment, VA) и тестирование на проникновение (Penetration Test, пентест). И это разные вещи, хотя часто идут в комплекте. Лучше понять разницу поможет простое сравнение.

• Анализ защищённости (VA) — это автоматизированное или ручное сканирование инфраструктуры на предмет известных уязвимостей. Сканеры проверяют версии ПО, открытые порты, отсутствие обновлений, слабые настройки безопасности. Результат — длинный список уязвимостей с критичностью. Нет эксплуатации, нет взлома. Это как пригласить врача, который измерит давление, возьмёт анализы и скажет: «у вас проблемы с сердцем».
• Тестирование на проникновение (пентест) — это имитация реальной атаки. Специалист пробует получить доступ к системе, обойти защиту, повысить привилегии. Результат — отчёт о том, что именно удалось взломать и какие данные потенциально украдены. Пентест отвечает на вопрос «можно ли взломать и насколько серьёзны последствия».

Анализ защищённости обычно проводится чаще (раз в месяц или квартал), а пентест — реже (раз в полгода или год) и стоит дороже. Идеально, когда они дополняют друг друга.

Кому и зачем нужен анализ защищённости

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

Вот кому анализ защищённости необходим в первую очередь:

• Компаниям, работающим с персональными данными (ПДн). По закону 152-ФЗ операторы обязаны оценивать эффективность мер защиты. Анализ защищённости — один из обязательных пунктов.
• Банкам, страховым, МФО, платёжным сервисам. Регуляторы (ЦБ, Роскомнадзор) требуют регулярных проверок безопасности инфраструктуры.
• Онлайн-магазинам, маркетплейсам, сервисам доставки. Утечка базы клиентов с телефонами и адресами — это репутационные потери и миллионные штрафы.
• Медицинским и образовательным учреждениям. Они хранят чувствительные данные и часто имеют старую, плохо защищённую инфраструктуру.
• IT-компаниям и стартапам. Для соответствия стандартам SOC2, ISO 27001 и требованиям западных партнёров.
• Всем, кто боится потерять данные или деньги из-за атаки шифровальщика (ransomware). Такие атаки начинаются с эксплуатации известной уязвимости, которую можно было закрыть за месяц до атаки.

Виды анализа защищённости: от внешнего контура до внутренней сети

Инфраструктура может быть сложной: веб-сайты, мобильные приложения, серверы в облаке, рабочие станции сотрудников, сетевое оборудование. Анализировать всё сразу не всегда эффективно. Поэтому проверку делят на несколько типов.

Анализ защищённости внешнего периметра

Сканируются сервисы, доступные из интернета: веб-сайты, публичные API, VPN-шлюзы, почтовые серверы, RDP-порты. Специалист смотрит, что видит злоумышленник извне. Самый популярный вид. Часто находят открытые порты с устаревшими сервисами, слабые сертификаты SSL/TLS, незащищённые админки.

Анализ защищённости внутренней сети

Проводится изнутри компании — как если бы атакующий уже получил доступ в локальную сеть (например, через заражённую рабочую станцию). Проверяется, насколько легко он может перемещаться между сегментами, добраться до серверов с БД или доменного контроллера. Это про «horizontal movement» — горизонтальное перемещение.

Анализ защищённости веб-приложений

Углублённое сканирование сайта или интернет-сервиса на наличие SQL-инъекций, XSS (межсайтовый скриптинг), CSRF, утечек исходного кода, слабых механизмов аутентификации. Часто используется комбинация автоматических сканеров (Acunetix, Burp Suite) и ручного анализа.

Анализ защищённости мобильных приложений

Проверяется, можно ли извлечь из APK-файла ключи шифрования, логины, можно ли подменить трафик между приложением и сервером, нет ли уязвимостей в хранении данных на устройстве (например, пароли в открытом виде в SharedPreferences).

Анализ облачной инфраструктуры

Проверяются настройки безопасности в AWS, Google Cloud, Yandex Cloud, Azure: открытые S3-бакеты, избыточные права IAM, отсутствие логирования, публично доступные RDS-базы данных. Ошибки конфигурации в облаках — одна из главных головокружительных дыр.

Как проходит процесс: от разведки до отчёта

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

• Шаг 1. Согласование целей и границ. Заказчик и исполнитель договариваются, что именно проверяется: IP-адреса, веб-приложения, домены, мобильные приложения. Определяются правила взаимодействия и время проведения (обычно в ночные часы, чтобы не мешать бизнесу). Подписывается договор и NDA (соглашение о неразглашении данных).
• Шаг 2. Сбор информации (разведка). Специалисты собирают публичные данные о компании: DNS-записи, диапазоны IP, открытые порты, технологии на сайте, поддомены. Это пассивная разведка, без отправки запросов на цели.
• Шаг 3. Сканирование (автоматическое + ручное). Запускаются профессиональные сканеры уязвимостей (например, Nessus, Qualys, MaxPatrol VM). Они проверяют версии ПО, отсутствие патчей, слабые настройки. Параллельно инженеры проводят ручную проверку — особенно для веб-приложений, где автоматизация может пропустить логические уязвимости.
• Шаг 4. Верификация и устранение ложных срабатываний. Сканеры иногда ошибаются, выдавая уязвимости там, где их нет. Инженер вручную проверяет каждую критическую находку. Это важный этап, который отделяет качественный анализ от формальной «отписки».
• Шаг 5. Классификация и оценка рисков. Каждой уязвимости присваивается уровень опасности: критический, высокий, средний, низкий. Используется стандарт CVSS (Common Vulnerability Scoring System). Также указывается вектор атаки — как именно злоумышленник может применить эту дыру.
• Шаг 6. Подготовка отчёта. Отчёт содержит исполнительное резюме (для руководства), техническую часть (для администраторов IT), описание каждой уязвимости с доказательствами (скриншоты, выводы команд), рекомендации по устранению.
• Шаг 7. Повторная проверка после устранения. Самый важный шаг, который многие пропускают. После того как команда исправила уязвимости, нужно снова провести анализ, чтобы убедиться, что всё закрыто. Иначе работа теряет смысл.

Что показывает типичный отчёт: разбор на примере

Отчёт по анализу защищённости — это не просто сухой список CVE-номеров (идентификаторов известных уязвимостей). Хороший отчёт читается разными людьми и даёт ответ на главный вопрос: «Что делать?».

Типовое содержание:

• Исполнительное резюме (1–2 страницы). Для гендиректора и финансового директора. Коротко о том, сколько найдено критических и высоких уязвимостей, каковы потенциальные последствия (например, «возможно полное заражение сети шифровальщиком»), бюджет на устранение и сроки.
• Сводная таблица уязвимостей. Уровень, название CVE, сервис, на котором обнаружена, краткое описание. Сортировка от критических к низким.
• Детальное описание каждой критической уязвимости. С техническими деталями: как воспроизвести, какой софт уязвим, ссылки на бюллетени безопасности, готовые эксплойты (если есть).
• Рекомендации по устранению (playbook). Например: «обновить Apache до версии 2.4.57», «отключить неиспользуемый RDP-порт на фаерволе», «запретить SSLv3 в настройках NGINX».
• Приложение с логами сканера (для IT-специалистов). Можно импортировать в системы управления уязвимостями.

После отчёта самое главное — не положить его в стол, а выделить ресурсы на устранение. Часто компании заказывают ежегодный анализ, получают список из 300 уязвимостей и… ничего не делают, потому что «нет времени». Это путь к компрометации.

Автоматизированный анализ против ручного: почему нужны оба подхода

На рынке десятки инструментов для сканирования: Nessus, Rapid7, PT BlackBox, MaxPatrol, OpenVAS (бесплатный). Они крутые и быстрые. Но только автоматикой сыт не будешь.

Что умеет автоматическое сканирование:

• Быстро проверять тысячи портов и сервисов.
• Находить устаревшие версии ПО и «известные» CVE.
• Заметить открытые сетевые ресурсы (SMB, NFS, FTP).
• Работать в непрерывном режиме (каждую ночь).

Чего не умеет автоматика без ручного анализа:

• Находить логические уязвимости в веб-приложениях (например, можно редактировать чужой заказ, подставив ID) — это только руками.
• Оценивать последствия эксплуатации без реальной попытки взлома.
• Распознавать сложные связки уязвимостей — цепочку, где одна дыра помогает открыть другую.
• Проверять корректность настроек безопасности бизнес-логики (например, двухфакторную аутентификацию в админке).

Идеальный вариант: автоматическое сканирование запускается каждую неделю (ловит новые CVE), а раз в квартал — ручной анализ (углублённая проверка веб-приложений и сетевой архитектуры).

Частые ошибки и как сделать анализ защищённости по-настоящему полезным

Многие компании формально подходят к безопасности: заказали анализ, получили отчёт, «отмазались» перед регулятором. Но такая стратегия не работает. Вот что идёт не так.

• Ошибка 1. Сканирование раз в год «для галочки». За год появляются сотни новых уязвимостей; инфраструктура меняется. Анализ нужен как минимум раз в квартал, а для публичных сервисов — непрерывно (недельный цикл).
• Ошибка 2. Не сканировать всю инфраструктуру. Часто забывают про тестовые стенды, резервные серверы, забытые поддомены. А злоумышленник не забудет. Результат — дыра там, где не ждали.
• Ошибка 3. Не назначать ответственного за устранение. Кто-то конкретный должен взять на себя обязательство закрывать уязвимости в оговорённые сроки (например, критические — за 1 день, высокие — за неделю). Иначе так и будет «никто не знает, кто должен ставить этот патч».
• Ошибка 4. Игнорировать средние и низкие уязвимости. Цепочка из нескольких низких может превратиться в критическую. Хакеры любят комбинировать.
• Ошибка 5. Не проводить повторную проверку после исправлений. Легко ошибиться и не закрыть уязвимость полностью. Повторное сканирование стоит недорого (или входит в абонемент), но часто о нём забывают.

Как выбрать подрядчика для анализа защищённости

Компаний, предоставляющих услуги VA (vulnerability assessment), много. Но качество сильно отличается. Вот критерии, которые помогут не ошибиться.

• Лицензия ФСТЭК (для госорганов и объектов КИИ). Если вы работаете с государственной тайной или критической информационной инфраструктурой, исполнитель должен иметь лицензию на техническую защиту информации.
• Опыт в вашей отрасли. Анализ ИТ-инфраструктуры ритейлера отличается от проверки медицинской системы. Спросите кейсы, похожие на вашу компанию.
• Прозрачная методология. Подрядчик должен рассказать, какие сканеры использует, как проводит ручную верификацию, какие стандарты применяет (например, OWASP для веб-приложений, MITRE ATT&CK для тактик атак).
• Понятный отчёт с ранжированием рисков. Не техническая «портянка» нечитаемых логов, а структурированный документ с исполнительным резюме и конкретными шагами.
• Повторная проверка включена в стоимость. Настаивайте на том, чтобы отчёт включал одну бесплатную перепроверку после устранения уязвимостей.
• Отзывы без «воды». Попросите контакты 1-2 клиентов, чтобы поговорить лично. Реальные отзывы не всегда идеальны, но они честные.

Что дальше: план после отчёта

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

• День 1-2. Устранить критические уязвимости (обычно это открытые порты, известные эксплойты, отсутствие аутентификации). Если это невозможно быстро, закрыть на фаерволе доступ к уязвимому сервису.
• Неделя 1. Устранить высокие уязвимости: обновить критическое ПО, изменить слабые пароли на сервисных учётках, настроить бэкапы.
• Месяц 1. Закрыть средние и низкие уязвимости: плановое обновление всех систем, настройка правил безопасности, отключение неиспользуемых сервисов.
• Параллельно. Завести регламент «управления уязвимостями» — кто, как и в какие сроки фиксит найденное. Интегрировать сканирование в CI/CD (если речь о собственной разработке).
• Через 1-3 месяца. Провести повторный анализ защищённости, чтобы убедиться, что старые проблемы закрыты и не появились новые.

Анализ защищённости — это не страшилка и не галочка. Это регулярная гигиена цифровой инфраструктуры. Как чистка зубов у стоматолога: лучше делать планово и недорого, чем потом лечить в тридорого. Хакеры не дремлют, но и в ваших руках есть мощный инструмент — вовремя заметить дыру и закрыть её. Начните с одного аудита, составьте план исправлений и сделайте безопасность непрерывным процессом. Это дешевле, чем платить выкуп за расшифрованные данные или терять репутацию клиентов.