מדריך תמחור של Microsoft Entra External Identities

By Mirko Peters · 2026-04-29 · Updated 2026-07-28

למדו על תמחור של Microsoft Entra External Identities עם הנחיות מעשיות לגבי ארכיטקטורה, אבטחה, ממשל, יישום ושימוש בעולם האמיתי.

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

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

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

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

איך פועל מודל החיוב החיצוני ב-Entra ID

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

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

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

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

מה נחשב למשתמש פעיל חודשי לצורך כניסות וחיוב

בעולמה של Entra ID, לא כל "משתמש" נחשב לחיוב. רק מי שמוגדר כמשתמש פעיל חודשי (MAU) למחזור החיוב הזה נספר. אז מה מפעיל את המתג? MAU הוא כל זהות חיצונית שמאמתת בהצלחה מול הדייר שלכם במהלך החודש. הדבר חל בין אם המשתמש משתמש בכניסה רגילה עם שם משתמש וסיסמה, OTP, כניסה דרך רשתות חברתיות או ספקי זהות מאוחדים.

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

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

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

חיבור נכון של דיירים חיצוניים למנויי Azure

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

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

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

שלבים לחיבור מנוי של דייר חיצוני

1. היכנסו לפורטל Azure כ-Global Administrator או כבעלים של מנוי היעד. נדרש תפקיד מתאים כדי לבצע שינויים ברמת המנוי.
2. נווטו אל החלונית Azure Active Directory, ולאחר מכן עברו לדייר שברצונכם לקשר כדייר חיצוני.
3. בדייר, היכנסו אל Subscriptions ובחרו Add או Associate. בחרו את מנוי Azure שברצונכם לקשר.
4. אשרו את השיוך והקצו את ההרשאות הנדרשות כדי לוודא שמנהלים יוכלו לנהל חיוב והגדרות הן עבור הדייר והן עבור המנוי המקושר.
5. לאחר החיבור, בדקו שוב את פרטי החיוב והחשבוניות בסעיף Cost Management + Billing. כך תזהו תצורות שגויות לפני שהן יגרמו לבעיות בהמשך.

פתרון תקלות: מה לעשות אם הדייר לא מקושר למנוי?

• בדיקת מצב הדייר: ודאו בפורטל Azure אם הדייר באמת יתום או שהתצוגה פשוט שגויה, על ידי בדיקת Subscription ID של הדייר ב-Entra.
• שיוך מנוי: אם הדייר אינו מקושר, השתמשו בהרשאות ניהול כדי לשייך אותו למנוי תקף מתוך Cost Management + Billing. חפשו את האפשרויות ל"קישור דייר".
• בעיות הרשאות: ודאו שיש לכם את תפקיד הניהול הנכון (Owner, Billing Administrator) כדי להימנע משגיאות גישה במהלך הקישור.
• פתרון התנגשויות בבעלות: אם לא ניתן לשייך את הדייר, בדקו אם קיימים קישורים או העברות קודמים, ופנו לתמיכת Microsoft אם נתקלתם בחסמים מתמשכים.

שיטות אימות והשפעתן על התמחור של Entra ID

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

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

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

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

שימוש ב-OTP ובהתחברות חברתית: השלכות על התמחור

