Hacker News

„Google“ API raktai nebuvo paslaptys, bet tada Dvyniai pakeitė taisykles

Komentarai

13 min read Via trufflesecurity.com

Mewayz Team

Editorial Team

Hacker News

Kai „Public by Design“ tampa saugumo įsipareigojimu

Beveik du dešimtmečius „Google“ ekosistema besiremiantys kūrėjai išmoko subtilią, bet svarbią pamoką: „Google“ API raktai iš tikrųjų nėra paslaptys. Jei „YouTube“ duomenų API raktą įdėjote į „JavaScript“ failą, „Google“ nesukėlė nerimo. Jei jūsų Žemėlapių API raktas buvo rodomas viešojoje „GitHub“ saugykloje, saugumo atsakas iš esmės buvo gūžtelėjimas pečiais ir priminimas nustatyti domeno apribojimus. Visas modelis buvo sukurtas remiantis prielaida, kad šie raktai veiks kliento kode ir bus rodomi visiems, kurie atidarė DevTools.

Ši filosofija buvo prasminga ilgą laiką. Žemėlapių API raktas, atskleistas be domeno apribojimų, gali sukaupti netikėtą sąskaitą, tačiau tai nepakenks pacientų įrašams ar išeikvotų banko sąskaitą. Sprogimo spindulys buvo finansinis ir valdomas. „Google“ įrankiai – persiuntimo apribojimai, IP įtraukimas į baltąjį sąrašą, kvotų ribos – buvo sukurti taip, kad apsaugotų nuo žalos, o ne visiškai apsaugotų nuo poveikio.

Tada atvyko Dvyniai, o taisyklės pasikeitė. Problema ta, kad milijonai kūrėjų negavo atmintinės.

Senas psichikos modelis, dėl kurio kūrėjai dabar degina

Senoji „Google“ kūrėjo patirtis buvo sąmoningai leistina. Kai sukūrėte Žemėlapių JavaScript API raktą, dokumentacija praktiškai paskatino jį įdėti tiesiai į HTML. Saugumo modelis nebuvo slaptumas – tai buvo apribojimas. Užrakintumėte domeno raktą, nustatytumėte kvotos įspėjimus ir judėtumėte toliau. Tai buvo pragmatiška inžinerija: kliento pusės programos iš tikrųjų negali saugoti paslapčių nuo ryžtingų vartotojų, todėl „Google“ sukūrė sistemą, kuri pripažino šią realybę.

Taip buvo sukurta kūrėjų karta – o dar svarbiau – institucinių įpročių karta, kai „Google“ API raktai užėmė kitą kategoriją nei, tarkime, „Stripe“ slaptasis raktas ar AWS prieigos kredencialas. Neįklijuotumėte savo „Stripe“ slaptojo rakto į viešą atpirkimo sandorį. Bet jūsų žemėlapių raktas? Tai buvo praktiškai konfigūracijos vertė, o ne paslaptis. Daugelis komandų saugojo juos viešuose konfigūracijos failuose, README failuose, net ir kliento aplinkos kintamuosiuose su priešdėliu NEXT_PUBLIC_ arba REACT_APP_, nieko negalvodami.

Saugos tyrėjai, nuskaitę „GitHub“, ieškodami atskleistų kredencialų, taip pat išmoko kitaip elgtis su „Google“ API raktais. Nutekėjęs Žemėlapių raktas buvo nedidelio sunkumo radinys. Nutekėjęs Dvynių raktas yra visiškai kitoks pokalbis.

Kas pasikeitė su Dvyniais – ir kodėl tai svarbu

„Google“ „Gemini“ API nesilaiko senojo vadovo. Kai generuojate Gemini API raktą naudodami „Google AI Studio“, sukuriate kredencialą, kurio rizikos profilis iš esmės skiriasi nuo Žemėlapių ar „YouTube“ rakto. Dvynių raktai autentifikuoja prieigą prie didelės kalbos modelio išvados – paslaugos, kuri kainuoja „Google“ realius skaičiavimo išteklius ir kuri apmokestinama pagal prieigos raktą, o ne pagal puslapio peržiūrą.

