Чтобы обеспечить безопасность ваших ресурсов Firebase и данных ваших пользователей, следуйте этим рекомендациям. Не каждый элемент обязательно будет соответствовать вашим требованиям, но имейте это в виду при разработке приложения.
Избегайте оскорбительного трафика
Настройка мониторинга и оповещений для серверных служб
Чтобы обнаружить неправомерный трафик, например атаки типа «отказ в обслуживании» (DOS), настройте мониторинг и оповещения для Cloud Firestore , Realtime Database , Cloud Storage и Hosting
Если вы подозреваете атаку на ваше приложение, как можно скорее обратитесь в службу поддержки, чтобы сообщить им, что происходит.
Включить App Check
Чтобы обеспечить доступ к серверным службам только вашим приложениям, включите Firebase App Check для каждой службы, которая ее поддерживает.
Настройте свои Cloud Functions для масштабирования для обычного трафика.
Cloud Functions автоматически масштабируются в соответствии с требованиями вашего приложения, но в случае атаки это может означать большие счета. Чтобы предотвратить это, вы можете ограничить количество одновременных экземпляров функции на основе обычного трафика вашего приложения.
Настройте оповещения, чтобы получать уведомления, когда лимиты почти достигнуты.
Если у вашего сервиса есть всплески запросов, часто срабатывают квоты и автоматически ограничивается трафик вашего приложения. Обязательно отслеживайте панель использования и выставления счетов , но вы также можете настроить оповещения о бюджете в своем проекте, чтобы получать уведомления, когда использование ресурсов превышает ожидания.
Предотвратите самостоятельные DOS: проверяйте функции локально с помощью эмуляторов.
При разработке Cloud Functions можно легко случайно получить DOS: например, создав бесконечный цикл записи триггера. Вы можете предотвратить влияние этих ошибок на работающие сервисы, выполняя разработку с помощью Firebase Local Emulator Suite .
А если вы случайно сделали DOS самостоятельно, отмените развертывание вашей функции, удалив ее из index.js и затем запустивfirebase deploy --only functions .
Там, где оперативность реагирования в реальном времени менее важна, структура функционирует в оборонительном режиме.
Если вам не нужно представлять результат функции в режиме реального времени, вы можете снизить уровень злоупотребления трафиком, обрабатывая результаты в пакетном режиме: публикуйте результаты в теме Pub/Sub и обрабатывайте результаты через регулярные промежутки времени с помощью запланированной функции. .
Понимание ключей API
Ключи API для сервисов Firebase не являются секретом
Firebase использует ключи API только для идентификации проекта Firebase вашего приложения для служб Firebase, а не для контроля доступа к базе данных или данным Cloud Storage , что осуществляется с помощью Firebase Security Rules . По этой причине вам не нужно относиться к ключам API для сервисов Firebase как к секретам, и вы можете безопасно встраивать их в клиентский код. Узнайте больше о ключах API для Firebase .
Настройте ограничения ключей API
В качестве дополнительного сдерживающего фактора против злоумышленника, пытающегося использовать ваш ключ API для подмены запросов, вы можете добавить ограничения на ключи API, чтобы ограничить доступ ваших ключей API к клиентам вашего приложения и используемым вами API.
Держите ключи сервера FCM в секрете
В отличие от ключей API для сервисов Firebase, ключи сервера FCM (используемые устаревшим HTTP API FCM ) конфиденциальны и должны храниться в секрете.
Храните ключи сервисных учетных записей в секрете
Кроме того, в отличие от ключей API для сервисов Firebase, закрытые ключи учетной записи службы (используемые Firebase Admin SDK ) являются конфиденциальными и должны храниться в секрете.
Firebase Security Rules
Инициализировать правила в рабочем или заблокированном режиме
При настройке Cloud Firestore , Realtime Database и Cloud Storage инициализируйте свои правила безопасности, чтобы запретить любой доступ по умолчанию, и добавьте правила, которые предоставляют доступ к определенным ресурсам по мере разработки приложения.
Используйте одну из настроек по умолчанию для новых экземпляров 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 и добавьте эти тесты в свой конвейер CI. См. эти руководства для 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 повторно используют среды между вызовами функций, конфиденциальная информация не должна храниться в среде.
Чтобы хранить ключи API Firebase (которые не являются секретными ), просто встройте их в код.
Если вы используете Firebase Admin SDK в Cloud Functions , вам не нужно явно указывать учетные данные сервисной учетной записи, поскольку Admin SDK может автоматически получить их во время инициализации.
Если вы вызываете API Google и Google Cloud , которым требуются учетные данные учетной записи службы, библиотека Google Auth для Node.js может получить эти учетные данные из учетных данных приложения по умолчанию , которые автоматически заполняются в Cloud Functions .
Чтобы сделать закрытые ключи и учетные данные для служб, не принадлежащих Google, доступными для ваших Cloud Functions , используйте Secret Manager .
Зашифруйте конфиденциальную информацию
Если вы не можете избежать передачи конфиденциальной информации в свои функции, вам необходимо придумать собственное решение для шифрования информации.
Простые функции безопаснее; если вам нужна сложность, рассмотрите Cloud Run
Постарайтесь, чтобы ваши функции были максимально простыми и понятными. Сложность функций часто может привести к трудно обнаруживаемым ошибкам или неожиданному поведению.
Если вам нужна сложная логика или конфигурации среды, рассмотрите возможность использования Cloud Run вместо Cloud Functions .
Управление окружающей средой
Настраивать разработку и реализацию проектов
Создайте отдельные проекты Firebase для разработки, подготовки и производства. Не объединяйте клиентский код с рабочей версией, пока он не будет проверен на тестовом проекте.
Ограничьте доступ команды к производственным данным
Если вы работаете с более крупной командой, вы можете смягчить последствия ошибок и нарушений, ограничив доступ к производственным данным с помощью предопределенных ролей IAM или пользовательских ролей IAM .
Если ваша команда использует для разработки Firebase Local Emulator Suite (рекомендуется) , вам, возможно, не потребуется предоставлять более широкий доступ к рабочему проекту.
Управление библиотекой
Следите за орфографическими ошибками в библиотеке или новыми сопровождающими.
Добавляя библиотеки в свой проект, обратите пристальное внимание на название библиотеки и ее сопровождающих. Библиотека с тем же именем, что и та, которую вы собираетесь установить, может содержать вредоносный код.
Не обновляйте библиотеки, не понимая изменений.
Перед обновлением просмотрите журналы изменений всех библиотек, которые вы используете. Убедитесь, что обновление повышает ценность, и убедитесь, что сопровождающий по-прежнему является стороной, которой вы доверяете.
Установите сторожевые библиотеки в качестве зависимостей разработки или тестирования.
Используйте библиотеку, такую как Snyk, для сканирования вашего проекта на наличие небезопасных зависимостей.
Настроить мониторинг Cloud Functions ; проверь это после обновлений библиотеки
Если вы используете SDK средства ведения журнала Cloud Functions , вы можете отслеживать и получать оповещения о необычном поведении, включая поведение, вызванное обновлениями библиотеки.