Контекстне шифрування для конвеєрів LLM та векторних баз даних
Корпоративна платформа AI потребувала можливості використання функцій на базі LLM (чат, пошук, аналіз документів), забезпечуючи при цьому, що конфіденційні дані — PII, фінансові записи, медична інформація — залишалися зашифрованими протягом усього конвеєра, включно зі зберіганням у вигляді векторних вбудовувань у векторній базі даних.
Обговоріть Ваш Проєкт
Виклик
Використання LLM та векторних баз даних з конфіденційними даними створило нові ризики безпеки:
- Атаки інверсії вбудовувань — Дослідження показали, що векторні вбудовування можуть бути реконструйовані для відновлення оригінального тексту, викриваючи PII, що зберігаються у векторних DB
- Витік контексту LLM — Конфіденційні дані, надіслані до LLM, можуть з'явитися у відповідях іншим користувачам, якщо їх не ізолювати належним чином
- Вимоги відповідності — GDPR, HIPAA та SOC2 вимагали шифрування даних у стані спокою та під час передачі, але векторні бази даних зберігали математичні представлення, а не традиційні текстові поля
- Функціональність пошуку — Шифрування тексту перед вбудовуванням руйнувало семантичне значення, роблячи пошук за схожістю марним
- Управління ключами — Потрібне було обертання ключів шифрування для кожного клієнта без повторного вбудовування всього набору даних
- Аудитний слід — Кожен доступ до розшифрованих конфіденційних даних потребував журналювання для забезпечення відповідності
Наше Рішення
Ми впровадили архітектуру контекстного шифрування, яка вибірково шифрує конфіденційні поля перед зберіганням, зберігаючи при цьому можливість семантичного пошуку за допомогою багатошарового підходу — шифруючи PII в метаданих, зберігаючи при цьому очищений, неконфіденційний вміст доступним для вбудовування.
Архітектура
- Двигун шифрування: AES-256-GCM з ключами шифрування для кожного клієнта
- Управління ключами: AWS KMS для генерації, обертання та контролю доступу до ключів
- Виявлення PII: Класифікатор PII на основі NER (Named Entity Recognition)
- Векторна база даних: Milvus для пошуку за схожістю на очищених вбудовуваннях
- Рівень LLM: Очищений контекст надсилається до LLM, конфіденційні поля повторно вводяться після генерації
- Система аудиту: Кожна подія розшифрування реєструється з користувачем, відміткою часу та метою
- База даних: PostgreSQL для зашифрованих метаданих
Стратегія контекстного шифрування
Класифікація даних
Перш ніж будь-які дані потраплять у конвеєр, класифікатор PII категоризує кожне поле за рівнем конфіденційності:
- Висококонфіденційні (наприклад, державні ідентифікатори, номери фінансових рахунків, медичні ідентифікатори) — Зашифровані, ніколи не вбудовуються, ніколи не надсилаються до LLM
- Конфіденційні PII (наприклад, повні імена, адреси електронної пошти, номери телефонів) — Зашифровані у стані спокою, замінюються заповнювачами перед вбудовуванням
- Контекстуальні (наприклад, посади, назви компаній) — Зашифровані у стані спокою, доступні для вбудовування за згодою
- Неконфіденційні (наприклад, описи продуктів, публічна інформація) — Зберігаються та вбудовуються як є
Рівні шифрування
Рівень 1: Шифрування на рівні поля у стані спокоюКонфіденційні поля шифруються за допомогою AES-256-GCM перед зберіганням. Кожен клієнт отримує виділений ключ шифрування даних (DEK), що управляється через ієрархію ключів за допомогою AWS KMS. Тіньові поля зберігають хеші, що дозволяють здійснювати пошук для точного співпадіння без необхідності розшифрування.
Рівень 2: Очищення перед вбудовуваннямPII виявляється та замінюється заповнювачами, що зберігають тип, перш ніж текст надсилається до моделі вбудовування. Це зберігає семантичне значення для пошуку за схожістю, одночасно видаляючи ідентифіковану інформацію. Зіставлення оригіналу із заповнювачем зберігається зашифрованим поруч із векторним записом.
Рівень 3: Введення контексту після генерації LLMLLM отримує очищений контекст із заповнювачами для генерації відповідей. Після генерації система повторно вводить фактичні значення із зашифрованого сховища у відповідь. Це запобігає потраплянню конфіденційних даних у навчальні дані LLM або їх кешуванню постачальником.
Безпека векторної бази даних
Дизайн колекції
Векторні колекції зберігають очищені вбудовування разом із зашифрованими оригінальними метаданими. Ізоляція клієнтів забезпечується за допомогою ключів розділів, при цьому метадані кожного клієнта шифруються за допомогою їх власного ключа. Рівень API перевіряє право власності клієнта перед будь-якою операцією розшифрування.
Управління ключами та ротація
Ієрархія ключів
Використовується багаторівнева ієрархія ключів: головний ключ в AWS KMS обгортає ключі шифрування ключів для кожного клієнта, які, у свою чергу, обгортають ключі шифрування даних для кожного клієнта, що використовуються для шифрування на рівні поля. Це дозволяє ефективно обертати ключі без повторного шифрування всього ланцюжка ключів.
Процес ротації ключів
- Створено новий DEK — Новий ключ шифрування даних створюється під існуючим ключем шифрування ключів
- Нові записи — Всі нові дані шифруються новим ключем; старий ключ залишається дійсним для читання
- Фонове повторне шифрування — Пакетне завдання повторно шифрує існуючі записи новим ключем
- Виведення старого DEK з експлуатації — Після міграції всіх записів старий ключ позначається як неактивний
- Журнал аудиту — Подія ротації реєструється з відмітками часу та кількістю залучених записів
Аудит та відповідність
Журнал аудиту розшифрування
Кожна подія розшифрування фіксує, хто її запросив, що було розшифровано, коли, чому (контекст запиту) і який ключ був використаний — надаючи повний слід для відповідності.
Право на видалення (GDPR)
Система підтримує повне видалення даних як у реляційній базі даних, так і у векторній базі даних, з додатковою ротацією ключів для криптографічного забезпечення відсутності залишкового доступу. Усі операції видалення реєструються в аудитному журналі GDPR.
Ключові особливості
- Шифрування на рівні поля — AES-256-GCM для конфіденційних полів, а не для цілих записів
- Очищення PII — Заповнювачі зберігають семантичне значення для вбудовувань
- Повторне введення після LLM — Конфіденційні дані ніколи не надсилаються постачальникам LLM
- Ключі для кожного клієнта — Ізольовані ключі шифрування з управлінням за допомогою AWS KMS
- Ротація ключів — Ротація без простоїв з фоновим повторним шифруванням
- Безпека вбудовувань — Очищені вбудовування запобігають атакам інверсії на PII
- Аудитний слід — Кожне розшифрування реєструється для звітності щодо відповідності
- Відповідність GDPR — Автоматичне видалення в зашифрованих сховищах та векторних DB
Результати
Технологічний Стек
caseStudyDetail.more Кейси
Ознайомтесь з іншими нашими технічними впровадженнями
Обробка рахунків-фактур за допомогою AI, OCR та інтеграції з QuickBooks
Середній бізнес, який щомісяця обробляє сотні рахунків-фактур від постачальників, потребував усунення ручного введення даних шляхом автоматичного вилучення даних рахунків-фактур за допомогою AI/OCR та їх прямої синхронізації з QuickBooks для ведення бухгалтерського обліку та відстеження платежів.
Вставка реклами на стороні клієнта (CSAI) з парсингом маркерів SCTE-35 та інтеграцією багатоплатформного плеєра
Платформа потокового відео потребувала впровадження вставки реклами на стороні клієнта (CSAI) для веб-, мобільних програм та програм для підключених телевізорів — що забезпечує персоналізований рекламний досвід на рівні пристрою з повною підтримкою взаємодії з рекламою (натискні оверлеї, супутні банери, кнопки пропуску), який не може забезпечити вставка на стороні сервера.
Готові Трансформувати Свій Бізнес?
Давайте обговоримо, як ми можемо застосувати подібні рішення для ваших завдань.