Трезори акредитива добављача за вишемоделне АИ мрежне пролазе: одвојено време извршавања, администраторски, обрачунски и БИОК приступ

<п>Довнстреам АПИ кључеви и акредитиви упстреам добављача решавају различите проблеме. Кључ програмера који издаје ваш мрежни пролаз идентификује апликацију, тим, закупца, буџет и контекст смерница. Кључ провајдера узводно омогућава мрежном пролазу да троши новац и приступ моделима на налогу провајдера. Третирање њих као исте врсте тајне је начин на који тимови завршавају са једним неограниченим кључем у дељеном пројекту, администраторским акредитивима у услугама за време извршавања и без поузданог начина да се одговори који закупац је проузроковао наплату на страни провајдера. <п>Практични образац је трезор акредитива добављача: наменска контролна раван за увоз, класификацију, складиштење, избор, ротирање и ревизију упстреам акредитива. Требало би да се налази иза рутера, књиге обрачуна, механизма политике и тока рада – не унутар кода апликације, конфигурационих датотека модела, записа закупаца или догађаја анализе. <х2>Проблем читача: упстреам акредитиви постају невидљива инфраструктура <п>Већина имплементација са више модела почиње са једноставним циљем: усмеравање једног захтева компатибилног са ОпенАИ-ом до најбољег доступног провајдера. Затим се појављује још налога: један пројекат добављача за производњу, други за процену, Антхропиц радни простор за пословну јединицу, Гоогле Цлоуд пројекат за Гемини и неколико кључева које достављају клијенти за БИОК уговоре. <п>Ризик није само тајно цурење. То је губитак контекста ауторизације. Важећи кључ добављача може технички да може да позове крајњу тачку, али мрежни пролаз и даље мора да зна да ли је тај кључ дозвољен за овог закупца, ову породицу модела, ову политику задржавања података, овај буџет, овај регион и ову путању аутоматизације. <п><стронг>Чињеница: платформе добављача откривају различите границе налога и типове акредитива. ОпенАИ документује пројекте и услужне налоге, и подразумеване дозволе АПИ кључа за налог услуге за приступ за читање и писање за АПИ ресурсе пројекта. ОпенАИ такође излаже Админ АПИ кључне објекте одвојено од уобичајене употребе АПИ-ја пројекта/рунтиме. Антхропиц документује радне просторе као организациону границу и наводи да крајње тачке АПИ-ја администратора захтевају Админ АПИ кључеве који се разликују од стандардних АПИ кључева; Антхропиц такође напомиње да су АПИ кључеви везани за радни простор где су креирани и да се не могу премештати између радних простора. Гоогле-ова документација Гемини АПИ кључа каже да је сваки Гемини АПИ кључ повезан са Гоогле Цлоуд пројектом и препоручује ограничења АПИ-ја како би се смањила штета ако је кључ компромитован. <п><стронг>Препорука: немојте правити једно генеричко поље „провидер_кеи“ и називати га завршеним. Направите инвентар акредитива који чува границе специфичне за провајдера док излаже нормализован модел политике мрежном пролазу. <х2>Дефинишите таксономију акредитива пре прихватања кључева <п>Трезор би требало да одбије двосмислене акредитиве. У време увоза, оператер или ток рада аутоматизације морају да класификују акредитиве. У најмању руку, користите ове категорије: <ул> <ли><стронг>Акредитиви за закључивање током извршавања: које мрежни пролаз користи за позивање крајњих тачака закључивања модела као што су ћаскање, одговори, уграђивање, модерација, транскрипција или генерисање слике, у зависности од подршке добављача. <ли><стронг>Акредитиви за аутоматизацију администратора: користе се за управљање организацијама на страни добављача, радним просторима, пројектима, корисницима, кључевима или административним ресурсима. Они никада не би требало да буду на путањи захтева за време извршавања. <ли><стронг>Акредитиви за обрачун и извештавање: користе се за преузимање извештаја о коришћењу, фактурама, трошковима или организацијама где добављачи подржавају те АПИ-је. Држите их одвојено од кључева за закључивање тако да послови извештавања не могу да генеришу коришћење модела. <ли><стронг>Акредитиви само за процену: користе се за мерење перформанси, обезбеђење квалитета, миграцију или сценски радни ток. Требало би да имају ниске квоте, јасне ознаке окружења и да не испуњавају услове за резервну производњу. <ли><стронг>Клијентски БИОК акредитиви: кључеви које је доставио корисник везани за одређеног закупца, налог добављача, уговор и политику података. Не би требало да се удружују у дељено рутирање осим ако се клијент изричито не одлучи за то. <п>Ова таксономија није само документација. Требало би да покреће контролу приступа, подобност рутирања, упозорење и ротацију. Ако је акредитив увезен без категорије, власника, границе налога добављача и дозвољене употребе, требало би да остане онемогућен. <х2>Чувајте тајне у трезору, а не у евиденцији производа <п>Трезор би требало да буде једина компонента која може да дешифрује упстреам акредитиве. Други системи могу да чувају референце, хешове, статусна поља и метаподатке смерница, али не и саму вредност акредитива. <х3>Не складишти тајне узводне на овим местима <ул> <ли>Редови профила закупца. <ли>Датотеке за конфигурацију рутирања модела. <ли>Захтев евиденције или распона праћења. <ли>Корисно оптерећење догађаја Аналитике. <ли>Променљиве ЦИ које се односе на програмера.<ли>Улазнице за подршку, алатке за ћаскање или снимке екрана. <п>Корисни дизајн трезора има две равни. <стронг>Тајни авион складишти шифровани материјал акредитива и строго контролише операције дешифровања. <стронг>Раван метаподатака складишти нетајне атрибуте које користе рутирање и управљање. Рутеру обично треба само ИД акредитива и краткотрајно преузимање тајне у меморији у време слања, а не широк приступ бази података сваком кључу провајдера. <п>Заштитите трезор као инфраструктуру високе вредности: шифровање омотача или управљани КМС, строги идентитети услуга, процедуре за разбијање стакла, тестирање резервних копија и враћање, преглед приступа и упозорење о необичном волумену дешифровања. Централни трезор поједностављује управљање, али такође концентрише ризик. То је компромис. <х2>Приложите метаподатке смерница сваком акредитиву <п>Модел метаподатака треба да буде довољно експлицитан да мрежни пролаз може да одлучи да ли је акредитив подобан пре него што додирне крајњу тачку добављача. <п>Практична евиденција акредитива укључује: <ул> <ли><стронг>цредентиал_ид: интерни непроменљиви идентификатор. <ли><стронг>провајдер: ОпенАИ, Антхропиц, Гемини, Азуре ОпенАИ или други адаптер. <ли><стронг>провидер_аццоунт_боундари: организација, пројекат, радни простор, пројекат у облаку, претплата или еквивалентно. <ли><стронг>цредентиал_цласс: време извођења, администратор, обрачун, евалуација или БИОК. <ли><стронг>окружење: производња, постављање, развој, евалуација, сандбок. <ли><стронг>тенант_биндинг: дељени акредитиви платформе, један закупац, група закупаца или клијент БИОК закупац. <ли><стронг>алловед_модел_фамилиес: на пример, генерисање текста, уграђивање, визија, слика, аудио или профили одређених модела. <ли><стронг>алловед_ендпоинтс: нормализоване могућности мрежног пролаза мапиране на крајње тачке добављача. <ли><стронг>дата_полици: дозвољена класа задржавања, класа евидентирања, услов пребивалишта и ограничења функција. <ли><стронг>будгет_сцопе: центар трошкова, купац препродавца, интерно одељење или уговор. <ли><стронг>власник: именовани тим или одговорна особа. <ли><стронг>цреатед_ат, екпирес_ат, ротатион_дуе_ат, ласт_усед_ат. <ли><стронг>хеалтх_статус: непознато, здраво, деградирано, неовлашћено, куота_екхаустед, дисаблед. <ли><стронг>емергенци_дисабле: Блок тренутног рутирања независно од нормалног стања политике. <п>Држите овај модел неутралним за добављача, али немојте брисати стварност добављача. Антропски кључ везан за радни простор и кључ Гемини везан за Гоогле Цлоуд пројекат нису заменљиви само зато што оба могу да генеришу текст. Гејтвеју је потребно то порекло за ревизије, повраћај средстава и безбедно пребацивање. <х2>Одвојени приступ времену извођења, администратору и обрачуну <п>Најважније правило је једноставно: кључ који се користи за закључивање током извршавања не би требало да управља организацијама добављача, радним просторима, корисницима, пројектима или административним ресурсима. <п>Саобраћај током рада је великог обима и изложен је највећој оперативној површини. Пролази кроз рутере захтева, логику поновног покушаја, руковаоце стримингом, адаптере модела и токове рада инцидента. Админ акредитиви су ниске фреквенције и велики утицај. Они треба да живе иза одвојене путање одобрења са кратким ТТЛ-овима, названим људско одобрење где је то прикладно, снажно евидентирање и без квалификованости за рутирање током извршавања. <п>Акредитиви за обрачун такође заслужују раздвајање. Посао извештавања који усаглашава фактуре не би требало да буде у могућности да генерише довршетке, а кључ за закључивање током извршавања не би требало да буде једини начин за преузимање извештаја о коришћењу. Када провајдер не нуди прецизно раздвајање, компензујте у мрежном пролазу: изолујте акредитиве, ограничите који интерни идентитет услуге може да их преузме и евидентирајте сваку употребу. <п><стронг>Препорука: нека класа акредитива буде чврста граница ауторизације, а не ознака. Диспечер времена извршавања не би требало да буде у могућности да захтева дешифровање за администраторске акредитиве чак и ако грешка у конфигурацији упућује на његов ИД. <х2>Направите механизам политике за избор акредитива <п>Одабир акредитива би требало да се деси након што мрежни пролаз аутентификује позиваоца у низу и пре покушаја позивања провајдера. Механизам политике треба да споји неколико уноса: <ул> <ли>ИД закупца и опсег АПИ кључа на нижем нивоу. <ли>Затражен профил модела или ИД модела специфичног за добављача. <ли>Могућност крајње тачке: ћаскање, уграђивање, слика, аудио, група, датотеке, алати или аутоматизација администратора. <ли>Захтеви за задржавање података и пребивалиште. <ли>Буџет, резервација кредита и центар трошкова. <ли>Стање ограничења брзине и притисак квоте. <ли>Метаподаци акредитива, здравље, животна средина и везивање закупца. <п>Машина би требало да врати један од три резултата: дозволи са изабраним акредитивима, одбије са разлогом за смернице или захтева одобрење. Одбијање треба да буде довољно прецизно да оперативни тимови реше проблем без откривања тајног материјала програмерима. <п>Пример одлуке: <пре><цоде>{ "тенант_ид": "тенант_42", "рекуестед_профиле": "фаст-тект-прод", "крајња тачка": "цхат.цомплетионс", "дата_полици": "но_промпт_логгинг", "цредентиал_рекуирементс": { "цласс": "рунтиме", "окружење": "производња", "тенант_биндинг": "тенант_42", "алловед_модел_фамили": "текст", "хеалтх_статус": "здраво" }, "одлука": "дозволи", "цредентиал_ид": "цред_8ф2...", "аудит_реасон": "акредитиви закупца БИОК се подударају са текстуалним профилом времена извршавања и смерницама за податке" } <п>Не имплементирајте резервни кључ као „пробајте следећи кључ“. Повратна политика мора поново да покрене политику. Акредитив дељене платформе може бити важећи за приступ провајдеру, али неважећи за клијента који користи само БИОК. Акредитив у другом пројекту може да има квоту, али може да крши захтеве за приписивање трошкова или задржавање. <х2>Рукуј БИОК-ом као приступом у власништву станара, а не резервним капацитетом <п>БИОК мења модел поверења. Клијент је доставио акредитиве тако да се њихов саобраћај може наплатити, управљати или изоловати у оквиру свог налога провајдера. Тај акредитив треба да буде везан за порекло налога закупца клијента и провајдера. <п>Препоручене БИОК контроле: <ул> <ли>Један запис у трезору по клијенту, добављачу, граници налога и окружењу. <ли>Нема рутирања међу закупцима преко БИОК акредитива. <ли>Нема употребе као дељени резервни капацитет осим ако се клијент изричито не одлучи. <ли>Здравствено стање видљиво кориснику које не открива необрађени кључ. <ли>Одвојени ток рада ротације који омогућава клијенту да дода замену пре него што се стари кључ онемогући. <ли>Јасна атрибуција у аналитици коришћења и фактурама: закупац мрежног пролаза, граница налога добављача, ИД акредитива, профил модела и ИД праћења захтева. <п>За агенције, препродавце и аутоматизацију АПИ партнера, БИОК може бити сложенији јер услуга може програмски да обезбеди закупце и акредитиве. Исто правило и даље важи: аутоматизација може да увози и везује акредитиве, али не би требало да замагли власништво станара. <х2>Додајте здравствене провере пре лета без цурења упита <п>Акредитив може да не успе из више разлога: опозван кључ, погрешан радни простор, недостајући приступ моделу, онемогућени обрачун, исцрпљивање квоте, ограничење крајње тачке, неусклађеност регионалних смерница или прекид рада добављача. Откривање тога тек након што стигне производни захтев ствара бучне инциденте. <п>Користите провере стања које потврђују способност без слања корисничких упита. Синтетичка провера може позвати минималну крајњу тачку, навести дозвољене моделе тамо где је то прикладно или послати безопасни фиксни упит ако је то једина практична опција. Нека ови чекови буду јефтини, ограничени на стопу и означени као синтетички саобраћај у телеметрији и наплати. <п>Провере здравља би требало да се покрену: <ул> <ли>При увозу акредитива. <ли>Пре омогућавања акредитива за усмеравање производње. <ли>Након промене ограничења на страни добављача. <ли>Током ротације. <ли>Периодично за акредитиве који испуњавају услове за производњу. <п><стронг>Компром: аутоматизоване провере рано хватају кључеве са истеклим роком трајања или са недовољно опсегом, али лоше дизајниране провере могу да доведу до непотребних позива добављача, буке наплате или лажних аларма током прекида рада добављача. Сачувајте резултат здравља са временском ознаком, класом грешке добављача, тестираном крајњом тачком и тестираном породицом модела. Не чувајте тајне вредности или осетљиве упите. <х2>Ротирајте са два утора, а не једном ризичном заменом <п>Ротација акредитива не би требало да буде операција брисања и молитви. Користите модел ротације са два прореза: <ол> <ли><стронг>Увезите акредитиве за замену као неактивне, са потпуним метаподацима и власником. <ли><стронг>Покрените синтетичке провере здравља за предвиђене крајње тачке, породице модела и границе налога. <ли><стронг>Омогућите испуњавање услова у сенци за мали део безбедног синтетичког саобраћаја или саобраћаја ниског ризика где је то прикладно. <ли><стронг>Постепено мењајте производни саобраћај са старих акредитива на нове акредитиве. <ли><стронг>Надгледајте грешке, кашњење, квоту и приписивање трошкова према ИД-у акредитива. <ли><стронг>Замрзните враћање на стари акредитив када нови акредитив буде стабилан. <ли><стронг>Опозовите старе акредитиве код добављача и означите запис трезора опозваним. <ли><стронг>Провери да нема дешифровања или позива добављача преко старог акредитива након опозива. <п>Рокови ротације треба да буду видљиви у приказима операција и упозорењима. Хитној ротацији је потребан краћи пут: онемогућите акредитиве, блокирајте рутирање, омогућите одобрену замену и сачувајте све записе ревизије за преглед инцидента. <х2>Ограничите кључеве добављача тамо где их провајдер подржава <п>Политика мрежног пролаза је неопходна, али ограничења на страни провајдера смањују радијус експлозије ако је кључ компромитован или злоупотребљен. За Гемини и друге АПИ кључеве платформе у облаку, користите ограничења за АПИ/услуге и одговарајућа ограничења апликација где су доступна. За пројекте добављача, радне просторе и услужне налоге избегавајте широке организационе привилегије када је кључ времена за извођење пројекта довољан. <п><стронг>Препорука: одржавајте контролну листу ограничења на страни добављача за сваку класу акредитива. Контролна листа треба да буде део одобрења увоза и одобрења за ротацију, а не посебан безбедносни задатак који се може прескочити под притиском. <п><стронг>Комбинација: ограничења на страни добављача додају оперативне трошкове. Нове крајње тачке, породице модела, региони или функције аутоматизације могу захтевати промене смерница и ограничења. То је боље од откривања након цурења информација да један кључ може да приступи сваком радном оптерећењу у дељеном пројекту. <х2>Чувајте евиденцију ревизије акредитива само за додавање <п>Ревизијски траг треба да одговори ко је увезао акредитив, шта му је дозвољено да ради, које су га одлуке о рутирању изабрали, када није успео и када је ротиран или опозван. <п>Евидентирај ове догађаје: <ул> <ли>Акредитив је направљен или увезен. <ли>Метаподаци су промењени, укључујући дозвољене крајње тачке, везивање закупца или смернице за податке. <ли>Провера здравља је обављена и резултат је забележен. <ли>Акредитив изабран смерницама рутирања за захтев. <ли>Дешифровање акредитива захтева интерни идентитет услуге. <ли>Позив добављача није успео због грешке у аутентификацији, ауторизацији, квоти или ограничењу. <ли>Ротација је започета, саобраћај је промењен, стари акредитив је опозван. <ли>Омогућено или избрисано онемогућавање у хитним случајевима. <ли>Приступљено је администраторским или бреак-гласс акредитивима. <п>Не стављајте необрађене вредности акредитива у догађаје ревизије. Користите ИД-ове акредитива, границе налога добављача, ИД-ове праћења захтева, идентитете актера и разлоге за одлучивање о смерницама. За велики обим саобраћаја током извршавања, можете узорковати детаљну телеметрију за дешифровање, али избор рутирања и атрибуција трошкова треба да остану довољно потпуни за обрачун и одговор на инцидент. <х2>Контролна листа имплементације <ул> <ли>Направите таксономију акредитива и одбијте некласификовани увоз. <ли>Преместите све тајне добављача у наменски шифровани трезор. <ли>Складиштите метаподатке о рутирању одвојено од тајног материјала. <ли>Учините акредитиве за време извршавања, администратора, обрачун, евалуацију и БИОК одвојене класе ауторизације. <ли>Повежите БИОК акредитиве са пореклом налога закупца и добављача. <ли>Захтевајте одобрење механизма за смернице пре него што изаберете било који упстреам акредитив. <ли>Покрените безбедне здравствене провере пре него што испуните услове за производњу. <ли>Користите ротацију са два места са постепеним померањем саобраћаја и опозивом на страни добављача. <ли>Примените ограничења на страни добављача где год су доступна. <ли>Одржавајте евиденције ревизије само за додавање за увоз, употребу, грешке, ротацију и опозив. <ли>Држите администраторске акредитиве иза контрола за разбијање стакла: кратак ТТЛ, именовано одобрење, снажно евидентирање, без употребе током рада. <х2>Закључак који се може спровести <п>Почните тако што ћете инвентарисати све акредитиве добављача који се тренутно користе за мрежни пролаз, скрипте, ЦИ послови, процене и аутоматизација партнера. За сваку од њих доделите класу, власника, границу налога добављача, везивање закупца, дозвољене крајње тачке, дозвољене породице модела, рок ротације и статус онемогућавања у хитним случајевима. Све што не можете да класификујете треба да буде онемогућено или стављено у карантин док не добије јасну сврху. <п>Затим примените једно архитектонско правило: развојни програмери добијају кључеве са опсегом мрежног пролаза; само гатеваи контролише приступ упстреам провајдера. То раздвајање вам омогућава да сачувате најмање привилегија, приписивање станара, тачност обрачуна, усмеравање смерница података и безбедну аутоматизацију чак и када се провајдери, пројекти, радни простори и БИОК корисници множе.<х2>Повезано читање<ул><ли><а хреф="хттпс://модел-гате.цом/ен/блог/ллм-апи-кеи-манагемент-теамс-исолатион-ротатион-спенд-лимитс-леак-респонсе-4/">управљање тимским АПИ кључевима и одговор на цурење<ли><а хреф="хттпс://модел-гате.цом/ен/блог/дата-ретентион-аваре-аи-апи-роутинг-здр-ресиденци-логгинг-16/">смернице усмеравања података-ретентион-аваре<ли><а хреф="хттпс://модел-гате.цом/ен/блог/аи-апи-биллинг-ледгер-куоте-ресерве-сеттле-рецонциле-14/">књига обрачуна и контроле приписивања трошкова