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