Share via

לזהות ומעבר – נקודת התהצגת של אדריכל אחד

  • מאמר

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

אודות המחבר

תמונת אלכס שטיינברג.

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

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

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

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

עקרונות מנחים

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

מושגים בסיסיים

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

איור של דייר, מנוי, שירות ונתונים.

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

בדיאגרמה:

  • Tenant = מופע של Microsoft Entra מזהה. היא מופיעה בחלק ה"עליון" של הירארכיה, או ברמה 1 בדיאגרמה. אנחנו יכולים לשקול רמה זו כ"גבול" שבו כל דבר אחר מתרחש (Microsoft Entra B2B בצד). כל שירותי הענן הארגוניים של Microsoft הם חלק מה דיירים אלה. שירותי צרכנים נפרדים. "דייר" מופיע בתיעוד כמו דייר Microsoft 365, דייר Azure, דייר WVD וכן הלאה. לעתים קרובות, וריאציות אלה עשויות לגרום לבלבול עבור לקוחות.
  • שירותים/מנויים, רמה 2 בדיאגרמה, שייכים לדייר אחד ורק לדייר אחד. רוב שירותי SaaS הם 1:1 ולא יכולים לעבור ללא העברה. Azure שונה, באפשרותך להעביר חיוב ו /או מנוי לדייר אחר. קיימים לקוחות רבים שיש להעביר מנויי Azure. לתרחיש זה יש השלכות שונות. אובייקטים הקיימים מחוץ למנוי אינם זזים. לדוגמה, בקרת גישה מבוססת תפקיד (Azure RBAC), אובייקטי Microsoft Entra (קבוצות, אפליקציות, פריטי מדיניות וכדומה) ושירותים מסוימים (Azure Key Vault, Data Bricks וכולי). אל תעביר שירותים ללא צורך עסקי טוב. קבצי Script מסוימים שעשויים להיות שימושיים להעברה משותפים ב- GitHub.
  • לשירות נתון יש בדרך כלל גבול "רמת משנה" או רמה 3 (L3). גבול זה שימושי להבנה לגבי הפרדה של אבטחה, מדיניות, פיקוח וכן הלאה. למרבה הצער, אין שם אחיד שאני מכיר. להלן כמה דוגמאות לשמות עבור L3: Azure Subscription = resource; Dynamics 365 CE = מופע; Power BI = סביבת עבודה; Power Apps = סביבה; וכן הלאה.
  • רמה 4 היא המקום שבו נמצאים הנתונים בפועל. "מישור נתונים" זה הוא מאמר מורכב. שירותים מסוימים משתמשים Microsoft Entra מזהה RBAC, ושירותים אחרים אינם משתמשים. אני נדון בזה קצת כ כשתגיע למאמרים של ההקצאה.

