אימות הסכמה (Consent Phishing) ב-Microsoft 365

By Mirko Peters · 2026-04-26 · Updated 2026-07-18

למדו כיצד התקפות Consent Phishing עוקפות הגנות MFA מסורתיות, מנצלות הרשאות OAuth, וכיצד לזהות ולמנוע אותן.

Automatically translated with AI from the original post. Read the English original

Consent Phishing הוא אחד מהאיומים שצומחים הכי מהר בסביבות Microsoft 365 ו-Azure, והוא מפתיע ארגונים משום שהוא עוקף אפילו את מנגנוני האימות החזקים ביותר. בניגוד לפישינג הקלאסי, שמנסה לגנוב את הסיסמה שלכם, Consent Phishing מאפשר לתוקפים להיכנס דרך "דלת אחורית" – על ידי ניצול המנגנונים שנועדו בדיוק כדי לאבטח את ההתחברות. הטכניקה מנצלת את אמון המשתמשים ונשענת על OAuth, אותו מסגרת הרשאות שמפעילה גם אינטגרציות לגיטימיות של Single Sign-On ואפליקציות בענן.

תוקפים יכולים להשתמש ב-Consent Phishing כדי לשמור על גישה מתמשכת וסמויה למידע עסקי רגיש, גם בסביבות המוגנות באימות רב-שלבי (MFA). מדריך זה צולל לעומק אל האופן שבו Consent Phishing עוקף את האבטחה המסורתית ומדוע, מפרק התקפות מהעולם האמיתי, ומציג צעדים מעשיים לזיהוי, מניעה והכלה של איומים הקשורים להסכמות. בין אם אתם מנהלים Microsoft 365 עבור צוות קטן ובין אם אתם אחראים על אבטחה לאלפי משתמשים, הבנה של אופן פעולתם של תוקפים בתהליכי הסכמת OAuth היא כיום כישור חובה.

הבנת Consent Phishing והסיבה לכשל ה-MFA

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

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

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

מהו Consent Phishing ומדוע הוא עוקף אימות רב-שלבי?

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

וכאן הטוויסט: כשאתם מאשרים מסך הסכמה, האפליקציה מקבלת מספק הזהות (כמו Microsoft Entra ID, שנקרא בעבר Azure AD) אסימוני גישה ואסימוני רענון. אפשר להשתמש באסימונים האלה כדי לגשת לנתוני Microsoft 365 שלכם – מדואר אלקטרוני, קבצים, יומן ועוד – בלי לדעת מעולם את הסיסמה שלכם ובלי להפעיל את ה-MFA. התוקף לא צריך לעקוף את מנגנוני ההתחברות שלכם; הוא פשוט משתמש בגישה שנתתם מרצונכם, והפלטפורמה רואה בה גישה לגיטימית לחלוטין.

ההבדל בין פישינג אישורי גישה (Credential Phishing) ל-Consent Phishing הוא עדין אך משמעותי. Credential Phishing מנסה ללכוד את שם המשתמש והסיסמה שלכם (ורכיב ה-MFA מסייע לעיתים קרובות להגן עליהם), ואילו Consent Phishing פועל בתוך תהליך OAuth 2.0 של Authorization Code הרשמי. גם כאשר ה-MFA נאכף במלואו, התוקפים עוקפים אותו לחלוטין על ידי כך שהמשתמש משלים את תהליך ההסכמה דרך ההפעלה הקיימת שלו. לאחר שאסימוני OAuth הונפקו, אחיזתו של התוקף נמשכת גם אם הקורבן משנה את הסיסמה שלו או מבטל את ההפעלה שלו.

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

כיצד פישינג של הסכמת OAuth מנצל אמון כדי לפגוע בנתונים

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

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

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

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

טכניקות נפוצות והתקפות פישינג להסכמה בעולם האמיתי

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

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

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

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

