היום, סשן העדכון הראשון בקריירה שלי, אבל אתה תראה אותו בעוד כמה דקות. לפני שנתחיל, אני רוצה לתת49 עדכון אפשרויות RBAC של Microsoft Sentinel לך הקדמה קצרה עליי. שמי Hanes L. אני אדריכל ענן מוביל באחת מחברות הייעוץ הגדולות באוסטריה בשם פתרונות IT של ACP. אני עובד עם Microsoft Azure מההתחלה, וזה גם נושא המיקוד שלי. יש לי הרבה הסמכות בתחומים שונים כמו פיתוח, ארכיטקטורת רשת, אבטחה, ויש לי גם קצת ניסיון ב-Hyperscalers אחרים כמו AWS ו-GCP. אבל המיקוד העיקרי שלי הוא Microsoft Azure. מאז שלוש שנים, אני גם MVP של Microsoft Azure. אני ממש שמח על זה, ותוכלו למצוא אותי בפלטפורמות שונות של מדיה חברתית כמו לינקדאין, טוויטר, ותוכלו למצוא אותי גם בבלוג הפרטי שלי בשם Cloud Blocker. יש לי את ערוץ היוטיוב הפרטי שלי, ותוכלו גם למצוא הכל על ההפעלות שלי במאגרי GitHub שלי. אז קחו בחשבון שהיום יש לנו הרבה תוכן. יש לנו קטע תיאוריה קטן ומעבירים לאחר מכן להדגמה חיה, ואת כל התסריטים, כל התבניות, וגם, ללא ספק, המצגת, תוכלו למצוא במאגר GitHub שלי.
???? לחץ כאן כדי לעקוב אחר אתר RonenGG בחדשות Google ולעקוב אחרינו
אוקיי, אז בואו נתחיל מהנושא, עם הפגישה להיום. היום, אנחנו מדברים על אפשרויות בקרת גישה מבוססות תפקידים שיש לך ב-Microsoft Sentinel. אז בעבר, לפני כשנה, הקלטתי גם מאמר על אפשרויות בקרת גישה מבוססות תפקידים שיש לכם. אתה יכול למצוא את המאמר בתגובות למטה. אז אם תרצו, תוכלו לבקר בכתבה הישנה וגם לראות אילו אפשרויות היו לכם לפני שנה. והיום, אני רוצה לתת לך סקירה כללית על הפונקציונליות החדשה, התכונות החדשות שיש לך, וגם העיצוב האדריכלי החדש שאתה יכול להביא לסביבת ה-Sentinel שלך.
אוקיי, אז בואו נעבור לסדר היום. זה ממש קצר. אז יש לנו קטע קטן, עוד פעם, קטע תיאוריה קטן, ואז נמסר להדגמה חיה. קודם כל, אנחנו רוצים לדבר על האפשרויות הישנות, או על אפשרויות בקרת הגישה מבוססות התפקידים שהיו לך, והיו זמינות בעבר. זו לא מורשת. זה ממש חשוב. זו לא מורשת. אתה יכול להשתמש בזה. יש אפשרות אחת, שהיא כרגע בחירה טובה יותר עם העדכון החדש, אבל יש גם כמה פונקציונליות של בקרת גישה מבוססת תפקידים שהם ממש נפוצים וגם מה שראיתי בסביבות משתמש. אז שום דבר אינו מורשת כאן. יש לנו אפשרויות חדשות, והאופציה החדשה מביאה לגמישות רבה יותר וגם נותנת לך את היכולת ליישם גישה לפחות הרשאות. אז נעבור לאפשרויות החדשות שיש לך ואיך להתחיל. ובסוף, אנחנו מעבירים להדגמה חיה.
עדכוני השקעות בהייטק: תובנות שוק ודגשים בפרויקט
אוקיי, אז בוא נתחיל עם ההרשאות הנוכחיות שיש לך. אז הראשון הוא תפקידים ספציפיים של Microsoft Sentinel. כאשר מיקרוסופט מיישמת שירות חדש או מוצר חדש, הם מביאים גם תפקידים מותאמים אישית ספציפיים לשירות זה. אז עבור Microsoft Sentinel, יש לך תפקידים כמו Sentinel Responder, Sentinel Contributor, Sentinel Reader. אלו הם תפקידי ברירת המחדל הנפוצים ביותר. ובכל סביבות הלקוחות שלי ובכל עיצובי הארכיטקטורה שלי, אני גם מביא את התפקידים המותאמים אישית האלה לתוך הארכיטקטורה ונותן ללקוחות את היכולת להשתמש בתפקידים האלה. אז זה ממש נפוץ להשתמש בתפקידים האלה. אבל במצבים מסוימים, ייתכן שתזדקק לתפקידים מותאמים אישית. לדוגמה, יש לך לקוח שצריך גישת קריאה, אבל הוא לא אמור לראות את המחברים הזמינים. אז אתה יכול לשכפל את התפקיד הקיים, התפקיד Sentinel Reader, ולהסיר בדיוק את ההרשאה הזו. אז יש לך תפקיד מותאם אישית. זה מבוסס על הפונקציונליות של השירות עצמו, אבל זה לא משנה דבר בהרשאות הנתונים. במקרה השימוש הזה, היו לנו בעבר אפשרויות שונות. אז קודם כל, טבלאות ברירת המחדל ב-Log Analytics, למשל, יומני כניסה של Office 365 או Azure Active Directory. אתה יכול להקצות הרשאות בדיוק לטבלאות האלה מכיוון שיש לך את היכולת לבחור את הטבלאות האלה ולהסיר את הגישה לכל הנתונים מהתפקיד המותאם אישית. או בעבר, הייתה לך את היכולת להשתמש בקרת גישה מבוססת משאבים. במקרה זה, הקצית מזהה משאב, ומזהה המשאב יכול להיות כל שירות בתוך Microsoft Azure.
כך, למשל, כאשר רציתם ליישם טבלה חדשה והטבלה החדשה מולאה על ידי ה-API עצמו, תוכלו להקצות לטבלה מזהה משאב ספציפי לתפקיד ולתת ללקוח הרשאה מדויקת למזהה המשאב הזה. תיארתי זאת במאמר שלי מהעבר, אז אנא בקר במאמר שלהלן. אבל כרגע, זה לא קל לטפל בכל ההרשאות לטפל בכל הטבלאות הנפרדות מכיוון שיש לך את היכולת להגדיר מזהה משאב ספציפי רק כאשר אתה מביא את נתוני המשאב דרך API למערכת שלך. או במקרים אחרים, אם אתה משתמש ב-Azure Arc, אם אתה משתמש ב-Log Forwarding Collector, המשאב הוא תמיד מזהה המשאב של Azure Arc.
A Game Changer: חושפת את השבוע המדהים ביותר ב-AI News
אז כאשר אתה מקצה שרת חדש למערכת שלך ושולח כל נתונים, למשל, נתוני SSL ל- SysCollector והעברת SysCollector
לגבי Log Analytics, המשאב הוא תמיד מזהה המשאב של Azure Arc. עכשיו יש לנו אפשרות חדשה. יש לנו אפשרות חדשה שמביאה לך דרך הרבה יותר גמישה להקצות הרשאות לטבלאות ספציפיות. השם הוא הרשאת גישה מבוססת תפקידים ברמת טבלה. אז הייתה לנו בעבר הרשאת גישה מבוססת תפקידים ברמת טבלה לטבלאות ברירת המחדל, אבל לא הייתה לך את היכולת להקצות הרשאת רמת טבלה לתפקיד מותאם אישית. אז אתה יכול להשתמש רק במזהה משאב או לומר, “היי, אני רוצה לתת ללקוח גישה לכל הטבלאות המותאמות אישית.” בפונקציונליות החדשה הזו, יש לך את היכולת להקצות הרשאות ספציפיות לטבלאות ספציפיות. פונקציונליות זו נמצאת כעת בתצוגה מקדימה, אך אתה יכול להשתמש בה בייצור. זכור תמיד, זה בתצוגה מקדימה, כך שאין לך SLA. במצבים מסוימים, עשוי להיות שינוי כלול בעתיד, אבל זה ממש מגניב להשתמש בפונקציונליות החדשה הזו.
אז השאלה היא איך להתחיל? כיצד להביא את אפשרות ההרשאה החדשה הזו לארכיטקטורה שלך? בדרך כלל, אני מתחיל בדרך הבאה. קודם כל, אני מגדיר הרשאה בסיסית לקבל גישה לסנטינל, רק לסנטינל. המשתמש לא אמור לראות שום נתונים, לא אמור להיות לו את היכולת לגשת לנתונים כלשהם, לא אמור להיות לו את היכולת לשנות שום דבר ב-Microsoft Sentinel. זו ההרשאה הבסיסית שלי. עבור תפקידים מותאמים אישית, יש לי את תפקידי ברירת המחדל, משיב זקיף, קורא זקיף, תורם זקיף. אלו הם תפקידי ברירת המחדל של האנליסטים שלי. אם אני רוצה להקצות או אם אני רוצה לתת הרשאות למשתמשים אחרים שאינם מתמקדים בחלק הניתוח והם רוצים לראות, למשל, את יומני חומת האש, למשל, אני מיישם הרשאה בסיסית. אחר כך אני שוקל איך הנתונים צריכים להיות מובנים בסנטינל. אני בוחר את שיטת האינטגרציה הנכונה, ואני גם חושב איך הנתונים צריכים להיות מובנים בטבלאות. ואז אני יוצר ארכיטקטורת נתונים. אני רוצה לראות חזותית איזה סוג של נתונים יש לי ממקורות שונים, מה המבנה מאחורי זה, הטבלאות עצמן, ואני גם מביא את רמת ההרשאה לנתונים. בסוף, אני מקצה את ההרשאה לא רק למשתמש ספציפי. אני תמיד משתמש בקבוצות של Microsoft Azure ID כדי להקצות הרשאות לקו הבסיס ובנוסף לטבלאות הנפרדות אם זה נדרש. זו נקודת ההתחלה שלי בכל פעם שאני מגיע ללקוחות שלי והם אומרים, “היי, אני רוצה לקבל את הרשאת ברירת המחדל ואני רוצה לקבל גישה לנתונים ל-Microsoft Sentinel.” זו הדרך שבה אני מתחיל את היישום שלי.
גלה את העתיד של משחקי אסטרטגיה בזמן אמת: הצצה ל-45 כותרים קרובים
אוקיי, אז יצירת המשתמש והקבוצה היא הראשונה. בחלק זה, אמורה להיות לך סקירה כללית איזו קבוצה זמינה ואיזה משתמש הוא חלק מהקבוצה. אני לא עושה את זה תמיד ידנית כי יש לך, למשל, אתה יכול להשתמש ב-Azure AD Connect כדי לסנכרן משתמשים. בדרך כלל אני יוצר קבוצה, מסנכרן את הקבוצה ומקצה משתמש לקבוצה. אם המשתמש יתווסף לקבוצה ויסונכרן ל-Azure, למשתמש יהיו הרשאות גם בשירותים שהקצית לקבוצה. בדרך כלל, אני יוצר קבוצה חדשה של Microsoft Azure ID, מסנכרן את הקבוצה, מוסיף את המשתמש, מחכה לסנכרון, ולמשתמש תהיה הרשאה לקבוצה.
כשיש לי את ארכיטקטורת הנתונים והרעיון של ההרשאות הנוכחיות שיש לי, אני הולך לשירות ורוצה לראות איך באמת התפקידים מיושמים. אני לא משתמש, למשל, בהקצאת תפקיד המשתמש הקלאסי לשירות עצמו. אני יוצר קבוצה חדשה של Microsoft Azure ID, למשל, ורוצה לראות איזו הרשאה יש לי בקבוצה זו. כשאני בוחר ב-Microsoft Sentinel ורואה את התפקידים, אני בדרך כלל רואה את התפקידים הקיימים. אתה יכול למצוא פוסט מגניב בבלוג של הקולגות שלי ל-MVP, טום ג’אג וגם יורגן ומיקרוסופט. זה נקרא “אל תפחד מהכללים”.
בפוסט זה בבלוג תוכלו למצוא סקירה כללית של כל התפקידים הקיימים בשירות. אני משתמש בקבוצה, למשל, ורוצה לראות את החברות בקבוצה הזו ולהקצות את התפקיד של Microsoft Sentinel לקבוצה. כשאני רוצה לראות סקירה כללית של מה התפקיד מסוגל, כשאני מקצה תפקיד ספציפי למשתמש, יש לי סקירה כללית על כל ההרשאות. אני יכול לבחור את התפקיד שאני רוצה להקצות. לקבלת הרשאות הנתונים, אני עובר ל-Microsoft Log Analytics. ב-Microsoft Log Analytics, אני מקצה את ההרשאות ברמת הטבלה. זה ההבדל כאן. הצעד הראשון הוא שאני בוחר מקור נתונים. זה לא חובה, אבל אני תמיד יוצר פתרון חדש למקור הנתונים שיש לי.
לדוגמה, כאשר יש לי אופיס 365, והדרישה היחידה היא אופיס 365, אני יוצר פתרון למקור הנתונים. זה נותן לי את ההזדמנות לראות את כל הטבלאות שמולאות על ידי Office 365 בנקודה מרכזית. אני בוחר בפתרון שלי, עבור להרשאות הטבלה. בהרשאות טבלה יש לי את היכולת להוסיף משתמש או קבוצת משתמשים. אני תמיד מוסיף קבוצות משתמשים. לדוגמה, קבוצת Sentinel Reader והוסף את התפקיד. זו הנקודה כאן. אני גם צריך לתת את ההרשאה להרשאות השאילתה. מלכתחילה, אינך צריך ליישם את החלק הזה. רק כאשר אתה הא
אם יש צורך נוסף בחלק הזה, אתה גם צריך ליישם את ההרשאות עבור חלק השאילתה. לחלק הנתונים, אנחנו צריכים רק להקצות את התפקיד. לדוגמה, עבור הטבלאות עבור Office 365, יש לנו טבלאות שונות.
יש לנו יומני ביקורת של Office 365, ויש לנו ממשקי API של פעילות ניהול Office 365. עבור כל טבלה, אני יכול להקצות את ההרשאה, למשל, לקבוצת Reader. כאשר המשתמש כעת חלק מקבוצת Reader, הוא יראה את כל הנתונים ואת כל הטבלאות מ-Office 365. במקרה זה, יש לו גם את היכולת לשנות את הנתונים, אך לא אמורה להיות לו גישה להרשאות הטבלה עצמה. עכשיו, יש לנו את ההבדל כאן. כאשר אתה מקצה, למשל, הרשאת קורא או קורא, יהיו לך גם הרשאות לראות את הרשאות הטבלה עצמה, אך לא אמור להיות לך אפשרות להקצות משתמש חדש או להקצות תפקיד חדש. אבל עבור חלק ההרשאות עבור השאילתה, אתה צריך גם ליישם את ההרשאות כדי לראות את הרשאות הטבלה, אבל גם להקצות למשתמש לראות את הנתונים. אז יש לך את היכולת לקבל, למשל, גישת קריאה וגישה לקריאה לטבלה עצמה. אז זו הדרך שבה אתה יכול להתחיל עם הרשאות הגישה מבוססות התפקידים.
אוקיי, אז בואו נלך לחלק ההדגמה החיה. קודם כל, אני רוצה להראות לך איך יוצרים קבוצת משתמשים ואיך מוסיפים משתמש לקבוצת משתמשים. אז בוא נלך לסביבה, ואני יכול להראות לך את זה בדרך הבאה. כאן יש לי את הפורטל Azure שלי. כשאני הולך ל-Azure Active Directory, ואני הולך לקבוצות, יש לי כאן קבוצה שנקראת Sentinel Reader. יש לי קבוצות שונות של Microsoft Azure ID, כמו קבוצת Sentinel Reader או קבוצת Sentinel Contributor.
אתה יכול לכלול משתמשים שונים בקבוצה זו, או לדוגמה, משתמש אחד, משתמשים מרובים וקבוצות מרובות. אם ברצונך להוסיף משתמש לקבוצה זו, עליך רק ללחוץ על הקבוצה, ובסקירה הכללית ניתן ללחוץ על כפתור הוסף משתמש. כאן, יש לך את היכולת להוסיף משתמש קיים. אתה יכול להוסיף משתמשים נוספים לקבוצה זו, או גם כאשר אתה משתמש ב-Azure Active Directory Connect, הקבוצה מסונכרנת ל-Microsoft Azure, וכל המשתמשים במדריך הפעיל יהיו חלק מקבוצה זו. אתה יכול לראות כאן את שמות המשתמשים. אלו שני המשתמשים היחידים שיש לי כרגע. כאשר אני לוחץ על המשתמש, יש לך את היכולת להקצות את ההרשאה ב-Microsoft Sentinel. זהו החלק של Azure Active Directory.
לגבי ההרשאות, אנחנו מדברים על, בסדר, יש לנו את הטבלאות החדשות, יש לנו את ההרשאות החדשות, ועכשיו אנחנו רוצים לראות איך להקצות את זה לטבלאות. בוא נלך ל-Microsoft Log Analytics. אני פותח את סביבת העבודה של Log Analytics. קודם כל, עלינו להגדיר את מקור הנתונים שלנו. במקור הנתונים יש לך את היכולת ליצור פתרון חדש. בפתרון, אתה יכול להגדיר איזה מקור נתונים אתה רוצה שיהיה לך. לדוגמה, כאשר אתה רוצה לבחור את נתוני Office 365 שלך, אתה יכול לבחור את נתוני Office 365 וליצור פתרון חדש עבור מקור נתונים זה. לאחר מכן תוכל להוסיף את זה לסביבת העבודה שלך.
בפתרון שלי, יש לי את המחברים והטבלאות עבור נתוני Office 365. בפתרון שלך, תוכל להוסיף את הטבלה שלך לפתרון זה, ואז כל ההרשאות לטבלה זו מיועדות רק לטבלה עצמה. כאשר אתה משתמש, למשל, אתה מוסיף את הטבלה כאן, וכבר יש לך משתמש לטבלה זו, המשתמש הזה לא יתווסף לטבלה החדשה. המשתמש הוא רק חלק מהטבלה הזו, וכאשר רוצים שתהיה טבלה בפתרון, צריך להוסיף את הטבלה לפתרון עצמו. כשאני לוחץ על הפתרון, יש לי את המחברים, למשל, שמביאים את הנתונים לסביבת העבודה של Microsoft Azure Log Analytics.
יש לי את הטבלאות, ולמשל, זו אחת הטבלאות שלי שיש לי כאן, נתוני Office 365, יש לי את מסד הנתונים שלי. אני יכול להקצות הרשאות ברמת הטבלה. כשאני עובר להרשאות הטבלה, אני יכול להוסיף את המשתמשים או קבוצות המשתמשים שלי. כשאני הולך לכאן, אני יכול לבחור את קבוצת המשתמשים שלי Sentinel Reader ולהקצות תפקיד. אתה יכול לקבל הרשאות לקרוא רק את הטבלה, לדוגמה, אתה יכול גם להקצות הרשאות לשינוי ולתפעל את מבנה הטבלה עצמו. לדוגמה, הדרך שבה אתה רוצה לראות את הנתונים שלך, למשל, בשורה הראשונה כאן. זו גם נקודה חשובה כאן. הרשאות הטבלה כאן חשובות מאוד מכיוון שהתפקידים ייכללו גם בסביבת העבודה של Microsoft Sentinel עצמה.
כשאני הולך לסביבת העבודה של Microsoft Sentinel ואני מסתכל על התפקידים בסביבת העבודה, אתה יכול לראות שיש תפקידים ספציפיים ל-Microsoft Sentinel עצמה, כמו Sentinel Responder, Sentinel Contributor, Sentinel Reader, שהם תפקידים נפוצים בסביבת העבודה. תפקידים אלה משמשים לניהול והגדרת התצורה של Microsoft Sentinel, והם מספקים רמות שונות של גישה לתכונות ולהגדרות השונות בתוך Sentinel. אתה יכול להקצות משתמשים או קבוצות משתמשים לתפקידים אלה על סמך תחומי האחריות שלהם ומה שאתה רוצה שהם יוכלו לעשות בסביבת העבודה של Sentinel. לדוגמה, לתפקיד ה-Sentinel Responder יש בדרך כלל יותר יכולות בהשוואה ל-th
תפקיד קורא סנטינל.
עם זאת, תפקידי סביבת עבודה אלה אינם שולטים ישירות בגישה לטבלאות נתונים ספציפיות בתוך סביבת העבודה של Log Analytics. הם שולטים במה שמשתמשים יכולים לעשות בתוך סביבת העבודה של Sentinel, כמו יצירת כללי ניתוח, ניהול אירועים וכו’. כדי לשלוט בגישה לטבלאות נתונים ספציפיות, עליך להגדיר הרשאות ברמת הנתונים בתוך סביבת העבודה של Log Analytics, שהצגתי קודם לכן.
כעת, אם הקצית משתמש לתפקיד Sentinel Reader בסביבת העבודה של Sentinel ונתת לו גישה לטבלאות נתונים ספציפיות ב-Log Analytics, הוא יוכל לעבוד עם הנתונים בטבלאות אלו על סמך תפקידו ב-Sentinel והגישה שלהם לטבלאות הנתונים הללו. לכן, חשוב לנהל גם תפקידי סביבת עבודה של Sentinel וגם הרשאות ברמת הטבלה ב-Log Analytics כדי להבטיח בקרת גישה נכונה.
50 משחקי המחשב החדשים המובילים של 2023
זכור כי זוהי סקירה כללית ברמה גבוהה, וההגדרה בפועל עשויה להשתנות בהתאם לדרישות והתצורות הספציפיות שלך. חשוב לתכנן בקפידה את אסטרטגיית בקרת הגישה מבוססת התפקידים שלך כדי להבטיח שלמשתמשים שלך תהיה רמת הגישה הנכונה לנתונים ולתכונות שהם צריכים תוך שמירה על אבטחה ותאימות.
אז, זה התהליך הכללי להגדרת בקרת גישה מבוססת תפקידים ב-Microsoft Sentinel, ואני מקווה שזה מבהיר את התפקידים וההרשאות השונות הזמינות בשירות. אם יש לך שאלות ספציפיות יותר או אם יש משהו אחר שתרצה לראות בפירוט רב יותר, אנא הודע לי, ואשמח לסייע בהמשך.