שיטות מומלצות לאבטחת אינטראקציות של סוכנים עם Model Context Protocol

שיטות מומלצות לאבטחת אינטראקציות של סוכנים עם Model Context Protocol

התקן Model Context Protocol‏ (MCP) קובע איך סוכני AI גנרטיביים מתחברים ל-Firestore. בגלל הסיכונים הטמונים בסוכנים אוטונומיים, כדי לצמצם את נקודות החולשה כמו הזרקת הנחיות, נדרש מודל של אחריות משותפת, שמשלב בין אמצעי בקרה של הפלטפורמה לבין תכנון מאובטח של האפליקציה.
כדי לתכנן ולפרוס אפליקציות מבוססות-AI שמשתמשות בכלים של Model Context Protocol‏ (MCP), כדאי לפעול לפי השיטות המומלצות שמפורטות במדריך הזה. Google Cloud

לפני שמתחילים

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

אחריות בנושא אבטחה

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

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

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

• זהות ייעודית: יוצרים חשבון שירות נפרד וייעודי לכל סוכן או אפליקציה ייחודיים באמצעות כלי MCP. אין להשתמש מחדש בחשבונות שירות קיימים, במיוחד בחשבונות עם הרשאות רחבות.
• היקפים מינימליים: מקצים לחשבון השירות רק את התפקידים הדרושים בניהול זהויות והרשאות גישה (IAM) – לדוגמה, alloydb.viewer ולא alloydb.admin. אם לסוכן נדרשת רק גישת קריאה למערך נתונים ספציפי, כדאי להשתמש בתפקידי IAM מותאמים אישית כדי להגביל את הגישה למינימום הנדרש לתפקוד שלו.
• הפרדת תפקידים: אם לסוכן דרושה גם גישת קריאה לנתונים וגם גישת כתיבה ליומן או לאחסון זמני, צריך להשתמש בשני חשבונות שירות נפרדים – חשבון אחד לגישה לנתונים בסיכון גבוה (עם היקף הרשאות מינימלי) וחשבון אחד למשימות תפעוליות בסיכון נמוך.

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

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

מוצר	מנגנון בקרה מפורט	התמקדות
Cloud SQL ו-AlloyDB	תפקידים ברמת מסד הנתונים, כמו CREATE ROLE ב-PostgreSQL וב-MySQL.	ניהול הרשאות במופע מסד נתונים ספציפי ובסכימות.
BigQuery	בקרת גישה ברמת העמודה (באמצעות תגי מדיניות)	הגבלת הגישה של הסוכן לעמודות רגישות – לדוגמה, מידע אישי מזהה – גם בטבלה מורשית.
Spanner	בקרת גישה פרטנית (תפקידים במסד נתונים עם GRANT/REVOKE)	אכיפת הרשאות מדויקות לקריאה, כתיבה ועדכון של טבלאות ועמודות.
Firestore	תפקידים ב-IAM ותנאים ב-IAM	הגדרת הרשאות גישה לכל מסד נתונים באמצעות תפקידי IAM ותנאי IAM.
Bigtable	תפקידי IAM	ב-Bigtable אפשר לנהל הרשאות מפורטות באמצעות תפקידי IAM ברמת הפרויקט, המופע והטבלה.
Oracle Database@Google Cloud	תפקידי IAM	‫Oracle Database@Google Cloud מציע בקרת גישה פרטנית באמצעות תפקידי IAM ברמת הפרויקט והמשאב.

תכנון סוכן מאובטח

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

התייחסות לנתונים ולפרטים שהמשתמשים סיפקו כאל מקורות לא מהימנים

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

הטמעה של דפוסי בחירת פעולות

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

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

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

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

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

הגבלת הגישה לנתונים במסדי נתונים עם ריבוי דיירים

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

כדי לוודא שהסוכן יוכל לקרוא רק קבוצות משנה של הנתונים שיש לו גישה אליהם, מומלץ ליצור כלים מותאמים אישית באמצעות מסגרת כמו MCP Toolbox for Databases. מידע נוסף זמין במאמר כלים מוכנים מראש לעומת כלים מותאמים אישית.

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

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

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

הגדרות אבטחה ובטיחות

‫Firestore מספק הגנה מוגברת על המודל כדי לאכוף גבולות בטיחות ברמת הפלטפורמה. צריך להפעיל ולקבוע את ההגדרות האלה.

הפעלת הגנה מוגברת על המודל

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

בדוגמה הבאה מפעילים את הגנה מוגברת על המודל בנקודת קצה של Vertex AI.

# Example: Enable Model Armor on a Vertex AI endpoint
gcloud ai endpoints update ENDPOINT_ID \
    --region=REGION \
    --enable-model-armor

למידע נוסף ולדוגמאות, אפשר לעיין במאמר הגדרת הגנה מוגברת על המודל עבור MCP ב- Google Cloud.

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

‫הגנה מוגברת על המודל מאפשר לכם לאכוף ערך סף מינימלי של בטיחות לפעולות שקשורות למידע אישי רגיש – לדוגמה, זיהוי והסרה של פרטים אישיים מזהים (PII). כדאי להשתמש ב-Sensitive Data Protection‏ DeidentifyTemplate כדי לצנזר או להסתיר מידע רגיש לפני שהוא מוחזר למשתמש, גם אם המודל נפגע.

