Даже самые передовые технологии — ИИ, Zero Trust и DevSecOps — могут обернуться угрозой, если внедрять их без стратегии и понимания рисков. Ошибки, рождённые спешкой, превращают инновации в уязвимости. Но при зрелом подходе эти инструменты становятся опорой бизнеса, а не его слабым звеном.
- Введение
- Как эйфория от ИИ приводит к утечкам и искам
- Zero Trust: модные стикеры на старом заборе
- DevSecOps: когда безопасность не успевает за разработкой
- Выводы
Введение
Сфера кибербезопасности живёт в состоянии перманентной гонки вооружений. Но если раньше главной задачей было отстроить и укрепить периметр, то сегодня правила игры изменились. Искусственный интеллект, архитектура нулевого доверия и тесная интеграция с разработкой – это уже не футуристические концепции, а рабочие инструменты. Однако именно на этом новом поле боя даже опытные ИБ-команды наступают на одни и те же грабли, превращая прорывные технологии в источники головной боли и серьёзных уязвимостей. Эксперты Angara Security рассказали, где именно кроются самые распространённые ошибки и почему в 2025 году недостаточно просто купить новое технологическое решение.
Как эйфория от ИИ приводит к утечкам и искам
Повальное увлечение искусственным интеллектом и большими языковыми моделями (LLM) открыло для бизнеса невероятные возможности, но для ИБ-служб – ящик Пандоры. Как отмечает Илья Поляков, руководитель отдела анализа кода Angara Security, главная проблема заключается в том, что компании бросаются внедрять AI и LLM без какой-либо чёткой стратегии. Это приводит к хаотичному использованию мощнейших инструментов, которые в итоге не решают реальных задач, а лишь создают новые риски.
Например, многие в погоне за быстрым результатом игнорируют фундаментальный аспект – анализ качества данных, на которых будут обучаться или дообучаться модели. В итоге системы, на которые возлагались большие надежды, начинают выдавать ошибочные или предвзятые результаты, подрывая доверие к технологии. Другая типичная и очень опасная ошибка – недостаточное обучение сотрудников. Люди начинают воспринимать LLM как волшебный чёрный ящик, не вникая в принципы его работы. Они бездумно копируют в чаты с публичными моделями фрагменты внутренних документов, служебной переписки или кода, тем самым случайно «сливая» конфиденциальную информацию.
Особенно обидно, когда отделы тратят внушительные бюджеты на интеграцию, но совершенно забывают про финансовые риски. Нередко никто не отслеживает стоимость обработки запросов в облаке, из-за чего счёта за использование LLM-сервисов внезапно взлетают как на дрожжах.
Исследование компании Gartner прогнозирует, что к концу 2025 года до 80 % успешных атак на системы ИИ будут связаны именно с человеческим фактором и ошибками в операционных процессах, а не с прямым взломом алгоритмов. Главный риск, который, по словам Ильи Полякова, до сих пор недооценивают, – это утечка чувствительной информации. Достаточно одному сотруднику скопировать фрагмент внутренней переписки в диалог с ИИ, и эти данные попадают в чужие руки. В случае с открытыми, публичными моделями вернуть их будет уже невозможно.
Но есть и «скрытый минус» – юридические коллизии. Представьте, что LLM сгенерирует для вашей компании маркетинговый текст или фрагмент кода, который окажется пугающе похожим на материал, защищённый авторским правом. В таком случае компания рискует получить вполне реальный иск за плагиат.
При этом ИБ-команды крайне редко заранее оценивают, как новый ИИ-инструмент будет взаимодействовать с существующей ИТ-инфраструктурой. Слабые точки в API или незащищённые эндпоинты становятся идеальной мишенью для злоумышленников, но на это, как правило, обращают внимание только после успешной атаки.
Чаще всего упускается из виду необходимость выстраивания гибкой системы управления рисками. Многие полагают, что, купив «коробочное» решение, они раз и навсегда закроют все проблемы. Но реальность такова, что искусственный интеллект требует постоянного аудита – от скрупулёзной проверки входных данных до непрерывного мониторинга того, что модель выдаёт на выходе. Ещё один колоссальный пробел – отсутствие чётких и понятных правил использования.
Кто-то разрешает сотрудникам генерировать отчёты через ChatGPT, но не объясняет, какие данные можно вводить, а какие – категорически нет. В итоге работа с ИИ превращается в «цифровую рулетку»: пока не случится громкий инцидент, все уверены, что система работает идеально. А когда в компанию приходят регуляторы с проверкой, внезапно выясняется, что ни внутренних политик, ни логов для полноценного аудита попросту не существует.
Zero Trust: модные стикеры на старом заборе
Другая область, где благие намерения часто ведут к печальным последствиям, – это внедрение концепции Zero Trust (ZT, концепция «нулевого доверия»). В 2025 году, как и прежде, этот процесс сопровождается типичными ошибками, причём как на стратегическом уровне, так и в плоскости корпоративной культуры. По словам Дениса Бандалетова, руководителя отдела сетевых технологий Angara Security, ключевая проблема заключается в переоценке технологий и одновременной недооценке уровня организационной зрелости компании.
Концепцию «нулевого доверия» нередко воспринимают как готовый продукт, который можно просто купить и установить. Компании приобретают современные системы сетевого контроля доступа (NAC) или внедряют VPN с многофакторной аутентификацией (MFA), однако сама логика предоставления доступа остаётся прежней. Отсутствует главный элемент – постоянная контекстная проверка прав пользователей. Итогом становится всё тот же традиционный периметр безопасности, просто украшенный элементами современных решений – своего рода «old-school perimeter with trendy stickers».
По данным Forrester, около 65 % организаций заявляют о внедрении Zero Trust, но лишь 20 % достигли зрелого уровня реализации, подразумевающего полный отказ от модели доверенной сети. Действительно, многие организации, заявляя о переходе на Zero Trust, продолжают игнорировать его фундаментальный принцип – предоставление минимально достаточного доступа (least privilege). Они по-прежнему поддерживают избыточные привилегии для сотрудников и систем, наивно полагаясь на то, что средства защиты сами по себе решат все проблемы.
Это прямо противоречит идее ZT, согласно которой доступ должен предоставляться строго в рамках необходимых полномочий и постоянно перепроверяться. Специалисты по ИБ привычно сосредотачиваются на защите внешних границ инфраструктуры, но совершенно забывают о рисках горизонтального перемещения трафика внутри корпоративных сетей. Этот недосмотр особенно опасен в современных облачных средах и микросервисных архитектурах, где внутренние взаимодействия сложны и многообразны.
Невозможно построить архитектуру Zero Trust без кристально ясного представления о том, кто, когда и зачем имеет доступ к каким ресурсам. Однако зачастую внедрение систем управления доступом происходит на основании устаревших и неполных данных о существующем ИТ-ландшафте предприятия, что в рамках принципов ZT просто недопустимо. К техническим и стратегическим просчётам добавляется и человеческий фактор – сопротивление со стороны бизнес-подразделений и ИТ-служб. Пользователи часто считают, что новые правила безопасности замедляют их работу и создают лишние сложности, особенно если реализация концепции происходит без учёта реальных бизнес-процессов и без прозрачного объяснения целей.
Успешной реализации Zero Trust мешают и популярные заблуждения. Некоторые до сих пор верят, что «Zero Trust – это всего лишь MFA плюс VPN». Другие убеждены, что раз они работают в облаке, то принцип «нулевого доверия» у них реализован по умолчанию. Третьи считают, что ZT можно один раз внедрить и забыть.
Денис Бандалетов подчёркивает: важно понимать, что Zero Trust – это не однократный проект, а непрерывный процесс. Для его успешного функционирования необходима зрелая система идентификации и авторизации (IAM), регулярная ревизия назначенных полномочий, постоянный мониторинг поведения пользователей и, что самое главное, тесное сотрудничество между ИБ, IT и бизнесом. Только в рамках такого комплексного подхода любые, даже самые современные, средства защиты смогут полноценно реализовать свой потенциал.
DevSecOps: когда безопасность не успевает за разработкой
Третье поле битвы, где ИБ-команды регулярно терпят поражение на первых порах, – это интеграция практик безопасности в процессы DevOps и безопасной разработки. Как объясняет Виктор Дрынов, руководитель отдела безопасной разработки Angara Security, практически все компании сталкиваются здесь с рядом типовых проблем.
Согласно ежегодному отчёту GitLab по состоянию DevSecOps, 57 % разработчиков признаются: проверки безопасности по-прежнему проводятся слишком поздно, уже на поздних стадиях разработки, что приводит к конфликтам и срыву сроков. Безопасность пытаются «встроить» поверх процессов, что создаёт узкие места.
Самое главное из них – отсутствие выстроенного взаимодействия между командами. Безопасность должна стать неотъемлемой, органичной частью культуры DevOps и разработки в целом. Если же этого не происходит, а коммуникация и совместная работа отсутствуют, любые попытки интеграции обречены на провал. Эта проблема порождает следующую – нечёткое распределение ролей и обязанностей. Когда нет ясного понимания, где заканчивается зона ответственности специалиста по ИБ и начинается зона ответственности DevOps-инженера или разработчика, это неизбежно приводит к недопониманиям, конфликтам и дублированию усилий.
Ещё один критический момент – недостаточное внедрение автоматизации. Скорость является ключевой ценностью DevOps, и любые процессы безопасности, оставшиеся ручными, не способны соответствовать этому темпу. Они становятся «бутылочным горлышком», тормозят весь конвейер разработки и в конечном итоге либо игнорируются, либо саботируются. Наконец, часто полностью отсутствуют метрики для оценки эффективности внедряемых процессов безопасной разработки. Без чётко определённых и официально утверждённых показателей невозможно объективно оценить успешность принятых мер и выявить те области, которые нуждаются в улучшении.
Чтобы эффективно решать большинство этих трудностей, Виктор Дрынов советует подходить к процессу интеграции как к полноценному, серьёзному проекту. Это означает, что необходимо начать с определения всех заинтересованных сторон, провести тщательное планирование, рассчитать трудозатраты как со стороны ИБ, так и со стороны разработки. Важно формализовать взаимные обязательства, согласовать метрики эффективности и, что самое главное, чётко обозначить конечные цели всего проекта. Как показывает практика, эти цели далеко не всегда очевидны с самого начала, и их совместная проработка – уже половина успеха. Только такой системный и структурированный подход позволяет превратить безопасность из досадного барьера в естественную и эффективную часть всего цикла разработки.
Выводы
Главная угроза современной кибербезопасности — не в технологиях, а в людях и процессах, которые ими управляют. Искусственный интеллект и Zero Trust перестают быть инструментами защиты, когда их воспринимают как «волшебные кнопки». Любая инновация требует зрелости, дисциплины и постоянного контроля.
Эффективная защита строится не на закупке решений, а на формировании культуры осознанного взаимодействия между бизнесом, ИТ и ИБ. Лишь в этом случае новые подходы перестают быть красивыми лозунгами и превращаются в живую систему, где технологии действительно работают на безопасность, а не создают иллюзию контроля.
Авторы:
Виктор Дрынов, руководитель отдела безопасной разработки, Angara Security.
Илья Поляков, руководитель отдела анализа кода, Angara Security.
