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

‫MySQL   |  PostgreSQL   |  SQL Server

גרסת טרום-השקה

השימוש בתכונה הזו כפוף לתנאי השימוש במוצרים בגרסת טרום-GA, שמפורטים בחלק "תנאים כלליים לשירות" של התנאים הספציפיים לשירות. השימוש בתכונות בגרסת טרום-GA הוא "כפי שהן" (As is), ויכול להיות שהתמיכה בהן תהיה מוגבלת. אתם יכולים לקרוא מידע נוסף בקטע תיאור שלבי ההשקה.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בדוגמה הבאה מפעילים את הגנה מוגברת על המודל בנקודת קצה של 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). כדאי להשתמש ב-DeidentifyTemplateSensitive Data Protection כדי לצנזר או להסתיר מידע רגיש לפני שהוא מוחזר למשתמש, גם אם המודל נפגע.

דוגמה להמחשה של הגדרה:

  # 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) עלול להיות מרומה ולבצע פקודה הרסנית כמו DROP TABLE או להשחית נתונים.

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

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

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

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

חשוב לוודא שיומני ביקורת של גישה לנתונים מופעלים ב-MCP וגם בכל Google Cloud השירותים הרלוונטיים כמו BigQuery,‏ Cloud SQL,‏ AlloyDB,‏ Firestore ו-Spanner. כברירת מחדל, רק יומני הביקורת Admin Activity מופעלים. ביומני הביקורת Data Access מתועדת כל פעולת קריאה וכתיבה שמבצע הסוכן. מידע נוסף זמין במאמר בנושא יומני ביקורת של גישה לנתונים ב-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 שהופעל.
• פקודה גולמית: הפקודה המדויקת – לדוגמה, שאילתת SQL או נתיב מסמך – שנוצרה על ידי ה-LLM.
• הפעולה הסופית: האם הפעולה מבוצעת (מודל Agent-Only) או מאושרת (Human-in-the-Middle). מידע נוסף זמין במאמר הסבר על השימוש בסוכנים.
• מזהה משתמש ומזהה סשן: המזהה של משתמש הקצה שיזם את הבקשה.