<п>Управљање кључевима АПИ-ја више није мали задатак на контролној табли. За тимове који користе АИ АПИ-је, то је део модела безбедности, трошкова и операција за сваку апликацију која шаље упите, прима излаз модела, позива алате или троши новац на мерено закључивање.<п>Многи тимови почињу са једним кључем добављача у датотеци локалног окружења. То функционише све док се исти кључ не појави у ЦИ варијаблама, бележницама, ИДЕ екстензијама, агентима, батцх пословима, интеграцијама клијената и скриптама за подршку. У том тренутку, кључ који је процурио није само проблем аутентификације. Може да изложи упите и одговоре, да покрене неочекиване наплате, позове премијум моделе, покрене алате са овлашћењем за апликације или учини да одговор на инцидент зависи од нагађања.<п>Овај водич третира управљање АПИ кључевима као животни циклус: како су кључеви дизајнирани, издати, ускладиштени, обухваћени, надгледани, ротирани и опозвани. Фокусира се на приступ АИ АПИ-ју, где се уобичајеним проблемима безбедности АПИ-ја придружују приступ моделу, потрошња заснована на токенима, акредитиви више добављача, атрибуција корисника и клијенти компатибилни са ОпенАИ-ом.<х2>Где се АПИ кључеви уклапају у безбедност АПИ-ја<п>АПИ кључ обично доказује поседовање акредитива. Одговара на питање „да ли овај позивалац има ваљану тајну?“ Он сам по себи не одговара на свако питање о ауторизацији које је важно.<п>Позадина још увек мора да одлучи да ли позивалац може да приступи одређеном закупцу, објекту, моделу, крајњој тачки, алату, радном простору, извештају или административној функцији. ОВАСП АПИ Сецурити Топ 10 ризика као што су оштећена ауторизација на нивоу објекта, покварена аутентификација, неограничена потрошња ресурса и неисправна ауторизација на нивоу функције су подсетници да је важећи акредитив само један слој система.<п>За АИ АПИ-је та разлика је важна јер исти кључ може да обавља радње са веома различитим профилима ризика. Кључ који може да позове јефтин текстуални модел за један интерни ток посла не би требало да аутоматски може да позива премијум моделе, креира групне послове, приступ подацима другог закупца, позива алатке које шаљу е-пошту или управља подешавањима обрачуна.<п>Издржљив АПИ безбедносни модел раздваја три питања:<ул><ли><стронг>Потврда идентитета: валидност захтева за потврду идентитета или потврду идентитета. сесија.<ли><стронг>Овлашћење: одлучивање о томе шта тај аутентификовани позивалац може да уради у тренутном закупцу, окружењу и пословном контексту.<ли><стронг>Управљање: ограничавање потрошње, стопа, приступ моделу, изложеност подацима и административна контрола тако да једна грешка има ограничен радијус експлозије.<п>Корисни су само они кључеви контроле, али су само кључна контрола, АПИ. ресурси високе вредности. Користите их уз ХТТПС, провере ауторизације на страни сервера, евиденцију ревизије, најмање привилегије, ограничења стопе, ограничења потрошње и безбедно руковање тајном.<х2>Почните са активним инвентаром АПИ кључева<п>Не можете да управљате кључевима којима не можете да именујете. Први практични корак је активна инвентаризација сваког АПИ кључа и објекта сличног акредитива које користе ваши системи вештачке интелигенције.<п>У најмању руку, сваки запис кључа треба да садржи ИД кључа, неповратни хеш или отисак прста, власника, креатора, тим или закупца, окружење, радно оптерећење, опсеге, дозвољене моделе, дозвољене крајње тачке, политику потрошње, смернице за временско ограничење, временско ограничење ИП-а, ограничење трајања ИП-а. временска ознака, група ротације и метаподаци ревизије.<п>Инвентар треба да покрије више од кључева за време извођења производње. Укључите личне кључеве програмера, кључеве налога за услугу, кључеве ЦИ/ЦД, кључеве радног простора, кључеве клијената или закупаца, кључеве којима управља препродавац, кључеве за обрачун/извештавање, административне АПИ акредитиве и акредитиве добављача.<п>Најважнија поља су власништво, сврха, обим, последња употреба и политика ограничења. Без њих, сваки будући безбедносни задатак постаје спорији: искључење, ротација, одговор на цурење, испитивање трошкова и корисничка подршка.<х2>Намерно дизајнирајте границе кључа<п>Највећа грешка у управљању АПИ кључевима је коришћење једног кључа преко превише граница. Заједнички производни кључ је у почетку згодан, али уништава приписивање и чини опозив ометајућим. Ако процури, можда ћете морати да зауставите саобраћај за сваку услугу, а да и даље не можете да идентификујете које је оптерећење изазвало проблем.<п>Добре кључне границе прате облик пословања и софтвера. Одвојите производњу од развоја, људе од услуга, клијенте из интерних тимова, закупце једни од других, акредитиве за време извршавања од административних акредитива и кључеве клијената издате од мрежног пролаза од кључева претходног добављача.<х3>Границе окружења<п>Развој, постављање и производња треба да користе засебне кључеве. Развојни кључ не би требало да достигне производне податке или производне буџете.A staging key should not have access to live customer workloads unless there is a tightly controlled reason.

