זהויות מנוהלות ב-Azure: מוקצית-מערכת או מוקצית-משתמש? איזו לבחור?

By Mirko Peters · 2026-10-26

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

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

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

עיקרי הדברים

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

הבנת ההבדלים המרכזיים

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

איך פועלות זהויות מוקצות-מערכת

זהות מנוהלת מוקצית-מערכת מופעלת ישירות בתוך משאב Azure מסוים, כמו Azure Virtual Machine, App Service או Function App. אפשר לחשוב עליה כזהות שנולדת יחד עם המשאב ומתה יחד איתו. כאשר מפעילים זהות מוקצית-מערכת במכונה וירטואלית, Azure יוצר ב-Microsoft Entra ID זהות שנושאת את שם המשאב בדיוק.

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

איך פועלות זהויות מוקצות-משתמש

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

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

ניהול מנהלתי והקצאות תפקידים

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

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

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

מלכודות ארכיטקטוניות ומקרי קצה

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

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

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

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

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

סיכום

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

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

שאלות נפוצות

האם משאב Azure יחיד יכול להשתמש גם בזהות מנוהלת שהוקצתה על ידי המערכת וגם בזהות מנוהלת שהוקצתה על ידי המשתמש?

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

מה קורה לזהות שהוקצתה על ידי המשתמש כשמשאב Azure שהיא מחוברת אליו נמחק?

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

מדוע Microsoft ממליצה על זהויות שהוקצו על ידי המשתמש ברוב התרחישים שבהם מעורבים כמה משאבים?

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

האם זהויות מנוהלות עולות כסף ב-Azure?

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