Upravljanje API ključem više nije mali zadatak nadzorne ploče. Za timove koji koriste AI API-je, to je dio sigurnosnog, troškovnog i operativnog modela za svaku aplikaciju koja šalje upite, prima izlaz modela, poziva alate ili troši novac na mjereno zaključivanje.

Mnogi timovi počinju s jednim ključem pružatelja u datoteci lokalnog okruženja. To funkcionira sve dok se isti ključ ne pojavi u CI varijablama, prijenosnim računalima, IDE ekstenzijama, agentima, skupnim poslovima, korisničkim integracijama i skriptama za podršku. U tom trenutku ključ koji je procurio nije samo problem autentifikacije. Može razotkriti upite i odgovore, pokrenuti neočekivane naplate, pozvati premium modele, pokrenuti alate s ovlastima aplikacije ili učiniti da odgovor na incident ovisi o nagađanju.

Ovaj vodič tretira upravljanje API ključem kao životni ciklus: kako se ključevi dizajniraju, izdaju, pohranjuju, obuhvaćaju, nadziru, rotiraju i opozivaju. Usredotočuje se na pristup AI API-ju, gdje se uobičajenim sigurnosnim problemima API-ja pridružuju pristup modelu, potrošnja na temelju tokena, vjerodajnice za više pružatelja usluga, atribucija korisnika i klijenti kompatibilni s OpenAI-jem.

Gdje se ključevi API-ja uklapaju u sigurnost API-ja

Ključ API-ja obično dokazuje posjedovanje vjerodajnice. Odgovara na pitanje "ima li ovaj pozivatelj valjanu tajnu?" On, sam po sebi, ne odgovara na svako važno pitanje autorizacije.

Pozadina još uvijek mora odlučiti može li pozivatelj pristupiti određenom zakupcu, objektu, modelu, krajnjoj točki, alatu, radnom prostoru, izvješću ili administrativnoj funkciji. Top 10 sigurnosnih rizika OWASP API-ja kao što su neispravna autorizacija na razini objekta, neispravna autentifikacija, neograničena potrošnja resursa i neispravna autorizacija na razini funkcije podsjetnici su da je valjana vjerodajnica samo jedan sloj sustava.

Za API-je umjetne inteligencije ta je razlika važna jer bi isti ključ mogao izvoditi radnje s vrlo različitim profilima rizika. Ključ koji može pozvati jeftini tekstualni model za jedan interni tijek rada ne bi trebao automatski moći pozvati premium modele, kreirati skupne poslove, pristupiti podacima drugog stanara, pozvati alate koji šalju e-poštu ili upravljati postavkama naplate.

Izdržljivi API sigurnosni model odvaja tri brige:

  • Autentikacija: dokazivanje da zahtjev ima važeću vjerodajnicu, token ili sesija.
  • Autorizacija: odlučivanje što taj autentificirani pozivatelj može učiniti u trenutnom zakupcu, okruženju i poslovnom kontekstu.
  • Upravljanje: ograničavanje potrošnje, stope, pristupa modelu, izloženosti podacima i administrativne kontrole tako da jedna pogreška ima ograničen radijus eksplozije.

API ključevi su korisni, ali ne bi trebali biti jedina kontrola koja štiti osjetljive ili visokovrijedne resurse. Koristite ih s HTTPS-om, provjerama autorizacije na strani poslužitelja, revizijskim zapisnicima, najmanjim privilegijama, ograničenjima stope, ograničenjima potrošnje i sigurnim tajnim rukovanjem.

Počnite s živim popisom API ključeva

Ne možete upravljati ključevima koje ne možete imenovati. Prvi praktični korak je inventar uživo svakog API ključa i objekta nalik vjerodajnicama koje upotrebljavaju vaši sustavi umjetne inteligencije.

Svaki zapis ključa trebao bi uključivati minimalno ID ključa, nepovratni hash ili otisak prsta, vlasnika, kreatora, tim ili stanara, okruženje, radno opterećenje, opsege, dopuštene modele, dopuštene krajnje točke, politiku potrošnje, politiku stope, IP ograničenja gdje je primjenjivo, status, vrijeme stvaranja, istek, posljednju korištenu vremensku oznaku, rotacijska grupa i metapodaci revizije.

