Чтобы обеспечить безопасность ваших ресурсов Firebase и данных ваших пользователей, следуйте этим рекомендациям. Не каждый элемент обязательно будет соответствовать вашим требованиям, но помните о них при разработке приложения.
Избегайте оскорбительного трафика
Настройка мониторинга и оповещения для серверных служб
Чтобы обнаруживать неправомерный трафик, такой как атаки типа «отказ в обслуживании» (DOS), настройте мониторинг и оповещение для Cloud Firestore , базы данных в реальном времени , облачного хранилища и хостинга.
Если вы подозреваете атаку на ваше приложение, как можно скорее обратитесь в службу поддержки , чтобы сообщить им, что происходит.
Включить проверку приложений
Чтобы убедиться, что только ваши приложения могут получить доступ к вашим серверным службам, включите проверку приложений для каждой службы, которая ее поддерживает.
Настройте свои облачные функции для масштабирования для обычного трафика
Облачные функции автоматически масштабируются в соответствии с требованиями вашего приложения, но в случае атаки это может означать большой счет. Чтобы предотвратить это, вы можете ограничить количество одновременных экземпляров функции на основе обычного трафика для вашего приложения.
Настройте оповещение, чтобы получать уведомления, когда пределы почти достигнуты
Если у вашего сервиса бывают скачки запросов, часто срабатывают квоты и автоматически ограничивают трафик к вашему приложению. Обязательно следите за своей панелью управления использованием и выставлением счетов , но вы также можете настроить оповещения о бюджете в своем проекте, чтобы получать уведомления, когда использование ресурсов превышает ожидаемое.
Предотвратите самостоятельные DOS: проверяйте функции локально с помощью эмуляторов.
При разработке Cloud Functions можно легко случайно попасть в DOS: например, создав бесконечный цикл триггер-запись. Вы можете предотвратить влияние этих ошибок на работающие сервисы, выполняя разработку с помощью набора эмуляторов Firebase .
(И если вы случайно используете DOS самостоятельно, отмените развертывание своей функции, удалив ее из index.js , а затем запустив
Там, где реагирование в режиме реального времени менее важно, структура выполняет защитную функцию.
Если вам не нужно представлять результат функции в режиме реального времени, вы можете снизить нагрузку на неправомерный трафик, обрабатывая результаты пакетами: публикуйте результаты в теме 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 (рабочий режим) и базы данных реального времени (заблокированный режим). Выберите этот параметр при настройке нового экземпляра базы данных.
Для облачного хранилища начните с настройки правил безопасности, как показано ниже:
rules_version = '2';
service firebase.storage {
match /b/{bucket}/o {
match /{allPaths=**} {
allow read, write: if false;
}
}
}
Правила безопасности — это схема; добавлять правила при добавлении документов
Не пишите правила безопасности после того, как вы написали свое приложение, как своего рода задачу перед запуском. Вместо этого пишите правила безопасности при написании приложения, рассматривая их как схему базы данных: всякий раз, когда вам нужно использовать новый тип документа или структуру пути, сначала напишите соответствующее правило безопасности.
Правила безопасности модульного тестирования с помощью Emulator Suite; добавить его в КИ
Чтобы убедиться, что ваши правила безопасности не отстают от разработки вашего приложения, проведите модульное тестирование своих правил с помощью набора эмуляторов Firebase и добавьте эти тесты в конвейер CI. См. эти руководства для Cloud Firestore и базы данных в реальном времени .
Аутентификация
Пользовательская аутентификация: создайте 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 Console .
Аутентификация по паролю электронной почты: включить защиту перечисления электронной почты
Если вы используете управляемую службу проверки подлинности электронной почты и пароля Firebase, включите защиту перечисления электронной почты , которая не позволит злоумышленникам злоупотреблять конечными точками проверки подлинности вашего проекта для угадывания имен учетных записей.
Перейдите на платформу Cloud Identity для многофакторной аутентификации.
Для дополнительной безопасности при входе вы можете добавить поддержку многофакторной аутентификации, перейдя на платформу 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 средства ведения журнала Cloud Functions , вы можете отслеживать и получать уведомления о необычном поведении, в том числе о поведении, вызванном обновлениями библиотеки.
Безопасность облачных функций
Никогда не помещайте конфиденциальную информацию в переменные среды облачной функции.
Часто в собственном приложении Node.js вы используете переменные среды для хранения конфиденциальной информации, такой как закрытые ключи. Не делайте этого в Cloud Functions . Поскольку Cloud Functions повторно использует среды между вызовами функций, конфиденциальная информация не должна храниться в среде.
- Чтобы хранить ключи Firebase API, которые не являются секретными , просто вставьте их в код.
- Если вы используете Firebase Admin SDK в облачной функции, вам не нужно явно указывать учетные данные служебной учетной записи, поскольку SDK может автоматически получить их во время инициализации.
- Если вы вызываете Google и Google Cloud API, для которых требуются учетные данные сервисного аккаунта, библиотека Google Auth для Node.js может получить эти учетные данные из учетных данных приложения по умолчанию , которые автоматически заполняются в Cloud Functions.
- Чтобы сделать закрытые ключи и учетные данные для сторонних сервисов доступными для ваших облачных функций, используйте Cloud Secret Manager .
Шифрование конфиденциальной информации
Если вы не можете избежать передачи конфиденциальной информации в свою облачную функцию, вы должны придумать собственное решение для шифрования информации.
Простые функции безопаснее; если вам нужна сложность, рассмотрите Cloud Run
Старайтесь, чтобы ваши облачные функции были максимально простыми и понятными. Сложность ваших функций часто может привести к трудно обнаруживаемым ошибкам или неожиданному поведению.
Если вам нужна сложная логика или конфигурация среды, рассмотрите возможность использования Cloud Run вместо Cloud Functions.