גניבת גישה למודלי AI: כשהארגון משלם על העסק של התוקף
גניבת גישה למודלי AI, המכונה LLMjacking, היא מתקפה שבה עבריינים משתמשים בהרשאות הארגון כדי לצרוך שירותי מודלים על חשבונו, ולעיתים מוכרים את הגישה לאחרים. המשמעות למנהלים: מפתח API שנחשף אינו רק אירוע אבטחה. הוא עלול להפוך להתחייבות כספית פתוחה, שממשיכה לגדול גם כשהמערכות העסקיות פועלות כרגיל.
לפי קבוצת מודיעין האיומים של Google, המכונה GTIG, מתקפות כאלה עלולות לייצר חיובים של יותר מ־100 אלף דולר ביום. הלקח לארגונים בישראל אינו להאט את אימוץ ה־AI, אלא להפסיק לנהל הרשאות למודלים כאילו היו פרט טכני שמסיימים להגדיר בזמן ההקמה.
- חיוב יומי אפשרי לפי GTIG
- מעל 100 אלף דולר
- קריאות בפחות משמונה שעות באירוע שתואר
- מעל 500 אלף
- עלות לארגון באותו אירוע
- כמעט מיליון דולר
אלה נתונים מאירועים שתוארו בניתוח, לא עלות ממוצעת למתקפה ולא תחזית לכל ארגון. ובכל זאת, הם ממחישים את הפער בין מהירות יצירת החיוב לבין קצב הבקרה המקובל: בדיקת חשבונית חודשית פשוט אינה מנגנון הגנה מתאים.
לא גונבים את המודל. גונבים את הזכות לחייב אתכם
במתקפת LLMjacking התוקף אינו חייב להעתיק את משקלי המודל או לפרוץ לתשתית של ספק ה־AI. מספיק להשיג הרשאה שמאפשרת להגיש בקשות בתשלום. מפתח שנשמר במאגר קוד ציבורי, חשבון שירות עם הרשאות עודפות או אסימון ענן שנגנב יכולים להספיק לפתיחת הדלת.
לפי GTIG, חלק מהתוקפים מרכזים מפתחות גנובים בשערי ניתוב המכונים LLM Mixers. השערים מפזרים בקשות בין חשבונות שונים, ומאפשרים למכור למנויים גישה שהקורבנות מממנים. באחד האירועים שתוארו, שירות בשם Jet Night ביצע יותר מחצי מיליון קריאות בפחות משמונה שעות, בעלות של כמעט מיליון דולר לארגון שנפגע.
זה מסביר מדוע שירות שמציע גישה נדיבה למודלים במחיר חריג צריך לעורר בדיקת נאותות. מחיר נמוך אינו הוכחה לפעילות פלילית, אבל ארגון אינו יכול להסתפק בכך שהשירות עובד. עליו להבין מי הספק, מכוח איזו הרשאה הוא מספק גישה ומהם תנאי השימוש והטיפול במידע.
במתקפה הזאת המערכות יכולות להישאר זמינות, העובדים יכולים להמשיך לעבוד, והנזק הכספי יכול להצטבר ברקע. היעדר השבתה אינו היעדר אירוע.
סימן האזהרה הראשון עשוי להיות בקשה זעירה
אחת הנקודות החשובות בניתוח של GTIG היא שהתוקפים בודקים לעיתים מפתחות באמצעות בקשות זעירות של אסימון בודד. בדיקה כזאת מאשרת שהגישה פעילה, בלי לייצר מיד קפיצה בולטת בצריכה.
לכן ניטור המבוסס רק על סכום ההוצאה מפספס חלק מהתמונה. צריך לחבר בין זהות, הרשאות, התנהגות ותקציב: מי פנה למודל, מאיזו סביבה, האם זו פעילות ראשונה של הזהות, והאם קדמו לה יצירת מפתח או שינוי הרשאות.
אין פירוש הדבר שכל בקשה קטנה חשודה. המשמעות היא שצירוף אירועים חשוב יותר מסף בודד. זהות חדשה שמקבלת הרשאה רחבה ומיד בודקת גישה למודל מצדיקה בדיקה גם כשהחיוב זניח.
| בקרה | מה היא מזהה | מה היא עלולה להחמיץ |
|---|---|---|
| התראת תקציב | עלייה בהוצאה | בדיקות גישה זעירות |
| ניטור זהויות | הרשאות ושינויים חריגים | עלות מצטברת |
| ניטור שימוש | דפוסי צריכה חריגים | מקור ההרשאה שנגנבה |
| שילוב הבקרות | קשר בין זהות, שימוש ועלות | מחייב הקשר עסקי |
הטבלה אינה מציעה לבחור בקרה אחת. ההגנה נוצרת מהחיבור ביניהן, עם בעל תפקיד שמוסמך לפעול כשהתמונה מצביעה על ניצול.
התראת תקציב אינה תקרת הוצאה
זו הבחנה שצריכה להופיע בכל דיון הנהלה על עלויות AI: התראה מודיעה שמשהו קרה; מגבלה אכיפה מצמצמת את מה שעוד יכול לקרות. בחלק מהשירותים הגדרת תקציב אינה עוצרת צריכה אוטומטית. צריך לבדוק את התנהגות המנגנון אצל הספק ובשכבת הניתוב, ולא להסיק משם ההגדרה שהיא חוסמת חיובים.
גם מגבלה קשיחה אינה פתרון יחיד. חסימה גורפת עלולה להשבית תהליך שירות או תפעול חיוני. לכן כדאי להפריד בין סביבות פיתוח וייצור, בין תהליכים עסקיים ובין זהויות של סוכנים. כך אפשר לצמצם אירוע נקודתי בלי לעצור את כל פעילות ה־AI בארגון.
מדד ניהולי שימושי הוא החשיפה האפשרית עד לבלימה: כמה צריכה יכולה להתרחש לפני הזיהוי, ההחלטה וביטול ההרשאה בפועל. זהו חישוב תלוי ארכיטקטורה, לא נתון קבוע של ספק המודל.
תשתית לסוכנים צריכה לכלול גם יכולת לעצור אותם
ארגונים צריכים לפתח יכולת פנימית להקמה ולניהול של סוכני AI. אבל פלטפורמה שמאפשרת רק לחבר מודל, להוסיף כלים ולהעלות תהליך לייצור אינה תשתית ארגונית שלמה.
נדרשים גם ניהול מחזור חיים של זהויות, שמירת סודות, הפרדת הרשאות, תיעוד שימוש, שיוך עלויות ויכולת ביטול ממוקדת. מפתח שניתן ליישום מסוים לא אמור לפתוח גישה חופשית למודלים ולשירותים אחרים.
גם שער ניתוב מרכזי אינו שכבת הגנה אוטומטית. הוא עשוי לשפר שליטה, אך הוא גם מרכז הרשאות ולכן דורש הקשחה, עדכונים והפרדה בין ניהול לשימוש. GTIG תיארה גם ניצול חולשה בשער LiteLLM שאפשר הסלמת הרשאות. המסקנה אינה להימנע משערים, אלא לנהל אותם כרכיב תשתית רגיש.
תוכנית פעולה: לחבר אבטחה, כספים ותפעול
נקודת הפתיחה אינה רכישת מוצר נוסף, אלא מיפוי האחריות. מי יודע אילו זהויות צורכות מודלים? מי מקבל התרעה? ומי רשאי להשבית גישה בלילה בלי להמתין לישיבת הנהלה?
ממפים את הגישה
מרכזים ספקים, שערי ניתוב, מפתחות וזהויות שירות ומצמידים לכל אחד בעלים עסקי וטכני.
מצמצמים הרשאות
מפרידים בין תהליכים וסביבות, שומרים סודות במנגנון ייעודי ומעדיפים זהויות קצרות חיים כשאפשר.
מחברים ניטור ועלויות
מצליבים שינויים בהרשאות עם פעילות מודלים וצריכה כספית כדי לזהות גם ניצול שמתחיל בהיקף קטן.
מגדירים בלימה ומתרגלים
בודקים בתרגיל מבוקר שאפשר לבטל גישה חשודה, להבין את השפעת הביטול ולהחזיר תהליך חיוני לפעילות.
התהליך הזה מחייב שותפות: אבטחת מידע אחראית לזיהוי ולתגובה, מערכות מידע לתשתית ולזהויות, הכספים לחשיפה ולשיוך העלויות, והיחידה העסקית להגדרת פעילות תקינה והשפעת השבתה. ספק חיצוני יכול לסייע, אבל האחריות הארגונית אינה עוברת אליו.
אדם בלולאה, לא אדם שמאשר כל בקשה
התגובה לסיכון אינה להוסיף אישור ידני לכל קריאה למודל. כך מבטלים את ההתייעלות שבשבילה הוטמע ה־AI. המטרה היא לאפשר לאדם לפקח על תהליכים רבים באמצעות מדיניות אכיפה, תצוגת מצב והסלמה של חריגים בעלי משמעות.
במקביל נדרשת אוריינות: עובדים ומפתחים צריכים להבין מדוע לא מדביקים מפתח API בצ'אט, בקובץ משותף או במאגר קוד. ההכשרה והתשתית משלימות זו את זו; אף אחת אינה תחליף לאחרת.
זה גם המבחן לבחירת שותף הטמעה. הדגמה משכנעת של סוכן אינה מספיקה. צריך ידע מקצועי עמוק, השכלה רלוונטית וניסיון עסקי ויישומי שמאפשרים לתכנן גם את מצבי הכשל. AI אינו רק עניין טכני, וחשבון הענן אינו רק עניין של כספים. ארגון שרוצה להרחיב שימוש בביטחון צריך לדעת לא רק מה הסוכנים שלו עושים, אלא גם מי יכול להפעיל אותם, על חשבון מי, ואיך עוצרים שימוש שאינו מורשה.
