מניעת תביעות ונזק מוניטין: אבטחת מסדי נתונים מול פגיעויות קוד AI (Supabase RLS)

הסיכון הקריטי: מדוע כלי בינה מלאכותית מדלגים על Row-Level Security#

מנגנון Row-Level Security (RLS) ב-PostgreSQL הוא שכבת ההגנה העליונה של מאגרי המידע שלכם בעבודה עם Supabase. כברירת מחדל, טבלאות חדשות ב-Supabase עלולות לחשוף פרופילי משתמשים, פרטי תשלום וסודות מסחריים לכל דורש דרך ממשק ה-PostREST הציבורי.

תוכנית עבודה להקשחה מלאה של בסיס הנתונים#

בצעו את הצעדים הבאים עבור כל טבלה ציבורית ב-Supabase:

-- שלב 1: הפעלת RLS על כל הטבלאות
ALTER TABLE public.profiles ENABLE ROW LEVEL SECURITY;
ALTER TABLE public.domains ENABLE ROW LEVEL SECURITY;
ALTER TABLE public.domain_tasks ENABLE ROW LEVEL SECURITY;

-- שלב 2: פוליסת קריאה מאובטחת של המשתמש בלבד
CREATE POLICY "משתמשים יכולים לצפות רק בפרופיל שלהם"
  ON public.profiles
  FOR SELECT
  USING (auth.uid() = id);

-- שלב 3: פוליסת עדכון מאובטחת של המשתמש בלבד
CREATE POLICY "משתמשים יכולים לעדכן רק את הפרופיל שלהם"
  ON public.profiles
  FOR UPDATE
  USING (auth.uid() = id)
  WITH CHECK (auth.uid() = id);

מניעת הסלמת הרשאות ורקורסיה בפוליסות#

1. 1
   **השתמשו ב-SECURITY INVOKER כברירת מחדל**: פונקציות ירוצו עם הרשאות המשתמש המבצע ויכבדו את כללי ה-RLS.
2. 2
   **הגדירו SET search_path = public בעבודה עם SECURITY DEFINER**: בעת יצירת טריגרים על הרשמת משתמשים, קבעו תמיד את נתיב החיפוש למניעת מתקפות search-path injection.
3. 3
   הימנעו מרקורסיה בפוליסות: לעולם אל תבצעו שאילתת SELECT לטבלת profiles מתוך פוליסה על profiles. השתמשו בפונקציית עזר is_admin() ייעודית.