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

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

קל מאוד לגרום בטעות למתקפת מניעת שירות (DoS) בזמן הפיתוח של 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 למפות או Gemini Developer API), צריך להשתמש במפתח API נפרד ולהגביל אותו ל-API הרלוונטי.

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

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

הפעלת רישום ביומן ביקורת של Cloud Messaging

מומלץ להפעיל רישום ביומני ביקורת בענן עבור Cloud Messaging כדי שתוכלו לתעד פעילויות אדמין ואירועי גישה במשאבי 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

כדי לוודא שכללי האבטחה מתאימים לפיתוח של האפליקציה, כדאי לבצע בדיקת יחידה (unit test) של הכללים באמצעות Firebase Local Emulator Suite ולהוסיף את הבדיקות האלה לצינור עיבוד הנתונים של ה-CI. במדריכים האלה אפשר למצוא מידע על Cloud Firestore ועל Realtime Database.

אימות

אימות בהתאמה אישית: יצירת אסימוני JWT מסביבה מהימנה (בצד השרת)

אם כבר יש לכם מערכת כניסה מאובטחת, בין אם מדובר במערכת בהתאמה אישית או בשירות של צד שלישי, אתם יכולים להשתמש במערכת הקיימת כדי לבצע אימות בשירותי Firebase. יוצרים אסימוני JWT בהתאמה אישית בסביבה מהימנה, ואז מעבירים את האסימונים ללקוח, שמשתמש בהם לאימות (iOS+‎,‏ Android, ‏ אינטרנט,‏ Unity, ‏ C++‎).

דוגמה לשימוש באימות מותאם אישית עם ספק צד שלישי מופיעה בפוסט בבלוג אימות באמצעות Firebase באמצעות Okta.

אימות מנוהל: ספקי OAuth 2.0 הם המאובטחים ביותר

אם אתם משתמשים בתכונות האימות המנוהלות של Firebase, האפשרויות של ספקי OAuth 2.0 / OpenID Connect (כמו Google, פייסבוק וכו') הן המאובטחות ביותר. מומלץ לתמוך באחד או יותר מהספקים האלה (בהתאם לבסיס המשתמשים שלכם).

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

אם אתם משתמשים בשירות המנוהל של 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.

ניהול סביבה

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

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

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

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

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

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

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

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

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

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

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

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

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

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