1. התחזות למפרסם: התוקפים יוצרים אפליקציות בשמות הדומים לשמות של ספקים לגיטימיים, כמו "Microsoft Secure Suite" או "HR Docs Cloud". המשתמשים סומכים על מיתוג מוכר, ולכן סביר יותר שיאשרו את הבקשה. תמיד בדקו לעומק את פרטי המפרסם ואמתו את המקור.
2. הצגה מטעה של הרשאות: אפליקציות זדוניות מדגישות לעיתים קרובות הרשאות לא מזיקות במסך ההסכמה, אבל מסתירות בתוכן הרשאות בעלות פריבילגיות גבוהות, כמו "קריאה וכתיבה לכל תיבות הדואר" או "גישה מלאה לקבצים". משתמשים שהוכשרו להסתכל רק על הטקסט המודגש עלולים לפספס את הסיכונים האמיתיים שהם מאשרים.
3. הענקות בהיקף מוגבל לצורך הסלמה מאוחרת יותר: חלק מהתוקפים מבקשים הרשאות בסיסיות (כמו גישה לפרופיל שלך) כדי להתחמק מחשד. לאחר מכן הם משתמשים בגישת הטוקן הראשונית כדי לחדור פנימה, ומנסים לקבל הסכמות מסוכנות יותר באמצעות דיוג מתוזמן או הסלמת הרשאות.
4. תנועה רוחבית עם טוקני OAuth מתמשכים: לאחר החדירה, התוקפים מנצלים טוקנים והרשאות אפליקציה כדי לנוע באופן רוחבי – גישה לכונני שיתוף, לאירועי יומן, או הסלמה בתוך Microsoft 365. טוקנים יכולים להעניק גישה "מינימלית בקושי" לתחילת הדרך, ולאחר מכן להירחב או להתרענן בשלב מאוחר יותר.
5. אפליקציות צד שלישי שנפרצו: במקום לבנות כלים משלהם, התוקפים לעתים קרובות פורצים לאפליקציות של ספקי תוכנה עצמאיים (ISV) מהימנים, או משתמשים בהן מחדש, אפליקציות שכבר קיבלו הרשאות רחבות מדיירים רבים. מתקפות שרשרת האספקה הללו קשות במיוחד לזיהוי, ויכולות להתפשט במהירות בין ארגונים.

להעמקה טכנית במנגנונים הבסיסיים ובאופן שבו אפשר לחזק את Entra ID מפני הדפוסים האלה, מומלץ לעיין בפירוט המלא הזה על ניצול הסכמות OAuth. אלו רק חלק קטן מהדרכים היצירתיות שבהן תוקפים למדו לעקוף הגנות מסורתיות ואימות רב-שלבי (MFA).

כך פועלת קמפיין ConsentFix, שלב אחר שלב

1. דוא"ל דיוג ראשוני: המתקפה מתחילה בהודעת דוא"ל משכנעת שמפצירה במשתמש "לתקן בעיית מדיניות" או "לאבטח את תיבת הדואר שלו". ההודעה כוללת קישור המוסווה כמשאב רשמי של Microsoft.
2. הפניה לדף הסכמה זדוני לאפליקציה: לחיצה על הקישור מובילה את המשתמש לחלון הסכמת OAuth. הממשק נראה מוכר, ממותג ולגיטימי, אך האפליקציה שמאחוריו נשלטת על ידי התוקפים – לעתים עם שם משובט או מטעה.
3. מתן הסכמה והנפקת טוקנים: המשתמש סוקר את ההרשאות המבוקשות – בדרך כלל מנוסחות כנדרשות לצורך "אבטחה" או "ציות" – ולוחץ על "אישור". כך התוקף מקבל טוקני גישה וטוקני רענון לחשבון המשתמש.
4. התוקף משיג גישה מתמשכת: בעזרת הטוקנים האלה, התוקפים ניגשים לתיבות דואר, קבצים, יומנים או ממשקי API אחרים של Microsoft 365 המכילים מידע רגיש. הסשן שורד שינויי סיסמה ואפילו איפוסי MFA ברוב המקרים, עד שההסכמה מבוטלת ידנית.
5. איסוף נתונים בחשאי ומונטיזציה: התוקף מוציא בשקט תוכן מהודעות דוא"ל, מסמכים רגישים, או יוזם תנועה רוחבית לשירותים מחוברים. מכיוון שהכול נראה "מאושר", הזיהוי קשה – אלא אם הצוות שלכם מנטר פעילות חריגה של אפליקציות או הענקות הסכמה חדשות.

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

