ביצוע מעבר חלק ל-Microsoft Entra ID

By Mirko Peters · 2026-08-22

למה לעבור ל-Microsoft Entra ID עכשיו? ארגונים עוברים יותר ויותר ממערכות זהות מפוצלות לפישוט ניהול הגישה. המעבר ל…

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

למה לעבור ל-Microsoft Entra ID עכשיו?

ארגונים מתרחקים יותר ויותר ממערכות זהות מפוצלות, כדי לפשט את ניהול הגישה. המעבר ל-Microsoft Entra ID (לשעבר Azure Active Directory) מספק פלטפורמת זהות אוניברסלית שמרכזת אימות הן למשאבים בענן והן למשאבים מקומיים. בניגוד לספקים מדור קודם כמו SiteMinder, שמסתמכים על אימות מבוסס כותרות, Entra ID תומך בפרוטוקולים מודרניים כמו SAML, OpenID Connect ו-OAuth, כדי לאבטח סביבות עבודה היברידיות.

איחוד תשתית הזהות מאפשר לאמץ אמצעי אבטחה עמידים להונאה (phish-resistant), שמערכות מקומיות ישנות מתקשות לתמוך בהם באופן מובנה. באמצעות המעבר, הצוותים יכולים להפיק תועלת מיכולות ממשל אוטומטיות, כולל גישה מוגבלת בזמן באמצעות Privileged Identity Management וניהול מחזור חיים יעיל. יתרה מכך, הפלטפורמה מאפשרת שיטות כניסה ללא סיסמה כמו מפתחות FIDO2 ואפליקציית Microsoft Authenticator, ומפחיתה באופן משמעותי את הסיכון לגניבת אישורי גישה.

פודקאסט M365 FM מסקר באופן קבוע מעברים כאלה, ועוזר לארכיטקטים לנווט בדרך ממערכת Active Directory Federation Services מדור קודם לאימות מבוסס ענן. לפי מחקר רב-ענני משנת 2025, 75% מהארגונים מנהלים כיום שני ספקי זהות או יותר. עם זאת, ריכוז הניהול במישור בקרה אחד מפחית חוב טכני ומשפר את תנוחת ה-Zero Trust הכוללת שלכם.

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

לפני שמתחילים בסנכרון כלשהו, יש לבצע ביקורת מעמיקה של התלויות המקומיות הקיימות. זה כולל מיפוי של שירותים קריטיים כמו DNS, Group Policy Objects, ויישומים מדור קודם שעשויים להסתמך על Kerberos או NTLM. אל תתעלמו מרכיבי תשתית כמו ממסרי SMTP, שרתי RADIUS והגדרות אימות של מדפסות, שכן אלה לעיתים קרובות נשברים במהלך lift-and-shift. בעוד שפודקאסט M365 FM מדגיש את המעבר לפרוטוקולים מודרניים, ארגונים רבים עדיין מארחים עומסי עבודה מדור קודם הדורשים מסלולי קישוריות ספציפיים.

הגדרת מצב היעד שלכם

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

• בצעו ביקורת של פרוטוקולי אימות מדור קודם, כולל LDAP ו-Kerberos, שלעיתים קרובות אין להם מקבילה ישירה בענן.
• נקו חשבונות ישנים ופתרו אי-התאמות ב-UPN כדי למנוע שגיאות סנכרון.
• שטחו קבוצות מקוננות היכן שאפשר, שכן הן עלולות ליצור מבני הרשאות מורכבים ובלתי מכוונים בענן.
• בדקו אם פתרונות MDM של צד שלישי או דרישות רשת מנותקות מחייבות להשאיר את AD FS לתקופה ארוכה מהמתוכנן.

המעבר למודל זהות מבוסס ענן מתחיל בביקורת מקיפה של הסביבה הקיימת. לאחר שתבינו את היקף הנוכחות שלכם, הטמיעו בסיס זהות היברידי באמצעות Microsoft Entra Connect כדי לסנכרן את הספרייה. צעד קריטי הבא הוא המעבר מ-AD FS לשיטות אימות מבוססות ענן, כגון Password Hash Sync או Pass-Through Authentication, תוך שימוש ב-AD FS Application Migration Wizard להגדרה מחדש של אפליקציות הסומכות (Relying Party) ל-Microsoft Entra ID. לאורך התהליך, השתמשו בכלי אבטחה להגנה על התשתית. לבסוף, לאחר שהאפליקציות והמשתמשים הועברו במלואם, ניתן לבטל בשיטתיות את שרתי בקר הדומיין המקומיים הישנים.

