Хранилища за идентификационни данни на доставчика за многомоделни AI шлюзове: отделно време за изпълнение, администратор, таксуване и BYOK достъп

Downstream API и идентификационните данни на доставчика нагоре решават различни проблеми. Ключ на програмист, издаден от вашия шлюз, идентифицира приложението, екипа, клиента, бюджета и контекста на правилата. Ключ на доставчик нагоре позволява на шлюза да харчи пари и да има достъп до модели в акаунт на доставчик. Третирането им като един и същ вид тайна е начинът, по който екипите се оказват с един неограничен ключ в споделен проект, администраторски идентификационни данни в услугите по време на изпълнение и липса на надежден начин да се отговори кой клиент е причинил кое таксуване от страна на доставчика.

Практическият модел е хранилище за идентификационни данни на доставчик: специална контролна равнина за импортиране, класифициране, съхраняване, избор, ротация и одит на идентификационни данни нагоре. Той трябва да стои зад рутера, книгата за фактуриране, механизма за правила и работния процес - не в кода на приложението, конфигурационните файлове на модела, записите на наемателите или събитията за анализ.

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

Повечето внедрявания с няколко модела започват с проста цел: насочете една OpenAI-съвместима заявка към най-добрия наличен доставчик. След това се появяват още акаунти: един проект на доставчик за производство, друг за оценка, Anthropic работно пространство за бизнес единица, Google Облачен проект за Gemini и няколко предоставени от клиента ключа за BYOK договори.

Рискът не е просто тайно изтичане. Това е загуба на контекст на оторизация. Валиден ключ на доставчик може технически да може да извика крайна точка, но шлюзът все още трябва да знае дали този ключ е разрешен за този клиент, това семейство модели, тази политика за запазване на данни, този бюджет, този регион и този път на автоматизация.

Факт: платформите на доставчици разкриват различни граници на акаунти и типове идентификационни данни. OpenAI документи за проекти и акаунти за услуги и разрешения за ключове за акаунт API за услуги по подразбиране за достъп за четене и запис за API ресурсите на проекта. OpenAI също излага ключовите обекти на Admin API отделно от обикновеното използване на проект/време на изпълнение API. Anthropic документира работните пространства като организационна граница и посочва, че крайните точки на Admin API изискват ключове Admin API, различни от стандартните ключове API; Anthropic също отбелязва, че API ключовете са свързани с работното пространство, където са създадени, и не могат да се преместват между работните пространства. Google's Gemini API key documentation казва, че всеки Gemini API ключ е свързан с Google облачен проект и препоръчва API ограничения за намаляване на щетите, ако даден ключ е компрометиран.

Препоръка: не създавайте едно общо поле „provider_key“ и го наричайте готово. Създайте списък с идентификационни данни, който запазва специфичните за доставчика граници, като същевременно излага нормализиран модел на политика към шлюза.

Дефинирайте таксономия на идентификационните данни, преди да приемете ключове

Трезорът трябва да отхвърля двусмислени идентификационни данни. По време на импортиране работният процес на оператора или автоматизацията трябва да класифицира идентификационните данни. Използвайте поне тези категории:

• Идентификационни данни за извод по време на изпълнение: използвани от шлюза за извикване на крайни точки за извод на модела, като чат, отговори, вграждания, модериране, транскрипция или генериране на изображения, в зависимост от поддръжката на доставчика.
• Идентификационни данни за автоматизация на администратора: използвани за управление на организации, работни пространства, проекти, потребители, ключове или административни ресурси от страната на доставчика. Те никога не трябва да са на пътя на заявката за изпълнение.
• Идентификационни данни за фактуриране и отчитане: използвани за извличане на отчети за използване, фактури, разходи или организация, където доставчиците поддържат тези API. Дръжте ги отделно от ключовете за изводи, така че заданията за отчитане да не могат да генерират използване на модела.
• Идентификационни данни само за оценка: използвани от бенчмарк, QA, миграция или етапни работни потоци. Те трябва да имат ниски квоти, ясни етикети за околната среда и да не отговарят на изискванията за резервно производство.
• Клиентски BYOK идентификационни данни: предоставени от клиента ключове, обвързани с конкретен клиент, акаунт на доставчик, договор и политика за данни. Те не трябва да се обединяват в споделено маршрутизиране, освен ако клиентът изрично не е избрал.

Тази таксономия не е просто документация. Той трябва да управлява контрола на достъпа, допустимостта на маршрутизирането, предупрежденията и работните процеси за ротация. Ако идентификационни данни се импортират без категория, собственик, граница на акаунта на доставчик и разрешена употреба, те трябва да останат деактивирани.