Inventar bi trebao pokrivati više od proizvodnih ključeva vremena izvođenja. Uključite osobne ključeve razvojnog programera, ključeve servisnih računa, ključeve CI/CD, ključeve radnog prostora, ključeve korisnika ili stanara, ključeve kojima upravlja preprodavač, ključeve za naplatu/izvješćivanje, administrativne vjerodajnice API-ja i vjerodajnice uzvodnog pružatelja usluga.

Najvažnija polja su vlasništvo, svrha, opseg, zadnja upotreba i politika ograničenja. Bez njih svaki budući sigurnosni zadatak postaje sporiji: uklanjanje, rotacija, odgovor na curenje, istraživanje troškova i korisnička podrška.

Namjerno dizajnirajte granice ključeva

Najveća pogreška u upravljanju API ključem je korištenje jednog ključa preko previše granica. Zajednički proizvodni ključ je u početku zgodan, ali uništava atribuciju i čini opoziv ometajućim. Ako procuri, možda ćete morati zaustaviti promet za svaku uslugu dok još uvijek ne možete identificirati koje je opterećenje uzrokovalo problem.

Dobre ključne granice slijede oblik poslovanja i softvera. Odvojite proizvodnju od razvoja, ljude od usluga, klijente od internih timova, stanare jedne od drugih, vjerodajnice za vrijeme izvođenja od administrativnih vjerodajnica i ključeve korisnika koje je izdao pristupnik od ključeva uzvodnog pružatelja usluga.

Granice okruženja

Razvoj, prikazivanje i proizvodnja trebaju koristiti zasebne ključeve. Razvojni ključ ne bi trebao dosegnuti proizvodne podatke ili proizvodne proračune.Postupni ključ ne bi trebao imati pristup aktivnim radnim opterećenjima korisnika osim ako ne postoji strogo kontrolirani razlog.

Granice radnog opterećenja

Svaka usluga, skupni posao, flota agenta, integracija ili zakazani zadatak trebaju imati vlastiti ključ ili račun usluge. To vam omogućuje da odgovorite na osnovna pitanja: koje je radno opterećenje potrošilo novac, koja je usluga počela neuspješno provjera autentičnosti, koja je integracija koristila zastarjeli model i koji ključ treba zamrznuti tijekom incidenta.

Granice zakupca i korisnika

Sustavi s više zakupaca trebaju atribuciju i izolaciju. Ako se API ključ usmjeren prema korisniku koristi za slanje upita, zahtjev bi trebao biti vezan za kupca, stanara, aplikaciju i idealno pseudonimnog krajnjeg korisnika ili aktera. Ugroženi ključ za jednog zakupca ne bi trebao dopustiti pristup podacima, profilu modela, proračunu ili zapisima drugog zakupca.

Granice vjerodajnica davatelja

Ključevi uzlaznog davatelja razlikuju se od ključeva koje izdajete klijentima ili internim aplikacijama. Vjerodajnice davatelja trebaju ostati na strani poslužitelja, pohranjene u trezoru ili tajnom upravitelju i nikada se ne šalju preglednicima, mobilnim aplikacijama, klijentima stolnih računala, javnim prijenosnim računalima ili okruženjima koja kontroliraju korisnici.

Gateway može pomoći ovdje otkrivanjem jedne površine ključa koja je okrenuta prema korisniku dok zadržava vjerodajnice davatelja uzlaznih usluga iza pristupnika. To omogućuje centraliziranje analitike korištenja, opoziva, timskih kontrola i provedbe pravila među pružateljima usluga. Ako standardizirate klijente oko API-ja kompatibilnog s OpenAI-jem, granica pristupnika postaje osobito važna jer mnogi alati očekuju jedan osnovni URL i token nositelja.

Primijenite najmanje povlastice na modele, krajnje točke, alate i potrošite

Najmanje povlastice znači da bi ključ trebao imati samo pristup potreban za svoje radno opterećenje. Za AI sustave opseg nije samo popis krajnjih točaka API-ja. Također uključuje modele, alate, proračune tokena, ograničenja stope, zakupce, klase podataka i administrativne funkcije.

