Как да проектираме LLM Service Accounts за производствени натоварвания

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

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

Какво представлява акаунт за LLM услуга?

Факт: Сервизните акаунти са нечовешки самоличности, използвани от приложения и работни натоварвания, а не от отделни потребители. OpenAI API проекти поддържат акаунти за услуги с обхват на проекта и API ключове. Anthropic описва акаунтите за услуги като именувани нечовешки самоличности в рамките на организация. Google Cloud IAM описва акаунтите за услуги като нечовешки потребители за приложения и работни натоварвания.

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

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

• Кое приложение или работен процес притежава тази самоличност?
• В коя среда може да работи?
• Кой екип е отговорен за разходите, достъпа и инцидентите?
• Кои модели, крайни точки, инструменти, правила за данни и региони са разрешени?
• Как идентификационните данни се ротират, отменят или заменят с федерация?

Кога да създадете акаунт за услуга

Създайте акаунт за услуга, когато обаждащият се е работещ софтуер, а не човек. Често срещаните примери включват CI/CD задания, които изпълняват оценки, производствени API услуги, работници за обработка на документи, помощни пилоти за поддръжка на клиенти, опашки с автономни агенти, планирани задания за обогатяване и вътрешни платформи за разработчици, които посредничат за достъп до LLM за много екипи.

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

Едно просто правило за вземане на решения работи добре:

• Ако повикващият може да работи без надзор, използвайте сервизен акаунт.
• Ако повикващият обслужва производствен трафик, използвайте акаунт за услуга за работно натоварване и среда.
• Ако обаждащият се действа от името на клиент или партньор, отделете идентичността на работното натоварване от идентичността на делегирания клиент.
• Ако обаждащият се е човек, използващ конзола или преносим компютър, не крийте това зад акаунт за производствена услуга.

Започнете с опис на самоличността

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

Създайте инвентар с тези категории:

• Човешки доставчик API ключове.
• Акаунти за услуга за работно натоварване.
• CI/CD идентичности.
• Вътрешни ключове, издадени от шлюза.
• Делегирани от партньор или клиент ключове.
• Идентификационни данни за спешно счупване на стъкло.
• Неизвестни ключове, които все още водят до употреба.

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

Използване на един сервизен акаунт за граница на работното натоварване

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

Използвайте отделни акаунти за услуги за:

• Производствени и непроизводствени среди.
• Различни приложения, притежавани от различни екипи.
• Услуги, насочени към клиента, срещу вътрешни работни места.
• Интерактивни пътища на заявки срещу асинхронни пакетни процесори.
• Агентни среди за изпълнение, които могат да извикват инструменти или да изпълняват цикли.
• Партньор API повърхности, които разкриват делегиран достъп.

Практичен модел за именуване е:

llm-sa-{app}-{env}-{team}-{purpose}

Примери:

llm-sa-supportbot-prod-cx-chat
llm-sa-contracts-stg-legal-extract
llm-sa-evals-ci-platform-regression
llm-sa-agentrunner-prod-eng-tools

Не кодирайте тайни, имена на клиенти, лични имена или номера на временни билети в името на акаунта. Вместо това поставете променливи подробности в тагове или метаданни.

Съпоставяне на акаунти на доставчик към модел на самоличност на шлюз

Факт: Възможностите на доставчиците са различни. OpenAI поддържа акаунти за услуги в API проекти, а акаунтите за услуги за проекти са уникални за проекта, където са създадени. Anthropic работните пространства могат да съдържат членове, акаунти за услуги, API ключове и ограничения на ресурсите. Anthropic обединяването на идентичността на работното натоварване позволява на работните натоварвания да използват подписани токени за самоличност вместо статични Anthropic идентификационни данни, с ограничения за приписване и скорост, свързани с работното пространство, когато е конфигурирано.

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

Например:

internal_service_account:
  id: sa_01h_supportbot_prod
  name: llm-sa-supportbot-prod-cx-chat
  owner_team: customer_experience
  environment: production
  app: supportbot
  allowed_models:
    - provider: openai
      model_family: gpt-4.1
    - provider: anthropic
      model_family: claude-sonnet
  data_policy: no_training_required
  monthly_budget_usd: 2500
  provider_bindings:
    openai_project: proj_supportbot_prod
    anthropic_workspace: ws_supportbot_prod

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

Тясно обхват на разрешенията

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

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

Административните API разрешения почти никога не би трябвало да са достъпни за акаунти за услуги по време на изпълнение. Отделете автоматизацията на осигуряване от работните натоварвания за изводи. Бекенд услуга, която изпраща подкани, не би трябвало също така да може да създава нови ключове на доставчик, да променя бюджети или да предоставя достъп до модел.

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

Факт: Anthropic документира обединяването на идентичността на работното натоварване като начин за работните натоварвания да използват подписани токени за самоличност вместо статични Anthropic идентификационни данни. Google Облакът предупреждава, че управляваните от потребители ключове за акаунти за услуги представляват риск за сигурността, ако не се управляват внимателно, и препоръчва по-сигурни алтернативи, когато е възможно. OWASP препоръчва централизирано тайно съхранение, одит на секретни заявки и използване, ротация, отмяна и изтичане, когато е възможно.

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

Потокът на обединяване обикновено изглежда така:

