Почему защита информационных систем — это не про антивирус
Когда меня спрашивают, что такое защита информационных систем, я отвечаю так: это не продукт, который покупают один раз и забывают, а набор слоёв, каждый из которых решает свою узкую задачу. Классическая ошибка малого и среднего бизнеса — закрыть один слой (поставить антивирус и файрвол) и считать вопрос решённым. На практике атакующий ищет не самый защищённый слой, а самый слабый: тот, про который в компании просто забыли.
Громкие утечки последних лет почти никогда не начинаются с «гениального взлома». Начинается всё с забытого тестового стенда с боевыми данными, сервисной учётки с паролем из 2015 года или подрядчика, у которого нет ни сегментации, ни логирования. Поэтому дальше — без маркетинга: что именно защищаем, из каких слоёв это состоит и где реально образуются бреши.
Что именно мы защищаем
Информационная система (ИС) — это совокупность данных, технических средств, программного обеспечения и людей, которые эти данные обрабатывают. Формальное определение защиты информации дано в ГОСТ Р 50922-2006: это деятельность, направленная на предотвращение утечки защищаемой информации, а также несанкционированных и непреднамеренных воздействий на неё.
На практике цель любой системы защиты сводится к триаде свойств, которую называют CIA:
- Конфиденциальность — данные видит только тот, кому они положены. Не «все сотрудники по умолчанию», а строго по ролям.
- Целостность — данные не изменены ни злоумышленником, ни сбоем, ни ошибкой в коде. Сюда же относится защита от подмены обновлений и конфигов.
- Доступность — система работает, когда она нужна бизнесу. Шифрование всего и вся без плана восстановления ключей ломает именно это свойство.
Отдельно стоит помнить про нормативную рамку: 152-ФЗ для персональных данных, приказы ФСТЭК №17 и №21 для ГИС и значимых объектов, ISO/IEC 27001 и NIST SP 800-53 как международные ориентиры. Требования не заменяют здравый смысл, но задают минимальный набор мер, за невыполнение которого приходит не хакер, а проверяющий.
Слои защиты: модель «луковицы» без иллюзий
Подход defense in depth (эшелонированная защита) предполагает, что пробитие одного слоя не означает компрометацию всей системы. Разберём слои так, как они выглядят в реальной инфраструктуре, а не в презентации вендора.
1. Физический слой
Контроль доступа в серверную, видеонаблюдение, защита от затопления и перебоев питания, маркировка носителей. Скучно, но именно этот слой чаще всего игнорируют при аудите, а восстановление после локального ЧП стоит дороже, чем весь ИБ-бюджет за год.
2. Сетевой слой
Межсетверные экраны, сегментация (VLAN, микросегментация), VPN для удалённого доступа, IDS/IPS, контроль исходящих соединений. Ключевой принцип — не «плоская» сеть, где один заражённый ноутбук видит весь периметр, а разделение на зоны доверия: отдельно офис, отдельно серверный сегмент, отдельно промышленный контур.
3. Хостовый слой (endpoint)
EDR-агенты или классический антивирус, управление патчами ОС и приложений, включённые механизмы защиты ОС (например, ASLR, DEP, SELinux/AppArmor), запрет неучтённого ПО. Здесь важна не «навороченность» агента, а регулярность обновлений: уязвимость без патча обесценивает любой EDR.
4. Идентификация и доступ
Многофакторная аутентификация, единая точка входа (SSO), управление жизненным циклом учётных записей, привилегированные учётки под контролем (PAM). Это слой, который даёт самый высокий эффект на вложенный рубль: по данным большинства разборов инцидентов, вход по украденным учётным данным — самый частый вектор.
5. Прикладной слой
Безопасность приложений и API: проверка входных данных, разграничение прав на уровне бизнес-логики, защита от инъекций и подделки запросов. Ориентир — OWASP Top 10. Частая ошибка: WAF ставят и успокаиваются, хотя он лечит симптом, а не логическую дыру в коде.
6. Слой данных
Шифрование при передаче и хранении, управление ключами, разметка и классификация данных, маскирование в тестовых средах, контроль выгрузок и бэкапов. Отдельно — резервное копирование по схеме 3-2-1 и обязательная проверка восстановления. Бэкап, который ни разу не восстанавливали, бэкапом не является.
7. Люди и процессы
Регламенты, обучение, разбор инцидентов, кадровый процесс при увольнении, контроль подрядчиков. Именно этот слой определяет, сработает ли всё остальное: технология без процесса рассыпается при первом же нестандартном случае.
Где чаще всего образуются бреши
По опыту разборов, слабые места распределяются примерно так — и почти ни одно из них не связано с отсутствием «той самой кнопки»:
- Учётные записи. Общие пароли, отсутствие MFA, активные учётки уволенных сотрудников, сервисные аккаунты с избыточными правами.
- Незакрытые уязвимости. Компоненты, которые годами не обновлялись, потому что «так работает, не трогай». Регулярно проверяйте свой стек по NVD и бюллетеням вендоров.
- Цепочка поставок. Библиотеки, контейнерные образы, CI/CD-пайплайны и доступы подрядчиков — всё, что вы не писали сами и не контролируете полностью.
- Ошибки конфигурации. Открытые в интернет панели администрирования, бакеты с публичным доступом, дефолтные пароли оборудования.
- Слепые зоны в логировании. Когда инцидент уже произошёл, а логов нет — разбор превращается в гадание, а атакующий спокойно остаётся в сети.
- Несогласованные бэкапы и ключи. Копии есть, но восстановить их нельзя либо ключи шифрования не найдены.
Принципы, которые работают при любом бюджете
- Наименьшие привилегии. Давайте права под задачу и на время, а не «на всякий случай».
- Сегментация и нулевое доверие. Внутренняя сеть — не зона комфорта. Проверяйте каждый запрос к ресурсу.
- Управляемый патч-менеджмент. Определите сроки: критичное — дни, остальное — недели. Без исключений «для главбуха».
- Логирование и мониторинг. Централизованный сбор, алерты на аномалии входа, тестирование сценариев детекта.
- Автоматизация в CI/CD. Сканирование зависимостей, статический анализ, запрет хардкода секретов и обязательный аудит того, что уходит в прод.
- Регулярные учения. Раз в год хотя бы один разбор: сможет ли команда обнаружить и остановить условную атаку.
Скепсис к «серебряным пулям»
Вендоры любят обещать «полную защиту от всех угроз» и «ИИ, который всё найдёт сам». Мой опыт говорит обратное: доминирующую часть реальных инцидентов закрывают базовые вещи — MFA, патчи, сегментация, разграничение прав и внятные бэкапы. Дорогие платформы дают эффект только там, где эти базы уже сделаны. Покупать SIEM раньше, чем навести порядок в учётных записях, — это платить за красивый дашборд, который нечем наполнять.
Чек-лист: с чего начать
- Инвентаризация: какие системы, данные и учётки у вас есть. Без этого списка дальше идти нет смысла.
- MFA на всё, что доступно извне, и на привилегированные учётки внутри.
- Регламентированный процесс установки патчей и сроки реакции на критические уязвимости.
- Сегментация сети и запрет доступа из офисного сегмента в серверный «по умолчанию».
- Централизованные логи с хранением минимум 3–6 месяцев и алерты на подозрительные входы.
- Бэкапы 3-2-1 с регулярной проверкой восстановления.
- Управление секретами: ни одного пароля и токена в репозиториях и конфигах.
- Обучение сотрудников и простой канал, куда сообщить о подозрительном письме или звонке.
- Разбор подрядчиков и внешних интеграций: какие у них доступы и зачем.
- План реагирования на инцидент: кто звонит, кто изолирует, кто общается с юристами и регулятором.
Вывод
Защита информационных систем — это про системность, а не про один инструмент. Слоёв много, и каждый из них имеет смысл только в связке с остальными: MFA не спасёт, если учётка с правами администратора лежит в общем чате, а шифрование не поможет, если ключи хранятся рядом с данными. Начните с инвентаризации и базовых мер — они закрывают большинство реальных угроз. А экзотику и «серебряные пули» оставьте на потом, когда фундамент уже стоит.
