Ключовете за API на Google не бяха тайни, но след това Gemini промени правилата

Когато „Публичен по дизайн“ се превърне в задължение за сигурност

В продължение на почти две десетилетия разработчиците, надграждащи екосистемата на Google, научиха фин, но важен урок: ключовете на Google API всъщност не са тайни. Ако сте вградили ключ за API за данни на YouTube в JavaScript файл, Google не се разтревожи. Ако вашият API ключ за Maps се появи в публично хранилище на GitHub, отговорът на сигурността беше по същество свиване на рамене и напомняне да зададете ограничения на домейна. Целият модел е изграден около предположението, че тези ключове ще живеят в код от страна на клиента, изложен на всеки, който отвори DevTools.

Тази философия имаше смисъл дълго време. Ключ за API на Карти, разкрит без ограничения на домейна, може да натрупа изненадваща сметка, но нямаше да компрометира досиета на пациенти или да източи банкова сметка. Радиусът на взрива беше финансов и управляем. Инструментите на Google – ограничения за референти, бели списъци на IP адреси, ограничения на квотите – са проектирани да ограничават щетите, а не да предотвратят изцяло излагането.

Тогава Джемини пристигна и правилата се промениха. Проблемът е, че милиони разработчици не са получили бележката.

Наследеният ментален модел, който сега изгаря разработчиците

Старият опит на разработчиците на Google беше съзнателно разрешителен. Когато сте създали API ключ на Maps JavaScript, документацията на практика ви е насърчила да го пуснете директно във вашия HTML. Моделът за сигурност не беше секретност - беше ограничение. Ще заключите ключа към вашия домейн, ще зададете известия за квоти и ще продължите напред. Това беше прагматично инженерство: приложенията от страна на клиента наистина не могат да пазят тайни от решителните потребители, така че Google изгради система, която признава тази реалност.

Това създаде поколение разработчици — и по-важното, поколение институционални навици — при които ключовете на API на Google заемат различна умствена категория от, да речем, таен ключ на Stripe или идентификационни данни за достъп до AWS. Не бихте поставили вашия Stripe секретен ключ в публично репо. Но вашият ключ за Карти? Това на практика беше конфигурационна стойност, а не тайна. Много екипи ги съхраняваха в публични конфигурационни файлове, файлове README, дори в променливи на средата от страна на клиента с префикс NEXT_PUBLIC_ или REACT_APP_ без да се замислят.

Изследователите по сигурността, сканиращи GitHub за разкрити идентификационни данни, се научиха да третират ключовете за API на Google също по различен начин. Изтекъл ключ за Карти беше констатация с ниска сериозност. Изтекъл ключ на Gemini е съвсем различен разговор.

Какво се промени с Gemini — и защо има значение

Приложният програмен интерфейс (API) на Google Gemini не следва старата инструкция. Когато генерирате ключ за API на Gemini чрез Google AI Studio, вие създавате идентификационни данни с фундаментално различен рисков профил от ключове за Карти или YouTube. Ключовете на Gemini удостоверяват достъпа до извода на големия езиков модел – услуга, която струва на Google реални изчислителни ресурси и която ви таксува по токена, а не по показването на страница.

По-критично, ключовете на Gemini API нямат същите вградени механизми за ограничаване на домейни, които направиха излагането на други ключове на Google оцелеещо. Няма прост контрол „заключи това към домейна на моя уебсайт“, който би попречил на атакуващ, който е намерил ключа ви в публично хранилище, да завърти собственото си приложение и да изконсумира вашата квота — или лимита ви за таксуване — от сървър в друга държава.

Опасността не е само финансова. Разкрит ключ Gemini може да се използва за генериране на вредно съдържание, извършване на бързи атаки за инжектиране или създаване на инструменти, които нарушават условията на услугата на Google – всичко това се таксува към вашия акаунт и може да бъде проследено обратно до вашата самоличност.

През 2024 г. изследователите по сигурността идентифицираха хиляди разкрити Gemini API ключове само в GitHub, много от тях в хранилища, които преди това са хоствали други Google API ключове без инциденти. Разработчиците не са били безразсъдни според собствените си исторически стандарти - те са прилагали умствен модел, който самият Google ги е обучил да използват. Средата се промени по-бързо от навиците.

Анатомията на едно случайно излагане

Разбирането как се случват тези експозиции е първата стъпка към предотвратяването им. Режимите на отказ са забележително последователни в екипи от всякакъв размер:

