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

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

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

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

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

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

Факт: платформите на доставчици разкриват различни граници на акаунти и типове идентификационни данни. OpenAI документира проекти и акаунти за услуги, както и разрешенията за ключ на API на акаунта за услуги по подразбиране за достъп за четене и запис за ресурсите на API на проекта. OpenAI също така излага ключови обекти на Admin API отделно от обикновеното използване на API за проекти/изпълнение. Anthropic документира работните пространства като организационна граница и заявява, че крайните точки на API на администратора изискват ключове на API на администратор, различни от стандартните ключове на API; Anthropic също така отбелязва, че API ключовете са свързани с работното пространство, където са създадени, и не могат да се преместват между работните пространства. Документацията на Google за Gemini API ключа казва, че всеки Gemini API ключ е свързан с проект на Google Cloud и препоръчва 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.
• здравен_статус: неизвестен, здрав, влошен, неоторизиран, квота_изчерпана, деактивиран.
• emergency_disable: незабавно блокиране на маршрутизирането независимо от нормалното състояние на правилата.

Запазете този модел неутрален към доставчика, но не изтривайте реалностите на доставчика. Ключът, свързан с работното пространство на Anthropic, и ключът Gemini, свързан с проект на Google Cloud, не са взаимозаменяеми само защото и двата могат да генерират текст. Шлюзът се нуждае от този произход за одити, връщане на плащания и безопасен отказ.

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

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

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

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

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

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

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

• Идентификатор на наемател и обхват на ключ на API надолу по веригата.
• Заявен профил на модел или специфичен за доставчика идентификатор на модел.
• Възможност за крайна точка: чат, вграждания, изображения, аудио, партида, файлове, инструменти или автоматизация на администратора.
• Изисквания за запазване на данни и пребиваване.
• Бюджет, кредитна резервация и разходен център.
• Състояние на ограничение на скоростта и квотен натиск.
• Метаданни за идентификационни данни, здраве, среда и обвързване на клиента.

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

Примерно решение:

<пре><код>{ "tenant_id": "tenant_42", "requested_profile": "fast-text-prod", "крайна точка": "chat.completions", "data_policy": "no_prompt_logging", "credential_requirements": { "клас": "време на изпълнение", "среда": "производство", "tenant_binding": "tenant_42", "allowed_model_family": "текст", "health_status": "здрав" }, "решение": "позволява", "credential_id": "cred_8f2...", "audit_reason": "идентификационните данни на клиента BYOK съответстват на текстовия профил по време на изпълнение и правилата за данни" }

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Изпълнимо заключение

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

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

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

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