הרשאות מואצלות לעומת הרשאות יישום

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

השוו בין הרשאות מואצלות להרשאות יישום ב-Microsoft Entra ID, ובחרו את מודל הגישה הנכון ל-APIs מאובטחים, לאוטומציה ולפיתוח אפליקציות.

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

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

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

רקע והקדמה למודלי הרשאות בזהויות של Microsoft

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

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

הרשאות יישום לעומת הרשאות מואצלות: מושגי יסוד ותרחישים מהעולם האמיתי

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

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

עם הרשאות יישום, האפליקציה עצמה מאמתת את עצמה בתור זהות משלה (service principal) ומקבלת אסימון משלה. זה מה שמניע אוטומציה ומשימות רקע, כמו אינטגרציית מערכות שמסנכרנת נתונים בין SharePoint למערכת ה-CRM שלכם בלילה. אין צורך באינטראקציה של משתמש; האפליקציה מבצעת משימות לפי לוח הזמנים שלה וברמת הגישה שלה—בכפוף לכל מה שמנהל מאשר.

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

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

בתוך הרשאות מואצלות של Microsoft Entra: זרימת אימות ומגבלות

הרשאות מואצלות ב-Microsoft Entra ID מובילות לתהליך אימות קלאסי שמונע על ידי המשתמש. התהליך מתחיל כאשר משתמש נכנס לאפליקציה שלכם באמצעות פרטי ההתחברות שלו ל-Microsoft. בשלב הזה האפליקציה מבקשת הרשאות ספציפיות – או היקפים (scopes) – ומציגה למשתמש (ולעיתים גם למנהל) בדיוק אילו סוגי נתונים או פעולות היא רוצה לגשת אליהם.

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

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

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

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

חשיפת יתר של הרשאות לאפליקציות ואבטחת אסימונים ב-Microsoft Entra ID

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

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

השיחה לא מסתיימת בחשיפת יתר של הרשאות. אסימונים ואישורי גישה – כולל סודות לקוח ותעודות – יכולים להפוך למטרה זהב לתוקפים אם אינם מאובטחים. סוד לקוח שדלף מרישום אפליקציה לבד (app-only) הוא כל מה שתוקף צריך כדי להתחזות לשירות שלכם. לכן היגיינת אישורים חיונית: השתמשו בזהויות מנוהלות (managed identities) כשאפשר, החליפו סודות באופן קבוע, ואל תאחסנו אישורי לקוח בקוד או בקבצים לא מוגנים. בסביבות שתלויות בגישה לא-אנושית, כדאי לשקול את Microsoft Entra Workload Identities, שמאפשרות גישה ללא סודות וניתנת לביקורת, ומבטלות את הכאב של חשבוני שירות מדור קודם. לצלילה מעמיקה יותר, ראו מדוע זהויות עומס עבודה (workload identities) הן חובה ל-Zero Trust.

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

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

• יישום בקרות מובנות של Entra לניהול הרשאותהשתמשו בתהליכי הסכמה מובנים של Microsoft Entra, בתהליכי אישור מנהל ובמדיניות מדויקת כדי להגביל את המשתמשים או הקבוצות שרשאים להעניק הרשאות. השתמשו במדיניות הסכמת מנהל כדי לוודא שרק אפליקציות שנבדקו מקבלות היקפי הרשאה בסיכון גבוה.
• אכפו את עקרון ההרשאה המינימליתהעניקו לאפליקציות רק את מערך ההרשאות המינימלי שנדרש לתפקידן. בדקו כל הרשאה שמתבקשת בזמן רישום האפליקציה, והסירו כל מה שאינו הכרחי. הרשאה מינימלית היא ההגנה החזקה ביותר שלכם מפני שימוש לרעה וחריגה מהרשאות.
• תזמנו סקירות והביקורות הרשאות באופן קבועהגדירו סקירות גישה שוטפות, באמצעות לוחות המחוונים של Entra להרשאות ולהסכמות, כדי לזהות ולבטל הרשאות שאינן בשימוש או מסוכנות. אם אפשר, הפכו את הבדיקות האלה לאוטומטיות כדי לאפשר ממשל מדורג, כפי שמתואר במדריכי ממשל מתקדמים כמו אסטרטגיית Microsoft Purview הזו.
• נטרו והתריעו על שינויים בהרשאותהקימו ניטור והתראות שיזהו הענקות OAuth חדשות, זינוקים בשימוש בהרשאות של אפליקציות, או אינטגרציות לא צפויות של מנהלים. דיווח פרואקטיבי נותן לכם זמן להגיב לפני שבעיות אבטחה מסלימות.
• אבטחו את אחסון הטוקנים וה-Credentialsאחסנו סודות של לקוחות וטוקנים בכספות מאובטחות כמו Azure Key Vault. החליפו פרטי גישה באופן קבוע, העדיפו תעודות על פני סודות משותפים, והעדיפו זהויות של עומסי עבודה כאשר משלבים גישה לא אנושית, שכן הן מספקות ניהול מחזור חיים וביקורתיות טובים יותר.
• אמצו ממשל מתקדם ואוטומציה של מדיניותהשתמשו בכלים כמו Microsoft Purview ו-Azure Policy כדי לאכוף בקרות ברמת הדייר כולו, לפלח סיכונים באמצעות Data Loss Prevention, ולתכנן לציות מתמשך. להתבוננות מעשית על שימוש במדיניות לממשל מתוך תכנון, ראו את אסטרטגיית הממשל הארגוני של Azure.

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

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

אם אתם בוחנים את delegated vs application permissions Entra ID, הפרקים האלה מוסיפים הקשר מעשי לאימוץ מאובטח של Microsoft 365, להגנה על מידע, לממשל ולניהול סיכוני AI.

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

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