Google Cloud призывает компании внедрять безопасность на платформенном уровне, а не «прикручивать» её позже

Среднее время между взломом и передачей данных злоумышленникам сократилось с восьми часов до 22 секунд

ИИ-агенты способны находить забытые серверы и вскрывать устаревшие данные, создавая новые уязвимости

После взлома API-ключей Google счета разработчиков вырастали до десятков тысяч долларов, а отзыв ключа занимал до 23 минут

Ключи Google Maps, размещённые публично по инструкциям самой компании, получили доступ к Gemini без явного уведомления пользователей — Truffle Security нашла 2 863 живых ключа

За кулисами недавнего мероприятия в Лос-Анджелесе операционный директор Google Cloud Фрэнсис деСоуза (Francis deSouza) уделил несколько минут разговору о том, как предприятия относятся к безопасности ИИ и что им следует делать. Говоря спокойным размеренным тоном университетского профессора, он заметил: «Будет переходный период, а затем, я думаю, мы придём к лучшему месту».

Источник изображения: Joan Cros/NurPhoto / Getty ImagesИсточник изображения — Joan Cros/NurPhoto / Getty Images

Как показывают события последних недель, Google и сама ещё проходит через этот переходный период — и не всегда красиво.

Кто говорит — и почему его стоит слушать

ДеСоуза пришёл в Google Cloud в январе 2025 года на должность COO и президента подразделения Security Products. За плечами у него почти четыре десятилетия в индустрии: восемь лет в Symantec, где он дорос до президента по продуктам и сервисам, затем кресло генерального директора биотехнологической Illumina, основание стартапа SynthLabs (постобучение моделей ИИ) и членство в совете директоров Deel. До этого две его компании были поглощены: IMLogic ушла в Symantec, Flash Communications — в Microsoft. То есть человек, выступающий от лица Google по теме «безопасность и ИИ», провёл значительную часть карьеры именно в кибербезопасности, а не пришёл в неё с конъюнктурного направления.

Главный тезис: безопасность не «прикручивается» сбоку

Основная мысль деСоузы — то, что специалисты по безопасности годами пытались донести до руководителей, а с появлением ИИ это стало критически важным: безопасность не может быть запоздалой мыслью. «Когда компании встают на путь ИИ, им нужно применять платформенный подход, — сказал он. — Безопасность — это не то, что можно добавить позже, и не то, что можно оставить на усмотрение сотрудников».

Он особо предупредил о «теневом ИИ» (shadow AI) — использовании сотрудниками потребительских инструментов в обход контроля со стороны организации — и отметил, что компании должны с самого начала требовать от своих платформ безопасности, управляемости и аудируемости. «Не существует стратегии ИИ без стратегии данных и стратегии безопасности. Они должны идти рука об руку», — подчеркнул он.

Стоит отметить: деСоуза не рекламировал только Google Cloud. Когда журналист заметил, что его советы звучат как реклама Google, он возразил. По его словам, Google привержена мультиоблачному подходу, и компании, считающие себя «однооблачными», почти наверняка ошибаются. «Даже если они выбрали одно облако, они полагаются на SaaS-приложения, у них есть бизнес-партнёры, которые могут пользоваться другими облаками, — сказал он. — Для компаний важно иметь согласованную стратегию безопасности во всех облаках и моделях».

Восемь часов превратились в 22 секунды

ДеСоуза утверждает, что ландшафт угроз изменился настолько фундаментально, что старые модели обороны просто слишком медленны. По его данным, среднее время между первоначальным проникновением и передачей доступа на следующий этап атаки сократилось с 8 часов до 22 секунд. Поверхность атаки тоже расширилась далеко за пределы традиционного сетевого периметра.

«В дополнение к обычной инфраструктуре теперь у вас есть модели, — перечисляет он. — У вас есть конвейеры данных для их обучения. У вас есть агенты, у вас есть промпты. Всё это нужно защищать».

Агенты находят то, о чём все давно забыли

Одна из угроз, на которую указал деСоуза и которая, по его мнению, получает недостаточно внимания: автономные ИИ-агенты, перемещающиеся по внутренним системам компании, могут вскрыть забытые репозитории данных, о которых никто не вспоминал годами. «У многих организаций есть старые серверы SharePoint и забытые настройки прав доступа, которые они не обновляли, — но это не имело значения, потому что никто не помнил, где они вообще находятся. Агенты же, бродящие по вашему предприятию, найдут эти ресурсы и раскроют данные на них».

