API-võtmehaldus ei ole enam väike armatuurlaua ülesanne. AI API-sid kasutavate meeskondade puhul on see osa turbe-, kulu- ja toimimismudelist iga rakenduse jaoks, mis saadab viipasid, võtab vastu mudeliväljundit, kutsub tööriistu või kulutab raha mõõdetud järeldustele.
Paljud meeskonnad alustavad ühest pakkuja võtmest kohalikus keskkonnafailis. See toimib seni, kuni sama võti kuvatakse CI muutujates, sülearvutites, IDE laiendustes, agentides, pakktöödes, klientide integreerimises ja tugiskriptides. Sel hetkel pole lekkinud võti ainult autentimisprobleem. See võib avaldada viipasid ja vastuseid, käivitada ootamatuid tasusid, helistada lisatasu mudelitele, käitada tööriistu rakenduse volitustega või muuta intsidentidele reageerimine sõltuvaks oletustest.
Selles juhendis käsitletakse API võtmehaldust kui elutsüklit: kuidas võtmeid kavandatakse, väljastatakse, salvestatakse, reguleeritakse, jälgitakse, pööratakse ja tühistatakse. See keskendub AI API juurdepääsule, kus tavapärastele API turvaprobleemidele lisandub juurdepääs mudelile, loapõhised kulutused, mitme teenusepakkuja mandaadid, klientide omistamine ja OpenAI-ga ühilduvad kliendid.
Kus API võtmed sobivad API turvalisusega
API-võti tõendab tavaliselt mandaadi omamist. See vastab küsimusele "kas sellel helistajal on kehtiv saladus?" See ei vasta iseenesest igale olulisele autoriseerimisküsimusele.
Tagaprogramm peab siiski otsustama, kas helistajal on juurdepääs konkreetsele rentnikule, objektile, mudelile, lõpp-punktile, tööriistale, tööruumile, aruandele või haldusfunktsioonile. OWASP API turvalisuse 10 parimat riski, nagu katkine objektitaseme autoriseerimine, rikutud autentimine, piiranguteta ressursitarbimine ja katkine funktsioonitaseme autoriseerimine, tuletavad meelde, et kehtiv mandaat on ainult üks süsteemi kiht.
AI API-de puhul on see eristamine oluline, kuna sama võti võib olla võimeline sooritama toiminguid väga erinevate riskiprofiilidega. Võti, mis suudab ühe sisemise töövoo jaoks odavat tekstimudelit kutsuda, ei tohiks automaatselt helistada tasulistele mudelitele, luua paketttöid, pääseda juurde teise rentniku andmetele, kutsuda tööriistu, mis saadavad meile ega hallata arveldusseadeid.
Püsiv API turbemudel eristab kolme probleemi:
- Autentimine: mis tõendab, et päringul on kehtiv või mandaadi olemasolu. seanss.
- Autoriseerimine: otsustada, mida autentitud helistaja praeguses rentniku, keskkonnas ja ärikontekstis teha võib.
- Juhtimine: kulutuste, määra, mudelile juurdepääsu, andmete eksponeerimise ja administratiivse kontrolli piiramine, nii et ühel veal on piiratud leviraadius.
API-ressursid ei tohiks olla kasulikud ega kõrge väärtusega. Kasutage neid HTTPS-i, serveripoolsete autoriseerimiskontrollide, auditilogide, vähimate õiguste, määrapiirangute, kululimiitide ja turvalise salajase haldamisega.
Alustage reaalajas API võtmete loendiga
Te ei saa hallata võtmeid, mida te ei saa nimetada. Esimene praktiline samm on kõigi teie tehisintellektisüsteemides kasutatavate API võtmete ja mandaadisarnaste objektide reaalajas inventuur.
Iga võtmekirje peab sisaldama vähemalt võtme ID-d, pöördumatut räsi või sõrmejälge, omanikku, loojat, meeskonda või rentnikku, keskkonda, töökoormust, ulatuseid, lubatud mudeleid, lubatud lõpp-punkte, kulupoliitikat, määrapoliitikat, IP-piiranguid, vajaduse korral kasutusaja piiranguid, expiry, stamp ja mp-d. metaandmed.
Varud peaksid katma rohkem kui tootmise käitusaja võtmed. Kaasake isiklikud arendaja võtmed, teenusekonto võtmed, CI/CD võtmed, tööruumi võtmed, kliendi või rentniku võtmed, edasimüüja hallatavad võtmed, arveldus-/aruandlusvõtmed, administraatori API mandaat ja ülesvoolu pakkuja mandaat.
Kõige olulisemad väljad on omandiõigus, eesmärk, ulatus, viimane kasutus ja piirangupoliitika. Ilma nendeta muutub iga tulevane turbeülesanne aeglasemaks: väljalülitamine, rotatsioon, lekkereaktsioon, kulude uurimine ja klienditugi.
Võtmepiiride kavandamine tahtlikult
Suurim API-võtmehalduse viga on ühe võtme kasutamine liiga paljudes piirides. Jagatud tootmisvõti on alguses mugav, kuid see hävitab omistamise ja muudab tühistamise häirivaks. Kui see lekib, peate võib-olla peatama iga teenuse liikluse, kuid ei suuda siiski tuvastada, milline töökoormus probleemi põhjustas.
Head võtmepiirid järgivad ettevõtte ja tarkvara kuju. Eraldage tootmine arendusest, inimesed teenustest, kliendid sisemistest meeskondadest, rentnikud üksteisest, käitusaja mandaadid administraatorimandaatidest ja lüüsi väljastatud kliendivõtmed ülesvoolu pakkuja võtmetest.
Keskkonnapiirid
Arendus, lavastus ja tootmine peaksid kasutama eraldi võtmeid. Arendusvõti ei tohiks jõuda tootmisandmete ega tootmiseelarveteni.Etapivõtmel ei tohiks olla juurdepääsu klientide reaalajas töökoormustele, välja arvatud juhul, kui sellel on rangelt kontrollitud põhjus.
Töökoormuse piirid
Igal teenusel, paketttööl, agendipargil, integratsioonil või ajastatud toimingul peab olema oma võti või teenusekonto. See võimaldab teil vastata põhiküsimustele: milline töökoormus kulutas raha, millise teenuse autentimine ebaõnnestus, milline integreerimine kasutas aegunud mudelit ja milline võti tuleks intsidendi ajal külmutada.
Üürniku ja kliendi piirid
Mitme rentnikuga süsteemid vajavad omistamist ja isoleerimist. Kui viipade esitamiseks kasutatakse kliendile suunatud API-võtit, peaks päring olema seotud kliendi, rentniku, rakendusega ja ideaalis pseudonüümiga lõppkasutaja või tegutsejaga. Ühe rentniku ohustatud võti ei tohiks võimaldada juurdepääsu teise rentniku andmetele, mudeliprofiilile, eelarvele ega logidele.
Pakkuja mandaadi piirid
Ülevoolu pakkuja võtmed erinevad klientidele või siserakendustele väljastatavatest võtmetest. Pakkuja mandaadid peaksid jääma serveri poolele, hoidma hoidlas või salahalduris ning neid ei tohi kunagi saata brauseritesse, mobiilirakendustesse, lauaarvutiklientidele, avalikesse sülearvutitesse või kliendi kontrollitavatesse keskkondadesse.
Lüüs võib siin aidata, paljastades ühe kliendile suunatud võtmepinna, säilitades samal ajal ülesvoolu pakkuja mandaadid lüüsi taga. See võimaldab tsentraliseerida kasutusanalüütikat, tühistamist, meeskonna juhtimist ja eeskirjade jõustamist teenusepakkujate vahel. Kui standardite kliente OpenAI-ga ühilduva API ümber, muutub lüüsi piir eriti oluliseks, kuna paljud tööriistad eeldavad üht põhi-URL-i ja kandja luba.
Rakendage mudelitele, lõpp-punktidele, tööriistadele ja kuludele vähim õigusi
Vähiim töökoormus tähendab ainult võtmele juurdepääsu. AI-süsteemide puhul ei ole ulatus ainult API lõpp-punktide loend. See hõlmab ka mudeleid, tööriistu, lubade eelarveid, määrapiiranguid, rentnikke, andmeklasse ja haldusfunktsioone.
Praktiline AI API võtmepoliitika võib hõlmata järgmist:
- lubatud mudeliperekonnad või konkreetsed mudeli ID-d.
- Lubatud lõpp-punktid, nagu vestluse lõpud, manustused, paketttööd või haldusliidese lisamine,
võtmete loomine. API-d, arvelduse API-d ja tööruumi halduse API-d käitusaja võtmete jaoks.
- Võtmepõhised piirangud taotlustele minutis ja žetoonide kohta minutis.
- Üürniku-, meeskonna- või kliendipõhised kululimiidid.
- Premium-mudel juhib nii, et kas madala riskiga töövoog ei pruugi selliste võtmete kohta käia. välised konnektorid, koodikäivitus, otsingusüsteemid või äritoimingud.
- IP-lubamisloendid stabiilse serveripoolse töökoormuse jaoks, kus võrgutee on prognoositav.
Kulude juhtimine on osa mõõdetud AI API-de API-turvalisusest. Lekkinud võti võib tekitada otsest rahalist kahju isegi siis, kui see kunagi tundlikele andmetele juurde ei pääse. Hindade piirangud aitavad, kuid neist ei piisa. Tokenide maht, korduskatsed, paketttööd, tööriistakutsed ja mudelivalik mõjutavad kulusid. Turvaline juurutamine peaks kombineerima määra kontrolli kululae, mudelite lubatud loendite, kõrvalekallete tuvastamise ja hädaolukorra külmutamise juhtelementidega.
Meeskonnad, kes võrdlevad mudeli maksumust ja juurdepääsupoliitikat, peaksid hoidma turvalisuse ja rahanduse kooskõlas. Mudelhinnakujundus ei ole ainult hankeküsimus; see määrab, kui palju ohustatud või valesti konfigureeritud võti võib kulutada. Hoidke kinnitatud mudeliprofiilid eelarvetega seotuna ja vaadake need üle, kui teie mudelite segu muutub, eriti kui kasutate AI mudeli hinnakujundust, et suunata töökoormusi kulude ja võimekuse alusel.
Säilitage saladused, kuhu need kuuluvad.
API võtmed kuuluvad salahalduritesse, serveri-/CD-konfiguratsioonisse, juhitavasse CI-sse või tagasivoolu. Need ei kuulu lähtekoodi, brauseri JavaScripti, mobiilikomplektidesse, töölauarakenduste pakettidesse, avalikesse märkmikesse, ekraanipiltidesse, vestlussõnumitesse, analüütika kasulikesse koormustesse, tugipiletitesse ega logidesse.
Kliendipoolne kokkupuude on tavaline tõrkerežiim. Kui teenusepakkuja võti on manustatud brauserisse või mobiilirakendusse, saab igaüks, kes saab rakendust kontrollida, selle välja võtta ja kontoomaniku nimel taotlusi esitada. Kontrollimatutes keskkondades töötavate brauserite, mobiilirakenduste, IDE-parkide ja agentide puhul kasutage serveripoolset puhverserverit või lühiajalisi kitsa ulatusega delegeeritud mandaate. Ärge levitage pikaajalisi teenusepakkuja mandaate klientidele, keda te ei saa kontrollida.
CI/CD vajab samasugust distsipliini. Salvestage võtmed kaitstud muutujatena. Piirake, kes saavad neid lugeda või muuta. Vältige ehituslogides keskkonnamuutujate printimist. Redigeerige autoriseerimispäised nurjunud päringu väljavõttes. Käsitlege eelvaate juurutusi ja kahvlitõmbetaotlusi kaitstud tootmistorustike erinevate usaldustsoonidena.
Erilist tähelepanu väärivad logid ja jälgitavuse süsteemid.Salvestage võtmete sõrmejäljed, päringu ID-d, rentnike ID-d, mudeli ID-d, vastuse olek, märgiloendurid, kululoendurid, vajaduse korral IP- või kliendi metaandmed ja poliitikaotsused. Ärge salvestage täielikke API-võtmeid. Redigeerige jälgede, pöördpuhverserveri logide, erandite aruannete, veebihaagi kasulike koormuste, tugitööriistade, analüüsisündmuste ja surnud tähtedega järjekordade saladusi.
Ehitage rotatsioon enne hädaolukorda
Pööramine ei tähenda lihtsalt ühe võtme kustutamist ja teise loomist. Kui juurutatud teenused sõltuvad endiselt vanast võtmest, põhjustab kustutamine seisakuid. Usaldusväärne pöörlemisprotsess kasutab kattumist, vaatlust ja selget lõpetamispunkti.
Üldine on kahe aktiivse pesaga pöörlemisrühm. Looge asendusvõti, juurutage see igas sõltuvas süsteemis, jälgige vana võtme viimast kasutamist, külmutage vana võti, kui liiklus on liikunud, ja kustutage see pärast usaldusakent. Hoidke tagasipööramise reeglid selged: millal saab vana võtme uuesti lubada, kes saab selle heaks kiita ja kui kaua võib see saadaval olla?
Võtme lühike kasutusaeg vähendab mandaadi vananemise riski, kuid suurendab töökoormust. Pikaealised võtmed vähendavad juurutamise katkemist, kuid loovad suurema akna unustatud volikirjade ja töötajate lahkumise lüngad. Õige poliitika sõltub töökoormusest. Suure väärtusega tootmisteenuse konto võib automatiseeritult muutuda kindla ajakava alusel. Ajutine arendajavõti peaks kiiresti aeguma. Kliendi hallatav integratsioon võib vajada pikemat migratsiooniakent ja selgeid aegumissõnumeid.
Ärge pöörake iga võtit ühtemoodi. Haldusmandaadid, mis võivad võtmeid loetleda, luua, kustutada või muuta, on suurema riskiga kui käitusaegsed järeldusvõtmed ning neil peaks olema tugevam juhtimine, kitsam juurdepääs ja agressiivsem jälgimine. Käitusaegsetel võtmetel ei tohiks olla haldusõigusi, välja arvatud juhul, kui sellel on konkreetne läbivaadatud põhjus.
Lekete ja ebatavalise kasutamise tuvastamine
Lekketuvastus toimib kõige paremini siis, kui mitu süsteemi üksteist tugevdavad. Allika juhtimise salajane skannimine võib püüda hoidlatesse määratud võtmeid. CI-kontrollid võivad enne ühendamist blokeerida ilmsed lekked. Kohandatud mustrid suudavad tuvastada sisemisi võtmevorminguid. Pakkujate armatuurlauad võivad paljastada ebatavalisi tegevusi. Lüüsi telemeetria võib näidata uusi IP-aadresse, uusi geograafiaid, ebaõnnestunud autentimispurse, äkilisi kulutamiskiirusi või kõnesid ootamatutele mudelitele.
Kasulikud turvapaneelid hõlmavad seisvaid võtmeid, omanikuta võtmeid, piiranguteta võtmeid, aegumistähtajaid, uutest võrkudest kasutatavaid võtmeid, tõrgeteta võtmete kiire kasvu vastuvõtvaid võtmeid, tõrgeteta võtmete kiire kasvuga võtmeid, klahvid, mis lähenevad kululagedele.
Tuvastamine peaks hõlmama ka palke ja asünkroonseid süsteeme. Veebihaagid, taustatööd, järjekorrad ja hilinenud valmimised vajavad päringu ID-sid ja algse võtme omistamist. Vastasel juhul ei pruugi kahtlase tagasihelistamise või paketttulemuse sidumine selle loonud võtme ja rentnikuga olla võimatu.
Kui Giti ajalukku ilmub saladus, ei piisa selle hoidlast eemaldamisest. Igaüks, kes pääses hoidlasse, ehitas logisid, peegleid, kahvleid, paki artefakte või vahemällu salvestatud lehti, võib võtme juba kopeerida. Mandaat tuleb kehtetuks tunnistada või külmutada ja seejärel asendada.
Rakitud API-võtmele reageerimine
Hea juhtumile reageerimise plaan on lühike, läbimõeldud ja konkreetne. Esimene otsus on tavaliselt, kas külmutada või tühistada. Freeze peatab liikluse kiiresti, säilitades samal ajal rekordi uurimise jaoks. Tühistamine keelab võtme jäädavalt. Mõned meeskonnad kasutavad kõigepealt külmutamist, kui nad vajavad auditi järjepidevust ja viivitamatuid tagasipööramise võimalusi; teised tühistavad kinnitatud avalike lekete korral automaatselt. Kumbki lähenemine vajab automatiseerimist ja selgeid volitusi.
Praktiline vastusevoog näeb välja selline:
- Külmutage või tühistage kahtlustatav võti tõsiduse ja usalduse põhjal.
- Tuvastage omanik, rentnik, töökoormus, ulatused, mudeli juurdepääs, kulupoliitika ja viimati kasutatud ajaskaala.
- Vaadake üle kasutus, mudelid, mudelid, IP-aadressid, lõpp-punktid, käsklused ja viidad, mudelid, lõpp-punktid, käsklused kulusid.
- Hinda mõjutatud andmeid, rentnikke, allavoolu toiminguid ja arvelduse mõju.
- Väljasta asendusvõti, millel on parandatud ulatus ja piirangud.
- Eemaldage algpõhjus, nt salajane saladus, paljastatud logi, laiaulatuslik CI-muutuja või kliendipoolne pakett.
- Lisage, nt salajane, lühiskannimise vältimine, logimise ulatus. või kuluhoiatused.
- Dokumenteerige juhtum ja värskendage käsiraamatuid.
Asendusetapp ei tohiks sama riski uuesti tekitada. Kui võti lekkis, kuna seda jagati kümne teenuse vahel, asendage see eraldi teenusekonto võtmetega. Kui see lekkis läbi logide, parandage logimine enne uue võtme väljastamist. Kui see kulutas üle, kuna see võib helistada igale mudelile, lisage mudelite lubade loendid ja kululimiidid.
Lüüsi hallatavad võtmed ja mitme teenusepakkuja AI-juurdepääs
AI meeskonnad kasutavad sageli mitut mudelipakkujat.Igal pakkujal on oma võtmemudel, tööruumi struktuur, tariifide piirangud, mudelite nimed, hinnakujundus ja administratiivsed API-d. Iga pakkuja võtme haldamine otse igas rakenduses suurendab operatsiooniriski.
Lüüsiga hallatav võtmemudel võib seda keerukust vähendada. Rakendused helistavad lüüsile kliendile suunatud või sisemise võtmega. Lüüs autentib helistaja, rakendab rentniku poliitikat, jõustab mudeli ja kulu juhtelemendid, registreerib kasutuse ja kasutab serveripoolselt ülesvoolu pakkuja mandaate. See on kasulik mitme mudeliga rakenduste, sisemiste platvormide, agentuuride ja edasimüüjate teenuste jaoks.
Modellvärava puhul on siin oluline lüüsi roll: tsentraliseeritud kliendile suunatud võtmed, ühtne kasutusanalüüs, meeskonna juhtelemendid, kululimiidid, IP-turvalisus, Telegrami tööintegratsioonid, Partner API automatiseerimine ja väärkasutusele reageerimine. Ettevõtete jaoks, kes varustavad kliente või järgnevaid teenuseid, võib Partner API automatiseerimine muuta võtmete loomise, värskenduste piiramise, külmutamise ja edasimüüja töövood käsitsi asemel järjepidevaks.
Lüüs ei eemalda rakendustiimilt kõiki kohustusi. Teil on endiselt vaja turvalist salvestusruumi, taustasüsteemi autoriseerimist, rentnike isoleerimist, lõpp-punkti disaini, CI/CD hügieeni, viipe- ja vastuseandmete poliitikat ning pakkujapoolseid piiranguid, kui need on saadaval. Lüüsist saab suure väärtusega juhttasand, seega vajab see tugevat võlvi, auditiloge, juurdepääsu juhtelemente, saadavuse planeerimist ja halduseraldust.
Levinud API võtmehalduse vead
Kõige tavalisemad vead on etteaimatavad. Meeskonnad panevad pakkuja võtmed otse kliendirakendustesse. Nad kasutavad iga teenuse ja kliendi jaoks ühte tootmisvõtit. Need pöörlevad, kustutades esmalt ja juurutades hiljem. Nad loovad võtmeid ilma omanike, piirangute, ulatuse või aegumiseta. Nad logivad täisvolituse päised. Nad toetuvad tehisintellekti kulude kontrollimiseks ainult kiiruspiirangutele. Nad annavad käitusaja teenuste administraatori mandaadid. Nad eemaldavad Gitist lekkinud võtme ilma seda tühistamata. Nad jätavad töötajatest välja, kuid jätavad isiklikud võtmed, kohaliku keskkonna failid ja CI muutujad aktiivseks.
Teine peen viga on viipe ja vastuse logimise käsitlemine puhtalt operatiivsena. Üksikasjalikud logid võivad aidata kuritarvitamist uurida, kuid need võivad sisaldada ka isikuandmeid, kliendi sisu, saladusi või reguleeritud teavet. Metaandmete esmane logimine on sageli turvalisem: jäädvustage võtmete sõrmejäljed, mudeli ID-d, lubade arvud, kulud, olekukoodid, poliitikaotsused ja päringu ID-d vaikimisi, seejärel on vaja kontrollitud juurdepääsu sügavamate silumisandmete jaoks.
Rakendamise kontroll-loend
Tugev API-võtmehaldusprogramm võib alata keskendunud kontrollnimekirjaga, inventari keskkond, kõik võtmed, omanikud,
> rentnikud, ulatused, piirangud ja viimase kasutuse ajatemplid.Järeldus
AI-liideste API võtmehaldus seisneb identiteedi, volituste, kulude ja operatiivse plahvatuse raadiuse kontrollimises. Turvaline võti ei ole lihtsalt juhuslik string. Sellel on omanik, eesmärk, ulatus, keskkond, eelarve, aegumine, rotatsioonitee, kontrolljälg ja juhtumitele reageerimise plaan.
Praktiline eesmärk ei ole luua iga taotluse ümber bürokraatiat. Selle eesmärk on muuta tavaline töö turvalisemaks: arendajad saavad ehitada, teenused töötavad, kliente saab varustada ja turvameeskonnad saavad vastata, mis juhtus, kui võti lekib või kulutab naelu. Alustage laoseisust ja piiridest, seejärel lisage minimaalsed privileegid, turvaline salvestus, pööramine, jälgimine ja reageerimise automatiseerimine. Mitme teenusepakkuja AI-juurdepääsu puhul võib lüüs suure osa sellest juhtimisest tsentraliseerida, kuid rakenduste autoriseerimine ja salajane hügieen jäävad siiski inseneri põhiülesanneteks.