23.03.2025
1 хв
1397
У статті пояснюється, як зовнішні тексти, документи та веб-контент можуть містити невидимі для людини команди, що впливають на відповіді ШІ, та чому ця малопомітна вразливість поступово перетворюється на один із головних викликів для безпеки генеративних технологій.
Швидке впровадження є однією з найактуальніших проблем, з якими стикаються найсучасніші моделі генеративного штучного інтелекту (GenAI). Національний центр кібербезпеки Великої Британії (NCSC) позначив це як критичний ризик, тоді як Національний інститут стандартів і технологій США назвав це «найбільшою вадою безпеки генеративного штучного інтелекту». Простіше кажучи, швидке впровадження відбувається , «коли зловмисник маніпулює великою мовною моделлю (LLM) за допомогою спеціально створених вхідних даних, змушуючи LLM несвідомо виконувати наміри зловмисника», як це формулюється в Open Worldwide Application Security Project. Це може призвести до маніпуляцій з прийняттям рішень системою, поширення дезінформації серед користувача, розкриття конфіденційної інформації, організації складних фішингових атак та виконання шкідливого коду.
Непряме впровадження запиту — це вставка шкідливої інформації в джерела даних системи GenAI шляхом приховування інструкцій у даних, до яких вона отримує доступ, таких як вхідні електронні листи або збережені документи. На відміну від прямого впровадження запиту, воно не вимагає прямого доступу до системи GenAI, натомість створює ризик для всього діапазону джерел даних, які система GenAI використовує для надання контексту.
Коли система GenAI отримує доступ до електронної пошти, особистих документів, знань організації та інших бізнес-додатків, значно зростає можливість впровадження зловмисної дезінформації шляхом непрямого впровадження з використанням прихованих інструкцій. Багато організацій усвідомлюють ризик дезінформації на основі GenAI, але намагаються ним керувати. McKinsey повідомила про неточність як про найважливіший ризик GenAI для організацій, охоплених її Глобальним опитуванням, і все ж лише 38% цих організацій працювали над пом’якшенням цих ризиків.
Ключовий компонент прихованих інструкцій полягає в тому, що помічник GenAI не зчитує дані так, як це робить людина. Це дозволяє розробляти надзвичайно прості методи введення, які невидимі для людського ока, але є центральними для процесу пошуку даних системою GenAI. У поєднанні з діапазоном методів введення, доступних помічнику GenAI, таких як електронні листи, документи та зовнішні веб-сторінки, область атаки є широкою та різноманітною.
Відповідальне впровадження системи GenAI вимагає належного зниження ризику непрямого оперативного впровадження даних шляхом контролю якості даних, свідомого управління доступом до даних, чіткого навчання користувачів безпечному використанню інструментів та постійного моніторингу для виявлення підозрілої поведінки.
Останніми роками спостерігається вибухове зростання використання GenAI організаціями. У липні 2024 року Statista виявила , що 75% співробітників підприємств використовували GenAI у своїй роботі; 46% з них впровадили GenAI протягом попередніх шести місяців. Усі основні варіанти використання – від маркетингу до управління персоналом та управління даними – залежать від доступу до бази знань бізнесу для ефективності. Дійсно, великі постачальники, такі як Microsoft, Google та Amazon, випустили продукти, що обіцяють підключити LLM до даних організації. На конференції Microsoft за другий квартал повідомили , що понад 10 000 компаній вже інтегрували CoPilot у свої програми Microsoft 365.
Підготовка спеціаліста з магістратури права (LLM) пов’язана з довгим списком накладних витрат. Згідно з прогнозом Міжнародного енергетичного агентства до 2026 року, річне споживання енергії центрами обробки даних зрівняється або перевищить споживання енергії Японією. Модель LLaMA 3.1-405B компанії Meta вимагала кластера з понад 16 000 графічних процесорів H100 для обчислень, що принесло Nvidia 30 мільярдів доларів. Очікується, що загальні витрати на масштабування LLM перевищать 1 трильйон доларів до кінця 2032 року.
Методи управління ресурсами (LLM) потребують чітких варіантів використання, щоб виправдати такі інвестиції. Вбудовування LLM у системи, що включають контекстну інформацію організації, є одним із шляхів для цього. Зазвичай, спираючись на систему під назвою Retrieval-Augmented Generation (RAG), системи RAG+LLM функціонують, приймаючи початковий запит користувача до системи, звертаючись до підключених джерел даних (наприклад, сховищ документів, баз даних, інтернет-сервісів та електронної пошти) та отримуючи найбільш релевантну контекстну інформацію. Потім вона надається LLM як частина його запиту в поєднанні з початковим запитом користувача та дозволяє LLM відповідати так, ніби він розуміє дані організації.
У прагненні до кращої продуктивності, готові системи за замовчуванням інтегруються в кілька корпоративних програм. Наприклад, корпоративні версії Microsoft CoPilot та Google Gemini мають доступ до електронної пошти, сховищ документів та вхідного інтернет-трафіку.
Хоча це може забезпечити вражаючу функціональність, це також створює очевидний ризик. Якщо зловмисник може вставити інформацію в будь-яке з наданих джерел даних, не попереджаючи користувача, який запитує, він може вплинути на поведінку системи RAG+LLM через контекст, який вона використовує. На базовому рівні можливо повністю зупинити відповідь системи. Більш тонкі атаки можуть перешкодити системі відповідати на запити, пов’язані з певними ключовими термінами. На вищому рівні зловмисник може використовувати непряме впровадження запиту для виконання шкідливого коду, впровадження дезінформації або повернення неправильних банківських реквізитів.
Крім того, системи GenAI схильні до галюцинацій, які виникають, коли LLM фальсифікує інформацію. Наприклад, чат-бот Bard від Google стверджував , що космічний телескоп Джеймса Вебба зробив перші у світі зображення планети за межами нашої Сонячної системи. Один зі способів зменшити ризик галюцинацій – використовувати організаційний контекст як точку відліку. Але це підвищує ризик непрямого впровадження інформації, оскільки може впровадити дані зі скомпрометованих електронних листів, документів і баз даних у відповіді системи GenAI.
Зрештою, існують пов’язані з цим проблеми у навчанні користувачів GenAI. Системи GenAI надають застереження про те, що деяка інформація, яку вони надають, може бути неправдивою, і відповідно посилання необхідно перевіряти. Однак у ці посилання можна вставляти фішингові посилання. У цьому випадку навчання користувача взаємодії із системою GenAI може суперечити його навчанню виявленню та уникненню шкідливих посилань.
Наведені нижче тематичні дослідження вносять свій вклад у літературу про можливі результати непрямого введення запитань. Ми поєднуємо це з простим механізмом, який ми виявили для обфускації великих обсягів тексту для читача електронної пошти або документа, водночас забезпечуючи доступність тексту для контекстного вікна програми LLM. (Про цей механізм було повідомлено NCSC.) Тематичні дослідження висвітлюють ризики, пов’язані з нездатністю користувача перевірити інформацію, що надходить від вбудованого LLM.
Метод обфускації даних для користувача однаковий у кожному з цих прикладів і не вимагає прямої маніпуляції з метаданими. Він не обмежений обсягом тексту, політикою безпеки за замовчуванням або кольоровою темою користувача, як це відбувається у випадку підходу, що базується на малому розмірі шрифту або білому тексті.
З огляду на те, що Microsoft та Google є двома найбільшими у світі постачальниками послуг електронної пошти, не дивно, що і CoPilot, і Gemini розроблені для доступу до електронних листів та їх узагальнення за замовчуванням. Спираючись на приклад, наведений на BlackHat USA 2024, ми показуємо, як електронні листи можна використовувати як шлях до бази знань користувача. Завдяки цьому ми можемо редагувати відповідь асистента на запит адрес електронної пошти або банківських реквізитів.
Документи є важливими для забезпечення ефективного контексту для систем RAG+LLM, особливо у великих організаціях. Більше того, документи дозволяють здійснювати широкий спектр атак з використанням ін’єкцій, оскільки вони не тільки містять набагато більше даних, ніж типовий електронний лист, але й часто доступні групам людей через хмарні сховища документів, такі як SharePoint та Google Диск. Тут ми показуємо, як впровадження дезінформації через обфусковані дані у збережений документ може призвести до того, що CoPilot перекручуватиме позицію організації щодо юридичної відповідальності та повторюватиме дезінформацію, коли його просять скласти лист-домовленість.
Відмова в обслуговуванні (DoS) становить загрозу для організацій, які мають намір покладатися на системи GenAI для виконання критично важливих завдань, таких як підтримка клієнтів та модерація контенту, або як джерело прийняття рішень. Непряме впровадження запиту дозволяє цілеспрямовану форму DoS. Замість того, щоб повністю знижувати продуктивність системи, воно натомість впроваджує шкідливу інформацію, яка запускає захисні механізми системи, змушуючи її відповідати відповіддю «Я не можу з цим допомогти» на загальний запит. Ці атаки можуть бути спрямовані на певні ключові слова та запити, що ускладнює їх відстеження, оскільки система, здається, функціонує нормально поза цими запитами.
Щоб усунути ризик непрямого впровадження даних, організаціям необхідно підтримувати належну гігієну даних, оцінювати системи перед розгортанням, проводити навчання користувачів та впроваджувати технічні запобіжні заходи. Кожна з цих стратегій відіграє важливу роль у забезпеченні безпеки та стійкості інструментів GenAI.
Ефективне внутрішнє управління даними є важливим під час впровадження інструментів на базі штучного інтелекту, таких як Microsoft CoPilot, Gemini та Amazon Q. Належна гігієна даних виходить за рамки простої організації та зберігання даних; вона також гарантує, що дані, до яких має доступ система штучного інтелекту, добре регулюються та захищені.
Багато традиційних практик управління даними застосовуються до запобіжних заходів проти непрямого впровадження даних. Найважливішим першим кроком є відокремлення будь-яких даних, що надходять до системи організації, від зовнішніх джерел, таких як електронна пошта. Наприклад, непрочитані електронні листи не повинні надходити до сховища даних для отримання, доки їх не перегляне або не прочитає авторизований користувач. Впровадження процесу затвердження нових даних, що надходять до сховища даних або системи RAG, допомагає створити захист, який обмежує потенційний вплив шкідливого контенту на всю систему.
Профілі співробітників для сховища даних також допомагають, гарантуючи, що певні користувачі матимуть доступ лише до даних, що стосуються їхньої роботи. Це зменшує масштаби шкоди, спричиненої атакою швидкого впровадження через скомпрометований документ, оскільки вона вплине лише на користувачів, яким потрібен доступ до цього документа; інші в організації не можуть отримати шкідливий контекст.
Крім того, організаціям слід уникати введення даних електронної пошти до сховища даних з адрес, що перебувають у чорному списку, або інших ненадійних адрес електронної пошти. Це допомагає обмежити вплив невідомих ризиків на конфіденційні системи. Організаціям також слід застосовувати засоби контролю до типів документів, що дозволяють прихований текст (наприклад, документи MS Word), та типів файлів, які можуть містити довільний код, наприклад, файли pickle (формат файлу, який зазвичай використовується для стиснення даних під час кодування на Python).
Оцінка будь-якої програми на базі штучного інтелекту перед розгортанням має бути автоматизованим або напівавтоматизованим процесом, щоб забезпечити узгодженість застосованих стандартів та створити чіткий шлях до керованого розгортання. Ця оцінка повинна використовувати постійно оновлювану базу даних стратегій атаки непрямого впровадження запитів, які використовують різні типи документів (наприклад, .doc, .pdf та .png); методи маскування (наприклад, прихований текст у документах Word та білий текст на білому фоні); та точки входу (наприклад, електронна пошта із зовнішніх джерел та прямий доступ до сховища документів як внутрішня загроза).
Процес оцінки перед розгортанням також повинен включати створення інтерфейсу для тестування застосунку – або шляхом взаємодії з базовими інтерфейсами прикладного програмування, або шляхом безпосереднього тестування інтерфейсу користувача за допомогою автоматизованих інструментів. Розрахувавши рівень успішності атаки, організації можуть бути впевнені в безпеці свого застосунку на базі штучного інтелекту, перш ніж розгортати його ширше.
Навчання користувачів має вирішальне значення для зменшення ризиків безпеки, пов’язаних із застосунками на основі штучного інтелекту, такими як Microsoft CoPilot. Більшість організацій проводять навчання з виявлення фішингових атак через електронну пошту, але навчання, спеціалізоване для ШІ, може допомогти співробітникам зрозуміти додаткові ризики безпеки, що виникають через ці інструменти. Це покращить їхнє розуміння того, як працюють моделі ШІ, вразливостей, які вони створюють, та того, як можна замаскувати шкідливі підказки.
Навчальні програми також повинні наголошувати на важливості перевірки інформації, створеної штучним інтелектом, та сприяти здоровому скептицизму щодо вбудованих посилань, неочікуваних даних та інших можливих артефактів, які можуть становити зловмисні ризики.
Введення природної мови в моделі ШІ робить непряме впровадження підказок таким ефективним. Це означає, що немає чіткого розмежування між інструкцією завдання, наданою базовому ШІ, та даними, отриманими зі сховища даних, необхідними для відповіді на запитання. Зловмисники використовують відсутність розмежування, вставляючи інструкцію в сховище даних, яка може ввести ШІ в оману.
Технічне рішення для зменшення цього може включати впровадження процесу оцінки — механізму, який сканує будь-які дані, отримані з бази даних, на наявність тексту, який може бути інтерпретований як інструкції, а не як дані. Якщо такий текст знайдено, його можна або позначити для перевірки, або відфільтрувати, перш ніж штучний інтелект включить його до згенерованої відповіді. Цей додатковий рівень перевірки може допомогти зменшити ймовірність того, що шкідливі інструкції потраплять у контекст запиту та спричинять проблему безпеки.
Непряме впровадження запиту є значним ризиком у широкомасштабному впровадженні RAG-систем, таких як Microsoft CoPilot, Google Gemini та Amazon Q. Хоча можливість застосовувати складні LLM до відповідних внутрішніх даних організації може підвищити продуктивність, вона також ризикує ненавмисно впровадити новий клас вразливостей. З огляду на швидкий розвиток цих систем, організації, які прагнуть їх впровадити, повинні включити найкращі практики безпеки та відповідне навчання користувачів у свої процеси розгортання. В іншому випадку вони ризикують наразитися на зовнішні маніпуляції – будь то викрадання даних, здійснення фішингових шахрайств, впровадження виконуваного коду або поширення дезінформації.
Нові дані свідчать про те, що ефективні засоби контролю мають значний вплив на здатність зловмисника здійснювати непряме оперативне введення вірусу. Ці засоби контролю включають впровадження технічних захисних заходів, таких як санітарна обробка вхідних даних та суворіший контроль доступу, та спираються на розвиток культури безпеки шляхом ефективного навчання користувачів. Вбудовуючи такі заходи в процеси перед розгортанням, організації можуть безпечно та надійно впроваджувати ці інструменти. Вони можуть поєднувати їх із моніторингом ефективності захисних заходів після розгортання, щоб забезпечити безпеку поведінки користувачів та пом’якшити нові загрози.
