ניהול ופריסה של כללי האבטחה ב-Firebase

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

לא משנה באיזה כלי משתמשים כדי להפעיל אותו, ה-API לניהול:

• קליטה של מקור כללים: קבוצת כללים, בדרך כלל קובץ קוד שמכיל הצהרות Firebase Security Rules.
• המערכת מאחסנת את המקור כקבוצת כללים קבועה.
• מערכת Rule Factory עוקבת אחרי הפריסה של כל קבוצת כללים בפריט תוכן. שירותים שמופעלים בהם כללי אבטחה של Firebase מחפשים את הגרסה של פרויקט כדי להעריך כל בקשה למשאב מאובטח.
• הכלי מאפשר להריץ בדיקות תחביריות וסמנטיות של קבוצת כללים.

שימוש ב-Firebase CLI

באמצעות Firebase CLI, אפשר להעלות מקורות מקומיים ולפרוס גרסאות. ה-CLI ‏Firebase Local Emulator Suite מאפשר לכם לבצע בדיקה מקומית מלאה של מקורות.

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

יצירת קובץ תצורה

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

Cloud Firestore

// Set up Firestore in your project directory, creates a .rules file
firebase init firestore

Realtime Database

// Set up Realtime Database in your project directory, creates a .rules file
firebase init database

Cloud Storage

// Set up Storage in your project directory, creates a .rules file
firebase init storage

עריכה ועדכון של הכללים

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

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

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

בדיקת העדכונים

‫Local Emulator Suite מספק אמולטורים לכל המוצרים שמופעלים בהם כללי אבטחה. מנוע כללי האבטחה של כל אמולטור מבצע הערכה תחבירית וסמנטית של הכללים, ולכן הוא עולה על הבדיקה התחבירית שמציע Security Rules management API.

אם אתם עובדים עם CLI, חבילת הכלים היא כלי מצוין לFirebase Security Rulesבדיקות. משתמשים ב-Local Emulator Suite כדי לבדוק את העדכונים באופן מקומי ולוודא ש-Rules של האפליקציה מתנהגים כמו שרוצים.

פריסת העדכונים

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

ב-Cloud Firestore Security Rules, כדי לשייך קבצי .rules למסדי הנתונים שמוגדרים כברירת מחדל ולמסדי נתונים נוספים עם שמות, צריך לבדוק ולעדכן את קובץ firebase.json.

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

Cloud Firestore

// Deploy rules for all databases configured in your firebase.json
firebase deploy --only firestore:rules

// Deploy rules for the specified database configured in your firebase.json
firebase deploy --only firestore:<databaseId>

Realtime Database

// Deploy your .rules file
firebase deploy --only database

Cloud Storage

// Deploy your .rules file
firebase deploy --only storage

שימוש במסוף Firebase

הערה: במסוף Firebase אפשר לפרוס את Cloud Firestore Security Rules למסד הנתונים שמוגדר כברירת מחדל בפרויקט. בעדכונים עתידיים, תוכלו לפרוס את Rules למסדי נתונים נוספים בפרויקט. אתם יכולים להשתמש ב-Firebase CLI כדי לעבוד עם Rules בפרויקטים שלכם עם כמה מסדי נתונים.

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

עריכה ועדכון של הכללים

1. פותחים את מסוף Firebase ובוחרים את הפרויקט.
2. לאחר מכן, בוחרים באפשרות Realtime Database, Cloud Firestore או אחסון בתפריט הניווט של המוצר, ואז לוחצים על כללים כדי לעבור אל כלי העריכה של Rules.
3. עורכים את הכללים ישירות בעורך.

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

בדיקת העדכונים

בנוסף לבדיקת התחביר בממשק המשתמש של העורך, אפשר לבדוק את ההתנהגות הסמנטית של Rules באמצעות מסד הנתונים ומשאבי האחסון של הפרויקט, ישירות במסוף Firebase באמצעות Rules Playground. פותחים את המסך Rules Playground בעורך Rules, משנים את ההגדרות ולוחצים על Run (הפעלה). מחפשים את הודעת האישור בחלק העליון של כלי העריכה.

פריסת העדכונים

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

שימוש ב-Admin SDK

הערה: בשלב הזה, Firebase Admin SDK תומך בפריסה של Cloud Firestore Security Rules למסד הנתונים שמוגדר כברירת מחדל בפרויקט. בעדכונים עתידיים, תוכלו לפרוס את Rules למסדי נתונים נוספים בפרויקט. אתם יכולים להשתמש ב-Firebase CLI כדי לעבוד עם Rules בפרויקטים שלכם עם כמה מסדי נתונים.

