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

Кључеви на нижем току API и акредитиви провајдера на даљем току решавају различите проблеме. Кључ програмера који издаје ваш мрежни пролаз идентификује апликацију, тим, закупца, буџет и контекст смерница. Кључ провајдера узводно омогућава мрежном пролазу да троши новац и приступ моделима на налогу провајдера. Третирање њих као исте врсте тајне је начин на који тимови завршавају са једним неограниченим кључем у дељеном пројекту, администраторским акредитивима у услугама за време извршавања и без поузданог начина да се одговори који закупац је проузроковао наплату на страни провајдера.

Практични образац је трезор акредитива добављача: наменска контролна раван за увоз, класификацију, складиштење, избор, ротирање и ревизију упстреам акредитива. Требало би да се налази иза рутера, књиге обрачуна, механизма политике и тока рада—не унутар кода апликације, конфигурационих датотека модела, записа закупаца или догађаја аналитике.

Проблем читача: упстреам акредитиви постају невидљива инфраструктура

Већина имплементација са више модела почиње са једноставним циљем: усмеравање једног захтева компатибилног са OpenAI до најбољег доступног добављача. Затим се појављује још налога: један пројекат добављача за производњу, други за процену, радни простор Anthropic за пословну јединицу, Google Цлоуд пројекат за Gemini и неколико кључева које достављају клијенти за БИОК уговоре.

Ризик није само тајно цурење. То је губитак контекста ауторизације. Важећи кључ добављача може технички да може да позове крајњу тачку, али мрежни пролаз и даље мора да зна да ли је тај кључ дозвољен за овог закупца, ову породицу модела, ову политику задржавања података, овај буџет, овај регион и ову путању аутоматизације.

Чињеница: платформе добављача откривају различите границе налога и типове акредитива. OpenAI документује пројекте и услужне налоге, а услужни налог API подразумеване кључне дозволе за приступ за читање и писање за API ресурсе пројекта. OpenAI такође излаже кључне објекте Админ API одвојено од уобичајене употребе пројекта/рунтиме API. Anthropic документује радне просторе као организациону границу и наводи да крајње тачке Админ API захтевају кључеве Админ API различите од стандардних кључева API; Anthropic такође напомиње да су кључеви API везани за радни простор у коме су креирани и да се не могу премештати између радних простора. Документација кључа Google Gemini API каже да је сваки кључ Gemini API повезан са Google Цлоуд пројектом и препоручује API ограничења да би се смањила штета ако је кључ компромитован.

Препорука: немојте правити једно генеричко поље „provider_key“ и називати га завршеним. Направите инвентар акредитива који чува границе специфичне за добављача док излаже нормализовани модел смерница мрежном пролазу.

Дефинишите таксономију акредитива пре прихватања кључева

Трезор би требало да одбије двосмислене акредитиве. У време увоза, оператер или ток рада аутоматизације морају да класификују акредитиве. У најмању руку, користите ове категорије:

• Акредитиви за закључивање током извршавања: које мрежни пролаз користи за позивање крајњих тачака закључивања модела као што су ћаскање, одговори, уграђивање, модерирање, транскрипција или генерисање слике, у зависности од подршке добављача.
• Акредитиви за аутоматизацију администратора: који се користе за управљање организацијама на страни добављача, радним просторима, пројектима, корисницима, кључевима или административним ресурсима. Они никада не би требало да буду на путањи захтева за време извршавања.
• Акредитиви за обрачун и извештавање: који се користе за преузимање извештаја о коришћењу, фактурама, трошковима или организацијама где добављачи подржавају те АПИ-је. Држите их одвојено од кључева за закључивање тако да послови извештавања не могу да генеришу коришћење модела.
• Акредитиви само за процену: који се користе за бенцхмарк, КА, миграцију или сценски радни ток. Требало би да имају ниске квоте, јасне ознаке окружења и да не испуњавају услове за резервну производњу.
• Клијентски БИОК акредитиви: кључеви које је доставио корисник везани за одређеног закупца, налог добављача, уговор и политику података. Не би требало да се обједињују у дељено рутирање осим ако се клијент изричито не одлучи за то.

Ова таксономија није само документација. Требало би да покреће контролу приступа, подобност рутирања, упозорење и ротацију. Ако је акредитив увезен без категорије, власника, границе налога добављача и дозвољене употребе, требало би да остане онемогућен.

Чувајте тајне у трезору, а не у евиденцији производа

Трезор би требало да буде једина компонента која може да дешифрује упстреам акредитиве. Други системи могу да чувају референце, хешове, статусна поља и метаподатке смерница, али не и саму вредност акредитива.

Не чувајте тајне узводно на овим местима

