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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Там, где оперативность реагирования в реальном времени менее важна, структура функционирует в оборонительном режиме.

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

Понимание ключей API

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

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

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

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

Держите ключи сервера FCM в секрете

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пользовательская аутентификация: создание 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 , чтобы предотвратить атаки методом перебора. Вы можете сделать это на странице API в консоли Google Cloud .

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

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

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

Для дополнительной безопасности при входе вы можете добавить поддержку многофакторной аутентификации, выполнив обновление до Cloud Identity Platform . Ваш существующий код аутентификации 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 средства ведения журнала Cloud Functions , вы можете отслеживать и получать оповещения о необычном поведении, включая поведение, вызванное обновлениями библиотеки.

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

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

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

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

Зашифруйте конфиденциальную информацию

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

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

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

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