אפשר להשתמש ב-Admin SDK ל-Node.js rulesets. הגישה הפרוגרמטית מאפשרת לכם:

• הטמעה של כלים, סקריפטים, לוחות בקרה וצינורות CI/CD בהתאמה אישית לניהול כללים.
• לנהל כללים בקלות רבה יותר בכמה פרויקטים ב-Firebase.

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

חשוב לזכור גם שנדרשות כמה דקות עד שגרסאות Firebase Security Rules מתעדכנות באופן מלא. כשמשתמשים ב-Admin SDK כדי לפרוס כללים, חשוב להימנע ממרוץ תהליכים שבו האפליקציה מסתמכת באופן מיידי על כללים שהפריסה שלהם עדיין לא הושלמה. אם בתרחיש השימוש שלכם נדרשים עדכונים תכופים של כללי בקרת הגישה, כדאי לשקול פתרונות שמשתמשים ב-Cloud Firestore, שנועד לצמצם את מרוץ התהליכים למרות העדכונים התכופים.

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

חשוב גם לשים לב למגבלות הבאות:

• הכללים צריכים להיות קטנים מ-256KiB של טקסט בקידוד UTF-8 כשהם עוברים סריאליזציה.
• פרויקט יכול לכלול עד 2,500 ערכות כללים שמוטמעות בסך הכול. אחרי שמגיעים למגבלה הזו, צריך למחוק חלק מקבוצות הכללים הישנות לפני שיוצרים קבוצות כללים חדשות.

יצירה ופריסה של ערכות כללים Cloud Storage או Cloud Firestore

תהליך עבודה טיפוסי לניהול כללי אבטחה באמצעות Admin SDK יכול לכלול שלושה שלבים נפרדים:

1. יצירת מקור של קובץ כללים (אופציונלי)
2. יצירת קבוצת כללים
3. מפרסמים או פורסים את קבוצת הכללים החדשה

ה-SDK מספק שיטה לשילוב השלבים האלה בקריאה אחת ל-API עבור כללי אבטחה של Cloud Storage ו-Cloud Firestore. לדוגמה:

    const source = `service cloud.firestore {
      match /databases/{database}/documents {
        match /carts/{cartID} {
          allow create: if request.auth != null && request.auth.uid == request.resource.data.ownerUID;
          allow read, update, delete: if request.auth != null && request.auth.uid == resource.data.ownerUID;
        }
      }
    }`;
    // Alternatively, load rules from a file
    // const fs = require('fs');
    // const source = fs.readFileSync('path/to/firestore.rules', 'utf8');

    await admin.securityRules().releaseFirestoreRulesetFromSource(source);

אותו דפוס פועל עבור Cloud Storage כללים עם releaseFirestoreRulesetFromSource().

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

    const rf = admin.securityRules().createRulesFileFromSource('firestore.rules', source);
    const rs = await admin.securityRules().createRuleset(rf);
    await admin.securityRules().releaseFirestoreRuleset(rs);

עדכון של Realtime Database ערכות כללים

כדי לעדכן את קבוצות הכללים של Realtime Database באמצעות Admin SDK, משתמשים בשיטות getRules() ו-setRules() של admin.database. אפשר לאחזר קבוצות כללים בפורמט JSON או כמחרוזת עם הערות.

כדי לעדכן קבוצת כללים:

    const source = `{
      "rules": {
        "scores": {
          ".indexOn": "score",
          "$uid": {
            ".read": "$uid == auth.uid",
            ".write": "$uid == auth.uid"
          }
        }
      }
    }`;
    await admin.database().setRules(source);

ניהול של קבוצות כללים

כדי לעזור לכם לנהל קבוצות גדולות של כללים, Admin SDK מאפשר לכם להציג רשימה של כל הכללים הקיימים באמצעות admin.securityRules().listRulesetMetadata. לדוגמה:

    const allRulesets = [];
    let pageToken = null;
    while (true) {
      const result = await admin.securityRules().listRulesetMetadata(pageToken: pageToken);
      allRulesets.push(...result.rulesets);
      pageToken = result.nextPageToken;
      if (!pageToken) {
        break;
      }
    }

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

    const thirtyDays = new Date(Date.now() - THIRTY_DAYS_IN_MILLIS);
    const promises = [];
    allRulesets.forEach((rs) => {
      if (new Date(rs.createTime) < thirtyDays) {
        promises.push(admin.securityRules().deleteRuleset(rs.name));
      }
    });
    await Promise.all(promises);
    console.log(`Deleted ${promises.length} rulesets.`);