Praktična politika AI API ključa može uključivati:

  • Dopuštene obitelji modela ili određene ID-ove modela.
  • Dopuštene krajnje točke, kao što su dovršeci chata, ugrađivanja, skupni poslovi ili generiranje slika.
  • Nedopušteni administrativni API-ji, API-ji za upravljanje ključevima, API-ji za naplatu i API-ji za upravljanje radnim prostorom za ključeve vremena izvođenja.
  • Ograničenja stope po ključu za zahtjeve po minuti i tokene po minuti.
  • Ograničenja potrošnje po stanaru, timu ili korisniku.
  • Premium model kontrolira tako da niskorizični tijek rada ne može iznenada koristiti najskuplji model.
  • Dozvole alata, kao što je može li ključ pozvati vanjski konektori, izvršavanje koda, sustavi za dohvaćanje ili poslovne radnje.
  • IP dopušteni popisi za stabilna radna opterećenja na strani poslužitelja, gdje je mrežni put predvidljiv.

Kontrola potrošnje dio je sigurnosti API-ja za mjerljive AI API-je. Ključ koji je procurio može stvoriti izravnu financijsku štetu čak i ako nikada ne pristupi osjetljivim podacima. Ograničenja brzine pomažu, ali nisu dovoljna. Količina tokena, ponovni pokušaji, skupni poslovi, pozivi alata i odabir modela utječu na cijenu. Sigurna implementacija trebala bi kombinirati kontrole stope s gornjim granicama potrošnje, popisima dopuštenih modela, otkrivanjem anomalija i kontrolama hitnog zamrzavanja.

Timovi koji uspoređuju troškove modela i politike pristupa trebali bi uskladiti sigurnost i financije. Model određivanja cijena nije samo pitanje nabave; određuje koliko kompromitirani ili pogrešno konfigurirani ključ može potrošiti. Držite odobrene profile modela vezane uz proračune i pregledajte ih kada se vaša kombinacija modela promijeni, posebno kada koristite cijene AI modela za usmjeravanje radnih opterećenja prema cijeni i mogućnostima.

Pohranite tajne tamo gdje im je mjesto

API ključevi pripadaju tajnim upraviteljima, konfiguraciji na strani poslužitelja, kontroliranim CI/CD varijablama ili pristupniku koji podržava trezor. Ne pripadaju izvornom kodu, JavaScriptu preglednika, mobilnim paketima, paketima aplikacija za stolna računala, javnim bilježnicama, snimkama zaslona, ​​porukama chata, korisnim sadržajima analitike, prijavama za podršku ili zapisnicima.

Izloženost na strani klijenta uobičajeni je način kvara. Ako je ključ pružatelja ugrađen u preglednik ili mobilnu aplikaciju, svatko tko može pregledati aplikaciju može ga izdvojiti i postavljati zahtjeve u ime vlasnika računa. Za preglednike, mobilne aplikacije, IDE flote i agente koji rade u nekontroliranim okruženjima, koristite proxy na strani poslužitelja ili kratkotrajne delegirane vjerodajnice s uskim opsegom. Ne distribuirajte dugotrajne vjerodajnice pružatelja usluga klijentima koje ne možete kontrolirati.

CI/CD treba istu disciplinu. Pohranite ključeve kao zaštićene varijable. Ograničite tko ih može čitati ili mijenjati. Izbjegavajte ispisivanje varijabli okruženja u zapisnicima izgradnje. Uredi zaglavlja autorizacije u ispisima neuspjelih zahtjeva. Tretirajte implementacije pregleda i račvaste zahtjeve za povlačenjem kao različite zone povjerenja od zaštićenih proizvodnih cjevovoda.

Dnevnici i sustavi za promatranje zaslužuju posebnu pozornost.Pohranite otiske ključeva, ID-ove zahtjeva, ID-ove stanara, ID-ove modela, status odgovora, brojače tokena, brojače troškova, IP ili metapodatke klijenta gdje je to prikladno i odluke o politici. Nemojte pohranjivati ​​pune API ključeve. Uređivanje tajni u tragovima, obrnuti proxy zapisnici, izvješća o iznimkama, učinci web-dojavnika, alati za podršku, analitički događaji i redovi mrtvih pisama.

