Безпека ШІ не зламана, ми просто захищаємо не те

У кібербезпеці є шаблон: коли з’являється нова технологія, ми одразу починаємо будувати навколо неї стіни. Ми робили це з хмарою, робили з контейнерами, і зараз робимо зі ШІ, тільки цього разу стіни ми будуємо в абсолютно неправильних місцях.

Зайдіть сьогодні на будь-який огляд безпеки на підприємстві, і ви почуєте одні й ті самі пріоритети: захист моделей ШІ, захист навчальних даних, валідація вихідних даних та розгортання AI-копілотів. Постачальники поспішають продавати інструменти “безпеки ШІ”, які зосереджені виключно на контролі на рівні моделі, такі як захисні обмеження, захист від ін’єкцій запитів та платформи моніторингу моделей.

Але нападники використовують ваші інтеграції ШІ як швидкісні магістралі до всього іншого.

Справжня поверхня атаки, за якою ніхто не стежить

Одна закономірність, яку ми постійно спостерігаємо в корпоративних середовищах, розповідає тривожну історію про те, як команди безпеки інвестують значні кошти в захист своїх середовищ розробки ШІ: контроль доступу до моделей, фреймворки управління даними, інструменти безпеки MLOps. Це створює хибну впевненість, що їхній ШІ “надійно захищений”.

Але коли ви картографуєте реальну поверхню атаки, ви бачите, що AI-чати часто мають OAuth-токени до десятків SaaS-платформ, API-ключі з надмірними дозволами в хмарі та відносини довіри ідентичностей, які можуть створити прямі шляхи від простої ін’єкції запиту до виробничої інфраструктури. Самі моделі можуть бути захищені, але екосистеми, в яких вони існують, часто широко відкриті, і це не винятковий випадок.

Підприємства зараз використовують в середньому понад 130 SaaS-додатків, а інтеграції ШІ охоплюють провайдерів ідентичностей, хмарну інфраструктуру, бази даних та бізнес-критичні системи. Кожна інтеграція — це потенційний шлях атаки, а кожне API-з’єднання — це межа довіри, яку нападники активно досліджують.

Проблема не в тому, що наші інструменти безпеки ШІ зламані. Проблема в тому, що ми захищаємо окремі компоненти, поки нападники експлуатують зв’язки між ними.

Чому модель-центрична безпека не враховує суті

Нинішній підхід до безпеки ШІ ґрунтується на фундаментальному непорозумінні того, як працюють сучасні атаки. Ми ставимося до ШІ як до автономного активу, який потребує захисту, подібно до того, як ми захищаємо базу даних або веб-додаток. Але ШІ у виробничому середовищі не існує ізольовано. Це вузол у складному графі ідентичностей, дозволів, API та потоків даних.

Розгляньмо типове корпоративне розгортання ШІ. У вас є AI-агент з доступом до вашого Google Workspace. Він підключений до Salesforce через API. Він інтегрований зі Slack для сповіщень. Він отримує дані з AWS S3-кошиків. Він автентифікований через Okta або Azure AD. Він запускає робочі процеси в ServiceNow.

Традиційна безпека ШІ зосереджена на самій моделі: її стан безпеки, валідація запитів, безпека вихідних даних. Але нападники зосереджені на інтеграціях: до чого вони можуть дістатися через скомпрометовані сервісні акаунти, куди можуть перейти через маніпуляції з API, які межі довіри можуть перетнути через експлуатовані інтеграції.

Атака не починається і не закінчується моделлю ШІ. Модель — це лише точка входу.

Шляхи атаки не поважають меж продуктів

Ось де більшість організацій застрягають. Вони розгорнули інструменти безпеки, кожен з яких забезпечує видимість у одній області. Один інструмент моніторить хмарні дозволи. Інший відстежує конфігурації SaaS. Третій керує управлінням ідентичностями. Четвертий займається управлінням вразливостями.

Кожен інструмент показує вам свою частину головоломки. Жоден з них не показує, як ці частини з’єднуються.

За даними Gartner, організації зараз використовують в середньому понад 45 інструментів безпеки. Проте, незважаючи на ці значні інвестиції, нападники успішно об’єднують ланцюжками неправильні конфігурації в цих областях, тому що жоден окремий інструмент не може бачити повний шлях атаки.

Нападнику не потрібно знаходити критичну вразливість у вашій моделі ШІ. Їм просто потрібно знайти ланцюжок. Можливо, це неправильно налаштована роль IAM, прикріплена до вашого сервісу ШІ, яка має дозволи на доступ до S3-кошика, який містить облікові дані до SaaS-додатка, що має адміністративний доступ до вашого виробничого середовища.

