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

נתמך ב:

המדריך הזה מיועד למהנדסי אבטחה ולמהנדסי זיהוי שרוצים לנתח מחדש נתוני יומן היסטוריים ב-Google Security Operations באמצעות Log Replay. במאמר מוסבר איך לאמת הגדרת מנתח פעיל ולבקש ממחלקת התמיכה Google Cloud משימת הפעלה מחדש של יומן הרישום (Log Replay) כדי למלא מחדש מיפויים של שדות במודל נתונים מאוחד (UDM) מעודכן, על פני עד 180 ימים של טלמטריה היסטורית. באמצעות השיטה הזו, תוכלו להחיל מנתחי נתונים מעודכנים מוכנים מראש, מנתחי נתונים בהתאמה אישית או תוספים של מנתחי נתונים על יומנים גולמיים מאוחסנים, כשבמקרים אחרים הוראות מיפוי חדשות חלות רק על יומנים חדשים שנוספו. השלמה מוצלחת משפרת את החיפוש ההיסטורי אחר איומים ואת הכיסוי של כללי הזיהוי, בלי שנדרש עיבוד מחדש של יומנים מנקודות קצה של מקורות.

תרחישים נפוצים לדוגמה

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

נורמליזציה רטרואקטיבית של שדות

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

איתור איומים ב-Logs Explorer

  • המטרה: שאילתת יומנים היסטוריים באמצעות מאפייני UDM שמופו לאחרונה כדי לחקור פעילות קודמת של גורמים עוינים.
  • ערך: מאיץ את התגובה לאירועים על ידי הצגת אינדיקטורים היסטוריים לפריצה (IOC) שלא מופו בעבר בטקסט של יומן גולמי.

הערכה היסטורית של כללי זיהוי

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

מונחים חשובים

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

לפני שמתחילים

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

  • הרשאות: אתם צריכים את ההרשאות הבאות:

    • הצגה וניהול של הגדרות ניתוח ב-Google SecOps (למשל, התפקיד Chronicle API Editor).
    • ליצור בקשות תמיכה במסוף Google Cloud (למשל, התפקיד 'Tech Support Editor', roles/cloudsupport.techSupportEditor).
  • בדיקת הסביבה: מוודאים שיש לכם את מזהה מופע הלקוח של Google SecOps ואת מזהה הפרויקט המשויך Google Cloud .

מגבלות

הפעלת יומן חוזרת פועלת במסגרת גבולות התמיכה הבאים:

  • חלון הזמן הנתמך לשמירת נתונים: אפשר לבקש ניתוח מחדש של נתונים היסטוריים עד 180 ימים (6 חודשים) אחורה.
  • נדרש מנתח פעיל: Log Replay מחיל רק את הגרסה הפעילה של מנתח היומנים. אי אפשר להשתמש בהגדרות של מנתח (parser) שנמצאות בשלב טיוטה, לא פעילות או שהועברו לארכיון.
  • הגדרת היקף: הניתוח מחדש מוגבל לסוגים ספציפיים של יומנים ולחותמות זמן מוגדרות של התחלה וסיום בפורמט RFC 3339 UTC.
  • אחסון גולמי שאי אפשר לשנות: Log Replay יוצר מחדש רק רשומות UDM מנורמלות. יומני הגולמי המקוריים לא משתנים במאגר הגולמי הבלתי ניתן לשינוי.

בקשה למשימת הפעלה חוזרת של יומן

כדי לאמת את כלי הניתוח ולהגיש בקשה להפעלה מחדש של יומן:

אימות ההגדרה הפעילה של מנתח התוכן

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

  1. במסוף Google SecOps, עוברים אל SIEM Settings > Parsers.
  2. מאתרים את סוג היומן שלכם ומוודאים שהסטטוס של מנתח הנתונים המובנה, מנתח הנתונים המותאם אישית או תוסף מנתח הנתונים המעודכן הוא Active ושהוא מבצע נורמליזציה של יומנים נכנסים בזמן אמת כמצופה.

שליחת בקשת התמיכה

שולחים כרטיס תמיכה עם פרמטרים של היקף נדרש כדי Google Cloud שהתמיכה תוכל להפעיל את משימת ההפעלה מחדש של ה-backend.

  1. פותחים בקשת תמיכה באמצעות מסוףGoogle Cloud .
  2. בתיאור בקשת התמיכה, חשוב לכלול את הפרטים הבאים:

    • מזהה המופע: מזהה מופע הלקוח שלכם ב-Google SecOps ומזהה הפרויקט המשויך Google Cloud .
    • Log type: התווית הספציפית log_type לניתוח מחדש (למשל, PAN_FIREWALL או <var>CUSTOM_LOG_TYPE</var>).
    • חלון הזמן של היעד: חותמות הזמן המדויקות של ההתחלה והסיום בפורמט RFC 3339 UTC (לדוגמה, 2026-06-01T00:00:00Z עד 2026-08-31T23:59:59Z), במסגרת המגבלה הנתמכת של 180 ימים.
    • פרטים על כלי הניתוח: הגרסה הפעילה של כלי הניתוח, השם של כלי ניתוח מותאם אישית או מזהה התוסף של כלי הניתוח שרוצים להחיל (הכלי Log Replay מחיל רק את הגרסה הפעילה).
    • הצדקה עסקית: סיכום קצר של הדרישה, כמו נורמליזציה רטרואקטיבית של שדה או חקירת אירוע.

דוגמאות ומידע לעיון

אפשר להשתמש בתבנית שבקטע הזה כדי להכין את בקשת התמיכה.

תבנית לבקשת תמיכה

כדי לשלוח את תיאור בקשת התמיכה, מעתיקים את התבנית הבאה וממלאים אותה:

Request type: Google SecOps Log Replay (historical re-parsing)
Customer instance ID: <YOUR_INSTANCE_ID>
Google Cloud project ID: <YOUR_PROJECT_ID>
Target log_type: <LOG_TYPE_LABEL>
Start timestamp (RFC 3339 UTC): 2026-06-01T00:00:00Z
End timestamp (RFC 3339 UTC): 2026-08-31T23:59:59Z
Active parser or extension ID: <ACTIVE_PARSER_NAME_OR_EXTENSION_ID>
Business justification: Retroactive UDM field normalization for active parser update

פתרון בעיות

בקטע הזה מפורטות ציפיות הביצועים ופתרונות לבעיות נפוצות ב-Log Replay.

זמן אחזור ומגבלות

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

תיקון שגיאות

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

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

אימות ובדיקה

אחרי Google Cloud שצוות התמיכה יאשר שמשימת ההפעלה מחדש של היומן הושלמה, צריך לאמת את רשומות ה-UDM המעודכנות בסביבה שלכם:

  1. במסוף Google SecOps, עוברים אל Investigation > SIEM Search.
  2. מגדירים את הכלי לבחירת טווח זמן כך שיתאים לחותמות הזמן ההיסטוריות של ההתחלה והסיום מהבקשה להפעלה חוזרת.
  3. מריצים שאילתת חיפוש ב-UDM שמטרגטת את השדות החדשים ב-UDM שמופו עבור log_type כדי לוודא שהמאפיינים הנורמליים מוצגים באירועים היסטוריים.

הבעיה עדיין לא נפתרה? קבלת תשובות מחברי הקהילה וממומחי Google SecOps.