מדוע ConsentFix חשוב לאבטחת Microsoft 365 ולאבטחת הענן

קמפיין ConsentFix הראה עד כמה מהר ובשקט תוקפים יכולים לפגוע ב-Microsoft 365, ב-Google Workspace ובדיירי SaaS אחרים, על ידי ניצול לרעה של תהליכי OAuth לגיטימיים. ארגונים מכל הענפים חוו גישה לא מורשית לדואר, דליפות קבצים והתמדה ממושכת של חשבונות, גם לאחר אכיפת איפוס סיסמאות ו-MFA. המתקפות האלה מדגישות את הדחיפות בהגנות שכבתיות: מודעות של המשתמשים, ניטור הסכמות בזמן אמת וממשל אפליקציות הדוק. אלה אינם "דברים נחמדים לקיים" – הם קריטיים למניעת פריצות והפסד נתונים בקנה מידה גדול בענן.

זיהוי אפליקציות זדוניות וניטור הסכמות חריגות

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

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

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

זיהוי יישומים זדוניים באמצעות סימנים התנהגותיים ואירועי הסכמה

1. ניטור מענקי הסכמה בלתי צפויים: שימו לב להסכמות OAuth חדשות, במיוחד כאלה שאושרו מחוץ לשעות העבודה הרגילות או שמקורן בספקים לא מוכרים. מספר גדול של יישומים שאושרו לאחרונה יכול להוות סימן אזהרה.
2. ניתוח דפוסי קריאות API חשודים: חפשו התנהגות חריגה, כגון גישה מהירה במיוחד לקבצים, קריאה המונית של תיבות דואר או שימוש לא אופייני ב-API של מנהלים. תוקפים נוטים "להשתמש יתר על המידה" בהרשאות בהשוואה ליישומים רגילים.
3. שימו לב לפעילות טוקנים חריגה: עקבו אחר יצירה מהירה או חוזרת של טוקני רענון ואחר דפוסים מוזרים במחזור החיים של הטוקנים. יישומים זדוניים עלולים לנצל טוקני רענון כדי לשמור על גישה הרבה לאחר הפריצה הראשונית.
4. מנפו את יומני Microsoft וה-Defender: השתמשו במוצרי אבטחת יישומי ענן וביומני Entra ID כדי לערוך מלאי של כל היישומים המורשים, ולחשוף יישומים מסוכנים או יישומי צל שעקפו את תהליכי האישור הרגילים של IT. כלים כמו Microsoft Defender for Cloud Apps מספקים נראות והתרעות על התנהגויות חשודות של יישומים.
5. פעלו בעקבות ממצאי Shadow IT: אירועים רבים נובעים מגישה של יישומים לא מאושרים או לא מנוהלים. בצעו ביקורת קבועה של הדייר שלכם, עקבו אחר גילויים של יישומים מסוכנים ונקו הענקות OAuth עם הרשאות עודפות. מידע נוסף על טיפול ב-Shadow IT ובשליטה ביישומים בלתי מורשים במדריך זה לניהול Shadow IT ב-Microsoft 365.

חקירת מתקפות פישינג להסכמה באמצעות Microsoft 365 Defender ו-Entra ID Protection