בדיקת אימות בענן באמצעות Staged Rollout

המעבר מ-Active Directory Federation Services (AD FS) לאימות מבוסס ענן דורש אסטרטגיית אימות אמינה. Staged Rollout משמש כגשר במעבר הזה, ומאפשר להעביר באופן סלקטיבי קבוצות משתמשים לאימות מבוסס ענן, תוך שמירה על תשתית הפדרציה הקיימת כגיבוי. כך מצטמצם הסיכון, שכן בעיות פוטנציאליות מתבודדות לקטעים קטנים של בסיס המשתמשים.

הגדרת שלב הפיילוט

לפני שמתחילים, ודאו את שיטת הסנכרון. עליכם להגדיר Password Hash Synchronization או Pass-through Authentication לצד סביבת ה-AD FS הפעילה. לאחר שהזהויות בענן מסונכרנות, עברו למרכז הניהול של Microsoft Entra כדי להפעיל את התכונה עבור קבוצות אבטחה מסוימות. כדי למנוע צווארי בקבוק בביצועים או פסקי זמן (timeout) בחוויית המשתמש, התחילו בהגבלת קבוצת הפיילוט הראשונית ל-200 משתמשים לכל היותר.

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

המרת הדומיין הפדרטיבי לדומיין מנוהל

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

מהם הצעדים החיוניים להמרת דומיין פדרטיבי לדומיין מנוהל ב-Entra ID? כדי להמיר דומיין פדרטיבי למנוהל, יש לוודא תחילה ש-Password Hash Synchronization (PHS) או Pass-through Authentication (PTA) מוגדרים ומאומתים במלואם.

1. התחברו ל-Microsoft Graph PowerShell SDK באמצעות הפקודה Connect-MgGraph -Scopes "Domain.ReadWrite.All".
2. ודאו שהוקצה לכם התפקיד מנהל שם דומיין (Domain Name Administrator) או מנהל כללי (Global Administrator), שכן הרשאות אלו נדרשות לשינוי הגדרות דומיין.
3. הריצו Update-MgDomain -DomainId <your-domain.com> -AuthenticationType "Managed" כדי להתחיל בתהליך ההמרה.
4. בדקו את עדכון סטטוס הדומיין במרכז הניהול של Microsoft Entra, ובצעו בדיקה מיידית עם קבוצת משתמשים פיילוט כדי לאשר אימות מוצלח מול הענן.

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

היערכו לתקלות נפוצות במהלך ההגירה

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

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

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

השתמשו ב-AD FS Application Migration Wizard ובכלים נוספים

העברת יישומים מדור קודם מ-Active Directory Federation Services (AD FS) נראית לעתים קרובות כחלק המאיים ביותר בפרויקט מודרניזציה של זהויות. כדי לפשט זאת, AD FS Application Migration Wizard משמשככלי ייעודי לגילוי, הערכה והגדרה של יישומי relying party. באמצעות אוטומציה, ארכיטקטים יכולים לסרוק תצורות קיימות ולקבל דוחות על זכאות היישומים, המדגישים אילו שירותים מוכנים להעברה מיידית ואילו מהם נתקלים במכשולים טכניים.

כשניגשים למעבר הזה, פעלו לפי מחזור הגירה מובנה. התחילו בשימוש ב-Discovery and Scope כדי לקטלג כל יישום, כולל יישומים שנמצאים בפיתוח. תעדפו את שלב הסיווג על ידי טיפול ביישומי SaaS פשוטים מהגלריה התומכים במספר ספקי זהות, לפני מעבר ליישומים מותאמים מורכבים מדור קודם. עבור יישומי ווב שאי אפשר למודרניזציה מלאה, Microsoft Entra application proxy ו-Secure Hybrid Access (SHA) מאפשרים לגשר על הפער ולספק גישה מרחוק מאובטחת ללא צורך ב-VPN מסורתי.

בחרו את שיטת האימות בענן: PHS, PTA או CBA

