ממשל MCP: מדריך מעשי לשרתים, גישה ואישורים

מה מכסה ממשל MCP

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

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

הגדר את היקף הממשל

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

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

גישה למלאי והקצאת בעלים

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

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

הגדר את כלי המדיניות והסקירה בנפרד

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

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

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

בדוק חיבור אחד לפני הרחבה

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

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

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

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

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

רישומי החלטות אינם מחייבים שמירת כל הנחיה או תגובה. ברירת המחדל של Durin לכידת שיחה למטא נתונים בלבד. כאשר מנהל מערכת מאפשר לכידת עריכה, לכידות חדשות נשמרות למשך 7, 90 או 180 ימים, או 360 ימים ב-Enterprise; סביבות עבודה עם הגדרה ישנה יותר של 1-30 יום שומרים אותה עד שמנהל מערכת יבחר תקופה נתמכת. תקופות שמירה אלו נפרדות משמירת ביקורת, חשבון וחיוב.

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

השתמש בשאלות אלה בכל סקירת השקה

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

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