Ключы Google API не былі сакрэтамі, але потым Gemini змяніла правілы

Калі "грамадскі па задуме" становіцца абавязацельствам бяспекі

На працягу амаль двух дзесяцігоддзяў распрацоўшчыкі, якія абапіраюцца на экасістэму Google, атрымалі тонкі, але важны ўрок: ключы Google API насамрэч не сакрэт. Калі вы ўбудавалі ключ API дадзеных YouTube у файл JavaScript, Google не насцярожыўся. Калі ваш ключ Maps API з'явіўся ў агульнадаступным рэпазітары GitHub, рэакцыя бяспекі была па сутнасці пацісканнем плячыма і напамінам усталяваць абмежаванні дамена. Уся мадэль была пабудавана на падставе здагадкі, што гэтыя ключы будуць знаходзіцца ў кодзе на баку кліента, адкрытым для ўсіх, хто адкрывае DevTools.

Гэтая філасофія мела сэнс на працягу доўгага часу. Ключ Maps API, адкрыты без абмежаванняў дамена, мог бы прынесці нечаканы рахунак, але ён не збіраўся скампраметаваць запісы пацыентаў або ачысціць банкаўскі рахунак. Радыус выбуху быў фінансавым і кіраваным. Інструменты Google — абмежаванні па спасылцы, белыя спісы IP-адрасоў, абмежаванні квот — былі распрацаваны, каб стрымаць шкоду, а не цалкам прадухіліць уздзеянне.

Потым з'явіўся Gemini, і правілы змяніліся. Праблема ў тым, што мільёны распрацоўшчыкаў не атрымалі памятку.

Пастарэлая ментальная мадэль, якая зараз выклікае апёк у распрацоўшчыкаў

Стары вопыт распрацоўшчыкаў Google быў наўмысна паблажлівым. Калі вы стварылі ключ Maps JavaScript API, дакументацыя практычна заахвоціла вас перанесці яго непасрэдна ў ваш HTML. Мадэль бяспекі не была сакрэтнасцю - гэта былі абмежаванні. Вы б заблакіравалі ключ да свайго дамена, усталявалі абвесткі аб квотах і пайшлі далей. Гэта была прагматычная распрацоўка: прыкладанні на баку кліента сапраўды не могуць захоўваць сакрэты ад рашучых карыстальнікаў, таму Google стварыў сістэму, якая прызнае гэтую рэальнасць.

Гэта стварыла пакаленне распрацоўшчыкаў — і, што больш важна, пакаленне інстытуцыйных звычак — у якіх ключы Google API займалі іншую разумовую катэгорыю, чым, скажам, сакрэтны ключ Stripe або ўліковыя дадзеныя доступу да AWS. Вы б не ўставілі свой сакрэтны ключ Stripe у публічнае сховішча. Але ваш ключ ад Карт? Гэта было практычна значэнне канфігурацыі, а не сакрэт. Многія каманды захоўвалі іх у агульнадаступных файлах канфігурацыі, файлах README, нават у зменных асяроддзя на баку кліента з прэфіксам NEXT_PUBLIC_ або REACT_APP_, не задумваючыся.

Даследчыкі бяспекі, якія скануюць GitHub на прадмет адкрытых уліковых дадзеных, таксама навучыліся па-рознаму абыходзіцца з ключамі Google API. Уцечка ключа Карт была знаходкай нізкай ступені сур'ёзнасці. Уцечка ключа Gemini - гэта зусім іншая размова.

Што змянілася з Gemini — і чаму гэта важна

Gemini API ад Google не прытрымліваецца старой кнігі. Калі вы ствараеце ключ Gemini API праз Google AI Studio, вы ствараеце ўліковыя дадзеныя з прынцыпова іншым профілем рызыкі, чым ключ Maps або YouTube. Ключы Gemini аўтэнтыфікуюць доступ да вываду вялікай моўнай мадэлі — сэрвісу, які каштуе Google рэальных вылічальных рэсурсаў і які выстаўляе вам рахунак па жэтоне, а не па праглядзе старонкі.

