Информационная безопасность сегодня — это не только технологии, но и быстрая адаптация к меняющемуся ландшафту угроз и ожиданий бизнеса. Как бы это тревожно не звучало, но даже опытные ИБ-команды совершают критические ошибки: одни переоценивают возможности AI-инструментов, другие буксуют на внедрении Zero Trust или не находят общего языка с DevOps. Cyber Media разбирает самые частые промахи ИБ-отделов в 2025 году и как их избежать.
Содержание
Сейчас бизнесу ИИ кажется этакой палочкой-выручалочкой: автоматизировать, ускорить, сэкономить — и все это без боли интеграций. Руководители хотят, чтобы LLM помогал сотрудникам писать тексты, обрабатывать запросы клиентов, анализировать документы. Маркетинг — чтобы он сам делал презентации. HR — чтобы писал вакансии и FAQ. А вот ИБ в это время потеет.
ИИ-алгоритмы — особенно крупные языковые модели — это не просто «удобный бот». Это сложный и не всегда предсказуемый механизм, в который сотрудники заливают конфиденциальные данные, не задумываясь о последствиях. Под капотом — непонятный «черный ящик», который может как выдать гениальный ответ, так и случайно слить наружу чувствительную информацию.
ИБ-команды часто оказываются в роли догоняющих: бизнес уже начал внедрять, а политики, контроль, аудит — «допишем по ходу». И вот тут начинаются ошибки.
Андрей Жданухин
Руководитель L1 GSOC компании «Газинформсервис»
В 2025 году главная ошибка ИБ-отделов при использовании AI/LLM — это переоценка «умности» и недооценка рисков. Часто ИБ-инструменты на базе ИИ внедряются как «волшебная таблетка», но без полноценного понимания, как они работают, как обрабатывают данные, какие уязвимости могут принести.
Типовые ошибки:
- Передача чувствительных данных в публичные LLM-сервисы. Несмотря на запреты, в некоторых компаниях сотрудники все еще используют публичные чат-боты для генерации отчетов или анализа, передавая туда конфиденциальную информацию.
- Отсутствие механизмов аудита и валидации результатов ИИ. LLM может ошибаться, галлюцинировать или непредсказуемо интерпретировать ввод — и это не всегда выявляется вовремя.
- Слабая или отсутствующая модель угроз ИИ-инфраструктуры. Многие ИБ-отделы пока не рассматривают LLM как часть поверхности атаки (attack surface), хотя векторы атак (от prompt injection до data poisoning) уже эксплуатируются на практике.
Лучшие практики:
Проблема в том, что ИБ-специалисты часто и сами не до конца разбираются в особенностях работы LLM — просто потому, что технологии развиваются быстрее, чем регламенты. Пока отделы безопасности пишут политики и разрабатывают подходы к контролю, бизнес уже активно экспериментирует: кто-то подключает ChatGPT через API, кто-то разворачивает open-source LLM в контейнерах, а кто-то — просто просит сотрудников «пробовать, но аккуратно».
Илья Поляков
Руководитель отдела анализа кода Angara Security
Еще один пробел — отсутствие четких правил использования: кто-то разрешает сотрудникам генерировать отчеты через ChatGPT, но не объясняет, какие данные можно вводить, а какие — категорически нет. В итоге получается «цифровая рулетка»: пока не случится инцидент, все считают, что система работает идеально. А когда приходят регуляторы с проверкой, выясняется, что ни политики, ни логов для аудита попросту нет.
Главная ошибка — откладывать включение ИБ в процесс до последнего. Даже если в компании пока нет стратегии по применению ИИ, это не значит, что ИБ может сидеть в стороне. Наоборот: чем раньше команда начнет задавать правильные вопросы — откуда берется модель, какие данные она видит, как происходит логирование, — тем меньше рисков вырастет потом.
ИИ — это не игрушка. Это часть инфраструктуры. А значит, она должна быть под контролем ИБ так же, как и любой другой критичный сервис.
Подход Zero Trust стал крайне модным в последние годы: никто не доверен по умолчанию, доступ — только по минимально необходимому, каждый запрос — под контролем. В теории звучит убедительно, особенно на конференциях и в презентациях. Но на практике многие компании сталкиваются с тем, что идеальная архитектура либо не приживается, либо быстро вырождается в избыточную бюрократию.
Михаил Кадер
Архитектор клиентского опыта будущего, UserGate
По моему мнению, чаще всего проблемы при внедрении Zero Trust связаны с несколькими основными вопросами:
- Нет точно сформулированного целеполагания, и именно — какие категории/роли пользователей на основании каких критериев/требований должны иметь доступ к каким ресурсам/приложениям?
- Разделение «островков» ответственности между несколькими подразделениям, например, ИБ/разные группы IT без формирования совместной команды, отвечающей за внедрение.
- «Слепые» зоны мониторинга и, поэтому потеря той части Zero Trust, которая отвечает за контроль происходящего во время взаимодействия.
- Техническая сложность построения решения. Даже в рамках подхода одного производителя решений, реализация Zero Trust состоит из нескольких продуктов, часто полученных в результате приобретения других компаний. Поэтому возникает много технических вопросов, связанных с интеграцией зоопарка продуктов между собой.
Основные ошибки при внедрении — чрезмерная централизация, упрощенные универсальные политики и игнорирование бизнес-логики. Например, все доступы начинают проходить через один узел, создавая точку отказа и снижая производительность. Или вводятся одинаковые правила для разных групп пользователей, вне зависимости от их задач, контекста и уровня риска. Это приводит к тому, что безопасность начинает мешать работе, а пользователи — искать обходные пути.
Максим Захаренко
СЕО «Облакотека»
Главная ловушка — внедрение ZT как продукта, а не как архитектурной философии. Закупили «Zero Trust firewall» — и думаем, что сделали все, что нужно. Нет, это так не работает. Без полноценного управления идентификацией, сегментацией сети, постоянного контроля поведения пользователей это все будет фикцией.
Еще, по моим наблюдениям, есть сильное сопротивление на уровне бизнеса: «Зачем вы все усложняете, у нас и так безопасно». Многим непонятно, что Zero Trust требует внедрения в культуру, что для этой технологии важны постоянная проверка, обучение сотрудников, гибкие сценарии доступа, наконец, прозрачность.
Что действительно работает:
Сам подход ценен, но требует аккуратного внедрения, трезвой оценки и регулярной адаптации. В противном случае вместо повышения безопасности можно получить ухудшение управляемости и сопротивление со стороны ключевых сотрудников.
DevOps всегда был про скорость: быстро писать, собирать и выкатывать в прод. А вот ИБ традиционно была про контроль, медленные проверки и стоп-кран. И когда эти два мира сталкиваются, все чаще слышится знакомое: «Мы бы рады подключить ИБ пораньше, но тогда все встанет».
На словах все за shift-left — мол, проверять безопасность нужно еще на этапе кода. Но на практике это «лево» почему-то наступает уже после деплоя, когда баг уже в проде, а угрозы — в системе. Основная ошибка — запоздалая интеграция ИБ в процессы. Безопасность подключается в последний момент, когда уже ничего нельзя изменить, а можно только сказать: «ну, вообще так нельзя было делать».
Алексей Ахмеев
Руководитель управления информационной безопасности и цифровизации Moneyman
Самая распространенная ошибка — не выделение на организацию процесса безопасной разработки отдельного штата специалистов ИБ. Все, что касается разработки, — это сильно специфичная область и «взваливать» это на плечи методологов ИБ и администраторов СЗИ абсолютно неправильно. Необходимо собирать штат специалистов, умеющих работать как с кодом (искать ошибки), так и с готовым продуктом — проводить «взломы» готовых приложений.
Также нужно купить специализированное ПО, чтобы иметь возможность проводить тесты кода и готового продукта. Также необходимо не забывать, что для организации процесса безопасной разработки необходимо встроить в существующий процесс разработки дополнительные этапы, на которых будут работать эти специализированные средства и обученные люди. Обычно это становится очень сложной задачей для команд разработки и может замедлять процесс выпуска новых релизов, что не всегда нравится руководству компаний, поскольку может стать причиной потери конкурентного преимущества.
Еще одна проблема — непонимание самого процесса CI/CD. Многие ИБ-команды смотрят на пайплайн как на нечто чуждое: мол, опять айтишники накрутили. Из-за этого контроль строится вручную: чек-листы, согласования по почте, сканирование после релиза. В условиях DevOps это не просто неэффективно — это гарантированный технический долг.
Антон Конопак
Начальник отдела DevSecOps, «Инфосистемы Джет»
Чтобы избежать вышеупомянутых (и не только) проблем, всегда придерживайтесь следующих принципов:
- Внедрение безопасной разработки, DevSecOps — это процесс, общение и желание взаимодействовать между специалистами по информационной безопасности и IT (разработкой и эксплуатацией). Если нет желания взаимодействовать друг с другом, необходимо это желание «вызвать» и только совместными усилиями выстраивать безопасную разработку в компании.
- DevSecOps — это инструменты, люди и процессы. Если отсутствует хотя бы один из трех столпов, выстроить безопасную разработку в компании будет очень сложно. И если с инструментами и людьми все вполне очевидно, то о процессах безопасной разработки (их описании и внедрении) часто забывают.
- Необязательно изобретать велосипед: всегда можно использовать готовый фреймворк и придерживаться его. На его основе можно провести аудит разработки в своей компании, составить дорожную карту развития DevSecOps, выяснить, сколько людей нужно нанять и какие документы разработать. Вот примеры таких фреймворков: BSIMM, SAMM, DSOMM, ГОСТ 56939-2024 и DAF.
Безопасность не должна тормозить DevOps, но и DevOps не должен работать в изоляции. Чтобы shift-left заработал, ИБ должна стать частью команды — не наблюдателем, а полноценным участником, говорящим с разработкой на одном языке.
В информационной безопасности любят искать «серебряные пули». Чтобы одно решение — и всех победили: и злоумышленников, и закрыли требования регуляторов, и баги в коде. Но, увы, такого не бывает. Мир меняется быстрее, чем успевает обновиться политика доступа или настройка в SIEM. Поэтому вместо «универсального рецепта» приходится учиться жить в постоянной адаптации.
Не инструменты делают ИБ устойчивой, а подход. Он не зависит от вендора, но определяет, насколько вообще система живет в реальности, а не только в презентациях.
Первый — культура обучения. Когда команда ИБ постоянно учится — не только читать отчеты об атаках, но и понимать, как работает новая архитектура, что происходит в разработке, зачем бизнесу этот ИИ-стартап. Без этого ИБ просто не догоняет.
Второй — диалог с разработкой. Не в стиле «вы опять все сломали», а на равных. Когда ИБ может прийти на созвон и объяснить, почему эта библиотека — риск, а не просто «не понравилась». Когда разработка не боится, что после каждого коммита придет человек с красной кнопкой.
Третий — прозрачность процессов. Не должно быть магии. Если политики доступа непонятны самим пользователям, они их обойдут. Если процесс реагирования на инциденты — тайна за семью печатями, в момент ЧП начнется хаос. Прозрачность — это не про «всем все показывать», а про понятные правила, роли и обратную связь.
Так что универсального рецепта нет. Зато есть база, на которой можно выстраивать все остальное — от внедрения Zero Trust до безопасного DevOps. И да, это требует усилий. Но других вариантов у нас, честно говоря, нет.
Даже зрелые ИБ-отделы совершают ошибки — мир меняется быстрее, чем успевают обновиться регламенты. ИИ, DevOps, Zero Trust — это не просто модные слова, а зоны, где ИБ должна быть не на подхвате, а в первом ряду. Чем раньше вы включитесь в процессы, тем меньше рисков и доработок потом. Не ждите идеальных условий. Действуйте уже сейчас: с тем, что есть, и там, где особенно больно.
Эпоха «символических» выплат за утечки персональных данных официально завершена еще в прошлом году.
Контейнеризация стала стандартом де-факто для разработки, доставки и эксплуатации приложений.
Каждый день в интернете появляются тысячи новых уязвимостей — открытые порты, забытые тестовые серверы, утекшие пароли сотрудников.
Современные операторы связи сталкиваются с беспрецедентными вызовами: взрывном рост трафика, усложнением архитектуры сетей, участившиеся кибератаки и постоянно растущие ожидания абонентов от качества и непрерывности сервиса.
Развитие «Газинформсервиса» как вендора стало логичным этапом для компании.
Когда сервер взломан, первое, что приходит в голову администратору: «Как это произошло?
Веб-сервер это первая линия обороны любой инфраструктуры.
В условиях цифровой трансформации и роста числа кибератак контроль доступа к корпоративной сети становится критически важным элементом безопасности.
Инфраструктуры на базе Windows Server 2025 сейчас работают в условиях, когда атаки становятся все более автоматизированными и нацеленными на конкретные уязвимости конфигурации.
В седьмой раз в Москве прошло масштабное офлайн- и онлайн-мероприятие UserGate Open Conf 2026, объединившее ведущих разработчиков, регуляторов и крупнейших заказчиков ИБ-отрасли.