1. ציד איומים: התחילו בחיפוש ביומני Entra ID ובהתראות של Microsoft 365 Defender אחר אירועי הסכמה אחרונים, יצירת יישומים חשודה או דפוסי כניסה חריגים הקשורים ליישומי OAuth.
2. חקירה ממוקדת: בדקו לעומק את ההיסטוריה של כל משתמש ויישום, ובדקו אילו הרשאות ניתנו, מתי ועל ידי מי. השוו פעילות זו לקווי בסיס רגילים ולתזמון תהליכי העבודה העסקיים.
3. תיקון: כאשר נמצאת הסכמה זדונית, בטלו מיד את טוקני היישומים ואת הענקות ההסכמה. Microsoft 365 Defender מאפשר ביטול מרוכז וגם יכול לסמן סשנים מסוכנים נוספים. כך מונעים מתוקפים להשתמש בטוקנים מתמשכים כדי לשמור על גישה.
4. ניטור מתמשך ואוטומציה: הגדירו התראות אוטומטיות על הסכמות חדשות ליישומים בסיכון גבוה, על בקשות הסכמת מנהל חוזרות או על מזהי מפרסמים זדוניים מוכרים. הגדירו מדיניות אוטומטית לתגובה מהירה יותר ולהפחתת זמן השהייה של התוקף בסביבה.
5. שילוב ציות ואכיפת מדיניות: השתמשו בMicrosoft Defender for Cloud לניטור ציות מתמשך לצד תגובה לאירועים, ועיינו בגישות ממשל זהויות ב-Entra ID כדי לוודא שמדיניות האבטחה ניתנת לאכיפה לאורך זמן. כך תוכלו לתפוס גם התקפות בזמן אמת וגם למנוע סחף תצורה עתידי או חוב זהויות שעלולים לפתוח סיכונים חדשים.

הגנה על הסביבה שלכם באמצעות מדיניות הסכמה והגבלות יישומים

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

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

ממשל אינו עניין של אמירת "לא" לחדשנות – מדובר בשליטה בגישה, בהגדרת תהליכי עבודה מהימנים ובאכיפת הגבולות ששומרים על הסביבה בריאה ככל שהיא גדלה. אם אתם עובדים על מסגרות אבטחה רחבות יותר, הלקחים כאן רלוונטיים הרבה מעבר ל-Microsoft 365, ונוגעים גם ל-Power Platform ולשירותי SaaS עסקיים אחרים. לתובנות נוספות על שיטות עבודה מומלצות, ראו המדריך לממשל ואבטחה ב-Power Platform.

כיצד להגדיר מדיניות הסכמה ולהגביל הסכמת משתמשים

1. הגבלת הסכמת משתמשים כברירת מחדל: ב-Microsoft Entra ID, הגדירו הגדרות על פני כל הדייר כך שרק מנהלים יוכלו לאשר הסכמות של אפליקציות בסיכון גבוה. משתמשי הקצה יראו מסכי הסכמה רק עבור אפליקציות בסיכון נמוך, מה שממזער אישורים מקריים.
2. הפעלת תהליכי אישור מנהל: דרשו בדיקה ואישור מנהל לכל אפליקציה שמבקשת הרשאות רחבות או רגישות. פעולה זו מונעת הרשאה "בלי לשים לב" של אפליקציות מסוכנות, ובונה תיעוד רשמי של פעילות ההסכמות.
3. הגדרת היקפי הרשאות מדויקים: אל תשתמשו בהרשאות "אפשר הכול" גורפות. הגבילו את ההסכמה למה שנדרש בפועל לצרכים העסקיים. הגדרות היקף מותאמות אישית מקשות על תוקפים להסתנן עם הרשאות מסוכנות.
4. ביקורת שוטפת של הסכמות שניתנו: בדקו אילו אפליקציות מחזיקות כרגע בהרשאה לגשת לדייר שלכם, במיוחד כאלה שאושרו על ידי משתמשים ללא פיקוח של IT. בטלו הסכמות מיושנות או מיותרות כדי לצמצם את משטח התקיפה.
5. שימוש במדיניות גישה מותנית: שלבו הגבלות הסכמה עם מדיניות גישה מותנית חזקה – כולל אכיפה מבוססת מיקום, מכשיר או סיכון – כדי לחסום חטיפת סשנים או גישה ממכשירים לא מנוהלים.

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