Што яшчэ больш крытычна, ключы Gemini API не маюць такіх убудаваных механізмаў абмежавання дамена, якія рабілі магчымым выкрыццё іншых ключоў Google. Няма простага элемента кіравання "заблакіраваць гэта ў дамене майго вэб-сайта", які перашкодзіў бы зламысніку, які знайшоў ваш ключ у агульнадаступным сховішчы, стварыць сваю ўласную праграму і спажыць вашу квоту — або ваш ліміт білінгу — з сервера ў іншай краіне.

Небяспека не толькі фінансавая. Выкрыты ключ Gemini можа быць выкарыстаны для стварэння шкоднага змесціва, правядзення хуткіх ін'екцыйных атак або стварэння інструментаў, якія парушаюць умовы абслугоўвання Google - усё гэта выстаўляецца на ваш уліковы запіс і адсочваецца да вашай асобы.

У 2024 годзе даследчыкі бяспекі ідэнтыфікавалі тысячы адкрытых ключоў API Gemini толькі на GitHub, многія з іх у сховішчах, дзе раней без здарэнняў размяшчаліся іншыя ключы API Google. Распрацоўшчыкі не былі неабдуманымі па сваіх уласных гістарычных стандартах — яны ўжывалі разумовую мадэль, якой навучыў іх выкарыстоўваць сам Google. Асяроддзе мянялася хутчэй, чым звычкі.

Анатомія выпадковага ўздзеяння

Разуменне таго, як адбываецца такое ўздзеянне, - першы крок да іх прадухілення. Рэжымы няўдач надзвычай аднолькавыя ў камандах любога памеру:

• Няправільная класіфікацыя зменных асяроддзя: распрацоўшчыкі, якія прывыклі да ключоў Google Maps, дадаюць да ключоў Gemini прэфікс NEXT_PUBLIC_ або VITE_, імгненна паказваючы іх у камплекце кліенцкага кода.
• Забруджванне гісторыі сховішча: ключ дадаецца ў файл канфігурацыі, фіксуецца, потым выдаляецца, але гісторыя git застаецца даступнай для пошуку на нявызначаны час. Зламыснікі выкарыстоўваюць такія інструменты, як truffleHog і gitleaks спецыяльна для здабычы гэтай гісторыі.
• Уцечка нататнікаў і прататыпаў: Навукоўцы па апрацоўцы даных, якія ствараюць прататыпы інтэграцыі Gemini у нататнікі Jupyter, перадаюць гэтыя нататнікі ў GitHub з дапамогай ключоў, убудаваных у выснову ячэйкі.
• Няправільная канфігурацыя CI/CD: Ключы, якія захоўваюцца ў якасці сакрэтных сховішчаў, выпадкова адлюстроўваюцца ў журналах зборкі, якія агульнадаступныя на GitHub Actions або падобных платформах.
• Пашырэнне старонніх службаў: распрацоўшчыкі ўстаўляюць ключы ў панэлі аналітыкі, інструменты без кода або інтэграцыйныя платформы, не правяраючы сістэмы бяспекі гэтых платформаў.
• Каналы камунікацыі каманды: ключы, якія абагульваюцца праз Slack, Discord або электронную пошту, заканчваюцца ў гісторыях паведамленняў з магчымасцю пошуку, якія перажываюць графік ратацыі.

Агульнай ніткай з'яўляецца не халатнасць - гэта калапс кантэксту. Паводзіны, якія былі бяспечнымі ў адным кантэксце (распрацоўка Google Maps), небяспечныя ў іншым (распрацоўка Gemini), і візуальнае падабенства ўліковых даных дазваляе лёгка прапусціць адрозненне.

Стварэнне культуры кіравання сакрэтамі, якая маштабуецца

Сітуацыя Gemini з'яўляецца карыснай функцыяй прымусу да чагосьці, ад чаго многія каманды распрацоўшчыкаў адкладалі: стварэнне рэальнай інфраструктуры кіравання сакрэтамі, а не спецыяльныя падыходы. Для невялікіх каманд гэта можа здацца празмернай працай, але кошт выкрыцця ўліковых даных — махлярства з выстаўленнем рахункаў, прыпыненне ўліковага запісу, апавяшчэнні аб парушэннях даных — значна перавышае намаганні, неабходныя для таго, каб зрабіць гэта правільна.

