Водич и увид

Управљање кључевима ЛЛМ АПИ-ја за тимове: изолација, ротација, ограничења потрошње и одговор на цурење

Практичан оперативни модел за управљање ЛЛМ АПИ кључевима у тимовима: изолација кључева, приступ само проксију, приписивање коришћења, контроле потрошње, ротација и одговор на цурење.

<п>Један дељени ЛЛМ АПИ кључ је згодан до првог цурења, необјашњивог рачуна или прекида производње. Практични циљ <стронг>управљања кључем АПИ-ја није само чување тајне акредитива. То је ограничавање радијуса експлозије, коришћење атрибута, безбедно ротирање, откривање ненормалне потрошње и опозив приступа без прекидања неповезаних апликација. <п>Овај водич даје тимовима оперативни модел за ЛЛМ АПИ кључеве за све провајдере, мрежне пролазе, интерне апликације, агенције и производе за клијенте. Он одваја проверене безбедносне чињенице од препоручених избора имплементације и избегава претпоставку да сваки провајдер излаже исте контроле. <х2>Модел рада: сваком кључу је потребна граница <п>Корисна кључна стратегија почиње једним питањем: <ем>шта би требало да пропадне ако се овај кључ злоупотреби или опозове? Ако је одговор „цела компанија“, кључ је превише широк. <п><стронг>Чињеница: Безбедносне смернице ОпенАИ-ја за АПИ кључ препоручују да сваки члан тима користи јединствени АПИ кључ, каже да је дељење кључева против његових Услова коришћења и препоручује доделу дозвола појединачним кључевима тамо где је то подржано. Упутства ОпенАИ-а такође саветују да се не примењују АПИ кључеви у окружењима на страни клијента, као што су прегледачи или мобилне апликације, јер се изложени кључеви могу злоупотребити за упућивање захтева у име власника. <п><стронг>Препорука: креирајте кључеве око оперативних граница, а не око погодности. Уобичајене границе укључују: <ул> <ли><стронг>Окружење: производња, постављање, развој, сандбок. <ли><стронг>Апликација: позадина чет робота, процесор докумената, помоћник за кодирање, ток рада аналитике. <ли><стронг>Власник: тим, налог услуге, програмер, клијент агенције, закупац. <ли><стронг>Ниво ризика: јавни ток посла, интерна аутоматизација, групни посао, експериментална интеграција. <ли><стронг>Добављач или рута: узводни добављач А, добављач Б, одобрена група модела или рута пролаза. <п>Добар подразумевани кључ за растући тим је: један производни кључ по апликацији или услузи, један непроизводни кључ по окружењу и одвојени кључеви за аутоматизацију високог ризика или коришћење на нивоу корисника. Агенције и препродавци би требало да преферирају виртуелне кључеве на нивоу клијента, а не да деле акредитиве добављача узводно. <х2>Никада не стављајте кључеве добављача у дистрибуиране клијенте <п>Прегледачи, апликације за мобилне уређаје, екстензије за рачунаре, јавни додаци и скрипте на страни корисника су непријатељска места за необрађене акредитиве добављача. Чак и ако замаглите кључ, дистрибуирани софтвер може бити прегледан, копиран или пресретнут. <п><стронг>Чињеница: ОпенАИ изричито упозорава да се АПИ кључеви не примењују у окружењима на страни клијента. Истраживање мобилних апликација је такође пријавило стално цурење акредитива за ЛЛМ АПИ у иОС апликацијама, подржавајући исто практично упозорење: акредитиви уграђени у дистрибуиране клијенте имају тенденцију да побегну. <п><стронг>Препорука: користите бацкенд или гатеваи образац: <ол> <ли>Клијент се аутентификује за вашу апликацију помоћу корисничке сесије, ЈВТ-а, токена клијента или краткотрајних акредитива. <ли>Ваш позадински део потврђује корисника, закупца, план и тражену операцију. <ли>Ваш бацкенд или АИ АПИ мрежни пролаз позива упстреам ЛЛМ провајдера користећи заштићене акредитиве на страни сервера. <ли>Одговор се враћа клијенту након провере смерница, евидентирања и обрачуна трошкова. <п>Овај дизајн вам омогућава да примените правила производа пре него што дође до потрошње. На пример, корисник бесплатног плана може да буде ограничен на мање моделе, плаћени закупац може да добије веће дневне квоте, а интерни ток рада администратора може да користи засебну руту са строжим надзором. <х2>Направите кључни инвентар пре него што вам затреба одговор на инцидент <п>Тимови често открију током цурења информација да нико не зна која услуга поседује откривени кључ. То је грешка у инвентару. <п><стронг>Чињеница: ОВАСП АПИ Сецурити Топ 10 2023 укључује неправилно управљање залихама као главни безбедносни ризик АПИ-ја. За ЛЛМ инфраструктуру, кључни инвентар је део АПИ инвентара: морате да знате који акредитиви постоје, чему могу да приступе и ко их поседује. <п><стронг>Препорука: сваки кључ треба да има метаподатке. У најмању руку, пратите: <ул> <ли>Име кључа и интерни ИД кључа. <ли>Власнички тим и контакт за хитне случајеве. <ли>Окружење: производња, постављање, развој, сандбок. <ли>Сврха: апликација, ток посла, закупац, интеграција или употреба програмера. <ли>Дозвољени добављачи, модели, крајње тачке или руте где су подржани. <ли>Датум креирања, временска ознака последње употребе и планирани датум прегледа. <ли>Праван или квота потрошње. <ли>Статус ротације и конфигурација повезане примене. <п>Користите конвенцију о именовању која остаје читљива у упозорењима. На пример: <пре><цоде>прод-суппортбот-теамцк-гпт4цласс-2026к3стг-доцпроцессор-платформ-ловцост-2026к3 станар-ацме-прод-стандард-2026к3 дев-јлее-сандбок-2026к3 <п>Тачан формат је мање важан од доследности. Циљ је да упозорење може да каже „станар-ацме-прод-стандард је премашио дневни праг“ и да одговорни власник зна шта да ради. <х2>Примени најмање привилегије тамо где то платформа дозвољава <п>Не излажу сваки провајдер или мрежни пролаз идентичне контроле дозвола, али принцип је конзистентан: кључ би требало да буде у стању да уради само оно што је потребно његовом радном оптерећењу. <п><стронг>Препорука: ограничите кључеве помоћу једне или више од следећих контрола где је то подржано: <ул> <ли><стронг>Пројекат: повежите кључеве за пројекат, а не за целу организацију. <ли><стронг>Модел: дозвољава само одобрене моделе; подразумевано блокирајте скупе или експерименталне моделе. <ли><стронг>Крајња тачка: дозвољава довршавање ћаскања, али одбија неповезане административне крајње тачке. <ли><стронг>Пут добављача: дозволите руту пролаза уместо директног приступа сваком узводном добављачу. <ли><стронг>Стопа: ограничење броја захтева по минуту или истовремених захтева. <ли><стронг>Буџет: примените ограничења потрошње по кључу, тиму или закупцу. <п>На пример, кључу за провођење обично није потребан приступ најскупљем производном моделу. Раднику за класификацију докумената вероватно није потребан приступ генерисању слика. Кључ закупца окренут клијенту не би требало да може да потроши буџет другог закупца. <х2>Дизајнирајте контроле потрошње у слојевима <п>ЛЛМ АПИ безбедност и контрола трошкова се преклапају. Кључ који је процурио се често открива као аномалија наплате пре него што се открије као безбедносни догађај. <п><стронг>Чињеница: Безбедносне смернице ОпенАИ налога препоручују разумна ограничења потрошње и напомињу да одвојени АПИ кључеви могу да олакшају преглед коришћења према функцији, тиму, производу или пројекту. ОпенАИ-ово извештавање о коришћењу такође подржава детаљну анализу кроз поља као што су ИД пројекта, ИД корисника, ИД АПИ кључа, модел, серија и ниво услуге. <п><стронг>Препорука: користите слојевита ограничења уместо једног глобалног ограничења: <ул> <ли><стронг>Ограничење по кључу: спречава да један акредитив потроши цео буџет. <ли><стронг>Ограничење по тиму: чини коришћење одељења видљивим и одговорним. <ли><стронг>Ограничење по закупцу: изолује коришћење корисника у СааС и агенцијским сценаријима. <ли><стронг>Праг дневне аномалије: покреће упозорења када употреба одступа од уобичајених образаца. <ли><стронг>Глобално заустављање у хитним случајевима: омогућава брзу суспензију када је злоупотреба активна. <п>Тврда ограничења су корисна, али могу прекинути легитимне групне послове. Безбеднији производни образац је низ контрола: <ол> <ли>Упозорење на 50 процената очекиване дневне потрошње. <ли>Ескалирајте на 80 процената. <ли>Смањите саобраћај који није критичан на 100 процената. <ли>Блокирајте само увредљиви кључ, закупца или руту пре коришћења глобалног искључивања. <п><стронг>Компром: строги буџети смањују ризик наплате, али могу створити ризик доступности. Ограничења нивоа према оптерећењу: интерактивни производни саобраћај, плаћени саобраћај окренут клијентима, послови у позадини, експерименти и заштићена окружења за програмере не би требало да пропадну на исти начин. <х2>Пратите употребу према кључу и логичком актеру <п>Кључ идентификује акредитив. Можда неће идентификовати стварног корисника, закупца, функцију или ток посла који је изазвао захтев. За корисну аналитику коришћења вештачке интелигенције, евидентирајте техничке и пословне димензије. <п><стронг>Препорука: прикупите следећа поља за сваки захтев где приватност и политика дозвољавају: <ул> <ли>ИД захтева и временска ознака. <ли>ИД кључа АПИ-ја или ИД виртуелног кључа. <ли>Идентификатор апликације, тима, станара, корисника или тока посла. <ли>Добављач, модел, рута и ниво услуге. <ли>Број токена за брзо и довршење или еквивалентне јединице коришћења. <ли>Процењена цена. <ли>Кашњење, статусни код, број поновних покушаја и класа грешке. <п>Не претварајте видљивост трошкова у непотребно прикупљање података. Избегавајте подразумевано складиштење комплетних упита ако могу да садрже личне податке, тајне клијената или регулисан садржај. У многим случајевима, хеширани ИД-ови корисника, ИД-ови станара, број токена и називи модела су довољни за повраћај средстава и откривање аномалија. <х2>Ротација без застоја: безбедан радни ток <п><стронг>Чињеница: НИСТ-ове смернице за управљање кључевима третирају управљање кључевима као дисциплину животног циклуса, укључујући генерисање, складиштење, активацију, ротацију, суспензију, опозив и уништавање. За ЛЛМ АПИ кључеве, ротација није једнократни безбедносни задатак; то је оперативни ток рада. <п><стронг>Препорука: користите овај процес ротације без застоја: <ол><ли><стронг>Направите заменски кључ. Ускладите потребне дозволе, буџет, руту и ​​метаподатке. Немојте још опозивати стари кључ. <ли><стронг>Сачувајте га у тајном менаџеру. Избегавајте локалне датотеке, поруке ћаскања, карте и налепљене променљиве окружења. <ли><стронг>Постепено имплементирајте конфигурацију. Ажурирајте једну услугу, регион, групу радника или сегмент закупца. <ли><стронг>Верификујте кретање саобраћаја. Потврдите да захтеви стижу под новим кључем и да су стопе грешака и кашњење нормални. <ли><стронг>Замрзни упис у стари кључ. Заустави нове имплементације да га упућују. <ли><стронг>Опозовите стари кључ. Када се саобраћај помери, онемогућите га радије него да га оставите као заборављени резервни кључ. <ли><стронг>Ревизија заостаје. Претрага евиденције, манифеста примене, тајних складишта, ЦИ променљивих и грешака у времену извођења за стари ИД кључа. <п>За апликације које још увек користе статичке променљиве окружења, ротација ће бити крхка. Померите се ка динамичком тајном учитавању, централизованој конфигурацији или виртуелним кључевима којима управља мрежни пролаз. У најмању руку, документ чије распоређивање мора да се промени пре опозива. <х2>Ручни приручник за одговор на цурење <п>Када кључ процури, брзина је битна. Одговор треба да буде написан пре инцидента, а не импровизован у паници наплате. <х3>Непосредно задржавање <ол> <ли>Опозовите или суспендујте изложени кључ. <ли>Ако би опозив прекинуо производњу, прво издајте замену и одмах промените критични саобраћај. <ли>Блокирајте руту, закупца или добављача ако је злоупотреба и даље активна. <ли>Сачувајте евиденције потребне за идентификацију злоупотребе. <х3>Истрага <ол> <ли>Идентификујте где се кључ појавио: спремиште, пакет интерфејса, мобилна апликација, датотека евиденције, карта за подршку, алатка добављача или ћаскање. <ли>Пронађите последњу познату легитимну употребу. <ли>Упоредите употребу пре и после сумње на излагање. <ли>Прегледајте коришћене моделе, захтевајте обим, цену, географију ако су доступни и необичне статусне кодове. <ли>Проверите да ли зависне тајне или суседни системи такође могу бити изложени. <х3>Опоравак и превенција <ол> <ли>Ротирајте зависне акредитиве ако је исто окружење можда открило више од једне тајне. <ли>Обавестите власнички тим и заинтересоване стране купаца на које се то односи. <ли>Додајте тајно скенирање у спремишта и ЦИ цевоводе. <ли>Спречите понављање тако што ћете позиве на страни клијента преместити иза позадине или мрежног пролаза. <ли>Документујте временски оквир инцидента, основни узрок, утицај на трошкове и побољшања контроле. <п><стронг>Предвиђање: како тимови повезују више агената, додатака, алата за аутоматизацију и токова рада специфичних за клијенте са ЛЛМ-овима, кључна цурења ће све више изгледати као трошковни инциденти, а затим безбедносни инциденти. Тимови са приписивањем по кључу и контролама буџета ће их решити брже од тимова који користе један дељени акредитив. <х2>Кључеви којима управља мрежни пролаз за тимове са више добављача <п>Ако ваша организација користи неколико ЛЛМ провајдера, директни кључеви добављача могу да створе разуђено управљање: различите контролне табле, различите приказе обрачуна, различите моделе дозвола и недоследне процесе ротације. <п>Слој кључева којим управља мрежни пролаз може да поједностави ово издавањем кључева окренутих према апликацији, док акредитиве упстреам провајдера држе скривеним. Апликације позивају крајњу тачку АПИ-ја компатибилну са ОпенАИ, док мрежни пролаз управља рутирањем, аналитиком коришћења, приписивањем обрачуна и применом смерница. <п><стронг>Препорука: размислите о слоју мрежног пролаза или проксија када вам је потребно: <ул> <ли>Једно место за управљање кључевима тима код више добављача. <ли>Обједињени АИ АПИ обрачун и извештавање о потрошњи по кључу. <ли>Виртуелни кључеви на нивоу корисника за агенције, препродавце или СааС закупце. <ли>Листе дозвољених централног модела, смернице за руте и обустављање у хитним случајевима. <ли>Приписивање коришћења према закупцу, функцији, току посла или партнеру. <п><стронг>Компром: мрежни пролаз побољшава управљање и сакрива акредитиве узводно, али постаје део путање захтева. Надгледајте га као производну инфраструктуру: кашњење, доступност, стопе грешака, чекање у реду, понашање при поновном покушају и кварови специфични за провајдера су све важни. <х2>Контролна листа имплементације <ул> <ли>Замените дељене кључеве за целу организацију кључевима у опсегу према апликацији, окружењу, закупцу или току посла. <ли>Уклоните необрађене кључеве добављача из прегледача, мобилних апликација, екстензија за десктоп рачунаре и јавних скрипти. <ли>Усмерите клијентске захтеве преко позадинског или АИ АПИ мрежног пролаза. <ли>Приложите власника, сврху, окружење, дозвољене моделе, буџет и метаподатке прегледа сваком кључу. <ли>Примени најмање привилегије: пројекат, крајња тачка, модел, рута, стопа и контрола буџета где су доступне.<ли>Подесите ограничења потрошње по кључу, тиму, закупцу и глобална ограничења. <ли>ИД кључа евиденције, логички актер, модел, употреба токена, процењена цена, кашњење и статусни код. <ли>Направите ток рада без прекида рада и тестирајте га пре хитног случаја. <ли>Напишите приручник за реаговање на цурење са корацима за задржавање, истрагу и превенцију. <ли>Прегледајте неактивне кључеве и опозовите било шта без власника или недавне легитимне употребе. <х2>Закључак који се може спровести <п>Почните са кључем највећег ризика: оним који се користи у производњи, који дели више људи, уграђен на превише места или одговоран за највећу потрошњу. Дајте му власника, поделите га по границама, додајте буџет, померите га иза позадине или гатеваи-а ако клијенти могу да га виде и документујте како да га ротирате. <п>Затим поновите. Снажно управљање кључевима ЛЛМ АПИ-ја није једна одлука о тајном складиштењу. То је животни циклус: инвентар, изолација, најмање привилегија, приписивање коришћења, контрола трошкова, ротација и одговор на цурење. Исплата је једноставна: када нешто крене по злу, само једна апликација, закупац или ток посла би требало да буду у опасности — не цео буџет АИ.<х2>Повезано читање<ул><ли><а хреф="хттпс://модел-гате.цом/ен/блог/релиабле-ллм-апи-роутинг-тимеоутс-ретриес-модел-фаллбацк">повратак АПИ-ја Лм-а и повратак на повратак ЛЛМ-а. дизајн<ли><а хреф="хттпс://модел-гате.цом/ен/блог/артицле-2-2/">раније белешке о моделу капије<ли><а хреф="хттпс://модел-гате.цом/ен/блог/артицле-1-1/">уводни чланак о моделу капије/<
FAQ