Иными словами, ИИ-агент работает не как сотрудник, который «и не подумал бы туда лезть», а как добросовестный сканер, методично перебирающий всё, к чему имеет хотя бы формальный доступ. Безопасность через неизвестность (security through obscurity) в эпоху агентов перестаёт работать.

Машинная скорость против машинной скорости

Ответ, по мнению деСоузы, — встретить машинную скорость машинной скоростью. «Мы наблюдаем появление нативной для ИИ, полностью агентной обороны, где организации запускают агентов, которые ведут защиту, — сказал он. — Вместо защиты под руководством человека или даже с участием человека в цикле теперь возможна модель, при которой люди наблюдают за полностью агентной обороной».

Он добавил, что вопрос вышел за пределы технического: «Это вопрос уровня совета директоров и исполнительного руководства. Это уже не только проблема команды безопасности».

«Баг-апокалипсис» и нехватка людей

Но даже когда ИИ берёт на себя больше оборонительной работы, людей, способных это контролировать, не хватает — а уязвимости, которые сам ИИ привносит, множатся быстрее, чем команды безопасности успевают с ними разбираться. «Нам понадобятся люди, чтобы справиться с баг-апокалипсисом», — заявила Лиа Кисснер (Lea Kissner), главный специалист по информационной безопасности LinkedIn, в интервью The New York Times на этой неделе. Кисснер добавила, что не ожидает, что индустрия сколько-нибудь устойчиво разберётся в безопасности ИИ ещё несколько лет.

Когда платформа сама становится проблемой

Что подводит нас обратно к самим платформенным провайдерам. The Register за последние недели опубликовал серию репортажей о волне разработчиков Google Cloud, получивших пятизначные счета после неавторизованных вызовов API к моделям Gemini — сервисам, которые многие из них никогда не использовали и сознательно не включали.

Сценарий повторяется до запятой:

  • Разработчик создал API-ключ для Google Maps и разместил его публично — ровно так, как рекомендует сама Google в документации (ключи Maps исторически считались идентификаторами проекта для биллинга, а не секретами).
  • В какой-то момент Google молча расширила область действия таких ключей: они получили возможность аутентифицироваться в API Gemini (Generative Language API). Пользователей об этом не уведомили.
  • Исследователи Truffle Security просканировали миллионы сайтов и нашли 2 863 живых ключа, которые когда-то использовались для Maps, а теперь дают доступ и к Gemini — со всеми возможностями выгружать загруженные файлы, кэшированные данные разговоров и генерировать платные запросы за счёт владельца.
  • Злоумышленники находят такой ключ, выкручивают на максимум самые дорогие модели (Gemini Pro Image, Gemini Pro Text, Nano Banana) — и за считанные минуты счёт улетает в небеса.

Это не «утечка ключей» в привычном смысле — это ретроактивная эскалация привилегий: учётные данные, изначально не считавшиеся секретом, незаметно стали секретом, потому что Google прицепила к ним новые возможности.

Конкретные жертвы и конкретные цифры

Род Данан (Rod Danan), генеральный директор платформы подготовки к собеседованиям Prentus, сообщил, что его счёт достиг $10 138 примерно за 30 минут после того, как злоумышленники воспользовались его скомпрометированным ключом. Исуру Фонсека (Isuru Fonseka), разработчик из Сиднея с десятилетним опытом работы в экосистеме Google Cloud, проснулся и обнаружил списания на сумму около AUD $17 000 — несмотря на то, что у него, как он полагал, был установлен лимит расходов в $250.

Чуть раньше, в феврале 2026 года, мексиканский стартап из трёх разработчиков получил счёт на $82 314,44 за 48 часов — при обычных тратах около $180 в месяц. Рост — примерно в 460 раз.

Объединяет все эти истории одна деталь: ни один из пострадавших не знал, что автоматические системы Google повысили их тарифные уровни на основе истории учётной записи, подняв эффективные лимиты с $250 до $100 000 без явного согласия пользователя.

Данану и Фонсеке Google вернула деньги после того, как The Register опубликовал свой репортаж. Тем не менее компания сообщила изданию, что не планирует менять политику автоматического повышения тарифного уровня, ссылаясь на приоритет — не допустить простоев сервиса важнее, чем соблюдать пользовательские бюджетные пожелания. Фонсека, в свою очередь, заявил, что отключил Gemini во всех своих проектах и будет пользоваться альтернативными провайдерами вроде OpenRouter, лишь бы держать риск подальше от своего аккаунта.