Сучаснае кіраванне сакрэтамі прытрымліваецца шматузроўневага падыходу. На ўзроўні інфраструктуры такія інструменты, як HashiCorp Vault, AWS Secrets Manager або Google Secret Manager, забяспечваюць цэнтралізаванае сховішча ўліковых даных, якое можна правяраць, з магчымасцю аўтаматычнай ратацыі. Гэта не толькі для буйных прадпрыемстваў — такія сэрвісы, як Doppler і Infisical, прыносяць аднолькавыя шаблоны камандам з двух-трох распрацоўшчыкаў па даступнай цане.

На ўзроўні кода дысцыпліна прасцейшая: уліковыя дадзеныя ніколі не датычацца зыходнага кода. Кропка. Ні ў закаментаваных радках, ні ў файлах прыкладаў, ні ў тэставых прыборах з фальшывымі значэннямі, якія аказваюцца сапраўднымі. Папярэдне зафіксаваныя хукі, якія запускаюць такія інструменты, як detect-secrets або gitleaks, выяўляюць парушэнні да таго, як яны трапляюць у аддаленыя сховішчы. Канфігурацыя гэтых гачкоў займае некалькі хвілін, а ваша трывога пры рэагаванні на інцыдэнт зніжаецца на гады.

Для арганізацый, якія працуюць са складанымі аперацыйнымі пакетамі — ад кіравання працоўнымі працэсамі CRM да інтэграцыі заработнай платы і сістэм браніравання, арыентаваных на кліентаў — цэнтралізаванае кіраванне ўліковымі дадзенымі становіцца яшчэ больш важным. Такія платформы, як Mewayz, якая аб'ядноўвае 207 бізнес-модуляў пад адным аперацыйным парасонам, пабудаваны на аснове гэтага прынцыпу: уліковыя дадзеныя і інтэграцыя API кіруюцца на ўзроўні платформы, а не раскіданыя па асобных модулях або асобных асяроддзях распрацоўшчыкаў. Калі трэба вярнуць ключ, гэта адбываецца адзін раз, у адным месцы, а не ў семнаццаці розных кропках інтэграцыі.

Вектар атакі білінга: мадэль пагрозы, якую распрацоўшчыкі недаацэньваюць

Дыскусіі аб бяспецы часта сканцэнтраваны на парушэннях даных і несанкцыянаваным доступе. Праблема ўздзеяння Gemini дадае трэцюю мадэль пагрозы, якая заслугоўвае роўнай увагі: махлярства з рахункамі ў маштабах.

Вывад вялікай моўнай мадэлі каштуе дорага. GPT-4 і Gemini Ultra апрацоўваюць токены па долях цэнта кожны, але ў маштабе - тысячы запытаў, мільёны токенаў - гэтыя долі вельмі хутка складаюць тысячы долараў. Зламыснікам, якія выяўляюць адкрытыя ключы API AI, неабавязкова патрэбныя вашы даныя. Яны хочуць бясплатных вылічэнняў. Яны будуць выкарыстоўваць вашыя ўліковыя даныя для запуску ўласных сэрвісаў штучнага інтэлекту, перапрадаваць магчымасці вываду або стрэс-тэсціраваць свае прыкладанні — і ўсё гэта, пакуль рахунак будзе за вас.

Адзін распрацоўшчык задакументаваў, як прачнуўся ад купюры ў 23 000 долараў ад ключа Gemini, які знаходзіўся ў публічным сховішчы менш чым на шэсць гадзін. Зламыснік неадкладна аўтаматызаваў эксплуатацыю, бесперапынна выконваючы задачы генерацыі высокай прапускной здольнасці, пакуль Google не выявіў махлярства. Распрацоўшчык у рэшце рэшт дамогся адмены абвінавачванняў пасля доўгага працэсу спрэчкі, але ўліковы запіс быў прыпынены на гэты перыяд, што прывяло да спынення вытворчых паслуг.

Вось чаму абвесткі аб выстаўленні рахункаў і ліміты квот не замяняюць належнае кіраванне сакрэтамі — гэта апошняя лінія абароны, якая, як вы спадзяецеся, вам ніколі не спатрэбіцца. Устанаўленне жорсткіх штомесячных лімітаў выдаткаў на ўліковыя запісы API AI цяпер стала звычайнай справай, але сапраўдная абарона заключаецца ў тым, каб гэтыя ўліковыя даныя ніколі не ўцекалі.

