
Почему самоаудит вообще работает
Полноценный пентест — это отдельный бюджет, и он честно нужен там, где есть деньги, регулятор и реальный интерес атакующих: финтех, медицина, крупный e-commerce. Но большинство инцидентов в компаниях малого и среднего бизнеса случается не из-за хитрых zero-day. Они случаются из-за непатченного сервиса, повторно используемых паролей, открытого наружу RDP и бэкапа, который никто ни разу не пробовал восстановить.
Всё это проверяется своими силами за два-три дня. Я делал такой аудит у себя и у пары знакомых команд — и каждый раз находилось минимум три пункта из категории «как это вообще дожило до сегодняшнего дня».
Договоримся о правиле: самоаудит — не замена независимой проверке. Но он снимает «низко висящие фрукты» и стоит вам только времени. И ещё одно: чек-лист работает, только если по каждому пункту есть бинарный ответ «да/нет» и доказательство — скриншот, вывод команды, дата проверки. Всё остальное — самоуспокоение.

Шаг 1. Инвентаризация: без неё остальное бессмысленно
Вы не защитите то, о существовании чего не знаете. Поэтому первый шаг — список активов. Именно здесь чаще всего всплывает «теневое IT»: тестовый сервер, который подняли полтора года назад «на недельку», прод-копия клиентской базы на ноутбуке разработчика, корпоративный аккаунт в SaaS, оформленный на личную почту уволенного сотрудника.
- Серверы, VPS, облачные инстансы — с указанием владельца.
- Домены и поддомены, включая забытые staging и dev.
- Корпоративные SaaS-сервисы и список тех, у кого есть к ним доступ.
- Весь софт и его версии — собранные сканированием, а не по памяти.
- Ноутбуки, телефоны и «рабочие» личные устройства сотрудников.
Собрали список? Отметьте для каждого актива критичность: что случится, если он утечёт или встанет на сутки. Это пригодится дальше — приоритеты по патчам и бэкапам берутся именно отсюда, а не из головы.
Шаг 2. Учётные записи и права доступа
Самый урожайный блок. Идиотски звучит, но проверьте банальное: сколько людей в компании пользуются паролем, который уже светился в утечках. Готовые базы вида Have I Been Pwned и внутренние проверки по хэшам дают ответ за вечер.
Дальше — про права. Принцип наименьших привилегий на бумаге есть у всех, в жизни — у единиц. Практически всегда находится десяток учёток, у которых доступ шире, чем нужно для работы, и несколько «сервисных» аккаунтов, от которых уже полгода никто не помнит пароль.
- MFA включена на почте, VPN, админ-панелях и облаке — обязательно, без исключений для директоров.
- Привилегированные аккаунты отделены от повседневных: под рутом не работаем, под своим аккаунтом не админим.
- Аккаунты уволенных сотрудников блокируются в тот же день, а не «когда руки дойдут».
- Сервисные токены и API-ключи имеют срок жизни и владельца, а не лежат в бессрочке.
- Есть журнал, кто и когда выдавал доступ. Если нет — так и запишите.
Шаг 3. Патчи и уязвимости
Приоритеты расставляйте не по панике из новостей, а по двум вещам: есть ли уязвимость в каталоге эксплуатируемых (CISA KEV) и касается ли она вашего периметра. CVE с высоким CVSS, но требующая физического доступа к серверу, вам сегодня неинтересна. А вот дыра в открытом наружу VPN-шлюзе — очень.
Инфраструктурный минимум: настроенные автообновления безопасности на серверах и рабочих станциях, актуальные версии базовых образов, контроль зависимостей в CI. Про сканеры: OpenVAS/Greenbone и Lynis дают приличную картину по сети и хосту бесплатно, Trivy или Grype — по образам и зависимостям. Они не заменят ручного разбора, но за час покажут то, что вы пропускаете годами.
Отдельный пункт — SBOM. Если вы собираете софт, вы должны уметь за минуты ответить на вопрос «а у нас вообще используется библиотека X версии Y?». После громких историй с компрометацией сборок это уже не роскошь.
Шаг 4. Резервные копии: проверяем не наличие, а восстановление
Здесь я редко вижу команды без бэкапов. И почти никогда — команды, которые пробовали из них восстанавливаться. Копия, которую невозможно развернуть за разумное время, это не бэкап, а успокоительное.
- Правило 3-2-1: три копии, два типа носителей, одна — вне основной площадки.
- Хотя бы одна копия офлайн или в отдельном сегменте, до которого шифровальщик не дотянется.
- Пароль/ключ шифрования бэкапов хранится отдельно от самого хранилища.
- Проведён реальный тест восстановления с замером времени — и он запротоколирован.
- Понятно, кто отвечает за восстановление и по какому телефону его поднимать.
Шаг 5. Сеть и периметр
Задача — увидеть себя глазами снаружи. Тут работают Nmap и Shodan/FOFA: посмотрите, какие порты и сервисы реально смотрят в интернет. Регулярно обнаруживается лишнее — веб-админка базы, тестовый Jenkins, тот самый «временный» FTP.
Внутри сети ключевой вопрос — сегментация. Гостевой Wi-Fi не должен видеть прод-подсеть, бухгалтерия не должна напрямую ходить в базу клиентов. Если у вас одна плоская сеть на всё, это и есть главный подарок атакующему после первой же компрометации ноутбука.
И логи. Не просто «включены», а собираются в одно место, где их не потрёт локальный админ, и хранятся дольше месяца. Без журналов разбор инцидента превращается в гадание.
Шаг 6. Конечные точки и люди
Ноутбук сотрудника — самая вероятная точка входа, и одновременно самая забытая. Минимальный набор: шифрование диска, актуальный EDR или хотя бы нормальный антивирус с централизованной консолью, автоблокировка экрана, запрет локального админа «на всякий случай».
Люди — отдельный фронт. Запустите внутренний фишинг-тест: не чтобы наказать, а чтобы понять реальный процент тех, кто кликнет. И параллельно проверьте, не хранит ли кто-то секреты прямо в репозитории — trufflehog или gitleaks находят такое стабильно, включая токены, которые «удалили» из кода, но оставили в истории коммитов.
Шаг 7. Процессы и реагирование
Последний и самый недооценённый блок. Если завтра в три часа ночи упадёт что-то критичное — кто узнает первым, по какому каналу и что будет делать? Если ответ «ну, кто-нибудь заметит», то процесса нет.
Минимум, который стоит иметь: план реагирования на одной странице с ролями и телефонами, контакты внешнего подрядчика на случай, когда самим не хватит рук, и понятный порядок изоляции заражённого хоста без «а давай сначала посмотрим, что там».
Чек-лист на один экран
- Список активов собран и имеет владельцев и критичность.
- На ключевых сервисах включена MFA, права выданы по минимуму.
- Аккаунты уволенных закрыты, привилегированные отделены.
- Патчи безопасности ставятся автоматически, зависимости контролируются в CI.
- Бэкапы изолированы и хотя бы раз успешно восстановлены.
- Снаружи открыто только то, что нужно; сеть сегментирована.
- Логи централизованы и хранятся дольше месяца.
- На устройствах есть шифрование и централизованный антивирус/EDR.
- Проведён фишинг-тест, обучение по паролям и секретам в коде.
- Есть одностраничный план реагирования с ролями и контактами.
Вывод
Самоаудит не сделает из вас защищённую компанию, но снимет большую часть реалистичных рисков — тех, которые эксплуатируются не умением, а автоматическим сканером по всей сети интернет. Регулярность важнее глубины: раз в квартал пройти по этому списку с датами и доказательствами полезнее, чем один раз в год заказать красивый отчёт с восьмью красными «critical» и убрать его в папку.
И трезвая мысль напоследок: не гоняйтесь за модными решениями. Начните с того, что уже стоит у вас и настроено наполовину. Именно эти половинки дают 90% реальных инцидентов.