"firebase adminsdk.json: что это, почему опасно и как защищать"

Что такое файл adminsdk.json (service account JSON)

adminsdk.json — неофициальное имя для JSON-файла служебного аккаунта (service account key), который используется Firebase Admin SDK для авторизации на серверах. По содержанию это стандартный Google Cloud service account key в формате JSON. Типичные поля:

• type — "service_account"
• project_id — идентификатор проекта
• private_key_id — ID приватного ключа
• private_key — приватный RSA-ключ, который используется для подписи JWT/OAuth-токенов
• client_email — email служебного аккаунта (например my-sa@appspot.gserviceaccount.com)
• client_id — ID клиента
• auth_uri, token_uri, и т.п.

Этот файл даёт приложению "право от имени" сервисного аккаунта обращаться к Firebase/Google API. На практике он часто хранится как serviceAccountKey.json, adminsdk.json или любой другой файл в бэкенде.

Почему утечка adminsdk.json — это серьёзно

Утечка такого JSON-файла эквивалентна компрометации ключа доступа с полномочиями, закреплёнными за сервис-аккаунтом. Последствия:

• 100% полномочий сервис-аккаунта: атакующий может читать/писать данные в Firestore/Realtime DB и Cloud Storage, управлять пользователями (создавать, удалять, выдавать права), выполнять функции Cloud Functions, изменять настройки проекта — в зависимости от назначенных ролей.
• Возможность выдавать JWT-токены (custom tokens), обходя механизм аутентификации приложения.
• Возможность списать данные, украсть PII, удалить бэкап, испортить приложения и инфраструктуру.

Факты и цифры: в 2020–2024 годах сотни инцидентов с утечками ключей происходили через публичные репозитории GitHub. По оценке разных аудитов, скомпрометированные сервис-аккаунты приводят к 4–7-значным потерям в зависимости от масштаба проекта.

Где и как получают adminsdk.json

Обычно файл получают в Google Cloud Console:

1. В Google Cloud Console → IAM & Admin → Service Accounts. 2. Создаёте сервис-аккаунт, назначаете роль(и). 3. На странице аккаунта → Keys → Create key → JSON → скачиваете файл.

Альтернативы генерации: gcloud CLI: gcloud iam service-accounts keys create key.json --iam-account=SERVICE_ACCOUNT_EMAIL

Важно: этот ключ — долгоживущий по умолчанию (до удаления). Поэтому хранение его в репозитории или публичном хранилище — ключевая ошибка.

Как правильно и безопасно использовать adminsdk.json

Основные практики защиты:

1. Никогда не храните JSON в публичных репозиториях. Проверяйте git-историю. 2. Не держите файл на клиенте (браузер, мобильные приложения). Только бэкенд. 3. Используйте минимальные права: принцип наименьших привилегий (least privilege). Создавайте сервис-аккаунт с конкретными ролями (например, только Firestore read/write и/или Firebase Auth admin), а не роль Owner/editor. 4. Избегайте долгоживущих ключей: используйте Workload Identity Federation (WIF) и Application Default Credentials (ADC) для GCP-сервисов — тогда ключи не нужны. 5. Храните секреты в секрет-менеджере: Google Secret Manager, HashiCorp Vault, AWS Secrets Manager, CI/CD secret storage. 6. Используйте переменные окружения или доступ к секретам через защищённые API, а не файлы в репозитории. 7. Ограничивайте доступ в IAM: кто может создавать ключи для сервис-аккаунтов — это отдельное право.

Пример инициализации Admin SDK в Node.js (без коммита файла в репо): const admin = require('firebase-admin'); const serviceAccount = JSON.parse(process.env.SERVICE_ACCOUNT_JSON); admin.initializeApp({ credential: admin.credential.cert(serviceAccount), databaseURL: 'https://PROJECT_ID.firebaseio.com' });

Лучше: при развёртывании на GCP (Cloud Run, GKE, Compute Engine) используйте персонаж-аккаунт (workload identity) и назначайте роли через IAM — тогда файл не нужен, SDK использует ADC автоматически.

Минимизация прав: пример подхода

Не давайте сервис-аккаунту роль Owner или Editor. Разбейте доступ:

• Для чтения/записи в Firestore: roles/datastore.user (в зависимости от потребностей)
• Для доступа к Firebase Auth: roles/firebaseauth.admin (или создать custom role, дающий только manageUsers)
• Для доступа к Storage: roles/storage.objectAdmin/roles/storage.objectViewer и т.д.