Практычныя крокі для каманд, якія робяць пераход

Калі ваша каманда стварала інтэграцыю API Google у адпаведнасці са старой ментальнай мадэллю і зараз дадае Gemini у стэк, вось рэалістычны кантрольны спіс для выпраўлення:

1. Неадкладна праверце існуючыя сховішчы. Запусціце truffleHog або gitleaks для вашай поўнай гісторыі git, а не толькі для бягучага HEAD. Засяродзьцеся асабліва на любым сховішчы, у якім у мінулым выкарыстоўваўся ключ Google API.
2. Паварот усіх адкрытых ключоў. Калі ключ Gemini калі-небудзь з'яўляўся ў фіксацыі, выкажам здагадку, што ён узламаны. Адклікайце яго і стварыце новы. Не спрабуйце ацаніць, ці хто-небудзь "сапраўды" гэта знайшоў.
3. Укараніце сканіраванне перад фіксацыяй. Усталюйце сакрэтныя хукі для выяўлення на кожнай машыне распрацоўшчыка і ў канвеерах CI/CD у якасці неабыходнага шлюза.
4. Стварыце інвентарызацыю ключоў. Ведайце, якія сэрвісы маюць якія ўліковыя даныя, каму яны належаць, калі яны апошні раз былі заменены і дзе яны выкарыстоўваліся. Электронная табліца - добрая адпраўная кропка; менеджэр сакрэтаў з'яўляецца пунктам прызначэння.
5. Усталюйце абвесткі аб выстаўленні рахункаў і жорсткія ліміты. На кожным уліковым запісе AI API наладзьце абвесткі на ўзроўні 50% і 80% вашых чаканых штомесячных выдаткаў і ўсталюйце жорсткія ліміты, якія прадухіляць катастрафічныя падзеі выстаўлення рахункаў.
6. Ясна задакументуйце новую ментальную мадэль. Абнавіце матэрыялы па адаптацыі і інжынернае кіраўніцтва вашай каманды, каб яўна пазначыць, што ключы Gemini API з'яўляюцца высокаканфідэнцыйнымі ўліковымі дадзенымі, якія патрабуюць таго ж абыходжання, што і сакрэты плацежнага працэсара.

Шырокі ўрок для платформенна-залежных кампаній

Сітуацыя з Gemini ілюструе заканамернасць, якая ўплывае на любы бізнес, глыбока інтэграваны са староннімі платформамі: платформы развіваюцца, і патрабаванні да бяспекі развіваюцца разам з імі, але інстытуцыянальныя звычкі каманд, якія выкарыстоўваюць гэтыя платформы, часта не паспяваюць за імі. Тое, што ўчора было бяспечным, сёння небяспечна, і разрыў паміж гэтымі двума станамі - гэта месца, дзе адбываюцца парушэнні.

Гэта асабліва актуальна для кампаній, якія працуюць са складанымі аперацыйнымі пакетамі. Кампанія, якая выкарыстоўвае функцыі штучнага інтэлекту ў абслугоўванні кліентаў, аналітыцы, генерацыі кантэнту і рэкамендацыях па прадуктах, можа мець інтэграцыю Gemini у тузіне розных кантэкстаў - кожны з іх з'яўляецца патэнцыйнай кропкай уздзеяння, калі ўліковыя дадзеныя апрацоўваюцца непаслядоўна. Рашэнне заключаецца не толькі ў паляпшэнні індывідуальных звычак распрацоўшчыка; гэта архітэктурна. Доступ да ўліковых дадзеных павінен быць цэнтралізаваным, кантраляваным і кіраваным на ўзроўні платформы.