אכיפת אימות מפרסמים והגבלת גישה לאפליקציות של צד ראשון

1. דרישת אימות מפרסמים: אפשרו רק לאפליקציות ממפרסמים מאומתים לבקש הסכמה של משתמשים או מנהלים בסביבה שלכם. כך מוודאים שמפתחי האפליקציות אימתו את זהותם, וזה מוסיף שכבת אמון נוספת החוסמת רוב מתקפות התחזות.
2. חסימת מפרסמים לא מאומתים: ב-Entra ID ובפלטפורמות אחרות, הגדירו מדיניות בסיס שדוחה אוטומטית הסכמות לאפליקציות שאינן עומדות בתקני אימות המפרסם. בדקו באופן קבוע את סטטוס המפרסם של כל האפליקציות הקיימות והחדשות.
3. הגבלת הסכמות לאפליקציות מהימנות של צד ראשון: הדקו את התצורה כך שרק אפליקציות של צד ראשון (למשל, של Microsoft עצמה) או אפליקציות של צד שלישי שאושרו במיוחד יוכלו לבקש הסכמות חדשות. כך מצמצמים משמעותית את הסיכון לתנועה רוחבית מאפליקציה פגומה אחת לאחרת.
4. ביקורת ומלאי של גישת מפרסמים: הפכו את סטטוס המפרסמים ומלאי האפליקציות לנושא קבוע במחזורי הסקירה האבטחתית השוטפים של IT, תוך שימוש בכלים אוטומטיים שמדגישים מפרסמים חדשים או לא מאושרים.
5. יישום על כל הפלטפורמות המחוברות: הרחיבו את אימות המפרסמים ואת הגבלות האפליקציות ל-Power Platform, לאפליקציות של Teams ול-SaaS מחובר. מידע נוסף על ביצוע הדבר בהיקף רחב יותר זמין במדריך הממשל של Power Platform.

ניהול תוקף אסימוני גישה ויישום ניטור מתמשך לאבטחת OAuth

הגבלת משך תוקפם של אסימוני OAuth לזמן קצר יותר מצמצמת את החלון שבו תוקף יכול לנצל אסימונים שנגנבו או שאושרו. יש להתאים את מדיניות תפוגת האסימונים כך שאסימוני גישה יפוגו במהירות, ואסימוני רענון יוחלפו מעת לעת. יש ליישם קישור אסימונים (token binding) וביטול גישה מבוסס סיכון כדי לנתק הפעלות חשודות או שנעשה בהן שימוש לרעה. יש לשלב אלה עם ניטור מתמשך של השימוש באסימונים ושל אירועי הסכמה, כדי לזהות דפוסים חריגים, תוך שימוש בכלים כמו Microsoft Defender for Office 365 ומדיניות גישה מותנית של Entra, כך שאסימונים שנפרצו לא יהפכו לאיום שקט ומתמשך. להגדרות מעשיות ולאסטרטגיות ניטור מתמשך, ראו המלצות האבטחה של Microsoft אלה.

חיזוק הממשל ובניית מודעות משתמשים נגד פישינג הסכמה

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

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

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

בניית מסגרת ממשל ל-OAuth וביקורת הרשאות קיימות

