M365Con 2027 – כנס אונליין חינמי · 11–22 Jan 2027 · 120 sessions→ m365con.net

בלוג · Mirko Peters

גילוי נקודות עיוורון בציות ב-M365 באמצעות Microsoft Graph

By ·

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

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

▶ BLOGUncovering M365Compliance Blindspots…M365.FM
Titelbild: Uncovering M365 Compliance Blindspots with Microsoft Graph

ברוכים השבים לפודקאסט ולבלוג הטכני הנלווה! אם אי פעם סמכתם על לוח הבקרה לציות של Microsoft 365 שמגיע כברירת מחדל והנחתם שהכול מכוסה במלואו, ייתכן שאתם נכנסים לתחושת ביטחון כוזבת. לוחות בקרה לציות שמגיעים כברירת מחדל נועדו להיות סיכומים, לא את האמת המלאה. אותות קריטיים, כמו התאמות של מניעת אובדן מידע (DLP), פעולות eDiscovery והתראות אבטחה בסיסיות, נמצאים לעיתים מאחורי נקודות קצה של Microsoft Graph שדורשות הרשאות נפרדות, פרמטרים מתקדמים לשאילתות וחיבור נכון של הנתונים. בפרק הזה נבחן מדוע הדוחות המקוריים שלכם חסרים מידע קריטי, נמפה את נקודות הקצה המדויקות של Graph שכדאי לשאול, ונראה כיצד להזרים את הראיות הגולמיות ישירות אל Microsoft Purview לצורך דיווח ברור וניתן להגנה. כדי לשמוע את הדיון המלא בנושא, כדאי לצפות בפרק הפודקאסט הקשור: Find Missing Microsoft 365 Compliance Data with Graph.

סקירה כללית

לוחות בקרה לציות שמגיעים כברירת מחדל הם סיכומים, לא האמת. אותות קריטיים (התאמות DLP, פעולות eDiscovery והתראות אבטחה) נמצאים לעיתים מאחורי נקודות קצה של Graph עם הרשאות נפרדות. אנחנו ממפים את ממשקי ה-API, היקפי ההרשאה (scopes) ותבניות הסקריפטים המדויקים לחילוץ ראיות במלוא הנאמנות, ומרכזים אותן ב-Purview לדיווח ברור וניתן להגנה.

למי זה מועיל

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

  • מנהלי M365 ו-Entra שבונים דיווח ואוטומציה

  • צוותי אבטחה שמקשרים בין נתוני DLP, eDiscovery ותיעוד התראות

נקודות העיוורון (מדוע לוחות ברירת המחדל מפספסים)

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

  • פערי היקף: פעולות eDiscovery והתאמות DLP עשויות להימצא מחוץ לייצואים הסטנדרטיים

  • הרשאות מפוצלות: נקודות הקצה של /security ו-/compliance דורשות היקפי הרשאה שונים

  • חוסר קישורים: לוחות בקרה כמעט אף פעם לא מקשרים בין אירועים לבין משתמשים, אחראי משמורת (custodians) או שלבי תיק

נקודות הקצה החשובות ב-Graph (רשימה להעתקה)

  • התראות אבטחה (רוחב)

    • נקודת קצה: /security/alerts או /security/alerts_v2

    • הרשאות אפליקציה (דוגמאות): SecurityEvents.Read.All (או Alerts.Read.All במודלים החדשים יותר)

    • שימוש: ציר זמן של התראות, חומרה, סטטוס ושיוכים

  • מדיניות ופעילות DLP (אובדן מידע)

    • נקודות קצה (הזמינות משתנה לפי דייר):

      • /security/dataLossPreventionPolicies (רשימת המדיניות)

      • /security/dlpIncidents או נקודות קצה מתקדמות של אירועי DLP במרחב השמות security (תלוי דייר)

    • הרשאות אפליקציה: SecurityEvents.Read.All (ו/או היקפי קריאה ייעודיים ל-DLP, לפי הזמינות)

    • שימוש: התאמות, מיקומים (Exchange/SharePoint/Teams) ופעולה שבוצעה

  • eDiscovery (תיקים ופעולות)

    • /compliance/ediscovery/cases

    • נתיבי משנה: /custodians, /searches, /reviewSets, /noncustodialDataSources, /operations

    • הרשאות אפליקציה: eDiscovery.Read.All (וכתיבה אם מנהלים תיקים)

    • שימוש: סטטוס תיק, השהיות (holds), אחראי משמורת, ייצואים ופעולות של סוקרים

  • ביקורת והקשר כניסה (ראיות משלימות)

    • /auditLogs/directoryAudits, /auditLogs/signIns

    • הרשאות אפליקציה: AuditLog.Read.All, Directory.Read.All

    • שימוש: מי שינה מה ומתי, והקשר של הסשנים

טיפ: מטענים של ציות הם לעיתים מקוננים מאוד. תכננו להשתמש ב-$expand, לדפדף באמצעות @odata.nextLink ולחבר ל-/users/{id} לקבלת שמות תצוגה ומחלקות.

אימות והרשאות (הדרך ללא כאבי ראש)

  • השתמשו בהרשאות אפליקציה (service principal) לעבודות ללא השגחה

  • רשמו אפליקציות נפרדות לאבטחה לעומת Graph הליבתי, אם הארגון דורש פיצול הרשאות

  • אשרו רק היקפי הרשאה מינימליים, ואחסנו סודות ותעודות ב-Key Vault

  • מימשו backoff אקספוננציאלי עבור 429/503 ותעדו את x-ms-request-id בלוגים

