כללי אבטחה לפעולות בצינור עיבוד נתונים

כללי אבטחה לפעולות בצינור עיבוד נתונים

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

דרישות לגבי המהדורה והמצב

המסמך הזה רלוונטי למהדורת Firestore Enterprise במצב Native.

ביטויי סינון נתמכים

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

• שוויון ואי-שוויון: eq, neq.
• השוואות: gt, gte, lt, lte.
• חברות במועדון: in, arrayContains.

הנה כמה דוגמאות:

• where(eq("foo", 2))
• where(lt("foo", 2))
• documents("/user/1", "/user/2").where(...)

הערה: ביטויים מורכבים, כמו פעולות חשבון בתוך מסנן (לדוגמה, where(eq("foo" * 2, 10))) או פונקציות של מחרוזות כמו strContains, לא מזוהים להגבלת שאילתות.

מאפייני הבקשה

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

מאפיינים נתמכים

המנוע החדש ממשיך לתמוך במאפיינים הבאים:

• request.auth: גישה לנתוני המזהה הייחודי (UID) והאסימון של המשתמש.
• ‫request.method: מזהה את הפעולה (לדוגמה, get, list).
• ‫request.path: הנתיב של המשאב שאליו ניגשים.
• ‫request.time: חותמת הזמן של הבקשה בצד השרת.

מאפיינים לא נתמכים

המאפיינים של request.query, כמו limit,‏ offset ו-orderBy, לא נתמכים בבדיקות של כללי Pipelines בגלל המורכבות של קביעת הערכים האלה בשאילתות עם כמה שלבים.

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

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

• הרשאות allow list: מופעלות בשלבים collection(),‏ collectionGroup() ו-database().
• הרשאות allow get: מופעלות על ידי השלב documents(), שמטופל באופן דומה לפעולת get באצווה.
• הרשאות allow create: מופעלות בשלבים insert() ובשלבים upsert() כשיוצרים מסמכים חדשים.
• הרשאות allow update: מופעלות בשלבים update(), ובשלבים upsert() כשמעדכנים מסמכים קיימים.
• הרשאות allow delete: מופעלות על ידי delete() שלבים.
• הרשאות allow write: חלות על כל פעולות ה-DML‏ (insert(),‏ update(),‏ upsert() ו-delete()).
• שלבי שינוי שדות: הכללים פועלים רק על נתונים מאוחסנים ולא על ערכים נגזרים. אם צינור עיבוד נתונים כולל שלבים שמשנים שדות (לדוגמה, AddFields, ReplaceWith, Select), מנוע הכללים מפסיק להחיל אילוצי סינון אחרי השלב הזה.
• שלב הליטרלים: השלב literals() לא קורא ממסד הנתונים, אבל יכול להיות שתחויבו בעלויות. כדי למנוע ניצול לרעה, צריך לשלב אותו עם שלב אחר (כמו collection()) שאפשר לאמת באמצעות כללים.

שלבי שפת טיפול בנתונים (DML) וכללי אבטחה

כשמבצעים שלבים של שפת טיפול בנתונים (DML) (insert(),‏ update(),‏ upsert() ו-delete()), כללי האבטחה מעריכים את ההרשאות באופן שונה מאשר בשאילתות קריאה:

• הערכת כללים לכל מסמך: בניגוד לצינורות עיבוד נתונים לקריאה, שדורשים ביטויי סינון מראש כדי להגביל את השאילתה בזמן התכנון, פעולות DML מעריכות את כללי האבטחה לכל מוטציה של מסמך בנפרד.
• משתני כללים:
  • ‫request.resource: מכיל את נתוני המסמך המוצעים לפעולות insert(), update() ו-upsert().
  • ‫resource: מכיל את נתוני המסמך הנוכחיים שמאוחסנים במסד הנתונים לפני השינוי (זמין ל-update(), ל-delete() ול-upsert() של מסמכים קיימים).

מגבלות המערכת והתנהגות ההרצה עם DML

כשמריצים פעולות DML עם כללי אבטחה, חשוב לזכור את מגבלות המערכת והתנהגויות ההרצה הבאות:

המגבלה של 20 חיפושים ב-get() וב-exists()

כללי האבטחה של Firebase מאפשרים עד 20 חיפושי מסמכים (get() או exists()) בכל הבקשה.

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

גם אם כללי האבטחה שלכם בודקים מסמך סטטי אחד, למשל, בודקים אם המשתמש הוא אדמין:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /posts/{postId} {
      allow write: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.isAdmin == true;
    }
  }
}

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

טיפ: כדי להימנע מהגעה למגבלה של 20 חיפושים בפעולות DML בכמות גדולה, השתמשו בהצהרות מותאמות אישית באסימונים של אימות ב-Firebase (לדוגמה, request.auth.token.isAdmin == true) במקום בחיפושים של get() או exists(). התביעות המותאמות אישית מאומתות בזיכרון ישירות מאסימון האימות, וכך נמנעות לחלוטין קריאות של מסמכים ומגבלות חיפוש.

הצלחה חלקית ו-PERMISSION_DENIED

כשמבצעים פעולות DML מחוץ לעסקה, הן מבצעות commit לכתיבות בקבוצות רציפות. אם אצווה נכשלת – בגלל שמסמך לא עומד בתנאי של כלל או בגלל חריגה ממגבלת 20 החיפושים – צינור עיבוד הנתונים נעצר ומוחזרת שגיאת PERMISSION_DENIED.

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

טיפ: אם עומס העבודה דורש ביצוע של הכל או כלום, כדאי להריץ את צינור עיבוד הנתונים של ה-DML בתוך טרנזקציית משתמש מפורשת (לדוגמה, באמצעות runTransaction ו-transaction.execute(pipeline)). בטרנזקציה, כל הפעולות מתבצעות יחד או מתבטלות לחלוטין במקרה של שגיאה. שימו לב שהעסקאות כפופות למגבלות העסקאות של מהדורת Firestore Enterprise.

אבחון כשלים בכללים באמצעות יומני הביקורת של Cloud

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

כדי לאבחן כשלים בהערכת כללים, מנהלי פרויקטים יכולים לבדוק את יומני הביקורת של Cloud במסוף Google Cloud (בקטע Firestore > Monitoring או ב-Logs Explorer) כדי לראות רשומות מפורטות של EvaluationError.