Я много лет смотрю на презентации вендоров ИБ, где одна «единая платформа» закрывает все риски разом. А потом приезжаю на объект и вижу SIEM, который полгода собирает логи в никуда, и политики безопасности, написанные под копирку. Система информационной защиты — это не коробка с логотипом вендора, а последовательность скучных, но проверяемых решений, которые принимает IT-отдел. В этой статье — план, который я собирал по кускам на реальных внедрениях: от списка активов до плана реагирования на инцидент. Без магии и без воды.
Шаг 1. Инвентаризация: не защитишь то, чего не видишь
Первое, что я делаю на любом проекте, — прошу список активов. И почти всегда получаю Excel-таблицу, которая устарела года два назад: часть серверов уже в облаке, часть — виртуализирована, а про тестовые стенды в соседнем кабинете вообще никто не помнит.
Начните с простого перечня: серверы, рабочие станции, ноутбуки, сетевое оборудование, СУБД, приложения, облачные подписки и SaaS-сервисы. По каждому активу зафиксируйте три вещи: владельца (кто отвечает), критичность (что будет, если актив исчезнет) и доступность из интернета. Отдельно пройдитесь по вопросам:
- Кто имеет доступ к этому активу и зачем?
- Какие сервисы смотрят наружу: порты, панели, API?
- Где хранятся секреты: пароли, ключи, токены?
Сетевые сканеры и агенты инвентаризации — хорошие помощники, но не подмена. Сканер покажет IP-адрес, а не бизнес-процесс. Заведите реестр активов и обновляйте его раз в квартал — это фундамент, на котором держится всё остальное.
Шаг 2. Модель угроз: три страницы вместо пятидесяти
ФСТЭК любит модели угроз на пятьдесят страниц, и аудиторы любят на них ссылаться. Но рабочая модель угроз для малого и среднего бизнеса умещается на трёх страницах, если отвечает на два вопроса: от кого мы защищаемся и что именно защищаем.
Честно перечислите актуальные сценарии: эксплуатация уязвимостей публичных сервисов, фишинг и компрометация учёток, инсайдеры (слив, саботаж, неосторожность), отказ оборудования, потеря ноутбука с данными. По моему опыту, для большинства компаний без статуса «объект КИИ» реальные риски — фишинг, слабые пароли и необновлённый софт, а не АПТ-группы спецслужб. Не выдумывайте противника, которого у вас нет, — иначе потратите бюджет на защиту от вымышленных сценариев.
Шаг 3. Базовая гигиена: 80% эффекта за 20% бюджета
Здесь начинается самое негламурное, но самое эффективное. Большинство инцидентов в малом и среднем бизнесе закрываются базовой гигиеной, а не дорогими системами:
- Автоматические обновления ОС и приложений. Звучит банально, но я видел компании, где патчи ставят раз в полгода, «чтобы не сломать», — и ломает их потом атакующий, а не обновление.
- Двухфакторная аутентификация везде, где можно: почта, VPN, админки, облачные консоли. Это закрывает подавляющую часть компрометаций паролей.
- Менеджер паролей для всей команды. Хватит хранить пароли в заметках, Excel и на стикерах под клавиатурой.
- Бэкапы по схеме 3-2-1: три копии, два разных носителя, одна — вне офиса. И регулярно проверяйте восстановление: бэкап, который нельзя развернуть, — это просто место на диске.
- Антивирус или EDR. Важно не наличие «коробки», а настроенные политики и живой человек, который смотрит алерты. EDR без разбора алертов — это дорогая игрушка.
Я сознательно ставлю гигиену до покупки SIEM и прочих «платформ»: сначала закройте дыры в фундаменте, потом стройте второй этаж.
Шаг 4. Доступы и привилегии: меньше прав — меньше боли
Принцип минимальных привилегий звучит красиво, но на практике его нарушают все. Админская учётка используется для почты и просмотра сайтов, бывший сотрудник числится в VPN ещё месяц после увольнения, а у стажёра полный доступ к прод-базе «потому что удобно».
Правила, которые я внедряю первыми:
- Отдельные учётки для администрирования — без прав на почту и повседневные задачи.
- Блокировка доступа в день увольнения, а не «потом». Потом — это когда уже поздно.
- Права выдаются по ролям и пересматриваются раз в квартал.
Отдельная боль — DevOps. Токены CI/CD, доступы к прод-серверам и облачным консолям, секреты в репозиториях. Один скомпрометированный токен в пайплайне — и цепочка поставки ПО под ударом, как это было в громких supply chain-инцидентах последних лет. Секреты — только в секрет-менеджере (Vault, SOPS, облачные KMS), никогда в коде, README или переменных окружения с дефолтными значениями.
Шаг 5. Безопасность разработки: DevSecOps без фанатизма
Если ваша команда пишет код, безопасность — часть процесса разработки, а не «этап перед релизом». OWASP Top 10 — это не чтиво на ночь, а рабочий чек-лист: инъекции, сломанная аутентификация, небезопасная десериализация никуда не делись за десять лет.
Минимальный набор для DevSecOps:
- Сканирование зависимостей (SCA) — уязвимые библиотеки причина половины современных атак. Подключите проверку прямо в CI.
- Статический анализ кода (SAST) на каждом pull request.
- Сканирование контейнерных образов перед выкладкой в прод.
- Code review как обязательный этап, а не формальность.
Не ждите, что инструменты всё сделают сами. Сканер найдёт — человек должен решить: обновить, задокументировать риск или принять его. Без этого процесса вы получите тонны алертов и ноль результата.
Шаг 6. Мониторинг: SIEM — не серебряная пуля
SIEM — любимая игрушка вендоров и аудиторов. Но SIEM без настроенных корреляций, источников событий и дежурного инженера — это дорогой архив логов. Я видел проекты, где SIEM внедряли «для галочки», и он не породил ни одного полезного алерта.
Начните с простого: централизованный сбор логов критичных систем (домен, почта, VPN, файловые серверы, базы), алерты на множественные неудачные входы, подозрительные процессы, аномальный исходящий трафик, изменения в системных файлах. И обязательно — план реагирования на инциденты:
- Кто поднимает руку первым и кому докладывает?
- Кто принимает решение отключить скомпрометированный сервер?
- Как уведомить сотрудников, клиентов и регулятора?
Проведите хотя бы одну тренировку: инсценируйте заражение рабочей станции и пройдите весь путь от обнаружения до восстановления. Гарантирую: найдёте дыры, о которых не подозревали.
Шаг 7. Регуляторика: 152-ФЗ без паники
Для российских компаний регуляторный контур — это 152-ФЗ о персональных данных и требования ФСТЭК. Многие пугаются слов «аттестация» и «сертифицированные СКЗИ» и предпочитают не трогать тему вообще. Это ошибка, но и паниковать не стоит.
Начните с простого вопроса: какие персональные данные вы вообще обрабатываете? Если только ФИО и контакты сотрудников в кадровом учёте — это один уровень требований. Если у вас база клиентов с паспортными данными и платёжными реквизитами — совсем другой. Под требования ФСТЭК попадёт и большинство государственных и муниципальных информационных систем, и объекты КИИ. Правильная последовательность — сначала классификация и модель угроз (шаги 1–2), потом выбор мер из базового набора, а не наоборот, «купили сертифицированное — значит защищены».
Чек-лист: с чего начать в понедельник
Если у вас нет системы защиты вообще, вот что я бы сделал в ближайший месяц:
- Соберите актуальный список активов: серверы, ноутбуки, облака, SaaS.
- Включите автоматические обновления и 2FA для почты, VPN и админок.
- Переведите команду на менеджер паролей.
- Проверьте бэкапы реальным восстановлением на тестовом стенде.
- Разведите админские и пользовательские учётки, уберите лишние права.
- Вынесите секреты из кода в секрет-менеджер.
- Настройте сбор логов и три-четыре честных алерта.
- Напишите план реагирования на инцидент на одну страницу.
- Определите, какие персональные данные обрабатывает компания.
Система информационной защиты — это не проект с финальной датой, а регулярный процесс. Начинайте с малого, делайте системно, и через год у вас будет то, что реально работает, а не то, что красиво выглядит в презентации вендора.
