Пентест «под ключ» от вменяемой команды стоит от нескольких сотен тысяч рублей и занимает недели. Но большинство реальных инцидентов случается не из-за хитрых 0-day, а из-за забытого тестового стенда с дефолтным паролем, секретов в git и бэкапа, лежащего в публичном бакете. Всё это находится своими руками за один-два дня — без лицензии ФСТЭК, сканера за миллион и красивых презентаций.
Ниже — 15 проверок, которые я прогоняю по своему контуру и по инфраструктуре клиентов, когда нужно быстро понять, где мы стоим. Это не замена полноценному аудиту и не пентест. Это гигиена: дешёвая, быстрая и отсекающая основную массу низковисящего риска, до которого добираются атакующие.
Правила игры: как не сломать прод
Экспресс-аудит — это всё равно активные действия. Прежде чем что-то проверять, зафиксируйте рамки:
- Письменное разрешение от владельца системы. Без него вы не аудитор, а нарушитель.
- Окно работ и запретные зоны: не трогаем то, что не выдержит перезагрузки (АСУ ТП, медоборудование, кассы).
- Уведомление дежурной смены и команды мониторинга, иначе ваши проверки уедут в тикеты как атака.
- Минимум агрессивности: никаких брутфорсов и попыток эксплуатации найденного. Нашли — зафиксировали, починили.
Дальше — сами проверки. Разбил их на три блока: периметр, данные и процессы.
Блок 1. Периметр и доступы
1. Инвентаризация: что у вас вообще есть
Самая скучная и самая результативная проверка. Возьмите список IP и доменов из биллинга, ARP-таблиц, DHCP-leases, выгрузок из облака и CMDB — и сойдите их между собой. Обычно 10–20% активов не числятся нигде: старый портал, стенд после уволившегося сотрудника, забытая админка на нестандартном порту.
Критерий прохождения: актуальный реестр активов с владельцем, назначением и уровнем критичности по каждому хосту.
2. Что торчит наружу
Соберите все адреса, которые резолвятся в интернет, и проверьте открытые порты. Тут работают и внешние сервисы вроде Shodan или Censys — они уже просканировали вас за вас, — и обычный сканер портов по согласованному диапазону.
Красный флаг — RDP, SSH, базы данных и панели управления (Zabbix, Grafana, ESXi, Jenkins), доступные напрямую из интернета. Такие вещи должны жить за VPN или как минимум за жёстким контролем доступа.
3. MFA на всех точках входа
Проверяйте не наличие MFA «в целом», а покрытие. Составьте таблицу: VPN, почта, админки облаков, CI/CD, бастион, панель хостинга, корпоративные SaaS. По опыту, MFA включена везде, кроме двух-трёх сервисов — и именно они потом становятся входной точкой.
Отдельно проверьте, что MFA нельзя обойти через устаревшую почтовую аутентификацию (IMAP/SMTP без OAuth) и что резервные коды не лежат в общем чате.
4. Дефолтные и бесхозные учётки
Ищите аккаунты, про которые «никто не знает, зачем они». Сервисные учётки без владельца, admin/admin на железках, тестовые пользователи с паролем вида qwerty, оставшиеся после интеграции. Проверьте срок действия паролей у привилегированных аккаунтов и наличие среди них бывших сотрудников.
Отдельная категория — встроенные учётки вендоров и «техподдержка». Убедитесь, что они либо отключены, либо под контролем, а не включаются по звонку.
5. Актуальность версий на периметре
Соберите версии всего, что смотрит в интернет: веб-серверы, балансировщики, VPN-шлюзы, CMS, фреймворки. Сверьте с бюллетенями вендоров и базой CVE. Особое внимание — устройствам, которые годами не обновлялись: у них обычно накопился целый букет критичных уязвимостей.
Заведите правило: любой актив на периметре имеет понятный процесс обновления и ответственного. Если прошивку негде взять — это отдельный риск, который надо осознанно принять и задокументировать.
Блок 2. Данные и конфигурации
6. Секреты в репозиториях и CI
Прогоните историю коммитов и текущее состояние репозиториев на предмет ключей, токенов, строк подключения и приватных сертификатов. Даже если секрет удалили год назад — он остался в истории git и, скорее всего, уже в чьей-то коллекции.
Результат проверки: все секреты вынесены в секрет-менеджер (Vault, облачный KMS, защищённые переменные CI), а найденные — отозваны и перевыпущены, а не просто удалены из файла.
7. Бэкапы: есть — и доступны ли они
Классика: копии делаются, но никто не проверял восстановление. Проверьте три вещи — регулярность, изоляцию и восстановление.
- Изоляция: может ли рядовой админ или скомпрометированный сервисный аккаунт удалить бэкапы? Если да — это не бэкап, а приманка для шифровальщика.
- Тест восстановления: разверните из копии реальный сервис на отдельном стенде и замерьте время. RTO в презентации и RTO по факту обычно расходятся в разы.
- Логи: убедитесь, что запись бэкапов идёт в отдельное хранилище, к которому нет доступа из основной сети.
8. Шифрование на дисках и в каналах
Проверьте, где лежат персональные данные и коммерческая тайна: на серверах с шифрованием диска или на ноутбуке менеджера без него? Внутренний трафик с ПДн тоже должен быть защищён — как минимум TLS, а не голый HTTP внутри периметра.
Подсказка по требованиям: если система обрабатывает персональные данные, ориентируйтесь на Приказ ФСТЭК №21 и 152-ФЗ; для государственных информационных систем — на Приказ №17; для финансовых организаций — на ГОСТ Р 57580. Это не бюрократия, а готовый перечень того, что спросят при проверке.
9. Права доступа и минимальные привилегии
Выгрузите список пользователей и групп по ключевым системам и ответьте на вопрос: кому это действительно нужно? Типичные находки: у половины разработчиков доступ к прод-базе через общий аккаунт, у стажёра — права администратора, у подрядчика — доступ ко всей сети, хотя нужен один сервис.
Проверьте также, что доступ отзывается автоматически при увольнении или переводе, а не «когда вспомним».
10. Логи и мониторинг
Проверка звучит так: если завтра в три часа ночи кто-то войдёт в систему с нетипичного IP, вы об этом узнаете? Для ответа нужно проверить три вещи:
- Аутентификация и действия админов логируются в централизованное хранилище, которое нельзя тихо подчистить с самого сервера.
- Есть алерты на подозрительное: перебор паролей, вход из нового региона, создание привилегированного пользователя, изменение правил firewall.
- Кто-то реально читает эти алерты. SIEM без дежурного — это дорогой архив.
Блок 3. Люди, процессы и восстановление
11. Патч-менеджмент зависимостей
Supply chain — сейчас один из самых горячих векторов. Прогоните манифесты проекта сканером уязвимостей зависимостей (например, встроенным в CI) и посмотрите на объём критичных находок. Дальше — вопрос процесса: кто и как часто обновляет библиотеки и есть ли у вас SBOM, чтобы за час понять, затронул ли вас очередной инцидент с популярным пакетом.
12. Фишинг и осведомлённость
Отправьте согласованную тестовую рассылку (или прогоните сотрудников через короткий тренинг) и посмотрите на процент кликов и, что важнее, на процент тех, кто сообщил о подозрительном письме. Вторая метрика важнее первой: она показывает, работает ли канал эскалации.
Заодно проверьте, отключена ли макрос-автоматика в офисе и включена ли защита от вложений на почтовом шлюзе.
13. Изолированность админской сети
Посмотрите, можно ли с рабочей станции бухгалтера дойти до интерфейса управления гипервизором. Если да — весь периметр бесполезен, потому что путь вглубь открыт. Зоны управления, прода и пользовательские сегменты должны быть разделены, с явными правилами и без «временного» разрешения вида any-any, которое живёт уже второй год.
14. Внешние подрядчики и удалённый доступ
Соберите список всех, у кого есть доступ к инфраструктуре: сопровождение 1С, бухгалтерия, вендор касс, внешние разработчики. По каждому: зачем, что именно видит, куда ходит и когда доступ отзывается. Идеал — прыжковый сервер с записью сессии и персональными учётками вместо общей «подрядчик». Практика — общий пароль в мессенджере. Ищите разницу между этими двумя состояниями и закрывайте её.
15. Готовность к инциденту
Финальная проверка — «сухой прогон». Возьмите один правдоподобный сценарий (утечка базы, шифровальщик на файловом сервере, компрометация облака) и пройдите по шагам: кто замечает, кому звонит, какие есть права на изоляцию, откуда восстанавливаемся, кого уведомляем по закону. Если на это уходит больше получаса согласований — плана нет, есть только надежда.
Минимум: актуальные контакты, зафиксированные роли, отпечатанная на бумаге инструкция на случай, когда недоступны корпоративные сервисы, и договор с внешней командой, если своих рук не хватит.
Как оформить результат
Не превращайте отчёт в простыню. По каждой из 15 проверок поставьте три вещи: статус (пройдено, частично, провал), конкретное доказательство и одну строку «что делать». Дальше расставьте приоритеты:
- Критично: прямой доступ к данным или управление из интернета, отсутствие рабочих бэкапов, отсутствие MFA на админках.
- Высоко: устаревшие версии на периметре, секреты в репозитории, отсутствие централизованных логов.
- Средне: избыточные права, слабая сегментация, отсутствие обучения сотрудников.
- Низко: улучшения и «хотелки», которые можно закрыть в порядке планового рефакторинга.
И главное — назначьте владельца и срок на каждый пункт. Аудит без плана работ — это просто способ понервничать.
Короткий чек-лист на один день
- Сверил реестр активов с реальностью.
- Проверил открытые в интернет порты.
- Убедился, что MFA включена на всех админках и VPN.
- Нашёл и закрыл бесхозные и дефолтные учётки.
- Сверил версии периметра с бюллетенями и CVE.
- Прогнал репозитории на секреты и отозвал найденное.
- Проверил изоляцию бэкапов и реально восстановился из копии.
- Проверил шифрование дисков и внутреннего трафика.
- Выгрузил и пересмотрел права привилегированных пользователей.
- Убедился, что логи уходят в защищённое хранилище и по ним есть алерты.
- Обновил критичные зависимости и начал вести SBOM.
- Провёл тренировку по фишингу и поправил почтовые настройки.
- Разделил админскую и пользовательскую сети.
- Ревизовал доступы подрядчиков и заменил общие учётки на персональные.
- Прогнал сценарий инцидента и проверил, что план работает.
Ни одна из этих проверок не требует бюджета на лицензии — только время и дисциплину. Если после экспресс-аудита закрылись первые десять пунктов, вы уже убрали большую часть риска, за которым охотятся реальные атакующие. Остальное — задача полноценного пентеста и регулярного цикла: то, что прошло сегодня, через полгода снова протухнет.
