Как проверить информационную защиту своими силами: чек-лист аудита

Почему самоаудит вообще работает

Полноценный пентест — это отдельный бюджет, и он честно нужен там, где есть деньги, регулятор и реальный интерес атакующих: финтех, медицина, крупный 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. Процессы и реагирование

Последний и самый недооценённый блок. Если завтра в три часа ночи упадёт что-то критичное — кто узнает первым, по какому каналу и что будет делать? Если ответ «ну, кто-нибудь заметит», то процесса нет.

Минимум, который стоит иметь: план реагирования на одной странице с ролями и телефонами, контакты внешнего подрядчика на случай, когда самим не хватит рук, и понятный порядок изоляции заражённого хоста без «а давай сначала посмотрим, что там».

Чек-лист на один экран

  1. Список активов собран и имеет владельцев и критичность.
  2. На ключевых сервисах включена MFA, права выданы по минимуму.
  3. Аккаунты уволенных закрыты, привилегированные отделены.
  4. Патчи безопасности ставятся автоматически, зависимости контролируются в CI.
  5. Бэкапы изолированы и хотя бы раз успешно восстановлены.
  6. Снаружи открыто только то, что нужно; сеть сегментирована.
  7. Логи централизованы и хранятся дольше месяца.
  8. На устройствах есть шифрование и централизованный антивирус/EDR.
  9. Проведён фишинг-тест, обучение по паролям и секретам в коде.
  10. Есть одностраничный план реагирования с ролями и контактами.

Вывод

Самоаудит не сделает из вас защищённую компанию, но снимет большую часть реалистичных рисков — тех, которые эксплуатируются не умением, а автоматическим сканером по всей сети интернет. Регулярность важнее глубины: раз в квартал пройти по этому списку с датами и доказательствами полезнее, чем один раз в год заказать красивый отчёт с восьмью красными «critical» и убрать его в папку.

И трезвая мысль напоследок: не гоняйтесь за модными решениями. Начните с того, что уже стоит у вас и настроено наполовину. Именно эти половинки дают 90% реальных инцидентов.

guest

0 Комментарий