האפליקציה שאישרתם הרגע פתחה לתוקף את הענן

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

במילים פשוטות: אבטחת OAuth היא כבר לא סעיף טכני של מנהלי זהויות. היא קו הגנה עסקי. Microsoft מתארת מתקפות consent phishing כתרחיש שבו משתמשים מעניקים הרשאות לאפליקציות ענן זדוניות, ואלו מקבלות גישה לנתונים לגיטימיים בלי צורך בגניבת סיסמה. מי שרוצה לראות את ההגדרה וההמלצות המקוריות יכול לקרוא את המסמך הרשמי של Microsoft על הגנה מפני consent phishing.

למה זו מתקפה שמבלבלת גם צוותי אבטחה טובים

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

זו הסיבה שהתגובה האוטומטית של החלפת סיסמה אינה מספיקה. Microsoft כותבת במפורש שבמתקפות illicit consent grant פעולות רגילות כמו איפוס סיסמה או דרישת MFA אינן יעילות מספיק, כי האפליקציה החיצונית כבר קיבלה גישה ברמת החשבון. ההנחיות המלאות נמצאות ב מדריך Microsoft לזיהוי וטיפול בהרשאות זדוניות.

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

מה באמת קורה מאחורי כפתור האישור

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

תרחיש נפוץ נראה כך:

1. התוקף יוצר אפליקציה שנראית כמו כלי תמים, למשל כלי סריקה, הרחבת פרודוקטיביות, מחבר לקבצים, מערכת חתימה או כלי AI.
2. העובד מקבל קישור שנראה קשור לעבודה, לפעמים דרך מייל, לפעמים דרך Teams, לפעמים דרך אתר שנראה אמין.
3. העובד לוחץ על התחברות ומקבל חלון הרשאות אמיתי של Microsoft או Google.
4. הוא מאשר גישה למייל, לקבצים, ליומן או לפרופיל.
5. האפליקציה מקבלת טוקן ומתחילה לפעול. מבחינת הלוגים, לא תמיד מדובר בפעולה חריגה. זו אפליקציה מורשית.

MITRE ממקמת גניבת Application Access Token תחת הטכניקה T1528 ומסבירה שטוקני OAuth מאפשרים לאפליקציות צד שלישי לפעול מול משאבים שמכילים נתוני משתמשים. אפשר לקרוא את הפירוט הטכני ב MITRE ATT&CK T1528. הנקודה החשובה לנו כארגון אינה רק הטכניקה, אלא המשמעות: ברגע שהטוקן אצל התוקף, ההגנה עוברת מסיסמאות להרשאות, מסינון קבצים לניטור התנהגות, ומחומת אש למשילות ענן.

הטעות הגדולה: לחשוב שהמשתמש אישר רק כלי אחד

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

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

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

Microsoft 365 ו Google Workspace: אותו סיכון בשתי שפות

ב Microsoft 365 האיום מתבטא בהרשאות אפליקציה ב Entra ID, ב service principals, בהרשאות Graph ובאפליקציות שמקבלות גישה ל Exchange, SharePoint, Teams או OneDrive. ב Google Workspace הסיכון מתבטא באפליקציות צד שלישי שמבקשות scopes לשירותים כמו Gmail, Drive, Calendar ו Contacts.

Google מאפשרת לאדמינים לבקר אילו אפליקציות ניגשות לנתוני Workspace, להגביל שירותים רגישים, לסווג אפליקציות כמאושרות או חסומות, ולראות scopes שהאפליקציות מבקשות. ההסבר הרשמי נמצא ב מדריך Google לניהול גישת אפליקציות לנתוני Workspace.

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

איך מזהים שהבעיה כבר קיימת אצלכם

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

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

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

תרחיש מהשטח: האישור הקטן שהפך לדלף גדול

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

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

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

הבעיה עם הרשאות אפליקציה היא שהן נשארות אחרי שהרגע נגמר

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

מה עושים ב 72 שעות הראשונות

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

1. מייצאים רשימת אפליקציות שאושרו בארגון, כולל שם האפליקציה, מפרסם, משתמשים שאישרו, scopes, תאריך אישור ותאריך פעילות אחרון.
2. מסמנים הרשאות בסיכון גבוה: קריאת דוא״ל, שליחת דוא״ל, גישה לקבצים, גישה לכלל הדייר, הרשאות כתיבה והרשאות offline access.
3. חוסמים או משהים אפליקציות שאינן מזוהות, אינן מאומתות, או אינן נדרשות עסקית.
4. בודקים אירועים אחרונים של Consent to application ומחפשים אישורים חריגים.
5. מגבילים אישור אפליקציות כך שמשתמשים לא יוכלו לאשר הרשאות רחבות ללא תהליך בדיקה.
6. מכניסים אירועי אישור, שינוי והרשאת אפליקציות למערך ניטור.

מה עושים ב 30 יום כדי להפוך את זה למשילות אמיתית

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

• מגדירים בעלים לכל אפליקציה עסקית. אפליקציה בלי בעלים היא סיכון בלי כתובת.
• יוצרים קטגוריות הרשאה: נמוכה, בינונית, גבוהה וקריטית. לא כל חיבור SaaS דורש ועדה, אבל חיבור שקורא מיילים או קבצים חייב בדיקה.
• מגדירים תהליך אישור קצר וברור לאפליקציות חדשות, כולל סיבת שימוש, בעלים עסקי, scopes נדרשים ותאריך בדיקה מחדש.
• מיישמים עיקרון least privilege גם באפליקציות, לא רק במשתמשים.
• מחברים לוגים של Entra ID, Google Workspace, Microsoft Defender ופעילות SaaS למערכת ניטור אחת.
• מבצעים סקירה חודשית של אפליקציות לא פעילות והרשאות רחבות מדי.

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

מה צריך לנטר כדי לא לגלות בדיעבד

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

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

כאן נכנס הערך של SIEM SOC. לא מספיק לאסוף לוגים. צריך לחבר בין אישור אפליקציה, פעולות משתמש, גישה לקבצים, דוא״ל, דפדפן וענן. האירוע האמיתי נמצא בקשר בין הסימנים.

איפה DLP ומודיעין סייבר נכנסים לתמונה

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

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

ומה עם CISA ומדדים חיצוניים

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

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

הצ׳קליסט שלנו לאבטחת OAuth בארגון

• לבטל אישור חופשי של אפליקציות בעלות הרשאות גבוהות.
• לאפשר אישור משתמשים רק להרשאות בסיכון נמוך ולמפרסמים מאומתים, אם זה מתאים למדיניות הארגון.
• להגדיר תהליך אישור מהיר לאפליקציות עסקיות חדשות.
• לבדוק scopes בפועל, לא רק את שם האפליקציה.
• להסיר אפליקציות לא פעילות.
• לצמצם הרשאות רחבות מדי ולהעדיף גישה נקודתית.
• לחבר אירועי consent ללוגים ולמערכת SIEM SOC.
• ליישם DLP על מייל, ענן ושיתוף קבצים.
• להדריך עובדים להבין חלון הרשאות, לא רק לזהות מייל חשוד.
• לבצע סקירה חודשית של אפליקציות, טוקנים והרשאות.

השורה התחתונה

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

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

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