Контрольный список мер по обеспечению безопасности Firebase

Чтобы защитить ресурсы Firebase и данные пользователей, следуйте приведенным ниже рекомендациям. Не все пункты могут быть применимы к вашим требованиям, но учитывайте их при разработке приложения.

Как избежать недействительного трафика

Настройте мониторинг и оповещения для бэкенд-служб

Чтобы обнаруживать подозрительный трафик, например DoS-атаки, настройте мониторинг и оповещения для Cloud Firestore, Realtime Database, Cloud Storage и Hosting.

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

Как включить App Check

Чтобы доступ к вашим бэкенд-службам был только у ваших приложений, включите Firebase App Check для всех служб, которые поддерживают эту функцию.

Настройте Cloud Functions для масштабирования при обычном трафике

Cloud Functions автоматически масштабируется в соответствии с потребностями вашего приложения, но в случае атаки это может привести к большим расходам. Чтобы этого не произошло, вы можете ограничить количество одновременно выполняемых экземпляров функции на основе обычного трафика вашего приложения.

Настройте оповещения о приближении к лимитам

Если в вашем сервисе наблюдаются пики запросов, часто начинают действовать квоты и трафик в ваше приложение автоматически ограничивается.

Как предотвратить DoS-атаки на собственные ресурсы: тестируйте функции локально с помощью эмуляторов

При разработке можно случайно вызвать DoS-атаку на собственный сервис, Cloud Functionsнапример создав бесконечный цикл триггеров и записей. Чтобы эти ошибки не повлияли на работу сервисов, используйте Firebase Local Emulator Suite.

Если вы случайно запустите DoS-атаку на свой проект, отмените развертывание функции, удалив ее из index.js, а затем выполните команду firebase deploy --only functions.

Если скорость ответа в реальном времени не так важна, используйте защитное программирование

Если вам не нужно представлять результат функции в реальном времени, вы можете снизить риск злоупотреблений, обрабатывая результаты пакетами: публикуйте результаты в теме Pub/Sub и обрабатывайте их через регулярные интервалы с помощью запланированной функции.

Что такое ключи API

Ключи API для сервисов Firebase не являются секретными

Ключи API для сервисов Firebase только идентифицируют ваш проект и приложение Firebase для этих сервисов. Авторизация выполняется с помощью разрешений IAM Google Cloud, Firebase Security Rules и Firebase App Check.

Для всех ключей API, предоставленных Firebase, автоматически устанавливаются ограничения на использование API, связанных с Firebase. Если ваше приложение настроено в соответствии с рекомендациями на этой странице, то ключи API, ограниченные сервисами Firebase, не нужно считать секретными. Их можно безопасно включать в код или файлы конфигурации.

Как настроить ограничения для ключа API

Если вы используете ключи API для других сервисов Google, убедитесь, что вы применили ограничения ключей API, чтобы ограничить их действие клиентами приложений и используемыми API.

Используйте ключи API, предоставленные Firebase, только для API, связанных с Firebase. Если ваше приложение использует другие API (например, Places API для Карт или Gemini Developer API), используйте отдельный ключ API и ограничьте его применимым API.

Храните ключи сервера FCM в секрете

В отличие от ключей API для сервисов Firebase, ключи сервера FCM (используемые устаревшим HTTP API FCM) являются конфиденциальными и должны храниться в секрете.

Как включить ведение журналов аудита для Cloud Messaging

Рекомендуем включить ведение журналов аудита Cloud для Cloud Messaging, чтобы регистрировать действия администратора и события доступа в ресурсах FCM.

Храните ключи сервисных аккаунтов в секрете

В отличие от ключей API для сервисов Firebase, закрытые ключи сервисных аккаунтов (используемые Firebase Admin SDK) являются конфиденциальными и должны храниться в секрете.

Firebase Security Rules

Инициализация правил в рабочем или заблокированном режиме

При настройке Cloud Firestore, Realtime Database и Cloud Storage инициализируйте Firebase Security Rules, чтобы по умолчанию запретить любой доступ, и добавляйте правила, предоставляющие доступ к определенным ресурсам по мере разработки приложения.

Используйте одну из настроек по умолчанию для новых экземпляров Cloud Firestore (рабочий режим) и Realtime Database (режим блокировки). Для Cloud Storage начните с конфигурации правил безопасности, например:

rules_version = '2';
service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write: if false;
    }
  }
}

Правила безопасности – это схема. Добавляйте правила при добавлении документов.

Не пишите правила безопасности после написания приложения, как своего рода задачу подготовки к запуску. Вместо этого пишите правила безопасности по мере создания приложения, рассматривая их как схему базы данных: каждый раз, когда вам нужно использовать новый тип документа или структуру пути, сначала напишите правило безопасности.

Проведите модульное тестирование правил безопасности с помощью Local Emulator Suite и добавьте его в CI.

Чтобы правила безопасности соответствовали разработке приложения, проведите модульное тестирование правил с помощью Firebase Local Emulator Suite и добавьте эти тесты в конвейер непрерывной интеграции. Ознакомьтесь с руководствами по Cloud Firestore и Realtime Database.

Аутентификация

Специальная аутентификация: создание JWT в доверенной среде (на стороне сервера)

Если у вас уже есть безопасная система входа, будь то пользовательская система или сторонняя служба, вы можете использовать существующую систему для аутентификации в службах Firebase. Создайте собственные JWT в доверенной среде, а затем передайте их клиенту, который будет использовать их для аутентификации (iOS+, Android, Web, Unity, C++).

Пример использования специальной аутентификации со сторонним поставщиком приведен в записи блога Аутентификация с помощью Firebase и Okta.

