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

‫MySQL   |  PostgreSQL   |  SQL Server

התקן Model Context Protocol‏ (MCP) קובע איך סוכני AI גנרטיביים מתחברים ל-Cloud SQL ל-SQL Server. בגלל הסיכונים הטמונים בסוכנים אוטונומיים, כדי לצמצם את הפגיעות כמו החדרה פרומפטים, נדרש מודל של אחריות משותפת, שמשלב בין אמצעי בקרה של הפלטפורמה לבין תכנון מאובטח של האפליקציה.
כדי לתכנן ולפרוס אפליקציות מבוססות-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 ברמת הפרויקט, המופע והטבלה.
Oracle Database@Google Cloud	תפקידי IAM	‫Oracle Database@Google Cloud מציע בקרת גישה פרטנית באמצעות תפקידי IAM ברמת הפרויקט והמשאב.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Product	מנגנוני גיבוי ושחזור
Cloud SQL	השירות תומך בגיבויים לפי דרישה ובגיבויים אוטומטיים, ומאפשר לשחזר מופע למצב קודם. הוא תומך גם ב-Point-in-Time Recovery (שחזור לנקודת זמן מסוימת, 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. כברירת מחדל, רק יומני הביקורת 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). מידע נוסף זמין במאמר הסבר על השימוש בסוכנים.
• מזהה משתמש ומזהה סשן: המזהה של משתמש הקצה שיזם את הבקשה.