כמה מושגים אחרים שאני מוצא לקוחות רבים (ועובדי Microsoft) מבולבלים או שיש להם שאלות לגבי כוללים את הבעיות הבאות:

  • כל אחד יכול ליצור דיירים רבים ללא תשלום. אין צורך להקצות שירות בתוכו. יש לי עשרות. כל שם דייר הוא ייחודי בשירות הענן ברחבי העולם של Microsoft (במילים אחרות, שני דיירים לא יכולים להיות בעלי שם זהה). כולם בתבנית של TenantName.onmicrosoft.com. קיימים גם תהליכים ליצירת דיירים באופן אוטומטי (דיירים לא מנוהלים). לדוגמה, תוצאה זו עשויה להתרחש כאשר משתמש נרשם לשירות ארגוני עם תחום דואר אלקטרוני שאינו קיים בדייר אחר.
  • בדייר מנוהל, ניתן לרשום בו תחומי DNS רבים. תוצאה זו אינה משנה את שם הדייר המקורי. בשלב זה אין דרך קלה לשנות שם של דייר (מלבד העברה). למרות ימינו, שם הדייר אינו קריטי מבחינה טכנית, יש אנשים העשויים להרגיש מוגבלים על-ידי מציאות זו.
  • עליך להזמין שם דייר עבור הארגון שלך גם אם עדיין אינך מתכנן לפרוס שירותים כלשהם. אחרת, מישהו יוכל לקחת אותו ממך, ולא יהיה תהליך פשוט להחזיר אותו (אותה בעיה כמו שמות DNS). אני שומע את זה יותר מדי פעמים מלקוחות. שם הדייר שלך צריך להיות גם מאמר בנושא דיון.
  • אם מרחב השמות של DNS נמצא בבעלותך, עליך להוסיף את כל מרחבי השמות הללו לדיירים שלך. אחרת, ניתן היה ליצור דייר לא מנוהל בשם זה, דבר הגורם להפרעה בהפיכתו למנוהל.
  • מרחב שמות DNS (לדוגמה, contoso.com) יכול להשתייך לדייר אחד בלבד. דרישה זו כוללת השלכות על תרחישים שונים (לדוגמה, שיתוף תחום דואר אלקטרוני במהלך מיזוג או רכישה וכן הלאה). קיימת דרך לרשום משנה של DNS (כגון div.contoso.com) בדייר אחר, אך יש להימנע מכך. על-ידי רישום שם תחום ברמה העליונה, ההנחה היא שכל תחומי המשנה שייכים לאותו דייר. בתרחישים של ריבוי דיירים (כפי שמוסבר בהמשך), בדרך כלל אני ממליץ להשתמש בשם תחום אחר ברמה העליונה (כגון contoso.ch או ch-contoso.com).
  • מי צריך "להיות הבעלים" של דייר? לעתים קרובות אני רואה לקוחות שאינם יודעים מי הבעלים של הדייר שלהם כעת. חוסר ידע זה הוא דגל אדום משמעותי. התקשר לתמיכה של Microsoft בהקדם האפשרי. בדיוק כמו שהבעיה היא כאשר בעלים של שירות (לרוב מנהל Exchange) מוגדר לניהול דייר. הדייר מכיל את כל השירותים שייתכן שתרצה בעתיד. הבעלים של הדייר צריך להיות קבוצה ה יכולה לקבל החלטה לגבי הפיכת כל שירותי הענן בארגון לזמינים. בעיה נוספת היא כאשר קבוצת בעלי דיירים מתבקשת לנהל את כל השירותים. שיטה זו אינה מקנה קנה מידה עבור ארגונים גדולים.
  • אין מושג של דייר משנה/סופר. מסיבה כלשהי, ה מיתוס הזה ממשיך לחזור על עצמו. רעיון זה חל גם על דיירי B2C של Azure Active Directory . אני שומע יותר מדי פעמים, "הסביבה שלי ב- B2C נמצאת בדייר XYZ שלי" או "כיצד ניתן לבצע את דייר Azure שלי לדייר Microsoft 365 שלי?"
  • מסמך זה מתמקד בעיקר בענן המסחרי ברחבי העולם, מכיוון שזה מה שרוב הלקוחות משתמשים בו. לפעמים כדאי לדעת על עננים ריבונות. לעננים ריבונים יש השלכות אחרות לדון שבהם מחוץ לטווח הדיון.

מאמרי זהות בסיסית

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

אספקה

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

Microsoft Entra חיבור לעומת Microsoft Identity Manager (MIM) לעומת פריט אחר (צד שלישי או מותאם אישית)? שמור לעצמך בעיות עכשיו ובעתיד ועבור אל Microsoft Entra התחבר. בכלי זה קיימים סוגים שונים של חכמים כדי לטפל בתצורות לקוח ספציפיות ובחידושים מתמשכת.

מקרי קצה מסוימים שעשויים לנהוג לעבר ארכיטקטורה מורכבת יותר:

  • יש לי יערות AD מרובים ללא קישוריות רשת ביניהן. קיימת אפשרות חדשה הנקראת 'הקצאת משאבים בענן'.
  • אין לי Active Directory, ואיני מעוניין להתקין אותו. Microsoft Entra ניתן לקבוע תצורה של חיבור לסינכרון מ- LDAP (ייתכן שיהיה צורך בשותף).
  • אני צריך להקצות את אותם אובייקטים לדיירים מרובים. תרחיש זה אינו נתמך מבחינה טכנית, אך תלוי בהגדרה של "זהה".

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