Workload boundaries

Each service, batch job, agent fleet, integration, or scheduled task should have its own key or service account. That lets you answer basic questions: which workload spent the money, which service started failing authentication, which integration used a deprecated model, and which key should be frozen during an incident.

Tenant and customer boundaries

Multi-tenant systems need attribution and isolation. If a customer-facing API key is used to submit prompts, the request should be tied to the customer, tenant, application, and ideally a pseudonymous end-user or actor. A compromised key for one tenant should not allow access to another tenant’s data, model profile, budget, or logs.

Provider credential boundaries

Upstream provider keys are different from keys you issue to customers or internal applications. Provider credentials should stay server-side, stored in a vault or secret manager, and never be sent to browsers, mobile apps, desktop clients, public notebooks, or customer-controlled environments.

A gateway can help here by exposing one customer-facing key surface while keeping upstream provider credentials behind the gateway. То омогућава да се централизује аналитика коришћења, опозив, контрола тима и спровођење политике међу провајдерима. If you are standardizing clients around an OpenAI-compatible API, the gateway boundary becomes especially important because many tools expect a single base URL and bearer token.

Apply least privilege to models, endpoints, tools, and spend

Least privilege means a key should have only the access required for its workload. За АИ системе, опсег није само листа крајњих тачака АПИ-ја. It also includes models, tools, token budgets, rate limits, tenants, data classes, and administrative functions.

A practical AI API key policy can include:

  • Allowed model families or specific model IDs.
  • Allowed endpoints, such as chat completions, embeddings, batch jobs, or image generation.
  • Disallowed administrative APIs, key-management APIs, billing APIs, and workspace-management APIs for runtime keys.
  • Per-key rate limits for requests per minute and tokens per minute.
  • Per-tenant, per-team, or per-customer spend limits.
  • Premium model controls so a low-risk workflow cannot suddenly use the most expensive model.
  • Tool permissions, such as whether a key may call external connectors, code execution, retrieval systems, or business actions.
  • IP allowlists for stable server-side workloads, where the network path is predictable.

Spend control is part of API security for metered AI APIs. Кључ који је процурио може да створи директну финансијску штету чак и ако никада не приступи осетљивим подацима. Rate limits help, but they are not enough. Обим токена, поновни покушаји, групни послови, позиви алата и избор модела утичу на цену. A secure implementation should combine rate controls with spend ceilings, model allowlists, anomaly detection, and emergency freeze controls.

Teams comparing model cost and access policies should keep security and finance aligned. Модел цена није само питање набавке; одређује колико компромитовани или погрешно конфигурисани кључ може да потроши. Keep approved model profiles tied to budgets and review them when your model mix changes, especially when using AI model pricing to route workloads by cost and capability.

Store secrets where they belong