Dar svarbiau, kad „Gemini“ API raktai neturi tų pačių įtaisytųjų domeno apribojimo mechanizmų, dėl kurių buvo galima atpažinti kitus „Google“ raktus. Nėra paprasto „užrakinti tai mano svetainės domene“ valdymo, kuris neleistų užpuolikui, radusiam jūsų raktą viešojoje saugykloje, sukurti savo programą ir sunaudoti jūsų kvotą (arba atsiskaitymo limitą) iš serverio kitoje šalyje.

Pavojus yra ne tik finansinis. Atidengtas Dvynių raktas gali būti naudojamas žalingam turiniui generuoti, skubioms injekcijos atakoms arba įrankiams, pažeidžiantiems „Google“ paslaugų teikimo sąlygas, kurti – visa tai apmokestinama jūsų paskyra ir atsekama iki jūsų tapatybės.

2024 m. saugumo tyrinėtojai vien tik GitHub tinkle aptiko tūkstančius atskleistų Gemini API raktų, daugelis jų buvo saugyklose, kuriose anksčiau be incidentų buvo priglobti kiti Google API raktai. Kūrėjai nebuvo neapgalvoti pagal savo istorinius standartus – jie taikė mentalinį modelį, kurį „Google“ išmokė naudoti pati. Aplinka keitėsi greičiau nei įpročiai.

Atsitiktinio poveikio anatomija

Supratimas, kaip įvyksta toks poveikis, yra pirmas žingsnis siekiant jų išvengti. Gedimų režimai yra nepaprastai vienodi visų dydžių komandose:

  • Klaidingas aplinkos kintamojo klasifikavimas: kūrėjai įpratę prie „Google“ žemėlapių raktų „Gemini“ raktų priešdėl NEXT_PUBLIC_ arba VITE_, iš karto pateikdami juos kartu su kliento kodu.
  • Saugyklos istorijos užteršimas: raktas pridedamas prie konfigūracijos failo, patvirtinamas, tada pašalinamas, tačiau „git“ istorijoje galima ieškoti neribotą laiką. Užpuolikai naudoja tokius įrankius kaip truffleHog ir gitleaks, kad gautų šią istoriją.
  • Nešiojamųjų kompiuterių ir prototipų nutekėjimas: duomenų mokslininkai, prototipuojantys Gemini integracijas Jupyter nešiojamuosiuose kompiuteriuose, perkelia tuos bloknotus į GitHub su raktais, įterptais į ląstelių išvestis.
  • Klaidinga CI / CD konfigūracija: raktai, saugomi kaip saugyklos paslaptys, netyčia atsiliepia kūrimo žurnaluose, kurie viešai matomi „GitHub Actions“ ar panašiose platformose.
  • Trečiųjų šalių paslaugų plėtra: kūrėjai įklijuoja raktus į analizės informacijos suvestines, be kodo įrankius arba integravimo platformas, neperžiūrėdami tų platformų saugos pozicijų.
  • Komandos komunikacijos kanalai: „Slack“, „Discord“ ar el. paštu bendrinami raktai patenka į pranešimų istorijas, kuriose galima ieškoti, ir kurios išgyvena rotacijos tvarkaraštį.

Bendra tema yra ne aplaidumas, o konteksto žlugimas. Elgesys, kuris buvo saugus viename kontekste („Google“ žemėlapių kūrimas), yra pavojingas kitame („Gemini“ kūrimas), o vizualinis kredencialų panašumas leidžia lengvai nepastebėti skirtumo.

Paslapčių valdymo kultūros kūrimas, kurios mastelis

Dvynių padėtis yra naudinga priverstinė funkcija, kurią daugelis kūrėjų komandų atideda: sukurti tikrą paslapčių valdymo infrastruktūrą, o ne ad hoc metodus. Mažoms komandoms tai gali atrodyti kaip perdėta inžinerija, tačiau kredencialų atskleidimo – apgaulės atsiskaitymo, paskyros sustabdymo, pranešimų apie duomenų pažeidimus – kaina gerokai viršija pastangas tai padaryti teisingai.

