האירוע העיר צוות שבנה את כל מודל הגישה שלו ל-AWS מתוך אמונה שרק בני אדם זהירים מחזיקים במפתחות סביבת ייצור (production). עם סוכני AI שמוטמעים כעת בכל תהליך עבודה של מפתח, האמונה הזו התבררה כלא נכונה. החברה הגיבה על ידי הקמת "מתווך גישה" (access broker) שמאלץ כל פעולה ברמת ייצור לעבור שלב אישור של "אדם בלולאה" (human-in-the-loop).
איך התרחשה התאונה
מהנדס נתן הנחיה (prompt) לסוכן קוד מבוסס AI ליצור סקריפט של צינור עיבוד (pipeline). הסוכן ירש את תפקיד ה-IAM של הייצור של המהנדס – זהות AWS שיכולה ליצור, לשנות ולמחוק מחסניות (stacks) של CloudFormation. הסקריפט רץ, יצר מחסנית בסביבת הייצור, ומחקה אותה מיד כשלב "ניקוי". מכיוון שהפעולה עקפה את צינור ה-CI/CD הסטנדרטי, מנוע המדיניות שבדרך כלל חוסם שינויים כאלה מעולם לא ראה אותה.
פלטפורמת הניטור, שהוגדרה לסמן כל תפקיד המבצע פעולה בעלת הרשאה מחוץ לצינור המאושר, העלתה התראה ברגע שהמחסנית נמחקה. אף שירות לא קרס, האזעקה הדגישה תרחיש שבו שם משאב שגוי או הנחיית AI שגויה היו עלולים למחוק תשתית קריטית.
הצוות הבין שזיהוי אינו מניעה. אם ה-AI היה מוחק את המחסנית הלא נכונה, אסון היה מתרחש.
מדוע מודל ההזדהות הישן נכשל
הגישה הקודמת של הארגון התבססה על סשנים (sessions) קצרי מועד המוגנים על ידי אימות רב-גורמי (MFA). בתיאוריה, מפתח היה מבקש סשן, מבצע משימה, וההרשאות היו פוקעות באופן אוטומטי. בפועל, ברגע שסשן התחיל במחשב נייד, הוא נשאר פעיל כל עוד המחשב פועל. כל תהליך – סדרות בדיקות (test suites), סקריפטים ברקע וכעת סוכני AI – השתמש בהרשאות הללו שוב ושוב ללא בדיקה נוספת.
בעיית ה-"ambient credential" (הרשאות סביבתיות) הזו הטמיעה את תפקיד ה-IAM של הייצור בתוך תחנת העבודה של המפתח. סוכן ה-AI, שרץ כתת-תהליך (subprocess) באותו shell, ירש את אותן הרשאות ויכול היה לפעול על משאבי ייצור בדיוק כפי שאדם יכול היה לעשות.
מתווך הגישה: שומר הסף החדש
כדי לשבור את שרשרת ההרשאות הסביבתיות, הצוות תכנן מחדש את האופן שבו ניתן לאמץ תפקידי ייצור. במקום לאפשר לכל זהות של מפתח לאמץ ישירות תפקיד בעל הרשאה, הם הציגו ישות אחת ומבוקרת היטב: מתווך גישה פנימי (internal access broker).
זרימת הבקשה
- פורטל אינטרנט – המהנדס פותח פורטל בשירות עצמי, בוחר את רמת הגישה הנדרשת (קריאה בלבד, מפתח או מנהל מערכת) ומספק הצדקה.
- אישור ב-Slack – הבקשה נשלחת לערוץ Slack ייעודי שבו מאשר מוסמך חייב להעניק אישור מפורש.
שלב ה-Slack משמש כגורם שני (second factor) בפלטפורמה שונה מהטרמינל שבו רץ סוכן ה-AI. מכיוון שהאישור חייב להתבצע בממשק משתמש (UI) נפרד, סקריפט אוטונומי אינו יכול להשלים את תהליך העבודה בעצמו.
גישה מדורגת
- קריאה בלבד (Read-only) – משתמשים יכולים לצפות במשאבים ובלוגים אך אינם יכולים לשנות דבר.
- מפתח (Developer) – מיועד למשימות תמיכה ושינויי תשתית; רמה זו חוסמת פעולות הרסניות כגון מחיקת מחסניות או גישה ישירה לנתוני לקוחות.
- מנהל מערכת (Administrator) – הרשאות מלאות, שמורות להתערבויות חירום וניתנות רק לאחר סקירה ברמה גבוהה יותר.
על ידי ניתוב כל הגישה לייצור דרך המתווך, הצוות ריכז את הסיכון בשירות אחד מוגן היטב, במקום לפזר הרשאות בעלות סמכות על פני כל מחשב נייד.
מה המתווך באמת מונע
המטרה העיקרית של המתווך היא לעצור הרשאות סביבתיות (ambient credentials) שסוכני AI עלולים לנצל בשקט. גם אם אדם מאשר בקשה, האישור הזה הוא החלטה מודעת; ה-AI אינו יכול לזייף את השלב הזה. כתוצאה מכך:
- מחיקות לא מכוונות – ה-AI לא יכול עוד להוציא פקודת מחיקה אלא אם אדם אישר במפורש את הסשן.
- פיזור הרשאות (Credential sprawl) – מפתחות ייצור כבר לא נמצאים על מכשירי המפתחים, מה שמצמצם את שטח התקיפה עבור גורמים פנימיים זדוניים וגורמים חיצוניים שעלולים לפרוץ למחשב נייד.
הצוות מדגיש שהמערכת אינה מבטלת טעויות אנוש; אישור שגוי עדיין עלול לגרום נזק. עם זאת, היא מסירה את הסיכון ה"שקט" של קוד אוטונומי הפועל על משאבי ייצור ללא נקודת בקרה אנושית.
שורה תחתונה
כאשר סוכני AI מקבלים את אותן הרשאות בלתי מוגבלות שניתנות למהנדסים אנושיים, הם מקבלים על עצמם את היכולת לשבש את סביבת הייצור — לעיתים קרובות מבלי שאיש יבחין בכך. באמצעות ריכוז הגישה המועדפת מאחורי מתווך המכריח ערוץ אישור אנושי נפרד, צוות יכול למנוע מסקריפטים אוטונומיים לגרום לכאוס בשקט, למרות שטעות אנוש עדיין עלולה לגרום לבעיות. ההישג האמיתי בתחום האבטחה טמון בביטול הרשאות סביבתיות, ולא בפיקוח על כל החלטה בודדת.