כיצד Managed Identities מבטלות סיסמאות קשיחות (Hardcoded) ב-Azure

By Mirko Peters · 2026-08-13

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

Cover: Entra Workload Identities - Simply Explained

ברוכים השבים לבלוג המלווה לפודקאסט שלנו! אם אתם בונים אפליקציות כבר תקופה לא קצרה, סביר להניח שנתקלתם בבעיה הוותיקה של חיבור הקוד שלכם למסד נתונים, ל-API או לחשבון אחסון בענן. בעבר, מפתחים פתרו זאת בכך שהכניסו מחרוזת חיבור, סיסמה למסד נתונים או Client Secret ישירות לקובץ הגדרות, למשתנה סביבה, או — גרוע מכך — קידדו אותם בקשיחות בתוך מאגר קוד המקור. כל עוד האפליקציה יכולה לקרוא את הסוד, היא יכולה להתאמת ולבצע את עבודתה. אבל מה קורה כאשר הקוד הזה נדחף בטעות למאגר GitHub ציבורי? מה קורה כאשר עובד מתוסכל עוזב, או תוקף מקבל גישת קריאה להגדרות האפליקציה שלכם? במקרה כזה, כל התשתית שלכם נפרצה במיידי. בארכיטקטורת ענן מודרנית, זה סיכון בלתי מקובל. היום אנחנו צוללים לעומק כדי להבין כיצד Managed Identities ב-Microsoft Azure מבטלות לחלוטין את הצורך בסיסמאות קשיחות, ומחליפות סודות סטטיים באסימוני גישה דינמיים וקצרי מועד.

מבוא לאבטחת ענן וסודות קשיחים

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

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

הבנת זהויות משתמש לעומת זהויות עומס עבודה ב-Entra ID

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

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

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

פענוח רישומי אפליקציות, אבטחת שירות (Service Principals) וזהויות מנוהלות

אם ביליתם זמן מה בהגדרת אפליקציות ב-Microsoft Entra ID, בטוח נתקלתם בשלושה מונחים שגורמים לבלבול לעיתים קרובות: App Registrations, Service Principals ו-Managed Identities. בואו נפרק אותם בפשטות.

רישום אפליקציה (Application Registration) הוא ההגדרה הגלובלית, או התבנית, של האפליקציה שלך. כאשר אתם רושמים אפליקציה ב-Microsoft Entra ID, אתם יוצרים את הזהות הגלובלית שלה בכל המערכת האקולוגית הרב-דיירית. כאן מגדירים אילו הרשאות האפליקציה עשויה לדרוש, אילו נקודות קצה לאימות היא משתמשת בהן ואילו URI משויכים אליה. חשבו על רישום האפליקציה כעל תבנית הדרכון.

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

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

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

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

כאשר האפליקציה שלכם זקוקה לגישה למשאב מוגן, כמו מסד נתונים או API, היא לא מחפשת סיסמה שמורה. במקום זאת, היא מבצעת קריאה מקומית לנקודת הקצה של Azure Instance Metadata Service (IMDS), שזמינה באופן מאובטח רק מתוך אותו משאב Azure ספציפי. הפלטפורמה הבסיסית של משאב Azure מבקשת מ-Microsoft Entra ID, בשם האפליקציה, אסימון JSON Web Token (JWT) בעל תוקף קצר.

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

שילוב של Azure Key Vault ואסימוני גישה קצרי חיים

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

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

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

אבטחת זהויות עומסי עבודה באמצעות הרשאות מינימליות וממשל

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

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

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

בחירת אסטרטגיית הזהות הנכונה לכל עומס עבודה בענן

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

אם הקוד שלכם פועל בתוך Microsoft Azure, בין אם ב-Azure App Services, ב-Azure Functions, במכונות וירטואליות, ב-Container Instances או ב-Azure Kubernetes Service, הבחירה הראשונה שלכם צריכה להיות תמיד Managed Identity. ניתן לבחור בין System-Assigned Managed Identity (שמחזור החיים שלה קשור ישירות וביחס של 1:1 למשאב של Azure) לבין User-Assigned Managed Identity (שניתן ליצור באופן עצמאי ולהקצות למספר משאבים של Azure, לניהול קל יותר).

אם האפליקציה שלכם פועלת מחוץ ל-Azure, למשל על שרתים מקומיים (on-premises), ב-AWS או כחלק מצינור CI/CD ב-GitHub Actions, Managed Identities שמתארחות ישירות בתשתית של Azure אינן אפשרות. בתרחישים כאלה כדאי להשתמש ב-Workload Identity Federation. היא מאפשרת לפלטפורמות חיצוניות להחליף טוקנים ישירות עם Microsoft Entra ID באמצעות אמון OpenID Connect (OIDC), וכך מבטלת לגמרי את הצורך לנהל, לסובב או לאחסן סודות לקוח ארוכי טווח.

לבסוף, באפליקציות ארגוניות מסורתיות שדורשות אימות לקוח, במקרים שבהם אין אפשרות להשתמש לא ב-Managed Identities ולא בפדרציה, יש לתת תמיד עדיפות לתעודות מנוהלות היטב על פני סודות לקוח ארוכי טווח. על ידי שילוב של Microsoft Entra Workload Identities, Azure Key Vault, עקרונות Zero Trust וגישה לפי הרשאות מינימליות, הארגון שלכם יוכל לחסל לחלוטין סיסמאות קשיחות בקוד ולבנות ארכיטקטורת ענן עמידה להפליא.

סיכום והצעדים הבאים לאבטחת ענן מודרנית

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

כדי להתעמק עוד יותר בנושא ולשמוע טיפים מעשיים מהשטח, הקפידו לצפות בפרק הפודקאסט הקשור: Entra Workload Identities - Simply Explained. הצטרפו אלינו כשנפרק את המושגים האלה עוד יותר, כדי שתוכלו לאבטח את סביבות Azure ו-Microsoft 365 שלכם כמו מקצוענים!