Зачем делать аудит своими руками, а не звать подрядчика
Внешний аудит ИБ в среднем проекте стоит от 300–500 тысяч рублей, а пентест — дороже, и к нему ещё нужно подготовить согласования, NDA и окно простоя. При этом львиная доля реальных проблем лежит на поверхности: забытые учётные записи уволившихся, панель администрирования, открытая в интернет, админы без второго фактора, секреты в репозитории, бэкапы, которые ни разу не восстанавливали.
Всё это находится без сканеров за миллион и без команды красных. Так что прежде чем выписывать счёт на внешний аудит — пройдите базовый цикл сами. Он не даст юридически значимого заключения и не заменит пентест, но закрывает тот уровень, с которого начинается большинство инцидентов. Ниже — десять шагов, которые sysadmin или DevOps может пройти за две-три недели, не отрываясь от текучки.
Шаг 1. Составьте карту активов
Без инвентаризации аудит превращается в блуждание по тёмной комнате. Выпишите всё, что у вас есть, даже если кажется, что вы и так это знаете.
- внешние сервисы и поддомены, включая забытые тестовые стенды;
- серверы, VPS, облачные инстансы и их владельцев;
- базы данных и бэкапы к ним;
- домашние и удалённые рабочие места сотрудников;
- подрядчики и интеграции со сторонним доступом.
Сверить список удобно по журналам обратного прокси и по DNS-зоне: почти всегда там всплывает что-то, о чём команда забыла.
Шаг 2. Проверьте доступы и права
Самый частый подарок злоумышленнику — избыточные права и мёртвые учётки. Начните с простого: выгрузите список пользователей во всех системах и сопоставьте с актуальным штатом и подрядчиками. Всё, что не привязано к живому человеку, — на удаление.
- у каждого ли администратора персональная учётка или есть общий root/admin;
- кто имеет доступ к продовой инфраструктуре и базе клиентов;
- остались ли аккаунты уволенных и стажёров;
- включён ли принцип минимальных привилегий.
Шаг 3. Наведите порядок в аутентификации
Парольная политика без второго фактора — это вчерашний день. Проверьте, что 2FA включён хотя бы там, где есть доступ к деньгам, данным и инфраструктуре: почта, VPN, панели облаков, Git, админки БД. Инженерную часть вопроса разбирает OWASP, но на практике вам достаточно ответить на вопрос: сможет ли сотрудник зайти в прод, зная только пароль.
Отдельно посмотрите на пароли в открытом виде: конфиги, скрипты деплоя, wiki. Всё, что найдёте, — не в файлы, а в менеджер секретов.
Шаг 4. Просканируйте внешний периметр
Соберите то, что видно снаружи. Открытые порты, панели управления, забытые файлы. Для инвентаризации подойдут массовые сканеры вроде nmap, но помните: сканировать чужие системы без разрешения нельзя, а свои — только с согласования владельца инфраструктуры и в письменном виде.
- не торчат ли наружу SSH, RDP, БД;
- нет ли доступа к админкам из интернета без VPN;
- не открыты ли бэкапы и каталоги с листингом.
Шаг 5. Проверьте уязвимости и версии
Здесь не нужно геройствовать с эксплойтами — достаточно сверить версии компонентов с официальными бюллетенями. Полезные источники: база БДУ ФСТЭК России и международная NVD. Составьте список того, что обновляется, и того, что давно застыло на мёртвой версии.
Особое внимание — заброшенным библиотекам и патчам, которые «вот-вот поставим уже полгода». Именно здесь живёт основная масса эксплуатируемых уязвимостей.
Шаг 6. Пройдитесь по зависимостям и CI/CD
Атакуют не только серверы, но и цепочку поставки. Проверьте:
- подключены ли сканеры зависимостей в пайплайне (Dependabot, Trivy, OWASP Dependency-Check);
- есть ли посторонние в правах на репозитории и пайплайны;
- не хранятся ли токены и ключи в переменных сборки в открытом виде;
- кто может пушить в прод напрямую, минуя ревью.
Шаг 7. Оцените работу с секретами
Простая проверка: возьмите историю коммитов и поищите ключи, пароли, токены. Даже если вы их удалили из текущего файла, в истории они остались. Всё найденное считается скомпрометированным и подлежит ротации, а не просто удалению.
Дальше — переезд секретов в специализированное хранилище (Vault, SOPS, менеджер секретов облака). Ручное копирование .env по серверам — прямой путь к утечке.
Шаг 8. Проверьте бэкапы и восстановление
Бэкап — это не факт наличия архива, а факт успешного восстановления. Убедитесь, что:
- копии хранятся отдельно от основной инфраструктуры;
- доступ к ним не сводится к тому же паролю, что и к прод;
- вы хотя бы раз в квартал разворачивали данные из бэкапа на тестовом стенде;
- есть копия вне площадки — на случай шифровальщика.
Шаг 9. Посмотрите на логирование и мониторинг
Инцидент, о котором вы узнаёте из звонка клиента, — это провал обнаружения. Проверьте, что логи собираются централизованно, хранятся достаточное время и по ним реально кто-то смотрит. Минимальный набор алертов: массовые неудачные входы, вход админов с новых адресов, изменения в правах, всплеск трафика на выгрузку данных.
Шаг 10. Оформите отчёт и план исправлений
Аудит без документа — это разговор, который забудется через неделю. Сведите находки в таблицу: что нашли, критичность, кто владелец, срок. Разделите на три группы: закрыть в течение недели, в течение месяца, в течение квартала. Это и будет ваша дорожная карта.
Итоговый чек-лист
- Инвентаризация активов и поддоменов.
- Ревизия учётных записей и прав доступа.
- Включение 2FA на критичных сервисах.
- Сканирование внешнего периметра.
- Сверка версий с бюллетенями уязвимостей.
- Проверка зависимостей и безопасности CI/CD.
- Вынос секретов из кода в хранилище.
- Тест восстановления из бэкапа.
- Настройка логирования и алертов.
- Отчёт с приоритетами и сроками.
Вместо вывода
Внутренний аудит не отменяет внешний — он делает его дешевле и осмысленнее. Когда вы уже знаете свою инфраструктуру, подрядчику остаётся искать действительно сложные вещи, а не показывать вам забытую админку за ваш же счёт. Главное правило простое: нашли проблему — не откладывайте в бесконечный бэклог, а закрывайте. Отсутствие процесса исправления убивает больше проектов, чем самые изощрённые атаки.
