Когда я слышу «мы внедрили систему информационной защиты», у меня всегда один вопрос: а что именно вы внедрили? Потому что в девяти случаях из десяти за этой фразой стоит покупка одного дорогого антивируса или SIEM-системы, после которой инфраструктуру продолжают админить как раньше — на доверии и удаче. Строить защиту «сверху вниз», начиная с вендорских коробок, — это путь к красивому отчёту для руководства и дырам, которые вскроются при первой же атаке. Давайте разберёмся, как выглядит рабочая система защиты, если собирать её снизу, от реальных активов, а не от маркетинговых буклетов.
Шаг 1. Инвентаризация: вы не защитите то, чего не видите
Прежде чем покупать хоть один инструмент, ответьте на вопрос: что именно нужно защищать? Соберите актуальный список активов:
- серверы и рабочие станции — с версиями ОС и установленным ПО;
- базы данных и критические сервисы — с указанием владельца;
- внешние интерфейсы: VPN, веб-приложения, API, почта;
- облачные ресурсы и SaaS-аккаунты, включая теневые (shadow IT);
- учётные записи привилегированных пользователей.
Практический совет: держите инвентаризацию в актуальном состоянии автоматически — через инвентаризационные агенты или API облачных провайдеров. Ручной Excel умрёт в первый же месяц, потому что в компании появится новый сервис, о котором никто не запишет.
Шаг 2. Доступы: принцип наименьших привилегий и 2FA
Правило простое: у каждого пользователя и сервиса ровно столько прав, сколько нужно для работы, и ни граммом больше. На практике это значит:
- запрет общей учётки root/Administrator для ежедневной работы;
- отдельные сервисные аккаунты для каждого приложения, а не один на всё;
- обязательный 2FA для VPN, почты и админ-панелей — TOTP или аппаратные ключи, а не SMS;
- регулярный аудит прав: кто заходил, кто уволился, чей доступ пора отозвать.
По статистике отчёта Verizon DBIR, значительная часть инцидентов начинается со скомпрометированных учётных данных. Парольная политика важна, но без многофакторной аутентификации она лишь замедлит атакующего на пару часов.
Шаг 3. Сегментация сети: почему «плоский» периметр — это плохо
Если у вас все серверы в одной подсети с рабочими станциями, одна скомпрометированная учётка отдаёт атакующему всю инфраструктуру. Разделите сеть на сегменты: DMZ для публичных сервисов, отдельные сегменты для БД, для разработки и для офисных ПК. Между сегментами — файрвол-правила, разрешающие только необходимое.
Особое внимание — контуру управления: доступ к админ-интерфейсам (SSH, панели, API) только из отдельной сети или через jump-host с 2FA. Это одна из самых дешёвых и при этом самых эффективных мер, которую чаще всего игнорируют.
Шаг 4. Безопасность CI/CD и цепочки поставок
Современная атака часто идёт не на ваш сервер, а на ваш пайплайн. Скомпрометированный пакет в зависимостях или утёкший токен CI могут дать доступ к коду и окружениям быстрее, чем любой «взлом периметра». Минимальный набор мер:
- скан зависимостей на известные уязвимости (CVE) при каждой сборке;
- подпись и проверка артефактов, чтобы в прод не попал подменённый бинарник;
- секреты — только в секрет-менеджере (Vault, AWS Secrets Manager), никогда в коде и переменных окружения репозитория;
- принцип наименьших прав для CI-аккаунтов: пайплайн не должен уметь всё.
Шаг 5. Мониторинг и реагирование: логи, которые кто-то читает
Собирать логи и «никогда их не смотреть» — почти то же самое, что не собирать. Внедрите централизованный сбор событий с ключевых систем и настройте алерты на аномалии: входы вне рабочего времени, массовые скачивания, изменения файрвол-правил, попытки доступа к несуществующим ресурсам.
Для малого и среднего бизнеса не обязательно тянуть полноценный SIEM за миллионы. Достаточно связки OpenSearch/Elasticsearch + системы алертов и чёткого runbook: кто реагирует, в какие сроки, как эскалировать. Главное — чтобы алерты не превращались в «шум», который все игнорируют: отсекайте ложные срабатывания и оставляйте только то, на что вы реально готовы реагировать.
Шаг 6. Бэкапы: ваша страховка от шифровальщиков
Атаки с программами-вымогателями бьют не по серверам — они бьют по данным и по времени простоя. Рабочее правило — 3-2-1: три копии данных, на двух разных носителях, одна — вне основной площадки. Обязательно:
- тестируйте восстановление регулярно, а не в момент кризиса;
- храните резервные копии в изолированном сегменте, куда не достанет скомпрометированный сервер;
- проверяйте целостность и шифрование копий — восстановление из «битого» бэкапа хуже, чем его отсутствие.
Шаг 7. Регуляторика: не только для банков
Если вы храните персональные данные граждан РФ, 152-ФЗ касается и вас: уведомление Роскомнадзора, согласия субъектов, договор с оператором. Если вы работаете с гостайной или объектами критической инфраструктуры — понадобятся аттестация и организационные меры по требованиям ФСТЭК. Но не путайте: соответствие регуляторике не равно безопасности. Сертификат не остановит атакующего, зато честно закрытые базовые шаги из этого чек-листа — остановят.
Итоговый чек-лист
- Актуальная автоматизированная инвентаризация активов.
- Принцип наименьших привилегий + 2FA на всех входах.
- Сегментация сети и изолированный контур управления.
- Сканирование зависимостей, секрет-менеджер, проверка артефактов.
- Централизованные логи с рабочими алертами и runbook’ом реагирования.
- Бэкапы по схеме 3-2-1 с регулярным тестированием восстановления.
- Назначенный ответственный и план реагирования на инциденты.
Ни один пункт из этого списка не требует покупки «волшебной коробки». Система информационной защиты — это не продукт, который можно установить за вечер. Это процесс: инвентаризация, контроль доступов, мониторинг и регулярные проверки. Начните с того, что у вас болит сильнее всего, и стройте по шагам — так защита будет работать, а не пылиться на полке рядом с сертификатами соответствия.
