זהויות מנוהלות לעומת רישומי אפליקציות ב-Azure: ההבדלים המרכזיים ושיטות עבודה מומלצות

By Mirko Peters · 2026-04-28

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

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

Cover: Stop OAuth Consent Attacks in Microsoft Entra ID

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

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

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

זהויות מנוהלות הן התשובה של Azure לאימות ללא סודות. במקום להתעסק עם סיסמאות אפליקציה ותעודות, אפשר להעניק למשאב של Azure (למשל מכונה virtual, App Service או Logic App) זהות משלו ב-Entra ID. הזהות הזו מנוהלת אוטומטית על ידי Azure: היא נוצרת יחד עם המשאב, נמחקת אם מוחקים את המשאב, והחשוב מכול—לעולם אינה חושפת אתכם להעברת סודות בין גורמים. קיימות שתי צורות של זהויות מנוהלות: מוקצית-מערכת (אחת לכל משאב, סגורה היטב) ומוקצית-משתמש (ניתנת לשימוש חוזר בכמה משאבים).

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

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

הבדלי ליבה: מחזור חיים, אבטחה ואינטגרציה ב-Azure

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

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

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

בכל הנוגע לאבטחה, ההבדל ברור: לזהויות מנוהלות (managed identities) יש אימות ללא סודות, הקשור למשאבי Azure, ואילו רישומי אפליקציות (app registrations) נשענים על סודות סטטיים או על אישורים. לכן מעדיפים זהויות מנוהלות בכל מקום שבו סודות מהווים סיכון, או שבו אוטומציה היא העיקר.

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

Service Principals, תפקידי RBAC והרשאות Microsoft Graph

עכשיו, בואו נציץ קצת מאחורי הקלעים. מתחת למכסה המנוע, גם זהויות מנוהלות וגם רישומי אפליקציות משתמשים בentity service principals ב-Entra ID. חשבו על service principal כעל הזהות האמיתית והפעילה שאותה Entra ID מכירה. בין אם היא נוצרה מזהות מנוהלת ובין אם מרישום אפליקציה, זהו האובייקט הזה שמקבל הרשאות וגישה בדייר שלכם.

בעבור רישומי אפליקציות, כשמוסיפים אפליקציה חדשה, Entra יוצר service principal תואם עבור כל דייר שאליו משויכת האפליקציה. זו הזהות שבה תשתמשו כדי להקצות תפקידי RBAC של Azure, כמו Contributor או Reader, ולהעניק הרשאות Graph API, בין אם מואצלות (delegated) ובין אם ברמת אפליקציה (application).

זהויות מנוהלות שונות במקצת, אך בנויות על אותו בסיס. הפעלת זהות מנוהלת עבור משאב Azure מורה ל-Entra ליצור service principal ייעודי שחי ומת יחד עם המשאב. לאחר מכן מקצים לזהות הזו ישירות תפקידי RBAC (כמו Key Vault Reader), והמשאב מקבל גישה באמצעות טוקנים מאחורי הקלעים. ללא שינויי קוד, וללא סודות שמסתובבים לכל מקום.

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

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

בחירת המודל המתאים: תרחישים, מעבר וממשל

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

זהויות מנוהלות מצטיינות בעומסי עבודה שרצים ישירות בתוך Azure ורק צריכים גישה בתוך אותו דייר. למשל, מכונות וירטואליות שמריצות סקריפטים, שירותי App Service שמתחברים ל-Key Vault, או Logic Apps שמבצעים שאילתות ל-Microsoft Graph. האבטחה טובה יותר, ההקמה מהירה יותר, ויש פחות ניהול סודות. אבל אם אתם מריצים SaaS, פתרונות מרובי דיירים, או סביבות היברידיות (כמו אפליקציות מקומיות שניגשות ל-APIs בענן), רישומי אפליקציות הם עדיין הבחירה המועדפת בזכות הגמישות והתאימות הרחבה שלהם.

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

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

מדיניות ממשל חזקה מחברת את כל האסטרטגיה יחד. שימוש ב-Azure Policy, ב-Privileged Identity Management ובבדיקות תאימות שגרתיות מבטיח שתאכפו הרשאות מינימליות, תזהו סטייה ותתאימו לגישת אפס אמון. לבדיקת מציאות על חשבונות שירות לעומת זהויות עומס עבודה אמיתיות (ולמה גישות ישנות לא מספיקות), עיינו בניתוח הזה על הסיכון של זהויות שאינן אנושיות ו-Microsoft Entra Workload Identities. רוצים את יסודות הממשל במלואם? המשאב אסטרטגיית ממשל ארגוני מלא בשיטות עבודה מומלצות.