API upravljanje 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 usluga 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č API upravljanje ključevima tretira kao životni ciklus: kako su ključevi dizajnirani, izdani, pohranjeni, opsegom, nadzirani, rotirani i opozvani. Usredotočen je na AI API pristup, gdje se uobičajenim API sigurnosnim problemima pridružuje pristup modelu, potrošnja na temelju tokena, vjerodajnice za više pružatelja usluga, atribucija korisnika i OpenAI-kompatibilni klijenti.

Gdje API ključevi odgovaraju API sigurnosti

API ključ obično dokazuje posjedovanje vjerodajnica. Odgovara na pitanje "ima li ovaj pozivatelj valjanu tajnu?" 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. OWASP API Sigurnost Top 10 rizika 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 AI API-je 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.

Trajni API sigurnosni model odvaja tri problema:

  • Autentifikacija: dokazivanje zahtjev ima valjanu vjerodajnicu, token ili sesiju.
  • Authorization: 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čenu eksploziju radijus.

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

Počnite s aktivnim API popisom 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 koriste vaši AI sustavi.

Svaki zapis ključa trebao bi uključivati minimalno ID ključa, nepovratni hash ili otisak prsta, vlasnika, kreatora, tim ili zakupca, 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, posljednja korištena vremenska oznaka, grupa rotacije 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 naplate/izvješćivanja, administrativne API vjerodajnice i vjerodajnice uzvodnog pružatelja.

Najvažnija polja su vlasništvo, svrha, opseg, posljednja 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 API pogreška u upravljanju ključevima 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 radno 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.

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 agenata, 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 ne uspjeti s autentifikacijom, 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 za slanje upita koristi tipka okrenuta prema korisniku API, zahtjev bi trebao biti povezan s korisnikom, zakupcem, aplikacijom i idealno pseudonimnim krajnjim korisnikom ili akterom. Ugroženi ključ za jednog zakupca ne bi trebao dopustiti pristup podacima, profilu modela, proračunu ili zapisima drugog zakupca.

Granice vjerodajnica pružatelja

Ključevi pružatelja uzlaznih usluga 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.

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

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

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

Praktična AI API ključna politika 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, ugradnje, skupni poslovi ili slika generacija.
  • 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.
  • Potrošnja po stanaru, po timu ili po korisniku ograničenja.
  • Premium model kontrolira tako da tijek rada s niskim rizikom ne može iznenada koristiti najskuplji model.
  • Dozvole alata, kao što je može li ključ pozivati vanjske konektore, izvršavanje koda, sustave za dohvaćanje ili poslovne radnje.
  • IP liste dopuštenih za stabilna radna opterećenja na strani poslužitelja, gdje je mrežni put predvidljiv.

Kontrola potrošnje dio je API sigurnosti za mjerne 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 stopa 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 pripadaju

API ključevi pripadaju tajnim upraviteljima, konfiguraciji na strani poslužitelja, kontroliranim CI/CD varijablama ili pristupniku koji podržava trezor. Oni ne pripadaju izvornom kodu, pregledniku JavaScript, paketima mobilnih uređaja, paketima aplikacija za stolna računala, javnim bilježnicama, snimkama zaslona, ​​porukama chata, korisnim sadržajima analitike, prijavama za podršku ili zapisima.

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. Nemojte distribuirati dugovječne 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 okoline u zapisnicima izgradnje. Redigirajte zaglavlja Authorization 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.

Zapisnici i sustavi promatranja 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 zapisnici proxyja, 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 obustavljanju.

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 određeni, pregledani razlog.

Otkrivanje curenja i neuobičajene upotrebe

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 mogu otkriti neobičnu aktivnost. Telemetrija pristupnika može pokazati nove IP adrese, nove geografske lokacije, neuspjele provjere autentičnosti, iznenadnu brzinu potrošnje ili pozive neočekivanim modelima.

Korisne sigurnosne nadzorne ploče uključuju ključeve u mirovanju, 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, neuspjele rafalne provjere autentičnosti i korisničke ključeve koji se približavaju gornjoj granici 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. Inače, 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 kompromitirani API ključ

Dobar plan odgovora na incident je kratak, uvježban i konkretan. 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 tok 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 upotrebu vremenska traka.
  3. Pregledajte korištenje neuobičajenih upita, modela, krajnjih točaka, alata, IP-ova, volumena tokena i cijene.
  4. Procijenite pogođene podatke, stanare, 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 istek ili upozorenja o potrošnji.
  8. Dokumentirajte incident i ažurirajte runbookove.

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 AI č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, Telegram operativne integracije, Partner API automatizacija i odgovor na zlouporabu. Za tvrtke koje pružaju klijentima ili nizvodne usluge, Partner API automatizacija 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 kontrolna ravnina visoke vrijednosti, pa su mu potrebni jaki trezori, revizijski zapisnici, kontrole pristupa, planiranje dostupnosti i administrativno odvajanje.

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

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 Authorization zaglavlja. Za kontrolu troškova umjetne inteligencije oslanjaju se samo na ograničenja stopa. Oni daju vjerodajnice administratora runtime uslugama. Oni uklanjaju ključ koji je procurio iz Gita bez njegovog opoziva. Oni isključuju zaposlenike, ali ostavljaju osobne ključeve, lokalne datoteke okruženja i CI varijable aktivnima.

Još jedna suptilna pogreška je tretiranje zapisnika 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.Zapisivanje 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 popis svih ključeva, vlasnika, okruženja, zakupaca, opsega, ograničenja i vremenskih oznaka posljednje upotrebe.
  • Odvojite 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 povlastica 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 zamrzavanja u hitnim slučajevima.
  • Pohranjujte tajne u tajnom upravitelju, trezoru, zaštićenoj spremištu CI varijabli ili vjerodajnicama kojima upravlja pristupnik sustav.
  • Uredite tajne iz zapisa, tragova, analitike, alata za podršku, webdojavljivača i izvješća o pogreškama.
  • 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đeni ključ obrasci.
  • Dokumentirajte ponašanje izvan broda za osobne ključeve, račune usluga, ključeve radnog prostora i korisničke ključeve.
  • Držite vjerodajnice zaključka o vremenu izvođenja odvojene od vjerodajnica administrativnog pružatelja usluga.
  • Testirajte odgovor na incident prije nego što stvarno curenje prisili proces.

Zaključak

API upravljanje ključem za AI API-je odnosi se na kontrolu identiteta, ovlaštenja, cijene 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 stvaranje birokracije 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.