"service account key.json: что это, почему опасно и как с этим работать"

Что такое service account key.json — кратко и по делу

Файл с именем key.json чаще всего ассоциируется с сервисными аккаунтами Google Cloud (формат JSON для ключей сервисного аккаунта). Это JSON-документ, который содержит набор полей (обычно 10 основных полей), включая закрытый ключ (private_key), идентификаторы клиента и аккаунта, URL-ы для OAuth и X.509 сертификаты. Обладатель такого файла может аутентифицироваться в API облачного провайдера от имени сервисного аккаунта и выполнять любые операции, на которые у этого аккаунта есть права.

Ключевые технические факты:

• Обычно в JSON ~10 значимых полей: type, project_id, private_key_id, private_key, client_email, client_id, auth_uri, token_uri, auth_provider_x509_cert_url, client_x509_cert_url.
• private_key — это PEM-строка RSA-ключа, стандартный размер — 2048 бит (иногда 4096).
• Токены доступа, полученные по этому ключу, живут коротко (обычно 1 час), но сам файл действует бессрочно, пока ключ не удалён или аккаунт не отключён.
• По умолчанию ключи сервисных аккаунтов не истекают автоматически — это свойство дает удобство, но увеличивает риск.

Почему это опасно — пошаговый сценарий атакующего

Если attacker получил key.json, он может: 1. Создать JWT и получить OAuth2 токен от имени сервисного аккаунта — доступ немедленный. 2. Вызывать любые API с правами аккаунта: читать хранилища, разворачивать VM, менять IAM-политику, запускать функции, экспортировать данные и т.д. 3. Использовать существующую инфраструктуру для дальнейшего распространения: развернуть майнер, exfiltrate данные, создать бекдоры.

Возможный ущерб зависит от прав аккаунта. Примеры:

• Если у аккаунта role/editor — attacker получает практически полный контроль над проектом.
• Если права минимальны (например, чтение одного bucket) — ущерб ограничен, но важные данные всё равно могут быть украдены.

Время действия:

• Получив ключ, злоумышленник может начать работу за 0–5 минут. Часто первые действия — проверка привилегий и поиск секретов.
• Восстановление контроля занимает дольше: удаление ключа и ротация — минуты, но полное исследование и устранение последствий может занять часы/дни.

Как находят key.json в репозиториях и на машинах — 6 проверенных методов

1. Статический поиск (grep): искать "gserviceaccount.com" или строку "-----BEGIN PRIVATE KEY-----" в репозиториях. - Команда: grep -R --include="*.json" -n "gserviceaccount.com" . 2. Поиск по истории Git: git log --all -S "gserviceaccount.com" — найдёт удалённые коммиты. 3. Инструменты типа gitleaks, truffleHog, git-secrets: автоматизируют поиск по паттернам и entropy-анализ. - gitleaks можно запускать в CI; он вернёт потенциально чувствительные файлы. 4. Просмотр публичных артефактов CI/CD: многие утечки происходят через артефакты сборки, где забыли .gitignore. 5. Поиск по публичным хранилищам объектов (например, случайно открытые GCS/S3): искать файлы с типичными именами key.json. 6. Локальный аудит: find / -type f -name "*key*.json" и проверка прав доступа (читаемость для сервисов, world-readable файлы).

Практические команды для управления ключами (Google Cloud)

• Создать новый ключ:
- gcloud iam service-accounts keys create key.json --iam-account=SA_EMAIL
• Перечислить ключи аккаунта:
- gcloud iam service-accounts keys list --iam-account=SA_EMAIL
• Удалить ключ по ID:
- gcloud iam service-accounts keys delete KEY_ID --iam-account=SA_EMAIL
• Отключить сервисный аккаунт (останавливает его использование):
- gcloud iam service-accounts disable SA_EMAIL

Эти команды — базовый набор для ротации / удаления компрометированных ключей.

Лучшие практики — что нужно сделать прямо сейчас (14 пунктов)

