Mandiant · 15 июля 2026
Риск открытых cloud functions и как их ужесточить
15 июля 2026 Mandiant (Google Cloud) опубликовала разбор, как публично доступные serverless-функции без аутентификации становятся точкой входа в облако — и какие компенсирующие меры работают, когда сервис должен оставаться доступным из интернета.
контекст
Что произошло
По опыту security assessments Mandiant часто встречает публично выставленные serverless-приложения без аутентификации: так бывает из‑за бизнес‑требований, а не только из‑за забытой конфигурации. Код обычно самописный и тянет сторонние пакеты, поэтому на поверхности оказываются уязвимости уровня приложения — в том числе включение файлов и инъекции команд.
Успешный компромисс контейнера serverless может дать плацдарм: извлечение секретов из кода, разбор логики, обращение к metadata за токенами сервисных аккаунтов и дальнейший pivot. Материал фокусируется на Google Cloud Run и Cloud Functions, но принципы применимы к любому публичному FaaS.
зачем это важно
Кого это касается
Serverless лежит под e‑commerce, медиа, платежами и всё чаще под AI‑воркфлоу: чат‑боты, генерация, агенты. Рост «vibe coding» и быстрых деплоев увеличивает число публичных функций, которые никто не считает периметром.
Под удар попадают команды, где публичный Cloud Run обслуживает ненадёжных внешних клиентов в том же проекте, что и критичные ресурсы: изоляция сервисов становится обязательной, а не «nice to have».
угроза
Как развивается компромисс
После первичного доступа атакующий ищет секреты, чувствительные данные и пути эскалации. Без сегментации и least‑privilege IAM компромисс одной функции превращается в захват окружения.
Mandiant подчёркивает: даже если приложение остаётся публичным, нужны runtime‑контроли и архитектурные слои, которые ограничивают blast radius.
защита
Что делать защитникам
Параллельно: Secure SDLC (сканирование, code review, least‑privilege IAM в CI/CD) и runtime defense‑in‑depth. Публичные сервисы для внешних клиентов — в отдельном изолированном проекте («service project»), чтобы пробой не открывал немедленный путь к внутренним системам.
Ограничьте ingress до internal-only и вынесите интернет‑экспозицию на Layer 7 Application Load Balancer с Cloud Armor: централизованные SSL/заголовки, WAF, rate limiting. Секреты — не в коде, а в Secret Manager; для внутренних пользователей — Identity‑Aware Proxy где уместно. Для AI‑сгенерированного кода — песочницы, контроль egress и только проверенные IDE/плагины с минимальными правами.
Ниже — чеклист политики, который можно вставить в runbook облачной безопасности.
вывод
Итог для SOC и cloud‑команд
Публичный serverless — не «маленький скрипт», а периметр. Если бизнес требует открытости, компенсируйте её архитектурой: изоляция проектов, ALB+WAF, секреты вне кода, строгий IAM и непрерывный мониторинг логов.
Цель — чтобы уязвимость в одной функции не давала токены и доступ ко всему облаку.
# defensive checklist — public serverless / Cloud Run
# policy note for cloud security reviews (not attack guidance)
public_faas:
require_auth_or_compensating_controls: true
isolate_untrusted_workloads: separate_gcp_project
ingress: internal-only # internet via Layer-7 ALB + Cloud Armor
secrets: secret_manager # never hardcoded
iam: least_privilege_service_accounts
logging: forward_to_siem
ai_generated_code:
sandbox: required
approved_ides_only: true