23 минуты после «удаления»: ключ всё ещё живой

Есть и отдельный, не менее тревожный вопрос: что происходит, когда разработчик пытается прекратить кровотечение. На этой неделе The Register сообщил об исследовании компании по безопасности Aikido: даже разработчики, которые заметили компрометацию и немедленно удалили ключ, могут оставаться уязвимыми.

По данным Aikido, злоумышленники могут продолжать использовать удалённый ключ до 23 минут — потому что отзыв доступа в инфраструктуре Google распространяется не мгновенно, а постепенно. В 10 испытаниях, проведённых за двое суток, исследователи получили следующую картину:

  • Медианное время отзыва — около 16 минут;
  • Минимальное — около 8 минут;
  • Максимальное — почти 23 минуты;
  • В отдельные минуты внутри этого окна более 90% запросов к API всё ещё успешно аутентифицировались;
  • В другие минуты — менее 1%. То есть успех непредсказуем, но достаточно высок, чтобы при достаточной интенсивности запросов гарантированно проходили десятки и сотни вызовов.

Исследователь Aikido Джозеф Леон (Joseph Leon) сообщил The Register, что в течение этого окна атакующий может выгрузить файлы и кэшированный контекст разговоров из Gemini. Дальше — деньги уже потрачены, данные уже утекли.

Любопытная деталь: проблема касается «старых» ключей Google API. Новые форматы учётных данных самой Google ведут себя нормально:

  • учётные данные API для сервисных аккаунтов (service accounts) отзываются примерно за 5 секунд;
  • новый формат ключей Gemini с префиксом AQ — примерно за 1 минуту;
  • старые «универсальные» API-ключи Google — до 23 минут.

«Оба новых формата работают в масштабе Google, — написал Леон в сопроводительном документе Aikido. — Оба показывают, что технически это решаемо и для классических ключей Google API». Иными словами, 23-минутное окно — это не инженерное ограничение, а вопрос приоритетов компании. Сама Google пометила тикет как «не будем чинить» (won't fix), описав задержку как «ожидаемое поведение eventually-consistent системы».

Что делать на стороне разработчика прямо сейчас

Пока платформа догоняет реальность, базовая гигиена — не роскошь, а обязательное условие:

  • Ротировать все ранее публичные ключи — любой ключ, который когда-либо появлялся в JavaScript, HTML, мобильном приложении или публичном репозитории, считать скомпрометированным.
  • Жёстко ограничивать область действия — каждый ключ привязывать только к конкретным API (Maps, Places и т.д.); никогда не оставлять режим «Unrestricted».
  • Сочетать ограничения по referrer и по API: одних referrer-ограничений недостаточно — они не защищают от серверных вызовов Gemini.
  • Отключать Generative Language API в тех проектах, где Gemini не нужен — это уберёт доступ к Gemini у всех ключей в проекте.
  • Разнести Maps и Gemini по разным проектам GCP: проект для публичного фронтенда и проект для ИИ-моделей не должны делить ключи.
  • Настроить агрессивные алерты по биллингу, особенно по Generative Language API — внезапный всплеск трат там обычно означает, что чужой ключ уже работает на чужую пользу.
  • Помнить про мифический «лимит расходов»: Google может молча повысить тарифный уровень. Реальный потолок — не тот, что вы видите в настройках.

Разрыв между тем, что говорят, и тем, как живут

Всё это стоит держать в голове, читая советы деСоузы — они здравые, и относиться к ним стоит серьёзно. Он не ошибается: безопасность действительно надо встраивать сразу, мультиоблачная стратегия действительно нужна, агентная оборона действительно неизбежна, а старые SharePoint-серверы действительно станут проблемой.

Но между тем, что предписывают платформы, и тем, как быстро они сами адаптируются, сейчас зияет ощутимый разрыв. Когда облачный гигант рассказывает корпорациям, как правильно строить безопасность ИИ, а параллельно — молча расширяет права старых ключей, автоматически поднимает лимиты расходов в 400 раз и тратит до 23 минут на то, чтобы прекратить принимать удалённый ключ, — это и есть тот самый «переходный период», о котором говорит деСоуза. Просто проходят его все — включая саму Google.