XYZ SaaS תומך בהקצאת משאבים של Just-in-Time (JIT), מדוע אתה דורש ממני לסנכרן? הצגת הפיסקה הקודמת. יישומים רבים זקוקים למידע "פרופיל" לפונקציונליות. לא יכולה להיות לך GAL אם כל האובייקטים המותאמים לדואר אינם זמינים. הדבר חל על הקצאת משתמשים ביישומים המשולבים עם Microsoft Entra מזהה.

אימות

סינכרון קודי Hash של סיסמאות (PHS) לעומת אימות מעבר (PTA) לעומת איחוד.

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

לקוחות מסוימים מאפשרים איחוד ו- PHS בעיקר עבור:

  • אפשרות לחזור אל (להתאוששות מאסון) אם שירות האיחוד אינו זמין.
  • יכולות נוספות (לדוגמה, Microsoft Entra Domain Services) ושירותים אבטחה (לדוגמה, אישורים דולפים)
  • תמיכה עבור שירותים ב- Azure שאינם מבינים אימות מאוחד (לדוגמה, Azure Files).

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

שיחת לוח ציור לדוגמה.

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

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

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

ההרשאות

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

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

מנגנון מדיניות Microsoft Entra מזהה.

שילוב כל האותות הללו יחד מאפשר פריטי מדיניות דינאמיים כגון אלה:

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

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

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

ביקורת

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

אין Exchange

אל דאגה! Exchange אינו יוצא משימוש (או SharePoint וכן הלאה). זה עדיין שירות מרכזי. מה שאני מתכוון הוא, במשך זמן מה, ספקי טכנולוגיה מספקים מעבר בין חוויות המשתמש (UX) לכלול רכיבים של שירותים מרובים. ב- Microsoft 365, דוגמה פשוטה היא "קבצים מצורפים מודרניים" שבהם קבצים מצורפים לדואר אלקטרוני מאוחסנים ב- SharePoint Online או ב- OneDrive.

צירוף קובץ להודעת דואר אלקטרוני.

כאשר אתה מסתכל על לקוח Outlook, באפשרותך לראות שירותים רבים "מחוברים" כחלק מחוויה זו, ולא רק Exchange. הדוגמאות כוללות Microsoft Entra מזהה, חיפוש של Microsoft, אפליקציות, פרופיל, תאימות וקבוצות של Microsoft 365.

ממשק Outlook עם הסברים.

קרא אודות מסגרת עריכה גמישה של Microsoft תצוגה מקדימה של יכולות קרובות. בתצוגה מקדימה כעת, אני יכול לקרוא שיחות Teams ולהשיב אותן ישירות ב- Outlook. למעשה, לקוח Teams הוא אחת מהדוגמאות הבולטות יותר של אסטרטגיה זו.

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

כיום, אני מוצא שקבוצות IT רבות של לקוחות מובנות סביב "מוצרים". זה הגיוני עבור עולם מקומי מכיוון שאתה זקוק למומחה עבור כל מוצר ספציפי. עם זאת, אני שמח שאני לא צריך לאתר שוב באגים במסד נתונים של Active Directory או Exchange משום שהשירותים האלה עברו לענן. אוטומציה (שהענן בעצם הוא) מסירה משרות ידניות שחוזרות על עצמן (ראה מה קרה למפעלים). עם זאת, משימות אלה מוחלפים בדרישות מורכבות יותר כדי להבין אינטראקציה בין שירותים, השפעה, צרכים עסקיים וכן הלאה. אם אתה מוכן ללמוד, ישנן הזדמנויות נהדרות שטרנספורמציית הענן מאפשרת. לפני שאני מדלג לטכנולוגיה, אני מדבר לעתים קרובות עם לקוחות על ניהול שינויים במיומנויות ה- IT ומבני הצוות.

לכל האנשים והמפתחים של SharePoint, הפסק לשאול "כיצד ניתן לבצע XYZ ב- SharePoint Online?" השתמש ב- Power Automate (או בזרימה) עבור זרימת עבודה, היא פלטפורמה הרבה יותר חזקה. השתמש ב- Azure Bot Framework כדי ליצור חוויית משתמש טובה יותר עבור רשימת הפריטים שלך ב- 500 K. התחל להשתמש ב- Microsoft Graph במקום ב- CSOM. Microsoft Teams כולל את SharePoint אך גם עולם נוסף. קיימות דוגמאות רבות אחרות שאני יכול להציג. יש היקום העצום והנפלאה שם בחוץ. פתח את הדלת והתחל לחקור.

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

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

