כדי לשמור על אבטחת המשאבים ב-Firebase ועל נתוני המשתמשים, כדאי לפעול לפי ההנחיות הבאות. לא כל הפרטים רלוונטיים בהכרח לדרישות שלכם, אבל כדאי לזכור אותם במהלך הפיתוח של האפליקציה.
הימנעות מתנועה פוגעת
הגדרת מעקב והתראות לשירותי הקצה העורפי
כדי לזהות תנועה שמנוצלת לרעה, כמו התקפות מניעת שירות (DoS), צריך להגדיר מעקב והתראות לגבי Cloud Firestore, Realtime Database, Cloud Storage ו-Hosting
אם אתם חושדים שזוהי התקפה על האפליקציה, פנו לתמיכה בהקדם האפשרי כדי להודיע להם מה קורה.
מפעילים את App Check
כדי לוודא שרק האפליקציות שלכם יכולות לגשת לשירותים לקצה העורפי, צריך להפעיל את Firebase App Check בכל שירות שתומך בכך.
הגדרת Cloud Functions להתאמה לעומס תנועה רגיל
Cloud Functions מתאים את עצמו באופן אוטומטי לדרישות של האפליקציה, אבל במקרה של התקפה, יכול להיות שתקבלו חשבון גבוה. כדי למנוע זאת, אפשר להגביל את מספר המופעים בו-זמנית של פונקציה על סמך התנועה הרגילה באפליקציה.
מגדירים התראות כדי לקבל עדכון כשמגיעים כמעט למגבלות
אם בשירות שלכם יש עליות חדות במספר הבקשות, לרוב המכסות ייכנסו לתוקף והתנועה לאפליקציה תוגבל באופן אוטומטי. חשוב לעקוב אחרי מרכז הבקרה לנתוני שימוש וחיובים, אבל אפשר גם להגדיר התראות תקציב בפרויקט כדי לקבל התראות כשהשימוש במשאבים חורג מהציפיות.
מניעת התקפות מניעת שירות (DoS) עצמאיות: בדיקת פונקציות באופן מקומי באמצעות הסימולטורים
קל לגרום בטעות להתקפת מניעת שירות (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 (שמשמשים את 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, אינטרנט, 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 יכול לקבל אותם באופן אוטומטי במהלך האיפוס.
אם אתם קוראים לממשקי API של Google ו-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 ולייצור. אל תמזגו את קוד הלקוח לסביבת הייצור עד שהוא נבדק בפרויקט של סבב הבדיקה.
הגבלת הגישה של הצוות לנתוני הייצור
אם אתם עובדים עם צוות גדול יותר, תוכלו לצמצם את ההשלכות של טעויות ופגיעות על ידי הגבלת הגישה לנתוני הייצור באמצעות תפקידים מוגדרים מראש ב-IAM או תפקידים מותאמים אישית ב-IAM.
אם הצוות שלכם משתמש ב-Firebase Local Emulator Suite (מומלץ) לפיתוח, יכול להיות שלא תצטרכו להעניק גישה רחבה יותר לפרויקט הייצור.
ניהול הספרייה
היזהרו משגיאות איות בספרייה או ממנהלים חדשים
כשאתם מוסיפים ספריות לפרויקט, חשוב לשים לב לשם הספרייה ולמפתחים שלה. ספרייה עם שם דומה לשם של הספרייה שאתם מתכוונים להתקין עשויה להכיל קוד זדוני.
אל תעדכנו ספריות בלי להבין את השינויים
לפני השדרוג, כדאי לעיין ביומני השינויים של כל הספריות שבהן אתם משתמשים. חשוב לוודא שהשדרוג מוסיף ערך, ולוודא שהמפתח עדיין צד שאתם סומכים עליו.
התקנת ספריות watchdog כיחסי תלות לפיתוח או בדיקה
אפשר להשתמש בספרייה כמו Snyk כדי לסרוק את הפרויקט ולחפש בו יחסי תלות לא מאובטחים.
מגדירים מעקב אחרי Cloud Functions ובודקים אותו אחרי עדכוני הספרייה
אם אתם משתמשים ב-Cloud Functions logger SDK, תוכלו לעקוב אחרי התנהגות חריגה ולקבל התראות עליה, כולל התנהגות שנגרמת כתוצאה מעדכוני ספריות.