• כניסות OTP: כל אימות מוצלח באמצעות קוד חד-פעמי (כמו דוא"ל או SMS) נספר כ-MAU לאותו חודש. אם משתמש מתחבר באמצעות OTP מספר פעמים בחודש, הוא עדיין נספר כ-MAU אחד, אבל כל אימות ראשון בכל תקופה מפעיל את החיוב.
• ספקי זהות חברתיים: כניסות באמצעות שירותים פופולריים, כמו Google, Facebook או LinkedIn, רושמות את המשתמש כ-MAU ברגע שהוא ניגש למשאב. כניסות נוספות באותו חודש אינן נספרות פעמיים, אך שימוש בחשבונות חברתיים שונים עבור אותה כתובת דוא"ל עלול להוביל ל-MAU חדשים.
• מקרי קצה: אם משתמש חיצוני עובר בין דיירים שונים (למשל, אם יש לכם חברות בת), כל כניסה לדייר ייחודי מפעילה MAU נוסף. לכן מיפוי ואיחוד של זהויות, במידת האפשר, עשויים להוריד את העלויות.

תרחישי אימות OpenID Connect, אפליקציות נייטיב ודפדפן

• OpenID Connect (OIDC): כשמשתמשים מאמתים באמצעות OIDC, כל כניסה ראשונית מוצלחת במחזור החיוב החודשי נספרת כ-MAU אחד. עם זאת, OIDC תומך ב-refresh tokens, ולכן כל עוד הטוקנים תקפים והסשנים לא פגו, משתמש לא נספר שוב כ-MAU חדש.
• אימות באפליקציות נייטיב: אפליקציות שמשתמשות בספריות הנייטיב של Entra ID (למשל MSAL) פועלות לפי כללים דומים: האימות הראשון נספר, אך רענון שקט של טוקן אינו נספר. אפליקציות שונות באותו דייר אינן מפעילות MAU נוספים כל עוד המשתמש פעיל.
• זרימות מבוססות דפדפן: סשנים בדפדפן עלולים להיות מורכבים: ניקוי עוגיות או פקיעת סשן עלולים לחייב אימות מחדש, וזה עשוי להיראות כמו MAU חדשים אם מדובר בסשן חדש לגמרי בחודש קלנדרי חדש. מודעות לכך יכולה לעזור בניהול הסשנים ובשליטה בעלויות.

טבלת השוואה: תמחור Entra External ID לעומת Azure AD B2C

• מודל תמחור: Entra External ID משתמש במדרגות מבוססות MAU, כך שהארגון משלם רק על משתמשים פעילים ייחודיים בחודש. Azure AD B2C התבסס באופן מסורתי יותר על עסקאות או עלויות לכל אימות, אם כי מודלים אחרונים עברו ל-MAU לשם פשטות.
• תכונות כלולות: שניהם מציעים איפוס סיסמה בשירות עצמי, אימות רב-שלבי וניהול משתמשים ברמת הבסיס. Entra External ID נותן שילוב עמוק יותר עם Microsoft 365, ואילו B2C מתמקד בתרחישים מול לקוחות עם מסעות משתמש הניתנים להתאמה אישית.
• אפשרויות תמיכה: התמיכה ב-Entra External ID היא חלק מערוצי התמיכה הרגילים של Microsoft. ל-B2C יש רמות תמיכה משלו, אך מענה מגובה SLA עשוי לדרוש תוכניות פרימיום.
• מקרי שימוש: Entra External ID הוא הבחירה המתאימה ביותר לשיתוף פעולה עסקי מול עסקים (B2B), שותפים או אורחים, במיוחד בתוך המערכת האקולוגית של Microsoft 365 ו-Azure. Azure AD B2C עדיף ליישומים עסקיים מול לקוחות (B2C) הדורשים מיתוג לבן (white-label) ואפשרויות כניסה גמישות.
• שיקולי מעבר: המעבר מ-B2C ל-Entra ID דורש מיפוי זהויות זהיר, אבל מאפשר ממשל הדוק יותר, עם סיכון אפשרי לתלות בספק. למידע על מעבר, כדאי לעקוב אחר הנחיות בנושא תלות בספק ופריסה מדורגת.

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

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

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

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

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

אסטרטגיות לניהול סשנים וטוקנים להפחתת MAU

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

ניהול זרימות משתמשים היברידיות כדי להימנע מחיוב כפול

• הקצאה מבוססת תפקידים: הגדירו בבירור ואכפו מתי משתמש נחשב "פנימי" לעומת "חיצוני", כדי שלא יחויבו פעמיים על אותו אדם.
• מאגרי זהויות מאוחדים: היכן שניתן, השתמשו במקור אמת יחיד לזהויות, de facto ב-Azure AD/Entra, כדי למנוע רשומות כפולות בין סביבות.
• מדיניות קבוצות אוטומטית: נצלו קבוצות דינמיות והקצאות אוטומטיות ב-Entra כדי להתאים את הסטטוס וההרשאות של המשתמש כשהתפקידים שלו משתנים.
• נוהלי ביקורת חיוב: תזמנו ביקורות קבועות לבדיקת חשבונות חופפים או מעברים, ותקנו אותם לפני שהם מנפחים את החשבונית.

סיכום: עיקרי הדברים ורשימת יישום לתמחור Entra ID

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

1. הבינו את מודל החיוב: משלמים לפי Monthly Active Users (MAU). כל משתמש חיצוני ייחודי שמתחבר במהלך חודש נספר, ולכן יותר התחברויות פירושן יותר חיובים. עקבו אחר מה שתורם ל-MAU שלכם.
2. נהלו קישור של דיירים ומנויים: ודאו שכל דייר חיצוני מגובה למנוי Azure הנכון. טעויות כאן עלולות להוביל לאובדן נתוני שימוש או לחיובים מפתיעים.
3. בחרו שיטות אימות בתבונה: לא כל ההתחברויות שוות. קוד OTP באימייל עלול להגדיל עלויות בגלל דמי משלוח או פניות לתמיכה, בעוד שהתחברויות חברתיות או זהויות מאוחדות (federated) עשויות לחסוך כסף בתרחישים של נפח גבוה.
4. בצעו אופטימיזציה להגדרות סשן וטוקן: כווננו את משך הסשן ואת פסקי הזמן לחוסר פעילות כדי להימנע from נפיחת MAU בשל התחברויות חוזרות מיותרות. שימוש חוזר בטוקנים הוא חבר טוב כאן, לצמצום משתמשים "פעילים" עודפים.
5. תכננו זרימות היברידיות ותפקידי משתמש מדויקים: שימו לב למשתמשים שעוברים בין פנימי לחיצוני. קל מאוד לחייב פעמיים בטעות אם לא שומרים על זרימות מסודרות וקטגוריות ברורות.

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

כדאי גם להאזין ל

אם אתם חוקרים את תמחור Microsoft Entra external identities, הפרקים הבאים מוסיפים הקשר מעשי על אבטחת זהויות, ממשל, בקרת גישה ותפעול Microsoft 365:

• Privileged Identity Management – Simply Explained — הבינו הרשאות מנוהלות לפי זמן דרישה (just-in-time), אישורים וסקירות גישה.
• Conditional Access – Simply Explained — למדו איך מדיניות מודעת-הקשר מגינה על משתמשים ומכשירים.
• Microsoft Defender XDR – Simply Explained — חברו בין אותות זהות לזיהוי, לחקירה ולתגובה.
• Microsoft Teams Governance – The Illusion of Control — ראו כיצד ממשל תקין יוצר בעלות ובקרות הניתנות לחזרה.

איך לאמוד את התמחור של Microsoft Entra External Identities

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

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

גורמי עלות של זהויות חיצוניות לתיעוד

שאלות נפוצות

מה ההבדל בין זהות חיצונית לחשבון אורח?

External identities הוא תחום היכולות הרחב של Microsoft Entra עבור אנשים מחוץ לדייר הארגוני. גישת אורחים היא דפוס שיתוף פעולה נפוץ בתוך מודל הגישה החיצונית הרחב יותר.

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

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

נבדק לאחרונה: יולי 2026.

🎧 כדאי גם להאזין ל

• ממשל זהויות ב-Microsoft Entra

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

• Microsoft Entra Private Access – הסבר פשוט

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

• מדיניות גישה מותנית לאורחים ב-Microsoft Entra ID

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