Когда мне приносят проект, где «защиту» решили добавить уже после того, как система написана, развёрнута и начала работать, у меня дёргается глаз. Не потому, что я злой: я просто знаю, чем это заканчивается — двухнедельный аврал, покупка дорогого устройства, которое никто не настроил, и отчёт «чтобы отстали». Проектирование защиты информационной системы — это не финальный штрих, а фундамент. Ниже — восемь типовых ошибок, которые я встречал в реальных проектах, и что с ними делать.
Ошибка 1. Защита «в конце» вместо security by design
Самая дорогая ошибка — думать, что безопасность можно добавить потом. Когда архитектура уже собрана, а потоки данных зафиксированы, любое «усиление» превращается в костыли: шифрование поверх небезопасного протокола, антивирус на сервере, к которому ходят все, и VPN «для красоты». Переделывать дороже в разы — по моим оценкам, трудозатраты на доработку и простой обходятся в три-десять раз дороже, чем если бы требования заложили сразу.
Правильный порядок — наоборот: требования к защите появляются, когда рисуется первая схема. Кто имеет доступ к данным, какие каналы передачи, где хранится самое ценное, что произойдёт при утечке. Это не паранойя ради паранойи: это те же вопросы, которые вы в любом случае зададите, но до того, как менять код станет поздно.
Ошибка 2. Модель угроз «для галочки»
Формальная модель угроз — это документ на сорок страниц, который пишут один раз, подписывают и кладут на полку. Она отвечает не на вопрос «что реально угрожает нашей системе», а на вопрос «что мы скажем проверяющему». В российской практике за основу обычно берут методику оценки угроз безопасности информации ФСТЭК России (утверждена 05.02.2021) — и это нормально, если методика работает как инструмент, а не как шаблон для копипасты.
Реальная модель угроз строится от активов: что у нас есть (данные, сервисы, доступы), что для нас ценно, кто может захотеть это получить и какими путями. Если модель угроз не меняется, когда вы добавили сервис, открыли порт или подключили подрядчика, — она мертва. Живая модель пересматривается при каждом существенном изменении системы, и именно на неё опираются при выборе контрмер.
Ошибка 3. Покупка «серебряной пули» вместо архитектуры
Хватит бегать за каждой новой волшебной кнопкой. SIEM, WAF, NGFW, «платформа кибербезопасности нового поколения» — это инструменты, а не стратегия. Я видел компании, где купленный за миллионы SIEM собирает логи, которые никто не читает, а WAF два года работает в режиме «только наблюдение». Это не защита, это декорация.
Сначала — архитектура: сегментация сети, контроль доступа, управление учётными записями, резервное копирование. Потом — процессы: кто и как реагирует на инциденты, как обновляются системы, как выдаются доступы. И только потом — инструменты, которые эти процессы автоматизируют. Покупать SIEM до того, как у вас появился регламент реагирования, — всё равно что покупать пожарную машину без шлангов: красиво, но бесполезно.
Ошибка 4. Плоская сеть, где «все свои»
Классика: одна подсеть, серверы и рабочие станции в одном сегменте, доступ по RDP открыт «для удобства». Внутренняя сеть считается доверенной — и зря: большинство инцидентов начинается изнутри, будь то скомпрометированная учётка сотрудника или фишинг. Один клик по письму — и злоумышленник уже внутри вашей «доверенной» сети.
Сегментация — это не модный термин, а инженерное решение: разделить сеть на зоны, ограничить трафик между ними правилами межсетевого экранирования, разнести контур с персональными данными и публичные сервисы. Даже простейший вариант — отдельная зона для баз данных и отдельная для приложений — кратно снижает радиус поражения. Концепция Zero Trust тут помогает не как «кнопка», а как принцип: не доверяй никому по умолчанию, проверяй всё.
Ошибка 5. Забыли про людей и процессы
Технологии — треть дела. Можно построить идеальную архитектуру, но если пароли на стикерах, доступы не отзываются у уволившихся, а обновления ставятся «когда будет время» — система не защищена. Человек — слабейшее звено, это не метафора, а вывод из множества разборов инцидентов.
На этапе проектирования закладывайте процессы: управление доступом (кто, когда, зачем и на какой срок), реагирование на инциденты (кто поднимает, кто решает, что делать), управление обновлениями и конфигурациями. И обучение: не «лекция о кибергигиене раз в год», а короткие регулярные тренировки, включая проверку на фишинг. Это дешевле, чем разбор утечки.
Ошибка 6. Секреты в коде и зависимости «на честном слове»
Для разработчиков и DevOps главные грабли — ключи и пароли в репозиториях, контейнеры с захардкоженными секретами, зависимости, которые никто не обновляет. Вспомните Log4Shell (CVE-2021-44228): одна библиотека в сотнях тысяч приложений, и обновлять её нужно было «вчера». Или цепочку поставок SolarWinds, где компрометация инструмента разработки ударила по тысячам компаний по всему миру. Для веб-приложений минимум — актуальный OWASP Top 10.
Закладывайте в проект секрет-менеджмент (Vault и аналоги), сканирование зависимостей в CI/CD, проверку образов контейнеров на известные уязвимости. Это не «дополнительные задачи», а часть инженерной культуры: если сборка прошла без проверки зависимостей, она не должна попадать в прод.
Ошибка 7. Регуляторика «на потом»
Если вы обрабатываете персональные данные граждан РФ, 152-ФЗ действует уже сейчас, и «на потом» не получится. Проектирование — лучший момент, чтобы понять, какие требования к вам применимы: 152-ФЗ, приказы ФСТЭК, отраслевые стандарты. Внедрять их задним числом, когда система уже работает, — это боль, штрафы и переделки.
Практический совет: на этапе проектирования определите категории обрабатываемых данных и обязательные меры защиты. Для персональных данных это минимум — назначение ответственного, оценка вреда, определение уровня защищённости и меры по приказам ФСТЭК. Если система государственная — отдельная история с требованиями к ГИС. Лучше задать себе эти вопросы до запуска, чем объяснять проверяющим после.
Ошибка 8. Резервные копии «как-нибудь потом»
Шифровальщики не спрашивают, готовы ли вы. Если резервных копий нет или они лежат в той же сети, что и рабочие данные, восстановление превращается в драму: платить выкуп (не рекомендую, но люди платят) или терять данные. Копии должны быть изолированы от основной сети и регулярно проверяться восстановлением, а не только «создаваться по расписанию». Копия, которую вы ни разу не пробовали развернуть, — это не копия, а надежда.
Чек-лист: что заложить в проект защиты
- Определите активы и критичность данных до выбора инструментов.
- Постройте модель угроз от активов, а не от шаблона, и назначьте ответственного за её актуализацию.
- Сегментируйте сеть и ограничьте трафик между зонами.
- Заложите процессы: управление доступом, реагирование на инциденты, обновления.
- Включите секрет-менеджмент и проверку зависимостей в CI/CD-пайплайн.
- Проверьте применимость 152-ФЗ и требований ФСТЭК до старта разработки.
- Настройте изолированные резервные копии и регулярно тестируйте восстановление.
- Выбирайте инструменты под архитектуру, а не архитектуру под инструменты.
Итог простой: защита информационной системы — это не покупка, а проект. Как и любой проект, он начинается с требований и архитектуры, а не с каталога вендора. Заложите безопасность в проект с первого дня — и сэкономите себе месяцы авралов и нервов.
