האם Microsoft Entra Agent IDs שומרים סיסמאות או סודות באופן מקומי?

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

כיצד Blueprints של סוכנים מטפלים בפריסות מרובות דיירים?

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

מה קורה לסוכן AI אם האדם שמשמש לו כספונסור עוזב את החברה?

Microsoft Entra מעביר אוטומטית את הספונסורשיפ של זהות הסוכן למנהל הישיר של הספונסור שעזב, כדי למנוע התפשטות בלתי מנוהלת.

האם ניתן להחיל מדיניות Conditional Access ישירות על זהויות של סוכנים?

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

Microsoft Entra Agent ID לעומת Service Principals: באיזה מהם כדאי לסוכני ה-AI שלכם להשתמש?

By Mirko Peters · 2026-10-26

השוו בין Microsoft Entra Agent ID ל-Service Principals. גלו מדוע סוכני AI זקוקים למסגרות זהות ייעודיות וממשל מבוסס Blueprint ב-M365.

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

Cover: Microsoft Entra Agent ID - Simply Explained

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

עיקרי הדברים

Service principals קושרים אישורים והרשאות ישירות לאפליקציה בודדת, ולכן קשה לעקוב אחר סוכני AI בעלי קצב גבוה וקצרי מועד ולאבטח אותם.
Microsoft Entra Agent ID מנתק את האישורים על ידי אחסונם ב-Blueprint מרכזי, ומקצה זהויות סוכן ייחודיות לכל עובד בנפרד.
זהויות סוכנים מבטלות סודות מקומיים על גבי הסוכן עצמו, ובכך מצמצמות באופן משמעותי את רדיוס הפגיעה אם רכיב כלשהו ייפרץ.
Blueprints מאפשרים למנהלים להחיל מדיניות בכמות גדולה, לנהל בקרות מחזור חיים, ולשמש מתג כיבוי מוחלט למשפחות שלמות של סוכני AI.
Managed identities נשארות אידיאליות לקוד המאורח ב-Azure, ואילו Agent IDs נועדו במיוחד לסוכני AI אוטונומיים שמקבלים החלטות עצמאיות בזמן ריצה.

הבנת פער הזהות של עובדי AI

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

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

Service Principals לעומת Agent IDs: הבדלים ארכיטקטוניים

כדי להבין מדוע Microsoft Entra Agent ID מייצג שינוי פרדיגמה, יש להבין כיצד הוא שונה מבחינה מבנית מ-service principal סטנדרטי. Service principal הוא מופע אחד-לאחד של אובייקט אפליקציה בדייר שלכם. הוא מחזיק בסודות ארוכי טווח משלו, בתעודות לקוח ובהקצאות הרשאות ישירות. עבור אפליקציות web יציבות וצפויות ותהליכי רקע (daemons), מודל זה עבד היטב במשך שנים.

עם זאת, כפיית סוכן AI להשתמש ב-service principal סטנדרטי יוצרת חיכוך ניהולי חמור:

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

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

כוחה של תבנית ה-Blueprint בניהול צי של סוכנים

החידוש המרכזי של Microsoft Entra Agent ID טמון באובייקט ה-blueprint. ניתן לחשוב על ה-blueprint כעל תבנית מאסטר המנהלת צי של עובדי AI קשורים זה לזה. לדוגמה, אם הארגון שלכם פורס תבנית בשם 'Sales Assistant Agent', ניתן ליצור באופן דינמי מופעים אזוריים לצפון אמריקה, דרום אמריקה ואירופה מתוך אותה הגדרה אחת.

מכיוון שהסוכנים חולקים blueprint משותף, למנהלים יש יכולות ניהול חזקות שמתרחבות בקלות:

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

מתי להשתמש בכל סוג זהות בארכיטקטורה שלכם

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

Managed Identities לקוד שרץ ב-Azure

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

Service Principals ליישומים מסורתיים

יש להמשיך להשתמש ב-service principals סטנדרטיים עבור יישומי ארגון יציבים, אינטגרציות SaaS ושירותי daemon ארוכי טווח הדורשים הקשרי יישום ייעודיים ומתמשכים ותהליכי client credentials מסורתיים.

Agent IDs לעובדי AI אוטונומיים

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

אבטחת העתיד הענני שלכם

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

שאלות נפוצות

האם זהויות Microsoft Entra Agent ID שומרות סיסמאות או סודות באופן מקומי?

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

כיצד תבניות סוכנים מטפלות בפריסות רב-דיירים?

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

מה קורה לסוכן AI אם נותן החסות האנושי שלו עוזב את החברה?

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

האם ניתן להחיל מדיניות גישה מותנית ישירות על זהויות של סוכנים?

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