Съхранявайте тайни в трезор, а не в продуктови записи

Сейфът трябва да е единственият компонент, който може да дешифрира идентификационни данни нагоре. Други системи могат да съхраняват препратки, хешове, полета за състояние и метаданни за правилата, но не и самата стойност на идентификационните данни.

Не съхранявайте тайни нагоре по веригата на тези места

• Редове на профила на наемател.
• Конфигурационни файлове за маршрутизиране на модели.
• Регистрации на подкани или участъци от проследяване.
• Полезни натоварвания за събития на Анализ.
• Променливи на CI, насочени към програмиста.
• Билети за поддръжка, инструменти за чат или екранни снимки.

Използваем дизайн на трезор има две равнини. Тайният самолет съхранява криптирани идентификационни данни и строго контролира операциите за дешифриране. равнината на метаданни съхранява несекретни атрибути, използвани от маршрутизирането и управлението. Рутерът обикновено се нуждае само от идентификационен номер и краткотрайно извличане на тайна в паметта по време на изпращане, а не широк достъп до база данни до всеки ключ на доставчика.

Защитете трезора като инфраструктура с висока стойност: криптиране на плик или управляван KMS, стриктни идентичности на услугата, процедури за счупване на стъкло, тестване за архивиране и възстановяване, преглед на достъпа и известяване при необичаен дешифриран обем. Централният трезор опростява управлението, но също така концентрира риска. Това е компромисът.

Прикачване на метаданни за правилата към всяко удостоверение

Моделът на метаданните трябва да е достатъчно ясен, за да може шлюзът да реши дали идентификационните данни отговарят на условията, преди да докоснат крайна точка на доставчик.

Практическият идентификационен запис включва:

• credential_id: вътрешен неизменен идентификатор.
• доставчик: OpenAI, Anthropic, Gemini, Azure OpenAI или друг адаптер.
• provider_account_boundary: организация, проект, работно пространство, облачен проект, абонамент или еквивалент.
• credential_class: време на изпълнение, администриране, таксуване, оценка или BYOK.
• среда: производство, постановка, разработка, оценка, пясъчник.
• tenant_binding: идентификационни данни за споделена платформа, един клиент, група клиенти или клиент BYOK клиент.
• 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 облачен проект, не са взаимозаменяеми само защото и двата могат да генерират текст. Шлюзът се нуждае от този произход за одити, връщане на плащания и безопасно преминаване при срив.

Отделен достъп по време на изпълнение, администратор и таксуване

Най-важното правило е просто: ключ, използван за извод по време на изпълнение, не трябва да управлява организации на доставчици, работни пространства, потребители, проекти или административни ресурси.

Трафикът по време на изпълнение е голям обем и е изложен на най-голямата работна повърхност. Той преминава през маршрутизатори на заявки, логика за повторен опит, манипулатори на поточно предаване, адаптери на модели и работни потоци на инциденти. Идентификационните данни на администратора са с ниска честота и голямо въздействие. Те трябва да живеят зад отделен път за одобрение с кратки TTL, наречено одобрение от човек, където е подходящо, силно регистриране и без допустимост за маршрутизиране по време на изпълнение.

Идентификационните данни за фактуриране също заслужават отделяне. Задание за отчитане, което съгласува фактури, не трябва да може да генерира завършвания и ключът за извод по време на изпълнение не трябва да е единственият начин за извличане на отчети за употреба. Когато доставчикът не предлага фино разделяне, компенсирайте в шлюза: изолирайте идентификационните данни, ограничете коя идентичност на вътрешната услуга може да ги извлече и регистрирайте всяко използване.

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

Създаване на машина за правила за избор на идентификационни данни

Изборът на идентификационни данни трябва да се извърши, след като шлюзът удостовери повикващия надолу по веригата и преди да бъде извършен опит за повикване на доставчик. Машината за правила трябва да обединява няколко входа:

• Идентификатор на наемател и обхват на ключ 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"
}

Не прилагайте резервен вариант като „опитайте следващия ключ“. Политиката за резервен вариант трябва да се изпълнява отново. Идентификационни данни за споделена платформа може да са валидни за достъп на доставчик, но невалидни за клиент само с BYOK. Идентификационни данни в друг проект може да имат квота, но може да нарушават изискванията за приписване на разходите или задържане.

Управлявайте BYOK като достъп, собственост на наемател, а не свободен капацитет

