RLS (Row-Level Security)
RLS היא טכנולוגיה לאבטחת מסד נתונים שמבטיחה שכל שורה במסד נגישה רק למשתמש/tenant הנכון. ב-Supabase (ובסיסי PostgreSQL), RLS מיושם ברמת הדטהבייס — לא ברמת האפליקציה — מה שמספק שכבת אבטחה נוספת.
Row-Level Security (RLS) הוא מנגנון אבטחה ברמת שורה, מובנה במסדי נתונים מבוססי PostgreSQL, שקובע אילו שורות בטבלה כל משתמש מורשה לראות, להוסיף, לעדכן או למחוק. במקום להסתמך רק על לוגיקת האפליקציה כדי לסנן נתונים לפי הרשאה, RLS אוכף את הכלל ישירות במסד הנתונים באמצעות "policies" (מדיניות) שמוגדרות פעם אחת ותקפות בכל שאילתה, מכל מקור — גם אם מישהו ניגש למסד ישירות. זה קריטי במיוחד בארכיטקטורת multi-tenant, שבה כמה ארגונים חולקים את אותו מסד נתונים אך חייבים בידוד מוחלט זה מזה. הטעות הנפוצה ביותר היא לסמוך רק על סינון ברמת קוד השרת ("WHERE tenant_id = ..." בכל שאילתה) — טעות אנוש אחת בשאילתה אחת חושפת נתונים של tenant אחר. ב-StoreChart, RLS מיושם דרך Supabase ומבטיח בידוד מוחלט בין tenants ברמת מסד הנתונים עצמו — שכבת הגנה שנשארת תקפה גם אם יש באג בקוד האפליקציה.
דרך קונקרטית לראות למה RLS חשוב: דמיינו באג באפליקציה שבטעות משמיט תנאי "WHERE tenant_id = current_tenant" משאילתת דוח אחת. בלי RLS, השורה החסרה הבודדת הזו חושפת את הנתונים של כל דייר דרך אותו דוח. עם RLS נאכף ברמת מסד הנתונים, מסד הנתונים עצמו דוחה או מסנן בשקט שורות שהחיבור לא מורשה לראות, ללא קשר למה שקוד האפליקציה כלל או לא כלל — הופך באג דליפת נתונים קריטי ללא-אירוע. לכן RLS נחשב להגנה בעומק: הוא לא מחליף קוד אפליקציה זהיר, אבל הוא אומר שטעות אחת בשאילתה אחת לא יכולה לחשוף את כל מערך הנתונים.
RLS מובן הכי טוב כשכבת אכיפה שנייה ועצמאית מתחת לקוד האפליקציה — אפילו אם מפתח כותב שאילתה ששוכחת להגביל לפי דייר, מסד הנתונים עצמו מסרב להחזיר שורות שהסשן הנוכחי לא מורשה לראות. הגישה הזו של הגנה מרובת שכבות היא בדיוק הסיבה שפלטפורמות שמטפלות בנתונים רב-דייריים רגישים (רשומות פיננסיות, מידע מזהה של לקוח, היסטוריית הזמנות) מתייחסות יותר ויותר ל-RLS כדרישת בסיס ולא צעד חיזוק אופציונלי, מכיוון שטעויות בשכבת אפליקציה נפוצות אך שכבת מסד הנתונים לעיתים רחוקות משקרת.
לעסק שמעריך פלטפורמת SaaS כדי לבטוח בה עם נתונים פיננסיים או נתוני לקוח, לשאול במפורש האם Row-Level Security נכפה בשכבת מסד הנתונים, ולא רק בקוד אפליקציה, היא שאלת בדיקת נאותות לגיטימית ונפוצה יותר ויותר ששווה לשאול לפני הרשמה.
שאלות נפוצות
יש עלות ביצועים קטנה מכיוון שמדיניות מוערכת בכל שאילתה, אבל מדיניות עם אינדקס טוב (בדרך כלל מסננת על עמודת tenant_id מאונדקסת) מוסיפה תקורה זניחה לעומת התועלת האבטחתית, ומתכנני שאילתות מודרניים של Postgres מייעלים מדיניות RLS ביעילות.
זו תכונה כללית של PostgreSQL — Supabase חושף ומתעד אותה באופן בולט כי היא מתאימה באופן טבעי למודל הגישה הישירה למסד הנתונים של Supabase, אבל כל מסד נתונים PostgreSQL יכול להגדיר ולאכוף מדיניות RLS.
כן — מדיניות RLS בדרך כלל לא חלה על משתמש-על של מסד הנתונים או חיבור בתפקיד שירות מעצם התכנון, מכיוון שמשימות backend לפעמים צריכות גישה חוצת-דיירים. זה הופך לקריטי לשמור על פרטי תפקיד השירות מוגבלים בקפדנות לקוד backend מהימן בלבד, ולעולם לא חשופים ללקוח.