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