Јединица 4 / 11

Контрола приступа, управљање идентитетом и тајно

Добици:

  • Способност раздвајања аутентификације и ауторизације и примене минималне ауторизације са РБАЦ/АБАЦ
  • Способност да се избегне мешовити ризик проксија покретањем модела у корисничком контексту
  • Могућност чувања и ротирања АПИ кључева са системом управљања тајном

Значајан део напада на систем вештачке интелигенције не почиње „преваривањем“ модела, већ украденим АПИ кључем или прекомерно овлашћеним налогом. Овај слој безбедности потиче од класичне информационе безбедности, али додаје нове ризике у контексту вештачке интелигенције: модел позива вожњу у туђе име, сервисни налог приступа свим подацима, кључ цури на ГитХуб. У овој јединици ћемо научити како да сузимо приступ АИ систему са аутентификацијом, ауторизацијом (РБАЦ/АБАЦ), минималном ауторизацијом и тајним управљањем.

Разлика између аутентификације и ауторизације

Ова два термина се често мешају:

  • Аутентификација: „Ко си ти?“ — доказивање да је корисник/услуга заиста оно за шта се представља (лозинка, токен, сертификат, МФА).
  • Овлашћење: "Шта можете учинити?" — одредите којем ресурсу/радњи аутентификована страна може да приступи.

Критична суптилност у системима вештачке интелигенције је следећа: када модел обавља посао у име корисника, да ли ради са ауторитетом тог корисника или са широким налогом услуге? Ово последње је опасно — јер модел који је преварен ињекцијом добија потпун приступ сервисном налогу.

Опрез: Проблем „збуњеног заменика“: корисник са ниским ауторитетом индиректно приступа подацима којима не може приступити тако што ће ангажовати модел високог ауторитета. Модел увек треба да функционише у контексту ауторитета корисника, а не његових ширих овлашћења.

РБАЦ и АБАЦ

  • РБАЦ (Контрола приступа заснована на улози): Приступ зависи од улоге корисника. Улога „специјалиста за подршку“ може да чита белешке корисника, али не може да их избрише. Једноставно и уобичајено.
  • АБАЦ (Контрола приступа заснована на атрибутима): Приступ зависи од атрибута: одељење корисника, ознака приватности података, доба дана, мрежа са које долази захтев. Више фино подешен али сложенији.

Већина организација почиње са РБАЦ-ом и продубљује се на АБАЦ за осетљиве податке. Правило за вештачку интелигенцију: модел треба да филтрира сваког агента којег позове и све податке којима приступа на основу улоге/атрибута корисника који подноси захтев.

Корак по корак: Примена минималних овлашћења

  1. Урадите инвентар. Које алате модел позива, којим подацима приступа? Наведите их све.
  2. Оправдајте сваки приступ. „Да ли је овом помоћнику заиста потребно овлашћење за брисање?“ У супротном, уклоните га.
  3. Подразумевано само за читање. Модел би требало да буде у стању да чита подразумевано; Захтева засебан токен за писање/брисање уског опсега.
  4. Померите кориснички контекст. Позовите возило са овлашћењем корисника, а не са сервисним налогом.
  5. Краткотрајни акредитив. Користите краткотрајне жетоне који се аутоматски обнављају уместо дуготрајних кључева.

Тајно управљање

Тајна су акредитиви који морају остати тајни, као што су АПИ кључ, лозинка, токен или сертификат. Најчешћа несрећа у пројектима АИ је када је АПИ кључ добављача модела уграђен у код и процури у контролу верзија (Гит).

Исправна примена:

  • Никада немојте уграђивати кључеве у код; Користите променљиву окружења или тајни систем управљања (услуга која чува шифроване кључеве и контролише приступ).
  • Ротација: Обнављајте кључеве у редовним интервалима (нпр. сваких 90 дана); Ако се сумња на цурење, одмах откажите.
  • Смањење обима: Сваки прекидач има само потребну услугу и потребну ауторизацију.
  • Ревизија: Запишите ко је користио кључ, када и где.

Четири шаблона за копирање

Упит за контролу прегледа приступа:

За сваки алат на листи алата испод, процените:- Да ли је овај алат ПОТРЕБАН за обављање посла овог помоћника? (да/не) - Да ли је само за читање или за писање/брисање? - Да ли се ова алатка позива са ауторитетом корисника или налогом услуге? Означите непотребне или претерано овлашћене као „УКЛОНИ/РЕДАЦТУЈ“.<тоолс>{{ тоол_лист }}</тоолс>

Упута за скенирање тајног цурења:

Пронађите било шта што би могло да буде чврсто кодирана тајна у следећем исечку кода: АПИ кључ, лозинка, токен, низ везе, приватни кључ. Дајте ред и тип за сваки. ЦОПИ вредност у одговор;маска (прва 4 знака + ***).<цоде>{{ соурце }}</цоде>