Кожна окрема неправильна конфігурація може отримати оцінку “середня” або “низька” у ваших інструментах безпеки. Але об’єднані в ланцюжок? Це критична загроза. І вона абсолютно невидима, якщо ви дивитеся на кожну область безпеки ізольовано.

Імператив управління загрозами

Ось чому дискусія має зміститися з “безпеки ШІ” на постійне управління загрозами для середовищ з інтеграцією ШІ.

Недостатньо запитувати, чи наші моделі ШІ захищені. Командам безпеки потрібно розуміти, до чого нападник насправді може дістатися, якщо скомпрометує сервісний акаунт ШІ. Їм потрібна видимість того, як неправильні конфігурації в хмарних, SaaS та системах ідентичностей можуть бути об’єднані в ланцюжок. Їм потрібно знати, як інтеграції ШІ змінюють їхню поверхню атаки в реальному часі. І їм потрібно розставляти пріоритети ризиків на основі реальної можливості атаки, а не просто оцінок серйозності.

Більшість програм безпеки досі розставляють пріоритети ризиків ізольовано, використовуючи оцінки CVSS та контрольні списки відповідності, які повністю ігнорують, чи є вразливість насправді експлуатованою у вашому конкретному середовищі.

Ця прогалина ще більш виражена в системах ШІ, тому що вони постійно змінюються. Нові інтеграції додаються щотижня. Дозволи еволюціонують. API-з’єднання змінюються. Ваша поверхня атаки місячної давнини — це не ваша поверхня атаки сьогодні, але ваша оцінка безпеки, ймовірно, саме така.

Як насправді виглядає безпека з обліком шляхів атаки

Захист ШІ у виробничому середовищі вимагає принципово іншого підходу, і він зводиться до чотирьох ключових змін у мисленні.

По-перше, вам потрібна об’єднана видимість у різних областях безпеки. Припиніть вимагати від кожного інструменту безпеки працювати у власній “силосній вежі”. Ваші інструменти хмарної безпеки, управління ідентичностями, управління SaaS та сканування вразливостей містять частини головоломки шляху атаки. Вони повинні ділитися даними в реальному часі, щоб ви могли бачити, як неправильні конфігурації об’єднуються в ланцюжок.

По-друге, прийміть постійне моделювання шляхів атаки. Не чекайте пентестів або вправ “червоних команд”, щоб виявити експлуатовані шляхи. Постійно тестуйте, як нападник міг би пересуватися вашим середовищем, фокусуючись на реальній експлуатабельності, а не покладаючись на теоретичні оцінки серйозності.

По-третє, розставляйте пріоритети на основі контексту. Неправильно налаштований S3-кошик не є критичним лише тому, що він публічний. Він критичний, якщо він публічний, містить облікові дані, ці облікові дані мають привілейований доступ, і до них можна дістатися з активу, доступного з інтернету. Контекст важливіший за будь-яку окрему оцінку.

По-четверте, рухайтеся до превентивного усунення загроз. До того часу, коли ваша команда SOC розслідує сповіщення, ви вже втратили цінний час на реагування. Сучасна оборона вимагає можливості закривати експлуатовані шляхи до того, як вони будуть використані, а не після інциденту.

Попередження, яке ми не можемо ігнорувати

Оскільки ШІ впроваджується на кожному рівні корпоративного стеку, поверхня атаки розширюється швидше, ніж команди безпеки можуть вручну її аналізувати. Ми додаємо інтеграції ШІ в 10 разів швидше, ніж захищаємо їх.

Якщо ви захищаєте ШІ ізольовано, захищаючи модель та ігноруючи екосистему, в якій вона працює, ви вже відстали. Нападники не думають інструментами, вони думають шляхами. Вони не експлуатують окремі вразливості. Вони об’єднують в ланцюжок неправильні конфігурації у всьому вашому середовищі.

Підприємства, які успішно захистять ШІ, будуть не тими, у кого найбільше інструментів безпеки ШІ. Це будуть ті, хто розуміє, що безпека ШІ нерозривно пов’язана з управлінням загрозами на всій їхній поверхні атаки.

Безпека моделі — це базовий мінімум. Важливо розуміти, до чого нападник може дістатися, коли скомпрометує інтеграцію ШІ. Поки команди безпеки не зможуть постійно, в реальному часі, давати відповідь на це запитання для всього свого середовища, вони не захищають ШІ. Вони просто сподіваються, що стіни, які вони побудували, знаходяться в правильних місцях.