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

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

Избегайте оскорбительного трафика

Настроить мониторинг и оповещения для серверных служб

Для обнаружения оскорбительного трафика, такие как отказ в обслуживании (DOS) атаки, созданный мониторинг и оповещение для облачных Firestore , в реальное время базов данных , Cloud Storage и хостинг

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

Включить проверку приложений

Для того, чтобы помочь обеспечить только ваши приложения могут получить доступ к серверным службам, включите App Check для каждой службы , которая поддерживает его.

Настройте свои облачные функции для масштабирования для нормального трафика

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

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

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

Предотвращение самодиагностики: тестируйте функции локально с помощью эмуляторов

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

(И если вы случайно DOS самостоятельно, отмените вашу функцию, удалив его из index.js затем работает firebase deploy --only functions .)

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

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

Понять ключи API

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

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

Настроить область действия ключа API

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

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

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

Хранить ключи сервисного аккаунта в секрете

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

Правила безопасности

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

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

Это одна из настроек по умолчанию для новых экземпляров Cloud Firestore (производственный режим) и Realtime Database (заблокированный режим). Выберите этот вариант при настройке нового экземпляра базы данных.

Для облачного хранилища начните с конфигурации правил безопасности, как показано ниже:

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

Правила безопасности - это схема; добавлять правила при добавлении документов

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

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

Для того, чтобы убедиться , что ваши правила безопасности в ногу с развитием вашего приложения, модульного тестирования ваших правил с эмулятором набором Firebase и добавить эти тесты для вашего CI трубопровода. Смотрите эти руководства для облачных Firestore и в реальном времени базы данных .

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

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

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

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

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

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

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

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

Переход на платформу Cloud Identity для многофакторной аутентификации

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

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

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

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

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

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

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

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

Например:

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

Управление окружающей средой

Настроить девелоперские и постановочные проекты

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

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

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

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

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

Остерегайтесь орфографических ошибок в библиотеке или новых сопровождающих

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

Не обновляйте библиотеки, не понимая изменений

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

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

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

Настроить мониторинг для функций; проверьте это после обновления библиотеки

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

Безопасность облачных функций

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

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

  • Для хранения ключей API Firebase, которые не секрет , просто вставлять их в коде.
  • Если вы используете Firebase Admin SDK в облачной функции, вам не нужно явно указывать учетные данные сервисной учетной записи, потому что SDK может автоматически получить их во время инициализации.
  • Если вы звоните Google и Google Cloud API , которые требуют учетных записей служб, библиотека Google Auth для Node.js может получить эти учетные данные из учетных данных по умолчанию приложения , которые автоматически заселенные в облаке функций.
  • Для того, чтобы закрытые ключи и учетные данные для служб , не Google , доступных для ваших функций Облака, используйте Облако Секретного менеджер .

Шифровать конфиденциальную информацию

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

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

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

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