הדוגמה הבאה היא להמחשה של הגדרה:

  # Example: Apply a DeidentifyTemplate to filter PII
gcloud ai endpoints update ENDPOINT_ID \
    --region=REGION \
    --model-armor-config-file=model_armor_config.json

בדוגמה הבאה, יכול להיות שההפניה model_armor_config.json היא לתבנית DLP:

{
  "safety_thresholds": {
    "injection": "HIGH",
    "harmful_content": "MEDIUM"
  },
  "data_protection_config": {
    "dlp_deidentify_template": "projects/PROJECT_NUMBER/locations/LOCATION/deidentifyTemplates/DLP_TEMPLATE_ID"
  }
}

ביקורת וניראות

היכולת לראות את פעולות הנציג חיונית לניתוח אחרי תקרית ולזיהוי נציגים שנפרצו.

הטמעה של אסטרטגיה לשחזור נתונים

אמצעי בקרה בשכבות כמו IAM ותפקידים מקוריים במסד הנתונים נועדו למנוע פעולות הרסניות, אבל אתם צריכים תוכנית שחזור למקרה שאמצעי ההגנה האלה ייכשלו. סוכן שנפרץ או סוכן תמים עם הרשאות כתיבה (סיכון מסוג Agent-Only) עלול להיות מרומה ולבצע פקודה הרסנית כמו Delete Database או להשחית נתונים.

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

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

Product	מנגנוני גיבוי ושחזור
Cloud SQL	תומך בגיבויים לפי דרישה ובגיבויים אוטומטיים, ומאפשר לשחזר מופע למצב קודם. הוא תומך גם בשחזור מערכת מנקודה מסוימת בזמן (PITR).
AlloyDB	כברירת מחדל, מתבצע גיבוי ושחזור רציפים. כך אפשר לבצע PITR עם רמת פירוט של מיקרו-שנייה, ולשחזר אשכול לכל נקודת זמן בחלון השמירה.
BigQuery	שחזור הנתונים מתבצע באמצעות 'מסע בזמן', שמאפשר לכם לגשת לנתונים ולשחזר אותם מכל נקודה ב-7 הימים האחרונים. כדי לשמור את הנתונים לטווח ארוך יותר, אתם יכולים ליצור תמונות מצב של הטבלה.
Spanner	השירות תומך גם בגיבויים לפי דרישה וגם ב-PITR.
Firestore	תמיכה בגיבויים אוטומטיים שמאפשרים לשחזר מסד נתונים למצב קודם. בנוסף, יש תמיכה ב-PITR להגנה מפני מחיקות או כתיבות בטעות. שתי התכונות האלה מושבתות כברירת מחדל.
Bigtable	תמיכה בגיבויים לפי דרישה ובגיבויים אוטומטיים. הגיבויים האלה מנוהלים באופן מלא ואפשר לשחזר אותם לטבלה חדשה.
Oracle Database@Google Cloud	תמיכה בגיבויים אוטומטיים ובשחזור לנקודת זמן מסוימת (PITR).

הפעלת יומני ביקורת ב-Cloud

חשוב לוודא שיומני ביקורת של גישה לנתונים מופעלים עבור MCP וגם עבור כל השירותים הרלוונטיים Google Cloud , כמו BigQuery,‏ Cloud SQL,‏ AlloyDB,‏ Firestore,‏ Spanner ו-Oracle Database@Google Cloud. כברירת מחדל, מופעלים רק יומני ביקורת של פעילות אדמין. ביומני הביקורת של גישה לנתונים מתועדת כל פעולת קריאה וכתיבה שמבצע הסוכן. מידע נוסף זמין במאמר בנושא יומני ביקורת של גישה לנתונים ב-MCP.

ביקורת על פעולות רגישות

הגדרת התראות ב-Cloud Logging כדי לזהות פעולות חריגות או פעולות בסיכון גבוה. השאילתה ב-Logs Explorer מזהה חשבונות שירות שמבצעים פעולות של כתיבת נתונים ב-Firestore, למשל, שהוא יעד נפוץ להעברת נתונים או להתקפות הרסניות:

resource.type="firestore_database"
# Filter for data write operations
AND protoPayload.methodName="google.firestore.v1.Firestore.Commit"
# Ensure the caller is an agent service account (modify regex as needed)
AND protoPayload.authenticationInfo.principalEmail=~".*@.*.gserviceaccount.com"
# Exclude expected system calls to reduce noise
AND NOT protoPayload.authenticationInfo.principalEmail=~"system-managed-service-account"

שימוש ברישום ביומן שספציפי לסוכן

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

• הפעלת הכלי: כלי ה-MCP שהופעל.
• פקודה גולמית: הפקודה המדויקת – לדוגמה, שאילתת Firestore או נתיב מסמך – שנוצרה על ידי ה-LLM.
• הפעולה הסופית: האם הפעולה בוצעה (מודל Agent-Only) או אושרה (Human-in-the-Middle). מידע נוסף זמין במאמר הסבר על השימוש בסוכן.
• מזהה משתמש ומזהה סשן: המזהה של משתמש הקצה שיזם את הבקשה.