Šiuolaikinis paslapčių valdymas yra pakopinis. Infrastruktūros lygmeniu tokie įrankiai kaip „HashiCorp Vault“, „AWS Secrets Manager“ arba „Google Secret Manager“ suteikia centralizuotą, tikrinamą kredencialų saugyklą su automatinio sukimosi galimybėmis. Tai ne tik didelėms įmonėms – tokios paslaugos kaip Doppler ir Infisical suteikia tuos pačius modelius dviejų ar trijų kūrėjų komandoms prieinamomis kainomis.

💡 DID YOU KNOW?

Mewayz replaces 8+ business tools in one platform

CRM · Invoicing · HR · Projects · Booking · eCommerce · POS · Analytics. Free forever plan available.

Start Free →

Kodo lygmeniu disciplina paprastesnė: kredencialai niekada neliečia šaltinio kodo. Visiškas sustojimas. Ne komentuojamose eilutėse, ne pavyzdiniuose failuose, ne bandomuosiuose įrenginiuose su netikromis reikšmėmis, kurios pasirodo tikros. Iš anksto patvirtinti kabliukai, kuriuose veikia tokie įrankiai kaip detect-secrets arba gitleaks, užfiksuoja pažeidimus dar nepasiekdami nuotolinių saugyklų. Šių kabliukų konfigūravimas užtrunka keletą minučių, o jūsų nerimastingumas dėl incidentų trunka kelerius metus.

Organizcijoms, kurios valdo sudėtingas operacines sistemas – valdo viską nuo CRM darbo eigos iki darbo užmokesčio integravimo iki klientų užsakymo sistemų – centralizuotas kredencialų valdymas tampa dar svarbesnis. Tokios platformos kaip Mewayz, sujungiančios 207 verslo modulius į vieną veiklos skėtį, yra sukurtos remiantis šiuo principu: kredencialai ir API integracijos valdomos platformos lygiu, o ne išsklaidytos atskiruose moduliuose ar atskirose kūrėjų aplinkose. Kai raktą reikia pasukti, tai įvyksta vieną kartą, vienoje vietoje, o ne septyniolikoje skirtingų integravimo taškų.

Atsiskaitymo atakos vektorius: grėsmės modelio kūrėjai neįvertina

Diskusijose dėl saugumo dažnai daugiausia dėmesio skiriama duomenų pažeidimams ir neteisėtai prieigai. Dvynių poveikio problema prideda trečią grėsmės modelį, kuris nusipelno tiek pat dėmesio: didelio masto sąskaitų apgaulė.

Didelės kalbos modelio išvada yra brangi. GPT-4 ir Gemini Ultra apdoroja žetonus po cento dalis, bet mastu – tūkstančiai užklausų, milijonai žetonų – šios frakcijos labai greitai prideda tūkstančius dolerių. Užpuolikai, aptikę atvirus AI API raktus, nebūtinai nori jūsų duomenų. Jie nori nemokamo skaičiavimo. Jie naudos jūsų kredencialus, kad galėtų vykdyti savo AI paslaugas, perparduoti išvadų pajėgumus arba išbandyti savo programas nepalankiausiomis sąlygomis – visa tai, kol sąskaita gausite jums.

Vienas kūrėjas dokumentavo, kad pabudo nuo 23 000 USD sąskaitos iš „Gemini“ rakto, kuris viešoje saugykloje buvo eksponuojamas mažiau nei šešias valandas. Užpuolikas nedelsdamas automatizavo išnaudojimą ir nuolat vykdė didelio našumo generavimo užduotis, kol „Google“ sukčiavimo aptikimas jį užfiksavo. Po ilgo ginčo proceso kūrėjas galiausiai atšaukė mokesčius, tačiau paskyra per tą laikotarpį buvo sustabdyta, todėl su ja buvo panaikintos gamybos paslaugos.