שימוש ב-API ל-REST

הכלים שמתוארים למעלה מתאימים למגוון תהליכי עבודה, כולל Firebase Security Rules ניהול של כמה מסדי נתונים Cloud Firestore בפרויקט, אבל יכול להיות שתרצו לנהל ולפרוס Firebase Security Rules באמצעות Management API עצמו. ה-API לניהול מספק את הגמישות הגדולה ביותר.

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

חשוב גם לשים לב למגבלות הבאות:

• הכללים צריכים להיות קטנים מ-256KiB של טקסט בקידוד UTF-8 כשהם עוברים סריאליזציה.
• פרויקט יכול לכלול עד 2,500 ערכות כללים שמוטמעות בסך הכול. אחרי שמגיעים למגבלה הזו, צריך למחוק חלק מקבוצות הכללים הישנות לפני שיוצרים קבוצות כללים חדשות.

יצירה ופריסה של ערכות כללים Cloud Firestore או Cloud Storage באמצעות REST

בדוגמאות שבקטע הזה נעשה שימוש ב-Firestore Rules, אבל הן רלוונטיות גם ל-Cloud Storage Rules.

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

השלבים האופייניים ליצירה ולפריסה של קבוצת כללים באמצעות Management API הם:

1. יצירת מקורות של קובצי כללים
2. יצירת קבוצת כללים
3. משחררים (פורסים) את קבוצת הכללים החדשה.

יצירת מקור

נניח שאתם עובדים על פרויקט Firebase מספר secure_commerce ורוצים לפרוס Cloud Firestore Rules מאובטח למסד נתונים בפרויקט בשם east_store.

אפשר להטמיע את הכללים האלה בקובץ firestore.rules.

service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if false;
    }
  }
}

יצירת קבוצת כללים

עכשיו, צריך ליצור טביעת אצבע בקידוד Base64 לקובץ הזה. אחר כך אפשר להשתמש במקור בקובץ הזה כדי לאכלס את מטען הייעודי (payload) שנדרש ליצירת קבוצת כללים באמצעות קריאת ה-REST‏ projects.rulesets.create. כאן, משתמשים בפקודה cat כדי להוסיף את התוכן של firestore.rules למטען הייעודי (payload) של בקשת ה-REST.

לצורך מעקב, כדי לשייך את זה למסד הנתונים של east_store, מגדירים את attachment_point לערך east_store.

curl -X POST -d '{
  "source": {
    "files": [
      {
        "content": "' $(cat storage.rules) '",
        "name": "firestore.rules",
        "fingerprint": <sha fingerprint>
      },
    "attachment_point": "firestore.googleapis.com/databases/east_store"
    ]
  }
}' 'https://firebaserules.googleapis.com/v1/projects/secure_commerce/rulesets'

ה-API מחזיר תגובת אימות ושם של קבוצת כללים, לדוגמה projects/secure_commerce/rulesets/uuid123.

השקה (פריסה) של קבוצת כללים

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

curl -X POST -d '{
  "name": "projects/secure_commerce/releases/cloud.firestore/east_store"  ,
  "rulesetName": "projects/secure_commerce/rulesets/uuid123"
}' 'https://firebaserules.googleapis.com/v1/projects/secure_commerce/releases'

הערה: כדי לפרסם במסד הנתונים (ברירת המחדל), הנתיב projects//releases/cloud.firestore/(default) שווה ל-projects//releases/cloud.firestore.

חשוב לדעת שנדרשות כמה דקות עד שגרסאות של Firebase Security Rules מתעדכנות באופן מלא. כשמשתמשים ב-REST API לניהול כדי לפרוס, חשוב להימנע ממצבי מירוץ שבהם האפליקציה מסתמכת באופן מיידי על כללים שהפריסה שלהם עדיין לא הושלמה.

עדכון של קבוצות כללים Realtime Database באמצעות REST

‫Realtime Database מספק ממשק REST משלו לניהול Rules. ניהול Firebase Realtime Database Rules באמצעות REST

ניהול של קבוצות כללים באמצעות REST

כדי לעזור בניהול פריסות גדולות של כללים, בנוסף ל-method של REST ליצירת קבוצות כללים וגרסאות, ה-API לניהול מספק methods ל:

• פירוט, קבלה ומחיקה של קבוצות כללים
• רשימה, קבלה ומחיקה של כללים מהדורות