תבניות סקריפטים (PowerShell או Python)

  • בחירה והרחבה: בקשו רק את השדות הנחוצים, $select=…, $expand=… עבור ישויות מקוננות

  • סינון וחלון זמן: $filter=createdDateTime ge {ISO8601} לשינויים מצטברים (deltas)

  • פגינציה: לולאה על @odata.nextLink; אל תניחו שהתוצאות נמצאות בעמוד אחד בלבד

  • נרמול: מיפוי מזהי משתמשים ואובייקטים לשמות ולמחלקות מראש, כדי שהפלטים יהיו קריאים

  • חיבור להקשר: העשרת אירועים (incidents) במטא-נתונים של משתמש, אתר, צוות או תיק לפני הייצוא

חיבור הכול ל-Purview (הופכים נתונים להחלטות)

  1. אחידות בפלט: קבצי CSV/JSON עם שמות שדות עקביים (tenant, incidentId, workload, userId, userUPN, severity, status, created, lastAction, caseId)

  2. קליטה: שמירת הקבצים במיקום אחסון מאובטח ש-Purview יכול לקרוא ממנו (למשל ADLS Gen2)

  3. תיוג וסימון: החלת תוויות רגישות או תגיות מותאמות אישית (למשל “DLP-PII-High”) לצורך ניתוב

  4. דשבורדים: Purview (או Power BI על נתוני Purview) למגמות, בעלים וגיול SLA

  5. אוטומציות: כללים שמתריעים לבעלי התיקים על חזרות או הסלמות; תקצירים שבועיים בפורמט PDF

פיילוט של 30 דקות (שלב אחר שלב)

  • 0–10 דקות: רישום אפליקציה + SecurityEvents.Read.All / eDiscovery.Read.All; יצירת סוד (secret) או תעודה

  • 10–20 דקות: כתיבת סקריפט לנקודת קצה אחת (התראות או תיקים) עם פגינציה ו-$filter לשבעת הימים האחרונים

  • 20–30 דקות: העשרה עם /users, ייצוא ל-CSV, העברה לנתיב ADLS והצגת תרשים בסיסי

מדדי ביצוע (KPIs) שמוכיחים ערך

  • אחוז האירועים שבהם מולאו הבעלים וההחלטה (disposition)

  • זמן ממוצע מאירוע ועד לתיק (או למבקר)

  • חשבונות או מיקומים של עברייני חזרה ב-30 יום

  • הפרש מול ספירות הדשבורד המובנה (OOTB), כלומר סגירת פערים

  • זמן מחזור של ביקורת (שעות שנחסכו בהכנת ראיות)

מלכודות נפוצות (ופתרונות)

  • תוצאות ריקות ← היקפי הרשאות שגויים, או שימוש בהרשאות Delegated במקום במקרים שבהם נדרשות הרשאות Application

  • חסר פירוט ← שכחתם את $expand / אוספים מקוננים לא פוענחו

  • נתונים חלקיים ← אין פגינציה; נלכדה רק העמוד הראשון

  • אי-התאמה בשמות ← אין העשרה (join) עם /users או עם נתוני משאבי אנוש

  • דשבורדים לא עדכניים ← אין הרצות מתוזמנות; הוסיפו משימה והתראות על כשלים

ניצחונות מהירים השבוע

  • משכו את שבעת הימים האחרונים מ-/security/alerts והשוו את הספירות לפורטל

  • ייצאו תיקי eDiscovery פתוחים + אחראים (custodians); שתפו עם המחלקה המשפטית לאימות

  • הריצו סריקת אירועי DLP וסמנו חזרות; פתחו משימות המשך ב-Purview

  • תזמנו חבילת ראיות שבועית (CSV + PDF) לתיבת דואר של הציות

שאלות נפוצות

  • האם צריך להיות מפתח? לא. סקריפטים של PowerShell או סקריפטים קצרים ב-Python מספיקים.

  • למה הרשאות של אפליקציה? רוב נקודות הקצה של /security ו-/compliance דורשות גישה אוטומטית (headless) ברמת אמון גבוהה.

  • האם אפשר להישאר ב-PowerShell? כן. השתמשו ב-Microsoft Graph PowerShell SDK וטפלו ב-$top, $filter, $expand ובפגינציה.

  • האם Purview הכרחי? לא בהכרח, אבל הוא הופך JSON גולמי לתהליכי עבודה ולדשבורדים הניתנים לביקורת.

סיכום

דשבורדים מסכמים; Graph מספר את הסיפור המלא. משכו את נקודות הקצה הנכונות, תקנו את האימות, עשו פגינציה והרחבה, ואז ריכזו הכול ב-Purview. תעברו מציות של סימון תיבות לנראות מוכחת ובזמן אמת, בלי להיקבר בייצואים ידניים. לשיחה מעמיקה וטיפים מומחים להתמודדות ישירה עם הפערים האלה, הקשיבו לפרק הפודקאסט הייעודי שלנו Find Missing Microsoft 365 Compliance Data with Graph. המשיכו לשפר את הסקריפטים שלכם, אבטחו את הרשאות האפליקציה שלכם, והתחילו להציג את הנתונים שהדשבורדים שלכם הסתירו!

Entities in this article

eDiscovery Compliance Dashboards Microsoft Graph Microsoft Purview Data loss prevention (DLP) PowerShell Microsoft 365 Exchange Online JSON

Related articles

RSS