רשימת משימות אבטחה ב-Firebase

כדי לשמור על האבטחה של המשאבים ב-Firebase והנתונים של המשתמשים, חשוב לפעול לפי ההנחיות הבאות. לא כל הפריטים רלוונטיים לדרישות שלכם, אבל כדאי לזכור אותם כשמפתחים את האפליקציה.

הימנעות מתנועה פוגעת

הגדרת מעקב והתראות לשירותי קצה עורפי

כדי לזהות תעבורת נתונים פוגעת, כמו התקפות מניעת שירות (DoS), צריך להגדיר מעקב והתראות לגבי Cloud Firestore, Realtime Database, Cloud Storage ו-Hosting.

אם אתם חושדים שהאפליקציה שלכם מותקפת, חשוב לפנות לתמיכה בהקדם האפשרי כדי לעדכן אותם במה שקורה.

מפעילים את App Check

כדי לוודא שרק האפליקציות שלכם יוכלו לגשת לשירותים לקצה העורפי, מפעילים את Firebase App Check בכל שירות שתומך בכך.

הגדרת Cloud Functions להרחבה בהתאם לתנועת גולשים רגילה

‫Cloud Functions מתרחב אוטומטית כדי לעמוד בדרישות של האפליקציה, אבל במקרה של מתקפה, זה יכול להוביל לחשבון גדול. כדי למנוע זאת, אפשר להגביל את מספר המופעים המקבילים של פונקציה על סמך תנועת הגולשים הרגילה באפליקציה.

הגדרת התראות כדי לקבל עדכון כשמתקרבים למגבלות

אם יש בשירות שלכם עליות פתאומיות במספר הבקשות, לרוב המכסות יופעלו והתנועה לאפליקציה תוגבל אוטומטית. חשוב לעקוב אחרי מרכז הבקרה לנתוני שימוש וחיוב, אבל אפשר גם להגדיר התראות לגבי התקציב בפרויקט כדי לקבל עדכון כשחורגים מהצפי לשימוש במשאבים.

מניעת התקפות מניעת שירות עצמיות: בדיקת פונקציות באופן מקומי באמצעות האמולטורים

במהלך הפיתוח של Cloud Functions, קל לגרום בטעות למתקפת מניעת שירות על עצמכם, למשל על ידי יצירת לולאה אינסופית של הפעלת טריגר וכתיבה. כדי למנוע מהטעויות האלה להשפיע על שירותים פעילים, כדאי לבצע את הפיתוח באמצעות Firebase Local Emulator Suite.

אם בטעות גרמתם לעצמכם מתקפת מניעת שירות, תוכלו לבטל את הפריסה של הפונקציה על ידי מחיקתה מ-index.js ואז הפעלת firebase deploy --only functions.

במקרים שבהם מהירות התגובה בזמן אמת פחות חשובה, פונקציית המבנה פועלת באופן מגן

אם לא צריך להציג את התוצאה של פונקציה בזמן אמת, אפשר לצמצם את הסיכון לתעבורת נתונים פוגעת על ידי עיבוד התוצאות באצווה: פרסום התוצאות בנושא Pub/Sub ועיבוד התוצאות במרווחי זמן קבועים באמצעות פונקציה מתוזמנת.

הסבר על מפתחות API

מפתחות API לשירותי Firebase הם לא סודיים

מפתחות API לשירותי Firebase רק מזהים את פרויקט Firebase והאפליקציה שלכם בשירותים האלה. הרשאה מנוהלת באמצעות Google Cloud הרשאות IAM,‏ Firebase Security Rules ו-Firebase App Check.

כל מפתחות ה-API שמוקצים ב-Firebase מוגבלים באופן אוטומטי לממשקי API שקשורים ל-Firebase. אם ההגדרה של האפליקציה שלכם תואמת להנחיות שבדף הזה, אז מפתחות API שמוגבלים לשירותי Firebase לא צריכים להיחשב כסודות, ואפשר לכלול אותם בקוד או בקובצי ההגדרה.

הגדרת הגבלות על מפתחות API

אם אתם משתמשים במפתחות API לשירותים אחרים של Google, הקפידו להחיל הגבלות על מפתחות API כדי להגדיר את היקף השימוש במפתחות ה-API ללקוחות האפליקציה ולממשקי ה-API שבהם אתם משתמשים.

משתמשים במפתחות API שהוקצו לכם ב-Firebase רק עבור ממשקי API שקשורים ל-Firebase. אם האפליקציה שלכם משתמשת בממשקי API אחרים (למשל, Places API for Maps או Gemini Developer API), צריך להשתמש במפתח API נפרד ולהגביל אותו ל-API הרלוונטי.

שמירה על סודיות של מפתחות השרת FCM

בניגוד למפתחות API לשירותי Firebase, מפתחות שרת של FCM (שמשמשים את legacy FCM HTTP API) הם רגישים וחובה לשמור אותם בסודיות.

שמירה על סודיות של מפתחות לחשבונות שירות