1. Минимизировать использование JSON-ключей: избегать long-lived keys вообще. 2. Использовать Workload Identity Federation или metadata server (GCE/GKE) — тогда ключи не нужны. 3. Принцип наименьших привилегий: выдавать роли с минимальными разрешениями (scoped roles), а не editor. 4. Ротация ключей каждые 90 дней — рекомендованная корпоративная практика (90 дней = industry common). 5. Ограничивать создание ключей через Organization Policy: разрешать создание ключей только избранным группам. 6. Использовать Secret Manager (GCP Secret Manager) с строгими ACL и audit-логами, а не хранить key.json в исходниках. 7. Включить мониторинг и оповещения: настроить alert на создание/удаление ключей и на необычные вызовы API. 8. Ограничить сеть: использовать VPC Service Controls и приватные endpoints, где возможно. 9. Отказываться от пользовательских long-lived refresh tokens — выдавать краткоживущие токены. 10. Проверять репозитории: добавить gitleaks в CI, запрет коммитов с секретами. 11. Обучение команд: инструкции не хранить ключи в .env, коде и публичных репо. 12. Использовать ключи с expiration, если провайдер позволяет (установить TTL при создании). 13. План реагирования: предусмотреть план на случай компрометации (см. ниже). 14. Логирование доступа к IAM: Audit Logs должны храниться и анализироваться (Retention зависит от политики; хранить минимум 90 дней для расследования).

Что делать при утечке key.json — пошаговый план реагирования (5 шагов)

1. Немедленно удалить/отозвать ключ: - gcloud iam service-accounts keys delete KEY_ID --iam-account=SA_EMAIL 2. Если есть риск, отключить сервисный аккаунт: - gcloud iam service-accounts disable SA_EMAIL 3. Проверить Audit Logs за последние 24–72 часа: какие API вызывались и с каких IP. - Важный фильтр: principalEmail=SA_EMAIL и timestamp. 4. Ротация прав: создать новый сервисный аккаунт с минимальными ролями и обменять ключи в приложениях. 5. Полное расследование: поиск других утечек (репозитории, артефакты CI), оценить объём доступа и восстановить целостность (например, сменить пароли, удалить артефакты, пересоздать сервисы).

Замечание: простое удаление key.json в репозитории не достаточно — нужно удалить ключ из системы и убедиться, что все токены больше не действуют (disable service account или удалить ключы).

Замена ключей: стратегия и автоматизация

• Рекоммендация: автоматизированная ротация. Пример: каждые 90 дней CI/CD создаёт новый ключ, проверяет работоспособность, переключает приложения, затем удаляет старые ключи.
• Используйте Infrastructure-as-Code (IaC): управление ключами и сервисными аккаунтами через Terraform / Deployment Manager с audit-логикой.
• Авто-тесты: после ротации запускайте smoke-tests, чтобы убедиться, что приложения могут получать токены и работать.

Альтернативы long-lived key.json — почему и как менять архитектуру

1. Workload Identity Federation: позволяет приложениям (например, на AWS/Azure/CI) обмениваться внешними учётными данными на Google-токены без JSON-ключей. 2. Metadata server: приложения в GCE/GKE используют metadata сервис и получают краткоживущие токены. 3. OAuth on-behalf-of: пользователи проходят OAuth, сервис получает токены с коротким TTL. 4. Secret Manager + IAM binding: хранение секретов централизовано с чётким контролем доступа.

Каждая из этих альтернатив уменьшает площадь атаки: вы управляете доступом, а не файлом.

Детекция и проактивный поиск — рекомендации по инструментам и метрикам

• Инструменты: gitleaks, truffleHog, git-secrets, detect-secrets, а также EDR и SIEM (Splunk, ELK).
• Регулярные проверки: сканирование всех репозиториев еженедельно; ретроспективный поиск по истории при найме новых подрядчиков.
• Метрики для наблюдения:

Вывод — кратко и чётко

Файл service account key.json — мощный инструмент для автоматизации в облаке, но одновременно и серьёзный вектор угроз. Его безопасность зависит от трёх вещей: архитектуры (избегать long-lived keys), процессов (ротация, least privilege, CI/CD сканы) и оперативного реагирования (удаление ключа, аудит, расследование).

Практическое правило: если можно работать без key.json — не создавайте его. Если не можете — строго ограничьте права, автоматизируйте ротацию (цель — каждые 90 дней или чаще) и держите мониторинг, который обнаружит подозрительную активность за первые минуты после компрометации.