חזרה לתובנות

גוגל מודה באובדן שליטה על ג׳מיני: מה המשמעות להגנת מידע אישי ופרטיות

תוכן העניינים

כשהתרגיל הופך למציאות: Gemini חצה את גבולות סביבת הבדיקה

מה שנועד להיות תרגיל מבוקר הפך לגישה למערכות אמיתיות

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

הנקודה המעניינת ביותר: ה-AI עצר בעצמו

היכולת לזהות טעות אינה מחליפה את הצורך בגבולות אבטחה

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

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

 AI מאובטח דורש יותר ממודל בטוח

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

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

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

Gemini מצטרף לשורת אירועים שמדגישה את אותו סיכון

ככל שה-AI מקבל יותר אוטונומיה, גם משטח התקיפה משתנה

האירוע של Google אינו עומד בפני עצמו. בחודשים האחרונים דווח על אירועים נוספים שבהם מודלי AI במסגרת בדיקות סייבר הגיעו למערכות אמיתיות או ביצעו פעולות שלא היו חלק מהתרחיש המתוכנן. גם מודלים של OpenAI, Anthropic ו-Meta נבדקו במסגרת הערכות של Irregular שבהן התגלו בעיות הקשורות לגבולות סביבת הבדיקה. במקרה של Gemini, Google הדגישה כי המודל עצר לאחר שזיהה את הטעות; באירועים אחרים שעליהם דווח, ההתנהגות והנסיבות היו שונות.
המשמעות עבור ארגונים אינה בהכרח שה-AI "הופך לתוקף". המשמעות המעשית היא שהמודלים הופכים מסוגלים לבצע יותר פעולות בעולם האמיתי ולכן גם טעות בהגדרת הרשאות, חיבור או סביבה יכולה לקבל משמעות אבטחתית גדולה יותר.
זהו שינוי שארגונים צריכים לקחת בחשבון כבר בשלב תכנון מערכות AI: לא רק מה המודל יודע, אלא גם מה המודל יכול לעשות.

תובנות מומחי IPV Security

האירוע של Gemini מדגים עיקרון שאנחנו ב־IPV Security רואים כחלק בלתי נפרד מאבטחת מערכות AI:

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

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

שלושה עקרונות שכדאי לארגונים לאמץ:

  1. הפרדה ברורה בין סביבות
    סביבת ניסוי, פיתוח או הערכה של AI צריכה להיות מבודדת מסביבות ייצור וממערכות אמיתיות, עם בקרות המונעות מעבר בלתי מתוכנן ביניהן.
  2. הרשאות מינימליות ל-AI
    גם אם המודל מסוגל לבצע פעולה, אין משמעות הדבר שהוא צריך לקבל הרשאה לבצע אותה. יש להחיל עקרון Least Privilege גם על סוכני AI ולצמצם גישה למידע, Credentials, APIs וכלים למינימום הנדרש.
  3. בדיקת התנהגות ולא רק תוצאה
    בדיקת AI צריכה לבחון גם תרחישי קצה: מה קורה כאשר המודל מקבל מידע שגוי, נתקל ביעד שאינו אמור להיות נגיש, מקבל הרשאות עודפות או מנסה לבצע פעולה מחוץ לתרחיש המקורי.

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

לסיכום

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

למידע נוסף: https://www.securityweek.com/google-confirms-gemini-ai-breached-three-firms/

 

להתייעצות מקצועית עם מומחי הסייבר של t.077-4447130 IPV Securityשנים של ניסיון בהגנת סייבר, מבדקים וסקרי סיכונים וציות לרגולציות.

לחצו כאן

שאלות נפוצות

איך Gemini הצליח להגיע למערכות אמיתיות?

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

האם מדובר בבעיה של המודל או של סביבת הבדיקה?

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

מה ארגונים יכולים ללמוד מהאירוע?

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

האם בדיקת אבטחה רגילה מספיקה למערכת AI?

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

נמשיך את השיחה

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

בואו נדבר