Прибуток:
- Можливість розділити автентифікацію та авторизацію та застосувати мінімальну авторизацію за допомогою RBAC/ABAC
- Можливість уникнути змішаного проксі-ризику шляхом запуску моделі в контексті користувача
- Можливість зберігати та обертати ключі API за допомогою секретної системи управління
Значна частина атак на систему штучного інтелекту починається не з «обману» моделі, а з викраденого ключа API або надмірно авторизованого облікового запису. Цей рівень безпеки походить від класичної інформаційної безпеки, але додає нові ризики в контексті ШІ: модель викликає поїздку від чужого імені, обліковий запис служби отримує доступ до всіх даних, витік ключа на GitHub. У цьому розділі ми дізнаємося, як звузити доступ до системи ШІ за допомогою аутентифікації, авторизації (RBAC/ABAC), мінімальної авторизації та керування секретами.
Різниця між автентифікацією та авторизацією
Ці два терміни часто плутають:
- Автентифікація: "Хто ти?" — підтвердження того, що користувач/сервіс дійсно є тим, за кого себе видають (пароль, токен, сертифікат, MFA).
- Авторизація: "Що ти можеш?" — визначити, до якого ресурсу/дії може отримати доступ аутентифікована сторона.
Критична тонкість у системах штучного інтелекту полягає в наступному: коли модель виконує роботу від імені користувача, чи працює вона з повноваженнями цього користувача чи з обліковим записом широкої служби? Останнє небезпечно — тому що обманута ін’єкцією модель отримує повний доступ до сервісного облікового запису.
Застереження: проблема «заплутаного заступника»: користувач з низькими повноваженнями опосередковано отримує доступ до даних, до яких він не може отримати доступ, передавши модель з високими повноваженнями на аутсорсинг. Модель завжди повинна працювати в контексті повноважень користувача, а не його власних повноважень.
RBAC і ABAC
- RBAC (контроль доступу на основі ролей): доступ залежить від ролі користувача. Роль «спеціаліст служби підтримки» може читати нотатки клієнтів, але не може їх видаляти. Простий і поширений.
- ABAC (контроль доступу на основі атрибутів): доступ залежить від атрибутів: відділ користувача, мітка конфіденційності даних, час доби, мережа, з якої надходить запит. Більш тонко налаштований, але складніший.
Більшість організацій починають із RBAC і переходять на ABAC для конфіденційних даних. Емпіричне правило для штучного інтелекту: модель повинна фільтрувати кожного агента, який вона викликає, і всі дані, до яких вона отримує доступ, на основі ролі/атрибутів користувача, який робить запит.
Крок за кроком: використання мінімальних повноважень
- Проведіть інвентаризацію. Які інструменти викликає модель, до яких даних має доступ? Перелічіть їх усіх.
- Кожен доступ обґрунтуйте. «Цьому помічнику дійсно потрібні повноваження на видалення?» В іншому випадку видаліть його.
- За замовчуванням лише для читання. Модель повинна мати можливість читати за замовчуванням; Вимагати запису/видалення окремого маркера вузького діапазону.
- Перемістити контекст користувача. Викликати транспортний засіб з повноваженнями користувача, а не з обліковим записом служби.
- Короткочасний обліковий запис. Використовуйте короткострокові токени з автоматичним оновленням замість довгострокових ключів.
Таємне управління
Секрет – це облікові дані, які мають залишатися в секреті, наприклад ключ API, пароль, маркер або сертифікат. Найпоширенішим нещасним випадком у проектах штучного інтелекту є випадки, коли ключ API постачальника моделі вбудовано в код і потрапляє в систему контролю версій (Git).
Правильне застосування:
- Ніколи не вставляйте ключі в код; Використовуйте змінну середовища або секретну систему керування (сервіс, який зберігає ключі в зашифрованому вигляді та контролює доступ).
- Ротація: оновлюйте ключі через регулярні проміжки часу (наприклад, кожні 90 днів); Якщо є підозра на витік, негайно скасуйте.
- Зменшення обсягу: кожен комутатор має лише необхідну послугу та необхідну авторизацію.
- Аудит: реєструйте, хто використовував ключ, коли та де.
Чотири шаблони, які можна копіювати
Підказка контролю перегляду доступу:
Для кожного інструменту в списку інструментів нижче оцініть: - Чи цей інструмент ОБОВ’ЯЗКОВИЙ для виконання роботи цього помічника? (так/ні) - Це лише для читання чи для запису/стирання? - Цей інструмент викликається з повноваженнями користувача чи обліковим записом служби? Позначте непотрібні або надмірно авторизовані як "ВИДАЛИТИ/РЕДАКТУВАТИ".<tools>{{ tool_list }}</tools>
Підказка сканування таємного витоку:
Знайдіть усе, що може бути жорстко закодованим секретом, у такому фрагменті коду: ключ API, пароль, маркер, рядок підключення, закритий ключ. Укажіть рядок і тип для кожного. COPY значення у відповідь;маска (перші 4 символи + ***).<code>{{ джерело }}</code>
Правило прийняття рішення про найменший авторитет:
Коли надходить новий інструмент/запит на доступ, запитайте:1. Чи можна виконати завдання без цього доступу? -> Якщо так: REJECT2. Чи достатньо лише читання? -> Якщо так: НАДАТИ дозвіл на запис3. Чи можна звузити коло до одного джерела? -> Якщо так: darat. Типовою відповіддю є "ні"; Доступ досягається розумом.
Нагадування про зміну календаря:
Для кожного секрету запишіть: власника, дату створення, термін дії, область дії. Повідомте про будь-який ключ, який перевищив 90 днів або не використовувався протягом 30 днів, як «КАНДИДАТ НА РОТАЦІЮ/СКАСУВАННЯ».
Слабка підказка / Сильна підказка
поганий підхід
Сильний підхід
Модель отримує доступ до всіх даних за допомогою єдиного облікового запису служби
Модель отримує доступ із повноваженнями користувача, який робить запит
Ключ API вбудовано в код, він ніколи не змінюється
Ротація в менеджері секретів ключів, 90 днів
Широкі повноваження помічника «робити все».
Лише читання за замовчуванням, вузький запис
Доступи ніколи не переглядаються
Регулярний перегляд та відкликання доступу
Три міні-чохли
Випадок 1 — Витік змішаних проксі-даних. Штатний помічник працював з обліковим записом служби, який мав доступ до всіх записів співробітників. Користувач-стажер отримав доступ до даних, які він зазвичай не бачив, сказавши «підсумувати таблицю зарплат керівника»; оскільки модель поставила це під сумнів у контексті власних широких повноважень, а не користувачів. Після того, як контекст користувача було налаштовано на переміщення, стажер міг отримати записи, які міг бачити лише він або вона.
Випадок 2 — Витік ключа, рахунок на 190 000 TL за 2 тижні. Розробник вставив ключ API моделі в допоміжний сценарій і відправив його в загальнодоступне сховище. Бот знайшов ключ за 40 хвилин і використовував його два тижні; Рахунок досяг 190 000 TL. Коли ключ було переміщено до секретного менеджера, підключено до ротації та додано сканування сховища, інцидент не повторився.
Випадок 3 — Переривання за замовчуванням, заборонене лише для читання. Помічник DevOps отримав команду «скинути робочу базу даних» через швидку ін’єкцію. Однак помічнику було надано лише маркер, доступний лише для читання; запис/стирання було в окремому затвердженому потоці. Команда була відхилена через помилку авторизації, і подія була зареєстрована як тривога; Втрати даних не було.
Порада. Зробіть "ні" відповіддю за умовчанням на новий запит на доступ. Доступ – це те, що отримано через виправдання; Роздавати всім, а потім скорочувати майже ніколи не робиться, і ризик накопичується.
Поширені помилки
- Запуск моделі з великим обліковим записом служби та втратою контексту користувача (змішаний проксі).
- Вбудовування ключа API в код і передача його в контроль версій.
- Клавіші не крутяться взагалі ("працює, не чіпай").
- Надання помічнику дозволів на запис/видалення за замовчуванням.
- Надання доступу один раз і більше ніколи його не переглядати.
- Плутаючи автентифікацію з авторизацією та припускаючи, що «він увійшов у систему, він може отримати доступ до всього».
Підсумовуючи
- Автентифікація – це питання «хто ти», авторизація – це питання «що ти можеш зробити»; У ШІ обидва мають працювати в контексті користувача.
- Модель має працювати з повноваженнями користувача, який робить запит, а не з власними широкими повноваженнями (уникаючи ризику змішаної діяльності).
- Почати з RBAC, поглибити з ABAC щодо конфіденційних даних; Зробіть мінімальні повноваження стандартними.
- Не ховайте секрети в коді; зберігайте його в секретному менеджері, звузіть його та помістіть у регулярну ротацію.
- За замовчуванням лише читання та вузький запис значно обмежують вплив ін’єкції.
Аплікаційне завдання
Перелічіть усі інструменти та дані, до яких має доступ ваш помічник ШІ. Дайте відповідь на три запитання для кожного: (1) Чи справді це необхідно? (2) Чи достатньо лише для читання? (3) Чи працює він у контексті користувача? Потім знайдіть усі жорстко закодовані секрети (за допомогою підказки сканування вище) і напишіть план ротації для кожного знайденого ключа. Видаліть принаймні одну непотрібну авторизацію.
контрольний список
- [ ] Модель працює в контексті повноважень користувача, який робить запит.
- [ ] Доступ до інструментів і даних було звужено до принципу найменших привілеїв.
- [ ] Запис/стирання відокремлено від режиму лише для читання, автентифікованого та вузького.
- [ ] У коді немає секретів; Зберігається в секретному менеджері.
- [ ] Існує графік ротації та порядок скасування ключів.
- [ ] Доступи перевіряються регулярно.