Izgradnja rotacije prije hitnog slučaja

Rotacija nije jednostavno brisanje jednog ključa i stvaranje drugog. Ako implementirane usluge i dalje ovise o starom ključu, brisanje uzrokuje prekid rada. Pouzdan proces rotacije koristi preklapanje, promatranje i jasnu točku povlačenja.

Uobičajeni obrazac je grupa rotacije s dva aktivna mjesta. Stvorite zamjenski ključ, implementirajte ga na svaki ovisni sustav, promatrajte posljednju upotrebu starog ključa, zamrznite stari ključ kada se promet pomakne i izbrišite ga nakon prozora pouzdanosti. Neka pravila vraćanja budu eksplicitna: kada se stari ključ može ponovno omogućiti, tko to može odobriti i koliko dugo može ostati dostupan?

Kratak životni vijek ključa smanjuje rizik od zastarjelih vjerodajnica, ali povećava operativni teret. Dugotrajni ključevi smanjuju odljev implementacije, ali stvaraju veći prozor za zaboravljene vjerodajnice i nedostatke zaposlenika. Prava politika ovisi o radnom opterećenju. Račun proizvodne usluge visoke vrijednosti može se rotirati prema fiksnom rasporedu s automatizacijom. Privremeni ključ razvojnog programera trebao bi brzo isteći. Za integraciju kojom upravlja korisnik možda će trebati duži vremenski okvir migracije i jasna poruka o obustavi.

Nemojte rotirati svaki ključ na isti način. Administrativne vjerodajnice koje mogu ispisivati, stvarati, brisati ili mijenjati ključeve su rizičnije od ključeva za zaključivanje vremena izvođenja i trebale bi imati jače kontrole, uži pristup i agresivniji nadzor. Ključevi za vrijeme izvođenja ne bi trebali imati administrativnu ovlast osim ako ne postoji poseban, pregledan razlog.

Otkrij curenje i neuobičajenu upotrebu

Otkrivanje curenja najbolje funkcionira kada se nekoliko sustava međusobno pojačava. Tajno skeniranje kontrole izvora može uhvatiti ključeve predane repozitoriju. CI provjere mogu blokirati očita curenja prije spajanja. Prilagođeni obrasci mogu otkriti unutarnje formate ključeva. Nadzorne ploče pružatelja usluga mogu otkriti neobičnu aktivnost. Telemetrija pristupnika može pokazati nove IP adrese, nove geografske lokacije, neuspjele autentifikacijske napade, iznenadnu brzinu potrošnje ili pozive neočekivanim modelima.

Korisne sigurnosne nadzorne ploče uključuju neaktivne ključeve, ključeve bez vlasnika, ključeve bez ograničenja, ključeve koji se bliže isteku, ključeve koji se koriste s novih mreža, ključeve s brzim rastom tokena, zamrznute ključeve koji još uvijek primaju promet, neuspjelu autentifikaciju praska i korisničke ključeve koji se približavaju gornjim granicama potrošnje.

Otkrivanje bi također trebalo pokriti zapisnike i asinkrone sustave. Web-dojavnici, pozadinski poslovi, redovi čekanja i odgođeni završeci zahtijevaju ID-ove zahtjeva i izvornu atribuciju ključa. U suprotnom, sumnjiv povratni poziv ili skupni rezultat možda neće biti moguće povezati s ključem i zakupcem koji ga je stvorio.

Kada se tajna pojavi u Git povijesti, nije dovoljno ukloniti je iz repozitorija. Svatko tko je pristupio repozitoriju, zapisnicima izgradnje, zrcalima, račvama, paketnim artefaktima ili predmemoriranim stranicama možda je već kopirao ključ. Vjerodajnica se mora poništiti ili zamrznuti, a zatim zamijeniti.

Odgovaranje na ugroženi API ključ