Если SDK нужен только для отправки push-уведомлений (FCM), выдайте только соответствующие права. В крупных проектах используйте кастомные роли: перечислите точные permission'ы, которые нужны, и дайте только их.

Ротация ключей и политики срока жизни

Рекомендуемая практика:

• Ротация ключей каждые 60–90 дней (зависит от вашей политики риска).
• Автоматизируйте процесс создания нового ключа, обновления окружений и удаления старого.
• Для CI/CD используйте short-lived credentials (WIF) вместо статичных JSON.

Команды gcloud:

• Создать ключ:
gcloud iam service-accounts keys create key.json --iam-account=SERVICE_ACCOUNT_EMAIL
• Список ключей:
gcloud iam service-accounts keys list --iam-account=SERVICE_ACCOUNT_EMAIL
• Удалить ключ:
gcloud iam service-accounts keys delete KEY_ID --iam-account=SERVICE_ACCOUNT_EMAIL

Примите политику: каждый новый релиз запускает проверку срока действия ключей и при необходимости — регенерацию.

Что делать при подозрении на утечку (пошагово)

1. Немедленно удалить скомпрометированный ключ: gcloud iam service-accounts keys delete KEY_ID --iam-account=SERVICE_ACCOUNT_EMAIL Или через Cloud Console → Service Account → Keys → Delete.

2. Создать новый ключ и обновить все окружения/CI/CD/серверы.

3. Проанализировать Audit Logs (Cloud Audit Logs) за действия сервис-аккаунта: - идентифицируйте IP-адреса - какие API использовали - какие данные были запрошены/изменены

Поиск в логах: в Log Explorer фильтр по resource.type="service_account" или по principalEmail=service-account@project.iam.gserviceaccount.com

4. Если есть подозрение на создание/изменение пользователей — откатите последствия: - Отмените сессии пользователей (revoke refresh tokens) для тех, чьи учётные записи могли быть скомпрометированы: auth.revokeRefreshTokens(uid) в Admin SDK. - Восстановите резервные копии данных, если есть удаление/изменение.

5. Проверьте CI/CD и репозитории на наличие других утечек (поиск по приватному ключу).

6. Проведите пост-инцидентный аудит доступа (кто мог создать ключ), введите ограничение на создание ключей и добавьте двухфакторную аутентификацию для учетных записей админов.

Обход долгоживущих ключей: Workload Identity и ADC

Workload Identity Federation позволяет приложениям извне GCP или в контейнерах получать временные креды без JSON-ключа. Преимущества:

• Нет долгоживущих секретов в репо/файлах.
• Креды короткоживущие, автоматически обновляются.
• Можно лимитировать происхождение запросов (identity pool, identity provider).

Для большинства CI/CD/Cloud Run/GKE рекомендуется настроить Workload Identity и привязать роль сервис-аккаунта к поду/сервису.

Контроль и автоматизация: инструменты и практики

• Сканирование репозиториев (git-secrets, truffleHog, gitleaks) — автоматический поиск ключей.
• Pre-commit hooks, политики PR, запрещающие конфиденциальные файлы.
• Использование Secret Manager и доступ по принципу least privilege.
• Мониторинг аудита: Alerts при срабатывании suspicious activity (необычные IP, массовые операции).
• Тестирование инцидент-ответа раз в квартал: сколько времени уйдёт на ротацию ключей и восстановление.

Итог: 10 практических рекомендаций

1. Никогда не коммитьте adminsdk.json в репозиторий. 2. Держите файл только на server-side, не на клиентах. 3. Применяйте принцип least privilege при назначении ролей сервис-аккаунту. 4. Используйте Workload Identity/ADC вместо долгоживущих JSON, когда возможно. 5. Храните секреты в Secret Manager или аналогах. 6. Ротация ключей — каждые 60–90 дней и при подозрении на утечку. 7. Автоматизируйте создание/удаление ключей и обновление окружений. 8. Включите аудит и алерты на подозрительную активность сервис-аккаунтов. 9. Проводите регулярные сканирования репозиториев и CI/CD на наличие секретов. 10. Имея инцидент, сразу удаляйте ключ, создавайте новый, анализируйте логи и отзывайте пользовательские токены при необходимости.

adminsdk.json — это не просто файл конфигурации, а ключ к вашему проекту. Отношение к нему должно быть как к секрету банковской карты: минимальный доступ, строгий контроль и план действий при инциденте. Соблюдение перечисленных практик существенно уменьшит шанс масштабной утечки и быстроту реакции в случае компрометации.