ממשל שרת MCP: מכניסה ועד פרישה

מה מכסה ניהול השרתים של MCP

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

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

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

בנה מלאי שתוכל לשמור על עדכניות

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

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

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

אשר שרתים לפי קריטריונים ברורים

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

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

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

העדיפו שרתים מרוחקים למערכות משותפות

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

ניתן להגיע לשרתים מרוחקים גם דרך נתיב מבוקר, שבו חוקי גישה ורשומות חלים על כל בקשה. שמור על שרתים מקומיים לעבודה שבאמת זקוקה למכונה, כגון קריאת עץ עובד או נהיגה בכלי מקומי.

סקור כל כלי, לא רק השרת

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

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

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

התייחס לשינויים כהחלטות חדשות

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

הצמד את מה שאישרת. עבור חבילות מקומיות, הצמד את הגרסה; עם משגרים כגון npx או uvx שמתקן רק את החבילה ברמה העליונה, בעוד שתמונת מיכל המוצמדת על ידי digest מתקנת את כל עץ התלות. עבור כלים, רשמו את ההגדרות שנבדקו והחזיקו את ההגדרות שהשתנו עד שמישהו יבדוק אותן.

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

מכיל את השרתים הפועלים באופן מקומי

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

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

רשום כל אישור

אישור שחי בשרשור צ'אט קשה לסקור מאוחר יותר. תיעוד קצר מבהיר את ההחלטה ונותן למבקר הבא משהו לבדוק מולו.

שמור את הרשומה עם ערך המלאי ועדכן אותו בכל פעם שהשרת, הכלים שלו או האישורים שלו משתנים.

לפרוש שרתים בצורה נקייה

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

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

איפה Durin מתאים

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

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

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