Сучасныя бізнес-аперацыйныя сістэмы ўсё часцей распрацоўваюцца з улікам гэтага. Калі Mewayz аб'ядноўвае магчымасці штучнага інтэлекту ва ўсім сваім наборы — ад інтэлектуальных працоўных працэсаў CRM да аўтаматызаванай аналітыкі ў экасістэме з 207 модуляў — кіраванне ўліковымі дадзенымі ажыццяўляецца на ўзроўні інфраструктуры, а не на ўзроўні прыкладанняў. Індывідуальныя распрацоўшчыкі модуляў не працуюць з неапрацаванымі ключамі API; яны атрымліваюць доступ да магчымасцей праз ўзроўні абстракцыі, якія забяспечваюць выкананне палітык ратацыі, аўдыту доступу і абмяжоўваюць радыус выбуху, калі нешта пойдзе не так. Гэта тая архітэктура, якой патрабуе эра Двайнят: не толькі лепшыя звычкі, але і лепшыя сістэмы, якія робяць правільныя звычкі адзіным даступным варыянтам.

Google не памыліўся, стварыўшы дазвольную мадэль ключа API для Карт і YouTube. Такая мадэль падыходзіла для тых службаў. Але паколькі магчымасці і профілі выдаткаў API рэзка развіваюцца — і паколькі API AI ўяўляюць сабой, мабыць, самую рэзкую кропку пералому ў гэтай эвалюцыі — уся галіна павінна скінуць свае налады па змаўчанні. Распрацоўшчыкі, якія квітнеюць у гэтым асяроддзі, будуць не тыя, хто лепш за ўсё вывучыў старыя правілы, а тыя, хто разумее, калі правілы прынцыпова змяніліся.

Часта задаюць пытанні

Чаму ключы API Google гістарычна лічыліся бяспечнымі для публічнага выкрыцця?

Google распрацаваў многія з сваіх API — Maps, YouTube, Places — для выкарыстання на баку кліента, што азначае, што ключы былі наўмысна ўбудаваныя ў інтэрфейсны код, бачны ўсім. Мадэль бяспекі абапіралася на абмежаванні выкарыстання, такія як белыя спісы даменаў і праверкі спасылак, а не на сакрэтнасць ключа. На працягу многіх гадоў адкрыты ключ лічыўся праблемай канфігурацыі, а не крытычнай уразлівасцю, якая патрабуе неадкладнай ратацыі.

Што змянілася, калі Google прадставіў ключы Gemini API?

У адрозненне ад састарэлых API Google, ключы Gemini API функцыянуюць больш як традыцыйныя сакрэты — раскрыццё аднаго можа прывесці да несанкцыянаванага спагнання плацяжоў з вашага плацежнага рахунку, злоўжывання мадэллю або вычарпання квоты без убудаванага абмежавання дамена, каб выратаваць вас. Змена азначае, што распрацоўшчыкі цяпер павінны абыходзіцца з ключамі Gemini з той жа дысцыплінай, што і з уліковымі дадзенымі AWS або сакрэтнымі ключамі Stripe, захоўваючы іх на баку сервера, а не ў кліенцкім кодзе.

Як распрацоўшчыкам сёння бяспечна кіраваць ключамі API для службаў штучнага інтэлекту?

Найлепшая практыка - захоўваць усе ключы API AI як зменныя асяроддзя на серверы, а не ў файлах з кантролем версій або кліенцкіх пакетах. Выкарыстоўвайце менеджэр сакрэтаў, рэгулярна мяняйце ключы і ўстанаўлівайце ліміты выдаткаў на ўзроўні пастаўшчыка. Такія платформы, як Mewayz — 207-модульная бізнес-АС па цане 19 долараў у месяц, даступная на app.mewayz.com — апрацоўваюць кіраванне ўліковымі данымі API у сваёй інфраструктуры, каб каманды не жангліравалі ўручную ключамі паміж службамі.

Што мне рабіць, калі я ўжо выпадкова раскрыў ключ API Gemini?

Анулюйце скампраметаваны ключ неадкладна праз Google Cloud Console і стварыце замену, перш чым рабіць што-небудзь яшчэ. Праверце прыборную панэль выстаўлення рахункаў на наяўнасць нечаканых скокаў выкарыстання, якія могуць азначаць, што ключ быў сабраны. Затым праглядзіце сваю кодавую базу, зменныя асяроддзя CI/CD і любыя агульнадаступныя сховішчы на ​​прадмет іншых уцечак уліковых дадзеных. Ставіцеся да інцыдэнту так, як і да раскрытых плацежных уліковых даных — лічыце, што яны знойдзены, і дзейнічайце адпаведна.