אפשרויות מבנה דייר

דייר יחיד לעומת דייר מרובה

באופן כללי, לרוב הלקוחות צריך להיות דייר ייצור אחד בלבד. קיימות סיבות רבות לכך ריבוי דיירים מאתגרים (לתת לו חיפוש ב- Bing) או לקרוא סקירה טכנית זו. בו-זמנית, לקוחות ארגוניים רבים שאני עובד איתם כוללים דייר אחר (קטן) ללמידה, בדיקה והתנסות של IT. גישה חוצה דיירים ל- Azure נוחה יותר עם Azure Lighthouse. Microsoft 365 ושירותים רבים אחרים של SaaS מוגבלים לתרחישים חוצי דיירים. יש לשקול דברים רבים בתרחישי Microsoft Entra B2B.

לקוחות רבים בסופו של דבר עם דיירי ייצור מרובים לאחר מיזוג ורכישה (M&A) וברצונך לאחד. כיום זה לא פשוט ודרוש Microsoft Consulting Services (MCS) או שותף בתוספת תוכנות של ספקים חיצוניים. יש עבודה מתמשכת בהנדסה כדי לטפל בתרחישים שונים עם לקוחות מרובי דיירים בעתיד.

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

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

בתרחישים אלה של ריבוי דיירים, לעתים קרובות הלקוחות רוצים לשמור על התצורה זהה בכל הדיירים, או לדווח על שינויי תצורה ועל סחף. משמעות הדבר לעתים קרובות היא מעבר משינויים ידניים לתצורה כקוד. התמיכה של Microsoft Premiere מציעה סדנה לסוגי דרישות אלה בהתבסס על כתובת IP ציבורית זו: https://Microsoft365dsc.com.

Multi-Geo

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

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

הקצאת ניהול

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

Microsoft Entra מזהה הניהול של Microsoft 365

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

  • מנהל מערכת כללי: תפקיד "כל" זה צריך להיות מוגן מאוד, בדיוק כפי שהיית עושה במערכות אחרות. המלצות אופייניות כוללות: ללא הקצאה קבועה ושימוש Microsoft Entra Privileged Identity Management (PIM); אימות חזק; וכן הלאה. מעניין, תפקיד זה אינו מעניק לך גישה לכל דבר כברירת מחדל. בדרך כלל, אני רואה בלבול לגבי גישת תאימות וגישת Azure, הנדון מאוחר יותר. עם זאת, תפקיד זה יכול תמיד להקצות גישה לשירותים אחרים בדייר.
  • מנהלי שירות ספציפיים: שירותים מסוימים (Exchange, SharePoint, Power BI וכן הלאה) צורכים תפקידי ניהול ברמה גבוהה Microsoft Entra מזהה. אופן פעולה זה אינו עקבי בכל השירותים וקיימים תפקידים ספציפיים יותר לשירות שמתוארים בהמשך.
  • פונקציונלי: קיימת רשימה ארוכה (וגדלה) של תפקידים המתמקדים בפעולות ספציפיות (מזמין אורח וכן הלאה). מעת לעת, יותר תפקידים אלה מתווספים בהתבסס על צרכי הלקוחות.

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

הערה: לממשק מרכז הניהול של Microsoft 365 יש ממשק ידידותי יותר למשתמש, אך הוא כולל קבוצת משנה של יכולות בהשוואה לחוויה Microsoft Entra הניהול. שני הפורטלים משתמשים באותם Microsoft Entra תפקידים, כך שמתרחשים שינויים באותו מקום. עצה: אם אתה מעוניין בממשק משתמש של מנהל מערכת ממוקד לניהול זהויות ללא כל העומס של Azure, השתמש ב- https://aad.portal.azure.com.

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

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

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

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

הזכרתי Microsoft Entra PIM כמה פעמים. קיים פתרון תואם של Microsoft Identity Manager (MIM) Privileged Access Management (PAM) עבור פקדים מקומיים. מומלץ גם לעיין ב- Privileged Access Workstations (PAWs) וב- ניהול מזהה Microsoft Entra. קיימים גם כלים שונים של ספקים חיצוניים, המאפשרים העלאת תפקידים פשוטים, פשוטים ודינאמיים. יכולת זו היא בדרך כלל חלק מדיון גדול יותר לאבטחת סביבה.

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