בניגוד למפתחות API לשירותי Firebase, מפתחות פרטיים של חשבונות שירות (שמשמשים את Firebase Admin SDK) הם רגישים וחובה לשמור אותם בסוד.

Firebase Security Rules

הפעלה של כללים בסביבת ייצור או במצב נעילה

כשמגדירים את Cloud Firestore, Realtime Database ו-Cloud Storage, מאתחלים את Firebase Security Rules כדי לחסום את כל הגישה כברירת מחדל, ומוסיפים כללים שמעניקים גישה למשאבים ספציפיים במהלך פיתוח האפליקציה.

אפשר להשתמש באחת מהגדרות ברירת המחדל למופעים חדשים של 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,‏ פייסבוק וכו'). מומלץ לתמוך באחד או יותר מהספקים האלה (בהתאם לבסיס המשתמשים שלכם).

אימות באמצעות אימייל וסיסמה: הגדרת מכסת שימוש מצומצמת לנקודת הקצה של הכניסה כדי למנוע התקפות ברוט פורס

אם אתם משתמשים בשירות המנוהל של 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 עושה שימוש חוזר בסביבות בין הפעלות של פונקציות, לא מומלץ לאחסן מידע רגיש בסביבה.

• כדי לאחסן מפתחות Firebase API (שהם לא סודיים), פשוט מטמיעים אותם בקוד.

• אם משתמשים ב-Firebase Admin SDK ב-Cloud Functions, לא צריך לספק במפורש את פרטי הכניסה של חשבון השירות, כי Admin SDK יכול לקבל אותם באופן אוטומטי במהלך האתחול.

• אם אתם קוראים לממשקי Google ו-Google Cloud API שמחייבים פרטי כניסה של חשבון שירות, ספריית האימות של Google ל-Node.js יכולה לקבל את פרטי הכניסה האלה מפרטי הכניסה שמוגדרים כברירת מחדל לאפליקציה, שמאוכלסים אוטומטית ב-Cloud Functions.

• כדי להפוך מפתחות פרטיים ופרטי כניסה לשירותים שאינם של Google לזמינים ל-Cloud Functions, צריך להשתמש ב-Secret Manager.

הצפנת מידע רגיש

אם אין ברירה אלא להעביר מידע רגיש לפונקציות, צריך ליצור פתרון מותאם אישית להצפנת המידע.

פונקציות פשוטות הן בטוחות יותר. אם אתם צריכים מורכבות, כדאי להשתמש ב-Cloud Run

כדאי לנסות לשמור על הפונקציות כמה שיותר בסיסיות וברורות. מורכבות בפונקציות עלולה לגרום לבאגים שקשה לזהות או להתנהגות לא צפויה.

אם אתם צריכים לוגיקה מורכבת או הגדרות סביבה, כדאי להשתמש ב-Cloud Run במקום ב-Cloud Functions.

ניהול סביבה

הגדרת פרויקטים של פיתוח ו-Staging

מגדירים פרויקטים נפרדים ב-Firebase לפיתוח, ל-Staging ולייצור. אל תמזגו את קוד הלקוח עם סביבת הייצור עד שתבדקו אותו מול פרויקט הביניים.

הגבלת הגישה של הצוות לנתוני הייצור

אם אתם עובדים בצוות גדול יותר, אתם יכולים לצמצם את ההשלכות של טעויות ופרצות אבטחה על ידי הגבלת הגישה לנתוני ייצור באמצעות תפקידים מוגדרים מראש ב-IAM או תפקידים בהתאמה אישית ב-IAM.

אם הצוות שלכם משתמש ב-Firebase Local Emulator Suite (מומלץ) לצורך פיתוח, יכול להיות שלא תצטרכו להעניק גישה רחבה יותר לפרויקט הייצור.

ניהול הספרייה

שימו לב לשגיאות כתיב בספרייה או למנהלים חדשים

כשמוסיפים ספריות לפרויקט, חשוב לשים לב לשם של הספרייה ולמי שמנהל אותה. ספרייה עם שם דומה לזה של הספרייה שרוצים להתקין עלולה להכיל קוד זדוני.

אל תעדכנו ספריות בלי להבין את השינויים

לפני שמשדרגים, כדאי לעיין ביומני השינויים של כל הספריות שבהן משתמשים. חשוב לוודא שהשדרוג מוסיף ערך, ולבדוק שהמפתח עדיין מהימן.

התקנת ספריות של watchdog כתלות בפיתוח או בבדיקה

אפשר להשתמש בספרייה כמו Snyk כדי לסרוק את הפרויקט ולחפש תלות לא מאובטחת.

הגדרת מעקב אחרי Cloud Functions; בדיקה אחרי עדכונים בספרייה

אם אתם משתמשים ב-Cloud Functions logger SDK, תוכלו לעקוב אחרי התנהגות חריגה ולקבל התראות עליה, כולל התנהגות שנגרמת בגלל עדכונים של ספריות.