בפריסות גדולות מאוד שמגיעות למגבלת 2,500 כללים לאורך זמן, אפשר ליצור לוגיקה למחיקת הכללים הכי ישנים במחזור זמן קבוע. לדוגמה, כדי למחוק את כל ערכות הכללים שנפרסו למשך יותר מ-30 יום, אפשר לקרוא לשיטה projects.rulesets.list, לנתח את רשימת אובייקטים בפורמט JSON Ruleset במפתחות createTime שלהם, ואז לקרוא לשיטה project.rulesets.delete בערכות הכללים המתאימות לפי ruleset_id.

בדיקת העדכונים באמצעות REST

בנוסף, Management API מאפשר לכם להריץ בדיקות תחביריות וסמנטיות במשאבי Cloud Firestore ו-Cloud Storage בפרויקטים שלכם בסביבת הייצור.

הערה: בדיקות שמופעלות באמצעות REST API משתמשות במסדי נתונים פעילים, בדלי אחסון ובמשאבים קשורים. יכול להיות שתחויבו על שימוש בחבילת הגלישה במהלך הבדיקה. אנחנו ממליצים מאוד להשתמש ב-Firebase Local Emulator Suite כדי לבצע בדיקות של Firebase Security Rules, כי אפשר להריץ בדיקות על משאבים לא מקוונים שאינם משאבי ייצור בלי לשלם על השימוש. אפשר לעיין במדריך שלנו בנושא בדיקת Firebase Security Rules באמצעות Local Emulator Suite.

בדיקה באמצעות הרכיב הזה של ה-API כוללת:

1. הגדרת אובייקט JSON‏ TestSuite לייצוג קבוצה של אובייקטים TestCase
2. שליחת TestSuite
3. ניתוח של TestResult אובייקטים שהוחזרו

נניח שרוצים להגדיר אובייקט TestSuite עם TestCase אחד בקובץ testcase.json. בדוגמה הזו, אנחנו מעבירים את Rulesשפת המקור בשורה עם מטען ה-REST, לצד חבילת הבדיקה להפעלה על הכללים האלה. אנחנו מציינים ציפייה להערכת כללים, ואת בקשת הלקוח שלפיה צריך לבדוק את קבוצת הכללים. אפשר גם לציין את רמת הפירוט של דוח הבדיקה באמצעות הערך FULL, כדי לציין שבדוח צריכות להיכלל תוצאות של כל הביטויים בשפה Rules, כולל ביטויים שלא תאמו לבקשה.

 {
  "source":
  {
    "files":
    [
      {
        "name": "firestore.rules",
        "content": "service cloud.firestore {
          match /databases/{database}/documents {
            match /users/{userId}{
              allow read: if (request.auth.uid == userId);
            }
            function doc(subpath) {
              return get(/databases/$(database)/documents/$(subpath)).data;
            }
            function isAccountOwner(accountId) {
              return request.auth.uid == accountId 
                  || doc(/users/$(request.auth.uid)).accountId == accountId;
            }
            match /licenses/{accountId} {
              allow read: if isAccountOwner(accountId);
            }
          }
        }"
      }
    ]
  },
  "testSuite":
  {
    "testCases":
    [
      {
        "expectation": "ALLOW",
        "request": {
           "auth": {"uid": "123"},
           "path": "/databases/(default)/documents/licenses/abcd",
           "method": "get"},
        "functionMocks": [
            {
            "function": "get",
            "args": [{"exact_value": "/databases/(default)/documents/users/123"}],
            "result": {"value": {"data": {"accountId": "abcd"}}}
            }
          ]
      }
    ]
  }
}

לאחר מכן נוכל לשלוח את TestSuite להערכה באמצעות השיטה projects.test.

curl -X POST -d '{
    ' $(cat testcase.json) '
}' 'https://firebaserules.googleapis.com/v1/projects/secure_commerce/rulesets/uuid123:test'

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

ניהול הרשאות לשימוש ב-Cloud Storage Security Rules בשירותים שונים

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

אם תחליטו להשבית את האבטחה הזו בין השירותים:

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

2. משתמשים בדף IAM במסוף Google Cloud כדי למחוק את התפקיד Firebase Rules Firestore Service Agent (סוכן שירות של Firebase Rules Firestore) לפי ההוראות במדריך Cloud לביטול תפקידים.

   הערה: בדף IAM, מסמנים את התיבה 'הכללת תפקידים שהוקצו על ידי Google' כדי לראות את כל התפקידים.
   הערה: בדף IAM, אמור להופיע חשבון השירות של Firebase Storage, עם מזהה שמסתיים ב[e-mail]. אם הכללים חוצי-השירותים מופעלים, התפקיד
   Firebase Rules Firestore Service Agent יופיע ברשימה.

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