Често постављана питања

Колико ЛЛМ АПИ кључева треба да креира тим?
Креирајте кључеве око оперативних граница: апликација, окружење, власник, закупац и ниво ризика. Избегавајте један дељени кључ за целу организацију. Више кључева побољшава атрибуцију и контролу радијуса експлозије, али захтева аутоматизацију инвентара и животног циклуса.
Да ли је безбедно користити ЛЛМ АПИ кључ у мобилној апликацији или прегледачу?
Не. Необрађени кључеви добављача не би требало да се постављају у дистрибуиране клијенте као што су прегледачи, мобилне апликације, екстензије за десктоп рачунаре или јавне скрипте. Користите бацкенд или гатеваи који аутентификује корисника и позива провајдера са акредитивима на страни сервера.
Шта треба да се евидентира за контролу трошкова АИ АПИ-ја?
ИД захтева за евиденцију, ИД кључа, идентификатор закупца или корисника где је прикладно, модел, добављач или рута, употреба токена или еквивалентне јединице, процењена цена, кашњење, статусни код и класа грешке. Избегавајте чување осетљивих брзих садржаја осим ако не постоји јасна потреба и одговарајуће контроле.
Који је најсигурнији начин ротирања ЛЛМ АПИ кључа?
Направите резервни кључ, сачувајте га у тајном менаџеру, постепено га примените, проверите да ли се саобраћај померио, опозовите стари кључ и извршите проверу за заостале. Немојте прво опозивати, осим ако активна злоупотреба не захтева хитно обуздавање.
Зашто користити слој кључа којим управља мрежни пролаз?
Слој којим се управља мрежним пролазом сакрива акредитиве добављача узводно и централизује управљање кључевима, аналитику коришћења, приписивање обрачуна, смернице модела и суспензију у хитним случајевима. Компромис је у томе што капија постаје производна инфраструктура и мора се надгледати.