BYOK променя модела на доверие. Клиентът е предоставил идентификационните данни, така че трафикът му да може да бъде таксуван, управляван или изолиран в акаунта на доставчика му. Тези идентификационни данни трябва да бъдат обвързани с произхода на акаунта на клиентски наемател и доставчик.

Препоръчани BYOK контроли:

• Един запис в трезора за клиент, доставчик, граница на акаунта и среда.
• Без маршрутизиране между клиенти чрез идентификационни данни BYOK.
• Не се използва като споделен резервен капацитет, освен ако клиентът изрично не го избере.
• Видимо от клиента здравословно състояние, което не разкрива необработения ключ.
• Отделен работен процес за ротация, който позволява на клиента да добави замяна, преди старият ключ да бъде деактивиран.
• Ясно приписване в анализа на използването и фактурите: наемател на шлюза, граница на акаунта на доставчика, идентификационен номер на идентификационни данни, профил на модела и идентификационен номер за проследяване на заявка.

За автоматизация на агенции, дистрибутори и партньор API BYOK може да бъде по-сложен, тъй като дадена услуга може да предоставя наематели и идентификационни данни програмно. Все още се прилага същото правило: автоматизацията може да импортира и обвързва идентификационни данни, но не трябва да замъглява собствеността на клиента.

Добавяне на проверки на състоянието преди полет без изтичане на подкани

Идентификационните данни могат да бъдат неуспешни по много причини: отменен ключ, грешно работно пространство, липсващ достъп до модела, деактивирано таксуване, изчерпване на квотата, ограничение на крайна точка, несъответствие на регионална политика или прекъсване на доставчика. Откриването, че само след като пристигне заявка за производство, създава шумни инциденти.

Използвайте проверки на състоянието, които потвърждават възможностите, без да изпращате подкани на клиента. Синтетичната проверка може да извика минимална крайна точка, да изброи разрешените модели, където е подходящо, или да изпрати безвредна фиксирана подкана, ако това е единствената практична опция. Поддържайте тези проверки евтини, ограничени по тарифи и означени като синтетичен трафик в телеметрията и таксуването.

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

• При импортиране на идентификационни данни.
• Преди да активирате идентификационни данни за производствено маршрутизиране.
• След промени в ограниченията от страна на доставчика.
• По време на прекъсване на въртенето.
• Периодично за идентификационни данни с допустимост за производство.

Компромис: автоматизираните проверки хващат ключове с изтекъл срок или недостатъчен обхват рано, но лошо проектираните проверки могат да създадат ненужни обаждания на доставчик, шум при таксуване или фалшиви аларми по време на прекъсвания на доставчика. Съхранявайте резултата за здравето с клеймо за време, клас на грешка на доставчика, тествана крайна точка и тествано семейство модели. Не съхранявайте тайни стойности или чувствителни подкани.

Завъртете с два слота, а не с една рискована замяна

Ротацията на идентификационните данни не трябва да бъде операция за изтриване и молба. Използвайте модел на ротация с два слота:

1. Импортиране на заместващи идентификационни данни като неактивни, с пълни метаданни и собственик.
2. Изпълнете синтетични проверки на състоянието за предвидените крайни точки, семейства модели и граница на акаунта.
3. Активирайте допустимостта за скрит достъп за малка част от безопасен синтетичен или нискорисков трафик, където е подходящо.
4. Преместете производствения трафик постепенно от стари идентификационни данни към нови идентификационни данни.
5. Наблюдение на грешки, забавяне, квота и приписване на разходите по ID на идентификационни данни.
6. Замразете резервното връщане към старите идентификационни данни, след като новите идентификационни данни са стабилни.
7. Отменете старите идентификационни данни на доставчика и маркирайте записа в трезора като отменен.
8. Уверете се, че няма декриптиране или обаждания на доставчик през старите идентификационни данни след отмяната.

Крайните срокове за ротация трябва да са видими в изгледите на операциите и предупрежденията. Аварийната ротация се нуждае от по-кратък път: деактивиране на идентификационни данни, блокиране на маршрутизиране, активиране на одобрена замяна и запазване на всички одитни записи за преглед на инциденти.

Ограничете ключовете на доставчика там, където доставчикът го поддържа

Политиката за шлюз е необходима, но ограниченията от страна на доставчика намаляват радиуса на взрив, ако ключ е компрометиран или злоупотребен. За Gemini и други ключове на облачна платформа API използвайте API/услугни ограничения и подходящи ограничения за приложения, където има такива. За проекти на доставчици, работни пространства и акаунти за услуги избягвайте широки организационни привилегии, когато е достатъчен ключ за изпълнение с обхват на проекта.

