изображение создано нейросетью
IT-World изучил, какие ошибки чаще всего допускают ИБ-отделы и как избежать подобных просчетов. erid: 2W5zFJYaMVa
ООО Тантор Лабс Реклама
Содержание:
AI и LLM: скорость, цена и новая ответственность безопасности
Интеграция LLM в эксплуатацию и безопасность перестала быть экспериментом — это инструмент ускорения и снижения когнитивной нагрузки. Но чем быстрее мы внедряем LLM, тем заметнее становится слабое звено — безопасность. В 2025 году ИБ-отделы все еще допускают критические ошибки: делятся логами с внешними сервисами, используют общие токены, не маскируют данные. Прежде чем говорить об ошибках, посмотрим, что уже реально дают LLM-компоненты бизнесу и ИБ-командам:
Даже при затратах на серверы и лицензии эффект эквивалентен 1,5–2 ставкам инженеров — и достигается без потери управляемости. Но чем выше скорость, тем строже должна быть рамка безопасности: LLM видит все, что ему показывают.
Ошибки и последствия
Главная ошибка 2025 года — воспринимать LLM как «умного помощника», а не как инфраструктуру обработки данных и идентичностей. Типовыми сбоями являются:
Разработка
Команды тестируют LLM на боевых выгрузках — в сессиях оказываются не только персональные данные, но и фрагменты кода, конфигурации, скрипты миграций, SQL-запросы и ключи API.
ИИ в кибербезопасности
Эти артефакты легко становятся публичными: так, в 2025 году тысячи чатов ChatGPT, помеченных пользователями как «shareable», были проиндексированы Google и Bing — с фрагментами кода, перепиской и внутренними инструкциями. Отечественная альтернатива Oracle Exadata: машины баз данных Tantor XData ИИ в мониторинге: не фантастика, а реальная потребность Артем Шейкин: «Ключ к обмену инцидентами — правовые гарантии»
Подобные случаи показывают: утечка через LLM — это не только риск ПДн, но и раскрытие архитектуры продукта.
Эксплуатация
Инженеры эксплуатации используют LLM для генерации скриптов и анализа логов, не замечая, что в промптах содержатся внутренние IP, имена сервисов и конфигурации. Prompt-инъекция способна извлечь токены мониторинга или переменные окружения — и дать атакующему легальный доступ.
Кейс: аварийная выгрузка логов в облако
Во время инцидентов эксплуатация часто действует «по горячему» — выгружает логи в публичные облака или подключает внешние LLM-сервисы (ChatGPT, Copilot, API). В логах при этом оказываются внутренние адреса, конфигурации, фрагменты кода, ключи и данные клиентов.
Весной 2025 года несколько финтех- и SaaS-компаний потеряли инфраструктурные данные именно так: при сбое техподдержка отправляла архивы логов во внешние модели без маскировки. В результате в открытом доступе оказались цепочки вызовов микросервисов, параметры подключения к БД и реальные ID клиентов. Этот кейс показал: скорость без встроенной защиты превращается в канал утечки, а ответственность здесь лежит не на людях, а на архитектуре.
ИБ-подразделения
Попытка «все запретить» дает обратный эффект — сотрудники продолжают пользоваться ИИ скрытно, без аудита и контроля. Возникает теневой контур, где риски уже не видны. Читайте также
Артем Шейкин: «Ключ к обмену инцидентами — правовые гарантии» Тема кибербезопасности все чаще звучит не только на ИТ-форумах, но и в законодательных дискуссиях. Сенатор Артем Шейкин, первый заместитель председателя Комитета Совета Федерации по конституционному законодательству и государственному строительству, считает, что цифровое регулирование должно развиваться так же быстро, как технологии, но без избыточного давления на бизнес и граждан. IT-World обсудил с ним, как выстраивается баланс между гибкостью и контролем, почему доверие к искусственному интеллекту требует четких правил и каким может быть законодательство в наше время.
Риски и нейтрализация
Вместе с ростом эффективности LLM-компоненты принесли и новые уязвимости. Чтобы использовать их безопасно, важно понимать ключевые риски и способы их нейтрализации.
Риск 1. Утечка данных и кода
В сессиях оказываются конфиги, SQL-запросы, ключи API — фактически карта инфраструктуры.
Риск 2. Компрометация токенов
Prompt-инъекция или уязвимость SDK позволяет вытянуть ключ и зайти в систему «как свой».
Риск 3. Провайдер как угроза
Владелец облачной модели видит контексты и метаданные; при злонамеренном использовании это вектор атаки.
Риск 4. Непрозрачность и зависимость
Неясно, где физически обрабатываются данные и кто имеет к ним доступ.
Как нейтрализовать:
Эталонная архитектура: безопасный ИИ-контур
Для того чтобы снизить риски и сохранить скорость внедрения, безопасность должна быть не надстройкой, а частью архитектуры. Ниже — принципы построения эталонного ИИ-контура, в котором защита встроена в каждый уровень системы.
1. Локальные модели
Разворачиваются в изолированных VPC- или on-prem-контурах; доступ по mTLS и OIDC; все модели (YaGPT, GigaChat, FRED AI, GPT-4 Private) подписаны и версионированы.
2. Policy-gateway
Фильтрует промпты, удаляет токены и PII, блокирует опасные цепочки; журналирует все запросы для аудита.
3. Разделенные хранилища логов и событий
Трехуровневая схема доступа:
Маскирование производится на уровне агента, до попадания в брокер. Поля PII заменяются на необратимые идентификаторы, чтобы LLM-агенты сохраняли контекст без реальных значений. Читайте также
Артем Калашников: «Уровень защиты определяется самым слабым звеном» В информационной безопасности больше нет внутренних тем. От зрелости подрядчиков до поведения сотрудников — все напрямую влияет на устойчивость бизнеса. Компании выстраивают доверие внутри экосистем, ищут баланс между контролем и удобством, осторожно пробуют ИИ и пересматривают отношение к open source. Известный эксперт по кибербезопасности Артем Калашников объясняет IT-World, почему ИБ должна проектироваться вместе с бизнесом, что мешает автоматизировать контроль и как культура становится реальным инструментом, а не лозунгом.
4. Emergency Mode
При аварии включается аварийный профиль: разрешен доступ к техническим логам определенного сервиса; все действия фиксируются и закрываются после восстановления.
5. Инцидент-менеджмент
Потоки «авария» и «инцидент безопасности» разделены; дежурная связка эксплуатации и ИБ; все сессии и доступы записываются.
6. Метрики зрелости
Требования к ИБ нового типа
По моему мнению, важно сразу оговориться: речь идет об идеальном контуре ИБ — о целевом состоянии, к которому стоит стремиться. Такой контур сегодня редкость, но именно он задает направление зрелости отрасли. ИБ будущего — не надстройка, а ткань бизнеса, вплетенная в процессы, продукты и управленческие решения. Она не тормозит — она удерживает систему в равновесии между скоростью, ответственностью и доверием. Определим главные требования к ИБ нового типа.
1. Безопасность как слой архитектуры
ИБ — не «служба контроля», а архитектурный слой, на котором держится доверие. Она формирует границы среды, где можно действовать быстро, не разрушая систему. Зрелая безопасность проектирует маршруты, по которым бизнес движется безопасно сам — без ручных разрешений и «бумажных согласований». Это не отдельный «блок» в оргструктуре, а часть инженерного ландшафта, встроенная в саму логику работы.
2. Встроенность в производственный поток
Безопасность должна быть частью жизненного цикла продукта — от замысла и дизайна до тестирования и эксплуатации. Security-review, ревью промптов, контроль ключей, mask-фильтры и SBOM-цепочка — не отдельные проверки, а естественные этапы пайплайна. ИБ не приходит «после», чтобы проверить, — она живет «вместе», чтобы предотвратить. Так рождается безопасность, которая масштабируется без потери скорости и смысла.
3. Совместная ответственность
Встроенная безопасность невозможна без общего владения процессом. Архитекторы, разработчики, эксплуатация и ИБ работают в едином ALM-контуре, с общими SLA и единым временем реакции. Никто не может сказать: «я только проверял». Каждый несет часть институциональной ответственности — и в этом проявляется настоящая субъектность организации.
4. От страха — к зрелости
Пока безопасность управляется страхом, она парализует. Когда ею управляет зрелость, она удерживает систему от хаоса. Современная ИБ допускает ошибку, но делает ее обратимой: временный аварийный доступ с аудитом, маскирование, разделенные хранилища логов. Это не про контроль — это про возможность действовать без разрушения доверия. Безопасность не блокирует решения, она делает их осмысленными и управляемыми.
5. От защиты — к созиданию
ИБ становится частью стратегии продукта, а не его внешним ограничителем. Она помогает внедрять ИИ, формировать цифровую этику, управлять рисками идентичности. Это не оборона бизнеса, а форма его устойчивого роста. Безопасность, встроенная в архитектуру, превращается в конкурентное преимущество — признак зрелости и институциональной надежности.
Таким образом, если ИБ осталась в прошлом — все профиты ИИ сгорают в рисках. По сути, идеальный контур ИБ — это реализация принципа жизнеспособной системы. Она не сопротивляется изменениям, а адаптируется к ним, сохраняя форму и смысл. Безопасность, встроенная в ткань бизнеса, — это и есть проявление управленческого гомеостаза: способности оставаться живой, когда все вокруг ускоряется.
Журнал IT Expert
Евгений СеменовЗаместитель генерального директора Центра биометрических технологий (ЦБТ)Информационная безопасностьИскусственный интеллект (ИИ, AI)Машинное обучение