Tenant Isolation במערכות AI רב-דייריות: איך מונעים דליפת מידע בין לקוחות באותה תשתית

מאת צוות מדיה דיל · 08.08.2026 · Enterprise AI · 11 דק׳

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

התרחיש: כשההקשר של לקוח אחד מזלג ללקוח אחר

חברת SaaS מריצה עוזר AI ארגוני שמשרת עשרות לקוחות במקביל, כל אחד עם בסיס ידע (knowledge base) פרטי משלו. יום אחד, נציג של לקוח A שואל שאלה ומקבל בתשובה קטע מידע שמקורו במסמכים של לקוח B - תוצאה של שגיאה בשכבת ה-retrieval שלא סיננה נכון לפי tenant_id. זו לא תקלה תיאורטית - היא אחת הבעיות הנפוצות ביותר במערכות RAG רב-דייריות שנבנות מהר מדי בלי תכנון isolation קפדני. בניגוד ל-SaaS רגיל, שבו טעות isolation חושפת שורה במסד נתונים, במערכות AI ההשלכה חמורה יותר: המידע הדולף לא רק נחשף אלא גם 'משוקלל' לתוך תשובה שנראית טבעית ואמינה, מה שהופך את הזיהוי לקשה יותר וההשלכה המשפטית לחמורה יותר.

שכבות ה-Isolation שצריך להגן עליהן

Tenant Isolation במערכת AI צריך לחול על כמה שכבות בו-זמנית, ולא רק על מסד הנתונים הראשי. השכבה הראשונה היא ה-Vector Database - כל embedding חייב להיות מתויג עם tenant_id ומסונן במפורש בכל שאילתת retrieval. השכבה השנייה היא היסטוריית השיחות (conversation memory) - שיחה של tenant אחד לא יכולה לזלוג לקונטקסט של tenant אחר, גם לא באמצעות cache משותף. השכבה השלישית היא ה-prompt עצמו - system prompts מותאמים ללקוח, custom instructions, וכל תוכן שמוזרק דינמית ל-context. השכבה הרביעית, שלרוב נשכחת, היא הלוגים - לוגים שמכילים תוכן שיחות אמיתי הם עצמם דאטה רגיש שדורש אותה רמת isolation כמו הדאטה החי.

Row-Level Security מול Isolation ברמת האפליקציה

יש שתי גישות מרכזיות לאכיפת isolation: Row-Level Security (RLS) ברמת מסד הנתונים, שבו כל שאילתה מסוננת אוטומטית לפי tenant גם אם קוד האפליקציה שוכח לסנן במפורש, ואכיפה ברמת האפליקציה בלבד, שדורשת משמעת קוד מוחלטת. RLS, הזמין במסדי נתונים כמו PostgreSQL, נותן שכבת הגנה נוספת (defense in depth) שמונעת אסון גם כשמפתח שוכח תנאי WHERE - וזו טעות שקורית בפועל, במיוחד בקוד שנכתב מהר תחת לחץ דדליין.

ארכיטקטורות isolation: Pooled מול Siloed

ההחלטה הארכיטקטונית המרכזית היא רמת ה-isolation הפיזי. במודל Pooled (Shared), כל הלקוחות חולקים את אותה תשתית - מסד נתונים אחד, Vector DB אחד - עם סינון לוגי לפי tenant_id. זול לתפעול וקל לתחזוקה, אבל דורש משמעת קוד מוחלטת כי כל טעות סינון חושפת דאטה. במודל Siloed, לכל tenant יש מופע נפרד לגמרי - מסד נתונים נפרד, ולעיתים אפילו instance נפרד של השירות. יקר משמעותית יותר אבל מבטל את הסיכון לדליפה חוצת-tenant ברמה הארכיטקטונית. יש גם מודל ביניים, Hybrid, שבו לקוחות רגילים חולקים תשתית Pooled אך לקוחות Enterprise עם דרישות אבטחה מחמירות מקבלים Silo נפרד.

דוגמת קוד: אכיפת Isolation בשאילתת Retrieval