Dobar plan odgovora na incident je kratak, uvježban i specifičan. Prva odluka obično je hoće li se zamrznuti ili opozvati. Zamrzavanje brzo zaustavlja promet dok čuva zapis za istragu. Opoziv trajno onesposobljava ključ. Neki timovi prvo koriste zamrzavanje kada im je potreban kontinuitet revizije i trenutne mogućnosti vraćanja; drugi se automatski opozivaju za potvrđeno javno curenje informacija. Oba pristupa zahtijevaju automatizaciju i jasne ovlasti.

Praktični tijek odgovora izgleda ovako:

  1. Zamrznite ili opozovite sumnjivi ključ na temelju ozbiljnosti i pouzdanosti.
  2. Identificirajte vlasnika, stanara, radno opterećenje, opsege, pristup modelu, politiku potrošnje i posljednju korištenu vremensku traku.
  3. Pregledajte upotrebu neobičnih upita, modela, krajnjih točaka, alata, IP-ova, volumen tokena i trošak.
  4. Procijenite zahvaćene podatke, zakupce, nizvodne radnje i utjecaj naplate.
  5. Izdajte zamjenski ključ s ispravljenim opsegom i ograničenjima.
  6. Uklonite glavni uzrok, kao što je predana tajna, izloženi dnevnik, preširoka CI varijabla ili paket na strani klijenta.
  7. Dodajte kontrolu prevencije, kao što je tajno skeniranje, redigiranje dnevnika, uži opseg, kraći rok trajanja ili upozorenja o potrošnji.
  8. Dokumentirajte incident i ažurirajte runbooks.

Korak zamjene ne bi trebao ponovno stvoriti isti rizik. Ako je ključ procurio jer je podijeljen na deset usluga, zamijenite ga zasebnim ključevima računa usluge. Ako je procurilo kroz zapise, popravite zapis prije izdavanja novog ključa. Ako je potrošio prekomjerno jer je mogao pozvati svaki model, dodajte popise dopuštenih modela i ograničenja potrošnje.

Ključevi kojima upravlja pristupnik i AI pristup s više pružatelja

Timovi za umjetnu inteligenciju često koriste nekoliko pružatelja modela.Svaki pružatelj usluga ima svoj model ključa, strukturu radnog prostora, ograničenja stope, nazive modela, cijene i administrativne API-je. Upravljanje svakim ključem pružatelja izravno u svakoj aplikaciji višestruko povećava operativni rizik.

Model ključa kojim upravlja pristupnik može smanjiti tu složenost. Aplikacije pozivaju gateway pomoću ključa okrenutog prema korisniku ili internog ključa. Pristupnik provjerava autentičnost pozivatelja, primjenjuje politiku zakupca, provodi model i kontrolu potrošnje, bilježi korištenje i koristi vjerodajnice uzlaznog davatelja na strani poslužitelja. Ovo je korisno za aplikacije s više modela, interne platforme, agencije i usluge preprodavača.

Za Model Gate, ovdje je relevantna uloga pristupnika: centralizirani ključevi okrenuti prema korisnicima, objedinjena analitika upotrebe, timske kontrole, ograničenja potrošnje, IP sigurnost, operativne integracije Telegrama, automatizacija Partner API-ja i odgovor na zlouporabu. Za tvrtke koje pružaju klijentima ili nizvodne usluge, Automatizacija API-ja za partnere može učiniti stvaranje ključa, ograničenje ažuriranja, zamrzavanje i tijekove rada preprodavača dosljednima umjesto ručnim.

Gateway ne uklanja svaku odgovornost s aplikacijskog tima. I dalje vam je potrebna sigurna pohrana, pozadinska autorizacija, izolacija stanara, dizajn krajnje točke, CI/CD higijena, politika podataka o brzim i odgovornim podacima i ograničenja na strani pružatelja usluga gdje su dostupna. Gateway postaje visokovrijedna kontrolna ravnina, pa mu je potrebno snažno trezorovanje, revizijski zapisnici, kontrole pristupa, planiranje dostupnosti i administrativno odvajanje.

Uobičajene pogreške u upravljanju ključevima API-ja

