ממשל גישה MCP: מי יכול להשתמש באילו כלים ונתונים

מה המשמעות של ממשל גישה MCP

פרוטוקול ה-Model Context (MCP) מאפשר ללקוחות בינה מלאכותית כגון Claude Code, Cursor או Codex להתחבר למערכות החברה באמצעות שרתים המציעים כלים: חיפוש תור כרטיסים, קריאת מסמך, עדכון רשומת לקוח. כל בקשת כלי מגיעה למערכת מטעמו של מישהו.

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

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

הגישה נקבעת בשכבות

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

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

קשר כל בקשה לאדם

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

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

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

הענק גישה דרך צוותים

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

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

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

שמור על גישה לסוכן למה שהעבודה צריכה

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

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

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

בדיקת גישה וביטול בדיקה

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

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

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

הפרד בין בקשה לאישור

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

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

שמור עדויות על גישה ושימוש

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

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

איפה Durin מתאים

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

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

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