Правило одлуке најмањег ауторитета:

Када стигне нова алатка/захтев за приступ, питајте:1. Може ли се задатак извршити без овог приступа? -> Ако јесте: ОДБАЦИ2. Да ли је довољно само за читање? -> Ако да: ДОДАЈТЕ дозволу за писање3. Може ли се опсег сузити на један извор? -> Ако да: дарат Подразумевани одговор је "не"; Приступ се добија разумом.

Подсетник за ротацију календара:

За сваку тајну, запис: власник, датум креирања, рок трајања, обим. Пријавите сваки кључ који је премашио 90 дана или није коришћен 30 дана као „КАНДИДАТ ЗА РОТАЦИЈУ/ОТКАЗИВАЊЕ“.

Слаба порука / јака промпт

лош приступ

Снажан приступ

Модел приступа свим подацима са једног налога услуге

Модел приступа са овлашћењем корисника који поставља захтев

АПИ кључ је уграђен у код, никада се не мења

Ротација у кључном тајном менаџеру, 90 дана

Широка овлашћења за помоћника "уради било шта".

Подразумевано само за читање, пишите уско

Приступи се никада не прегледају

Редовни преглед и опозив приступа

Три мини кућишта

Случај 1 — Процурели мешовити прокси подаци. Помоћник у кући је радио са услужним налогом који је имао приступ свим евиденцијама запослених. Корисник приправник је приступио подацима које иначе не би видео тако што је рекао „сажмите табелу плата руководиоца“; јер га је модел довео у питање у контексту сопственог широког ауторитета, а не ауторитета корисника. Једном када је кориснички контекст прилагођен да буде померен, приправник је могао да извуче снимке које је само он или она могла да види.

Случај 2 — Процурео кључ, рачун од 190.000 ТЛ за 2 недеље. Програмер је уградио модел АПИ кључ у помоћну скрипту и гурнуо га у јавно спремиште. Бот је пронашао кључ за 40 минута и користио га две недеље; Рачун је достигао 190.000 ТЛ. Када је кључ премештен у тајни менаџер, повезан са ротацијом и додато скенирање спремишта, инцидент се није поновио.

Случај 3 — Подразумевани прекид који је спречен само за читање. ДевОпс помоћник је добио команду „ресетуј производну базу података“ путем брзе ињекције. Међутим, помоћнику је дат само токен само за читање; писање/брисање је било у посебном одобреном току. Команда је одбијена са грешком у ауторизацији и догађај је евидентиран као аларм; Није било губитка података.

Савет: Нека „не“ буде подразумевани одговор на нови захтев за приступ. Приступ је нешто што се добија кроз оправдање; Давање свима у ширину, а затим смањење готово никада се не ради и ризик се акумулира.

Уобичајене грешке

  • Покретање модела са великим налогом услуге и губљење корисничког контекста (мешовити прокси).
  • Уграђивање АПИ кључа у код и његово пропуштање у контролу верзија.
  • Уопште не ротирати тастере („ради, не дирај“).
  • Подразумевано даје помоћнику дозволе за писање/брисање.
  • Омогућавање приступа једном и никада не разматрање.
  • Бркање аутентификације са ауторизацијом и под претпоставком да је "пријављен, може приступити свему".

Укратко

  • Аутентификација је питање „ко си ти“, ауторизација је питање „шта можеш да урадиш“; У АИ, оба морају да раде у контексту корисника.
  • Модел треба да функционише са ауторитетом корисника који подноси захтев, а не са сопственим широким овлашћењем (избегавајући ризик од мешовите агенције).
  • Почните са РБАЦ-ом, продубите са АБАЦ-ом на осетљивим подацима; Нека минимална овлашћења буду подразумевана.
  • Не сахрањујте тајне у коду; сачувајте га у тајном менаџеру, сузите га и ставите у редовну ротацију.
  • Подразумевано само за читање и уско писање у великој мери ограничавају утицај убризгавања.

Задатак апликације

Наведите све алате и податке којима ваш АИ помоћник приступа. Одговорите на три питања за свако: (1) Да ли је заиста неопходно? (2) Да ли је довољно само за читање? (3) Да ли ради у корисничком контексту? Затим потражите све тврдо кодиране тајне (преко горњег упита за скенирање) и напишите план ротације за сваки кључ који пронађете. Уклоните најмање једно непотребно овлашћење.

контролна листа

  • [ ] Модел ради у контексту ауторитета корисника који поставља захтев.
  • [ ] Приступ алатима и подацима је сужен на принцип најмање привилегија.
  • [ ] Уписивање/брисање је одвојено од само за читање, аутентификовано и уско.
  • [ ] Ниједна тајна није закопана у коду; Чува се у тајном менаџеру.
  • [ ] Постоји распоред ротације и поступак отказивања за кључеве.
  • [ ] Приступи се редовно прегледају.