Управляемая аутентификация: поставщики OAuth 2.0 обеспечивают самый высокий уровень безопасности

Если вы используете функции управляемой аутентификации Firebase, то наиболее безопасными будут варианты поставщиков OAuth 2.0 / OpenID Connect (Google, Facebook и т. д.). По возможности поддерживайте одного или нескольких из этих поставщиков (в зависимости от вашей пользовательской базы).

Аутентификация по адресу электронной почты и паролю: установите строгую квоту для конечной точки входа, чтобы предотвратить атаки методом подбора.

Если вы используете управляемый сервис аутентификации по электронной почте и паролю Firebase, увеличьте квоту по умолчанию для конечных точек identitytoolkit.googleapis.com, чтобы предотвратить атаки методом перебора. Это можно сделать на странице Identity Toolkit API в консоли Google Cloud.

Аутентификация по адресу электронной почты и паролю: включите защиту от перебора адресов электронной почты

Если вы используете управляемый сервис аутентификации Firebase по электронной почте и паролю, включите защиту от перечисления адресов электронной почты. Это не позволит злоумышленникам использовать конечные точки аутентификации вашего проекта для угадывания названий аккаунтов.

Перейдите на версию Google Cloud Identity Platform, чтобы использовать многофакторную аутентификацию

Чтобы повысить безопасность при входе, вы можете добавить поддержку многофакторной аутентификации, перейдя на Google Cloud Identity Platform. После обновления существующий код Firebase Authentication продолжит работать.

Анонимная аутентификация

Используйте анонимную аутентификацию только для упрощенной регистрации

Используйте анонимную аутентификацию только для сохранения базового состояния пользователей до того, как они войдут в систему. Анонимная аутентификация не заменяет вход пользователя в аккаунт.

Как перевести пользователей на другой способ входа, если они хотят использовать свои данные на других устройствах

Анонимные данные аутентификации не сохраняются, если пользователь очищает локальное хранилище или меняет устройство. Если вам нужно сохранять данные после перезапуска приложения на одном устройстве, преобразуйте анонимный аккаунт в постоянный.

Используйте правила безопасности, требующие, чтобы пользователи перешли на поставщика услуг входа или подтвердили адрес электронной почты.

Любой пользователь может создать анонимный аккаунт в вашем проекте. Поэтому защитите все непубличные данные с помощью правил безопасности, требующих определенных способов входа или подтвержденных адресов электронной почты.

Пример:

allow write: if request.auth.token.firebase.sign_in_provider != "anonymous";
allow write: if request.auth.token.email_verified = true;

Cloud Functions: сейфти

Никогда не указывайте конфиденциальную информацию в переменных среды

В самостоятельно размещенном приложении Node.js часто используются переменные среды, содержащие конфиденциальную информацию, например закрытые ключи. Не делайте этого в Cloud Functions. Поскольку Cloud Functions повторно использует среды между вызовами функций, конфиденциальную информацию не следует хранить в среде.

  • Чтобы сохранить ключи Firebase API (которые не являются секретными), просто встройте их в код.

  • Если вы используете Firebase Admin SDK в Cloud Functions, вам не нужно явно указывать учетные данные сервисного аккаунта, поскольку Admin SDK может автоматически получить их во время инициализации.

  • Если вы вызываете API Google и Google Cloud, для которых требуются учетные данные сервисного аккаунта, библиотека Google Auth для Node.js может получить эти учетные данные из учетных данных приложения по умолчанию, которые автоматически заполняются в Cloud Functions.

  • Чтобы сделать закрытые ключи и учетные данные для сторонних сервисов доступными для Cloud Functions, используйте Secret Manager.

Шифрование конфиденциальной информации

Если вам необходимо передавать конфиденциальную информацию в функции, вам нужно разработать собственное решение для ее шифрования.

Простые функции безопаснее. Если вам нужны сложные, используйте Cloud Run.

Старайтесь, чтобы функции были как можно более простыми и понятными. Сложность функций часто приводит к трудно обнаруживаемым ошибкам или неожиданному поведению.

Если вам нужна сложная логика или конфигурация среды, используйте Cloud Run вместо Cloud Functions.

Управление средой

Настройте проекты для разработки и тестирования

Настройте отдельные проекты Firebase для разработки, подготовки и выпуска. Не объединяйте код клиента с рабочей средой, пока он не будет протестирован в промежуточном проекте.

Ограничьте доступ команды к рабочим данным

Если вы работаете в большой команде, вы можете снизить риск ошибок и утечек, ограничив доступ к производственным данным с помощью предопределенных ролей IAM или специальных ролей IAM.

Если ваша команда использует Firebase Local Emulator Suite (рекомендуется) для разработки, вам может не понадобиться предоставлять более широкий доступ к рабочему проекту.

Управление библиотекой

Остерегайтесь опечаток в названиях библиотек и новых разработчиков

При добавлении библиотек в проект внимательно следите за названием библиотеки и ее разработчиками. Библиотека с похожим названием может содержать вредоносный код.

Не обновляйте библиотеки, не разобравшись в изменениях

Перед обновлением изучите журналы изменений всех используемых библиотек. Убедитесь, что обновление добавляет ценность, и проверьте, что сопровождающий по-прежнему является стороной, которой вы доверяете.

Установите библиотеки сторожевого таймера как зависимости для разработки или тестирования

Используйте библиотеку, например Snyk, чтобы проверить проект на наличие небезопасных зависимостей.

Настройте мониторинг для Cloud Functions и проверьте его после обновления библиотеки.

Если вы используете Cloud Functions logger SDK, то можете отслеживать необычное поведение и получать уведомления о нем, в том числе о поведении, вызванном обновлениями библиотек.