בחירת מסלול האימות הנכון קובעת את תנוחת האבטחה ואת חוויית המשתמש. Microsoft ממליצה על Password Hash Synchronization (PHS) כבחירה המועדפת על רוב הארגונים. על ידי סנכרון hash של סיסמאות לענן, אתם פותחים תכונות אבטחה חיוניות כמו זיהוי אישורים שנחשפו ו-Identity Protection, ובמקביל מאפשרים מעבר לשיטות כניסה ללא סיסמה מודרניות כמו מפתחות FIDO2.

עבור סביבות שבהן רגולציה מונעת אחסון של hash של סיסמאות בענן, Pass-through Authentication (PTA) הוא חלופה בת קיימא. שיטה זו מאמתת את פרטי המשתמש ישירות מול Active Directory המקומי שלכם. אם אתם פורסים PTA, דאגו להתקין מספר סוכני אימות קלים כדי לשמור על זמינות גבוהה, שכן שרתים אלה הופכים לשומרי הסף העיקריים של הכניסות שלכם לענן.

כאשר אתם צריכים לעמוד בדרישות מחמירות של עמידות להונאת דיוג (phish-resistant), כגון אלה המפורטות ב-EO 14028, עברו ל-Microsoft Entra Certificate-based Authentication (CBA). גישה זו מאפשרת למשתמשים להתאמת באמצעות כרטיסים חכמים או תעודות, ומספקת אימות זהות בעל רמת ביטחון גבוהה שאינו תלוי בשרת הפדרציה המקומי שלכם.

כדי לשמור על חוויית משתמש חלקה במהלך המעבר, הטמיעו Seamless SSO לצד השיטה שבחרתם. אם כוח העבודה שלכם משתמש במכשירי macOS או iOS, כדאי לפרוס את התוסף Microsoft Enterprise SSO עבור מכשירי Apple כדי להבטיח כניסות חלקות ומתמשכות ללא בקשות אימות חוזרות. אנחנו רואים שהשילוב של שיטות אלה עם מדיניות Conditional Access חזקה מספק את האיזון הטוב ביותר בין אבטחה ארגונית לפרודוקטיביות של המשתמשים.

תכננו את הפירוק של AD FS

פירוק תשתית הפדרציה המדור קודמת הוא השלב האחרון בדרך להשגת מצב זהות מודרני. לפני ביצוע כל פעולה קבועה, עליכם לוודא שאין תעבורה שיורית שמסתמכת על חוות ה-AD FS שלכם. השתמשו בדוח Connect Health Usage Analytics כדי לאשר שכל בקשות האימות עברו בהצלחה ל-Microsoft Entra ID.

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

1. הסירו את כל הרשומות מאיזון העומסים המקומי כדי לעצור את תעבורת הכניסה.
2. עדכנו או מחקו רשומות DNS הקשורות לשירותי הפדרציה כדי להפנות את הבקשות מחדש.
3. הסירו בשיטתיות את תפקידי השרת Web Application Proxy ו-AD FS.
4. נקו נתוני תצורה שנותרו על ידי ניקוי מאגרי התעודות באמצעות ADSI Edit, כדי לוודא שהסביבה נוקתה לחלוטין.

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

העבירו את מדיניות האימות לפני המועד האחרון

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

כדי להתחיל, נווטו אל Protection > Authentication methods > Policies בפורטל Entra. השתמשו באשף ההעברה המובנה כדי לבדוק את הסביבה הנוכחית ולזהות התנגשויות בין ההגדרות המדור קודמות לבין המסגרת החדשה. מומלץ כשעניין שפרקטיקה טובה להגדיר את סטטוס ההעברה ל-'Migration in progress', כך שתוכלו לבדוק את המדיניות החדשה תוך שהגדרות המדור קודמות נשארות פעילות עבור בסיס המשתמשים הקיים.

• שיטות אימות מתקדמות כגון מפתחות אבטחה FIDO2, Temporary Access Pass (TAP), ואימות מבוסס תעודות מנוהלות אך ורק דרך המדיניות החדשה.
• תהליך ההגירה הפיך, ותוכלו לעבור בין המצבים במידת הצורך, כדי לשחזר את ההתנהגות הישנה בשלב הבדיקות.
• הכלי האוטומטי מעביר הגדרות ברמת הדייר כולו, אך נדרשת בדיקה ידנית כדי לוודא שההגדרות הספציפיות לקבוצות משוכפלות כראוי.
• המעבר למדיניות המאוחדת הזו מאפשר יישור טוב יותר עם תקני אבטחה מודרניים, כמו אימות רב-שלבי עמיד לפishing.

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

