Francis de Souza из Google Cloud: ИИ-безопасность должна быть заложена в платформу с самого начала — ИИ для бизнеса

Francis de Souza из Google Cloud: ИИ-безопасность должна быть заложена в платформу с самого начала

Прослушать статью

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

Как выясняется, сам Google тоже проходит этот переходный период.

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

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

Важно отметить: он не продвигал только Google Cloud. Когда я заметил, что его советы звучат как реклама Google, он возразил. Google, по его словам, придерживается multicloud-подхода, и он утверждал, что компании, которые считают, будто работают в одном cloud, почти наверняка ошибаются. «Даже если они выбрали один cloud, они используют SaaS-приложения, у них есть бизнес-партнеры, которые могут работать в других cloud», — сказал он. — «Для компаний важно иметь единый уровень безопасности across clouds, across models».

Он также утверждал, что ландшафт угроз изменился настолько фундаментально, что старые модели защиты слишком медленны.

По его словам, среднее время между первоначальным взломом и переходом к следующему этапу атаки сократилось с восьми часов до 22 секунд, а поверхность атаки давно вышла за пределы традиционного сетевого периметра. «Помимо вашей обычной инфраструктуры, теперь у вас есть модели. У вас есть data pipelines, которые используются для обучения моделей. У вас есть agents, у вас есть prompts. Все это нужно защищать».

Одна угроза, на которую de Souza обратил внимание и о которой говорят недостаточно, — это то, что agents, перемещающиеся по внутренним системам компании, могут обнаруживать забытые хранилища данных, о которых никто не вспоминал годами. «У многих организаций есть старые SharePoint servers [и access controls], которые они давно не обновляли, но это не имело значения, потому что никто толком не знал, где они находятся. Но agents, путешествующие по вашей корпоративной среде, найдут эти data assets и раскроют данные на них».

Ответ, по его мнению, — отвечать машинной скорости машинной скоростью. «Сейчас мы видим появление AI-native, fully agentic defense, когда организации могут запускать agents, управляющих их защитой, — сказал он. — Вместо защиты, которой руководит человек, или даже human in the loop, теперь можно иметь людей, которые наблюдают за fully agentic defense». Он добавил, что это стало вопросом не только технологий, но и руководства. «Это вопрос уровня совета директоров и executive team. Это не только вопрос команды безопасности».

Но даже по мере того, как ИИ берет на себя все больше оборонительной работы, людей, способных надзирать за ней, не хватает — а уязвимости, которые сам ИИ привносит в систему, множатся быстрее, чем команды безопасности успевают их закрывать. «Нам понадобятся люди, чтобы справляться с bug-pocalypse», — сказала The New York Times на этой неделе chief information security officer LinkedIn Lea Kissner, добавив, что не ожидает, что индустрия сможет устойчиво и в долгую понять безопасность ИИ хотя бы в ближайшие несколько лет.

Это возвращает нас к самим поставщикам платформ. The Register в последние несколько недель опубликовал серию материалов о Google Cloud-разработчиках, которые получили счета на пятизначные суммы после несанкционированных API-вызовов к моделям Gemini — сервисам, которыми многие из них никогда не пользовались и которые не включали намеренно. Схема во всех случаях была похожей: API keys, изначально созданные для Google Maps и по инструкциям Google размещенные публично, после расширения их области действия Google тихо получили возможность обращаться к Gemini, хотя об этом изменении четко не сообщили.

Rod Danan, CEO платформы для подготовки к собеседованиям Prentus, сказал, что его счет достиг $10,138 примерно за 30 минут после того, как злоумышленники воспользовались его скомпрометированным API key. Isuru Fonseka, разработчик из Сиднея, чей аккаунт также был взломан, проснулся со списанием примерно AUD $17,000, хотя считал, что у него установлен лимит расходов в $250.

Ни один из них не знал, что автоматические системы Google повысили их billing tiers на основе истории аккаунта, подняв фактический потолок расходов до $100,000 без явного согласия.

После того как The Register опубликовал первоначальный материал, Google вернул деньги обоим. Тем не менее Google сообщил The Register, что не собирается менять политику автоматического повышения tier-уровней, заявив, что ставит предотвращение сбоев сервисов выше соблюдения заявленных пользователями бюджетных предпочтений.

Есть и отдельный вопрос о том, что происходит, когда разработчик пытается все отключить. The Register сообщил на этой неделе о исследовании компании Aikido, которое показало, что даже если разработчик обнаружит скомпрометированный key и немедленно удалит его, это все равно может не спасти. По данным Aikido, злоумышленники могут продолжать использовать такой key до 23 минут, потому что revocation в инфраструктуре Google распространяется постепенно. Исследователь Aikido Joseph Leon сказал The Register, что в этот промежуток поведение непредсказуемо — в некоторые минуты все еще проходит более 90% запросов — и злоумышленники могут использовать это время, чтобы выгрузить файлы и кэшированные данные разговоров из Gemini.

Leon также отметил, что у более новых форматов учетных данных Google, похоже, нет такой проблемы: API credentials service account отзываются примерно за пять секунд, а более новый формат key с префиксом AQ — примерно за минуту. «Оба работают в масштабе Google, — написал он в сопутствующей статье Aikido. — Оба указывают на то, что технически это решаемо и для Google API keys». Иными словами, по мнению Leon, 23-минутное окно — это не инженерное ограничение, а вопрос приоритетов компании.

Это стоит учитывать, читая советы de Souza: они разумны и к ним действительно нужно отнестись очень серьезно. Он не ошибается, но сейчас существует разрыв между тем, что платформы рекомендуют, и тем, как быстро они сами это реализуют, и об этом тоже полезно помнить.


Материал — перевод статьи с английского.

Оригинал: Everyone is navigating AI security in real time — even Google