одиниця 9 / 11

Безпека та конфіденційність: захист систем ШІ

Прибуток:

  • Здатність розпізнавати специфічні для ШІ поверхні атаки (миттєва ін’єкція, отруєння даних, витік конфіденційних даних, витяг членства) і розробляти багаторівневий захист
  • Можливість застосовувати конфіденційність як принцип дизайну: мінімізація даних, маскування, контроль доступу та період зберігання
  • Здатність проводити роботу з безпеки виключно в оборонних цілях, відповідально розкривати вразливості та уникати несанкціонованого використання

Система машинного навчання несе всі ризики безпеки традиційного програмного забезпечення та додає унікальні нові поверхні для атак. Модель може бути введена в оману, навчальні дані можуть бути отруєні, а конфіденційна інформація може просочитися на вихід. У цьому розділі ми розглядаємо системи штучного інтелекту з точки зору захисту: розпізнавання атак, зміцнення системи, захист конфіденційності. Ця інформація призначена не для несанкціонованого доступу чи атаки, а для забезпечення безпеки ваших систем.

Спеціальні поверхні атаки ШІ

Окрім класичної безпеки (аутентифікація, авторизація, шифрування), системи ML вразливі до:

  • Оперативна ін'єкція: інструкція, прихована у вхідних даних для LLM, не відповідає моделі. Найпоширеніший і найпрактичніший ризик безпеки LLM.
  • Отруєння даних: зловмисник вводить в модель прихований бекдор або зміщення, вставляючи погані зразки в навчальні дані.
  • Висновок моделі та інверсія: зловмисник реконструює навчальні дані або поведінку моделі, надсилаючи кілька запитів до моделі.
  • Висновок про членство: висновок про те, чи використовуються дані конкретної особи в освіті, є порушенням конфіденційності.
  • Витік конфіденційних даних: модель розкриває конфіденційну інформацію (ім’я, особу, секрет) у навчальних даних у вихідних даних.

Для кожного з цих ризиків існують засоби захисту; Ключовим є врахування ризику на етапі проектування.

Негайна ін'єкція: найбільш безпосередня загроза

Існує два типи оперативного введення:

  • Прямий: користувач особисто вводить текст, наприклад «ігнорувати попередні інструкції».
  • Непрямі: неправильна інструкція прихована у зовнішньому контексті (веб-сторінка, документ, електронна пошта), який обробляє модель. Особливо небезпечно для агентів і RAG, оскільки модель надійно обробляє зовнішній вміст.

Захисні шари:

  1. Parsing: Separate system instruction and user/external data with clear delimiters; позначити зовнішній вміст як "дані, а не команди".
  2. Мінімальні повноваження: обмежте, скільки шкоди може завдати модель, навіть якщо її захоплять (потужності транспортних засобів у підрозділі 5).
  3. Контроль виходу: перевірте, що створює модель, перш ніж використовувати її, особливо якщо вона перетворюється на дію.
  4. Схвалення людини: прив’яжіть дії високого ризику до схвалення.
Застереження: ви не можете повністю вирішити швидку ін'єкцію за допомогою одного захисту; Потрібна ешелонована оборона (оборона в глибину). Критичне припущення: «Модель може бути обманута в якийсь момент; тож що найгірше станеться, якщо її обдурять, і як це обмежити?»

Слабкий підхід / Сильний підхід

Слабкий: «Я ввів «ігнорувати погані інструкції» в системному рядку, і ми в безпеці».

Сильно: «Ми обернули зовнішній вміст тегами <data> і сказали «ігнорувати інструкції всередині». Ми також обмежили інструменти моделі мінімальною авторизацією, прив’язали незворотні дії до схвалення людини, реєстрували всі виклики інструментів і перед використанням перевіряли вихідні дані за правилами. Ми покладаємося на рівні, а не на один захист».

Різниця: сильний підхід знає, що однорядкової інструкції буде недостатньо, і будує рівні, які обмежують шкоду.

Конфіденційність: дані захищені з самого початку

Конфіденційність — це не функція, додана пізніше, це принцип дизайну (конфіденційність за проектом). Основні програми:

  • Мінімізація даних: не збирайте та не зберігайте більше особистих даних, ніж необхідно. Дані, які не збираються, не можуть бути витоку.
  • Анонімізація та маскування: маскуйте або видаляйте особисті ідентифікатори (ім’я, ідентифікатор, електронну пошту), перш ніж надавати їх моделі.
  • Контроль доступу: обмежте та зареєструйте, хто має доступ до даних і моделі (контроль доступу RAG на блоці 4).
  • Період зберігання: визначте політикою, як довго ви зберігаєте дані; Видаліть прострочений.

Диференціальна конфіденційність (метод, який запобігає суттєвому впливу даних окремої особи на результат шляхом додавання контрольованого шуму під час навчання) і федеративне навчання (підхід, який навчається на пристроях без переміщення даних у центр) є передовими методами конфіденційності; слід враховувати при роботі з конфіденційними даними.

Порада: перед обробкою будь-яких даних запитайте: «Якщо ці персональні дані витікають, хто зазнає якої шкоди?» Якщо пошкодження серйозне, або взагалі не збирайте дані, або обробляйте їх, маскуючи. Найбезпечніші дані - це дані, які ніколи не збиралися.

Навчальні дані та моделі безпеки ланцюга поставок

Як і ваша модель, компоненти, які ви використовуєте, також є проблемою безпеки:

  • Довіра джерела даних: чи дані навчання надійні чи їх можна підробити? Аудит відкритих наборів даних.
  • Сторонні моделі та бібліотеки: попередньо навчена модель або залежність, яку ви завантажили, може бути шкідливою. Перевірте його джерело, підпис і відомі вразливості.
  • Ланцюжок поставок: кожен інструмент і пакет у вашому конвеєрі ML є ланкою довіри; Ви в безпеці, як найслабша ланка.