• Грешна класификация на променливите на средата: Разработчиците, свикнали с ключовете на Google Карти, префиксират ключовете Gemini с NEXT_PUBLIC_ или VITE_, незабавно ги разкривайки в пакетен код от страна на клиента.
• Замърсяване на хронологията на хранилището: Към конфигурационен файл се добавя ключ, записва се, след което се премахва — но хронологията на git остава достъпна за търсене за неопределено време. Нападателите използват инструменти като truffleHog и gitleaks специално за копаене на тази история.
• Изтичане на преносими компютри и прототипи: Учените по данни, създаващи прототипи на интеграции на Gemini в преносими компютри на Jupyter, изпращат тези преносими компютри към GitHub с ключове, вградени в изходните данни на клетката.
• Грешна конфигурация на CI/CD: Ключовете, съхранени като тайни на хранилище, случайно се отразяват в регистрационни файлове за компилация, които са публично видими в GitHub Actions или подобни платформи.
• Разрастване на услугите на трети страни: Разработчиците поставят ключове в табла за управление на анализи, инструменти без код или платформи за интегриране, без да преглеждат позициите за сигурност на тези платформи.
• Канали за комуникация на екипа: Ключовете, споделени през Slack, Discord или имейл, завършват в истории на съобщения с възможност за търсене, които надживяват графика за ротация.

Общата нишка не е небрежност — това е колапс на контекста. Поведения, които са били безопасни в един контекст (разработка на Google Карти), са опасни в друг (разработка на Gemini), а визуалното сходство на идентификационните данни прави разликата лесна за пропускане.

Изграждане на култура на управление на тайните, която се мащабира

Ситуацията с Gemini е полезна форсираща функция за нещо, което много екипи за разработка отлагат: изграждане на действителна инфраструктура за управление на тайни, а не ad hoc подходи. За малки екипи това може да изглежда като прекомерно инженерство, но цената на разкриването на идентификационни данни – измама с таксуване, спиране на акаунт, известия за нарушаване на данните – значително надвишава усилието да се направи това правилно.

Съвременното управление на тайни следва подход на нива. На ниво инфраструктура инструменти като HashiCorp Vault, AWS Secrets Manager или Google Secret Manager осигуряват централизирано, подлежащо на проверка съхранение на идентификационни данни с възможности за автоматична ротация. Те не са само за големи предприятия — услуги като Doppler и Infisical предоставят същите модели на екипи от двама или трима разработчици на достъпни цени.

На ниво код дисциплината е по-проста: идентификационните данни никога не докосват изходния код. Точка. Не в коментирани редове, не в примерни файлове, не в тестови приспособления с фалшиво изглеждащи стойности, които се оказват истински. Предварителните кукички, работещи с инструменти като detect-secrets или gitleaks улавят нарушенията, преди да достигнат до отдалечени хранилища. Тези кукички отнемат минути за конфигуриране и години намалят безпокойството ви при реакция при инцидент.

За организации, управляващи сложни оперативни стекове — управление на всичко от работни потоци на CRM до интеграции на заплати до системи за резервации, насочени към клиента — централизираното управление на идентификационните данни става още по-критично. Платформи като Mewayz, която обединява 207 бизнес модула под един оперативен чадър, са изградени с този принцип в основата си: идентификационните данни и интеграциите на API се управляват на ниво платформа, а не разпръснати в отделни модули или отделни среди на разработчици. Когато даден ключ трябва да се завърти, това се случва веднъж, на едно място, а не през седемнадесет различни точки на интеграция.

Векторът на атака срещу таксуване: модел на заплаха, който разработчиците подценяват

Дискусиите относно сигурността често се съсредоточават върху нарушения на данните и неупълномощен достъп. Проблемът с излагането на Gemini добавя трети модел на заплаха, който заслужава също толкова внимание: мащабни измами с таксуване.

Изводът за голям езиков модел е скъп. GPT-4 и Gemini Ultra обработват токени на части от цента всеки, но в мащаб - хиляди заявки, милиони токени - тези фракции добавят хиляди долари много бързо. Нападателите, които открият разкрити AI API ключове, не искат непременно вашите данни. Те искат безплатни компютри. Те ще използват вашите идентификационни данни, за да управляват свои собствени услуги за изкуствен интелект, да препродават капацитет за изводи или да тестват приложенията си под стрес – всичко това, докато сметката е за вас.

