Зачем нужен аудит, если «и так всё работает»
Пока ничего не сломалось, защита кажется достаточной. Проблема в другом: вы не видите, где именно она уже не работает. Аудит нужен не для галочки перед проверкой, а чтобы найти слепые зоны раньше, чем их найдёт кто-то с другой стороны.
Формата два. Внешний — приходят подрядчики, тестируют, дают независимую оценку. Внутренний — вы сами проходите по чек-листу и фиксируете факты. Первый стоит денег и даёт свежий взгляд, второй можно начать на этой неделе. Даже беглый внутренний аудит обычно закрывает большую часть очевидных дыр за пару дней.
Ниже — маршрут, по которому я иду на практике. Порядок не случайный: сначала границы, потом активы, потом доступы, и только затем технические средства. Любимая ошибка — начать с покупки SIEM. SIEM без порядка в активах честно собирает шум и жрёт бюджет.
Шаг 1. Границы и инвентаризация активов
Аудит начинается с вопроса: а что именно мы защищаем? Без ответа все дальнейшие шаги превращаются в разговор о вкусах.
- Составьте список серверов, ВМ, сетевых устройств, рабочих станций, мобильных устройств (MDM) и облачных сервисов.
- Отдельно выпишите внешние сервисы: сайт, API, VPN, почта, файловые шары, панели администрирования.
- Пометьте, где живут персональные данные (152-ФЗ), платёжная информация, исходный код и ключи.
Если инвентаризация держится в голове или в чьей-то таблице на рабочем столе — это уже находка. Активы должны быть в системе учёта (CMDB, NetBox, пусть даже аккуратный CSV в git), а не «у Васи спроси».
Шаг 2. Учётные записи и права доступа
Здесь чаще всего и живут реальные проблемы. Проверяем:
- Уволенные сотрудники: их учётки, VPN-сертификаты, токены в CI-CD действительно отключены?
- Сервисные аккаунты: где они, кому известны пароли, нет ли общей «технической» учётки на всех?
- Принцип наименьших привилегий: сколько людей имеют локального админа на своём ноуте «на всякий случай»?
- Многофакторная аутентификация (MFA) на VPN, почте, админ-панелях, облаке, репозиториях кода.
Обязательные сервисные учётки стоит увести в менеджер секретов с разграничением доступа и ротацией, а привилегированные — в PAM-решение с записью сессий. Особое внимание — аккаунтам в облаке и на CI/CD: утёкший токен деплоя обходится дороже забытого пароля.
Шаг 3. Обновления и управление уязвимостями
Проверьте не «есть ли у нас сканер», а реальный цикл: от появления информации об уязвимости до установки патча. Практические вопросы:
- Кто отвечает за ежемесячный просмотр бюллетеней вендоров и БДУ ФСТЭК?
- Сколько времени проходит от публикации CVE до закрытия на прод-системах?
- Есть ли отдельный регламент для критических уязвимостей, эксплуатируемых «в дикой природе» (kev), — их надо закрывать в течение дней, а не квартала.
Хорошая привычка: раз в месяц сверять список установленного софта с данными NVD и внутренним сканером. И помните — сканер показывает только то, что умеет распознать; устаревшее и кастомное ПО он нередко пропускает.
Шаг 4. Сеть и сегментация
Смотрите на сеть глазами человека, который уже внутри. Сколько можно пройти, получив одну рабочую машину?
- Разделены ли офисная сеть, серверный сегмент, гостевой Wi-Fi и управляющие интерфейсы?
- Есть ли правила firewall на внутреннем контуре или по умолчанию открыто всё?
- Как устроен доступ снаружи: VPN с MFA или проброшенный RDP «на всякий случай»?
Сегментация — один из немногих инструментов, который стоит копейки и реально тормозит распространение атаки. Плоский L2-домен на весь офис — это подарок для шифровальщика, а не удобство.
Шаг 5. Конечные точки
Рабочие станции — самая массовая точка входа. Проверьте, что на них есть EDR/антивирус с централизованным управлением, включено шифрование диска, блокируется съёмное ПО по политике, а права локального админа выданы не всем.
Тут же — управление обновлениями ОС и браузеров. Заброшенный парк Windows или устаревшие версии офисных пакетов и PDF-ридеров закрывают много вопросов на чужой стороне.
Шаг 6. Резервные копии
Главный тест — не «есть ли бэкапы», а «пробовали ли вы из них восстанавливаться». Проведите учебное восстановление на отдельной площадке, с фиксацией времени (RTO) и полноты данных (RPO).
- Копии хранятся офлайн или в неизменяемом (immutable/air-gapped) хранилище?
- Есть ли отдельные учётки для доступа к бэкапу, не связанные с доменом?
- Кто имеет право удалять и перезаписывать резервные копии?
Шифровальщики в первую очередь ищут и уничтожают именно бэкапы, поэтому «всё в одном NAS под той же админ-учёткой» — классический сценарий разом потерять и данные, и копии.
Шаг 7. Логи и мониторинг
Без логов инцидент невозможно разобрать, а без мониторинга — вовремя заметить. Проверьте:
- Собираются ли логи с серверов, DNS, VPN, firewall, облака и хранятся ли они отдельно от своих источников?
- Настроены ли алерты на что-то кроме «диск заполнен»: массовое неуспешное логинирование, повышение привилегий, доступ к чувствительным данным?
- Настроена ли синхронизация времени (NTP)? Без неё корреляция событий превращается в гадание.
Сначала — минимальный набор из 10–15 понятных правил, а не «полный SIEM с сотней корреляций по умолчанию». Дежурный должен успевать реагировать.
Шаг 8. Секреты и цепочка поставок
Пройдитесь по репозиториям и конфигам: не лежат ли пароли, API-ключи и токены в открытом виде в git, в .env или в CI-переменных? Для разработчиков освежите правила из OWASP Top 10 — там есть отдельные категории про секреты и целостность цепочки поставок.
- Секреты хранятся в vault/secret manager, а не в коде и не в чатах.
- Зависимости фиксируются по хэшам, есть аудит на уязвимости в сторонних библиотеках.
- Разграничены права в CI/CD: сборка и деплой используют разные, ограниченные токены.
Шаг 9. Люди и процессы
Техника без процессов не работает. Проверьте, есть ли регулярные учебные фишинговые рассылки, понятный порядок сообщения об инциденте, онбординг и офбординг с чек-листом по доступам. Самое слабое звено по-прежнему человек — и не потому, что он глупый, а потому что никто не объяснил ему правила.
Шаг 10. Регуляторика
Если вы оператор персональных данных, рамку задаёт 152-ФЗ и приказы ФСТЭК № 17 и № 21. Проверьте, что модель угроз и уровень защищённости определены, а организационные документы существуют не только на словах. Для значимых объектов и отдельных отраслей добавляются требования ФСБ и отраслевых регуляторов. Речь не о том, чтобы «сделать красиво», а о том, что эти же требования совпадают с реальной защитой чаще, чем кажется.
Как оформить результат
Находки фиксируйте не списком «плохо/хорошо», а в виде рисков: что именно случится, с какой вероятностью и что потеряем. Простая матрица «вероятность × ущерб» помогает расставить приоритеты и объяснить руководству, почему патч-менеджмент важнее нового монитора для переговорки.
Дальше — план с владельцами и сроками. Аудит без назначенных ответственных остаётся документом, а не улучшением.
Итоговый чек-лист
- Инвентаризация активов и данных — проведена и поддерживается.
- Учётные записи и права приведены в порядок, MFA включена на критичных сервисах.
- Патчи и уязвимости закрываются по регламенту, критические — вне очереди.
- Сеть сегментирована, снаружи только VPN с MFA.
- Конечные точки под управлением EDR, диски зашифрованы.
- Резервные копии изолированы, восстановление протестировано.
- Логи собираются отдельно, алерты настроены и кто-то их читает.
- Секреты — в хранилище, доступы в CI/CD ограничены.
- Есть обучение и порядок действий при инциденте.
- Требования 152-ФЗ и ФСТЭК/ФСБ закрыты документально и фактически.
Не гонитесь за закрытием всего списка за неделю. Возьмите три самых болезненных пункта, закройте их, запишите результат — и вернитесь через месяц. Систематичность здесь работает лучше, чем разовый героический рывок перед проверкой.
