Pakkuja mandaadihoidlad mitme mudeli AI lüüside jaoks: eraldi käitusaeg, administraator, arveldus ja BYOK juurdepääs
Praktiline mandaadihoidla muster mitme mudeliga AI-lüüside jaoks: klassifitseerige ülesvoolu pakkuja võtmed, isoleerige käitusaeg administraatorijuurdepääsust, siduge BYOK-i mandaadid rentnikega, pöörake turvaliselt ja kontrollige iga mandaadiga seotud otsust.
Allavoolu API võtmed ja ülesvoolu pakkuja mandaadid lahendavad erinevaid probleeme. Teie lüüsi väljastatud arendaja võti tuvastab rakenduse, meeskonna, rentniku, eelarve ja eeskirjade konteksti. Ülesvoolu pakkuja võti võimaldab lüüsil kulutada raha ja pääseda juurde teenusepakkuja konto mudelitele. Nende käsitlemine samasuguse saladusena seisneb selles, et meeskonnad saavad jagatud projektis ühe piiramatu võtme, käitusaegsetes teenustes administraatori mandaadid ja puudub usaldusväärne viis vastata, milline rentnik millise teenusepakkujapoolse tasu põhjustas.
Praktiline muster on pakkuja mandaadihoidla: spetsiaalne juhtimistasand ülesvoolu mandaatide importimiseks, klassifitseerimiseks, salvestamiseks, valimiseks, pööramiseks ja auditeerimiseks. See peaks asuma ruuteri, arveldusraamatu, poliitikamootori ja toimingute töövoo taga – mitte rakenduse koodis, mudeli konfiguratsioonifailides, rentniku kirjetes ega analüüsisündmustes.
Lugeja probleem: ülesvoolu mandaadid muutuvad nähtamatuks infrastruktuuriks
Enamik mitme mudeli juurutusi algab lihtsa eesmärgiga: suunake üks OpenAI-ga ühilduv päring parimale saadaolevale pakkujale. Seejärel ilmub rohkem kontosid: üks pakkuja projekt tootmiseks, teine hindamiseks, Anthropic tööruum äriüksuse jaoks, Google Cloudi projekt Gemini jaoks ja mitmed kliendi tarnitud võtmed BYOKi lepingute jaoks.
Oht ei ole pelgalt salajane leke. See on autoriseerimiskonteksti kaotamine. Kehtiv pakkuja võti võib tehniliselt olla võimeline lõpp-punkti kutsuma, kuid lüüs peab siiski teadma, kas see võti on selle rentniku, mudeliperekonna, andmete säilitamise poliitika, eelarve, piirkonna ja automatiseerimistee jaoks lubatud.
Fakt: pakkujaplatvormid paljastavad erinevad kontopiirid ja mandaaditüübid. OpenAI dokumenteerib projekte ja teenusekontosid ning teenusekonto API võtmeõigusi, et lugeda ja kirjutada juurdepääsu projekti API ressurssidele. OpenAI paljastab ka administraatori API võtmeobjektid tavalisest projekti/käitusaja API kasutusest eraldi. Anthropic dokumenteerib tööruume organisatsiooni piirina ja väidab, et Admin API lõpp-punktid nõuavad administraatori API võtmeid, mis erinevad standardsetest API võtmetest; Anthropic märgib ka, et API-võtmed on seotud tööruumiga, kus need luuakse, ja neid ei saa tööruumide vahel teisaldada. Google'i Gemini API võtmedokumentatsioonis öeldakse, et iga Gemini API võti on seotud Google Cloudi projektiga ja soovitab API piiranguid, et vähendada võtme kahjustamise korral kahju.
Soovitus: ärge looge üht üldist välja „provider_key” ja nimetage seda tehtuks. Koostage mandaatide loend, mis säilitab pakkujaspetsiifilised piirid, jättes samal ajal lüüsile normaliseeritud poliitikamudeli.
Enne võtmete vastuvõtmist määrake mandaatide taksonoomia
Võlv peaks tagasi lükkama mitmetähenduslikud volikirjad. Importimise ajal peab operaator või automatiseerimise töövoog mandaadi klassifitseerima. Kasutage vähemalt järgmisi kategooriaid:
- Käitusaja järeldamise mandaadid: mida lüüs kasutab mudeli järelduste lõpp-punktide (nt vestlus, vastused, manustamine, modereerimine, transkriptsioon või pildi genereerimine) kutsumiseks, olenevalt pakkuja toest.
- Administraatori automatiseerimismandaadid: kasutatakse teenusepakkujapoolsete organisatsioonide, tööruumide, projektide, kasutajate, võtmete või haldusressursside haldamiseks. Need ei tohiks kunagi asuda käitusaja päringu teel.
- Arveldus- ja aruandlusmandaadid: kasutatakse kasutus-, arve-, kulude- või organisatsiooniaruannete hankimiseks, kui pakkujad neid API-sid toetavad. Hoidke need järeldusvõtmetest eraldi, et aruandlustööd ei saaks mudelikasutust genereerida.
- Ainult hindamise mandaadid: kasutatakse võrdlusuuringu, kvaliteedi tagamise, migratsiooni või etapi töövoogude jaoks. Neil peaksid olema madalad kvoodid, selged keskkonnasildid ja neil ei tohiks olla varunduskõlblikkust.
- Kliendi BYOK-mandaadid: kliendi tarnitud võtmed, mis on seotud konkreetse rentniku, teenusepakkuja konto, lepingu ja andmepoliitikaga. Neid ei tohiks kombineerida jagatud marsruutimiseks, välja arvatud juhul, kui klient on selle selgesõnaliselt lubanud.
See taksonoomia ei ole ainult dokumentatsioon. See peaks juhtima juurdepääsu kontrolli, marsruutimise sobivust, hoiatamist ja rotatsiooni töövooge. Kui mandaat imporditakse ilma kategooria, omaniku, pakkuja konto piiri ja lubatud kasutuseta, peaks see olema keelatud.
Säilitage saladusi hoidlas, mitte tootekirjetes
Võlv peaks olema ainus komponent, mis suudab ülesvoolu mandaate dekrüpteerida. Teised süsteemid võivad salvestada viiteid, räsi, olekuvälju ja poliitika metaandmeid, kuid mitte mandaadi väärtust ennast.
Ärge talletage nendes kohtades ülesvoolu saladusi
- Üürniku profiili read.
- Mudelmarsruutimise konfiguratsioonifailid.
- Küsi logid või jälgimisvahemikud.
- Analüütika sündmuste kasulikud koormused.
- Arendajale suunatud CI muutujad.
- Toetage pileteid, vestlustööriistu või ekraanipilte.
Kasutataval võlvi kujundusel on kaks tasapinda. Salalennuk salvestab krüptitud mandaadimaterjali ja kontrollib täpselt dekrüpteerimistoiminguid. Metaandmete tasand salvestab mittesalajast atribuudid, mida marsruutimine ja haldamine kasutavad. Tavaliselt peaks ruuter vajama väljasaatmise ajal ainult mandaadi ID-d ja lühiajalist mälus oleva salajase otsingu funktsiooni, mitte laialdast juurdepääsu andmebaasile igale pakkuja võtmele.
Kaitske varahoidlat väärtusliku infrastruktuurina: ümbriku krüptimine või hallatud KMS, ranged teenuseidentiteedid, klaasi purunemise protseduurid, varundamise ja taastamise testimine, juurdepääsu ülevaatus ja hoiatus ebatavalise dekrüpteerimismahu korral. Keskvarahoidla lihtsustab juhtimist, kuid kontsentreerib ka riske. See on kompromiss.
Lisage eeskirjade metaandmed igale mandaadile
Metaandmete mudel peaks olema piisavalt selge, et lüüs saaks otsustada, kas mandaat on sobilik, enne kui see puudutab pakkuja lõpp-punkti.
Praktiline volikiri sisaldab järgmist:
- credential_id: sisemine muutumatu identifikaator.
- pakkuja: OpenAI, Anthropic, Gemini, Azure OpenAI või mõni muu adapter.
- provider_account_boundary: organisatsioon, projekt, tööruum, pilveprojekt, tellimus või samaväärne.
- credential_class: käitusaeg, administraator, arveldus, hindamine või BYOK.
- keskkond: tootmine, lavastus, arendus, hindamine, liivakast.
- rentant_binding: jagatud platvormi mandaat, üks rentnik, rentnike rühm või kliendi BYOK rentnik.
- allowed_model_families: näiteks teksti genereerimine, manustamine, nägemus, pilt, heli või konkreetse mudeli profiilid.
- allowed_endpoints: normaliseeritud lüüsi võimalused, mis on vastendatud pakkuja lõpp-punktidele.
- data_policy: lubatud säilitusklass, logimisklass, elukohanõue ja funktsioonipiirangud.
- eelarve ulatus: kulukeskus, edasimüüja klient, siseosakond või leping.
- omanik: nimetatud meeskond või vastutav isik.
- loodud_kell, aegub_kuupäev, rotation_due_at, last_used_at.
- health_status: tundmatu, terve, halvenenud, volitamata, quota_exhausted, keelatud.
- emergency_disable: vahetu marsruutimisplokk, mis ei sõltu tavapärasest poliitikaseisundist.
Hoidke see mudeli pakkuja neutraalne, kuid ärge kustutage pakkuja tegelikkust. Antroopse tööruumiga seotud võti ja Google Cloudi projektiga seotud Gemini võti ei ole omavahel asendatavad, kuna mõlemad võivad teksti genereerida. Lüüs vajab seda päritolu auditite, tagasimaksete ja turvalise tõrkeotsuste jaoks.
Eri käitusaja-, administraatori- ja arveldusjuurdepääs
Kõige olulisem reegel on lihtne: käitusaja järeldamiseks kasutatav võti ei tohiks hallata pakkujaorganisatsioone, tööruume, kasutajaid, projekte ega haldusressursse.
Käitamise ajal liiklus on suur ja avatud suurimale tööpinnale. See läbib päringu ruuterid, uuesti proovimise loogika, voogesituse töötlejad, mudeliadapterid ja juhtumite töövood. Administraatori mandaadid on madala sagedusega ja suure mõjuga. Nad peaksid elama eraldi kinnitustee taga, millel on lühikesed TTL-id, mida nimetatakse vajaduse korral inimese heakskiiduks, tugev logimine ja käitusaja marsruutimiskõlblikkus.
Ka arveldusmandaadid väärivad eraldamist. Arvete vastavusse viiv aruandlustöö ei tohiks olla võimeline genereerima lõpetamisi ja käitusaegne järeldusvõti ei tohiks olla ainus viis kasutusaruannete toomiseks. Kui teenusepakkuja ei paku peeneteralist eraldamist, kompenseerige lüüsis: isoleerige mandaat, piirake, millist sisemist teenuseidentiteeti saab selle hankida, ja logige iga kasutuskord.
Soovitus: muutke mandaadiklass rangeks autoriseerimispiiriks, mitte sildiks. Käitusaegne dispetšer ei peaks saama taotleda administraatori mandaadi dekrüpteerimist isegi siis, kui konfiguratsiooniviga viitab selle ID-le.
Mandaadi valimise poliitikamootori loomine
Mandaadi valimine peaks toimuma pärast seda, kui lüüs autentib allavoolu helistaja ja enne teenusepakkuja helistamise katset. Reeglimootor peaks ühendama mitu sisendit:
- Üürniku ID ja allavoolu API võtme ulatus.
- Taotletud mudeliprofiil või pakkujaspetsiifiline mudeli ID.
- Lõpp-punkti võimalus: vestlus, manustamine, pilt, heli, pakett, failid, tööriistad või administraatori automatiseerimine.
- Andmete säilitamise ja elukoha nõuded.
- Eelarve, krediidireserveerimine ja kulukeskus.
- Määrusepiirangu olek ja kvoodisurve.
- Mandaadi metaandmed, tervis, keskkond ja rentniku sidumine.
Mootor peaks tagastama ühe kolmest tulemusest: luba valitud mandaadiga, keeldu poliitika põhjusega või nõuab kinnitust. Keeldumised peaksid olema piisavalt täpsed, et operatiivmeeskonnad saaksid probleemi lahendada, ilma et see avaldaks arendajatele salajast materjali.
Otsuse näide:
Ärge rakendage varundamist kui „proovige järgmist klahvi”. Varupoliitika tuleb uuesti käivitada. Jagatud platvormi mandaat võib pakkuja juurdepääsu jaoks kehtida, kuid ainult BYOK-i kliendi jaoks kehtetu. Teise projekti mandaadil võib olla kvoot, kuid see võib rikkuda kulude omistamise või säilitamise nõudeid.
Käsitlege BYOK-i üürnikule kuuluva juurdepääsuna, mitte vaba võimsusega
BYOK muudab usaldusmudelit. Klient esitas mandaadi, nii et tema liiklust saab tasuda teenusepakkuja kontolt, seda reguleerida või isoleerida. See mandaat peaks olema seotud kliendi üürniku ja teenusepakkuja konto päritoluga.
Soovitatavad BYOK-juhtelemendid:
- Üks hoidla kirje kliendi, pakkuja, kontopiiri ja keskkonna kohta.
- BYOKi mandaatide kaudu rentnikeülene marsruutimine puudub.
- Ei kasuta jagatud varuvõimsusena, välja arvatud juhul, kui klient on selle selgesõnaliselt lubanud.
- Kliendile nähtav tervislik seisund, mis ei avalda töötlemata võtit.
- Eraldi rotatsiooni töövoog, mis võimaldab kliendil lisada asendus, enne kui vana võti keelatakse.
- Tühjendage kasutusanalüütikas ja arvetel omistamine: lüüsi rentnik, pakkuja konto piir, mandaadi ID, mudeli profiil ja päringu jälgimise ID.
Agentuuride, edasimüüjate ja partneri API automatiseerimise jaoks võib BYOK olla keerulisem, kuna teenus võib pakkuda rentnikke ja mandaate programmiliselt. Sama reegel kehtib endiselt: automatiseerimine võib importida ja siduda mandaate, kuid see ei tohiks hägustada rentniku omandiõigust.
Lisage lennueelsed tervisekontrollid ilma viipade lekkimiseta
Mandaat võib ebaõnnestuda mitmel põhjusel: tühistatud võti, vale tööruum, puuduv juurdepääs mudelile, keelatud arveldamine, kvoodi ammendumine, lõpp-punkti piirang, regionaalpoliitika mittevastavus või pakkuja katkestus. Kui avastate, et alles pärast tootmistaotluse saabumist, tekivad mürarikkad juhtumid.
Kasutage tervisekontrolle, mis kinnitavad võimekuse ilma kliendiviipasid saatmata. Sünteetiline kontroll võib kutsuda välja minimaalse lõpp-punkti, loetleda lubatud mudelid, kui see on asjakohane, või saata kahjutu fikseeritud viipa, kui see on ainus praktiline võimalus. Hoidke need tšekid odavatena, tariifidega piiratud ning telemeetria ja arveldamise osas märgistatud sünteetilise liiklusena.
Tervisekontroll tuleks läbi viia:
- Mandaadi importimisel.
- Enne tootmismarsruutimiseks mandaadi lubamist.
- Pärast pakkujapoolsete piirangute muutmist.
- Pöörlemise katkestamise ajal.
- Perioodiliselt tootmiskõlblike mandaatide jaoks.
Muu: automaatsed kontrollid tabavad aegunud või alaulatuslikud võtmed varakult, kuid halvasti kavandatud kontrollid võivad teenusepakkuja katkestuste ajal tekitada tarbetuid teenusepakkuja kõnesid, arveldusmüra või valehäireid. Salvestage tervisetulemus koos ajatempli, pakkuja veaklassi, testitud lõpp-punkti ja testitud mudeliperega. Ärge salvestage salajasi väärtusi ega tundlikke viipasid.
Pöörake kahe pesaga, mitte ühe riskantse asendusega
Mandaadi vahetamine ei tohiks olla kustutamise ja palvetamise toiming. Kasutage kahe piluga pöörlemismudelit:
- Impordi asendusmandaat kui passiivne, koos täielike metaandmete ja omanikuga.
- Käitage sünteetilisi tervisekontrolle ettenähtud lõpp-punktide, mudeliperekondade ja kontopiiri jaoks.
- Lubage varjukõlblikkus väikese osa turvalise sünteetilise või madala riskiga liikluse jaoks, kui see on asjakohane.
- Nihutage tootmisliiklust järk-järgult vanalt mandaadilt uuele.
- Jälgige vigu, latentsust, kvoote ja kulu omistamist mandaadi ID järgi.
- Külmutage vanale mandaadile naasmine, kui uus mandaat on stabiilne.
- Tühistage teenusepakkuja vana mandaat ja märkige hoidla kirje tühistatuks.
- Veenduge, et pärast tühistamist ei toimuks vana mandaadi kaudu dekrüpteerimist ega teenusepakkuja kõnesid.
Pöörlemise tähtajad peaksid olema nähtavad operatsioonide vaadetes ja hoiatustes. Hädaolukorra pööramine vajab lühemat teed: keelake mandaat, blokeerige marsruutimine, lubage heakskiidetud asendus ja säilitage kõik auditikirjed juhtumi ülevaatamiseks.
Piirake pakkuja võtmeid, kui pakkuja seda toetab
Lüüsipoliitika on vajalik, kuid teenusepakkujapoolsed piirangud vähendavad löögi raadiust, kui võti on ohus või väärkasutatud. Gemini ja muude pilveplatvormi API võtmete puhul kasutage API/teenuse piiranguid ja sobivaid rakenduspiiranguid, kui need on saadaval. Pakkujate projektide, tööruumide ja teenusekontode puhul vältige ulatuslikke organisatsioonilisi õigusi, kui piisab projekti ulatusega käitusaja võtmest.
Soovitus: säilitage iga mandaadiklassi jaoks pakkujapoolne piirangute kontroll-loend. Kontroll-loend peaks olema impordi ja rotatsiooni kinnitamise osa, mitte eraldi turvaülesanne, mille võib surve all vahele jätta.
Tõrjutus: pakkujapoolsed piirangud lisavad töökulusid. Uued lõpp-punktid, mudelipered, piirkonnad või automatiseerimisfunktsioonid võivad nõuda eeskirjade ja piirangute muutmist. See on parem kui pärast leket avastada, et üks võti pääseb juurde jagatud projekti igale töökoormusele.
Hoidke ainult mandaatide lisamise auditi logi
Kontrolljälg peaks vastama, kes mandaadi importis, mida tal oli lubatud teha, millised marsruutimisotsused selle valisid, millal see ebaõnnestus ja millal see ümber pöörati või tühistati.
Logi need sündmused:
- Mandaat on loodud või imporditud.
- Muudetud metaandmed, sh lubatud lõpp-punktid, rentniku sidumine või andmepoliitika.
- Tervisekontroll teostatud ja tulemus salvestatud.
- Päringu marsruutimispoliitikaga valitud mandaat.
- Siseteenuse identiteedi nõudis mandaadi dekrüptimine.
- Pakkuja kõne nurjus autentimise, autoriseerimise, kvoodi või piirangu vea tõttu.
- Pööramine alanud, liiklus nihkunud, vana mandaat tühistatud.
- Hädaolukorra keelamine on lubatud või kustutatud.
- Juurdepääs on administraatori või klaasimurdmise mandaadile.
Ärge lisage auditisündmustesse mandaadi töötlemata väärtusi. Kasutage mandaadi ID-sid, pakkuja kontode piire, päringu jälgimise ID-sid, osalejate identiteete ja poliitikaotsuste põhjuseid. Suuremahulise käitusaegse liikluse korral saate proovide põhjal üksikasjalikku dekrüpteerida telemeetriat, kuid marsruutimise valik ja kulude omistamine peaksid jääma arveldamiseks ja juhtumitele reageerimiseks piisavalt täielikuks.
Rakendamise kontroll-loend
- Looge mandaatide taksonoomia ja keelduge klassifitseerimata impordist.
- Teisaldage kõik pakkuja saladused spetsiaalsesse krüptitud hoidlasse.
- Salvestage marsruutimise metaandmeid salajasest materjalist eraldi.
- Muutke käitusaja-, administraatori-, arveldus-, hindamis- ja BYOK-mandaadid eraldi autoriseerimisklassideks.
- Siduda BYOK-i mandaadid üürniku ja teenusepakkuja konto päritoluga.
- Enne ülesvoolu mandaadi valimist nõua poliitikamootori kinnitust.
- Käitage kiire ja ohutu tervisekontroll enne tootmiskõlblikkuse saamist.
- Kasutage kahe pesa vaheldumist koos järkjärgulise liikluse nihutamise ja pakkujapoolse tühistamisega.
- Rakendage pakkujapoolseid piiranguid kõikjal, kus see on saadaval.
- Häda importimise, kasutamise, tõrgete, pööramise ja tühistamise kohta ainult lisamise auditilogid.
- Hoidke administraatori mandaadid katkestusklaasi juhtelementide taga: lühike TTL, nimega kinnitus, tugev logimine, käitusaegne kasutamine.
Tehtitav järeldus
Alustage kõigi lüüsis praegu kasutatavate ülesvoolu pakkuja mandaatide, skriptide, CI-tööde, hindamisrihmade ja partnerite automatiseerimise inventuuriga. Määrake igaühe jaoks klass, omanik, pakkuja konto piir, rentniku sidumine, lubatud lõpp-punktid, lubatud mudelipered, rotatsiooni tähtaeg ja hädaolukorra keelamise olek. Kõik, mida te ei saa klassifitseerida, tuleks keelata või karantiini panna, kuni sellel on selge eesmärk.
Seejärel jõustage üks arhitektuurireegel: allavoolu arendajad saavad lüüsi ulatusega võtmed; lüüs üksi kontrollib ülesvoolu pakkuja juurdepääsu. See eraldamine võimaldab teil säilitada kõige vähem privileege, rentniku omistamist, arvelduse täpsust, andmepoliitika marsruutimist ja turvalist automatiseerimist isegi siis, kui pakkujad, projektid, tööruumid ja BYOK-i kliendid paljunevad.