הרשאות שרת MCP מעל Postgres ל-CRM עסקי: ארכיטקטורה בטוחה במקום SQL חופשי

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

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

למה חיבור SQL גולמי ב-MCP נכשל בתוך CRM עסקי

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

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

הפרדת גבולות בשרת ה-MCP: קריאה, טיוטה והצעת שינוי

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

גזירת זהות מהסשן המאומת ולא מארגומנטים של המודל

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

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

הגנת עומק עם Row-Level Security ב-Postgres

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

משתני הקשר מקומיים לטרנזקציה מעל מאגר חיבורים

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

הפרדה בין סינון שורות להסתרת עמודות רגישות

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

תרחיש סינתטי: טיפול מבוקר בבקשת שינוי של לקוח מרובה סניפים

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

1. קשירת זהות בטרנזקציה מבודדת: שרת ה-MCP מאמת את הסשן של מנהלת התיק, פותח טרנזקציה מוגבלת ומזריק את זהותה ואת התיקים המשויכים לה להקשר הטרנזקציה.
2. קריאה תחומה ונטרול הטקסט הזר: הסוכן מפעיל כלי קריאה עבור הלקוח הנוכחי בלבד, ותוכן המייל מסומן כטקסט מבקר לא מהימן. כל ניסיון לגשת לחברה הנוספת נחסם הן בשכבת השירות והן במדיניות ה-RLS.
3. הכנת הצעת שינוי מבוססת מקורות: במקום לערוך טבלאות ישירות, הסוכן מפעיל כלי הצעה שמייצר כרטיס החלטה עם קישור ישיר לשורות המייל ולתיעוד הביקור.
4. אישור אנושי ויומן ביקורת: מנהלת התיק בודקת את המקורות ומאשרת את ניתוב המשימות, וכל הפעולות נשמרות בטבלת ביקורת לקריאה והוספה בלבד.

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

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

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

יומן ביקורת ורשימת בדיקה הנדסית לפני עלייה לייצור

כשמתכננים תשתית כזאת במסגרת פיתוח סוכני AI ומערכות חכמות לעסקים, חמישה עקרונות שומרים על משילות הנתונים מהיום הראשון:

• תפקיד Postgres ייעודי ללא עקיפת RLS: חיבור עם הרשאות מינימליות ואכיפת RLS על כל טבלאות העסק.
• אפס כלי SQL פתוחים בתפעול: כל כלי עוטף שירות דומיין בדוק עם אימות סכמה ומגבלות שליפה.
• ניהול משתמשים ומפתחות מחוץ ל-MCP: ניהול הרשאות והנפקת מפתחות שמורים לממשק ניהול אנושי בלבד.
• בידוד קלט חיצוני בכל שדה: סימון כל טקסט מלקוח או מטופס חיצוני כתוכן לא מהימן.
• יומן ביקורת בלתי ניתן לדריסה: תיעוד המשתמש המאומת, סוג המפתח, שם הכלי, הרשומות שהושפעו והחלטת האישור.