Najčešće pogreške su predvidljive. Timovi stavljaju ključeve pružatelja usluga izravno u klijentske aplikacije. Koriste jedan proizvodni ključ za svaku uslugu i kupca. Rotiraju se tako da se prvo brišu, a kasnije postavljaju. Oni stvaraju ključeve bez vlasnika, ograničenja, opsega ili isteka. Zapisuju puna zaglavlja autorizacije. Za kontrolu troškova umjetne inteligencije oslanjaju se samo na ograničenja stopa. Oni daju vjerodajnice administratora runtime usluga. Oni uklanjaju ključ koji je procurio iz Gita bez njegovog opoziva. Oni isključuju zaposlenike, ali ostavljaju osobne ključeve, datoteke lokalnog okruženja i CI varijable aktivnima.

Još jedna suptilna pogreška je tretiranje zapisivanja brzih i odgovora kao čisto operativnih. Detaljni zapisnici mogu pomoći u istraživanju zlouporabe, ali također mogu sadržavati osobne podatke, sadržaj korisnika, tajne ili regulirane informacije. Bilježenje metapodataka često je sigurnije: zabilježite otiske ključeva, ID-ove modela, brojeve tokena, troškove, statusne kodove, odluke o politici i ID-ove zahtjeva prema zadanim postavkama, a zatim zahtijevate kontrolirani pristup za dublje podatke o otklanjanju pogrešaka.

Kontrolni popis za implementaciju

Snažan API program za upravljanje ključevima može započeti s fokusiranim kontrolnim popisom:

  • Stvorite inventar svih ključeva, vlasnika, okruženja, zakupci, opseg, ograničenja i vremenske oznake posljednje upotrebe.
  • Razdvojite ključeve po okruženju, radnom opterećenju, zakupcu, korisniku i klasi vjerodajnica.
  • Premjestite vjerodajnice pružatelja na stranu poslužitelja i izvan preglednika, mobilnih aplikacija, prijenosnih računala i javnih klijenata.
  • Koristite najmanje privilegije za modele, krajnje točke, alate, zakupce, proračune i administrativne funkcije.
  • Dodajte ograničenja potrošnje, ograničenja stope, popise dopuštenih modela, upozorenja o anomalijama i kontrole za hitno zamrzavanje.
  • Pohranite tajne u upravitelj tajnima, trezor, zaštićenu pohranu CI varijabli ili sustav vjerodajnica kojim upravlja pristupnik.
  • Uredite tajne iz zapisa, praćenja, analitike, alata za podršku, webdojavnika i pogreške izvješća.
  • Implementirajte rotaciju s ključevima koji se preklapaju, praćenje zadnje upotrebe, zamrzavanje i konačno brisanje.
  • Integrirajte tajno skeniranje u repozitorije i CI/CD, uključujući prilagođene uzorke ključeva.
  • Dokumentirajte ponašanje izvan broda za osobne ključeve, račune usluga, ključeve radnog prostora i korisničke ključeve.
  • Držite vjerodajnice za zaključivanje vremena odvojene od administrativnog pružatelja usluga vjerodajnice.
  • Testirajte reakciju na incident prije nego što stvarno curenje pokrene proces.

Zaključak

Upravljanje ključem API-ja za API-je umjetne inteligencije odnosi se na kontrolu identiteta, ovlaštenja, troškova i operativnog radijusa eksplozije. Sigurni ključ nije samo nasumični niz. Ima vlasnika, svrhu, opseg, okruženje, proračun, istek, putanju rotacije, revizijski trag i plan odgovora na incident.

Praktični cilj nije stvoriti birokraciju oko svakog zahtjeva. To je učiniti normalan rad sigurnijim: razvojni programeri mogu graditi, usluge se mogu izvoditi, kupcima se mogu omogućiti, a sigurnosni timovi mogu odgovoriti što se dogodilo kada ključ procuri ili poraste potrošnja. Počnite s inventarom i granicama, zatim dodajte najmanje privilegije, sigurnu pohranu, rotaciju, nadzor i automatizaciju odgovora. Za AI pristup više pružatelja, pristupnik može centralizirati velik dio te kontrole, ali autorizacija aplikacija i tajna higijena i dalje ostaju glavne inženjerske odgovornosti.