Kliendi ulatusega AI API võtmed: isoleerige üürnikud, eelarved ja kuritarvitamine ilma teenusepakkuja võtme laialivalgumiseta

Täpsed väljad varieeruvad, kuid põhimõte ei tohiks olla: iga sissetulev päring lahendab enne saatmist rentnikupoliitika võtme. Autentimine vastab "kes helistab?" Poliitikaresolutsioon vastab: "Mida võib see helistaja teha, kui palju ta võib kulutada, kuhu võib päringu suunata ja mida tuleb logida?"

Siin on oluline ka semantiline tootestrateegia. Platvorm, mis müüb AI API-t agentuuridele, võib vajada kliendi ja kampaania mõõtmeid. Arendaja tööriist võib vajada tööruumi ja hoidla mõõtmeid. Edasimüüja võib vajada väliseid kliendi ID-sid, mis vastavad tema arveldussüsteemile.

Võtme loomise töövoog

Võtme loomine peaks olema automatiseerimiseks piisavalt deterministlik ja turvalisuse ülevaatamiseks piisavalt range.

1. Loo esmalt kliendikirje

Ärge looge omanikuta võtmeid. Võti peaks enne selle olemasolu kuuluma üürnikule ja kliendikirjele. Edasimüüjate platvormide puhul peaks kliendikirje sisaldama edasimüüja CRM-i või arveldussüsteemi väliseid ID-sid, plaani metaandmeid, vajaduse korral maksude või arvete rühmitamist ja olekuvälja, mis võib peatada kõik alamvõtmed.

2. Manustage mudeliprofiil

Mudeliprofiil seostab klientidele suunatud mudelinimed pakkuja mudelite ja võimalustega. Näiteks support-standard võib lubada tasakaalustatud tekstimudelit, pildisisestust ja ilma koodi käivitamiseta. research-premium võib lubada pika kontekstiga mudeleid, veebiotsingut ja kõrgemaid taotluste piirmäärasid.

Ärge sundige allavoolu rakendusi kasutama kõvakoodi pakkuja mudeli ID-sid. Kasutage lüüsi profiili, et hallata saadavust, varu, hinnakujundust ja kasutusea lõppemist.

3. Kulutuste ja intressimäärade piirangute määramine

Kasutage koos eelarveid ja intressipiiranguid. Kuueelarve hoiab ära arvete kahjustumise aja jooksul. Intressipiirangud hoiavad ära äkilise kuritarvitamise, uuesti proovimise või juhuslike ahelate kulumise kogu eelarve minutitega.

Kasulikud juhtelemendid on järgmised:

• Kliendi kuueelarve.
• Igapäevane pehme kork kõrvalekallete tuvastamiseks.
• Võtmepäringu määr.
• Sisend- ja väljundmärgi määr.
• Taotluse maksimaalne hinnanguline kulu.
• Tööriistapõhised piirangud hostitud otsingule, failitöötlusele või koodi täitmisele.

Eelarve jõustamine peaks reserveerima hinnangulised kulud enne saatmist, arveldama tegelikud kulud pärast lõpetamist ja vabastama kasutamata reservi. See ühendab põhireeglid AI API arveldamisega, selle asemel, et käsitleda arveldust viivitatud aruandlustoiminguna.

4. Looge ja salvestage saladus õigesti

Kuva lihtteksti saladus üks kord. Toe otsimiseks salvestage ainult tugev räsi ja lühike eesliide või sõrmejälg. Eesliide aitab tugimeeskondadel tuvastada „võtme, mis lõpeb numbriga 8F2A”, ilma saladust nägemata.

Tüüpiline salvestusmuster on:

• key_id: stabiilne andmebaasi identifikaator.
• secret_hash: täieliku saladuse räsi, kasutades sobivat parooli või loa räsistrateegiat.
• secret_prefix: lühike mittetundlik kuvatava eesliide.
• sõrmejälg: deterministlik identifikaator auditi otsimiseks.
• created_by: kasutaja või Partner API klient, kes lõi võtme.
• olek: aktiivne, tühjeneb, tühistatud, karantiinis, aegunud.

Ärge kunagi salvestage ülesvoolu pakkuja võtmeid kliendi võtmeobjektile. Pakkuja mandaadid kuuluvad eraldi mandaadihoidlasse, millel on oma juurdepääsureeglid.

