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

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

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

מה בעצם אישרתם

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

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

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

למה החלפת סיסמה לא תמיד סוגרת את הדלת

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

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

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

אילו נתונים אפליקציה יכולה לקבל

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

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

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

איך הרשאה תמימה הופכת לסיכון

כלי לגיטימי שננטש

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

אפליקציה שמבקשת יותר מדי

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

Consent phishing

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

ביוני 2025 הסבירה Microsoft Entra Blog שאפליקציה שקיבלה הסכמה יכולה לבצע קריאות API בשם המשתמש בלי סיסמה, ואף לפעול ברקע כשהמשתמש אינו נוכח. במרץ 2026 תיעדה Microsoft Security ניצול נוסף של זרימות OAuth לצורך הפניות לדיוג ולהפצת נוזקה. לא כל בקשת הרשאה היא זדונית, אבל עצם הופעתה באתר כניסה מוכר אינה הוכחת אמינות.

איך מבצעים ביקורת הרשאות

מתחילים במלאי, לא בביטול אקראי. במרכז הניהול של Microsoft Entra עוברים אל Enterprise applications ומציגים את כל האפליקציות. לכל אפליקציה בודקים שם מפרסם, תאריך יצירה, משתמשים שהוקצו, פעילות כניסה והרשאות. מדריך Microsoft לבדיקת הרשאות חל על אפליקציות שנוספו לסביבה באמצעות הסכמת משתמש או מנהל ומציג גם דרכים לבטל הרשאות דרך מרכז הניהול, Microsoft Graph או PowerShell.

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

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

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

מה מבטלים ומה משאירים

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

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

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

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

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

ב-Microsoft Entra אפשר להגדיר Admin consent workflow. במקום שהעובד יחפש דרך לעקוף חסימה, הוא שולח בקשה מתוך מסך ההסכמה. הבודק רואה מה האפליקציה מבקשת, מי ביקש ולמה, ויכול לאשר, לדחות או לחסום. בתיעוד המעודכן של Microsoft מוסבר שחסימה מונעת גם בקשות עתידיות לאותה אפליקציה.

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

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

מה עושים כשיש חשד לניצול

1. מתעדים לפני השינוי: שם האפליקציה, מזהה האפליקציה, המפרסם, ההרשאות, המשתמשים ותאריכי הפעילות.
2. חוסמים הנפקת אסימונים חדשים: משביתים את האפליקציה בסביבה ומבטלים את ההסכמות המתאימות.
3. בודקים את החשבון שאישר: כניסות, MFA, מכשירים, כללי תיבה, הודעות שנשלחו ושינויים בהרשאות.
4. מחפשים פעילות נתונים: הורדות חריגות, גישה ל-SharePoint, שימוש בדואר ופעילות API שאינה מתאימה לעבודה.
5. מטפלים בשורש: אם ההסכמה ניתנה בעקבות דיוג, מאתרים את ההודעה והנמענים הנוספים ולא מסתפקים במשתמש הראשון.
6. מתעדים החלטה: מה בוטל, מי בדק, אילו משתמשים הושפעו ומה נדרש להמשך ניטור.

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

צ'קליסט רבעוני לעסק

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

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

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

סיכום

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

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