שרת MLflow נשכח בענן: כך בודקים חשיפה והרשאות לפני שהניסוי הופך לסיכון
חולשת SSRF חדשה ב-MLflow מחדדת סיכון בשרתי ניסוי בענן. כך ממפים חשיפה, מצמצמים הרשאות, בודקים לוגים ומגדירים אחריות בלי לעצור את העבודה.
שרת MLflow יכול להתחיל כניסוי קטן של מפתח או ספק חיצוני, ואז להישאר מחובר לענן הרבה אחרי שהניסוי הסתיים. חולשת SSRF חדשה שנכנסה לקטלוג CISA מזכירה למה עסק צריך לדעת לא רק אילו כלי AI נרכשו, אלא גם אילו שרתי ניסוי פועלים מאחוריהם ולאן הם מסוגלים להגיע.
למה חולשה ב-MLflow מעניינת גם עסק שאינו חברת תוכנה
MLflow היא מערכת לניהול ניסויי Machine Learning: היא שומרת ריצות, מודלים, מדדים וקבצים שנוצרו בתהליך. בעסק קטן היא עשויה להופיע בפרויקט חיזוי מכירות, סיווג מסמכים, מוקד שירות או אוטומציה שבנה ספק.
ב-19 באוגוסט 2026 פורסם בקטלוג החולשות המנוצלות של CISA רישום על חולשת Server-Side Request Forgery ב-MLflow. SSRF היא חולשה שמאפשרת לתוקף לגרום לשרת לשלוח בקשות בשמו לכתובות אחרות. לפי רישום החולשה ב-NVD, הגישה עלולה לכלול שירותים פנימיים או שירותי metadata של ספקי ענן.
שירות metadata הוא כתובת פנימית שמכונת ענן משתמשת בה כדי לקבל מידע ולעיתים גם הרשאות זמניות. הוא לא אמור להיות תחנת חלוקה למבקרים, ובכל זאת תצורה חלשה יכולה להפוך אותו בדיוק לכזה.
השאלה העסקית: לא מי התקין, אלא מי עדיין אחראי
הסיכון מתחיל כשהשרת יושב בין כמה כיסאות. מנהל הפרויקט מכיר את המטרה העסקית, ספק הפיתוח הקים את הסביבה, ואיש ה-IT רואה רק מכונה נוספת בחשבון הענן. אם אין בעלים מוגדר, אף אחד לא יודע אם השרת חשוף לאינטרנט, איזו גרסה מותקנת ומה יקרה אם מכבים אותו.
זה דומה לבעיה של כלי AI פנימיים שמקבלים גישה למידע רגיש, אבל הזווית כאן שונה: צריך לבדוק גם את רשת הענן ואת הזהות של השרת עצמו. חשבון משתמש עם MFA לא עוזר כאשר שירות רקע מחזיק הרשאה רחבה מדי.
בקשו תשובות כתובות לחמש שאלות:
- איפה MLflow פועל: מחשב מקומי, שרת במשרד או שירות ענן?
- האם אפשר להגיע לממשק מהאינטרנט, או רק דרך VPN ורשת מוגדרת?
- איזו זהות ענן משויכת לשרת, ולאילו משאבים היא מורשית לגשת?
- מי מתקין עדכונים ובאיזה פרק זמן לאחר פרסום חולשה פעילה?
- אילו לוגים נשמרים, ומי בודק גישה חריגה?
אם התשובה לכל שאלה היא "הספק יודע", יש עוד שאלה אחת: איפה זה מתועד אצלכם.
בדיקה מעשית בלי לפרק סביבת ייצור
אל תתחילו מסריקת תקיפה על שרת פעיל. התחילו ממיפוי. בחשבון הענן חפשו מכונות, קונטיינרים ושירותים עם השם MLflow, experiment, model או שם הפרויקט. בדקו גם חשבוניות ענן ומסמכי מסירה מספקים, כי שרת נשכח משאיר לעיתים עקבות בחיוב לפני שהוא מופיע במפת המערכות.
לאחר שמצאתם את הסביבה, בצעו את הבדיקות הבאות עם איש IT או עם הספק:
- תעדו גרסה, כתובת, בעלים עסקי ובעלים טכני.
- בדקו אם הממשק פתוח לכל האינטרנט. אם אין צורך עסקי בכך, הגבילו אותו ל-VPN, כתובות ניהול או רשת פרטית.
- צמצמו את הרשאת מכונת הענן למשאבים שהיישום באמת צריך. אל תשתמשו בתפקיד מנהל כללי לניסוי.
- הגבילו ברמת הרשת גישה לכתובות metadata ולמערכות פנימיות שאינן חלק מהתהליך.
- עדכנו לפי הנחיות היצרן, בדקו בסביבת בדיקה, ורק אז העבירו את השינוי לייצור.
- חפשו בלוגים בקשות חריגות לכתובות פנימיות, שינויים במודלים ויציאה לא צפויה ליעדים חיצוניים.
קטלוג Known Exploited Vulnerabilities של CISA נועד לעזור לתעדף חולשות שיש לגביהן עדות לניצול, ולא רק ציון תיאורטי. ההסבר של OWASP על SSRF נותן לצוות הטכני דוגמאות לדפוס התקיפה ולהגנות רלוונטיות.
גם אחרי העדכון צריך לצמצם את הנזק האפשרי
עדכון גרסה מטפל בחולשה ידועה, אך הוא לא מתקן הרשאות מופרזות או שרת שנחשף ללא צורך. לכן כדאי להפריד בין שני מסלולים: טיפול דחוף בגרסה, ולאחריו הקשחת הסביבה.
במסלול ההקשחה בדקו סודות, מפתחות API וחשבונות שירות. אם מפתח נשמר בקובץ הגדרות או נשלח ב-WhatsApp, פעלו לפי נוהל מסודר של ניהול והחלפת מפתחות API. אם גיליתם כמה פלטפורמות ניסוי שאין להן בעלים, מפת התפשטות כלי AI בעסק יכולה לעזור להחליט מה משאירים ומה סוגרים.
רצוי גם לקבוע כלל פשוט: סביבת ניסוי מקבלת תאריך תפוגה. בתאריך הזה מחליטים אם להפוך אותה למערכת מנוהלת, להאריך את הניסוי עם בעלים מוגדר, או למחוק אותה. "נבדוק בחודש הבא" הוא תאריך תפוגה מפורסם למדי, בעיקר מפני שהוא לעולם לא מגיע.
מה צריך להיות מתועד בסיום הטיפול
מסמך קצר עדיף על מצגת שלא תיפתח שוב. שמרו בו את שם השירות, הגרסה, מיקום האירוח, כתובת הגישה, אחראי עסקי, אחראי טכני, הרשאות הענן, תאריך העדכון ותוצאת בדיקת הלוגים.
אם נמצאה חשיפה, תעדו מתי התחילה ככל שניתן, אילו משאבים היו נגישים ואילו מפתחות הוחלפו. במצב של חשד לגישה לא מורשית, אל תמחקו לוגים כדי "לנקות" את המערכת. שמרו ראיות וקבלו סיוע מקצועי. מידע נוסף על תהליך מסודר אפשר למצוא בעמוד אבטחת מידע לעסקים.
שאלות נפוצות
האם כל התקנת MLflow חשופה לחולשה?
לא. רמת הסיכון תלויה בגרסה, בתצורה, בחשיפה לרשת ובהרשאות של השרת. צריך לזהות את ההתקנה בפועל, לבדוק את הנחיות הפרויקט והספק, ולא להסיק רק משם המוצר.
האם מספיק לחסום את MLflow מהאינטרנט?
חסימת גישה ציבורית מצמצמת סיכון, אך אינה מחליפה עדכון והרשאות מצומצמות. משתמש פנימי, VPN שנפרץ או שירות מחובר עלולים עדיין להגיע לממשק. ההגנה צריכה לכלול רשת, זהות, גרסה ולוגים.
מה עושים אם ספק חיצוני הקים את השרת?
מבקשים ממנו גרסה, תרשים גישה, רשימת הרשאות, תיעוד עדכון ותוכנית סגירה. האחריות הטכנית יכולה להיות אצל הספק, אבל העסק צריך להחזיק עותק של המידע ודרך לפעול אם ההתקשרות מסתיימת.
האם צריך לכבות מיד את סביבת הניסוי?
לא תמיד. אם יש חשיפה פעילה או שאין דרך לעדכן בבטחה, ניתוק זמני עשוי להיות נכון. אם הסביבה פנימית ותלויה בתהליך עסקי, אפשר להגביל גישה, לגבות את הדרוש, לעדכן ולבדוק לפי חלון שינוי מוסכם.
לימי פתרונות מחשוב יכולה לסייע במיפוי שרתי ניסוי, בדיקת חשיפה והרשאות ענן, ובניית תוכנית טיפול שאינה משביתה את העבודה ללא צורך. לתיאום בדיקה: 0542395928 או gallev@limitech.co.il.