• Редови профила закупца.
• Датотеке за конфигурацију рутирања модела.
• Евиденције упита или распони праћења.
• Корисно оптерећење догађаја Аналитике.
• Променљиве ЦИ окренуте програмеру.
• Улазнице за подршку, алатке за ћаскање или снимке екрана.

Корисни дизајн трезора има две равни. Тајни план складишти шифровани материјал акредитива и строго контролише операције дешифровања. Раван метаподатака складишти нетајне атрибуте које користе рутирање и управљање. Рутеру обично треба само ИД акредитива и краткотрајно преузимање тајне у меморији у време слања, а не широк приступ бази података сваком кључу добављача.

Заштитите трезор као инфраструктуру високе вредности: шифровање омотача или управљани КМС, строги идентитети услуга, процедуре разбијања стакла, тестирање резервних копија и враћање, преглед приступа и упозорење о необичном волумену дешифровања. Централни трезор поједностављује управљање, али такође концентрише ризик. То је компромис.

Приложите метаподатке о смерницама уз сваки акредитив

Модел метаподатака треба да буде довољно експлицитан да мрежни пролаз може да одлучи да ли је акредитив подобан пре него што додирне крајњу тачку добављача.

Практична евиденција акредитива укључује:

• credential_id: интерни непроменљиви идентификатор.
• провидер: OpenAI, Anthropic, Gemini, Азуре OpenAI или други адаптер.
• provider_account_boundary: организација, пројекат, радни простор, пројекат у облаку, претплата или еквивалентно.
• credential_class: време извођења, администратор, обрачун, евалуација или БИОК.
• окружење: производња, постављање, развој, евалуација, сандбок.
• tenant_binding: акредитив дељене платформе, појединачни закупац, група закупаца или клијент БИОК закупац.
• allowed_model_families: на пример, генерисање текста, уградња, визија, слика, аудио или профили одређених модела.
• allowed_endpoints: нормализоване могућности мрежног пролаза мапиране на крајње тачке добављача.
• data_policy: дозвољена класа задржавања, класа евидентирања, услов боравка и ограничења функција.
• budget_scope: центар трошкова, купац препродавца, интерно одељење или уговор.
• власник: именовани тим или одговорна особа.
• created_at, expires_at, rotation_due_at, last_used_at.
• health_status: непознато, здраво, деградирано, неовлашћено, quota_exhausted, онемогућено.
• emergency_disable: Блок тренутног рутирања независно од нормалног стања политике.

Држите овај модел неутралним за добављача, али немојте брисати стварност добављача. Кључ везан за радни простор Anthropic и кључ Gemini везан за Google Цлоуд пројекат нису заменљиви само зато што оба могу да генеришу текст. Мрежном пролазу је потребно то порекло за ревизије, повраћај средстава и безбедно пребацивање на грешку.

Одвојени приступ времену извођења, администратору и обрачуну

Најважније правило је једноставно: кључ који се користи за извођење закључка не би требало да управља организацијама добављача, радним просторима, корисницима, пројектима или административним ресурсима.

Саобраћај током рада је великог обима и изложен је највећој оперативној површини. Пролази кроз рутере захтева, логику поновног покушаја, руковаоце стримингом, адаптере модела и токове рада инцидента. Админ акредитиви су ниске фреквенције и велики утицај. Требало би да живе иза одвојеног пута за одобрење са кратким ТТЛ-овима, названим људско одобрење где је то прикладно, снажно евидентирање и без квалификованости за рутирање током извршавања.

Акредитиви за обрачун такође заслужују раздвајање. Посао извештавања који усаглашава фактуре не би требало да буде у стању да генерише довршетке, а кључ за закључивање током извршавања не би требало да буде једини начин за преузимање извештаја о коришћењу. Када провајдер не нуди прецизно раздвајање, компензујте у мрежном пролазу: изолујте акредитиве, ограничите који идентитет интерне услуге може да их преузме и евидентирајте сваку употребу.

Препорука: нека класа акредитива буде чврста граница ауторизације, а не ознака. Диспечер времена извршавања не би требало да буде у могућности да затражи дешифровање за администраторске акредитиве чак и ако грешка у конфигурацији упућује на његов ИД.

Креирајте механизам политике за избор акредитива

Избор акредитива би требало да се деси након што мрежни пролаз аутентификује позиваоца у низу и пре покушаја позивања провајдера. Механизам смерница треба да споји неколико уноса:

• ИД закупца и доњи део кључа API.
• Затражен профил модела или ИД модела специфичног за добављача.
• Могућност крајње тачке: ћаскање, уграђивање, слика, аудио, групни, фајлови, алати или аутоматизација администратора.
• Захтеви за задржавање података и пребивалиште.
• Буџет, резервација кредита и центар трошкова.
• Стање ограничења брзине и притисак квоте.
• Метаподаци акредитива, здравље, животна средина и везивање закупаца.

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

