Каждый раз, когда я читаю очередной пресс-релиз про «комплексную систему защиты информации на базе ИИ», вспоминаю свой первый аудит в компании на 120 человек. Формально там было всё: антивирус, межсетевой экран, DLP, политика паролей на двадцать страниц и подписанный акт соответствия. По факту — бухгалтер с правами локального администратора, пароль от 1С на стикере, бэкапы на том же диске, что и рабочая база, и действующая учётная запись сотрудника, уволенного полгода назад.
Деньги потратили, защиту — нет. И это не единичный случай, а закономерность: рынок ИБ продаёт продукты, а инциденты происходят в процессах. Ниже — семь ошибок, которые я встречаю чаще всего, и то, что с ними делать на практике.
Ошибка 1. Защита ради галочки, а не ради риска
Самая дорогая ошибка. Компания покупает SIEM или DLP, потому что «так у всех» или потому что этого требует аудитор, разворачивает, закрывает проект и больше в консоль не заходит. Алерты копятся, разбирать их некому, через год лицензия продлевается уже по привычке.
Комплаенс и защищённость — разные вещи. 152-ФЗ и приказы ФСТЭК №17 и №21 описывают минимальный набор мер, а не модель угроз вашего конкретного бизнеса. Формально выполнить требования можно, оставшись при этом полностью уязвимым.
Что делать: начинать с модели угроз и оценки рисков, а не с выбора вендора. Приоритизировать по связке «вероятность × ущерб» и мерить результат не галочкой «внедрено», а метриками: доля критичных уязвимостей, закрытых в срок, покрытие MFA, среднее время обнаружения и реакции на инцидент.
Ошибка 2. Нет инвентаризации активов, данных и доступов
Нельзя защитить то, чего нет в реестре. Классика: тестовый стенд с полной копией продакшн-базы, включая персональные данные клиентов; забытый поддомен с админкой; бакет в облаке с публичным доступом; три теневых сервиса, которыми команда пользуется, но о которых не знает ИБ.
Инвентаризация — скучная работа, поэтому её постоянно откладывают. А без неё любая оценка рисков превращается в гадание.
Что делать: вести реестр активов с владельцами и владельцами данных; провести классификацию информации (какие ПДн обрабатываем, где лежат, кто имеет доступ, сколько храним); автоматизировать сбор — API облаков, сканеры сети, инвентаризация из систем мониторинга. Тестовые данные либо маскировать, либо не выносить в тестовые контуры вовсе.
Ошибка 3. Патчи и уязвимости по остаточному принципу
Уязвимости, которые эксплуатируются в реальных атаках, обычно не требуют гениальности от атакующего — они требуют, чтобы админ не обновился. Log4Shell (CVE-2021-44228) находили на периметрах спустя месяцы после публикации патча. Уязвимость в MOVEit Transfer (CVE-2023-34362) использовала группа Cl0p, и жертвами стали десятки организаций по всему миру — в том числе те, у кого процессы обновления были «на бумаге».
Отдельная история — зависимость, которую никто не считает своей: бэкдор в liblzma (CVE-2024-3094) в 2024 году заметил разработчик по случайности, из-за аномалии в производительности. Это не про халатность одного мейнтейнера, это про то, что вы не контролируете то, что тянете в сборку.
Что делать: выстроить непрерывный процесс, а не «патч-день раз в квартал». Сканирование зависимостей прямо в CI, SBOM на каждый релиз, окна реакции по критичности — для активно эксплуатируемых уязвимостей часы и дни, а не месяцы.
Ошибка 4. Человеческий фактор пытаются закрыть «обучалками»
Клик по фишинговой ссылке — не главная проблема. Проблема в том, что происходит после клика: ни MFA, ни ограничения прав, ни детекта, ни возможности быстро отозвать сессию. Если сотрудник кликнул, и это ничем не закончилось, система работает. Если кликнул и получил рабочий доступ ко всей сети — виновата не обучалка, а архитектура.
Вторая беда — наказания за ошибки. Там, где за клик штрафуют, люди молчат о подозрительных письмах и тянут до последнего.
Что делать: короткие регулярные сессии вместо годового двухчасового курса; симуляции фишинга без репрессий и с разбором; техническая подстраховка — MFA (лучше аппаратные ключи или FIDO2 для критичных систем), ограничение макросов, блокировка нетипичных вложений; кнопка «сообщить о подозрительном» в один клик прямо в почтовом клиенте.
Ошибка 5. Плоские права и бессрочные доступы
Все в одном домене, у админов полные права «чтобы не мешать работе», сервисные учётки с паролем, который не менялся с установки, «временный» доступ пятилетней давности. В отчётах по инцидентам именно это и превращает одну скомпрометированную учётку в полный контроль над инфраструктурой: горизонтальное перемещение внутри сети занимает часы.
Что делать: принцип наименьших привилегий и ролевая модель; отдельный контур для администрирования; PAM-решение или хотя бы хранилище привилегированных учёток с выдачей по запросу на время; сегментация сети, чтобы из бухгалтерии не было прямого маршрута к базе клиентов; регулярные ревью доступов и отзыв прав в день увольнения, а не «когда дойдут руки».
Ошибка 6. Секреты в репозиториях и недоверенная цепочка поставок
Токены в истории git, .env в коммите, ключи от платёжного API в переменных CI, которые видит любой разработчик, — это не экзотика, а повседневность. Плюс зависимости из публичного реестра без проверки: подмена имени пакета, тайпсквоттинг, скомпрометированные мейнтейнеры.
Что делать: secret scanning на pre-commit и в CI, ротация всех ключей при утечке (а она будет), секрет-менеджер вместо переменных окружения, короткоживущие креды вместо долгоживущих, приватный прокси-реестр с проверкой пакетов, lock-файлы и подпись артефактов перед деплоем.
Ошибка 7. Нет логов, детекта и проверенного плана реакции
Типичный разговор при разборе инцидента: «логи хранили три дня, диск маленький», «алертов не было, потому что правила никто не настраивал», «план реагирования есть, лежит у безопасника в папке, никто не читал». В итоге атаку обнаруживает клиент или платёжная система, а не вы.
Что делать: централизованный сбор логов с retention, рассчитанным по требованиям и практике, а не по остатку места на диске; детект-правила на ключевые сценарии (вход из нетипичной локации, массовая выгрузка данных, создание новых привилегированных учёток); план реагирования с ролями, контактами и каналами связи — и хотя бы одно учение в год, где вы репетируете, кто и кому звонит в три часа ночи. После каждого инцидента — разбор без поиска виноватых, с конкретными изменениями в процессе.
Что с этим делать: чек-лист на ближайший месяц
- Составить реестр активов и понять, где лежат персональные данные и коммерческая тайна.
- Описать модель угроз хотя бы на одну страницу — без неё всё остальное бессмысленно.
- Включить MFA на почте, VPN, админ-панелях и облачной инфраструктуре — начиная с привилегированных учёток.
- Проверить, что бэкапы лежат отдельно, проверяются восстановлением и защищены от удаления.
- Настроить сканирование зависимостей и секретов в CI, ввести окна реакции на критичные уязвимости.
- Провести ревизию доступов: у кого что есть и почему, кого пора лишить прав.
- Выделить админский контур и сегментировать сеть хотя бы до уровня критичных сервисов.
- Поднять срок хранения логов и настроить пять-семь детект-правил на самые очевидные сценарии.
- Записать план реагирования на одну страницу и провести по нему получасовое учение.
- Завести метрики и смотреть на них раз в месяц, а не раз в год перед аудитом.
Вывод простой, хотя и неудобный: защита информации — это не продукт, который можно купить и закрыть задачу, а набор регулярных скучных действий. Семь ошибок выше объединяет одно — где-то решили, что достаточно бумаги вместо процесса. Начните с инвентаризации, MFA и бэкапов: три этих шага закрывают больше реальных рисков, чем половина бюджета, потраченного на очередную волшебную кнопку.