Taotluse aja jõustamine

Lüüs peaks käsitlema iga mudelikutset poliitikaotsusena, millele järgneb teenusepakkuja saatmine. Praktiline päringu tee näeb välja selline:

1. Parsige esitatud lüüsi võti.
2. Otsige üles võtme räsi ja olek.
3. Lahendage üürniku, kliendi, rakenduse, keskkonna, omaniku ja mudeli profiil.
4. Kontrollige, kas üürnik ja klient on aktiivsed.
5. Kinnitage taotletud mudeli pseudonüüm, moodus, tööriistad, säilitusrežiim, piirkond ja teenusetasand.
6. Prognoosige taotluse maksumust ja reservi eelarvet.
7. Kontrollige määrpiiranguid ja kuritarvitamise künniseid.
8. Valige ülesvoolu mandaadirežiim: ühendatud, rentnikuga seotud või BYOK.
9. Saada teenusepakkujale.
10. Jäädvustage kasutust, kulusid, pakkuja viiteid, vigu ja ohutussignaale.
11. Arveldage eelarve reservatsioon ja kirjutage pearaamatu lõppsündmus.

See jada jätab lüüsi kliendilepingu eest vastutavaks. Pakkujate armatuurlauad muutuvad kooskõlastussisenditeks, mitte ainsaks tõe allikaks.

Kasutage pearaamatu välju, millest hiljem on abi

Lüüsi pearaamat peaks säilitama piisavalt üksikasju, et vastata toe, arveldamise, väärkasutuse ja marsruutimise küsimustele, ilma et oleks vaja vaikimisi toores viipade salvestamist.

Kasulikud väljad on järgmised:

• request_id ja trace_id.
• üürniku_id, kliendi_id, rakenduse_id ja võtme_id.
• Lõppkasutaja identifikaator, võimalusel pseudonüüm.
• Kliendi taotletud mudeli alias.
• Lahendatud ülesvoolu pakkuja ja mudel.
• Sisend, väljund, põhjendus, vahemällu salvestatud, heli-, pildi-, video- ja tööriistakasutus, kui see on asjakohane.
• Pakutud hind, reserveeritud summa, arveldatud kulu, valuuta ja hinnakataloogi versioon.
• Pakkuja taotluse ID, kasutusaruande viide, projekt, tööruum või API võtmete rühmitamise dimensioon, kui see on saadaval.
• Rakendati säilitamiseeskirju.
• Ohutuse, kuritarvitamise või poliitikaotsuste koodid.
• Veakategooria ja proovige uuesti metaandmeid.

See struktuur toetab tagasimakseid, kliendituge, intsidentidele reageerimist ja API võtmehalduse töövoogu, mis suudab vastata küsimusele „mida see võti tegi?” ilma sõltumatuid üürnikke paljastamata.

Mandaadirežiimid: koondatud, üürnikuga seotud ja BYOK

Ühendatud pakkuja mandaadid

Vaikerežiimis läbivad paljud kliendivõtmed väiksema teenusepakkuja mandaatide komplekti. See on oma tegevuses lihtne ja vähendab pakkujapoolset laialivalgumist. See töötab siis, kui lüüsil on tugev rentnike omistamine, eelarve jõustamine, määra piiramine, väärkasutuse isoleerimine ja vahemälu piiride juhtelemendid.

Kompprorm on see, et pakkujapoolne aruandlus võib näidata ainult lüüsi mandaati või pakkuja projekti. Peate ühendama teenusepakkuja kirjed tagasi lüüsi pearaamatu kirjetega, et luua klienditasemel arveldus- ja analüütika.

Üürnikuga seotud teenusepakkuja mandaadid

Suuremate või riskantsemate üürnike puhul siduge üürnik spetsiaalse teenusepakkuja projekti, tööruumi, teenusekonto või võtmega. See tagab tugevama ülesvoolu eraldamise ja võib lihtsustada pakkujapoolset aruandlust. See võib pakkuda ka kõva kvoodi tagamise vahendit, kui pakkuja toetab sellel piiril piiranguid.

