Aby chronić zasoby Firebase i dane użytkowników, postępuj zgodnie z tymi wskazówkami. Nie wszystkie elementy będą koniecznie dotyczyć Twoich wymagań, ale pamiętaj o nich podczas tworzenia aplikacji.
Unikanie nadużyć związanych z ruchem
Konfigurowanie monitorowania i alertów dotyczących usług backendu
Aby wykrywać nadużycia, takie jak ataki typu DoS, skonfiguruj monitorowanie i alerty dotyczące tych usług: Cloud Firestore, Realtime Database, Cloud Storage i Hosting.
Jeśli podejrzewasz atak na aplikację, jak najszybciej skontaktuj się z zespołem pomocy, aby poinformować go o zaistniałej sytuacji.
Włącz App Check
Aby mieć pewność, że tylko Twoje aplikacje będą miały dostęp do usług backendu, włącz Firebase App Check w przypadku każdej usługi, która to obsługuje.
Skonfiguruj Cloud Functions tak, aby skalował się w przypadku normalnego ruchu.
Cloud Functions automatycznie skaluje się, aby sprostać wymaganiom aplikacji, ale w przypadku ataku może to oznaczać wysoki rachunek. Aby temu zapobiec, możesz ograniczyć liczbę równoczesnych instancji funkcji na podstawie normalnego ruchu w aplikacji.
Skonfiguruj alerty, aby otrzymywać powiadomienia, gdy limity są bliskie osiągnięcia
Jeśli Twoja usługa ma skoki liczby żądań, często włączają się limity i automatycznie ograniczają ruch do Twojej aplikacji. Pamiętaj, aby monitorować panel Wykorzystanie i rozliczenia. Możesz też ustawić alerty budżetowe w projekcie, aby otrzymywać powiadomienia, gdy wykorzystanie zasobów przekroczy oczekiwania.
Zapobiegaj atakom typu DoS na własne usługi: testuj funkcje lokalnie za pomocą emulatorów
Podczas tworzenia kodu możesz przypadkowo spowodować atak typu DoS na własne urządzenieCloud Functions, np. tworząc nieskończoną pętlę wyzwalającą zapis. Aby zapobiec wpływowi tych błędów na usługi działające w czasie rzeczywistym, prowadź prace deweloperskie w Firebase Local Emulator Suite.
Jeśli przypadkowo spowodujesz atak typu DoS na własną funkcję, cofnij jej wdrożenie, usuwając ją z index.js, a następnie uruchamiając polecenie firebase deploy --only functions
W przypadku, gdy szybkość reakcji w czasie rzeczywistym jest mniej istotna, struktura działa defensywnie.
Jeśli nie musisz prezentować wyniku funkcji w czasie rzeczywistym, możesz ograniczyć nadużycia, przetwarzając wyniki w partiach: publikuj wyniki w temacie Pub/Sub i przetwarzaj je w regularnych odstępach czasu za pomocą zaplanowanej funkcji.
Informacje o kluczach interfejsu API
Klucze API do usług Firebase nie są tajne
Klucze interfejsu API usług Firebase tylko identyfikują Twój projekt w Firebase i aplikację w tych usługach. Autoryzacja jest obsługiwana za pomocą uprawnień Google Cloud, Firebase Security Rules i Firebase App Check.
Wszystkie klucze interfejsu API udostępniane przez Firebase są automatycznie ograniczone do interfejsów API związanych z Firebase. Jeśli konfiguracja aplikacji jest zgodna z wytycznymi na tej stronie, klucze interfejsu API ograniczone do usług Firebase nie muszą być traktowane jako tajne i można je bezpiecznie umieszczać w kodzie lub plikach konfiguracyjnych.
Konfigurowanie ograniczeń klucza interfejsu API
Jeśli używasz kluczy interfejsu API w przypadku innych usług Google, pamiętaj, aby zastosować ograniczenia klucza interfejsu API, aby ograniczyć zakres kluczy interfejsu API do klientów aplikacji i używanych interfejsów API.
Używaj kluczy interfejsu API udostępnionych przez Firebase tylko w przypadku interfejsów API związanych z Firebase. Jeśli Twoja aplikacja korzysta z innych interfejsów API (np. interfejsu Places API w Mapach lub Gemini Developer API), użyj osobnego klucza interfejsu API i ogranicz go do odpowiedniego interfejsu API.
Zachowaj FCM klucze serwera w tajemnicy
W przeciwieństwie do kluczy interfejsu API usług Firebase FCMklucze serwera (używane przez starszy FCM interfejs HTTP API) są poufne i muszą być utrzymywane w tajemnicy.
Zachowaj klucze kont usługi w tajemnicy
W przeciwieństwie do kluczy interfejsu API usług Firebase klucze prywatne kont usługi (używane przez Firebase Admin SDK) są poufne i muszą być utrzymywane w tajemnicy.
Firebase Security Rules
Inicjowanie reguł w trybie produkcyjnym lub trybie blokady
Podczas konfigurowania Cloud Firestore, Realtime Database i Cloud Storage zainicjuj Firebase Security Rules, aby domyślnie odrzucać wszystkie żądania dostępu, a następnie dodawaj reguły, które przyznają dostęp do określonych zasobów w miarę tworzenia aplikacji.
Użyj jednego z ustawień domyślnych dla nowych instancji Cloud Firestore (tryb produkcyjny) i Realtime Database (tryb blokady). W przypadku Cloud Storage zacznij od konfiguracji reguł bezpieczeństwa, takiej jak ta:
rules_version = '2';
service firebase.storage {
match /b/{bucket}/o {
match /{allPaths=**} {
allow read, write: if false;
}
}
}
Reguły zabezpieczeń to schemat. Dodawaj reguły podczas dodawania dokumentów.
Nie pisz reguł zabezpieczeń po napisaniu aplikacji jako zadania przed jej uruchomieniem. Zamiast tego pisz reguły zabezpieczeń w trakcie tworzenia aplikacji, traktując je jak schemat bazy danych: gdy tylko musisz użyć nowego typu dokumentu lub struktury ścieżki, najpierw napisz regułę zabezpieczeń.
Testowanie jednostkowe reguł zabezpieczeń za pomocą narzędzia Local Emulator Suite; dodawanie go do CI
Aby mieć pewność, że reguły bezpieczeństwa nadążają za rozwojem aplikacji, przetestuj je za pomocą Firebase Local Emulator Suite i dodaj te testy do potoku CI. Więcej informacji znajdziesz w tych przewodnikach:Cloud Firestore i Realtime Database.
Uwierzytelnianie
Uwierzytelnianie niestandardowe: generowanie tokenów JWT w zaufanym środowisku (po stronie serwera)
Jeśli masz już bezpieczny system logowania, np. system niestandardowy lub usługę innej firmy, możesz go używać do uwierzytelniania w usługach Firebase. Twórz niestandardowe tokeny JWT w zaufanym środowisku, a następnie przekazuj je do klienta, który używa ich do uwierzytelniania (iOS+, Android, Web, Unity, C++).
Przykład użycia niestandardowego uwierzytelniania z zewnętrznym dostawcą znajdziesz w tym artykule na blogu: Uwierzytelnianie w Firebase za pomocą Okty.
Uwierzytelnianie zarządzane: dostawcy OAuth 2.0 zapewniają największe bezpieczeństwo
Jeśli korzystasz z funkcji zarządzanego uwierzytelniania Firebase, najbezpieczniejsze są opcje dostawcy protokołu OAuth 2.0 / OpenID Connect (Google, Facebook itp.). Jeśli to możliwe, obsługuj co najmniej jednego z tych dostawców (w zależności od bazy użytkowników).
Uwierzytelnianie za pomocą adresu e-mail i hasła: ustaw ścisły limit dla punktu końcowego logowania, aby zapobiec atakom siłowym.
Jeśli korzystasz z zarządzanej przez Firebase usługi uwierzytelniania za pomocą adresu e-mail i hasła, zwiększ domyślny limit punktów końcowych identitytoolkit.googleapis.com, aby zapobiec atakom siłowym. Możesz to zrobić na stronie Identity Toolkit API w Google Cloud konsoli.
Uwierzytelnianie za pomocą adresu e-mail i hasła: włączanie ochrony przed wyliczaniem adresów e-mail
Jeśli korzystasz z zarządzanej przez Firebase usługi uwierzytelniania za pomocą adresu e-mail i hasła, włącz ochronę przed wyliczaniem adresów e-mail. Zapobiega ona wykorzystywaniu przez nieuczciwych podmiotów punktów końcowych uwierzytelniania w projekcie do odgadywania nazw kont.
Przejdź na Google Cloud Identity Platform, aby korzystać z uwierzytelniania wielopoziomowego
Aby zwiększyć bezpieczeństwo logowania, możesz dodać obsługę uwierzytelniania wielopoziomowego, przechodząc na Google Cloud Identity Platform. Po uaktualnieniu dotychczasowy kod Firebase Authentication nadal będzie działać.
Uwierzytelnianie anonimowe
Używaj anonimowego uwierzytelniania tylko w przypadku wprowadzania na ciepło
Uwierzytelnianie anonimowe służy tylko do zapisywania podstawowego stanu użytkowników przed zalogowaniem. Uwierzytelnianie anonimowe nie zastępuje logowania użytkownika.
Przekształcanie użytkowników na inną metodę logowania, jeśli chcą mieć dostęp do danych na innych urządzeniach
Anonimowe dane uwierzytelniające nie są zachowywane, jeśli użytkownik wyczyści pamięć lokalną lub zmieni urządzenie. Jeśli chcesz zachować dane po ponownym uruchomieniu aplikacji na jednym urządzeniu, przekształć konto użytkownika w konto stałe.
Używaj reguł zabezpieczeń, które wymagają od użytkowników przejścia na dostawcę logowania lub zweryfikowania adresu e-mail.
Każdy może utworzyć w Twoim projekcie konto anonimowe. Pamiętaj o tym, aby chronić wszystkie dane niepubliczne za pomocą reguł bezpieczeństwa, które wymagają określonych metod logowania lub zweryfikowanych adresów e-mail.
Przykład:
allow write: if request.auth.token.firebase.sign_in_provider != "anonymous";
allow write: if request.auth.token.email_verified = true;
Cloud Functions: zagranie bezpieczne
Nigdy nie umieszczaj informacji poufnych w zmiennych środowiskowych
W samodzielnie hostowanej aplikacji Node.js często używasz zmiennych środowiskowych do przechowywania informacji poufnych, takich jak klucze prywatne. Nie rób tego w Cloud Functions. Ponieważ Cloud Functions ponownie wykorzystuje środowiska między wywołaniami funkcji, w środowisku nie należy przechowywać informacji poufnych.
Aby przechowywać klucze interfejsu API Firebase (które nie są tajne), wystarczy umieścić je w kodzie.
Jeśli używasz Firebase Admin SDK w Cloud Functions, nie musisz podawać danych logowania konta usługi, ponieważ Admin SDK może je automatycznie uzyskać podczas inicjowania.
Jeśli wywołujesz interfejsy API Google i Google Cloud, które wymagają danych logowania konta usługi, biblioteka Google Auth dla Node.js może pobrać te dane logowania z domyślnych danych logowania aplikacji, które są automatycznie wypełniane w Cloud Functions.
Aby udostępnić klucze prywatne i dane logowania do usług innych niż Google w usłudze Cloud Functions, użyj Secret Manager.
Szyfrowanie informacji poufnych
Jeśli nie możesz uniknąć przekazywania informacji poufnych do funkcji, musisz opracować własne rozwiązanie do szyfrowania tych informacji.
Proste funkcje są bezpieczniejsze. Jeśli potrzebujesz bardziej złożonych funkcji, rozważ użycie Cloud Run
Staraj się, aby funkcje były jak najbardziej podstawowe i zrozumiałe. Złożoność funkcji może często prowadzić do trudnych do wykrycia błędów lub nieoczekiwanego działania.
Jeśli potrzebujesz złożonej logiki lub konfiguracji środowiska, użyj Cloud Run zamiast Cloud Functions.
Zarządzanie środowiskiem
Konfigurowanie projektów programistycznych i testowych
Skonfiguruj osobne projekty w Firebase na potrzeby programowania, testowania i produkcji. Nie scalaj kodu klienta z wersją produkcyjną, dopóki nie zostanie on przetestowany w projekcie przejściowym.
Ograniczanie dostępu zespołu do danych produkcyjnych
Jeśli pracujesz w większym zespole, możesz ograniczyć konsekwencje błędów i naruszeń bezpieczeństwa, ograniczając dostęp do danych produkcyjnych za pomocą wstępnie zdefiniowanych ról uprawnień lub niestandardowych ról uprawnień.
Jeśli Twój zespół używa Firebase Local Emulator Suite (zalecane) na potrzeby programowania, możesz nie musieć przyznawać szerszego dostępu do projektu produkcyjnego.
Zarządzanie biblioteką
Uważaj na błędy w pisowni bibliotek lub nowych opiekunów
Podczas dodawania bibliotek do projektu zwracaj szczególną uwagę na nazwę biblioteki i jej opiekunów. Biblioteka o podobnej nazwie do tej, którą chcesz zainstalować, może zawierać szkodliwy kod.
Nie aktualizuj bibliotek bez zrozumienia zmian
Przed uaktualnieniem przejrzyj dzienniki zmian wszystkich używanych bibliotek. Upewnij się, że uaktualnienie wnosi wartość, i sprawdź, czy osoba odpowiedzialna za utrzymanie jest nadal zaufaną stroną.
Instalowanie bibliotek watchdog jako zależności deweloperskich lub testowych
Użyj biblioteki takiej jak Snyk, aby przeskanować projekt pod kątem niezabezpieczonych zależności.
Skonfiguruj monitorowanie Cloud Functions i sprawdź je po aktualizacji biblioteki
Jeśli używasz Cloud Functionspakietu SDK rejestratora, możesz monitorować i otrzymywać alerty dotyczące nietypowych zachowań, w tym zachowań spowodowanych aktualizacjami bibliotek.