שער MCP לעומת אבטחה MCP: מה שער מכסה
שער בודק גישה ומתעד את בקשות הסוכן שהוא מקבל. ראה באילו סיכוני אבטחה MCP היא מטפלת ובאילו עדיין יש צורך בבקרות אחרות.
ההחלטה בקצרה
שער עבור MCP הוא נקודת ביקורת על הנתיב בין לקוחות AI והכלים שהם משתמשים בהם. עבור הבקשות שהוא מקבל, הוא יכול לבדוק מי שואל, להחיל כללי גישה, לשמור אישורים נפרדים, לעצור כלים שלא נבדקו, לנתב שינויים רגישים לבדיקה ולתעד מה קרה. אבטחת MCP היא העבודה הרחבה יותר: היא מכסה גם הזרקה מהירה, הקוד של כל שרת, שרתים מקומיים במחשבים ניידים וכל נתיב שעוקף את השער. רוב הצוותים צריכים שער ושאר הפקדים יחד.
התשובה הקצרה
פרוטוקול ה-Model Context (MCP) מחבר לקוחות AI, כגון Claude Code או Cursor, לשרתים המציעים כלים: חיפוש תור כרטיסים, קריאת קובץ, עדכון רשומת לקוח. שער יושב בין אותם לקוחות לשרתים. לקוחות מתחברים לנקודת קצה אחת מבוקרת, והשער בודק כל בקשה לפני שהוא מעביר אותה.
אבטחת MCP רחבה יותר. הוא מכסה כל דרך שבה שימוש בכלי סוכן יכול להשתבש: המודל העוקב אחר הוראות מוסתרות בתוכן, שרת שהכלים שלו אינם מה שהם טוענים, אסימון בשימוש היכן שהוא לא אמור להיות, סוכן עם יותר גישה ממה שהמשימה שלו צריכה, או חיבור שאיש לא ידע על קיומו.
אז ההשוואה היא פחות על שני מוצרים מאשר על היקף. שער הוא שליטה אחת בתוך האבטחה MCP, ואחת חזקה לבקשות שהוא מקבל. השאלה היא באילו סיכונים היא מטפלת בפריסה שלך ומי הבעלים של השאר.
היכן מטופל כל סיכון אבטחה MCP
שני מקורות נותנים רשימת התחלה טובה. שיטות האבטחה המומלצות של MCP מתארות התקפות ספציפיות לפרוטוקול, כגון העברת אסימונים ובעיות סגן מבולבל. ה-MCP Top 10 של OWASP, פרויקט בטא בזמן כתיבת שורות אלו, מקבץ את הסיכונים העיקריים לעשר קטגוריות.
הטבלה ממפה את עשר הקטגוריות האלה למה ששער יכול לתרום ומה צריך להגיע ממקום אחר. השתמש בו כנקודת התחלה לסקירה משלך, ובדוק כל שורה שאתה תלוי בה.
| סיכון | מה ששער יכול לעשות | מה עוד צריך |
|---|---|---|
| ניהול כושל סמלי וחשיפה סודית | שמור את האישורים במעלה הזרם מחוץ למכשירים ומחוץ להנחיות, אם כי זה הופך את השער למטרה חשובה | חנויות סודיות ואסימונים קצרי מועד, בהיקף צר |
| הסלמה של הרשאות באמצעות זחילת היקף | הגבל כלים, משאבים ופעולות לכל צוות, ובדוק גישה חדשה | היקפי OAuth צרים וסקירות גישה קבועות |
| הרעלת כלי עבודה | חסום כלים עד שהם ייבדקו והתייחס להגדרות שהשתנו כאל ביקורות חדשות | בדיקת שרתים לפני אישור ולקוחות שמדגלים שינויים |
| התקפות שרשרת אספקה ושיבוש תלות | קטן: זה לא יכול לבדוק את קוד השרת, רק להגביל אילו שרתים מחוברים | בדיקות מוצא, גרסאות מוצמדות וכתבי תוכנה |
| הזרקת פקודה וביצוע | חלקית: הוא יכול לדחות טיעונים הנופלים מחוץ לסכימה שנבדקה | אימות קלט וטיפול בטוח בפקודות בשרת, בתוספת ארגז חול |
| הזרקה מהירה דרך תוכן שהסוכן קורא | הגבל את מה שסוכן שולל יכול להגיע אליו והחזק שינויים תוצאתיים לבדיקה | הגנות מודל ולקוח והנחיות אישור |
| אימות והרשאה לא מספקים | בדוק את הזהות והגישה בכל בקשה שהיא מקבלת | כל שרת עדיין אוכף בקרת גישה משלו |
| חוסר ביקורת וטלמטריה | רשום החלטות ותוצאות עבור בקשות מנותבות | יומני לקוח, שרת ונקודות קצה לכל השאר |
| שרתי Shadow MCP | שום דבר לבקשות שהוא אף פעם לא מקבל | גילוי, מלאי של נקודות קצה, בקרות רשת ונתיב מאושר קל |
| הזרקת הקשר ושיתוף יתר | הגבל אילו כלים יכולים לקרוא ולבדוק תגובות היכן שהוגדרו | סיווג נתונים ותנאי הנתונים של ספק המודל |
מה ששער עושה טוב
שער הוא בעל ערך מכיוון שכל בקשה שהוא מקבל עוברת את אותם בדיקות, לאיזה לקוח שלח אותה. זה יכול לאשר את מי שואל, האם הם עדיין שייכים לצוות, והאם הם עשויים להשתמש בחיבור, בכלי ובמשאב הזה. החלטות אלו יושבות במקום אחד במקום לחזור על עצמן, באופן לא עקבי, בכל לקוח ושרת.
זה יכול להפריד בין אישורים. אנשים נכנסים לשער, והשער מתקשר למערכת במעלה הזרם עם אישור שהונפק עבור מערכת זו. מפרט MCP אוסר על העברת אסימון של לקוח ישר דרך, מכיוון שכך עוקף את הבקרות של המערכת במעלה הזרם ולא משאיר תיעוד ברור מי פעל.
זה יכול להתייחס לכלים כאל דברים שצריך לבדוק. שמות הכלים והתיאורים הם טקסט שהמודל קורא ופועל על פיו, כך ששער שמחזיק כלים שלא נבדקו, ומתייחס להגדרה ששונתה כסקירה חדשה, סוגר פער שהפרוטוקול משאיר פתוח. זה גם יכול לנתב שינויים רגישים לבודק ולתעד גם את ההחלטה וגם את התוצאה.
שער מביא חובות אבטחה משלו
שער מרכז גישה, כך שהוא ראוי לאותה בדיקה כמו כל מערכת שמחזיקה באישורים לרבים אחרים. בשיטות האבטחה המומלצות של MCP, שרת המחבר לקוחות ל-APIs של צד שלישי נקרא שרת proxy, ויש לו התחייבויות ספציפיות.
פרוקסי כזה חייב לבקש הסכמה עבור כל לקוח לפני העברה לשרת הרשאות צד שלישי, להתאים כתובות להפניה מחדש במדויק ולאמת את פרמטר המצב OAuth. בלעדיהם, תוקף יכול לנצל את הסכמתו המוקדמת יותר של משתמש כדי לקבל גישה שהמשתמש מעולם לא קיבל, מה שהמפרט מכנה התקפת סגן מבולבלת.
שער גם מביא מטא נתונים וקורא לשרתים במעלה הזרם בשמם של אנשים. המפרט מצפה מלקוחות הפרוסים בשרתים להגן מפני זיוף בקשות בצד השרת, למשל על ידי דרישת HTTPS, חסימת טווחי כתובות פרטיות ובדיקת הפניות מחדש. שאל כיצד שער מטפל בזרימות הללו ומה קורה לאישורים שהוא מאחסן אם הוא נפגע.
מה שיושב מחוץ לשער
שער רואה בקשות, לא את ההיגיון מאחוריהן. אם מסמך אומר למודל לשלוח נתונים לאנשהו, והבקשה היא כזו שהאדם רשאי להגיש, בדיקת מדיניות לבדה לא יכולה להבחין בין כוונה להוראה. Anthropic מתאר הזרקה מיידית רחוקה מבעיה שנפתרה. הרשאות מצומצמות וסקירה של פעולות תוצאתיות מגבילות את הנזק; הם לא הופכים את התוכן לאמין.
שרתים מקומיים נמצאים גם מחוץ לזה. שרת שהופעל על מחשב נייד פועל עם הרשאות המשתמש, והתעבורה שלו לעולם לא מגיעה לשער מרוחק. ההנחיה של פרויקט MCP מתייחסת לאלו כאל תוכנות רגילות שזקוקות לניהול נקודות קצה ותוכנה.
גם הערות לכלים, כגון רמז לכך שכלי קורא נתונים בלבד, אינן אכיפה. מתחזקי ה-MCP ממליצים לשמור על ערובות בטיחות בבקרות דטרמיניסטיות. לבסוף, חוקי השער אינם חלים כאשר נעשה שימוש באותם אישורים דרך נתיב אחר, והוא אינו יכול לראות מה לקוח שולח לספק הדגם שלו.
כרטיס תמיכה עם הוראות נסתרות
סוכן תמיכה קורא כרטיסים ויכול לחפש רישומי לקוחות. מגיע כרטיס המכיל טקסט שאומר לסוכן לייצא את רשימת הלקוחות המלאה ולצרף אותה לתשובה.
הדגם עשוי לעקוב אחר ההוראה או לא; זה תלוי בדגם ובלקוח. אם הוא מנסה, השער בודק אם אדם זה עשוי להשתמש בכלי ייצוא במשאב זה. אם הכלי מעולם לא הופעל לתמיכה, הבקשה נדחית. אם זה הופעל והצוות דורש בדיקה עבור יצוא, סוקר יראה את הבקשה המדויקת לפני שמשהו רץ.
אם הייצוא מותר ואינו זקוק לבדיקה, אין לשער למה להתנגד: הבקשה מותרת לפי הכללים שניתנה. לכן עיצוב הכלים ובחירות הגישה חשובות לא פחות מהמחסום עצמו.
איך כלי אבטחה MCP מתאימים לצד זה
מוצרים הנמכרים כאבטחה MCP עושים לעתים קרובות עבודות שונות משער. סורקים בודקים חבילות שרת ותיאורי כלים עבור הוראות נסתרות לפני שאתה מאשר אותם. ניטורי זמן ריצה בודקים תוכן והתנהגות בזמן שסוכנים עובדים. כלי גילוי מחפשים שרתי MCP המוגדרים במכשירים.
אלה משלימים שער ולא מחליפים אותו. סריקה מודיעה אילו שרתים אתה מאשר, בדיקה מוסיפה בדיקת תוכן שמדיניות לבדה לא יכולה לספק, וגילוי מראה אילו מסלולים עדיין עוקפים את הפקדים שלך. כאשר אתה מעריך שער, השאלות האלה מראות מה הוא אוכף בפריסה שלך:
- אילו בקשות יראה השער בפועל, ואילו מסלולים עוקפים אותו?
- כיצד נשמרים אישורי כניסה של לקוח והרשאות במעלה הזרם נפרדים?
- כיצד בודקים את הגדרות הכלים, ומה קורה כאשר משתנה?
- האם ניתן להגביל את הגישה על ידי כלי, משאב וסוג הפעולה, לא רק על ידי חיבור?
- איך עובדת סקירה של שינוי מוצע ומה רואה סוקר?
- האם הרשומה מפרידה בין החלטת הגישה לתוצאה של הפעולה?
איפה Durin מתאים
Durin מספקת ניהול של MCP דרך שער, עבור צוותים שזקוקים לכללים וראיות עקביים עבור בקשות סוכן. עבור בקשות המנותבות דרכה, כל שיחה חייבת לעבור בדיקות זהות, חברות, צוות, חיבור, אישורים, כלי נבדק, משאבים ובדיקה נוכחית. הכלים נשארים חסומים עד שהם נבדקים, והגדרת כלי ששונתה זקוקה לבדיקה מחודשת. Durin מתקשר לספק עם האישור של החיבור עצמו ואינו מעביר את האסימון שלו במעלה הזרם.
בקשות שנבדקו יכולות להמשיך כברירת מחדל לאחר בדיקות אלו. צוותים יכולים לדחות גישה כברירת מחדל או לדרוש ממנהל אחר שיבדוק שינויים מוצעים; לאחר מכן המבקש שולח שוב את אותה בקשה לפני שההרשאה תפוג. Durin מתעד את ההחלטה ואת התוצאה בנפרד, ותוצאה לא ודאית לעולם לא חוזרת על עצמה באופן אוטומטי.
Durin אינו מונע הזרקה מיידית ואינו יכול לשלוט בבקשות שעוקפות אותה. גילוי ה-Shadow MCP שלו מדווח על שרתי MCP המוגדרים במכשירים רשומים, כולל מסלולים שעוקפים את Durin; זה לא חוסם אותם. בקרות מודל, לקוח, נקודות קצה ושרת נשארות חלק מהתוכנית.