Microsoft Defender XDR התאימות של Microsoft 365 Purview

תפקידי & אלקטרוני ושיתוף פעולה בפורטל Microsoft Defender ו- *תפקידים עבור פתרונות Microsoft Purview בפורטל התאימות של Microsoft 365 Purview הם אוסף של "קבוצות תפקידים", שהנם נפרדים ונפרדים Microsoft Entra תפקידים. הדבר עשוי להיות מבלבל מאחר של חלק מקבוצות תפקידים אלה יש שם זהה לשם של תפקידי Microsoft Entra (לדוגמה, 'קורא אבטחה'), אך יכול להיות להם חברות שונה. אני מעדיף את השימוש Microsoft Entra שלי. כל קבוצת תפקידים מורכבת מ"תפקיד" אחד או יותר (ראה למה אני מתכוון לגבי שימוש חוזר באותה מילה?) ויש להם חברים מ- Microsoft Entra מזהה, שהם אובייקטים מותאמים לדואר אלקטרוני. כמו כן, באפשרותך ליצור קבוצת תפקידים עם שם זהה לזה של תפקיד, שעשויה להכיל תפקיד זה או לא (למנוע בלבול זה).

באופן מסוים, הרשאות אלה הן התפתחות של מודל קבוצות התפקידים של Exchange. עם זאת, Exchange Online ממשק ניהול קבוצת תפקידים משלו. קבוצות תפקידים מסוימות ב- Exchange Online נעולות ומנוהלות מ- Microsoft Entra מזהה או מפורטלי התאימות של Microsoft Defender XDR ו- Microsoft 365 Purview, אך ייתכן שלמשתמשים אחרים יש שמות זהים או דומים ומנוהלים ב- Exchange Online (מוסיפים לבלבול). אני ממליץ לך להימנע משימוש בממשק Exchange Online אלא אם אתה זקוק לטווחים עבור ניהול Exchange.

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

קבוצות תפקידים אלה דורשות גם חברות ישירה ולא יכולות להכיל Microsoft Entra אלה. למרבה הצער, היום קבוצות תפקידים אלה אינן נתמכות על-ידי Microsoft Entra PIM. כמו Microsoft Entra, אני נוטה להמליץ על ניהול קבוצות תפקידים אלה באמצעות ממשקי API או מוצר פיקוח של שותף, כגון Saviynt או אחרים.

Microsoft Defender פורטל התאימות של Microsoft 365 Purview מתפרסים על Microsoft 365 ולא ניתן להגדיר קבוצות תפקידים אלה לקבוצת משנה של הסביבה (כפי שניתן לעשות עם יחידות ניהול ב- Microsoft Entra מזהה). לקוחות רבים שואלים כיצד הם יכולים לבצע בחירות משנה. לדוגמה, "צור מדיניות DLP רק עבור משתמשי האיחוד האירופי". כיום, אם יש לך זכויות לפונקציה ספציפית בפורטלי התאימות של Microsoft Defender XDR ו- Microsoft 365 Purview, יש לך זכויות לכל מה שפונקציה זו תכלול בדייר. עם זאת, פריטי מדיניות רבים כוללים יכולות לייעד קבוצת משנה של הסביבה (לדוגמה, "הפוך תוויות אלה לזמינים רק למשתמשים אלה"). פיקוח ותקשורת נכונה הם רכיב מפתח למניעת התנגשויות. לקוחות מסוימים בוחרים ליישם גישה "תצורה כקוד" כדי לטפל בהקצאת משנה בפורטלי התאימות של Microsoft Defender XDR ו- Microsoft 365 Purview. שירותים ספציפיים מסוימים תומכים בהקצאת משנה (עיין בסעיף הבא).