אבטחה עם Conditional Access וניטור

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

מעבר לבדיקות, יש לעדכן גם את סף הנעילה. במהלך המעבר, הגדירו smart lockout ב-Microsoft Entra ID עם פרק זמן קצר יותר מזה שבהגדרות Active Directory המקומי שלכם, כדי לספק הגנה מיידית יותר מפני מתקפות brute-force. לשמירה על נראות במהלך המעבר, הסתמכו על חוברות העבודה של Hybrid Auth כדי לנטר תהליכי אימות ולזהות חריגות אפשריות. מומלץ לעקוב מקרוב אחר יומני הכניסה למשך שבוע עד שבועיים לאחר ההגירה, כדי לוודא שהמשתמשים מאמתים בהצלחה ולאפשר חזרה מהירה לקודם אם יתעוררו בעיות.

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

משאבי למידה ותיעוד של Microsoft Entra ID

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

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

בנוסף, מעקב קבוע אחר הסעיף 'What's New' בתיעוד של Entra הוא קריטי כדי לעקוב אחר העדכונים המהירים של המוצר.

ניהול גישה עם PIM וניהול מחזור חיים של זהויות

המעבר למודל זהויות מבוסס ענן מחייב מעבר מגישה ניהולית קבועה. Microsoft Entra ID Privileged Identity Management (PIM) פותר זאת על ידי הפעלת תפקידים מבוססת זמן ואישור. בניגוד למערכות ישנות שמעניקות הרשאות מתמשכות, PIM אוכף גישה לפי הצורך (just-in-time), דבר שמפחית באופן משמעותי את משטח התקיפה של חשבונות מוגברי הרשאות.

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

אוטומציה של גישה וציות

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

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

תכנון לזהויות חיצוניות ולעתיד

ניהול זהויות חיצוניות דורש גישה יזומה, ככל ש-Microsoft משנה את מגוון השירותים שלה. ארגונים שמסתמכים על Azure AD B2C חייבים להתכונן למעבר ידני ל-Microsoft Entra External ID, שכן כרגע אין מסלול מקורי ואוטומטי לחלוטin בין שתי הפלטפורמות. תצטרכו לייצא נתוני משתמשים מהספרייה הקיימת ולייבא אותם לדייר החדש. למרות שקיים ב-GitHub ערכת כלים להעברה הנתמכת על ידי הקהילה שתסייע בתהליך, כדאי להשתמש בהעברת הסיסמאות Just-In-Time (JIT) כדי להבטיח חוויה חלקה יותר בכניסה הראשונה של המשתמשים.

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

אבטחה נשארת בעדיפות עליונה במהלך העדכונים האלה. החל מ-1 ביוני 2026, Microsoft תחסום פעולות של 'hard-match' שמקשרות משתמשים חדשים מ-Active Directory מקומי לחשבונות קיימים שמנוהלים בענן ומחזיקים כבר בתפקידי ניהול. אמצעי הגנה זה נועד למנוע מניפולציה של מאפיינים ולהגן על הזהויות בעלות הפריבילגיות הגבוהות ביותר מפני השתלטות לא מורשית. בזמן ההיערכות לעתיד, בדקו כבר עכשיו את חיבורי הדיירים החוצי-דיירים הקיימים ואת ההקצאות הניהוליות, כדי להימנע מהפרעות לשירות כאשר בקרות אבטחה אלה ייכנסו לתוקף.

הדרך לזהות חלקה בענן

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

לאחר המעבר, העבודה שלכם תתמקד בניטור פעיל של יומני כניסה ובתצורות של Authentication methods policy. עקביות היא קריטית, וכדאי תמיד לוודא שפעילות הפדרציה הישנה הופסקה לפני הפירוק הסופי. כדי לעמוד בשינויים האלה, האזינו ל-M365 FM Podcast לקבלת תובנות יומיות על העדכונים.

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