1. Работното натоварване се изпълнява под облак, CI или принципал на доставчик на самоличност.
2. Работното натоварване получава подписан токен за идентичност от този доставчик на идентичност нагоре.
3. Доставчикът на LLM или вътрешният шлюз валидира издателя, аудиторията, темата и твърденията.
4. Шлюзът свързва токена с акаунт за вътрешна услуга.
5. Шлюзът издава краткотрайна сесия или директно оторизира заявката за LLM.

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

Изискване на метаданни за приписване при всяка заявка

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

Изискване на тези полета на шлюза:

• service_account_id
• app
• environment
• owner_team
• deployment_id или версия
• request_purpose, като чат, извличане, класификация, оценка или agent_tool_use
• tenant_id или идентификатор на клиента, когато е приложимо
• workflow_id или идентификатор на работа за асинхронна работа

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

Прикачване на бюджети и сигнали към идентичности на работното натоварване

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

Задайте бюджети на няколко слоя:

• Проект на доставчик или бюджет за работно пространство, където се поддържа.
• Месечен бюджет на ниво портал за акаунт за услуга.
• Откриване на аномалия в кратък прозорец за внезапни пикове.
• Максимални прогнозни разходи за заявка или задание.
• Отделни ограничения за работни натоварвания за производство, етапи, CI и оценка.

Използване на различни действия за различни прагове. При 50 процента уведомете екипа на собственика. При 80 процента изисква потвърждение. При 100 процента блокирайте некритични заявки, понижете до по-евтини одобрени модели или изисквайте изрично отмяна. Правилното поведение зависи от това дали работното натоварване е насочено към клиента, вътрешно, партидно или критично за безопасността.

Проектиране на работния процес на жизнения цикъл

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

Заявка

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

Одобрение

Одобрението трябва да идва от екипа на собственика и платформата или правилата за сигурност. Работните натоварвания с висок бюджет, чувствителни данни, работа с партньори или използване на инструменти трябва да изискват по-строг преглед от нискорисковите задачи за вътрешно обобщаване.

Осигуряване

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

Тайна доставка

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

Преглед

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

Деактивиране и изтриване

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

Регистрирайте събитията, от които се нуждаят одиторите и респондентите

Регистрационните файлове за одит трябва да обхващат дейността както в контролната равнина, така и в равнината на данни. Най-малко лог:

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

Изпратете тези събития към неизменен или устойчив на подправяне поток за проверка. Съхранявайте телеметрията на заявките с висока кардиналност отделно от доказателствата за одит за дълго съхранение, ако това помага да се контролират разходите за съхранение, но запазете ключовете за присъединяване, необходими за разследвания.

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

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

1. Идентифицирайте най-натоварените споделени ключове. Класиране по разходи, трафик, достъп до модела и неизвестна собственост.
2. Групирайте повикващите в граници на работното натоварване. Използвайте регистрационни файлове, хранилища на източници, променливи за внедряване, потребителски агенти и данни за мрежови източници.
3. Създайте акаунти за услуги с обхват. Започнете с производствени работни натоварвания, които имат ясни собственици и високи разходи или висок риск.
4. Маршрут през шлюза. Запазете временно стария ключ на доставчик зад шлюза, ако директната миграция на доставчика ще отнеме повече време.
5. Двойно приписване. Сравнете трафика, разходите, грешките, забавянето и таксуването на доставчика, преди да прекъснете напълно.
6. Редувайте обаждащите се. Актуализирайте тайните за внедряване, CI променливите и конфигурацията на приложението едно натоварване наведнъж.
7. Отмяна на споделения ключ. Първо поставяне под карантина, ако радиусът на взрива е неясен, след това отмяна след прозореца за наблюдение.

Целта не е просто да завъртите ключ. Целта е да се замени двусмисленият достъп с идентичност, политика, бюджет и доказателства, притежавани от работното натоварване.

Компромиси, за да се направи изрично

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

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

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

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

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

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

• Създайте опис на човешки ключове, самоличности за работно натоварване, идентичности на CI, партньорски ключове и идентификационни данни за счупено стъкло.
• Дефинирайте конвенция за именуване с приложение, среда, екип собственик и цел.
• Използвайте един сервизен акаунт за граница на производствено работно натоварване.
• Свържете всяка самоличност с тесни проекти или работни пространства на доставчик.
• Ограничаване на семейства модели, крайни точки, региони, правила за данни и бюджети.
• Предпочитайте федерация или обмен на краткотрайни токени, където се поддържа.
• Съхранявайте статични ключове само при централизирано секретно управление.
• Изискване на метаданни за приписване при всяка заявка.
• Задайте бюджети на акаунти за услуги и сигнали за аномалии.
• Регистриране на идентификационни данни, разрешение, заявка, бюджет и събития за отмяна.
• Деактивирайте неизползваните акаунти, преди да ги изтриете.
• Мигрирайте споделени ключове по натоварване, след което отменете старите идентификационни данни.

Заключение

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

Прогноза: Платформите за LLM ще продължат да се отдалечават от широки статични ключове към модели на акаунт за услуги и идентичност на работното натоварване. Екипите, които установят чиста собственост върху работното натоварване сега, ще имат по-лесен път към обединяване на доставчици, готовност за одит, управление API на партньори и надежден контрол на разходите по-късно.

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

• API ключово управление за екипи