Štai kodėl atsiskaitymo įspėjimai ir kvotų apribojimai nepakeičia tinkamo paslapčių valdymo – tai paskutinė gynybos linija, kurios, tikiuosi, jums niekada neprireiks. Griežtų mėnesinių išlaidų limitų AI API paskyroms nustatymas dabar yra stalo statymas, tačiau tikroji apsauga yra užtikrinti, kad tie kredencialai niekada nenutekėtų.

Praktiniai žingsniai pereinančioms komandoms

Jei jūsų komanda kūrė „Google“ API integracijas pagal seną mąstymo modelį ir dabar į steką prideda „Gemini“, čia pateikiamas realus ištaisymo kontrolinis sąrašas:

  1. Nedelsdami patikrinkite esamas saugyklas. Vykdykite truffleHog arba gitleaks su visa „git“ istorija, o ne tik su dabartine HEAD. Ypatingą dėmesį atkreipkite į bet kurią saugyklą, kurioje anksčiau buvo naudojamas Google API raktas.
  2. Pasukti visus atskleistus raktus. Jei Dvynių raktas kada nors atsirado įsipareigojant, manykite, kad jis pažeistas. Panaikinkite jį ir sukurkite naują. Nemėginkite vertinti, ar kas nors „iš tikrųjų“ jį rado.
  3. Įdiekite nuskaitymą prieš patvirtinimą. Įdiekite slaptus aptikimo kabliukus kiekviename kūrėjo įrenginyje ir CI / CD konvejeriuose kaip neapeinamus vartus.
  4. Sukurkite pagrindinį inventorių. Žinokite, kurios paslaugos turi kokius kredencialus, kam jie priklauso, kada jie paskutinį kartą buvo keičiami ir kur jomis naudojamasi. Skaičiuoklė yra puikus pradžios taškas; paslapčių tvarkyklė yra tikslas.
  5. Nustatykite atsiskaitymo įspėjimus ir griežtus apribojimus. Kiekvienoje AI API paskyroje sukonfigūruokite įspėjimus 50 % ir 80 % numatomų mėnesinių išlaidų ir nustatykite griežtus limitus, kurie apsaugotų nuo katastrofiškų atsiskaitymo įvykių.
  6. Aiškiai dokumentuokite naująjį mentalinį modelį. Atnaujinkite savo komandos mokymo medžiagą ir inžinerijos vadovą, kad aiškiai nurodytumėte, jog Gemini API raktai yra labai jautrūs kredencialai, su kuriais reikia elgtis taip pat, kaip ir su mokėjimų procesoriaus paslaptimis.

Platesnė pamoka nuo platformos priklausančioms įmonėms

Dvynių situacija iliustruoja modelį, kuris turi įtakos bet kuriam verslui, giliai integruotam su trečiųjų šalių platformomis: platformos vystosi, o kartu su jomis kinta ir saugumo reikalavimai, tačiau tas platformas naudojančių komandų instituciniai įpročiai dažnai neatsilieka. Tai, kas buvo saugu vakar, yra pavojinga šiandien, o atotrūkis tarp šių dviejų valstijų yra ta vieta, kur įvyksta pažeidimai.

Tai ypač aktualu įmonėms, kurios valdo sudėtingus operatyvinius paketus. Įmonė, naudojanti dirbtinio intelekto funkcijas klientų aptarnavimo, analizės, turinio generavimo ir produktų rekomendacijų srityse, gali turėti Gemini integraciją keliolikoje skirtingų kontekstų – kiekvienas iš jų gali būti potencialus poveikio taškas, jei kredencialai tvarkomi nenuosekliai. Sprendimas yra ne tik geresni individualūs kūrėjų įpročiai; tai architektūrinis. Prieiga prie kredencialų turi būti centralizuota, tikrinama ir valdoma platformos lygiu.

