יומני ביקורת לא מציגים נתונים: סיבות לתקלה ופתרונות

By Mirko Peters · 2026-04-22

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

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

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

מבוא לפערים ביומני ביקורת בסביבות Microsoft

בעולם של Microsoft, יומני ביקורת הם כמו קטעי מצלמת האבטחה – הם שם כדי לתעד מי עשה מה, ומתי. אתם מצפים שכל פעולה של משתמש ושינוי מערכתי שחשובים יירשמו, בין אם מדובר ב-Microsoft 365, ב-Azure או ב-Power Platform.

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

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

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

זיהוי תסמינים ובעיות כשנתוני ביקורת חסרים

1. חיפושים ריקים או חלקיים ביומנים: פותחים את חיפוש יומני הביקורת (אולי ב-Microsoft Purview) ולא רואים תוצאות לתקופה שבה אתם יודעים שהתרחשה פעילות. זה אחד מסימני האזהרה הראשונים – אם פעולות משתמשים או אירועי מערכת לא מופיעים ברשימה, משהו לא בסדר.
2. אין עדות לאירועים ספציפיים של משתמש או מנהל: בין אם מדובר בשיתוף קבצים, בשינויי הרשאות או בגישה לתיבת דואר, האירוע הצפוי לא נרשם. אתם מחפשים משתמש שערך מסמך או שינה הגדרה, אבל היומנים ריקים.
3. קפיצות זמן או פערים לא מוסברים בנתוני הביקורת: אתם רואים קפיצה פתאומית בחותמות הזמן – אירוע אחד בשעה 10:00, הבא בשעה 14:00 – בלי רשומות באמצע. זה מעיד על כך שחלק מנתוני היומן חסר, בין אם בגלל תום תקופת השמירה, כשל במערכת או פערי הגדרות.
4. מעקב אחר שינויים שנכשל או לא שלם: שינויים חשובים – כמו עדכונים לקבוצות אבטחה או למדיניות מניעת אובדן נתונים (DLP) – לא נרשמים. המשמעות היא שאין שרשרת אחריות ברורה, וזה עלול לפגוע בציות או בחקירות.
5. פערים בין מערכות שונות: לפעמים היומנים מופיעים במערכת אחת (כמו לוח מחוונים של SIEM) אבל לא בפלטפורמת המקור. או, גרוע מזה – היומנים לא מגיעים בכלל למערכת הניטור המרכזית בגלל כשלי העברה או אינטגרציה.
6. עיכוב בזמינות היומנים: בסביבות ענן, לפעמים היומנים פשוט מתעכבים בהופעה. זה לא אותו דבר כמו פער קבוע, אבל זה יכול לדמות את אותם תסמינים – יומנים עשויים להיראות "חסרים" באופן זמני בזמן שהם עדיין מעובדים בשל עומס מערכת או הגבלת קצב.
7. נקודות עיוורון שנובעות מהרשאות: לא כל המשתמשים רואים כל רשומה ביומני הביקורת. אם הגדרות RBAC או הרשאות המשתמשים מוגבלות מדי, ייתכן שהנתונים קיימים, אבל אין לכם את ההרשאות לראות אותם. ההבחנה הזו קריטית – לפעמים הבעיה היא בנראות, לא במעקב.
8. בעיות מדיניות ושמירת נתונים: נתוני יומן ביקורת עשויים לפוג או להיות מועברים לארכיון בהתאם למדיניות שמירה, ולכן הם נראים “חסרים” כאשר פשוט חלף משך האחסון שלהם. לדיון בממשל נתונים מעבר לבקרות הסטנדרטיות, האזינו לפודקאסט הזה על אשליית הממשל.

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

אבחון יעיל של רשומות יומן ביקורת חסרות

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

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

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

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

הגורמים הנפוצים לפערים ביומני הביקורת ב-Microsoft 365 וב-Azure

1. מדיניות ביקורת כבויה או לא מוגדרת: אם רישום הביקורת לא הופעל עבור עומסי עבודה או דיירים מסוימים, לא יירשם דבר. זו בעיה נפוצה להפתיע לאחר מעבר בין דיירים או בהקמה ראשונית. יש תמיד לוודא שהביקורת פעילה באפליקציות הליבה.
2. מדיניות שמירה ופקיעת נתונים: לעיתים הנתונים היו קיימים, אך נמחקו בהתאם לתקופת שמירה קצרה או לחלון אחסון ברירת מחדל. ב-Microsoft 365, למשל, יומני ביקורת סטנדרטיים עשויים להישמר רק 90 יום. אם אתם זקוקים לאחסון ארוך יותר, שדרגו לרמות מתקדמות, אחרת אתם מסתכנים בהחמצת עדויות היסטוריות.
3. הרשאות משתמש ומגבלות RBAC: ייתכן שרשומות ביקורת קיימות, אך הרשאות הצופה מגבילות את הנראות שלו. הגדרות Role-Based Access Control או היקפים מותאמים אישית יכולים להגביל אילו אירועים ואילו משתמשים אדם יכול לראות ביומנים. כאשר נתונים “נעלמים”, בדקו תמיד מחדש את היקף ההרשאות.
4. הפסקות שירות או עיכובים בעיבוד: תקלות זמניות בשירותי הענן או בעומס שירות גבוה עלולות להוביל לעיכוב בקליטת יומנים או לקבוצות נתונים לא שלמות. לפעמים היומנים פשוט אינם מעובדים מספיק מהר, במיוחד בשעות שיא פעילות או באירועים בענן.
5. כשלים בהעברת יומנים או באינטגרציה: בשימוש ב-SIEM או בכלי ניתוח אחרים, ייתכן שהיומנים נוצרים אך אינם מועברים בהצלחה למערכות חיצוניות. בדקו את תקינות הסוכנים, תצורת המחברים ומיפויי הקליטה, כדי שלא תחמיצו את הנראות המרכזית.
6. מורכבות היברידית ורב-פלטפורמית: בסביבות היברידיות, העברת אירועים בין מערכות מקומיות לענן עלולה להישבר, וכתוצאה מכך ייווצרו פערים כאשר צד אחד אינו מעביר יומנים לצד השני. בעלות מפוזרת או בלבול בין פלטפורמות, כפי שמודגש בפרק הזה על כשלי ממשל, יכולים להקל על כך שהגדרות ביקורת יסטו או יאבדו.
7. בעיות גרסאות ו-Shadow IT: תכונות שיתוף פעולה מודרניות (כמו AutoSave ב-M365) עלולות לצמצם את היסטוריית הגרסאות, ולגרום לכך שמדיניות הביקורת תחמיץ שינויים התנהגותיים עדינים, כפי שנדון בפודקאסט הזה על סחף ציות.

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

איך סביבות והגדרות תצורה משפיעות על רישום ביקורת

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

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

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

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

פתרונות מהירים ליומני ביקורת ואיך לוודא שהם עבדו

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

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

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

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

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

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

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

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

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

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

האם המדריך הזה עזר לכם? שתפו את המשוב והשאלות הבאות שלכם

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

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

עדיין יש שאלות? פנו לתמיכה או בקרו בקהילה

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

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