שירות ספציפי

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

  • Exchange Online - (/exchange/permissions-exo/permissions-exo)
  • SharePoint Online - (/sharepoint/manage-site-collection-administrators)
  • Microsoft Teams - (/microsoftteams/itadmin-readiness)
  • גילוי אלקטרוני - (.. /compliance/index.yml)
    • סינון הרשאות - (.. /compliance/index.yml)
    • גבולות תאימות - (.. /compliance/set-up-compliance-boundaries.md)
    • גילוי אלקטרוני (Premium) - (.. /compliance/overview-ediscovery-20.md)
  • Viva Engage - (/viva/engage/manage-viva-engage-users/manage-viva-engage-admins)
  • Multi-geo - (.. /enterprise/add-a-sharepoint-geo-admin.md)
  • Dynamics 365 – (/dynamics365/)

הערה

קישור זה מיועד לבסיס התיעוד. קיימים סוגים מרובים של שירותים עם וריאציות במודל הניהול/הקצאה.

  • Power Platform - (/power-platform/admin/admin-documentation)

    • Power Apps - (/power-platform/admin/wp-security)

      הערה

      קיימים סוגים מרובים עם וריאציות במודלים של ניהול/הקצאה.

    • Power Automate - (/power-automate/environments-overview-admin)

    • Power BI - (/power-bi/service-admin-governance)

      הערה: אבטחה והקצאה של פלטפורמת נתונים (ש- Power BI הוא רכיב) היא אזור מורכב.

  • Intune - (/mem/intune/fundamentals/role-based-access-control)

  • Microsoft Defender עבור נקודת קצה - (/windows/security/threat-protection/microsoft-defender-atp/user-roles)

  • Microsoft Defender XDR - (.. /security/defender/m365d-permissions.md)

  • יישומי ענן של Microsoft Defender - (/cloud-app-security/manage-admins)

  • Stream - (/stream/assign-administrator-user-role)

  • מחסומי מידע - (.. /compliance/information-barriers.md)

יומני פעילות

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

דוגמאות ליומני רישום של Microsoft 365 הנגישות באמצעות ממשקי API אחרים כוללות את התכונות הבאות:

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

מנקודת המבט של הקצאת מנהלי מערכת, לרוב יומני הפעילות של Microsoft 365 אין מודל RBAC מוכלל. אם יש לך הרשאה לראות יומן רישום, תוכל לראות את כל מה שיש בו. דוגמה נפוצה של דרישת לקוח היא: "אני רוצה להיות מסוגל לבצע שאילתות על פעילות רק עבור משתמשי האיחוד האירופי" (או ממד אחר). כדי להשיג דרישה זו, עלינו להעביר יומני רישום לשירות אחר. בענן של Microsoft, מומלץ להעביר אותו אל Microsoft Sentinel או Log Analytics.

דיאגרמה ברמה גבוהה:

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

הדיאגרמה מייצגת יכולות מוכללות לשליחת יומני רישום אל מרכזי אירועים ו/או Azure Storage ו/או Azure Log Analytics. לא כל המערכות כוללות עדיין מוצר מוכן מראש זה. אך קיימות גישות אחרות לשליחת יומני רישום אלה לאותו מאגר. לדוגמה, ראה הגנה על Teams באמצעות Microsoft Sentinel.

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

אין צורך להעביר יומני רישום למקום אחד בלבד. ייתכן גם שיהיה מועיל לשלב את יומני הרישום של Microsoft 365 עם יישומי ענן של Microsoft Defender או מודל RBAC מותאם אישית ב- Power BI. למאגרים שונים יש יתרונות וקהלים שונים.

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

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

Azure

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

חשוב להבין קשרי גומלין בין שירותים שונים באותו דייר. אני עובד עם לקוחות רבים שבונים פתרונות עסקיים המשתרעים על-פני Azure, Microsoft 365 ו- Power Platform (ול לרוב גם שירותי ענן מקומיים וספקים חיצוניים). דוגמה נפוצה אחת:

  1. ברצוני לשתף פעולה בערכת מסמכים/תמונות/וכו' (Microsoft 365)
  2. שליחת כל אחד מהם באמצעות תהליך אישור (Power Platform)
  3. לאחר אישור כל הרכיבים, הרכב פריטים אלה ל- API מאוחד של Microsoft Graph (תוצרים) של Microsoft Graph . לא בלתי אפשרי, אך מורכב יותר באופן משמעותי לעיצוב פתרון התפרס על פני דיירים מרובים.

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

תצוגה ברמה גבוהה של רכיבי Azure לניהול מוסמך.

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

מסקנה

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