Препоръка: поддържайте контролен списък с ограничения от страна на доставчика за всеки клас идентификационни данни. Контролният списък трябва да бъде част от одобрението за импортиране и ротация, а не отделна задача за сигурност, която може да бъде пропусната под напрежение.

Компромис: ограниченията от страна на доставчика добавят оперативни разходи. Нови крайни точки, семейства модели, региони или функции за автоматизация може да изискват промени в правилата и ограниченията. Това е за предпочитане пред откриването след изтичане на информация, че един ключ може да има достъп до всяко работно натоварване в споделен проект.

Съхранявайте дневник за проверка на идентификационни данни само за добавяне

Една одитна пътека трябва да отговори кой е импортирал идентификационни данни, какво му е било разрешено да прави, кои решения за маршрутизиране са го избрали, кога е бил неуспешен и кога е бил ротиран или отменен.

Регистрирайте тези събития:

• Идентификационни данни са създадени или импортирани.
• Променени метаданни, включително разрешени крайни точки, обвързване на клиента или правила за данни.
• Изпълнена проверка на състоянието и записан резултат.
• Идентификационни данни, избрани от правилата за маршрутизиране за заявка.
• Декриптиране на идентификационни данни, поискано от самоличност на вътрешна услуга.
• Неуспешно обаждане на доставчик поради грешка при удостоверяване, оторизация, квота или ограничение.
• Ротацията е започната, трафикът е изместен, старите идентификационни данни са отменени.
• Аварийното изключване е активирано или изчистено.
• Достъп до идентификационните данни на администратор или счупено стъкло.

Не поставяйте необработени стойности на идентификационни данни в събития за проверка. Използвайте идентификатори на идентификационни данни, граници на акаунта на доставчика, идентификатори за проследяване на заявки, самоличности на актьори и причини за вземане на решение по правилата. За голям обем трафик по време на изпълнение можете да извадите подробна декриптирана телеметрия, но изборът на маршрут и приписването на разходите трябва да останат достатъчно пълни за фактуриране и реакция при инцидент.

Контролен списък за внедряване

• Създайте таксономия на идентификационните данни и отхвърлете некласифицирани импортирания.
• Преместете всички тайни на доставчика в специално шифровано хранилище.
• Съхранявайте метаданните за маршрутизиране отделно от секретния материал.
• Направете идентификационни данни за време на изпълнение, администриране, таксуване, оценка и BYOK отделни класове за оторизация.
• Свържете идентификационните данни на BYOK с произхода на акаунта на клиента и доставчика.
• Изискване на одобрение от машина за правила, преди да изберете идентификационни данни нагоре по веригата.
• Изпълнете бързи и безопасни проверки на здравето преди допустимостта на производството.
• Използване на ротация с два слота с постепенно изместване на трафика и отмяна от страна на доставчика.
• Прилагайте ограничения от страна на доставчика, където има такива.
• Поддържане на одитни регистрационни файлове само за добавяне за импортиране, използване, грешки, ротация и отмяна.
• Съхранявайте администраторските идентификационни данни зад контроли със счупено стъкло: кратък TTL, наименувано одобрение, силно регистриране, без използване на време за изпълнение.

Приложимо заключение

Започнете, като инвентаризирате всички идентификационни данни на доставчик нагоре по веригата, използвани в момента от шлюза, скриптове, CI задачи, системи за оценка и автоматизация на партньори. За всеки от тях задайте клас, собственик, граница на акаунта на доставчика, обвързване на клиента, разрешени крайни точки, разрешени семейства модели, краен срок за ротация и състояние на спешно деактивиране. Всичко, което не можете да класифицирате, трябва да бъде деактивирано или поставено под карантина, докато има ясна цел.

След това наложете едно архитектурно правило: разработчиците надолу по веригата получават ключове с обхват на шлюза; само шлюзът контролира достъпа на доставчика нагоре по веригата. Това разделяне ви позволява да запазите най-малките привилегии, приписването на наемателите, точността на таксуването, маршрутизирането на политиката за данни и безопасната автоматизация, дори когато доставчиците, проектите, работните пространства и клиентите на BYOK се умножават.

Свързано четене

• екипно API управление на ключове и изтичане отговор
• правила за маршрутизиране, съобразени със запазване на данни
• контроли за фактуриране и приписване на разходите