Един разработчик документира събуждане до сметка от $23 000 от ключ Gemini, изложен в публично хранилище за по-малко от шест часа. Нападателят незабавно е автоматизирал експлоатацията, изпълнявайки непрекъснато задачи за генериране на висока пропускателна способност, докато разкриването на измами на Google не го улови. Програмистът в крайна сметка успя да отмени таксите след дълъг процес на оспорване, но акаунтът беше спрян през този период, което свали производствените услуги заедно с него.

Ето защо сигналите за таксуване и ограниченията на квотите не са заместител на правилното управление на тайните — те са последна линия на защита, която се надявате никога да не ви потрябва. Задаването на строги месечни лимити на разходите за акаунти в AI API вече е залог, но истинската защита е да се гарантира, че тези идентификационни данни никога няма да изтекат.

Практически стъпки за екипи, извършващи преход

Ако вашият екип е изграждал интеграции на 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 интегрира AI възможности в целия си пакет – от интелигентни CRM работни потоци до автоматизирани анализи в своята 207-модулна екосистема – управлението на идентификационните данни се обработва на инфраструктурния слой, а не на приложния слой. Индивидуалните разработчици на модули не обработват необработени API ключове; те имат достъп до възможности чрез абстракционни слоеве, които налагат политики за ротация, одит на достъпа и ограничават радиуса на взрив, ако нещо се обърка. Това е архитектурата, която изисква ерата на Близнаци: не само по-добри навици, но и по-добри системи, които правят правилния навик единствената налична опция.

Google не допусна грешка при изграждането на разрешителен модел на API ключ за Карти и YouTube. Този модел беше подходящ за тези услуги. Но тъй като възможностите и профилите на разходите на API се развиват драстично – и тъй като API на AI представляват може би най-острата инфлексна точка в тази еволюция – цялата индустрия трябва да нулира своите настройки по подразбиране. Разработчиците, които процъфтяват в тази среда, няма да са тези, които са научили най-добре старите правила, а тези, които разпознават кога правилата са се променили фундаментално.

Често задавани въпроси

Защо ключовете за API на Google в миналото са били смятани за безопасни за публично разкриване?

Google проектира много от своите API – Карти, YouTube, Места – за използване от страна на клиента, което означава, че ключовете са били умишлено вградени в кода от предния край, видим за всеки. Моделът за сигурност разчиташе на ограничения за използване като списъци с разрешени домейни и проверки на референти, а не на секретност на ключовете. Години наред откритият ключ се смяташе за проблем с конфигурацията, а не за критична уязвимост, изискваща незабавна ротация.

Какво се промени, когато Google представи Gemini API ключове?

За разлика от наследените API на Google, API ключовете на Gemini функционират по-скоро като традиционни тайни — разкриването на един може да доведе до неоторизирани такси към вашия акаунт за таксуване, злоупотреба с модела или изчерпване на квотата без вградено ограничение на домейна, което да ви спаси. Промяната означава, че разработчиците вече трябва да третират ключовете на Gemini със същата дисциплина като идентификационните данни на AWS или тайните ключове на Stripe, като ги съхраняват от страната на сървъра и никога в кода, обърнат към клиента.

Как разработчиците трябва да управляват сигурно API ключовете за AI услуги днес?

Най-добрата практика е да съхранявате всички API ключове за AI като променливи на средата на сървъра, никога в контролирани от версия файлове или клиентски пакети. Използвайте мениджър на тайни, редувайте ключовете редовно и задавайте лимити на разходите на ниво доставчик. Платформи като Mewayz — 207-модулна бизнес операционна система за $19/месец, налична на app.mewayz.com — обработват управлението на идентификационните данни на API в рамките на тяхната инфраструктура, така че екипите да не жонглират ръчно с ключове между услугите.

Какво трябва да направя, ако вече съм разкрил случайно API ключ на Gemini?

Анулирайте компрометирания ключ незабавно чрез Google Cloud Console и генерирайте заместител, преди да направите каквото и да било друго. Проверявайте таблото си за таксуване за неочаквани пикове в употребата, които биха могли да показват, че ключът е събран. След това прегледайте кодовата си база, променливите на средата на CI/CD и всички публични хранилища за други изтекли идентификационни данни. Отнесете се към инцидента, както към всеки разкрит идентификационен номер за плащане — приемете, че е намерен и действайте съответно.