Семь дней на аудит информационной защиты — это не про сертификат и не про отчёт на 80 страниц, который никто не прочитает. Это про то, чтобы за неделю понять, где у вас реально болит, и выйти с планом, который не стыдно показать директору. Я проходил такой спринт трижды: на стартапе с двумя десятками человек, в аутсорсе с десятком клиентских контуров и в компании, где вся ИБ держалась на одном энтузиасте с доступом к роутеру. Ниже — маршрут по дням, вопросы, на которые нужно ответить, и то, что в итоге попадёт в отчёт.
Чего недельный аудит не даст
Сразу снимем ожидания. За семь дней вы не найдёте логические уязвимости в коде, не увидите, сидит ли в вашей сети кто-то чужой, и не получите никаких гарантий. Это не пентест и не сертификационный аудит по ISO 27001 или ГОСТ Р 57580. Сканеры уязвимостей на такой дистанции дают заметную долю ложных срабатываний, и верить им на слово — плохая идея.
Что вы получите: карту активов, список дыр с доказательствами и приоритетами, понимание, какие процессы существуют только на бумаге. Этого достаточно, чтобы навести порядок в ближайший квартал и перестать тушить пожары вслепую.
День 1. Инвентаризация: без неё остальное — гадание
Классика жанра: компания считает, что у неё три сервера, а на деле — тринадцать, плюс два забытых домена, плюс тестовый стенд с реальной копией базы клиентов. Поэтому первый день уходит не на безопасность, а на бухгалтерию активов.
Где искать: договоры с провайдерами и платежи, DNS-зоны и историю поддоменов, аккаунты в облаках (Yandex Cloud, VK Cloud, Selectel), репозитории и CI/CD, файлообменники, CRM и внутренние мессенджеры, корпоративные лицензии, а также презентации отдела продаж — там иногда всплывают сервисы, о которых ИТ не знает.
На выходе — таблица с четырьмя колонками:
- актив (домен, сервер, SaaS, база, репозиторий);
- владелец — конкретный человек, а не отдел;
- где физически или юридически лежит и кто имеет доступ;
- что будет, если актив утечёт или упадёт на сутки.
Последняя колонка важнее первых трёх: она сразу отделяет критичное от декоративного.
День 2. Доступы и аутентификация
По статистике утечек, слабые или переиспользованные учётки и отсутствие второго фактора остаются в топе причин взломов. Проверяете по списку:
- включена ли MFA на VPN, админках облака, почте, Git-сервере, панелях управления сайтами;
- сколько у вас привилегированных учёток и у кого они; не сидит ли кто-то под root и admin каждый день;
- сверка с HR: уволенные сотрудники, у которых доступ жив, — самая частая находка на таких аудитах;
- сервисные аккаунты: их пароли, срок жизни, где они записаны (файл на шаре или менеджер паролей);
- секреты в репозиториях — прогоните историю коммитов через gitleaks или trufflehog, найдёте больше, чем ожидаете;
- общие учётки вида info@ и admin, которыми пользуются пятеро.
Отдельно про парольную политику. Если у вас всё ещё принудительная смена пароля раз в 90 дней — по современным рекомендациям NIST это скорее вредит: люди начинают менять цифру в конце. Работающая связка — длинный пароль, менеджер паролей, MFA и блокировка после серии неудачных попыток.
День 3. Внешний периметр и патчи
Берёте список активов из дня первого и честно сравниваете с тем, что торчит в интернет. Практика: соберите диапазоны IP, прогоните по ним nmap и nuclei с дефолтными шаблонами — этого хватает, чтобы найти RDP наружу, SSH с паролем, открытые админки, тестовые стенды на старых версиях и панели вроде Prometheus, Grafana или Kibana без авторизации.
Отдельно ищите хранилища: публично доступный бакет с бэкапами — это не гипотетический риск, а типовой инцидент последних лет.
Дальше — версии ПО и скорость реакции на чужие проблемы. Вспомните, чем закончились CitrixBleed (CVE-2023-4966), MOVEit (CVE-2023-34362) и GlobalProtect в PAN-OS (CVE-2024-3400): во всех случаях эксплуатировали не хитрую логику, а непропатченный пограничный сервис. Вопрос аудита простой: за сколько дней у вас ставится критичный патч на внешний периметр и кто за это отвечает.
Не забудьте про EOL: Windows Server 2012, старые версии PostgreSQL, антивирус без поддержки вендора. Если продукт больше не получает обновлений, он уже не про безопасность, а про удачу.
День 4. Бэкапы: проверяем не наличие, а восстановление
Люди любят писать «бэкапы есть», не проверяя ни разу. На аудите задайте четыре вопроса.
- Работает ли схема 3-2-1: три копии, два носителя, одна копия вне основной площадки.
- Есть ли изолированная копия — офлайн-лента или immutable-хранилище, которое нельзя удалить скомпрометированной учёткой.
- Задокументированы ли RTO и RPO и понимает ли бизнес, что «двое суток» — это ответ, а не отговорка.
- Кто и когда последний раз восстанавливал систему целиком, а не отдельный файл.
Пятый, необязательный, но полезный пункт: лежит ли бэкап в том же аккаунте или домене, что и прод. Если да, то при захвате домена вы теряете и данные, и копии одновременно.
День 5. Логи и обнаружение
Вопрос дня: если завтра кто-то войдёт в админку под привилегированной учёткой в три ночи, вы об этом узнаете?
Минимальный набор, который должен логироваться: входы и неуспешные попытки, административные действия, изменения конфигураций, доступ к чувствительным данным, работа с бэкапами. Дальше — три проверки:
- включены ли аудит-логи в облаке (по умолчанию во многих сервисах они не пишутся);
- сколько логи хранятся — для персональных данных это отдельное требование, и срок не бесконечный;
- кто и как часто их смотрит. Логи без разбора — это просто страховка от претензий, а не от инцидентов.
Хороший признак — настроенные алерты: вход с нового гео, создание новой админ-учётки, массовые неуспешные входы, отключение антивируса, изменения в политике бэкапов. Если SIEM нет и не планируется, хватит связки централизованного сбора логов плюс десятка правил в нём.
День 6. Люди и процессы
Самая недооценённая часть. Проверьте процедуры онбординга и увольнения: кто выдаёт доступы, кто их забирает и есть ли чек-лист. Пройдитесь по подрядчикам — сколько внешних людей имеет доступ к вашим системам, подписаны ли NDA, ограничены ли их права по времени.
Дальше — готовность к инциденту. Спросите у дежурного: что ты сделаешь в первую минуту после сообщения о шифровании файлов и кому позвонишь? Если ответ начинается с «ну, наверное, позвоню…» — регламент существует только в чьей-то голове. Заодно проверьте покрытие EDR или антивирусом: обычно под защитой десктопы, а Linux-серверы, маки разработчиков и контейнеры остаются голыми.
И последнее на сегодня: сравните то, что написано в политиках, с тем, что происходит в жизни. Расхождение в две-три страницы — норма, в двадцать — повод переписать политики, а не людей.
День 7. Отчёт и приоритизация
Отчёт делайте на 4–6 страниц. Формат находки: что нашли, как это проверить (скриншот или вывод команды без секретов), какой риск, кто владелец, срок. Дальше приоритизация по простой матрице «вероятность × ущерб» — экспертной оценке 3×3 более чем достаточно для недельного спринта.
Разложите всё на три срока:
- неделя — то, что делается силами команды: MFA, закрытие лишних портов, удаление уволенных учёток, отзыв старых ключей;
- месяц — процессы и деньги: immutable-бэкап, алерты, менеджер паролей, инвентаризация как регламент;
- квартал — архитектура: сегментация сети, EDR на серверы, SIEM, импортозамещение выпадающих из поддержки продуктов.
Не пишите в отчёт пятьдесят пунктов. Пять находок, которые реально снизят риск, работают лучше, чем документ, который положат в папку.
Что проверить по части регуляторики
Если вы обрабатываете персональные данные, недельный аудит должен ответить и на формальные вопросы: определён ли состав обрабатываемых данных, подано ли уведомление в Роскомнадзор, есть ли модель угроз и акт оценки эффективности мер по статье 19 152-ФЗ. С 2025 года за неподачу уведомления об обработке персональных данных введена отдельная административная ответственность — если не уверены, проверьте статус своей организации в реестре операторов.
Дальше — отраслевые документы: приказ ФСТЭК России № 17 для государственных информационных систем и приказ № 21 для систем персональных данных. Требования к уровню защищённости определяются моделью угроз, и без неё любой чек-лист превращается в набор случайных мер. Об этом стоит помнить, когда вендор обещает «полное соответствие за месяц» — за месяц можно привести документы в порядок, но не построить защиту.
Чек-лист аудита за неделю
- Собран реестр активов с владельцами и оценкой ущерба.
- MFA включена на всех внешних и административных точках входа.
- Уволенные и подрядчики не имеют живых доступов; привилегии выданы по минимуму.
- Секреты не лежат в репозиториях, пароли — в менеджере, а не в файле на шаре.
- Внешний периметр совпадает с инвентарём, лишнего наружу не смотрит.
- Для критичных CVE есть срок установки патча и ответственный.
- Есть изолированная копия бэкапа и хотя бы один успешный тест восстановления.
- Логи собираются, хранятся нужный срок и порождают алерты.
- Дежурный знает, что делать в первые 15 минут инцидента.
- Отчёт с топ-5 находок и планом на 30/90/180 дней лежит у руководителя.
Вместо вывода
Недельный аудит не делает вас защищёнными. Но он делает следующее: превращает тревожное «нам кажется, у нас всё плохо» в конкретный список с адресами, сроками и ценой. И, что важнее, показывает команде, что безопасность — это не пачка политик в SharePoint, а несколько регулярных действий, которые можно встроить в обычную работу. Остальное — вопрос дисциплины и повторяемости, а не волшебной кнопки.