Šiuolaikinės verslo operacinės sistemos vis dažniau kuriamos atsižvelgiant į tai. Kai Mewayz integruoja dirbtinio intelekto galimybes į savo rinkinį – nuo ​​išmaniųjų CRM darbo eigų iki automatizuotos analizės savo 207 modulių ekosistemoje – kredencialų valdymas tvarkomas infrastruktūros lygmenyje, o ne programų lygyje. Atskirų modulių kūrėjai neapdoroja neapdorotų API raktų; jie pasiekia galimybes per abstrakcijos sluoksnius, kurie įgyvendina rotacijos politiką, tikrina prieigą ir riboja sprogimo spindulį, jei kas nors negerai. Tai architektūra, kurios reikalauja Dvynių era: ne tik geresnių įpročių, bet ir geresnių sistemų, dėl kurių tinkamas įprotis yra vienintelė galima galimybė.

„Google“ nesuklydo kurdama leistiną API rakto modelį Žemėlapiams ir „YouTube“. Tas modelis tiko toms paslaugoms. Tačiau, kadangi API galimybės ir sąnaudų profiliai dramatiškai vystosi, o AI API yra bene ryškiausias tos raidos posūkio taškas, visai pramonei reikia iš naujo nustatyti numatytuosius nustatymus. Kūrėjai, kurie klesti šioje aplinkoje, bus ne tie, kurie geriausiai išmoko senąsias taisykles, o tie, kurie atpažįsta, kai taisyklės iš esmės pasikeitė.

Dažniausiai užduodami klausimai

Kodėl „Google“ API raktai istoriškai buvo laikomi saugiais viešai paskelbti?

„Google“ sukūrė daug savo API – Žemėlapius, „YouTube“, Vietas, skirtus naudoti kliento pusėje, o tai reiškia, kad raktai buvo sąmoningai įterpti į bet kam matomą priekinį kodą. Saugos modelis rėmėsi naudojimo apribojimais, pvz., domenų leidžiamaisiais sąrašais ir persiuntimo siuntėjo patikra, o ne rakto paslaptimi. Daugelį metų atskleistas raktas buvo laikomas konfigūracijos problema, o ne kritiniu pažeidžiamumu, kurį reikia nedelsiant pasukti.

Kas pasikeitė, kai „Google“ pristatė „Gemini“ API raktus?

Skirtingai nei senosios „Google“ API, „Gemini“ API raktai veikia labiau kaip tradicinės paslaptys – jų atskleidimas gali sukelti neteisėtus atsiskaitymo paskyros mokesčius, piktnaudžiavimą modeliu arba kvotos išnaudojimą be integruoto domeno apribojimo, kad jus išgelbėtų. Pakeitimas reiškia, kad kūrėjai dabar turi elgtis su Gemini raktais taip pat, kaip ir su AWS kredencialais arba slaptaisiais „Stripe“ raktais, saugodami juos serverio pusėje ir niekada kliento kode.

Kaip kūrėjai šiandien turėtų saugiai tvarkyti AI paslaugų API raktus?

Geriausia praktika yra saugoti visus AI API raktus kaip aplinkos kintamuosius serveryje, o ne versijos valdomuose failuose ar klientų paketuose. Naudokite paslapčių tvarkyklę, reguliariai keiskite raktus ir nustatykite išlaidų limitus teikėjo lygiu. Tokios platformos kaip „Mewayz“ – 207 modulių verslo OS už 19 USD/mėn., kurią galima įsigyti adresu app.mewayz.com – tvarko API kredencialus savo infrastruktūroje, kad komandos neautomatiškai žongliruotų paslaugų raktais.

Ką daryti, jei jau netyčia atskleidžiau Gemini API raktą?

Nedelsdami atšaukite pažeistą raktą naudodami „Google Cloud Console“ ir sugeneruokite pakeitimą prieš darydami ką nors kita. Patikrinkite atsiskaitymo informacijos suvestinę, ar nėra netikėtų naudojimo smailių, galinčių reikšti, kad raktas buvo paimtas. Tada peržiūrėkite savo kodų bazę, CI / CD aplinkos kintamuosius ir visas viešąsias saugyklas, ar nėra kitų nutekėjusių kredencialų. Su incidentu elkitės taip, kaip elgtumėtės su bet kokiu atskleistu mokėjimo kredencialu – manykite, kad jis buvo rastas, ir elkitės atitinkamai.