Пример одлуке:

{
  "tenant_id": "tenant_42",
  "requested_profile": "fast-text-prod",
  "endpoint": "chat.completions",
  "data_policy": "no_prompt_logging",
  "credential_requirements": {
    "class": "runtime",
    "environment": "production",
    "tenant_binding": "tenant_42",
    "allowed_model_family": "text",
    "health_status": "healthy"
  },
  "decision": "allow",
  "credential_id": "cred_8f2...",
  "audit_reason": "tenant BYOK credential matches runtime text profile and data policy"
}

Не примењујте резервни кључ као „пробајте следећи кључ“. Повратна политика мора поново да покрене политику. Акредитив дељене платформе може бити важећи за приступ провајдеру, али неважећи за клијента који користи само БИОК. Акредитив у другом пројекту може да има квоту, али може да крши захтеве приписивања трошкова или задржавања.

Рукуј БИОК-ом као приступом у власништву станара, а не резервним капацитетом

БИОК мења модел поверења. Клијент је доставио акредитиве тако да се њихов саобраћај може наплатити, управљати или изоловати у оквиру свог налога провајдера. Тај акредитив треба да буде везан за поријекло налога закупца клијента и провајдера.

Препоручене БИОК контроле:

• Један запис у трезору по клијенту, добављачу, граници налога и окружењу.
• Без рутирања међу закупцима преко БИОК акредитива.
• Нема употребе као дељени резервни капацитет осим ако се клијент изричито не одлучи.
• Кориснички видљиво здравствено стање које не открива необрађени кључ.
• Одвојени ток рада ротације који омогућава клијенту да дода замену пре него што стари кључ буде онемогућен.
• Јасно приписивање у аналитици коришћења и фактурама: закупац мрежног пролаза, граница налога добављача, ИД акредитива, профил модела и ИД тражења.

За агенције, препродавце и аутоматизацију партнера API, БИОК може бити сложенији јер услуга може програмски да обезбеди станаре и акредитиве. Исто правило и даље важи: аутоматизација може да увози и везује акредитиве, али не би требало да замагли власништво станара.

Додајте здравствене провере пре лета без цурења упита

Акредитив може да не успе из више разлога: опозван кључ, погрешан радни простор, недостајући приступ моделу, онемогућени обрачун, исцрпљивање квоте, ограничење крајње тачке, неусклађеност регионалних смерница или прекид у раду добављача. Откривање да тек након што стигне производни захтев ствара бучне инциденте.

Користите провере стања које потврђују способност без слања корисничких упита. Синтетичка провера може позвати минималну крајњу тачку, навести дозвољене моделе тамо где је то прикладно или послати безопасни фиксни упит ако је то једина практична опција. Нека ове чекове буду јефтине, ограничене на стопу и означене као синтетички саобраћај у телеметрији и обрачуну.

Провере здравља би требало да се покрену:

• При увозу акредитива.
• Пре омогућавања акредитива за усмеравање производње.
• Након промена ограничења на страни добављача.
• Током преласка ротације.
• Периодично за акредитиве који испуњавају услове за производњу.

Компром: аутоматске провере рано хватају кључеве са истеклим роком трајања или недовољно опсега, али лоше дизајниране провере могу да доведу до непотребних позива добављача, буке при наплати или лажних аларма током прекида рада добављача. Сачувајте резултат здравља са временском ознаком, класом грешке добављача, тестираном крајњом тачком и тестираном породицом модела. Не чувајте тајне вредности или осетљиве упите.

Ротирајте са два отвора, а не једном ризичном заменом

Ротација акредитива не би требало да буде операција брисања и молитви. Користите модел ротације са два прореза:

1. Увезите замену акредитива као неактивну, са пуним метаподацима и власником.
2. Покрените синтетичке провере здравља за предвиђене крајње тачке, породице модела и границе налога.
3. Омогућите квалификованост у сенци за мали део безбедног синтетичког или нискоризичног саобраћаја где је то потребно.
4. Постепено пребацивање производног саобраћаја са старих акредитива на нове акредитиве.
5. Надгледајте грешке, кашњење, квоту и приписивање трошкова према ИД-у акредитива.
6. Замрзни повратак на стари акредитив када нови акредитив постане стабилан.
7. Опозовите старе акредитиве код провајдера и означите да је запис у трезору опозван.
8. Провери да нема дешифровања или позива добављача преко старог акредитива након опозива.

