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

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

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

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

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

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

הפעלה של App Check

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

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

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

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

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

  • חשוב לעקוב אחרי לוח הבקרה לשימוש ולחיוב.

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

  • אם אתם משתמשים ב-Firebase AI Logic,‏ Firebase App Hosting,‏ Cloud Functions for Firebase ו-Firebase Extensions, כדאי להגדיר מגבלות הוצאה כדי להשהות את השירות הרלוונטי אם הפרויקט יגיע לתקציב שהוגדר לשירות הזה.

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

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

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

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

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

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

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

מפתחות API לשירותי Firebase רק מזהים את הפרויקט והאפליקציה שלכם ב-Firebase בשירותים האלה. הרשאה מנוהלת באמצעות הרשאות IAM‏ Google Cloud,‏ 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 (שמשמשים את Firebase HTTP API מדור קודם) הם רגישים וחובה לשמור אותם בסודיות.FCM

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

בניגוד למפתחות 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,‏ 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 יכול לקבל אותם באופן אוטומטי במהלך האתחול.

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