def retrieve_context(query_embedding, tenant_id, top_k=5):
    # סינון חובה ברמת השאילתה - לא ברמת הקוד המזמין
    results = vector_db.query(
        vector=query_embedding,
        filter={'tenant_id': {'$eq': tenant_id}},
        top_k=top_k
    )
    for r in results:
        assert r.metadata['tenant_id'] == tenant_id, 'ISOLATION BREACH DETECTED'
    return results

שימו לב לשורת ה-assert - זו שכבת בדיקה נוספת (defense in depth) שתופסת כשל isolation גם אם הפילטר עצמו נכשל מסיבה כלשהי, ומאפשרת להפעיל alert מיידי במקום לתת לדליפה לעבור בשקט.

בידוד בשכבת ה-Prompt וה-Context Window

היבט ייחודי ל-AI הוא הסיכון שדאטה מ-tenant אחד יזלוג דרך מנגנוני caching בצד הספק. אם אתם משתמשים ב-prompt caching כדי לחסוך עלויות, חובה לוודא שמפתח ה-cache כולל tenant_id כחלק מהזיהוי, אחרת קיים סיכון תיאורטי (תלוי במימוש הספק) שתוכן שמור מלקוח אחד ישפיע על תשובה ללקוח אחר. באופן דומה, אם משתמשים ב-fine-tuning או ב-few-shot examples ספציפיים ללקוח, יש לוודא שהם נטענים דינמית לפי tenant ולא נשמרים ב-cache גלובלי משותף.

בדיקות Isolation אוטומטיות

Tenant Isolation הוא בדיוק סוג הבעיה שדורש בדיקות אוטומטיות ייעודיות, לא רק code review. בדיקות isolation טובות יוצרות שני tenants מדומים עם דאטה ייחודי ומובחן לכל אחד, ומריצות שאילתות שמנסות לחלץ מידע חוצה-tenant בכוונה - סוג של בדיקת חדירה (penetration testing) פנימית שרצה כחלק מה-CI/CD בכל שינוי בשכבת ה-retrieval או ה-database. בדיקה כזו הייתה תופסת את התרחיש שתיארנו בפתיחה הרבה לפני שהוא הגיע ללקוח אמיתי.

טעויות נפוצות בפרודקשן

• הסתמכות על סינון ברמת האפליקציה בלבד בלי RLS כשכבת הגנה נוספת.
• שכחת סינון tenant_id בקוד דיבוג או endpoints פנימיים שלא עברו את אותה בדיקת קוד קפדנית.
• Cache משותף (Redis, prompt caching) בלי הפרדה מפורשת לפי tenant.
• לוגים שמכילים תוכן שיחות מלא בלי בקרת גישה נפרדת מה-production database.
• העדר בדיקות isolation אוטומטיות שרצות כחלק מתהליך הפיתוח השוטף.

מתי לבחור Pooled ומתי Siloed

עבור מוצר B2C או SMB עם דאטה בעל רגישות נמוכה יחסית, מודל Pooled עם isolation לוגי קפדני מספק איזון טוב בין עלות לאבטחה. עבור לקוחות Enterprise, גופים פיננסיים, או מערכות עם דאטה רפואי ורגיש, מודל Siloed או Hybrid הוא לרוב דרישה - הן מטעמי אבטחה אמיתיים והן מטעמי ציות רגולטורי שדורשים הפרדה מוכחת ומתועדת. ב-מדיה דיל אנחנו בונים בדרך כלל תשתית Hybrid שמתחילה Pooled ומאפשרת מעבר ל-Silo נקודתי ללקוחות ספציפיים בלי לשכתב את הארכיטקטורה כולה.

סיכום

Tenant Isolation במערכות AI רב-דייריות הוא הרבה יותר מסינון WHERE במסד נתונים - הוא נוגע לכל שכבה שבה דאטה זורם, כולל Vector DB, cache, ולוגים. בדיקות אוטומטיות ושכבות הגנה מרובות הן הדרך היחידה למנוע את התרחיש שבו טעות קטנה הופכת לדליפת מידע חוצת-לקוחות.

תגיות: Tenant Isolation · Multi-tenant AI · Row-Level Security · Vector Database Security · RAG Security · Data Privacy · SaaS Architecture

← חזרה לבלוג · צור קשר