אבטחת מידע ב-MCP: המדריך המלא

למה אבטחה ב-MCP חשובה במיוחד?

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

עקרון 1: Least Privilege — הרשאות מינימליות

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

עקרון 2: אימות וזיהוי (Authentication)

כל חיבור בין הלקוח לשרת ה-MCP חייב לעבור אימות. אפשרויות: API Keys (בינונית, מתאים ל-POC), OAuth 2.0 (גבוהה, לפרודקשן), JWT (גבוהה, ל-microservices), ו-mTLS (מקסימלית, לפיננסים ורגולציה).

עקרון 3: הצפנה בכל שכבה

HTTPS/TLS 1.3 לכל חיבור חיצוני. mTLS או VPN לחיבורים פנימיים. הצפנת נתונים רגישים במצב מנוחה (at rest) עם AES-256.

עקרון 4: לוגים ומעקב (Auditing)

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

עקרון 5: הפרדת סביבות ורשתות

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

5 שכבות ההגנה של MCP

1. Least Privilege — הרשאות מינימליות לכל שרת
2. Authentication — אימות כל חיבור
3. Encryption — הצפנה in transit ו-at rest
4. Auditing — לוגים מלאים לכל פעולה
5. Isolation — הפרדת סביבות ורשתות

תאימות רגולטורית

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

סיכום

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