רשימת בדיקה לאבטחת Firebase

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

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

הגדר ניטור והתראה עבור שירותי backend

כדי לזהות תנועה פוגענית, כגון התקפות מניעת שירות (DOS), הגדר ניטור והתראה עבור Cloud Firestore , מסד נתונים בזמן אמת , אחסון בענן ואירוח

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

אפשר בדיקת אפליקציות

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

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

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

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

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

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

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

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

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

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

הבן מפתחות API

מפתחות API עבור שירותי Firebase אינם סודיים

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

הגדר היקף מפתחות API

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

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

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

שמור את מפתחות חשבון השירות בסוד

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

כללי אבטחה

אתחול כללים במצב ייצור או נעילה

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

זו אחת מהגדרות ברירת המחדל עבור מופעים חדשים של Cloud Firestore (מצב ייצור) ומסד נתונים בזמן אמת (מצב נעול). בחר באפשרות זו בעת הגדרת מופע מסד נתונים חדש.

עבור Cloud Storage, התחל עם תצורת כללי אבטחה כמו הבאה:

rules_version = '2';
service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write: if false;
    }
  }
}

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

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

כללי אבטחה לבדיקת יחידות עם חבילת האמולטור; הוסף אותו ל-CI

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

אימות

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

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

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

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

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

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

אם אתה משתמש בשירות אימות סיסמת דוא"ל מנוהל של Firebase, הדק את מכסת ברירת המחדל של נקודות הקצה identitytoolkit.googleapis.com כדי למנוע התקפות של כוח גס. אתה יכול לעשות זאת מהדף של ממשק ה-API במסוף Google Cloud .

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

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

שדרג לפלטפורמת Cloud Identity לאימות מרובה גורמים

לאבטחה נוספת בכניסה, תוכל להוסיף תמיכה באימות רב-גורמי על ידי שדרוג ל- Cloud Identity Platform . קוד האימות הקיים של Firebase ימשיך לעבוד לאחר השדרוג.

אימות אנונימי

השתמש רק באימות אנונימי לכניסה חמה למטוס

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

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

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

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

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

לדוגמה:

allow write: if request.auth.token.firebase.sign_in_provider != "anonymous";
allow write: if request.auth.token.email_verified = true;

ניהול סביבה

הקמת פרויקטי פיתוח והקמה

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

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

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

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

ניהול ספרייה

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

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

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

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

התקן ספריות Watchdog כתלות במפתחים או בדיקות

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

הגדר ניטור עבור פונקציות; בדוק את זה לאחר עדכוני הספרייה

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

בטיחות פונקציית ענן

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

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

• כדי לאחסן מפתחות API של Firebase, שאינם סודיים , פשוט הטמע אותם בקוד.
• אם אתה משתמש ב-Firebase Admin SDK בפונקציה בענן, אינך צריך לספק אישורים מפורשים של חשבון שירות, מכיוון שה-SDK יכול לרכוש אותם באופן אוטומטי במהלך האתחול.
• אם אתה מתקשר לממשקי API של Google ו-Google Cloud הדורשים אישורי חשבון שירות, ספריית Google Auth עבור Node.js יכולה לקבל אישורים אלה מאישורי ברירת המחדל של היישום , אשר מאוכלסים אוטומטית ב-Cloud Functions.
• כדי להפוך מפתחות פרטיים ואישורים עבור שירותים שאינם של Google לזמינים לפונקציות הענן שלך, השתמש ב- Cloud Secret Manager .

הצפין מידע רגיש

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

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

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

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