למה אבטחה ב-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
- Least Privilege — הרשאות מינימליות לכל שרת
- Authentication — אימות כל חיבור
- Encryption — הצפנה in transit ו-at rest
- Auditing — לוגים מלאים לכל פעולה
- Isolation — הפרדת סביבות ורשתות
תאימות רגולטורית
ארגונים ישראליים חייבים לעמוד בדרישות חוק הגנת הפרטיות: עיבוד מידע אישי רק בהסכמה, נתונים בשליטת הארגון, מנגנון למחיקת מידע, ומסמכי מדיניות מעודכנים.
סיכום
אבטחת MCP אינה אופציה — היא חלק בלתי נפרד מכל פריסה. חשבו על כל שרת MCP כעובד חדש בארגון — תנו לו רק את ההרשאות שהוא צריך, בדקו את הפעולות שלו, וסקרו את ההרשאות שלו מדי רבעון.
