Слово «информационная защита» всплывает в двух случаях: когда в компанию приходит аудитор и когда что-то уже случилось. В обоих случаях выясняется неприятное — у команды есть антивирус, пароль на Wi-Fi и смутное ощущение, что «вроде всё настроено», но нет ответа на простой вопрос: что именно мы защищаем, от кого и на каком уровне. Эта статья — про то, как выстроить эту рамку без покупки ещё одного «революционного» средства защиты.
Защита информации и информационная безопасность: где граница
ГОСТ Р 50922-2006 определяет защиту информации как деятельность по предотвращению утечки защищаемой информации, несанкционированных и непреднамеренных воздействий на неё. Ключевое слово — деятельность. Не продукт, не лицензия, не «внедрили DLP и успокоились», а непрерывный процесс с владельцами, сроками и ответственными.
Информационная безопасность — рамка шире: она про состояние защищённости информации и поддерживающей её инфраструктуры, включая доступность для тех, кому она нужна по работе. Проще говоря, ИБ отвечает на вопрос «чего мы хотим достичь», а защита информации — «какими средствами и в каком режиме».
На практике это значит: если у вас нет письменного ответа, какие системы критичны и что будет, если они встанут, — вы занимаетесь не защитой, а закупкой. Любой вендор вам это подтвердит, только за деньги.
Пять уровней информационной защиты
Уровни удобно раскладывать от «внешнего» к «внутреннему»: сначала то, что навязано извне, затем то, что вы придумали сами, и только потом железяки и софт. Классическая ошибка — начинать с последнего.
1. Законодательный уровень
Это требования, которые вы не выбираете: 152-ФЗ о персональных данных, 149-ФЗ об информации, 187-ФЗ о критической информационной инфраструктуре, приказы ФСТЭК №17 (ГИС) и №21 (ИСПДн), отраслевые стандарты Банка России. Сюда же — обязанность уведомлять регулятора об инцидентах. С 30 мая 2025 года операторы персональных данных должны сообщать Роскомнадзору об утечке в течение 24 часов, а результаты внутреннего расследования предоставлять в течение 72 часов. Для субъектов КИИ по 187-ФЗ сроки ещё жёстче: 24 часа на уведомление ФСБ о факте и 72 часа на дополнительную информацию.
Для IT-команды это означает одно: часть ваших задач — не технические, а документарные и они имеют дедлайны, привязанные к календарю, а не к спринту.
2. Административный уровень
Приказы, политики, регламенты, матрица доступа, соглашения о конфиденциальности, приказ о назначении ответственного за ИБ. Здесь описывается, кто что имеет право делать и кто за это отвечает. Плохая новость: без этого уровня остальные четыре не проверяются — аудитору не с чем сравнивать факт.
3. Процедурный уровень
Самая недооценённая часть. Как выдаётся доступ новому сотруднику и как отзывается у уволенного за час, а не за три недели. Как проверяются резервные копии — восстановлением, а не наличием файла на полке. Как проводится управление изменениями, ревью прав раз в квартал и разбор инцидентов. Процедуры — это то, что превращает политику из PDF в работающий механизм.
4. Программно-аппаратный уровень
Собственно технические средства: IAM и MFA, EDR на конечных точках, WAF и сегментация сети, шифрование данных при передаче и хранении, SIEM для сбора событий, средства защиты информации из комплекта по приказу №17. Важно: каждый из этих инструментов даёт эффект только при наличии процедур из предыдущего пункта. SIEM без процесса реагирования — это очень дорогой сборник логов.
5. Физический уровень
Контроль доступа в серверную, опечатанные шкафы, защита от кражи ноутбуков, уничтожение носителей. Скучно ровно до момента, когда кто-то уносит диск с бэкапом в рюкзаке.
Принципы, которые действительно работают
Принципы — не лозунги для презентации совету директоров, а фильтры для решений. Вот те, что я видел работающими на практике:
- Системность. Защита — это связка люди — процессы — технологии. Дыра в любом звене обесценивает остальные: MFA не спасёт, если пароль от почты администратора лежит в общем чате.
- Разумная достаточность. Защита должна быть соразмерна ценности актива и вероятности угрозы. Шифровать публичный пресс-кит с тем же усердием, что и базу клиентов, — это трата бюджета, а не безопасность.
- Эшелонированная защита (defense in depth). Ни один контроль не должен быть единственным. Не сработал WAF — сработает сегментация; не сработала сегментация — сработает EDR и мониторинг.
- Минимальные привилегии. Каждый получает ровно те права, что нужны для задачи, и на нужный срок. Отдельный разговор — сервисные учётки и админский доступ: постоянный «root на всякий случай» — это не удобство, а отложенный инцидент.
- Разделение обязанностей. Разработчик не должен единолично выкатывать изменения в прод и отключать аудит. Две пары глаз там, где речь о деньгах и данных, — не бюрократия.
- Непрерывность и цикличность. Модель NIST Cybersecurity Framework 2.0 (2024) описывает шесть функций: Govern, Identify, Protect, Detect, Respond, Recover. Обратите внимание: защита — только один блок из шести. Управление, обнаружение и восстановление весят не меньше.
- Прослеживаемость. Логи нужны не для отчётности, а для ответа на вопрос «что произошло». Без них инцидент превращается в гадание, а разбор — в поиск виноватого.
От чего защищаемся: модель CIA и приоритизация
Классический каркас — конфиденциальность, целостность, доступность. К нему полезно прикрутить аутентичность (мы знаем, кто автор данных) и неотказуемость (автор не сможет отказаться от действия) — для юридически значимых систем это критично.
Дальше — простая цепочка, которую команда может пройти за один воркшоп: актив (что защищаем) → угроза (кто и как может навредить) → уязвимость (что позволяет это сделать) → последствие (деньги, простой, репутация, штраф). Риск на выходе = вероятность × ущерб. Всё, что не влезает в эту цепочку, в бюджет на защиту не попадает — и это нормально.
Кто за что отвечает в команде
- Разработка — безопасный код, работа с зависимостями, отсутствие секретов в репозитории, проверка входных данных.
- DevOps/эксплуатация — конфигурация по baseline, сегментация, патчи, бэкапы и их проверка, ротация ключей.
- Ответственный за ИБ — модель угроз, политики, контроль исполнения, коммуникация с регулятором.
- Руководитель — приоритеты, бюджет и готовность принять остаточный риск письменно.
Ключевой момент: безопасность — не отдел, который «придёт и проверит». Это свойство того, как команда проектирует и эксплуатирует системы.
Типичные ошибки
- Покупать SIEM/DLP до того, как есть процессы и владельцы этих процессов.
- Считать, что защита = антивирус и файрвол на периметре.
- Писать политику на 80 страниц, которую не читал никто, включая автора.
- Делать бэкапы и ни разу не восстанавливать их на чистом железе.
- Держать доступы «пока не разберёмся» — это самый популярный способ дожить до инцидента.
- Считать, что в облаке за вас всё защищено. За безопасность данных в облаке отвечаете вы, провайдер отвечает за физическую инфраструктуру.
Чек-лист первого месяца
- Составьте реестр активов: системы, данные, кто владелец.
- Отметьте, где лежат персональные данные и под какие требования вы попадаете.
- Опишите модель угроз хотя бы на 10 сценариев.
- Включите MFA на почте, VPN, админ-панелях и облаке.
- Проведите ревизию доступов и уберите тех, кому они больше не нужны.
- Настройте резервное копирование по правилу 3-2-1 и один раз восстановите из копии.
- Соберите логи критичных систем в одно место и назначьте, кто их читает.
- Заведите простой регламент реагирования: кому звонить, что фиксировать, кто решает.
- Проверьте, нет ли секретов и ключей в репозиториях и CI/CD.
- Зафиксируйте остаточные риски письменно — с датой пересмотра.
Вывод
Информационная защита — это не набор продуктов, а пять уровней, которые должны работать синхронно: закон задаёт рамку, политика — правила, процедуры — исполнение, средства защиты — автоматизацию, физика — последний барьер. Если хотя бы один уровень пустой, вся конструкция держится на энтузиазме конкретного человека.
Начните с реестра активов и модели угроз — это дешево, быстро и сразу показывает, где вы на самом деле уязвимы. Гораздо полезнее, чем ещё одна коробка с надписью «интеллектуальная защита».
