Почему «утекают» данные в больших языковых моделях. Часть 1
При разработке чат-ботов на основе больших языковых моделей (Large Language Model, LLM) всё чаще становится актуальной проблема «утечки» конфиденциальных данных. Причём она сопряжена со множеством значимых негативных последствий, как для клиентов, так и для бизнеса. Рассматривая значительный круг вопросов, охватываемых этой темой, особое внимание привлекают следующие факторы, ведущие к потере критически важной конфиденциальной информации:
Технической
наборы данных;
архитектура модели;
конвейер обучения;
метрики качества;
неопределённости и уязвимости модели;
аннотации данных;
веб-страницы;
обучающие корпуса;
шаблоны подсказок;
сообщения из чата о предыдущих беседах и т. д.
Инфраструктурной
системы мониторинга;
внешние сервисы: сбор, хранение, распределение, контроль качества данных);
архитектура чат-ботов;
алгоритмы и методики, используемые в разработке;
спецификации;
руководства пользователя;
инструкции по установке и администрированию;
сведения о внутренней архитектуре систем;
используемые протоколы и схемы соединений компонентов;
информация о системах безопасности, методах защиты данных и противодействия угрозам;
подробности тестирования, развёртывания, мониторинга и поддержки систем;
конфигурационные файлы, скрипты и другие артефакты, связанные с разработкой и эксплуатацией;
сведения о ключах, сертификатах и других элементах криптографической защиты;
данные об используемых сторонних компонентах, библиотеках и платформах.
Правовой
договоры;
контракты сотрудников;
устав и положения организации;
внутренние документы;
нормативно-правовые акты и соглашения;
политики безопасности;
процедуры обработки инцидентов безопасности;
планы реагирования на инциденты;
NDA;
PDA;
лицензионные соглашения программного обеспечения;
уведомления о приватности;
политики и процедуры управления доступом;
санкции и юридические последствия;
потеря доверия со стороны пользователей;
проблемы с репутацией.
Персональной
персональные данные клиентов, сотрудников, контрагентов и подрядчиков;
биометрическая информация;
геолокационные данные;
данные социального, финансового, образовательного, медицинского и профессионального поведений людей.
Интеллектуальной собственности
авторские права на базы данных и код;
торговые секреты;
ноухау;
коммерческие разработки;
патенты на алгоритмы и методы;
лицензии на использование данных.
Как видите, большие языковые модели активно собирают и используют в своей работе многочисленные источники информации, которая подлежит защите и сохранению в тайне. Однако, на сегодняшний день выделяется уже достаточно много видов кибератак на LLM, активно используемые во множестве чат-ботов, таких как ChatGPT, Bard, Notion AI, Compose AI, Poe, Writesonic, Phind, Browse AI, Kickresume, Texti, You.com, Rytr, Character AI, Perplexity. Это провоцирует значительное количество утечек конфиденциальных данных. Кроме того, многие утечки весьма сложны в устранении. Например, стриминговый сервис Spotify не может убрать ряд утечек уже 5,5 лет!
Виды атак
Special Characters Attack
Начнём с не самой очевидной, но получившей в последнее время достаточно широкую огласку атаки под названием Special Character Attac (SCA). Она позволяет вытаскивать адреса электронной почты, учётные записи пользователей iCloud и много другой конфиденциальной информации. В атаке используются необрабатываемые символы, такие как {, }, @, #, $,
Например, Llama-2 имеет тенденцию генерировать разреженное распределение с большим количеством управляющих данных или лексем в формате UTF-8 (например, , , <0x20>, <0x0A>) в присутствии последовательностей SCA под названием SCALogit Biased (SCA-LB), в которых управляющим лексемам или лексемам UTF-8 присваиваются более высокие вероятности. Одним из побочных эффектов SCA является то, что модель постоянно отвечает максимальной длиной лексем. Более того, с помощью этой атаки можно получить распределение языков и контента в обучающем корпусе текстов. В качестве метрики качества использовались два значения: Count и Attack Success Rate (ASR). Count — это количество ответов, сгенерированных LLM, которые попадают в любой из возможных наборов, в то время как ASR (%) — доля последовательности SCA каждого типа, которая может привести к успешной атаке.
Как показано в исследовательской работе, атака была успешно применена как к открытым, так и коммерческим LLM, демонстрируя возможность извлечения информации даже из более устойчивых моделей. В качестве примера использования SCA упоминается разработка Special Characters Attack — Semantic Continuation (SCA-SC), которая позволяет эффективно извлекать данные из коммерческих LLM с помощью вручную спроектированных специальных символов.
Это подчёркивает способность злоумышленников проникнуть даже в модели, которые были защищены от подобных угроз. Одним из методов блокирования этой атаки является адверсариальное обучение, в статье как раз и рассматривается подобный случай. В репозитории собраны последние статьи по поводу адверсариального обучения моделей, и он постоянно пополняется. Также уже есть готовые инструменты, позволяющие разрабатывать более безопасные модели, среди наиболее популярных — Adversarial Robustness Toolbox (ART). Наиболее полное объяснение атаки для NLP найдено здесь.
Leakage of Test Data in Training Data
Немного более «тонкая» форма утечки происходит, когда есть пересечение между тестовыми данными и обучающим набором. Эта проблему сложно обнаружить из-за проприетарной и неоднозначной природы наборов данных для обучения LLM. Эта ситуация представляет значительный вызов для точности и надёжности оценок производительности модели.
Здесь мы имеем дело с некорректным моделированием вектора данных в целом. Более того, наряду с этим выделяют большое разнообразие в источниках данных и высокую степень насыщения модели предметными областями. При этом характерно наличие дубликатов в данных, то есть когда по источнику «циркулирует» одна и та же информация, но подвергшаяся многократному переписыванию, или когда модель достраивает ответы, используя информацию из смежных областей, но по смыслу никак не связанных.
Также одной из причин для реализации атаки LTDAT называют наличие внутренних конфликтов в модели, когда есть неопределённость отнесения данных к разным категориям. Побочным эффектом этой проблемы является сверхвысокая точность при обучении модели на тестовой выборке и низкие результаты на тестовой. Очень простой пример подобной реализации рассматривается здесь. Сюда относят все источники информации, включая книги, статьи, веб-страницы, блоги, соцсети и т. д. Например, это могут быть предложения или фразы, содержащие определённые ключевые «триггерные» слова или конструкции, которые модель «распознаёт» по аналогии с обучающими данными. Реализация этой атаки сходна с DDoS (Distributed Denial of Service), то есть цель атакующего — собрать как можно больше информации по одному вопросу и затем использовать для будущих реконструированных запросов. Эти данные являются своего рода «маскировкой», и модель перестаёт обращать на них внимание, так как уже знает, что они используются в её обучающем наборе. Здесь возможно закладывание необрабатываемого структурного запроса при использовании, например, SCA-атаки.
Leakage in Prompt Atack (PLeak)
Утечка пользовательских данных происходит, когда пользователи случайно включают личную идентифицирующую информацию или конфиденциальные данные в свои входные запросы. Такой вид утечки может привести к нарушению приватности и непреднамеренной передаче конфиденциальной информации в обучающее пространство модели, из которой она собирает ответы. В этой работе приводится тест на реализацию атаки на примере чат-бота Poe. Также авторы предоставили подробный репозиторий по реализации атаки.
Более того, по данным исследователей, Poe позволяет пользователю сохранять конфиденциальность системной подсказки своего LLM-ассистента, и 55% (3 945 из 7 165) LLM-ассистентов на Poe решили сохранить конфиденциальность своих системных подсказок. Таким образом, естественной атакой (так называемой утечкой подсказок) на LLM-ассистента является кража его системной подсказки, что ставит под угрозу интеллектуальную собственность пользователя.
Структура работы Pleak.
В PLeak запрос противника шаг за шагом оптимизируется для «теневых» системных подсказок. То есть, начинает с первых нескольких лексем каждой подсказки в «теневом» наборе данных и затем увеличивает размер лексем до полной длины.
Кроме того, в PLeak для дальнейшего повышения эффективности атаки используют ещё одну стратегию, называемую постобработкой. В частности, шлют целевому LLM-приложению несколько атакующих запросов и объединяют их ответы для реконструкции системного запроса, получая, например, перекрытие между ответами на атакующие запросы. LLM на основе подсказки выводит первый токен, затем добавляет его к подсказке и выводит второй токен на основе подсказки + первый токен, далее этот процесс повторяется до тех пор, пока не будет выведен специальный токен END. Таким образом можно вытащить структуру подсказок, по которым оперирует модель, и понять, как она устроена, а дальше «вытаскивать» из неё все конфиденциальные данные. В качестве стратегий используются beam, sample, beamsample. Сама атака разбита на несколько фаз:
Offline AQ Optimization. Пространство поиска для состязательного запроса огромно, поскольку каждый из его токенов может быть любым токеном в большом словаре, что может легко привести к локальному оптимуму. Поэтому в PLeak разбивают поиск на более мелкие шаги и постепенно оптимизируют. Более того, начальные лексемы подсказки для «теневой» системы имеют большее значение, чем последние. Исходя из этого сначала оптимизируют AQ для реконструкции t лексем подсказок для «теневой» системы в наборе теневых данных Ds, а затем постепенно увеличивают размер реконструкции шаг за шагом, пока не смогут реконструировать все подсказки для «теневой» системы. Во-вторых, в PLeak используют градиентный метод поиска для повышения эффективности на каждом шаге оптимизации.
Target System Prompt Reconstruction. Восстановление подсказки целевой системы: восстановление исходного ответа после обфускации и извлечение подсказки целевой системы.
Способы защиты
Для предотвращения атак описанных видов сегодня используется достаточно много приемов и методик. Все они направлены на выстраивание «корректного» вектора данных и минимизации последствий. Кроме того, защита должна строиться в оба направления: и со стороны модели, и со стороны пользователя. То есть важно учитывать не только запрос от пользователя, но и то, что отдаёт модель, и фильтровать её выдачу на наличие конфиденциальных данных. Более того, по последним новостям всё чаще уже ставится во главу угла не то, насколько модель может выполнить возложенные на неё функции, а то, насколько она безопасна в целом.
Также есть и другие подходы, нацеленные на разработку безопасных LLM-моделей, ниже я привёл подробный список. Сразу оговорюсь, здесь не будет популярных решений по общей системе безопасности инфраструктуры и периметра, а только то, что непосредственно относится к большим языковым моделям и их поведению:
Маскировка данных (Data Masking). Заменяем конфиденциальную информацию на значение-заглушку. При повторном запросе отправляем оповещение о потенциально опасной деятельности и рассматриваем вопрос о предоставлении информации пользователю уже со стороны оператора, модератора чата или сети, настроенной на поиск конфиденциальных данных. Эффективная маскировка данных требует комплексного подхода, включающего не только замену реальных данных на заглушки, но и регулярное их обновление, чтобы они оставались сложными для дешифровки.
Классификация данных (Data Classification). Либо классифицируем и категоризируем данные в зависимости от их конфиденциальности, помогая скрыть от «посторонних» глаз, либо опрашиваем пользователя, зачем ему нужна эта информация. То есть, здесь мы концентрируемся на разграничении прав доступа по различным критериям, как со стороны пользователя, так и со стороны самих данных. Сейчас любой пользователь может получить любые данные по любому запросу. С одной стороны, это правильно, а с другой — требует контроля.
Мониторинг данных (Data Monitoring). Так как модели со временем «прокисают» и их необходимо дообучать, мы всегда смотрим, как изменяется вектор данных при дообучении, не попала ли в него случайно конфиденциальная информация. Поэтому при загрузке новых данных необходимо учитывать, что предоставляется модели для обучения, и настраивать фильтры на входе и выходе, даже если мы пропустили конфиденциальные данные в предыдущих двух пунктах.
Анонимизация данных (Data Anonymization). Мы изменяем или удаляем личную идентифицирующую информацию, делая данные менее уязвимыми для утечки, даже если невозможно их замаскировать или они сложны для классификации и мониторинга вследствие разнородности.
Шифрование данных (Data Encryption). Предлагается разработать ряд процедур, чтобы данные приходили от пользователя в зашифрованном виде, а на стороне модели расшифровывались и проверялись. Затем модель обрабатывает ответ, шифрует и отправляет пользователю, причем количество шифров и их порядок следует постоянно менять от запроса к запросу, чтобы сложнее было восстановить сигнатуру исходного запроса по множеству разнородных запросов, но нацеленных на одну задачу.
Безопасное согласование (Safe Concurrency). Используют механизмы, которые гарантируют невозможность одновременного использования LLM-ассистента несколькими пользователями или процессами. Например, синхронизируют доступ к модели или предотвращают конфликтующие операции.
Сегрегация внешнего контента (Segregating External Content) от настоящих запросов пользователей, чтобы модель не обрабатывала потенциально вредоносный ввод как легитимные запросы. Это может быть достигнуто с помощью проверок, которые тщательно изучают данные на наличие признаков манипуляций или злонамеренного подхода.
Постоянный мониторинг ответов LLM для обнаружения аномалий (Continuously Monitor the LLMs' Output). Большинство пользователей задают в целом «стандартные» запросы. Поэтому создают систему оценки необычных, нестандартных ответов, которые могут быть сопоставлены с другими надёжными ответами для обнаружения неточностей или потенциальных утечек в данных.
Хронологический контроль при добавлении данных. То есть учёт, когда данные по модели были добавлены, чтобы обеспечить наиболее релевантную и свежую информацию.
Фильтрация и генерация случайного, но семантически верного расположения префикса и порядка слов при создании и выдаче системных подсказок у генеративных моделей.
Как видите, атаки на LLM эволюционируют очень активно и во многом схожи с классическими кибератаками. Однако есть и своя, ярко выраженная направленность и особенность. При подготовке моделей необходимо уже сейчас рассматривать весь спектр защитных механизмов для предотвращения утечек. В следующей части я постараюсь рассказать про уже наработанные решения и их практическую реализацию.
