התאמה לקנה מידה: ניהול עימוד, הגבלות קצב וביקורות של דיירי M365 גדולים
By Mirko Peters ·
ברוכים השבים לבלוג! אם אתם מנהלים סביבה גדולה של Microsoft 365, אתם כבר יודעים שכלי הדיווח הסטנדרטיים שמגיעים מהקופסה רק מגרדים את פני השטח…
Automatically translated with AI from the original post. Read the English original
ברוכים השבים לבלוג! אם אתם מנהלים סביבת Microsoft 365 גדולה, אתם כבר יודעים שכלי הדיווח הסטנדרטיים שמגיעים מהקופסה חושפים רק את קצה הקרחון. כאשר צוותי אבטחה וקציני ציות מסתכלים על דיירים עצומים, סקריפטים בסיסיים ותצוגות מוכנות במרכז הניהול פשוט קורסים תחת המשקל של אלפי משתמשים, קבוצות וקבצים. ביקורת של דיירי M365 גדולים דורשת יותר מסקריפטים בסיסיים; היא דורשת גישה טקטית ומתוכנתת שמבוססת על Microsoft Graph API. במדריך המקיף הזה אנחנו ממשיכים ישירות את השיחה שלנו בפרק הפודקאסט Map Microsoft 365 Users, Groups, Files, and Shares with Graph. בואו נצלול לעומק ונבין איך לטפל בעימוד באמצעות @odata.nextLink, לכבד מגבלות קצב של 429 עם השהיה מעריכית (exponential backoff), ולהימנע ממלכודות נפוצות כמו הטיית עמוד 1 (Page 1 bias), כדי להשיג נראות מלאה של הדייר.
מבוא לאתגרי הביקורת ב-M365
סביבות ארגוניות גדלות באופן אורגני. משתמשים מגיעים והולכים, פרויקטים יוצרים מחלקות בין לילה, ושותפים חיצוניים מוזמנים למרחבי שיתוף פעולה. עם הזמן, הנראות הניהולית מתדרדרת. מרכזי הניהול הרגילים מציגים שברים מבודדים של התשתית שלכם, ומשאירים נקודות עיוורות שגורמים זדוניים או גורמים פנימיים בשוגג יכולים לנצל. כדי לקבל תמונה אמיתית של מצב האבטחה של הדייר, צריך לעבור מביקורת ידנית של לחיצה-והצבעה לסריקת גרפים אוטומטית מבוססת API. עם זאת, הרחבת השאילתות האלה לגודל ארגוני מציבה מכשולים מורכבים, כולל מטעני נתונים עצומים, הגבלות קצב אגרסיביות ומבנים יחסיים מקוננים מאוד.
למה M365 אינו מבודד: הבנת הגישה היחסית
אחת המציאויות הבסיסיות של Microsoft 365 היא ששירותים כמו SharePoint, Teams ו-OneDrive אינם סילואים מבודדים. הם מזינים זה את זה ברציפות באמצעות חברות בקבוצות ורשימות בקרת גישה בסיסיות. פעולה ניהולית אחת, כמו הוספת משתמש לקבוצת אבטחה, יכולה להתפשט לעשרות אתרי צוותים, ספריות מסמכים וערוצים פרטיים, מבלי להשאיר רצף ביקורת ברור בתצוגות הסטנדרטיות.
זה יוצר סיכוני ציות נסתרים. קישורי שיתוף לאורחים שנשלחו בצ'אטים מבודדים, קבצים משוכפלים בין ספריות צוות שונות, ושיתופים יתומים מפרויקטים שכבר נסגרו, יוצרים מסלולים בלתי נראים אל הנתונים הארגוניים שלכם. הגישה ב-M365 היא יחסית מיסודה, ולא מבוססת מיקום. כדי לבצע ביקורת אפקטיבית, צריך למפות את הקשרים המדורגים האלה ולא להתייחס לכל שירות כאל אי עצמאי.
מיפוי טביעת רגל עם Graph Explorer
לפני כתיבת אוטומציה בקנה מידה ארגוני, צריך להבין איך לעקוב ידנית אחר טביעת הרגל של משתמש באמצעות Graph Explorer. בניית השאילתות שלב אחר שלב מבטיחה שההיגיון שלכם תקין לפני כתיבת שורות קוד. הנה הפרויקט לביצוע מיפוי נקודות המגע של המשתמש:
- עיגון על המשתמש: התחילו בשליפת אובייקט המשתמש הבסיסי באמצעות GET /v1.0/users/{userPrincipalName}?$select=id,displayName,userPrincipalName.
- ספירת חברויות: משכו את הקבוצות והתפקידים המשויכים לזהות הזו באמצעות GET /v1.0/users/{id}/memberOf?$select=id,displayName.
- מעבר חזרה למשאבים של אותן קבוצות: עבור קבוצות M365 וצוותים, פנו לאתר SharePoint הבסיסי באמצעות GET /v1.0/groups/{groupId}/drive/root/children?$select=id,name,lastModifiedDateTime,webUrl, או פרטו ישירות את כונני האתר באמצעות GET /v1.0/sites/{siteId}/drives.
- שליפת הרשאות וקישורים לפריטים: בדקו את הגישה לקבצים בודדים באמצעות GET /v1.0/drives/{driveId}/items/{itemId}/permissions?$select=id,grantedToV2,link,roles,shareId.
- מעקב אחר מי ניגש למה: קשרו פעולות משתמש באמצעות יומני כניסה או התראות אבטחה, יחד עם הקשר של הקבצים והאתרים.
- סגירת המעגל להודעות בצוותים: חפשו הודעות ערוץ עבור הפניות לקבצים ספציפיים באמצעות GET /v1.0/teams/{teamId}/channels/{channelId}/messages?$search="filename" (תוך התחשבות בהרשאות ובדרישות של ה-beta).
מסננים לסינון רעש שתשתמשו בהם בפועל
שאילתות ל-Microsoft Graph ללא מסננים הן דרך מהירה להציף את המערכת שלכם בזרם נתונים מכריע. כדי להציג סיכון אמיתי, צריך אסטרטגיות סינון מדויקות. הנה דפוסי השאילתות שכדאי לכם להפעיל:
- שיתופים חיצוניים ב-7 הימים האחרונים: כוונו לקישורים אנונימיים או לקישורים ברמת הארגון באמצעות GET /v1.0/drives/{driveId}/items/{itemId}/permissions?$filter=link/scope eq 'anonymous' or link/scope eq 'organization'.
- רק סוגי קבצים מסוכנים: הוסיפו מסננים כמו $filter=endsWith(resourceReference/name,'.xlsm') או endsWith(resourceReference/name,'.pst') כדי לאתר מאקרו וקבצי ארכיון.
- אזכורים של מונחים רגישים מחוץ לשעות העבודה ב-Teams: חפשו בהודעות ערוץ מונחים כמו confidential, ולאחר מכן סננו את התוצאות לפי חותמות זמן יצירה שמחוץ לשעות העבודה הרגילות.
- שמרו על מטענים קלים: כללו תמיד פרמטרי $select כדי להחזיר רק מזהים, שמות, כתובות URL וחותמות זמן הכרחיים.
- תקרה למיון ראשוני: השתמשו ב-$top=50 לבדיקות מהירות, אך הסירו פרמטר זה בעת הרצת ייצואים מלאים למאגר הנתונים שלכם.
דרישות חובה לקנה מידה ארגוני: עימוד והגבלת קצב
כאשר מריצים ביקורות על פני דייר עם מאות אלפי אובייקטים, הסקריפטים שלכם ייתקלו בחומות אם הם אינם מתחשבים במגבלות ה-API ובעימוד. לעולם אינכם מסיימים למשוך נתונים לפני שעקבתם אחר המאפיין @odata.nextLink בכל עמוד שה-API מחזיר. התעלמות מכך תגרום לכך שהסקריפטים ילכדו רק את האצווה הראשונה של התוצאות, ותפספסו לחלוטין את שאר הדייר.
יתר על כן, עליכם לכבד תגובות של הגבלת קצב מסוג HTTP 429. יישמו לוגיקה חזקה של backoff מעריכי, כך שהסקריפט ייעצר, ימתין עד תום תקופת ההתקררות וימשיך בדיוק מהנקודה שבה עצר. אצו את הבקשות בחוכמה: העדיפו מעט בקשות גדולות ולוגיות יותר, ושמרו במטמון את מיפויי קבוצה-לאתר. בדיירים גדולים מאוד, חלקו את הסריקות לפי אתר או טווח תאריכים, ותזמנו אותן בשעות שפל כדי לא לפגוע בביצועי הסביבה הייצורית.
מלכודות נפוצות ותיקונים מהירים
גם מנהלים מנוסים נתקלים במכשולים כשמרחיבים ביקורות M365. אלה המלכודות הנפוצות ביותר וכיצד לתקן אותן:
- מלכודת: ייצואי CSV סוטים לאורך זמן כאשר הסכמות משתנות. תיקון: השתמשו ישירות ב-Graph API עם טרנספורמציות מגורסאות, וטפלו בשדות לא מוכרים בצורה מתונה.
- מלכודת: מזהים מעורבים, כמו GUIDs לעומת שמות משתמש עיקריים (UPN), שוברים חיבורים בין טבלאות במסד הנתונים. תיקון: נרמלו הכול למודל סמנטי נקי הכולל Users, Groups, Sites, Drives, Items ו-Permissions.
- מלכודת: הטיה לעמוד הראשון מסתירה את רוב אירועי האבטחה הטמונים עמוק יותר בתוצאות. תיקון: תמיד רשמו ביומן את מספר העמודים שעובדו, והגדירו התראות אם נפח הנתונים הצפוי יורד לפתע.
- מלכודת: שטף של קבצים לא רלוונטיים מכביד על מנועי העיבוד. תיקון: הפעילו מסננים קפדניים לפי היקפי שיתוף, חלונות זמן ורשימות של מונחים רגישים.
- מלכודת: שיתופים ב-Teams מנותקים מהקבצים שבבסיסם. תיקון: קשרו ישירות כתובות URL של הודעות ערוץ לפריטי הכונן, ושמרו את שני המזהים יחד.
מדדי KPI ברמה ניהולית שנפתחים בזכות זה
נתונים טכניים שווים משהו רק אם ניתן לתרגם אותם למודיעין עסקי אקטיבי עבור ההנהלה. בניית צינור ביקורת אוטומטי של Graph פותחת מדדי KPI ניהוליים חזקים:
- מהירות חשיפה חיצונית: מדדו קישורי אורחים חדשים שנוצרו בשבוע, מפוצלים לפי אתר וצוות.
- שיעור גישה לקבצים רגישים: עקבו אחר צופים ייחודיים בתוכן בעל תווית, והפרידו בין משתמשים פנימיים לאורחים חיצוניים.
- אדווה של סיכון קבוצתי: מדדו קבצים שנעשו נגישים לראשונה תוך 24 שעות משינויים מהותיים בחברות בקבוצות.
- מחזור צללים: עקבו אחר קבצים רגישים המופיעים במספר צוותים או אתרים בתוך ספרינט אחד.
- יעילות ניקוי: עקבו לאורך זמן אחר מספר הקישורים שבוטלו ומדדי זמן לתיקון.
מתכון שאילתות להתחלה מהירה
אם אתם מוכנים להתחיל לבנות צינור איסוף משלכם, השתמשו בזרימה להעתקה והדבקה הבאה כדי להתחיל:
- משכו פרטי ליבה של משתמש וחברויות: /users/{upn}?$select=id,displayName ו-/users/{id}/memberOf?$select=id,displayName.
- לכל קבוצת M365, פרטו את פריטי הכונן: /groups/{groupId}/drive/root/children?$select=id,name,webUrl,lastModifiedDateTime&$top=200, תוך מעקב אחר @odata.nextLink.
- לכל פריט, משכו את ההרשאות: /drives/{driveId}/items/{itemId}/permissions?$select=id,roles,grantedToV2,link, וסננו להיקפים של anonymous או organization.
- ייצאו שורות למאגר הנתונים שייעודד לכך, וכללו: זמן דייר, מזהי אתרים, מזהי כוננים, מזהי פריטים, כתובות URL, בעלים, היקפים ופרטי תפוגה.
- הציגו את הנתונים המנורמלים ב-Power BI ללוחות מחוונים להנהלה ולתפעול.
איך הופכים את זה ללוח מחוונים חי
ביקורת שרצה פעם אחת היא תמונת מצב; ביקורת שרצה ברציפות היא תוכנית אבטחה. כדי להפוך קריאות Graph גולמיות ללוח מחוונים חי, הזרימו את הנתונים ל-Power Dataflows כדי לייצר טבלאות מנורמלות של Users, Groups, Sites, Drives, Items, Permissions ו-Messages. מודלו את הנתונים בסכמת כוכב עם Items במרכז, ותחזקו קשרים נקיים אל Users ואל Groups.
הגדירו רענון incremental על בסיס שדות lastModifiedDateTime, והריצו עדכונים תוך-יומיים עבור אתרים בסיכון גבוה. לבסוף, הגדירו התראות אוטומטיות שיופעלו בכל פעם שמופיעים קישורים חיצוניים חדשים לתוכן מסווג, או כאשר קפיצות בהתפשטות הקבוצות מעידות על הרחבה לא מורשית של הגישה.
תוכנית פריסה של 30 יום
רומא לא נבנתה ביום אחד, וגם מסגרת ביקורת ארגונית דורשת שלבים מדוקדקים. עקבו אחר תוכנית הפריסה הבת 30 הימים הבאה כדי להבטיח הטמעה חלקה:
שבוע 1: הגדירו רישום אפליקציה ב-Azure, הקצו הרשאות Graph API בעלות הרשאות מינימליות, וקבעו בסיס לשאילתות הראשונות שלכם באמצעות הפרמטרים $select ו-$filter.
שבוע 2: פתחו סקריפטים לחלוקה לעמודים (pagination), נרמלו מזהים לפורמט אחיד של UPN ושמות מכשירים, והריצו את ייצוא הנתונים הראשון מקצה לקצה בהצלחה.
שבוע 3: בנו את מודל הנתונים שלכם ב-Power BI, והגדירו מדדי ביצוע מרכזיים כמו חשיפה חיצונית, סיכון התפשטות וציר הזמן מרגע החשיפה ועד לביטולה.
שבוע 4: אוטומטו את רעננות הנתונים, הטמיעו התראות על חריגות, ותעדו נהלי עבודה סטנדרטיים עבור צוות חקירות האבטחה שלכם.
למי כדאי לצפות
המסגרת הזו נועדה במיוחד עבור מנהלי M365 ומובילי SecOps שחושדים שלוחות המחוונים הירוקים שלהם מסתירים אזורים אפורים, עבור צוותי ציות שנזקקים לנראות מקצה לקצה של שיתופים בלי להתבסס על כלי צד שלישי נוספים, ועבור בעלי שיתוף פעולה האחראים לשמירה על פרקטיקות בטוחות של שיתוף חיצוני.
טיפים מהשטח
כשאתם מפעילים את הסקריפטים הללו בסביבת הייצור, שימו לב לטיפים המהירים הבאים: התחילו תמיד את החקירות שלכם מהמשתמש או מהקובץ, ואז פנו לשני הכיוונים כדי לחסל נקודות עיוורון. ראו בכל אירוע של הוספה לקבוצה שינוי בסיכון גבוה, ובדקו את הגישה במורד הזרם תוך 24 שעות. נהלו רשימה חיה ומעודכנת של מונחים רגישים לחיפוש בשמות קבצים ובהודעות Teams. ולבסוף, תעדו בקפידה את מספר העמודים ואת נפחי התוצאות – שתיקה מהסקריפט היא לעתים קרובות סימן לעבודה תקולה ולא לדייר נקי.
סיכום
שליטה ב-pagination, כיבוד מגבלות קצב (rate limits) והימנעות מהטיית עמוד 1 הם כישורים חיוניים לכל מי שאחראי על אבטחת דייר גדול של Microsoft 365. כאשר עוברים מעבר לקונסולות הניהול הבסיסיות ומנצלים את מלוא העוצמה התכנותית של Microsoft Graph API, ניתן להפוך סיכוני שיתוף בלתי נראים לתובנות אבטחה ברורות ומדידות.
למעמקים נוספים, דוגמאות קוד ומתכוני Graph מהשטח, הקשיבו לדיון המלא שלנו בפודקאסט. צפו בפרק הקשור וקראו את כל הפרטים ב-Map Microsoft 365 Users, Groups, Files, and Shares with Graph. היו בטוחים, המשיכו לאוטמט, ונתראה בפרק הבא!