אוקטובר השחור: מפתח ה־API שלכם הפך לתקציב של מישהו אחר

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

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

מאחורי הגישה הזאת יכול להיות גם חשבון לתשלום.

הנה שמונה דברים שלקחתי מהדיווחים שמאחורי ״אוקטובר השחור״, ומה המשמעות שלהם מבחינתי כמפתח שמשתמש ב־AI.

1. לפחות תשע פלטפורמות דיווחו על אירועים באוקטובר

בדוח שפרסמה Wiz ב־30 באוקטובר הופיעו לפחות תשע פלטפורמות פיתוח AI שדיווחו על אירועים באותו חודש. הרשימה התרחבה מאז. תשע היא הספירה המקורית של הדוח לאוקטובר, ולא סיכום סופי. מחקר Wiz

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

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

2. Zeabur דיווחה על חשיפה של יותר מ־3.2 מיליון רשומות משתני סביבה

בדוח הראשוני של Zeabur מופיעות 3,218,965 רשומות של משתני סביבה ומידע הקשור ל־321,810 חשבונות במסד הנתונים שקרא התוקף. אלה יחידות שונות: רשומות אינן מפתחות ייחודיים או אנשים. החברה דיווחה גם על הרצת פקודות ב־865 שירותי מסדי נתונים, שחלקן לא הצליחו. דוח האירוע של Zeabur

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

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

3. ב־Railway גם 1.85 אחוז היו בערך 100 אלף סביבות עבודה

Railway מסרה כי אצל לכל היותר 1.85% מסביבות העבודה, כ־100,000, ייתכן שחלק ממשתני הסביבה נפגעו. זאת הערכת היקף ראשונית, ולא אישור שכל הסודות בסביבות האלה נגנבו.

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

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

4. ציר הזמן של Fireworks ממחיש את הפער בין זיהוי להודעה

Fireworks זיהתה פעילות ב־6 באוקטובר ב־09:00 לפי שעון PDT, והחלה להודיע ללקוחות שנפגעו ב־7 באוקטובר ב־07:00: 22 שעות מאוחר יותר, בחישוב מציר הזמן שפרסמה.

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

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

5. מפתח גנוב אחד שימש לכ־800 אלף קריאות למודלים

במקרה ארגוני שחקרה Wiz, הקריאה הלא מורשית הראשונה בוצעה בתוך 30 דקות ממועד הגישה המדווחת לפרטי הגישה אצל הספק. בהמשך בוצעו כ־800,000 קריאות ל־Amazon Bedrock במשך 30 שעות, וכ־90% הצליחו, עד לטיפול במפתח. מחקר Wiz

זאת המשמעות המעשית של LLMJacking: שימוש בגישה גנובה כדי לצרוך שירותי מודלים על חשבון הקורבן.

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

6. הצפנה באחסון עדיין תלויה במי שיכול לפענח

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

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

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

7. יש דיווחים על שימוש ב־AI, אבל הייחוס עדיין חלקי

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

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

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

8. השינויים שהייתי מתעדף בפרויקט קטן

הייתי מתחיל מסדר בפרטי הגישה, לפני הוספת עוד דשבורד אבטחה:

1. לרשום איפה כל מפתח נמצא. לכלול אחסון, CI, הגדרות מקומיות, אוטומציות וגיבויים. לציין מי יכול לבטל אותו ואילו יישומים תלויים בו.
2. להפריד בין פרויקטים וסביבות. לניסוי זמני צריכה להיות גישה שמתאימה לניסוי הזה.
3. לצמצם הרשאות ותוקף. להשתמש בפרטי גישה זמניים כשזה נתמך. AWS ממליצה על תפקידים ליישומים ועל הרשאות מינימליות. הנחיות AWS IAM
4. לעקוב אחרי שימוש ולבדוק מגבלות. לברר מה הספק אוכף בפועל. להתייחס להתראה כהודעה, עד שבודקים שהמנגנון באמת עוצר צריכה.
5. לתרגל ביטול והחלפה של מפתח. לדעת לעצור את הישן, לעדכן את היישומים שתלויים בו ולוודא שהתאוששו. מחיקת משתנה שמור לבדה לא מבטלת מפתח אצל ספק חיצוני. הנחיות הטיפול של Fireworks

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

המחקר נבדק עד 9 בנובמבר 2026. ממצאי האירועים והיקפם עשויים להשתנות עם המשך החקירות. הנתונים נשמרו ביחידות ובהסתייגויות שבהן דווחו.