1. הגדרת מדיניות הסכמה ושימוש באפליקציות: יש לקבוע כללים ברורים הקובעים אילו משתמשים ואילו אפליקציות רשאים לבקש הסכמה, תוך פירוט סוגי ההרשאות המותרים ותרחישי השימוש העסקיים. יש לפרסם הנחיות אלה כך שכל מי שבארגון יכיר את כללי המשחק.
2. תחזוקת מלאי אפליקציות מלא: יש לרשום את כל האפליקציות המחוברות ל-OAuth ב-Entra ID, ולציין מי אישר כל הסכמה, את המפרסם, את ההיקפים שנדרשו ואת ההצדקה העסקית. גילוי אוטומטי באמצעות ממשקי Entra APIs או Microsoft Defender יכול לזרז את התהליך ולאתר אפליקציות צל.
3. ביצוע ביקורות הרשאות תקופתיות: יש לתזמן סקירות רבעוניות או דו-שנתיות כדי לאתר הרשאות מיושנות, כפולות או מסוכנות. יש לבדוק את מצב אימות המפרסם של האפליקציות, ולהסיר הרשאות של אפליקציות שאינן בשימוש עוד או כאלה שהפכו לחשודות.
4. ניטור וטיפול בחריגות: יש להגדיר התראות על הפרות מדיניות, כגון משתמשים שמעניקים הרשאות רחבות למפרסמים שלא אושרו, ולהפעיל קמפייני תיקון מיד עם איתור פערים. ביקורות קבועות שומרות על ההגנות שלכם זריזות ועל מערכת האפליקציות בריאה.
5. שילוב הממשל עם ציות ו-DLP: בסביבות בסיכון גבוה או מוסדרות, יש לשלב את ממשל OAuth עם מדיניות ה-DLP של Microsoft Purview ועם רישום הביקורת. ראו מדריך הממשל הזה של Purview לדרכים מעשיות לניטור פעילות משתמשים וגבולות מחברים בקנה מידה רחב.

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

• הדרכה ממוקדת למשתמשים בנושא סיכוני OAuth: יש לערוך סדנאות או מודולי למידה מקוונים באופן קבוע כדי ללמד את העובדים על הסכנות שבבקשות אפליקציה חשודות, הרשאות מטעות ואמון יתר בממשקים עם מותג. יש להדגיש דוגמאות אמיתיות, כגון הודעות פישינג ומסכי הסכמה, כדי שהמשתמשים יוכלו לזהות סימני אזהרה.
• סימולציה של התקפות פישינג להסכמה לאפליקציות: הריצו בדיקות פישינג מדומות שמתמקדות בתהליכי OAuth כדי לבנות אינסטינקט ומוכנות אצל המשתמשים. עודדו את המשתמשים לדווח על בקשות חשודות ללא חשש.
• הפיכת תהליכי אישור אפליקציות לפורמליים: קבעו שכל שילוב של אפליקציית צד שלישי, במיוחד כזו שמבקשת הרשאות רגישות, חייב לעבור תהליך אישור בהובלת מחלקת IT לפני שמישהו יכול לאשר הסכמה.
• קמפיינים להעלאת המודעות למדיניות: השלימו את ההדרכה הטכנית בפוסטרים, תזכורות קבועות ורענון של המדיניות. הפכו החלטות בטוחות על הסכמה לנושא שוטף, ולא ל"הגדירו ושכחו".
• ניטור Shadow IT מצד המשתמש: שלבו את אכיפת תהליכי העבודה עם טכנולוגיה שמזהה וחוסמת ניסיונות להשתמש ב-SaaS לא מאושר או בסוכני AI לא מורשים. למידע נוסף על התמודדות עם אתגר ה-Shadow IT של AI, עיינו במדריך הממשל הזה.

היגיינה לצד הפיתוח והמלצות לאבטחת אפליקציות עבור ISVs ו-CISOs

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

כדאי גם להאזין לפרקים הבאים

אם אתם בוחנים את פישינג להסכמה ב-Microsoft 365, הפרקים האלה מוסיפים הקשר מעשי לאימוץ מאובטח של Microsoft 365, הגנת מידע, ממשל וניהול סיכוני AI.

• Microsoft Purview – Simply Explained — ראו כיצד סיווג, שמירה, ציות והגנה משתלבים במודל ממשל נתונים אחד של Microsoft.
• Microsoft Defender XDR – Simply Explained — חברו בין בקרות הגנת מידע לזיהוי, חקירה ותגובה.
• Conditional Access – Simply Explained — הבינו כיצד אותות זהות וסיכון מוסיפים הקשר להחלטות גישה.
• Microsoft AI Agent Harness – Simply Explained — גלו את הבקרות שהופכות אוטומציה מבוססת AI לאמינה, שקופה ובטוחה יותר.

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