Kulu tuleneb operatsiooni keerukusest. Ettevalmistus, rotatsioon, pakkujate piirangud, intsidentidele reageerimine ja vastavusse viimine toimuvad nüüd rohkemate ülesvoolu objektide vahel.

Kaasake oma võti

BYOK võib olla kasulik, kui kliendid peavad omama teenusepakkuja kontot, pidama läbirääkimisi teenusepakkuja lepingu üle või hoidma teenusepakkuja arveldamist eraldi. Võimaluse korral rakendab lüüs endiselt mudeliprofiile, marsruutimispoliitikat, analüüsi ja rakendusetaseme juhtelemente.

Müügilahendus on toe keerukus. Iga kliendi teenusepakkuja kontol võib olla erinev juurdepääs mudelile, kvoodid, hinnakujundus, säilitamisseaded ja juhtumite olek. Lüüs peab need erinevused selgelt tuvastama ja selgitama.

Tühistamine ja karantiin

Tühistamisega peaks koheselt blokeerima uued kliendivõtme päringud ilma sõltumatuid ülesvoolu pakkuja mandaate vahetamata. See on virtuaalsete võtmete üks peamisi eeliseid.

Kasutage erinevate toimingute jaoks eraldi olekuid:

• aktiivne: päringud on lubatud.
• tühjendamine: vana võti aktsepteeritakse pöörlemisakna ajal, kuid väljastatakse hoiatusi ja auditisündmusi.
• tühistatud: uued taotlused lükatakse jäädavalt tagasi.
• karantiinis: uued taotlused blokeeritakse väärkasutuse, maksete, eeskirjade või intsidentide reageerimise tõttu.
• aegunud: võtme kasutusiga on ületatud ja see tuleb välja vahetada.

Karantiin peaks intsidendi lahendamisel olema pöörduv. Tavaliselt ei tohiks tühistamist tagasi pöörata, sest vanade saladuste taastamine suurendab segadust ja riski.

Kui võti rikub kasutuseeskirju, logige sisse põhjus, osaleja, aeg ja jõustamise ulatus. Kui otsus oli automatiseeritud, säilitage reegli versioon ja selle käivitanud signaalid. See hoiab klientide vestlused faktilistena.

Pööramine tootmist katkestamata

Võtmete pööramine peaks kasutama kahe klahviga kattuvat töövoogu:

1. Looge asendusvõti sama kliendi, rakenduse, mudeliprofiili ja piirangutega, kui operaator neid tahtlikult ei muuda.
2. Kuva uus saladus üks kord.
3. Märkige vana võti kui tühjendav.
4. Nõustuge mõlema võtmega piiratud perioodiks, näiteks 7, 14 või 30 päeva, olenevalt kliendi plaanist ja riskist.
5. Edasta tühjendusvõtmele kasutushoiatused.
6. Teavitage omanikku või Partner API klienti, kui vana võtit tähtaja lähedal veel kasutatakse.
7. Tühistage vana võti akna lõpus.
8. Säilitage omistamine mõlema võtme-ID vahel sama kliendi ja rakenduse all.

See väldib tavalist tõrkerežiimi, kus turvatäiustusest saab tootmisseisak. Rotatsioon on endiselt kontroll, kuid sellest saab tõendite ja tähtaegadega operatiivne töövoog.

Partner API pind

Kui allplatvormid haldavad kliente programmiliselt, tutvustage võtmetoiminguid Partner API kaudu. API peaks toetama idempotentsusvõtmeid ja auditisündmusi, kuna varustamine toimub sageli arveldamise, liitumise või kliendisuhete halduse töövoogudes.

Minimaalsed lõpp-punktid:

• POSTITUS /kliendid: looge või muutke klient.
• POSTITA /kliendid/{customer_id}/keys: looge võti.
• HANGI /kliendid/{customer_id}/keys: loendi võtmed ja olekud.
• PATCH /keys/{key_id}: värskendage ulatust, omanikku, piiranguid, mudeliprofiili või olekut.
• POSTITA /keys/{key_id}/rotate: loo asendus ja märkige vana võti tühjendavaks.
• POST /keys/{key_id}/revoke: tühista kohe.
• HANGI /kliendid/{customer_id}/usage: tagastage kasutus ja kulu ajavahemiku, võtme, rakenduse, mudeli või lõppkasutaja dimensiooni järgi.

