Помните типовую сцену: приезжают консультанты из компании с громким именем, две недели ходят по офису, задают вопросы из методички, а потом выкатывают PDF на 120 страниц, где 110 — это «общие рекомендации» и приложение с копипастой ГОСТа. Дальше документ пылится на вики, а через год приходит новый аудит — с тем же результатом. Знакомо?
Я не против внешних аудиторов: для формальных требований регуляторов они нужны. Но базовую гигиену безопасности ваша команда способна проверить сама — за пару дней и без бюджета. Ниже рабочий чек-лист, по которому я гоняю собственные проекты и инфраструктуру клиентов. Берите и адаптируйте под себя.
Чем аудит ИБ отличается от пентеста
Прежде чем бежать, договоримся о терминах — на собеседованиях и в ТЗ их любят смешивать.
- Пентест — активная проверка «на пробиваемость»: ищете, можно ли попасть внутрь через конкретные дыры прямо сейчас.
- Аудит ИБ — системная проверка: есть ли политики, настроены ли средства защиты, не разъехалась ли реальность с документами.
- Compliance-проверка — частный случай аудита под требования конкретного регулятора (ФСТЭК, 152-ФЗ, PCI DSS).
Аудит отвечает на вопрос «что у нас настроено и где дыры в процессах», пентест — «можно ли этой дырой воспользоваться». Логичный порядок: сначала аудит, потом точечный пентест самых критичных контуров.
Шаг 0: скоуп и реестр активов
Самый частый провал — команда начинает проверять «всё подряд» и через час тонет в хаосе. Не надо так. Начните с инвентаризации: это фундамент, без которого аудит превращается в гадание.
- Составьте список всех систем: серверы, базы данных, приложения, API, VPN, облачные аккаунты.
- Пометьте критичность: что упадёт — бизнес встанет, а что может потерпеть до утра.
- Определите границы: что входит в проверку сейчас, а что осознанно отложили.
Если реестра активов нет вообще — это уже первая находка аудита. Храните его в git, таблице или CMDB — неважно где, важно чтобы он был живым, а не «нарисовали в 2019-м и забыли».
Пять зон, которые проверяем
Не пытайтесь объять необъятное за один вечер. Разбейте работу на пять дней — по одной зоне в день — и фиксируйте находки в одном месте: таблице или issue-трекере.
1. Доступы и учётки
По данным Verizon DBIR, примерно три четверти утечек так или иначе связаны с человеческим фактором — чаще всего с украденными или «забытыми» учётками. С них и начинаем.
- Сверьте активных пользователей в AD/IdP со списком сотрудников от HR. Аккаунты уволенных и ушедших стажёров — классика жанра.
- Посчитайте привилегированные учётки (domain admin, root, sudo). Идеал — единицы, а не «половина отдела с админ-правами, потому что так удобнее».
- Проверьте MFA: он должен быть на почте, VPN и всех админках. Отсутствие MFA — это не «риск», это открытая дверь.
- Найдите общие и сервисные аккаунты: на кого оформлены, когда менялся пароль.
Быстрый тест: запросите у HR список уволенных за полгода и поищите их логины в системе. Нашли активные? Внесите в план первоочередных действий.
2. Обновления и зависимости
Атаки на цепочку поставок — не абстракция из новостей: Log4Shell (CVE-2021-44228) до сих пор находят в продакшене спустя годы после выхода фикса. Проверка обновлений скучная, но именно здесь живут самые «громкие» дыры.
- Составьте реестр ОС и middleware: что работает на версиях с закончившейся поддержкой?
- Проверьте зависимости приложений: npm audit, pip-audit или аналоги под ваш стек. Сотни known vulnerabilities в зависимостях — уже сигнал.
- Есть ли регламент обновлений и окно для них? Или патчи ставятся «когда-нибудь в пятницу вечером»?
Совет из практики: не гонитесь за нулём уязвимостей — это недостижимо. Гонитесь за тем, чтобы критические CVE закрывались за 7–14 дней, а остальное — по регулярному графику.
3. Секреты и конфигурации
Загляните в git-репозитории. Если найдёте .env с паролями или ключи от облака в публичном репо — это не «находка», а инцидент, который уже произошёл. Такое не чинят, а ротируют.
- Просканируйте репозитории утилитами вроде gitleaks или trufflehog — они ловят случайно закоммиченные секреты.
- Проверьте, где хранятся секреты в проде: в env-файлах и коде или в секрет-менеджере (Vault, AWS Secrets Manager, аналог)?
- Посмотрите дефолтные конфиги: не остались ли admin/admin на базах, Redis или панелях управления.
Важный нюанс: если секрет попал в историю git, простого удаления из файла мало — нужна полная ротация. История никуда не денется.
4. Сеть и периметр
- Просканируйте внешний периметр: какие порты торчат наружу и зачем они там?
- Проверьте сегментацию: может ли разработчик из внутренней сети достучаться до продакшен-базы напрямую?
- Разберите правила firewall: не висят ли там allow all с пометкой «временно, потом почистим» образца 2018 года.
- Если есть веб-приложения — что закрывает их от типовых атак по OWASP Top 10?
5. Логи и мониторинг
Есть старая шутка: утечку в среднем обнаруживают спустя месяцы, потому что никто не смотрит в логи. Преувеличение, но с горькой правдой внутри. Проверьте, что у вас вообще логируется.
- Собираются ли логи аутентификации, VPN, межсетевых экранов?
- Есть ли централизованный сбор (SIEM или хотя бы ELK) или логи живут на каждом сервере и умирают вместе с ним?
- Настроены ли алерты на аномалии: массовый вход, логин из другой страны в 4 утра?
- Как долго хранятся логи — хватит ли этого для расследования инцидента?
6. Резервные копии и восстановление
Аудит безопасности, в котором не проверяют бэкапы, — фикция. Вопрос не «есть ли копии», а «сможем ли мы восстановиться». Шифровальщики бьют ровно туда, где бэкапов нет или они лежат рядом с продакшеном.
- Есть ли копии по схеме 3-2-1: три копии, два носителя, одна офлайн или в другом месте?
- Когда последний раз реально тестировали восстановление? «Настроили когда-то и забыли» не считается.
- Защищены ли бэкапы от случайного или злонамеренного удаления (immutable)?
Проверка на практике: возьмите тестовую машину, поднимите её из бэкапа и засеките время. Если за час не подняли — план восстановления нужно переписывать.
7. Люди и процессы
Идеально настроенная техника разваливается, если доступы выдаёт «админ Вася по заявке в чате», а онбординг и офбординг нигде не описаны.
- Есть ли процесс онбординга и офбординга: кто выдаёт и отзывает доступы и в какие сроки?
- Проводится ли обучение по фишингу и социальной инженерии, или «и так все знают»?
- Описан ли хоть короткий runbook действий при инциденте? Кто принимает решение об отключении системы?
Как разбирать находки без паники
После аудита у вас будет список из 30–100 пунктов. Помечать всё «критично» — путь к параличу: команда увидит сто критичных задач и не сделает ни одной. Работает риск-подход.
- Оцените каждую находку по шкале «вероятность × ущерб».
- Помните: CVSS — лишь подсказка. Уязвимость с баллом 9.9 в системе без внешнего доступа может быть менее срочной, чем «средний» CVE на внешнем периметре.
- Разбейте список на три кучи: чинить на этой неделе, чинить в квартале, отложить в долгосрочный бэклог.
И не пытайтесь закрыть всё в одиночку: половину пунктов делегируйте командам — владельцам систем. Аудит лишь показывает, кому и что делать.
План после аудита: 30/60/90 дней
Аудит без плана исправлений — это те самые 120 страниц PDF, которые пылятся на вики. Зафиксируйте результаты, назначьте сроки и ответственного.
- 30 дней: ротация скомпрометированных секретов, отключение мёртвых учёток, закрытие критических CVE, включение MFA.
- 60 дней: сегментация сети, централизованные логи и базовые алерты, тест восстановления из бэкапа.
- 90 дней: политики и runbook, обучение команды, повторная быстрая проверка снаружи.
Без назначенного владельца любая задача из списка «сама собой» не сделается — проверено не раз.
Итог: шпаргалка на один день
Если времени совсем нет, пробегитесь хотя бы по этому минимуму — он ловит 80% типовых проблем:
- Сверить активные учётки со списком сотрудников и найти привилегированные.
- Проверить MFA на почте, VPN и админках.
- Просканировать репозитории на случайные секреты.
- Закрыть внешние порты, которые не используются.
- Убедиться, что логи аутентификации куда-то пишутся.
- Поднять тестовую машину из бэкапа и засечь время.
Аудит — это не разовое мероприятие «для галочки перед проверкой регулятора», а регулярная гигиена. Раз в квартал — быстрый прогон чек-листа, раз в год — глубокая проверка с привлечением внешних, если есть бюджет и требования. Так вы будете знать, что у вас внутри. А это уже больше, чем у половины рынка.
