Добивки:
- Способност да се одвои автентикација и овластување и да се примени минимално овластување со RBAC/ABAC
- Способност да се избегне мешан ризик од прокси со водење на моделот во кориснички контекст
- Способност за складирање и ротирање на API клучеви со тајниот систем за управување
Значителен дел од нападите врз системот за вештачка интелигенција не започнуваат со „измамување“ на моделот, туку со украден клуч API или преку овластена сметка. Овој слој на безбедност доаѓа од класичната безбедност на информациите, но додава нови ризици во контекст на вештачката интелигенција: модел повикува возење во туѓо име, сметката на услугата пристапува до сите податоци, клучот протекува до GitHub. Во оваа единица, ќе научиме како да го стесниме пристапот до системот за вештачка интелигенција со автентикација, овластување (RBAC/ABAC), минимално овластување и тајно управување.
Разлика помеѓу автентикација и авторизација
Двата термина често се мешаат:
- Автентикација: "Кој си ти?" — докажување дека корисникот/услугата е навистина она што тие тврдат дека се (лозинка, токен, сертификат, МНР).
- Овластување: "Што можете да направите?" — одреди до кој ресурс/дејство може да пристапи автентицираната страна.
Критичната суптилност во системите за вештачка интелигенција е следна: кога моделот извршува работа во име на корисникот, дали работи со авторитетот на тој корисник или со широка сметка за услуги? Последново е опасно - затоа што моделот измамен со инјектирање добива целосен пристап до сметката на услугата.
Внимание: проблем „збунет заменик“: корисник со ниски авторитети индиректно пристапува до податоци до кои не може да пристапи преку аутсорсинг на модел со висок авторитет. Моделот секогаш треба да работи во контекст на авторитетот на корисникот, а не во неговиот широк авторитет.
RBAC и ABAC
- RBAC (Контрола на пристап базирана на улоги): Пристапот зависи од улогата на корисникот. Улогата „специјалист за поддршка“ може да ги чита белешките од клиентите, но не може да ги избрише. Едноставно и вообичаено.
- ABAC (Контрола на пристап базирана на атрибути): Пристапот зависи од атрибутите: одделот на корисникот, ознаката за приватност на податоците, времето од денот, мрежата од која доаѓа барањето. Пофино подесен, но покомплексен.
Повеќето организации започнуваат со RBAC и се продлабочуваат до ABAC за чувствителни податоци. Правило на палецот за вештачката интелигенција: моделот треба да го филтрира секој агент што го повикува и секој податок до кој пристапува врз основа на улогата/атрибутите на корисникот што го поднесува барањето.
Чекор по чекор: практикување минимална моќ
- Земете инвентар. Кои алатки ги повикува моделот, до кои податоци пристапува? Наведете ги сите.
- Оправдајте го секој пристап. „Дали на овој помошник навистина му треба овластување за бришење? Во спротивно, отстранете го.
- Стандардно само за читање. Моделот треба стандардно да може да чита; Потребна е запишување/бришење посебен токен со тесен опсег.
- Премести кориснички контекст. Повикајте го возилото со овластување на корисникот, а не со сервисната сметка.
- Краткотраен акредитив. Користете краткотрајни токени кои автоматски се обновуваат наместо долготрајни клучеви.
Тајно управување
Тајна се ингеренциите што мора да останат тајни, како што се клучот API, лозинка, токен или сертификат. Најчеста несреќа во проектите за вештачка интелигенција е кога клучот API на давателот на моделот е вграден во кодот и протекува во контролата на верзијата (Git).
Правилна апликација:
- Никогаш не вметнувајте клучеви во код; Користете променлива на околината или таен систем за управување (услуга што ги складира клучевите шифрирани и го контролира пристапот).
- Ротација: обновувајте ги копчињата во редовни интервали (на пр. на секои 90 дена); Ако постои сомневање за истекување, веднаш откажете го.
- Намалување на опсегот: Секој прекинувач ја има само потребната услуга и потребната овластување.
- Ревизија: евиденција кој го користел клучот, кога и каде.
Четири шаблони за копирање
Прашање за контрола на преглед на пристап:
За секоја алатка од списокот со алатки подолу, проценете:- Дали оваа алатка е ПОТРЕБНА за извршување на работата на овој асистент? (да/не) - Дали е само за читање или пишување/бришење? - Дали оваа алатка се повикува со авторитет на корисникот или сметка на услугата? Означете ги непотребните или прекумерно овластените како „ОТСТРАНИ/РЕДАКТИРАЈ“.<tools>{{ tool_list }}</tools>
Тајно известување за скенирање истекување:
Најдете сè што може да биде хардкодирана тајна во следниот фрагмент од код: клуч API, лозинка, токен, низа за поврзување, приватен клуч. Дајте ред и напишете за секој. КОПИРАЈ ја вредноста во одговор;маска (првите 4 знаци + ***).<code>{{ извор }}</code>
Правило за одлука за најмал орган:
Кога ќе пристигне нова алатка/барање за пристап, прашајте:1. Дали задачата може да се изврши без овој пристап? -> Ако да: ОТФРЛИ 2. Дали е доволно само за читање? -> Ако да: ДАДЕТЕ дозвола за пишување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) Дали работи во кориснички контекст? Потоа побарајте ги сите хард-кодирани тајни (преку горенаведеното барање за скенирање) и напишете план за ротација за секој клуч што ќе го најдете. Отстранете барем едно непотребно овластување.
листа за проверка
- [ ] Моделот работи во контекст на авторитет на корисникот кој го поднесува барањето.
- [ ] Пристапот до алатки и податоци е намален на принципот на најмала привилегија.
- [ ] Запишувањето/бришењето е одвоено од само за читање, автентицирано и тесно.
- [ ] Нема тајни закопани во кодот; Се чува во тајниот управител.
- [ ] Постои распоред за ротација и процедура за откажување на клучевите.
- [ ] Пристапите се прегледуваат редовно.