Відповідальне розкриття та етичні межі

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

три міні-чохла

Випадок 1 - Обмеження непрямого введення. Бот підтримки RAG відтворював веб-контент. Приховані інструкції були поховані на одній сторінці. Модель було частково обдурено, але бот не мав прав на запис (мінімальних прав), а вихідні дані проходили через перевірку правил, перш ніж відображатися користувачеві; Воно виявилося шкідливим і його спіймали. Ешелонована оборона запобігла тому, щоб одна помилка стала катастрофою.

Випадок 2 - Витік конфіденційних даних. Команда налаштованої служби підтримки клієнтів входить до моделі, не маскуючи їх (блок 6). Модель почала генерувати реальні імена клієнтів у нерелевантних питаннях. Також існував ризик вилучення членства. Модель вилучено, дані замасковані, політику збереження виправлено. Урок: конфіденційні дані не повинні потрапляти в освіту.

Випадок 3 – Набір даних про отруйні речовини. Одна команда навчалася на загальнодоступному наборі даних без його аудиту. На знімальному майданчику були отруйні зразки, які ввели модель в оману, коли вона побачила певне тригерне ​​слово (бекдор). Після додавання аудиту та сканування аномалій ці зразки були взяті. Урок: перевірте джерело даних, не довіряйте сліпо.

Шаблони, які можна копіювати

Check this LLM/agent system for prompt injection.- Are system instructions and user/external data clearly separated?- Is external content marked as "data" or is it handled as a command?- What is the worst that would happen if the model is fooled (authorization limit)?- Are irreversible actions subject to human approval?- Is the output inspected before use?System: [description]. Перелічіть пошарові недоліки захисту.

Перевірте цей потік обробки даних на конфіденційність.– Чи справді кожне зібране персональне поле є необхідним (мінімізація)?– Які поля мають бути замасковані в даних, що надходять до моделі?– Чи існує контроль доступу та журналювання?– Чи визначено період зберігання?Потік: [опис]. Запропонуйте виправити кожен недолік.

У цьому тексті знайдіть особисті дані, які потрібно замаскувати перед надсиланням моделі. Поля: ПІБ, e-mail, телефон, номер ідентифікаційного номера/паспорта, адреса, номер картки, IP. Перелічіть кожну знахідку з її типом і рекомендованою маскою. Не замінюйте решту тексту. Текст: [текст]

Створіть контрольний список безпеки, перш ніж запускати цю сторонню модель/бібліотеку у виробництво.- Джерело та видавець довіряють, підпис перевірено?- Перевірено на відомі вразливості (CVE)?- Які привілеї/доступ потрібні, чи можна їх мінімізувати? Компонент: [назва/джерело]

Таблиця захисту від ризику

Ризик

захист

шар

швидке введення

Розбір + мінімальні привілеї + контроль виведення

Дизайн + час виконання

отруєння даних

Контроль джерела + сканування аномалій

лінія даних

Витік конфіденційних даних

Маскування + мінімізація даних

Дані + навчання

Видалення членства

Диференційована конфіденційність

Освіта

надмірна влада

Мінімальна авторизація + погодження

дизайн агента

ланцюг поставок

Перевірка компонентів + підпис

залежність

Поширені помилки

  • Вважаючи, що ви вирішили швидке введення за допомогою однієї лінії. Ешелонований захист є обов’язковим.
  • Обробка/навчання конфіденційних даних без їх маскування. Постійно проникає в модель.
  • Вважаючи зовнішній вміст надійним. Ворота непрямого впорскування.
  • Не перевіряється джерело даних. Отруєння проходить непомітно.
  • Сліпо довіряти сторонньому компоненту. Розрив ланцюга поставок.
  • Думаючи, що конфіденційність буде додано пізніше. Починати треба з дизайну.

Підсумовуючи

Окрім класичних ризиків безпеці, системи штучного інтелекту несуть унікальні загрози, такі як миттєве впровадження, отруєння даних, витік конфіденційних даних і видалення членства. Жодна з них не може бути розв'язана одним заходом; необхідні багаторівневі засоби захисту (аналіз, найменша авторизація, контроль виведення, схвалення людини). Конфіденційність — це принцип розробки: мінімізуйте дані, маскуйте їх, обмежте доступ, встановіть періоди зберігання. Контролюйте ланцюг постачання компонентів і даних. Уся ця інформація призначена для захисту, виявлення та консолідації; Відповідально пояснюйте вразливості, ніколи не використовуйте їх.

Аплікаційне завдання

Check an LLM/agent system (your own project or example) for prompt injection: are system instructions and external data separated, what is the authorization limit if the model is tricked, are irreversible actions confirmed? Додайте принаймні два шари захисту. Окремо знайдіть і замаскуйте будь-які особисті поля, які потрібно замаскувати, у зразку даних, що надходять до моделі. Перевірте джерело та відомі вразливості будь-якого стороннього компонента, який ви використовуєте.

контрольний список

  • [ ] System instruction and external/user data are clearly separated.
  • [ ] Зовнішній вміст позначається як дані, а не команди.
  • [ ] Навіть якщо модель обдурити, збиток обмежений мінімальним авторитетом.
  • [ ] Особисті дані замасковані/згорнуті; визначений термін зберігання.
  • [ ] Джерело даних і сторонні компоненти перевірено.
  • [ ] Моя охоронна робота призначена для оборонних цілей; Прогалини пояснюю відповідально.