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

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

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

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

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

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

הפעלה של App Check

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

הגדרת Cloud Functions כך שיפעלו על סמך תנועה רגילה

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

הגדרת התראות לקבלת התראה כשכמעט הגעת למגבלות

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

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

קל לגרום ל-DOS בטעות בזמן הפיתוח של Cloud Functions: לדוגמה, על ידי יצירת לולאה אינסופית של טריגר-כתיבה. כדי למנוע מהטעויות האלה להשפיע על שירותים פעילים, בפיתוח עם 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 (שבהם משתמשים API ל-HTTP 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;
    }
  }
}

כללי אבטחה הם סכימה; הוספת כללים כשמוסיפים מסמכים

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

כללי אבטחה של בדיקות יחידה (unit testing) עם Local Emulator Suite; הוספה ל-CI

כדי לוודא שכללי האבטחה שלך תואמים לפיתוח האפליקציה, לבדוק יחד את הכללים שלכם 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 אפשרויות הספקים של החיבור (Google, Facebook וכו') הן המאובטחות ביותר. אם אתם יכולים, כדאי שתתמכו באחד או יותר מהספקים האלה (בהתאם לבסיס המשתמשים שלכם).

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

אם אתם משתמשים בשירות המנוהל של 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 ולממשקי ה-API של Google Cloud שנדרשים להם חשבון שירות פרטי כניסה, ספריית Google Auth ל-Node.js יכולה לקבל את פרטי הכניסה מ- Application Default Credentials, שאוכלסו באופן אוטומטי ב-Cloud Functions.

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

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

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

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

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

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

ניהול סביבה

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

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

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

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

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

ניהול ספריות

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

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

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

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

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

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

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

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