Microsoft Entra ID בהסבר: יסוד הזהויות עבור Microsoft 365 ו-Azure

By Mirko Peters · 2026-08-27 · Updated 2026-09-13

הכירו את Microsoft Entra ID, לשעבר Azure AD: משתמשים, קבוצות, אפליקציות, SSO, MFA, Conditional Access וניהול זהויות ב-Microsoft 365 וב-Azure.

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

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

אם אתם פועלים בתחום ה-IT כבר זמן מה, סביר להניח שאתם זוכרים את התקופה שבה הזהות הייתה קשורה למכונה פיזית שעמדה בחדר שרתים והריצה Windows Server Active Directory. כשארגונים החלו לעבור לענן, הפרדיגמה הזו השתנתה לחלוטין. אבטחה מבוססת היקף רשת התיישנה כמעט בן לילה. כיום, היקף הרשת כבר אינו מוגדר על ידי חומות אש וכתובות IP, אלא על ידי הזהות. Microsoft Entra ID הוא המנצח על היקף חדש זה. בפוסט הבלוג המלווה והמקיף הזה נרחיב על המושגים המרכזיים שדנו בהם בפודקאסט, ונפרק את הנושאים של משתמשים, קבוצות, ניהול אפליקציות, מנגנוני אימות ותהליכי ממשל, כדי שתוכלו לאבטח ולייעל את סביבת הענן של הארגון שלכם.

מבוא ל-Microsoft Entra ID ולניהול זהויות מודרני

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

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

Microsoft Entra ID הוא שירות לניהול זהויות והרשאות גישה (IAM) מבוסס ענן, שתוכנן לאבטח ולנהל זהויות בסביבות היברידיות ומרובות עננים. זהו אינו רק גרסת ענן של Windows Server Active Directory; הוא נבנה מהיסוד במיוחד עבור עומסי עבודה בענן בקנה מידה של האינטרנט, פרוטוקולי אימות מבוססי רשת ואינטגרציות מבוססות API. בין אם עובד נכנס ל-Microsoft 365 כדי לבדוק את Outlook, מפעיל מכונה וירטואלית ב-Azure או מתאמת למערכת משאבי אנוש חיצונית, Microsoft Entra ID מאמת את זהותו, מעריך את הסיכון שבחיבור ומאכוף מדיניות ארגונית תוך אלפיות השנייה.

רכיבי הליבה: משתמשים, קבוצות ומכשירים

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

ניהול משתמשים בענן

משתמשים ב-Entra ID מייצגים זהויות אישיות שזקוקות לגישה למשאבי הארגון. אלה יכולים להיות עובדים פנימיים, קבלני משנה חיצוניים, ארגוני שותפים, או אף חשבונות שירות ואפליקציות אוטומטיים (המכונים לעיתים קרובות service principals או managed identities). מחזור החיים של המשתמשים דורש ניהול קפדני – מהקמה עם קליטת העובד, דרך שינויי תפקיד במהלך העבודה, ועד ביטול מיידי של הגישה עם העזיבה.

ארגונים בדרך כלל מאמצים אחד משני מודלים לניהול משתמשים:

• זהויות ענן בלבד: נוצרות ומנוהלות כולן בתוך Entra ID. זהו מצב נפוץ בסטארטאפים שנולדו בענן או עבור חשבוני אורח ספציפיים.
• זהויות היברידיות: מסונכרנות מסביבת Active Directory מקומית באמצעות כלי בשם Microsoft Entra Connect (או Entra Cloud Sync). כך ארגונים יכולים להמשיך להפעיל בקרי הדומיין המסורתיים שלהם, ובו בזמן להרחיב את זהויות המשתמשים לענן בצורה חלקה, ולאפשר חוויית כניסה יחידה (SSO).

הכוח של קבוצות

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

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

מכשירים כאזרחים מן המעלה הראשונה

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

ניהול יישומי ארגון ושילובי SaaS

אחת היכולות החזקות ביותר של Microsoft Entra ID היא היכולת לשמש כספק זהויות (IdP) עבור אלפי יישומי ענן משולבים מראש דרך גלריית היישומים של Entra. בין אם הארגון שלכם מסתמך על Adobe, Zoom, Workday או על יישומי web פנימיים שנבנו בהתאמה אישית, Entra ID מרכז את הגישה ליישומים.

יישומי ארגון לעומת רישומי יישומים

כאשר עובדים עם יישומים ב-Entra ID, חיוני להבין את ההבדל בין יישומי ארגון לבין רישומי יישומים:

• יישומי ארגון: אלה הייצוגים המקומיים (או service principals) של יישומים שהוגדרו כך שיסמכו על Entra ID לצורך כניסה יחידה (SSO). זהו המקום שבו מנהלי IT מקצים משתמשים וקבוצות, מגדירים מדיניות גישה מותנית ליישומים ספציפיים ומנהלים הקצאת משתמשים (provisioning).
• רישומי יישומים: אלה מייצגים את ההגדרה הגלובלית של יישום שמפתחים בתוך הארגון בונים. הם מגדירים כיצד היישום משתלב עם פלטפורמת הזהויות של Microsoft, אילו הרשאות הוא דורש, ובאילו סודות אימות או תעודות הוא משתמש.