API keys belong in secret managers, server-side configuration, controlled CI/CD variables, or a vault-backed gateway. They do not belong in source code, browser JavaScript, mobile bundles, desktop app packages, public notebooks, screenshots, chat messages, analytics payloads, support tickets, or logs.

Client-side exposure is a common failure mode. If a provider key is embedded in a browser or mobile app, anyone who can inspect the app can extract it and make requests on the account holder’s behalf. For browsers, mobile apps, IDE fleets, and agents running in uncontrolled environments, use server-side proxying or short-lived delegated credentials with narrow scope. Немојте дистрибуирати дуговечне акредитиве добављача клијентима које не можете да контролишете.<п>ЦИ/ЦД захтева исту дисциплину. Store keys as protected variables. Restrict who can read or change them. Избегавајте штампање променљивих окружења у евиденцијама изградње. Редигујте заглавља овлашћења у неуспелим депонијама захтева. Treat preview deployments and forked pull requests as different trust zones from protected production pipelines.

Logs and observability systems deserve special attention.Чувајте отиске кључа, ИД-ове захтева, ИД-ове станара, ИД-ове модела, статус одговора, бројаче токена, бројаче трошкова, ИП или метаподатке о клијентима где је то прикладно, и одлуке о политици. Не чувајте пуне АПИ кључеве. Редигујте тајне у траговима, обрнутим евиденцијама проксија, извештајима о изузетцима, корисним учитавањима веб-хука, алатима за подршку, аналитичким догађајима и редовима за мртве поруке.<х2>Израда ротације пре хитног случаја<п>Ротација није једноставно брисање једног кључа и креирање другог. Ако примењене услуге и даље зависе од старог кључа, брисање изазива прекид рада. Поуздан процес ротације користи преклапање, посматрање и јасну тачку повлачења.<п>Уобичајени образац је група ротације са два активна слота. Креирајте заменски кључ, примените га на сваки зависни систем, посматрајте последњу употребу старог кључа, замрзните стари кључ када се саобраћај помери и избришите га након прозора поверења. Нека правила враћања буду експлицитна: када стари кључ може поново да се омогући, ко то може да одобри и колико дуго може да остане доступан?<п>Кратки животни век кључа смањује ризик од застарелих акредитива, али повећава оперативно оптерећење. Дуготрајни кључеви смањују одлив при примени, али стварају већи прозор за заборављене акредитиве и празнине у вези са одласком запослених. Права политика зависи од обима посла. Налог за производну услугу високе вредности може да се ротира по фиксном распореду уз аутоматизацију. Привремени кључ програмера би требало брзо да истекне. Интеграцији којом управљају клијенти ће можда бити потребан дужи период миграције и јасне поруке о застаревању.<п>Не ротирајте сваки кључ на исти начин. Административни акредитиви који могу да наведу, креирају, бришу или модификују кључеве су ризичнији од кључева за закључивање током извршавања и требало би да имају јаче контроле, ужи приступ и агресивније надгледање. Кључеви за време извршавања не би требало да имају административна овлашћења осим ако не постоји конкретан, прегледан разлог.<х2>Откривање цурења и ненормално коришћење<п>Откривање цурења најбоље функционише када се неколико система међусобно појачавају. Тајно скенирање за контролу извора може ухватити кључеве предате спремиштима. ЦИ провере могу блокирати очигледна цурења пре спајања. Прилагођени обрасци могу открити интерне формате кључева. Контролне табле добављача могу открити неуобичајене активности. Телеметрија мрежног пролаза може да прикаже нове ИП адресе, нове географске локације, неуспешне рафале аутентификације, изненадну брзину потрошње или позиве неочекиваним моделима.<п>Корисне безбедносне контролне табле обухватају неактивне кључеве, кључеве без власника, кључеве без ограничења, кључеве који се ближи истеку, кључеве који се користе са нових мрежа за брзи раст, кључеве који се још увек не развијају, кључеве који се још увек не развијају, кључеве који се још увек не развијају, кључеве без власника, кључеве без ограничења. рафали за аутентификацију и кључеви клијената који се приближавају границама потрошње.<п>Откривање такође треба да обухвати евиденције и асинхроне системе. Веб-хукови, послови у позадини, редови и одложени довршеци захтевају ИД-ове захтева и приписивање оригиналног кључа. У супротном, сумњиви повратни позив или резултат групе можда неће бити могуће повезати са кључем и закупцем који су га креирали.<п>Када се тајна појави у Гит историји, њено уклањање из спремишта није довољно. Свако ко је приступио спремишту, евиденцијама изградње, огледалима, виљушкама, артефактима пакета или кешираним страницама можда је већ копирао кључ. Акредитив мора бити поништен или замрзнут, а затим замењен.<х2>Одговарање на компромитовани АПИ кључ<п>Добар план реаговања на инцидент је кратак, увежбан и специфичан. Прва одлука је обично да ли да се замрзне или опозове. Замрзавање брзо зауставља саобраћај уз чување записа за истрагу. Опозив трајно онемогућава кључ. Неки тимови прво користе замрзавање када им је потребан континуитет ревизије и опције тренутног враћања; други се аутоматски опозивају због потврђених јавних цурења. За оба приступа потребна је аутоматизација и јасна овлашћења.<п>Практичан ток одговора изгледа овако:<ол><ли>Замрзните или опозовите сумњиви кључ на основу озбиљности и поверења.<ли>Идентификујте власника, закупца, радно оптерећење, опсеге, приступ моделу, политику потрошње и последње коришћене временске линије.<ли>Необичне алатке за крајњу тачку прегледа.<ли> ИП адресе, обим токена и цена.<ли>Процените погођене податке, закупце, низводне радње и утицај на обрачун.<ли>Издајте заменски кључ са исправљеним обимом и ограничењима.<ли>Уклоните основни узрок, као што је предата тајна, откривена евиденција, преширока ЦИ променљива, или контролна евиденција на страни клијента, као што је контролна група евиденције на страни клијента>Ад. редакција, ужи опсег, краћи рок трајања или упозорења о потрошњи.<ли>Документујте инцидент и ажурирајте рунбоокс.<п>Корак замене не би требало да поново креира исти ризик. Ако је кључ процурио зато што је дељен у десет услуга, замените га посебним кључевима налога услуге. Ако је процурио кроз евиденције, поправите евиденцију пре издавања новог кључа. Ако је превише потрошио јер би могао да позове сваки модел, додајте листе дозвољених модела и ограничења потрошње.<х2>Кључеви којима управља мрежни пролаз и приступ вештачкој интелигенцији са више провајдера<п>АИ тимови често користе неколико добављача модела.Сваки провајдер има свој модел кључа, структуру радног простора, ограничења стопе, називе модела, цене и административне АПИ-је. Управљање сваким кључем добављача директно у свакој апликацији умножава оперативни ризик.<п>Модел кључа којим се управља мрежним пролазом може смањити ту сложеност. Апликације позивају мрежни пролаз помоћу кључа окренутог клијенту или интерног кључа. Мрежни пролаз аутентификује позиваоца, примењује политику закупца, спроводи контролу модела и потрошње, бележи коришћење и користи акредитиве упстреам провајдера на страни сервера. Ово је корисно за апликације са више модела, интерне платформе, агенције и услуге препродавача.<п>За Модел Гате, ово је место где је улога мрежног пролаза релевантна: централизовани кључеви окренути клијентима, обједињена аналитика коришћења, контроле тима, ограничења потрошње, ИП безбедност, оперативне интеграције Телеграма, аутоматизација АПИ партнера и одговор на злоупотребу. За предузећа која обезбеђују клијенте или даље услуге, <а хреф="/ен/доцс/партнер-апи">Партнер АПИ аутоматизација може да учини конзистентним креирање кључева, ограничавање ажурирања, замрзавање и токове рада препродавца уместо ручних.<п>Гатеваи не уклања сваку одговорност са тима за апликације. И даље вам је потребно безбедно складиштење, позадинско овлашћење, изолација станара, дизајн крајње тачке, хигијена ЦИ/ЦД-а, политика брзих података и одговора и ограничења на страни добављача где су доступна. Мрежни пролаз постаје контролна раван високе вредности, тако да су му потребни јаки трезори, евиденције ревизије, контроле приступа, планирање доступности и административно одвајање.<х2>Уобичајене грешке у управљању АПИ кључевима<п>Најчешће грешке су предвидљиве. Тимови стављају кључеве добављача директно у клијентске апликације. Они користе један производни кључ за сваку услугу и купца. Ротирају се тако што се прво бришу, а касније примењују. Они креирају кључеве без власника, ограничења, опсега или истека. Они евидентирају пуна заглавља ауторизације. Они се ослањају само на ограничења стопе за контролу трошкова АИ. Они дају администраторске акредитиве за рунтиме сервисе. Они уклањају кључ који је процурио из Гита без опозива. Они нису запослени, али остављају личне кључеве, датотеке локалног окружења и ЦИ варијабле активне.<п>Још једна суптилна грешка је третирање евиденције брзих одговора и одговора као чисто оперативне. Детаљне евиденције могу помоћи у истраживању злоупотребе, али такође могу да садрже личне податке, садржај корисника, тајне или регулисане информације. Евидентирање на основу метаподатака је често безбедније: бележите отиске кључева, ИД-ове модела, број токена, трошкове, статусне кодове, одлуке о смерницама и ИД-ове захтева подразумевано, а затим захтевајте контролисан приступ за дубље податке за отклањање грешака.<х2>Контролна листа за имплементацију<п>Снажан програм за управљање кључевима АПИ-ја може да почне са фокусираном контролном листом, ><улирајте све власнике контролне листе>Ц><ре>све контролне листе. окружења, закупци, опсег, ограничења и временске ознаке последње употребе.<ли>Одвојите кључеве према окружењу, радном оптерећењу, закупцу, клијенту и класи акредитива.<ли>Преместите акредитиве добављача на страну сервера и ван прегледача, апликација за мобилне уређаје, бележница и јавних клијената.<ли>Користите алатке са најмањим привилегијама, моделе крајњих тачака за најмање привилегије, алатке за крајњу тачку са најмањим привилегијама, алатке за најмање привилегије и ван њих. функције.<ли>Додајте ограничења потрошње, ограничења стопе, листе дозвољених модела, упозорења о аномалијама и контроле замрзавања у хитним случајевима.<ли>Складиштите тајне у менаџеру тајних података, трезору, заштићеном складишту ЦИ варијабли или систему акредитива којим управља мрежни пролаз.<ли>Редигујте тајне из аналитичких евиденција, трагова веба и алатки за подршку, алатки за анализу, о грешкама, акредитива којима управља мрежни пролаз. извештаје.<ли>Примените ротацију са кључевима који се преклапају, праћење последње употребе, замрзавање и коначно брисање.<ли>Интегришите тајно скенирање у спремишта и ЦИ/ЦД, укључујући прилагођене шаблоне кључева.<ли>Понашање докумената ван укрцаја за личне кључеве, налоге услуге, кључеве радног простора и кључеве за клијенте који су одвојени од административних кључева за покретање. акредитиви.<ли>Тестирајте одговор на инцидент пре него што стварно цурење примора процес.<х2>Закључак<п>Управљање кључем АПИ-ја за АИ АПИ-је се односи на контролу идентитета, овлашћења, трошкова и оперативног радијуса експлозије. Безбедни кључ није само насумични низ. Има власника, сврху, обим, окружење, буџет, рок трајања, путању ротације, ревизијски траг и план реаговања на инциденте.<п>Практични циљ није стварање бирократије око сваког захтева. То је да би нормалан рад био безбеднији: програмери могу да граде, услуге могу да раде, клијенти могу да буду обезбеђени, а безбедносни тимови могу да одговоре шта се догодило када кључ процури или потрошња нагло порасте. Почните са инвентаром и границама, а затим додајте најмање привилегија, безбедно складиштење, ротацију, надгледање и аутоматизацију одговора. За приступ вештачкој интелигенцији више провајдера, мрежни пролаз може да централизује већи део те контроле, али ауторизација апликација и тајна хигијена и даље остају основне инжењерске одговорности.