Рокови ротације треба да буду видљиви у оперативним приказима и упозорењима. Хитној ротацији је потребан краћи пут: онемогућите акредитиве, блокирајте рутирање, омогућите одобрену замену и сачувајте све записе ревизије за преглед инцидента.

Ограничи кључеве добављача тамо где их добављач подржава

Политика мрежног пролаза је неопходна, али ограничења на страни провајдера смањују радијус експлозије ако је кључ компромитован или злоупотребљен. За кључеве Gemini и друге клауд платформе API користите ограничења API/сервице и одговарајућа ограничења апликација где су доступна. За пројекте добављача, радне просторе и услужне налоге, избегавајте широке организационе привилегије када је кључ времена извршавања на нивоу пројекта довољан.

Препорука: одржавајте контролну листу ограничења на страни добављача за сваку класу акредитива. Контролна листа треба да буде део одобрења за увоз и одобрења ротације, а не посебан безбедносни задатак који се може прескочити под притиском.

Замена: ограничења на страни провајдера додају оперативне трошкове. Нове крајње тачке, породице модела, региони или функције аутоматизације могу захтевати промене смерница и ограничења. То је боље него открити након цурења да би један кључ могао да приступи сваком радном оптерећењу у дељеном пројекту.

Чувајте евиденцију ревизије акредитива само за додавање

Ревизијски траг треба да одговори ко је увезао акредитив, шта му је дозвољено да уради, које су га одлуке о рутирању изабрали, када није успео и када је ротиран или опозван.

Евидентирај ове догађаје:

• Акредитиви креирани или увезени.
• Метаподаци су промењени, укључујући дозвољене крајње тачке, везивање закупца или смернице за податке.
• Провера здравља је обављена и резултат је забележен.
• Акредитив изабран смерницама усмеравања за захтев.
• Дешифровање акредитива захтева интерни идентитет услуге.
• Позив добављача није успео због грешке у аутентификацији, ауторизацији, квоти или ограничењу.
• Ротација је започета, саобраћај је промењен, стари акредитив је опозван.
• Омогућено или избрисано онемогућавање у хитним случајевима.
• Приступљено је акредитивима администратора или разбијеног стакла.

Не стављајте необрађене вредности акредитива у догађаје ревизије. Користите ИД-ове акредитива, границе налога добављача, ИД-ове праћења захтева, идентитете актера и разлоге за одлучивање о смерницама. За велики обим саобраћаја током извршавања, можете узорковати детаљну телеметрију дешифровања, али избор рутирања и атрибуција трошкова треба да остану довољно потпуни за обрачун и одговор на инцидент.

Контролна листа за имплементацију

• Креирајте таксономију акредитива и одбијте некласификовани увоз.
• Преместите све тајне добављача у наменски шифровани трезор.
• Чувајте метаподатке о рутирању одвојено од тајног материјала.
• Учините акредитиве за време извршавања, администратора, обрачун, евалуацију и БИОК одвојене класе ауторизације.
• Повежите БИОК акредитиве са пореклом налога закупца и добављача.
• Захтевајте одобрење механизма за смернице пре него што изаберете било који упстреам акредитив.
• Покрените безбедне здравствене провере пре него што испуните услове за производњу.
• Користите ротацију у два слота са постепеним померањем саобраћаја и опозивом на страни добављача.
• Примените ограничења на страни добављача где год су доступна.
• Одржавајте евиденције ревизије само за додавање за увоз, употребу, грешке, ротацију и опозив.
• Држите администраторске акредитиве иза контрола за разбијање стакла: кратак ТТЛ, именовано одобрење, снажно евидентирање, без употребе током рада.

Закључак који се може применити

Почните тако што ћете инвентарисати све акредитиве упстреам добављача који тренутно користе мрежни пролаз, скрипте, ЦИ послови, алати за евалуацију и аутоматизација партнера. За сваку од њих доделите класу, власника, границу налога добављача, везивање закупца, дозвољене крајње тачке, дозвољене породице модела, рок ротације и статус онемогућавања у хитним случајевима. Све што не можете да класификујете треба да буде онемогућено или стављено у карантин док не добије јасну сврху.

Затим примените једно архитектонско правило: програмери на нижем току добијају кључеве са опсегом мрежног пролаза; само гатеваи контролише приступ упстреам провајдера. То раздвајање вам омогућава да сачувате најмање привилегије, приписивање станара, тачност обрачуна, усмеравање смерница података и безбедну аутоматизацију чак и када се добављачи, пројекти, радни простори и БИОК клијенти множе.

Повезано читање

• API управљање кључевима одговор
• смернице рутирања свесне на задржавање података
• контроле књиге обрачуна и приписивања трошкова