שימו לב לפער: תקרית Salesforce והאופי המתפתח של סיכוני ענן

By קייט או'פלאהרטי • 30 באפריל 2026 • 7 דקות קריאה

לאחר שקולקטיב ההאקרים ShinyHunters ניצל תצורות משתמשי אורחים "מתירניות יתר על המידה" ב-Salesforce כדי לגשת לנתונים של עד 400 ארגונים, כיצד חברות יכולות לחזק את החוסן?

מאת קייט או'פלאהרטי

בחודש מרץ, פרסמה Salesforce אזהרה ללקוחות ש- קולקטיב ההאקינג של ShinyHunters ניצלה תצורות שגויות באתרי Experience Cloud הפונים לציבור כדי לגשת לנתונים רגישים ולהחזיק חברות ככופר.

ככל הנראה, התוקפים כיכבו גרסה משופרת של כלי קוד פתוח. AuraInspector, שפותחה במקור על ידי Mandiant, כדי לבצע סריקה המונית ולמצוא פערים בתצורה כדי לתקוף עד 400 ארגונים.

כחלק ממסגרת Salesforce Aura לזיהוי תצורות אבטחה שגויות באתרי Experience Cloud, התוקפים יצרו גרסה של הכלי "המסוגלת לחרוג מזיהוי כדי לחלץ נתונים בפועל", הזהירה Salesforce בהודעה. ייעוץ.

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

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

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

תצורות שגויות

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

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

שמישות ואבטחה "נמצאות במתח מתמיד מבחינה עיצובית", והחלטות תצורה המתקבלות בזמן היישום נבדקות לעיתים רחוקות מחדש, אומר גארווי-נורת' מ-Microlise. "פורטלים של Salesforce Experience Cloud משתמשים בפרופיל משתמש אורח ייעודי המאפשר למבקרים לא מאומתים לצפות בדפים ציבוריים או להגיש טפסים מבלי להתחבר. כאשר פרופיל זה מוגדר באופן שגוי עם הרשאות מוגזמות, נתונים שאינם מיועדים להיות ציבוריים הופכים לניתנים לשאילתה ישירה, ללא צורך בכניסה."

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

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

את מי להאשים?

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

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

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

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

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

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

אוטומציה מאפשרת התקפות

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

"כאשר מגיני הגנה חושבים על סיכון ענן, הם עדיין נוטים לחשוב במונחים של אירועים בודדים", אומר גארווי-נורת'.

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

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

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

הקבוצה הפעילה פעולות ויישינג מקבילות, התחזתה לצוותי IT והפנתה עובדים לאתרי איסוף אישורים כדי לאסוף אישורי כניסה יחידה (SEO) ו... אימות רב-גורמי קודי (MFA). השילוב מכוון, אומר גארווי-נורת': "לגנוב נתונים באמצעות תצורה שגויה, לאסוף אישורים באמצעות הנדסה חברתית, ואז לסחוט באמצעות שניהם."

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

"למרות שזה בבירור לא מומלץ, לעתים קרובות זול יותר לשלם כדי למנוע את פרסום הנתונים, מאשר להתמודד עם הקנסות והעלויות המשפטיות הנובעות מחשיפה", אומר טוני גי, יועץ אבטחת סייבר ראשי ב-3B Data Security.

גישור על פער הנראות

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

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

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

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

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

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

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

בקרה הגנתית מרכזית היא בדיקת נאותות חזקה של ספקים וניהול סיכונים מתמשך של צד שלישי, אומר ג'י מ-3B Data Security. הוא ממליץ על גישת "מינימום פריבילגיות" לשיתוף נתונים, כאשר רק הנתונים הדרושים משותפים עם הצד השלישי.

גארווי-נורת' מ-Microlise ממליצה לשאול ספקים את השאלות שהייתם שואלים לגבי התשתית שלכם: "מהן תצורות ברירת המחדל המאובטחות שלכם, כיצד אתם מזהים גישה חריגה ברמת הפלטפורמה, ואיך נראה תהליך הגילוי שלכם כאשר משהו משתבש?"

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

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

"המקום שבו ISO 27001 מוסיף ערך אמיתי בסביבות דיגיטליות מורכבות הוא בכפיית בהירות ארגונית: מי הבעלים של כל בקרה, איך נראה סיכון מקובל, וכיצד אירועי בקרה מוסלמים ונלמדים מהם", אומרת גארווי-נורת'. "מבנה ממשל זה הופך לרקמה המחברת בין יכולת הנדסת האבטחה שלך לבין תיאבון הסיכון שלך ברמת הדירקטוריון. בלעדיו, יש לך כלים ללא אחריות."