כניסה יחידה (SSO) ופדרציה

עברו הימים שבהם משתמשים נדרשו לזכור תריסר סיסמאות שונות עבור תריסר יישומי עבודה שונים. Entra ID תומך בפרוטוקולי אימות מודרניים כגון Security Assertion Markup Language (SAML) 2.0 ו-OpenID Connect (OIDC) לאפשר כניסה יחידה חלקה. משתמשים מאמתים פעם אחת מול Entra ID, ויישומי SaaS מהימנים מקבלים את אסימון האימות הזה ומעניקים גישה מיידית ומאובטחת.

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

אבטחת אימות ובקרת גישה

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

אימות רב-שלבי (MFA)

הפעלת אימות רב-שלבי היא ללא ספק אמצעי האבטחה המשפיע ביותר שארגון יכול ליישם. Microsoft Entra ID הופך את פריסת ה-MFA לגמישה וידידותית למשתמש, ותומך בשיטות כגון אפליקציית Microsoft Authenticator (עם התראות push והתאמת מספרים), מפתחות אבטחה מסוג FIDO2, אסימונים פיזיים, ושיחות SMS או קוליות (אם כי מומלץ בחום להעדיף התראות push באפליקציה ומפתחות חומרה על פני SMS, בשל הפגיעות להתקפות החלפת כרטיס SIM).

כדי לבטל לחלוטין את הסיסמאות, Entra ID תומך בשיטות אימות ללא סיסמה, לרבות Windows Hello for Business, מפתחות אבטחה מסוג FIDO2 וכניסה באמצעות הטלפון דרך אפליקציית Microsoft Authenticator. אימות ללא סיסמה מספק חוויית משתמש טובה בהרבה ובו בזמן מנטרל את גניבת פרטי ההתחברות.

Conditional Access: מנוע המדיניות החכם

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

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

תהליך טיפוסי של מדיניות Conditional Access נראה כך:

• אם משתמש מנסה לגשת ליישום פיננסי רגיש מאוד...
• וגם רמת הסיכון של הכניסה שלו מוערכת כבינונית או גבוהה על ידי Microsoft Entra Identity Protection...
• אז אשר את הגישה, אך דרוש אימות רב-שלבי ואיפוס סיסמה, או חסום את הגישה לחלוטין עד לטיפול בסיכון.

Conditional Access מאפשר לארגונים לעבור from אבטחת היקף נוקשה לארכיטקטורה חזקה של Zero Trust – לעולם אל תסמוך, תמיד אמת, והנח שיש פריצה.

הבנת הרשאות, תפקידים והאצלה

לאחר שמשתמש אומת בהצלחה ועבר את כל בדיקות Conditional Access, מה מותר לו לעשות? ניהול הרשאות ב-Microsoft Entra ID דורש הבנה מעמיקה של הרשאות, תפקידי ניהול ומודלים של האצלה.

תפקידים מובנים ב-Microsoft Entra

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

Entra ID מספק מגוון רחב של תפקידי ניהול מובנים ומדויקים. לדוגמה:

• User Administrator: יכול לנהל את כל ההיבטים של משתמשים וקבוצות, לרבות איפוס סיסמאות למשתמשים שאינם מנהלים.
• Helpdesk Administrator: יכול לאפס סיסמאות למשתמשים שאינם מנהלים ולתפקידי תמיכה מסוימים, אך אינו יכול ליצור משתמשים או לשנות הגדרות אבטחה גלובליות.
• Conditional Access Administrator: יכול ליצור ולנהל מדיניות Conditional Access ללא גישה לחשבונות משתמשים או לנתוני חיוב.
• Global Administrator: תפקיד הניהול הגבוה ביותר, עם גישה מלאה לכל תכונות הדיירקטורי. יש להגביל תפקיד זה בקפדנות למספר קטן מאוד של אנשים (רצוי פחות מחמישה) ולנטר אותו היטב.

ניהול זהויות מיוחדות (PIM)

גם עם תפקידים מדויקים, הרשאות ניהול קבועות מהוות סיכון אבטחה משמעותי. אם פרטי ההתחברות של Global Administrator נפרצים, לתוקף יש את המפתחות לממלכה כולה. כאן נכנס לתמונה Microsoft Entra Privileged Identity Management (PIM).

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

שיטות עבודה מומלצות לניהול Entra ID בארגון

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

1. אכיפת MFA עמיד לפишינג לכולם

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

2. אימוץ Zero Trust עם תבניות בסיס של Conditional Access

הטמיעו מיד סט בסיסי של מדיניות Conditional Access. לכל הפחות, חסמו פרוטוקולי אימות מדור קודם (שאינם תומכים בבקרות אבטחה מודרניות), דרשו מכשירים תואמים לגישה למידע הארגוני, והגדירו מדיניות מבוססת סיכון שמסתגלת באופן דינמי להתנהגות כניסה חשודה.

3. ביקורת וצמצום של Global Administrators

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

4. ניצול ניהול זהויות מיוחדות (PIM)

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

5. בדיקה קבועה של גישת אורחים ושיתוף פעולה B2B

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

סיכום

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

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