הנהלת החשבונות במשרד של 30 עובדים מקבלת מייל שנראה כמו הזמנה לצפות במסמך משותף. הלחיצה מובילה למסך כניסה אמיתי של Microsoft — לא חיקוי, המסך המקורי — ואחריו מופיע חלון שמבקש אישור: "האפליקציה מבקשת לקרוא את הדואר שלך, לקרוא את הקבצים שלך, ולשמור על גישה לנתונים שאישרת לה". העובדת לוחצת "אשר". היא לא הקלידה סיסמה לאתר זר, לא עקפה אימות דו-שלבי, ולא הורידה קובץ. שבועיים אחר כך מתברר שמישהו קורא בשקט את התכתובת מול הספקים.
זה לא תרחיש תיאורטי, וזה גם לא פריצה במובן שרוב האנשים מדמיינים. אף אחד לא "שבר" כלום. מישהו פשוט ביקש הרשאה — והעובדת נתנה אותה.
מה בעצם קורה כשמאשרים אפליקציה
ב-Microsoft 365 כל אפליקציה חיצונית שרוצה לגעת בנתונים שלכם מבקשת הרשאות אפליקציה — מה שנקרא בתיעוד של Microsoft delegated permissions. לפי תיעוד Microsoft Entra, כשמשתמש מאשר הרשאה כזאת האפליקציה מקבלת גישה לנתונים "בזמן שהיא פועלת בשם אותו משתמש". הרשאה בשם Mail.Read, למשל, מאפשרת לאפליקציה לקרוא את תוכן תיבת הדואר של המשתמש.
ההבדל המהותי מהתקפת פישינג רגילה: אין כאן גניבת סיסמה. האפליקציה מקבלת אסימון גישה משלה, שהוא נפרד לחלוטין מהסיסמה של המשתמש. זו הסיבה שהתקפה מהסוג הזה שורדת דברים שהיינו מצפים שיעצרו אותה.
למה אימות דו-שלבי לא עצר את זה
אימות דו-שלבי מגן על שלב הכניסה. בתרחיש הזה הכניסה הייתה תקינה לגמרי — זו הייתה העובדת עצמה, מהמחשב שלה, אחרי שאישרה את ההתראה בטלפון. מה שקרה אחרי הכניסה, האישור לאפליקציה, הוא פעולה נפרדת שה-MFA לא נוגע בה.
גם החלפת סיסמה אינה פתרון מלא. לפי תיעוד Microsoft בנושא refresh tokens, אורך החיים של אסימון רענון הוא 90 יום ברוב התרחישים, ופעולות מסוימות — כמו איפוס סיסמה בידי המשתמש או ביטול יזום של כל אסימוני הרענון בידי מנהל — מבטלות אותו. אבל ההרשאה עצמה נשארת רשומה בארגון גם אחרי כן. כל עוד לא הסירו אותה, הדרך חזרה פתוחה.
איך בודקים מה מחובר אצלכם — היום
הבדיקה לוקחת פחות מעשר דקות ואפשר לעשות אותה עכשיו. לפי התיעוד הרשמי, המסלול הוא:
- היכנסו ל-Microsoft Entra admin center בהרשאת Cloud Application Administrator ומעלה.
- נווטו אל Entra ID ← Enterprise apps ← All applications.
- בחרו אפליקציה ולחצו על Permissions.
- לשונית Admin consent מציגה הרשאות שאושרו לכל הארגון. לשונית User consent מציגה הרשאות שמשתמש בודד נתן.
מה מחפשים ברשימה: אפליקציות שאף אחד לא מזהה, אפליקציות עם שם גנרי, ובעיקר הרשאות רחבות על דואר וקבצים. הטבלה הבאה מתרגמת את השמות הטכניים לשפה שאפשר להחליט לפיה:
| שם ההרשאה | מה זה מאפשר בפועל | רמת סיכון בעסק קטן |
|---|---|---|
| Mail.Read | קריאת כל תוכן תיבת הדואר של המשתמש | גבוהה |
| Mail.Send | שליחת מיילים בשם המשתמש | גבוהה מאוד |
| Files.ReadWrite.All | קריאה ושינוי של קבצים שלמשתמש יש גישה אליהם | גבוהה מאוד |
| offline_access | שמירת גישה גם כשהמשתמש לא מחובר | קריטית בשילוב עם השאר |
| User.Read | קריאת פרופיל המשתמש בלבד | נמוכה |
הצירוף שמדליק נורה אדומה הוא Mail.Read או Files.ReadWrite.All יחד עם offline_access. זה בדיוק המתכון לגישה שקטה ומתמשכת, מהסוג שממשיך לעבוד גם אחרי שהעובד סגר את המחשב והלך הביתה.
ההגדרה שקובעת אם זה יכול לקרות בכלל
יש הגדרה אחת בארגון שמכריעה את השאלה הזאת: האם משתמש רגיל רשאי לאשר אפליקציות בעצמו. התיעוד של Microsoft מפרט שלוש אפשרויות, ומגדירים אותן במסלול Enterprise apps ← Consent and permissions ← User consent settings:
| ההגדרה | מה היא עושה | למי זה מתאים |
|---|---|---|
| Do not allow user consent | משתמשים לא יכולים לאשר אפליקציות כלל; רק בעלי תפקיד מתאים | ארגונים עם דרישות רגולטוריות או מידע רגיש |
| Allow user consent for apps from verified publishers, for selected permissions | אישור רק לאפליקציות מיצרנים מאומתים, ורק להרשאות שסווגו כבעלות השפעה נמוכה | רוב העסקים הקטנים והבינוניים |
| Allow user consent for apps | כל משתמש מאשר כל אפליקציה, לכל הרשאה שאינה דורשת מנהל | כמעט אף אחד |
אנחנו לא יכולים לומר לכם מה מוגדר אצלכם — זה משתנה בין ארגונים ובין דיירים שהוקמו בתקופות שונות. לכו לבדוק. אם מצאתם את האפשרות השלישית, שינוי לאפשרות השנייה הוא כנראה השיפור הזול והמהיר ביותר שתעשו החודש בתחום אבטחת מידע וסייבר.
ואם זה כבר קרה: סדר הפעולות
- הסירו את ההרשאה. שימו לב לפרט שתופס אנשים לא מוכנים: בפורטל אפשר לבטל הרשאות רק מלשונית Admin consent. ביטול הרשאה שמשתמש בודד נתן מחייב, לפי התיעוד, שימוש ב-Microsoft Graph או ב-PowerShell.
- בטלו את אסימוני הרענון של המשתמש ואפסו סיסמה, כדי לסגור גם את הגישה שכבר הונפקה.
- בדקו כללי תיבה. תוקף שקיבל גישה כמעט תמיד משאיר מאחוריו כללי העברת מיילים אוטומטית שממשיכים לעבוד גם אחרי שסגרתם את הגישה.
- בדקו מה יצא החוצה. כאן נכנס לתמונה גם שיתוף חיצוני ב-Microsoft 365 — קישורי שיתוף שנוצרו בתקופת החשיפה נשארים פעילים בפני עצמם.
- שחזרו מה שנמחק או שונה. אם התוקף מחק תכתובת כדי לטשטש עקבות, מה שיציל אתכם הוא עותק שנמצא מחוץ לסביבת Microsoft 365 — כלומר גיבוי דואר בענן שאינו תלוי בשימור הפנימי של הדייר עצמו.
נקודה אחת שכדאי להפנים מהתיעוד של Microsoft: ביטול ההרשאה לא מונע מהמשתמש לאשר את אותה אפליקציה מחדש. אם לא שיניתם את הגדרת האישור בארגון, סגרתם אירוע — לא סגרתם פרצה.
שאלות שחוזרות
איך אני יודע אם עובד אישר אפליקציה בעבר?
ברשימת Enterprise applications, בלשונית User consent של כל אפליקציה. אפליקציה שאושרה בידי משתמש בודד לא תמיד בולטת ברשימה, ולכן כדאי לסרוק את הרשימה כולה ולא רק את מה שמוכר לכם.
מחיקת האפליקציה מהרשימה מספיקה?
היא מסירה את ההרשאה, אבל לא מבטלת אוטומטית סיסמאות או אסימונים שכבר הונפקו למשתמש עצמו. לכן הסרה, ביטול אסימונים ואיפוס סיסמה הולכים יחד — לא במקום זה.
זה רלוונטי גם לעסק עם עשרה עובדים?
כן, ובמובן מסוים יותר. בעסק קטן אין מי שסורק את הרשימה, ההגדרה נשארת כפי שהיא הוגדרה ביום ההקמה, והנזק מגישה לתיבת הדואר של המנהל או של הנהלת החשבונות הוא מיידי.
צריך רישיון מיוחד כדי לבדוק את זה?
הצפייה ברשימת Enterprise applications וההרשאות שלהן, וכן הגדרת מדיניות האישור, זמינות בממשק הניהול של Entra. יכולות ניטור וסיווג מתקדמות יותר משויכות למוצרים נפרדים של Microsoft, ולכן שווה לבדוק מה כלול ברישוי שלכם לפני שמתכננים תהליך שוטף.
מה כדאי לעשות עכשיו
שתי פעולות, שתיהן קצרות: לפתוח את רשימת Enterprise applications ולעבור עליה, ולבדוק איזו משלוש הגדרות האישור פעילה אצלכם. אם משהו ברשימה לא מוכר, או שאתם לא בטוחים איך לבטל הרשאה שמשתמש נתן בלי לשבור אינטגרציה לגיטימית — דברו איתנו. נעבור על הדייר שלכם, נסמן מה חורג, ונשאיר אתכם עם הגדרה שאפשר לחיות איתה.