Iga mutatsioonitaotlus peaks aktsepteerima idempotentsusvõtit. Iga muudatus peaks kirjutama auditisündmuse koos osaleja, sihtmärgi, enne ja pärast väljadega, allika IP või kliendi identiteedi ja võimaluse korral põhjusega.

Millal kasutada pakkuja projekte või tööruume

Ärge käsitlege lüüsi võtmeid ja pakkuja piire üksteist välistavatena. Nad lahendavad erinevaid probleeme.

Kasutage lüüsi võtmeid tavaliseks klienditasemel juhtimiseks:

• Omistamine kliendi kohta.
• Rakendusepõhised võtmed.
• Eelarve ja intressipiirangud.
• Kiire peatamine.
• Pööramise töövood.
• Kasutusanalüütika ja edasimüüjate aruandlus.

Lisage pakkuja projekte, tööruume või spetsiaalseid teenusepakkuja mandaate, kui klient vajab tugevamat eraldamist.

• Suur igakuine maht, mis väärib spetsiaalseid kvoote.
• Reguleeritud töökoormus koos selgesõnaliste elukoha- või säilitamisnõuetega.
• Lepinguline arvete eraldamine.
• Pakkujapoolne karm eelarve või kvootide tagamine.
• Spetsiaalne kuritarvitamise jälgimine või ohutusülevaatus.
• Kliendile kuuluvad teenusepakkuja kontod BYOKi kaudu.

Praktiline vaikeseade on lüüsiga jõustatud isolatsioon selektiivsete ülesvoolu kõvade piiridega. See hoiab ühise tee lihtsana, säilitades samas eskalatsioonitee klientidele, kes vajavad suuremat eraldatust.

Rakendamise kontroll-loend

• Määratlege kliendivõtme skeem rentniku, kliendi, rakenduse, keskkonna, omaniku, mudeliprofiili, piirangute, säilitamispoliitika ja olekuga.
• Räsi saladusi puhkeolekus ja kuvage lihtteksti ainult üks kord.
• Eraldage lüüsivõtmed ülesvoolu pakkuja mandaatide salvestusruumist.
• Lahendage iga päring enne saatmist poliitikasse.
• Reserveerige eelarve enne teenusepakkuja kõnesid ja arveldage pärast lõplikku kasutust.
• Kirjutage kasutust kliendi, võtme, mudeli pseudonüümi, ülesvoolu mudeli, loa kategooriate, tööriista kasutamise, noteeritud kulu, arveldatud kulu ja pakkuja viidetega.
• Rakendage aktiivsed, tühjenenud, tühistatud, karantiini pandud ja aegunud olekud.
• Toetage kahe klahvi pööramise kattumist.
• Avaldage partneri API toimingud idempotentsusvõtmetega.
• Kasutage pakkujaprojekte või tööruume ainult siis, kui nende tegevuskulud on õigustatud.

Tehtitav järeldus

Kliendi isoleerimine tehisintellekti juurdepääsu jaoks peaks tavaliselt algama lüüsi võtmest, mitte teenusepakkuja võtmest. Lüüsivõti on kliendile suunatud leping: see nimetab üürniku, kliendi, rakenduse, mudeliprofiili, eelarve, määra limiiti, säilitamisreegli ja auditipoliitika. Pakkuja võti on selle lepingu juurutamise üksikasjad.

See arhitektuur tagab SaaS-i koostajatele ja edasimüüjate platvormidele kiire tühistamise, täpse omistamise, kliendipõhise eelarve, kontrollitud rotatsiooni ja kasuliku kasutusanalüütika, ilma et iga kliendi jaoks vaikimisi tuleks luua üks ülesvoolu pakkuja projekt. Kasutage ülesvoolu projekte, tööruume, rentnikuga seotud mandaate või BYOK-i, kui risk, maht, elukoht või leping seda nõuavad. Tavalise tee jaoks jõustage klientide isoleerimine lüüsi pearaamatus ja poliitikamootoris ning seejärel kooskõlastage teenusepakkuja kirjed.

Seotud lugemine

• Klientide jaoks mõeldud võtmete API-de ja partnerite pakkumised krediiti