עבודה עם ממשק המשתמש של הפידים

נתמך ב:

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

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

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

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

פורמטים נתמכים של דחיסה להעלאת פידים כוללים ‎ .gz,‏ ‎.tar.gz,‏ ‎.tar ו-solr.gz. בטבלה הבאה מפורטים הגדלים השונים של קבצים שנתמכים בהזנות של Google SecOps לצורך טרנספורמציה:

פעולה סוג קלט גודל מומלץ משך הזמן הצפוי גודל מקסימלי
מודלים של נתונים CSV פחות מ-5GB ‫< 7 דקות ‫10GB
מודלים של נתונים CSV פחות מ-5GB כ-30 דקות ‫10GB
מודלים של נתונים CSV TBD TBD 2 GB
מודלים של נתונים XML / ‏ JSON פחות מ-1GB ‫< 10 דקות 2 GB
מודלים של נתונים XLS / XLSX פחות מ-50MB ~דקה אחת 50MB
מיזוג קבצים הכול פחות מ-1GB משתנה בהתאם למספר הקבצים 100GB
פריסת קבצים Non-ZIP פחות מ-5GB משתנה בהתאם למספר הקבצים ‫10GB (לא דחוס)
פריסת קבצים מיקוד - משתנה בהתאם למספר הקבצים ‫4GB (לא דחוס)

מגבלות על שורות ביומן ותוחמים

כשמבצעים המרה של יומנים מבוססי-טקסט (JSON,‏ CSV או Syslog), חשוב לוודא שהנתונים עומדים במגבלות ההמרה הספציפיות האלה:

  • גודל השורה המקסימלי: גודל של שורה אחת ביומן לא יכול להיות יותר מ-4MB. אם שורה אחת חורגת מהמגבלה הזו, הפיד ייכשל עם השגיאה MaxLogLineSize4MBExceeded.
  • תווי הפרדה נתמכים: נתמכים גם מעבר לשורה חדשה (\n) וגם החזרת כרכרה + מעבר לשורה חדשה (\r\n).

ההשפעה של שינוי פרויקט Cloud המקושר על פידים של נתונים

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

  • AMAZON_S3_V2
  • AMAZON_SQS_V2
  • GOOGLE_CLOUD_STORAGE_V2
  • AZURE_BLOBSTORE_V2
  • GOOGLE_CLOUD_STORAGE_EVENT_DRIVEN

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

מה יקרה במהלך ההעברה

בפידים המושפעים, יחולו השינויים הבאים:

  • סטטוס הפיד: הפידים שנוצרו לפני המיגרציה יפסיקו מיד לשלוף נתונים בזמן אמת ויהפכו לקריאה בלבד.
  • נתונים קיימים: כל הנתונים שכבר הועברו אל Google SecOps לפני ההעברה ייקלטו באופן אוטומטי, ולא יאבדו נתונים.
  • הודעות שגיאה: אם תנסו לערוך או למחוק פיד ישן, תוצג לכם ההודעה: This feed is read-only because this SecOps has now moved to a new Google Cloud Project (BYOP). To continue ingesting data from this source, please create a new feed.

פעולות נדרשות ללקוחות

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

  1. יצירה מחדש של פידים: צריך ליצור פידים חדשים במקום הפידים שהיו לפני ההעברה.
  2. הגדרת הערך Max File Age: כשמגדירים את הפידים החדשים, צריך להגדיר את הערך Max File Age (הגיל המקסימלי של הקובץ) לפרק זמן של שעתיים לפני שהתחיל העדכון של BYOP. הזמן הזה מאפשר מעבר חלק.

  3. ניהול נתונים כפולים: בהתאם לגיל המקסימלי של הקובץ שתבחרו, יכול להיות שתהיה העברה של נתונים כפולים. פרטים טכניים על האופן שבו Google SecOps מסנן את היומנים המיותרים האלה זמינים במאמר מניעת ביטול כפילויות.

  4. תיעוד ומחיקה של פידים קיימים (לפני ההעברה): לפני שמתחילים בהעברת ה-BYOP, צריך לתעד את הגדרות התצורה של כל הפידים הקיימים שמשתמשים במחברים המושפעים (לדוגמה, Amazon S3 V2), ואז למחוק את הפידים. אם לא מוחקים פידים שנוצרו לפני ההעברה, הם הופכים לבלתי ניתנים לניהול ונשארים בממשק האינטרנט של Google SecOps כהגדרות יתומות.

דרכים להגדרת פידים

לקוחות Google SecOps יכולים להגדיר פיד בפלטפורמה בשתי דרכים. משתמשים בשיטה שהכי מתאימה לסביבה שלכם:

  • הגדרות SIEM > פידים (סטנדרטי)
  • ‫Content Hub > Content Packs (פרימיום)

הגדרת הפידים

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

הוספת פיד

כדי להוסיף פיד לחשבון Google SecOps, פועלים לפי השלבים הבאים:

  1. בתפריט Google SecOps, בוחרים באפשרות SIEM Settings (הגדרות SIEM) > Feeds (פידים).

  2. לוחצים על הוספת פיד חדש.

  3. בדף הבא, לוחצים על הגדרת פיד יחיד. הערה: השלב הזה לא רלוונטי ללקוחות שמשתמשים בפלטפורמה העצמאית של Google SecOps SIEM.

  4. מוסיפים שם לזיהוי הפיד.

  5. ברשימה סוג המקור, בוחרים את סוג המקור לייבוא נתונים אל Google SecOps. אפשר לבחור מבין סוגי מקורות הפיד הבאים:

    • Amazon Data Firehose
    • ‫Amazon S3 (הוצא משימוש)
    • ‫Amazon S3 (V2)
    • ‫Amazon SQS (הוצא משימוש)
    • ‫Amazon SQS (V2)
    • ‫Azure Blob Storage (הוצא משימוש)
    • ‫Azure Blob Storage (V2)
    • Custom API
    • ‫Google Cloud Pub/Sub
    • Cloud Storage (הוצא משימוש)
    • Cloud Storage (V2)
    • Cloud Storage Event Driven
    • API של צד שלישי
    • Webhook

    חשוב לדעת:

    • כשמשתמשים בפידים של Amazon S3 (הוצא משימוש), Amazon SQS (הוצא משימוש), Azure Blob Storage (הוצא משימוש) ו- Google Cloud Cloud Storage (הוצא משימוש), צריך לוודא שיש נתיב תקף לספרייה.
    • כשמשתמשים ב-Amazon SQS (הוצא משימוש) או ב-Amazon SQS (גרסה 2), צריך להעניק ל-Google SecOps הרשאות מפורשות למחיקת הודעות מתור ה-Amazon SQS.
    • כשמשתמשים בפידים של Amazon SQS (הוצא משימוש), חשוב לוודא שרק פיד אחד צורך הודעות מהתור. הודעות שנקראו על ידי אפליקציה או פיד אחרים לא נכללות בפיד הנוכחי.
    • השימוש ב-Amazon SQS (הוצא משימוש) כסוג של מקור פיד נתמך רק עבור יומנים בקטגוריות של Amazon S3.

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

    אם בוחרים באפשרות Cloud Storage כסוג המקור, משתמשים באפשרות קבלת חשבון שירות כדי לקבל חשבון שירות ייחודי. דוגמה להגדרת פיד ב-Google Cloud Storage

  7. לוחצים על הבא.

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

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

  10. לוחצים על הבא.

  11. בודקים את הגדרת הפיד החדשה בכרטיסייה Finalize.

  12. לוחצים על שליחה. ‫Google SecOps משלים בדיקת אימות של הפיד החדש. אם הפיד עובר את הבדיקה, נוצר שם בשביל הפיד, הוא נשלח ל-Google SecOps ו-Google SecOps מתחיל לנסות לאחזר נתונים.

    השלמת בקשת הפיד

הגדרת כמה פידים למשפחת מוצרים (ללקוחות Google SecOps בלבד)

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

  • סוגי יומנים בסיסיים: מסומנים כמומלצים. מומלץ להשתמש בסוגי היומנים האלה כדי להפעיל את הפונקציונליות הבסיסית של הפלטפורמה.
  • סוגי יומנים משלימים: מסומנים כאופציונליים. סוגי היומנים האלה מספקים הקשר נוסף.

כדי לפשט את ההגדרה, הפלטפורמה מספקת הוראות הגדרה ספציפיות ופרמטרים מוגדרים מראש לכל הגדרה. לדוגמה, ב-CrowdStrike Falcon, אפשר ליצור כמה פידים ייחודיים גם בקטגוריה מומלץ וגם בקטגוריה אופציונלי של סוגי יומנים, כדי לוודא שיש כיסוי מקיף מספיק של הנתונים.

הגדרת הפיד ל-CrowdStrike EDR

כדי להגדיר פיד של יומנים עבור CrowdStrike EDR, פועלים לפי השלבים הבאים.

  1. בקטע הגדרות > פידים, לוחצים על הוספת פיד חדש.
    1. לוחצים על המוצר CrowdStrike Falcon:.
    2. בוחרים את סוג היומן CrowdStrike EDR.
  2. לחלופין, מתוך Content Hub > Content Packs (מרכז התוכן > חבילות תוכן), לוחצים על המוצר CrowdStrike Falcon:
    1. לוחצים על Get Started.
    2. בוחרים את סוג היומן CrowdStrike EDR.

  3. מציינים ערכים בשדות הבאים:

    שדה תיאור
    Source Type ‫Amazon SQS
    Region האזור ב-AWS S3 שמשויך ל-URI.
    Queue Name השם של תור SQS שממנו רוצים לקרוא.
    Account Number מספר החשבון ב-SQS.
    Source Deletion Option מציין אם למחוק קבצים וספריות אחרי ההעברה.
    Queue Access Key ID מפתח גישה אלפאנומרי בן 20 תווים לחשבון, כמו AKIAOSFOODNN7EXAMPLE.
    Queue Secret Access Key מפתח גישה סודי באורך 40 תווים אלפאנומריים לחשבון, לדוגמה, wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY.

  4. אופציונלי: מגדירים את הפרמטרים הבאים:

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

  5. לוחצים על יצירת פיד.

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

יצירת רשימה של כתובות IP מותרות

מפעילים את רשימת ההיתרים ומוסיפים את טווח כתובות ה-IP של Google לכל סוגי היומנים שמקבלים נתונים מממשקי API של צד שלישי.

מחיקת קובצי מקור

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

אפשרויות למחיקת מקורות

  • בשדה SOURCE DELETION OPTION (אפשרות למחיקת מקור) מוצגות האפשרויות הבאות לגבי סוגי מקורות נתונים נתמכים, כולל Cloud Storage:

    • לא למחוק קבצים אף פעם
    • מחיקת קבצים שהועברו וספריות ריקות
    • מחיקת קבצים שהועברו

  • ‫Microsoft Azure Blob Storage‏ (AZURE_BLOBSTORE) לא תומך במחיקה של קובצי מקור. בשדה SOURCE DELETION OPTION (אפשרות מחיקת המקור), בוחרים רק באפשרות Never delete files (לא למחוק קבצים לעולם).

  • במקורות הפידים הבאים ("feedSourceType"): GOOGLE_CLOUD_STORAGE_V2, GOOGLE_CLOUD_STORAGE_EVENT_DRIVEN, AMAZON_S3_V2, AMAZON_SQS_V2 ו-AZURE_BLOBSTORE_V2, בשדה SOURCE DELETION OPTION יש שתי אפשרויות:

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

הגדרות והרשאות ספציפיות למקור

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

דוגמה להגדרת פיד של Google Cloud Storage

  1. בתפריט Google SecOps, בוחרים באפשרות הגדרות ואז לוחצים על פידים.
  2. לוחצים על הוספת פיד חדש.
  3. בדף הבא, לוחצים על הגדרת פיד יחיד. השלב הזה לא רלוונטי אם אתם משתמשים בפלטפורמת Google SecOps SIEM עצמאית.
  4. בוחרים באפשרות Cloud Storage v2 בשדה Source Type.
  5. בוחרים את סוג היומן. לדוגמה, כדי ליצור פיד ליומני ביקורת של Google Kubernetes Engine, בוחרים באפשרות Google Kubernetes Engine audit logs (יומני ביקורת של Google Kubernetes Engine) בתור Log Type (סוג יומן).
  6. לוחצים על טעינת חשבון שירות. ‫Google SecOps מספק חשבון שירות ייחודי שמשמש להזנת נתונים ל-Google SecOps. לחלופין, אפשר לקבל את חשבון השירות הזה באופן פרוגרמטי באמצעות ה-API. מידע נוסף זמין במאמר אחזור חשבון שירות.
  7. אופציונלי: מגדירים את חשבון השירות. מידע נוסף זמין במאמר בנושא הענקת גישה לחשבון השירות של Google SecOps.
  8. לוחצים על הבא.

  9. בהתאם להגדרות של Cloud Storage שיצרתם, מציינים ערכים בשדות הבאים:

    • URI של קטגוריית אחסון

    • אפשרות למחיקת מקור

    מידע נוסף על הגדרת קטגוריות ב-Cloud Storage זמין במאמר יצירת קטגוריות.

  10. לוחצים על הבא ואז על שליחה.

מתן גישה לחשבון השירות של Google SecOps

  1. במסוף Google Cloud , נכנסים לדף Buckets של Cloud Storage.

    כניסה לדף Buckets

  2. מעניקים לחשבון השירות גישה לאובייקטים הרלוונטיים ב-Cloud Storage.

    • כדי לתת הרשאת קריאה לקובץ ספציפי, פועלים לפי השלבים הבאים:

      1. בוחרים את הקובץ ולוחצים על גישת עריכה.
      2. לוחצים על Add principal.
      3. בשדה New principals, מזינים את השם של חשבון השירות של Google SecOps.
      4. מקצים תפקיד שמכיל את הרשאת הקריאה לחשבון השירות של Google SecOps. לדוגמה, צפייה באובייקט אחסון (roles/storage.objectViewer). אפשר לעשות את זה רק אם לא הפעלתם גישה אחידה ברמת הקטגוריה.
      5. לוחצים על Save.

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

      • עבור "feedSourceType": "GOOGLE_CLOUD_STORAGE":

        1. מוסיפים את חשבון השירות של Google SecOps כחשבון ראשי לקטגוריית האחסון ומקצים לו את תפקיד ה-IAM‏ Storage Object Viewer (roles/storage.objectViewer).
        2. אם מגדירים את הפיד למחיקת קובצי מקור, צריך להוסיף את חשבון השירות של Google SecOps כחשבון משתמש ב-Bucket ולהעניק לו את תפקיד ה-IAM‏ Storage Object Admin‏ (roles/storage.objectAdmin).

      • ל-"feedSourceType": "GOOGLE_CLOUD_STORAGE_V2", מקצים את התפקידים הבאים:

        1. הקצאת התפקיד הבא:

          • צפייה באובייקטים באחסון (roles/storage.objectViewer) אם ההעברה היא לקטגוריה אחרת של Cloud Storage.

        2. נותנים אחד מהתפקידים הבאים, בהתאם לאפשרות שבוחרים באפשרות מחיקת המקור. אם בוחרים באפשרות On Success, צריך להעניק את התפקיד Storage Legacy Bucket Writer. אם בוחרים באפשרות לעולם לא, צריך להקצות את התפקיד קריאה בקטגוריה באחסון מדור קודם:

          • ‫Storage Legacy Bucket Writer (roles/storage.legacyBucketWriter) אם נדרשת הרשאת מחיקת אובייקטים.
          • ‫Storage Legacy Bucket Reader (roles/storage.legacyBucketReader) אם לא נדרשת הרשאת מחיקת אובייקטים.

      • עבור "feedSourceType": "GOOGLE_CLOUD_STORAGE_EVENT_DRIVEN":

        1. נותנים את אחד מהתפקידים הבאים:

          • צפייה באובייקטים באחסון (roles/storage.objectViewer) אם ההעברה היא לקטגוריה אחרת של Cloud Storage.
          • ‫Storage Object Creator (roles/storage.objectCreator) אם ההעברה היא למערכת קבצים.

        2. נותנים את אחד מהתפקידים הבאים:

          • ‫Storage Legacy Bucket Writer (roles/storage.legacyBucketWriter) אם נדרשת הרשאת מחיקת אובייקטים.
          • ‫Storage Legacy Bucket Reader (roles/storage.legacyBucketReader) אם לא נדרשת הרשאת מחיקת אובייקטים.

הפעלת גישת STS ל-Amazon S3 ול-Azure Storage

ה-STS משמש להעברת נתונים מ-Amazon S3 וממאגרי blob ב-Azure Storage אל Google SecOps באמצעות הפידים הבאים של Google Cloud Storage:

  • ‫Amazon S3 (V2)
  • ‫Amazon SQS (V2)
  • ‫Azure Blob Storage (V2)

‫STS שולח בקשות להעברת נתונים לשירותי האחסון של Amazon S3 ו-Azure מתוך קבוצה של טווחי כתובות IP מוגדרים של STS. טווחי כתובות ה-IP של STS מפורסמים בקובץ ה-JSON הבא: טווחי כתובות IP

כדי להשתמש בסוגים האלה של מקורות פידים של STS, יכול להיות שתצטרכו לשנות את ההגבלות על גישה לכתובות IP כדי לאפשר ל-STS לגשת לשירותי האחסון של Amazon S3 ו-Azure:

  1. שולפים את טווחי כתובות ה-IP העדכניים מקובץ ה-JSON.

    מומלץ לקרוא נתונים מקובץ ה-JSON הזה לפחות פעם בשבוע כדי לשמור על עדכניות של הגדרות האבטחה. כשמוסיפים טווח חדש לקובץ, המערכת ממתינה לפחות 7 ימים לפני שהיא משתמשת בטווח הזה לבקשות מ-STS.

    במאמר כתובות IP לדומיינים שמוגדרים כברירת מחדל מופיע סקריפט Python לדוגמה שמחלץ טווחי כתובות IP מקובץ JSON.

  2. משווים את טווח כתובות ה-IP הנוכחי creationTime לטווח כתובות ה-IP creationTime שנקרא מקובץ ה-JSON הקודם. אם יש הבדלים, צריך לעדכן את ההגבלות על גישה לכתובות IP ב-Amazon S3 וב-Azure Storage blobstores.

    • ב-Amazon S3

      כדי לעדכן את ההגבלות על גישה לכתובות IP ב-blobstore של Amazon S3:

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

      כדי להוסיף את הטווחים האלה ככתובות IP מותרות, משתמשים בשדה Condition ב-bucket policy, כמו שמתואר במסמכי AWS S3 בנושא ניהול גישה על סמך כתובות IP ספציפיות.

    • ב-Azure Storage

      כדי לעדכן את ההגבלות על גישה לכתובות IP ב-blobstore של Azure Storage:

      אם אתם מגבילים את הגישה למשאבי Azure באמצעות חומת אש של Azure Storage, אתם צריכים להוסיף את טווחי כתובות ה-IP שמשמשים את עובדי STS לרשימת כתובות ה-IP המותרות.

      כדי להוסיף את טווחי כתובות ה-IP האלה ככתובות IP מורשות, פועלים לפי ההוראות במאמר הגדרת חומות אש ורשתות וירטואליות ב-Azure Storage.

הגדרת פיד בדחיפה של Pub/Sub

כדי להגדיר פיד מסוג Pub/Sub push:

  1. יוצרים פיד מסוג Pub/Sub push.
  2. מציינים את כתובת ה-URL של נקודת הקצה במינוי ל-Pub/Sub.

יצירת פיד מסוג Pub/Sub push

  1. בתפריט של Google SecOps, בוחרים באפשרות הגדרות ואז לוחצים על פידים.
  2. לוחצים על הוספת חדש.
  3. בשדה שם הפיד, מזינים שם לפיד.
  4. ברשימה Source type, בוחרים באפשרות Google Cloud Pub/Sub Push.
  5. בוחרים את סוג היומן. לדוגמה, כדי ליצור פיד עבור Open Cybersecurity Schema Framework (מסגרת סכימה פתוחה לאבטחת סייבר), בוחרים באפשרות Open Cybersecurity Schema Framework (OCSF) בתור סוג היומן.
  6. לוחצים על הבא.
  7. אופציונלי: מציינים ערכים לפרמטרים הבאים של הקלט:
    • תו מפריד לפיצול: התו המפריד שמשמש להפרדה בין שורות ביומן. אפשר להשתמש רק ב-\n.
    • מרחב השמות של הנכס: מרחב השמות של הנכס.
    • תוויות להוספה: התווית שתתווסף לאירועים מהפיד הזה.
  8. לוחצים על הבא.
  9. בודקים את ההגדרות של הפיד החדש במסך סיום ולוחצים על שליחה.
  10. בכרטיסייה Details (פרטים), מעתיקים את כתובת ה-URL של נקודת הקצה של הפיד מהשדה Endpoint Information (פרטי נקודת הקצה). צריך את כתובת ה-URL של נקודת הקצה הזו כדי ליצור מינוי דחיפה ב-Pub/Sub.
  11. אופציונלי: לוחצים על המתג הפיד מופעל כדי להשבית את הפיד. הפיד מופעל כברירת מחדל.
  12. לוחצים על סיום.

מציינים את כתובת ה-URL של נקודת הקצה

אחרי שיוצרים פיד מסוג Pub/Sub push, מציינים את כתובת ה-URL של נקודת הקצה באופן הבא:

  1. ב-Pub/Sub, יוצרים מינוי דחיפה. מידע נוסף על יצירת מינוי דחיפה זמין במאמר יצירת מינויי דחיפה.
  2. מציינים את כתובת ה-URL של נקודת הקצה, שזמינה בפיד הדחיפה של Google Cloud Pub/Sub.
  3. בוחרים באפשרות Enable authentication ובוחרים חשבון שירות.
  4. משביתים את האפשרויות פריסת מטען ייעודי (payload) של הודעות פוש ופריסת מטען ייעודי (payload) של הודעות פוש לכתיבת מטא-נתונים של הודעות.

הגדרה של פיד Amazon Data Firehose

כדי להגדיר פיד של Amazon Data Firehose:

  1. יוצרים פיד Amazon Data Firehose ומעתיקים את כתובת ה-URL של נקודת הקצה ואת המפתח הסודי.
  2. יוצרים מפתח API כדי לבצע אימות ל-Google SecOps. אפשר גם לעשות שימוש חוזר במפתח API קיים כדי לבצע אימות ל-Google SecOps.
  3. מציינים את כתובת ה-URL של נקודת הקצה ב-Amazon Data Firehose.

יצירת פיד Amazon Data Firehose

  1. בתפריט של Google SecOps, בוחרים באפשרות הגדרות ואז לוחצים על פידים.
  2. לוחצים על הוספת חדש.
  3. בשדה שם הפיד, מזינים שם לפיד.
  4. ברשימה סוג המקור, בוחרים באפשרות Amazon Data Firehose.
  5. בוחרים את סוג היומן. לדוגמה, כדי ליצור פיד עבור Open Cybersecurity Schema Framework (מסגרת סכימה פתוחה לאבטחת סייבר), בוחרים באפשרות Open Cybersecurity Schema Framework (OCSF) בתור סוג היומן.
  6. לוחצים על הבא.
  7. אופציונלי: מציינים ערכים לפרמטרים הבאים של הקלט:
    • תו מפריד לפיצול: התו המפריד שמשמש להפרדה בין שורות ביומן. אפשר להשתמש רק ב-\n.
    • מרחב השמות של הנכס: מרחב השמות של הנכס.
    • תוויות להוספה: התווית שתתווסף לאירועים מהפיד הזה.
  8. לוחצים על הבא.
  9. בודקים את ההגדרות של הפיד החדש במסך סיום ולוחצים על שליחה.
  10. לוחצים על יצירת מפתח סודי כדי ליצור מפתח סודי לאימות הפיד הזה.
  11. חשוב להעתיק ולשמור את המפתח הסודי כי לא תהיה לך אפשרות לראות אותו שוב. אפשר ליצור מחדש מפתח סודי חדש, אבל יצירה מחדש של המפתח הסודי מבטלת את המפתח הסודי הקודם.
  12. בכרטיסייה פרטים, מעתיקים את כתובת ה-URL של נקודת הקצה של הפיד מהשדה פרטי נקודת הקצה. תצטרכו את כתובת ה-URL של נקודת הקצה הזו כשמציינים את הגדרות היעד של זרם ההעברה ב-Amazon Data Firehose.
  13. אופציונלי: לוחצים על המתג הפיד מופעל כדי להשבית את הפיד. הפיד מופעל כברירת מחדל.
  14. לוחצים על סיום.

יצירת מפתח API לשימוש בפיד Amazon Data Firehose

כדי ליצור מפתח API לשימוש בפיד Amazon Data Firehose:

  1. עוברים לדף Credentials במסוף Google Cloud .
  2. לוחצים על Create credentials ובוחרים באפשרות API key.
  3. להגביל את הגישה של מפתח ה-API ל-Chronicle API.

מציינים את כתובת ה-URL של נקודת הקצה

ב-Amazon Data Firehose, מציינים את נקודת הקצה מסוג HTTPS ואת מפתח הגישה, באופן הבא:

  1. מוסיפים את מפתח ה-API לכתובת ה-URL של נקודת הקצה של הפיד ומציינים את כתובת ה-URL הזו ככתובת ה-URL של נקודת הקצה של ה-HTTP בפורמט הבא:

      ENDPOINT_URL?key=API_KEY

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫ENDPOINT_URL: כתובת ה-URL של נקודת הקצה של הפיד.
    • ‫API_KEY: מפתח ה-API לאימות ב-Google SecOps.

  2. במקום מפתח הגישה, מציינים את המפתח הסודי שקיבלתם כשנוצר פיד Amazon Data Firehose.

הגדרת פיד webhook ב-HTTPS

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

  • מוודאים שמוגדר פרויקטGoogle Cloud ל-Google SecOps וש-Chronicle API מופעל בפרויקט.

  • קישור של מכונת Google SecOps אל Google Cloud שירותים.

כדי להגדיר פיד webhook של HTTPS:

  1. יוצרים פיד של תגובה לפעולה מאתר אחר (webhook) מסוג HTTPS ומעתיקים את כתובת ה-URL של נקודת הקצה ואת המפתח הסודי.
  2. יוצרים מפתח API שמוגדר עם כתובת ה-URL של נקודת הקצה. אפשר גם לעשות שימוש חוזר במפתח ה-API הקיים כדי לבצע אימות ל-Google SecOps.
  3. מציינים את כתובת ה-URL של נקודת הקצה באפליקציה.

שליחת כמה אירועים בבקשת webhook אחת

בדוגמת הקוד הבאה אפשר לראות איך מעצבים גוף של בקשה יחידה עם כמה אובייקטים של JSON שמופרדים באמצעות שורות חדשות אחרי הפריט curl --location:

--header 'Content-Type: application/json' \
--header 'X-goog-api-key: API_KEY' \
--header 'X-Webhook-Access-Key: SECRET' \
--data '{"principal": {"asset_id": "asset 123"}, "metadata": {"event_type": "GENERIC_EVENT", "product_name": "Product Acme"}}
{"principal": {"asset_id": "asset 123"}, "metadata": {"event_type": "GENERIC_EVENT", "product_name": "Product Acme"}}'

יצירת פיד של תגובה לפעולה מאתר אחר (webhook) ב-HTTPS

  1. בתפריט של Google SecOps, בוחרים באפשרות הגדרות ואז לוחצים על פידים.
  2. לוחצים על הוספת חדש.
  3. בשדה שם הפיד, מזינים שם לפיד.
  4. ברשימה סוג המקור, בוחרים באפשרות Webhook.
  5. בוחרים את סוג היומן. לדוגמה, כדי ליצור פיד עבור Open Cybersecurity Schema Framework (מסגרת סכימה פתוחה לאבטחת סייבר), בוחרים באפשרות Open Cybersecurity Schema Framework (OCSF) בתור סוג היומן.
  6. לוחצים על הבא.
  7. אופציונלי: מציינים ערכים לפרמטרים הבאים של הקלט:
    • תו מפריד לפיצול: התו המפריד שמשמש להפרדה בין שורות ביומן. אפשר להשתמש רק ב-\n.
    • מרחב השמות של הנכס: מרחב השמות של הנכס.
    • תוויות להוספה: התווית שתתווסף לאירועים מהפיד הזה.
  8. לוחצים על הבא.
  9. בודקים את ההגדרות של הפיד החדש במסך סיום ולוחצים על שליחה.
  10. לוחצים על יצירת מפתח סודי כדי ליצור מפתח סודי לאימות הפיד הזה.
  11. חשוב להעתיק ולשמור את המפתח הסודי כי לא תהיה לך אפשרות לראות אותו שוב. אפשר ליצור מחדש מפתח סודי חדש, אבל יצירה מחדש של המפתח הסודי מבטלת את המפתח הסודי הקודם.
  12. בכרטיסייה Details (פרטים), מעתיקים את כתובת ה-URL של נקודת הקצה של הפיד מהשדה Endpoint Information (פרטי נקודת הקצה). צריך לציין את כתובת ה-URL של נקודת הקצה הזו באפליקציית הלקוח.
  13. אופציונלי: לוחצים על המתג הפיד מופעל כדי להשבית את הפיד. הפיד מופעל כברירת מחדל.
  14. לוחצים על סיום.

יצירת מפתח API ל-Webhook Feed

  1. עוברים לדף Credentials במסוף Google Cloud .
  2. לוחצים על Create credentials ואז על API key.
  3. להגביל את הגישה של מפתח ה-API ל-Chronicle API.

מציינים את כתובת ה-URL של נקודת הקצה

  1. באפליקציית הלקוח, מציינים את נקודת הקצה מסוג HTTPS, שזמינה בפיד ה-webhook.

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

    X-goog-api-key = API_KEY

    X-Webhook-Access-Key = SECRET

    מומלץ לציין את מפתח ה-API ככותרת במקום לציין אותו בכתובת ה-URL. אם לקוח ה-webhook שלכם לא תומך בכותרות בהתאמה אישית, אתם יכולים לציין את מפתח ה-API ואת המפתח הסודי באמצעות פרמטרים של שאילתה בפורמט הבא:

      ENDPOINT_URL?key=API_KEY&secret=SECRET

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫ENDPOINT_URL: כתובת ה-URL של נקודת הקצה של הפיד.
    • ‫API_KEY: מפתח ה-API לאימות ב-Google SecOps.
    • ‫SECRET: המפתח הסודי שיצרתם כדי לאמת את הפיד.

הגדרת פיד API מותאם אישית

פידים של Google Security Operations Custom API (שנקראים גם Codeless Connectors) מאפשרים לכם להטמיע טלמטריה מ-REST APIs של צד שלישי באמצעות מודל גמיש שמבוסס על הגדרה. אתם יכולים להגדיר שליפות נתונים על ידי הגדרת נקודות קצה, אימות, אסטרטגיות חלוקה לעמודים וניהול מצב ישירות במסוף.

יתרונות מרכזיים

  • שילוב מהיר יותר: אפשר להוסיף מקורות טלמטריה חדשים תוך דקות באמצעות אשף מודרך, בלי לחכות לעדכוני קצה עורפי.
  • שמירת מצב בנקודות ביקורת: שמירת מצב בנקודות ביקורת מבטיחה שלא יהיו כפילויות בנתונים ושלא יהיו יומנים חסרים במחזורי הסקר.
  • Parent-child fan-out: תומך בתהליכי עבודה של גילוי בשתי רמות, כמו רישום משאבים ואחזור נתוני הטלמטריה המשויכים שלהם.
  • חוסן אוטומטי והגבלת קצב: מונעים הגבלת קצב על ידי הספק ומיצוי מכסת השימוש. כדי להבטיח קליטה מהימנה ללא הפרעות, פיד ה-API בהתאמה אישית מטפל אוטומטית בתגובות HTTP 429 באמצעות השהיה מעריכית לפני ניסיון חוזר (truncated exponential backoff), קובע את קצב הבקשות באמצעות הגבלת קצב שניתנת להגדרה, משהה את המשימות לסירוגין ומחיל אמצעי הגנה. מידע נוסף מופיע במאמר בנושא מגבלות על קצב הבקשות והגבלת רוחב פס.

דרישות מוקדמות

לפני שיוצרים פיד מותאם אישית של API, צריך לוודא שמתקיימות הדרישות המוקדמות הבאות:

  • הרשאות: כדי ליצור או לשנות פידים, צריך להיות לכם תפקיד אדמין של Chronicle API ‏ (roles/chronicle.admin) או תפקיד עורך של Chronicle API ‏ (roles/chronicle.editor).
  • דרישות ל-API של צד שלישי:
    • כתובת URL בסיסית תקינה של API (חובה להשתמש ב-https://).
    • פרטי כניסה ל-API (מפתח API, פרטי כניסה לאימות בסיסי או מזהה לקוח/סוד לקוח ב-OAuth 2.0).
    • מאמרי העזרה של ה-API של ספקים עם פרטים על נתיבי נקודות קצה, פרמטרים של בקשות, מבנים של תגובות JSON והגבלת קצב של יצירת בקשות.
  • גישה ל-Secret Manager: פרטי הכניסה מוצפנים ומנוהלים בצורה מאובטחת ב-Secret Manager. זהות השירות שמריצה את המחבר יוצרת אינטראקציה אוטומטית עם Secret Manager (roles/secretmanager.secretAccessor ו-roles/secretmanager.admin).

הגדרת פיד API מותאם אישית

כדי להגדיר פיד API בהתאמה אישית:

  1. עוברים אל SIEM Settings > Feeds.
  2. לוחצים על הוספת פיד חדש.
  3. לוחצים על הגדרת פיד יחיד.
  4. בשדה שם הפיד, מזינים שם תיאורי ייחודי (לדוגמה, 1Password-Audit-Events).
  5. ברשימה סוג המקור, בוחרים באפשרות Custom API (API בהתאמה אישית).
  6. ברשימה סוג היומן, בוחרים את סוג היומן של Google SecOps.
  7. לוחצים על הבא.

  8. בקטע הגדרות כלליות, קובעים את ההגדרות הבאות:

    • כתובת URL בסיסית: מזינים את המארח הראשי (לדוגמה, https://events.1password.com). כתובת ה-URL חייבת להתחיל ב-https://. אל תוסיפו נתיבי משנה או לוכסנים בסוף.

    • תדירות הבדיקה: מציינים את התדירות שבה הפלטפורמה בודקת את ה-API כדי לראות אם יש טלמטריה חדשה, בדקות. הטווח הנתמך: 5 עד 2,880 דקות (ברירת מחדל: 15 דקות). בפידים של Standard API (Sequential), הזמן המקובל הוא 10-15 דקות. בפידים של List & Detail (Parent-Child), מומלץ להגדיר 30-60 דקות כדי לאפשר ביצוע מלא של משימות ה-fan-out בלי חפיפה.

  9. בקטע אימות, בוחרים אחת משיטות האימות הנתמכות ומגדירים את השדות הנדרשים:

    • אימות בסיסי: מזינים את שם המשתמש (זהות חשבון ה-API) ואת הסוד (כלומר, הסיסמה או האסימון הסודיים).
    • פרטי כניסה של לקוח OAuth 2.0: אימות באמצעות תהליך הענקת פרטי כניסה של לקוח OAuth 2.0. ‫Google SecOps מבקש, שומר במטמון ומרענן באופן אוטומטי אסימוני גישה מסוג bearer לפני כל מחזור הטמעה. מזינים את נקודת הקצה של טוקן OAuth (לדוגמה, https://auth.vendor.com/oauth/token), את מזהה הלקוח ב-OAuth ואת סוד הלקוח ב-OAuth.
    • כותרות בקשה של מפתח API: אימות באמצעות מפתחות API בהתאמה אישית שמוזרקים לכותרות בקשה (התבנית הנפוצה ביותר של REST בארגונים). מזינים את שם הכותרת (לדוגמה, Authorization או X-API-Key) ואת ערך הכותרת (לדוגמה, Bearer <SECRET_TOKEN> או <SECRET_KEY>).
    • פרמטרים של שאילתות במפתח API: אימות באמצעות מפתחות API מותאמים אישית שמוזרקים לפרמטרים של שאילתות בכתובות URL. מזינים את שם הפרמטר של השאילתה (לדוגמה, api_key) ואת ערך הפרמטר (לדוגמה, <SECRET_KEY>).

  10. בוחרים את מודל המחבר שבו משתמש ה-API המותאם אישית:

    • ‫Standard API (Sequential): תהליך ליניארי של שליחת בקשות, שבו כל בקשה מתבססת ישירות על המצב של הבקשה הקודמת. במודל הזה, הסקר הבא משתמש בסמן, באסימון או בחותמת זמן שחולצו מהסקר הקודם כדי לאחזר רק נתונים חדשים. בוחרים בכרטיס הזה אם הספק מספק נקודת קצה שמחזירה ישירות רשומות של אירועי טלמטריה (לדוגמה, 1Password,‏ Okta,‏ SentinelOne,‏ GitHub או Slack).
    • רשימה ופרטים (פריט ראשי ופריט משני): תהליך גילוי בשתי רמות. הפיד מבצע קריאה ראשונית (parent) כדי לאחזר רשימה של משאבים או אובייקטים (לדוגמה, רשימה של מזהי משתמשים או אזורים). לאחר מכן, הפיד יוצר באופן אוטומטי קריאות המשך תלויות (צאצא) כדי לאחזר טלמטריה מפורטת לכל משאב בודד שזוהה. בוחרים בכרטיס הזה אם ה-API של הספק דורש תבנית גילוי דו-שכבתית: קודם שולחים קריאה לנקודת קצה כדי לאחזר רשימה דינמית של ישויות (לדוגמה, אזורים, חשבונות, פרויקטים, מכשירים), ואז מבצעים בקשות פרטים למעקב לכל ישות כדי לאחזר טלמטריה (לדוגמה, Cloudflare,‏ AWS CloudWatch או Tenable).

  11. אם בחרתם באפשרות Standard API (Sequential), מבצעים את הפעולות הבאות:

    1. בקטע נקודת קצה ל-API, מגדירים את הפרמטרים הבאים כדי להגדיר את המסלול הטכני ואת קצב השליחה של הבקשה:
      • נתיב נקודת הקצה: מסלול ה-API הספציפי שמצורף לכתובת הבסיס (לדוגמה, /api/v1/auditevents). הנתיב הזה מגדיר את משאב הטלמטריה המדויק שאליו מתבצעת השאילתה.
      • שיטת HTTP: בוחרים באפשרות GET כדי לאחזר נתונים באמצעות פרמטרים של שאילתת כתובת URL, או באפשרות POST כדי לשלוח מטען ייעודי לחיפוש או גוף של מסנן.
    2. גוף הבקשה: בבקשות מסוג POST, צריך לספק את מטען הנתונים בפורמט JSON. אפשר להטמיע משתנים דינמיים של נקודות ביקורת, כמו {"limit": 100, "start_time": "{{.last_timestamp}}"}.
    3. מספר בקשות מקסימלי לדקה: מזינים את המספר המקסימלי של בקשות לשליחה לדקה. זוהי הגבלה של קצב יצירת הבקשות בצד הלקוח, כדי לעמוד במגבלות של קצב יצירת הבקשות של ספקי API (ברירת מחדל: 5 בקשות לדקה = בקשה אחת כל 12 שניות). ההגדרה הזו מונעת חריגה מהמכסה במהלך חלוקה לעמודים של כמה דפים.
    4. אופציונלי: בקטע Custom headers (כותרות בהתאמה אישית), מגדירים את Header name (שם הכותרת) ואת Value (הערך), ואז לוחצים על Add (הוספה) כדי להגדיר כותרות HTTP מיוחדות שנדרשות על ידי ה-API של היעד (לדוגמה, Content-Type: application/json, Accept: application/json).
    5. אופציונלי: בקטע פרמטרים של שאילתות, מגדירים את המפתח ואת הערך, ואז לוחצים על הוספה כדי לציין מסננים או אפשרויות נוספים שמצורפים למחרוזת השאילתה של כתובת ה-URL (לדוגמה, count=1000, status=active) או לקשור משתני תבנית דינמיים (לדוגמה, start={{.last_run_time}}).
    6. בקטע אסטרטגיית חלוקה לדפים: בוחרים את מנגנון החלוקה לדפים שנדרש ל-API של הצד השלישי כדי לטפל במערכי תוצאות מרובי דפים, ואז מגדירים את השדות הנדרשים:
      • ללא: אחזור נתונים בבקשה יחידה ללא חלוקה לדפים.
      • עימוד באמצעות אסימונים: שימוש באסימונים (מפתחות בהתאמה אישית) כדי להגיע לדף הבא. מזינים את נתיב ה-JSON של אסימון הדף הבא (לדוגמה, meta.next_cursor) ואת שם פרמטר השאילתה של חלוקת האסימון לדפים (לדוגמה, cursor).
      • קישור לדפים הבאים: כדי לקבל נתונים נוספים, צריך לעקוב אחרי כתובות ה-URL שמופיעות בתשובה. מזינים את נתיב ה-JSON של הקישור לדף הבא (לדוגמה, links.next או @odata.nextLink).
      • החלוקה לדפים עם היסט: דילוג על מספר מסוים של רשומות כדי לקבל את הקבוצה הבאה. מזינים את שם הפרמטר של השאילתה של ההיסט (לדוגמה, offset).
      • מספור דפים: מעבר למספר הדף הבא ברצף. מזינים את שם הפרמטר של השאילתה של מספר הדף (לדוגמה, page).

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

      • שיטה: בוחרים אחת מהשיטות הבאות ומגדירים את השדות הנדרשים:
        • ללא: אחזור של כל הנתונים הזמינים בלי מעקב אחר ההתקדמות לאורך המחזורים.
        • חותמת הזמן האחרונה: מעקב אחרי חותמת הזמן של הרשומה החדשה ביותר. מזינים את נתיב ה-JSON של ערך נקודת הבדיקה (לדוגמה, timestamp או event_time) ואת משתנה נקודת הבדיקה (לדוגמה, last_run_time, שמופיע בהמשך הסקרים כ-{{.last_run_time}}).
        • הרישום האחרון: מעקב אחרי מזהה הרשומה הגבוה ביותר כדי לאחזר רק רשומות חדשות. מזינים את נתיב ה-JSON של ערך נקודת הבדיקה (לדוגמה, id או event_id) ואת משתנה נקודת הבדיקה (לדוגמה, last_id, שמופיע כ-{{.last_id}}).
        • אסימון איטרטור: משתמשים באסימוני המשך מתמשכים שמסופקים על ידי ה-API. מזינים את נתיב ה-JSON של ערך נקודת הבדיקה ואת משתנה נקודת הבדיקה (לדוגמה, iterator_token, שמופיע כ-{{.iterator_token}}).

    8. בקטע Response Mapping (מיפוי תגובות), מציינים כללים שמסבירים לפלטפורמה איך לאתר ולחלץ יומנים:

      • נתיב JSON של נתוני היעד: מזינים את הנתיב המדויק במטען הייעודי לתגובת ה-API שבו נמצאת רשימת רשומות היומן של היעד. למערכים שעטופים באובייקט (לדוגמה, {"items": [...]}), מזינים items. אם ממשקי ה-API מחזירים ישירות מערך JSON ברמת הבסיס (לדוגמה, [{...}, {...}]), משאירים את השדה הזה ריק לגמרי ([]).

  12. אם בחרתם באפשרות רשימה ופרטים (הורה-צאצא), צריך לפעול באופן הבא:

    1. בקשת הורה (Discovery): מגדירים את נקודת הקצה שמחזירה רשימה של פריטים:
      1. בקטע נקודת קצה ל-API, מגדירים את הפרמטרים הבאים כדי להגדיר את המסלול הטכני ואת קצב השליחה של הבקשה:
        • נתיב נקודת הקצה: נתיב ה-API הספציפי שמצורף לכתובת ה-URL הבסיסית (לדוגמה, /api/v1/auditevents). הנתיב הזה מגדיר את משאב הטלמטריה המדויק שאליו מתבצעת השאילתה.
        • שיטת HTTP: בוחרים באפשרות GET כדי לאחזר נתונים באמצעות פרמטרים של שאילתת כתובת URL, או באפשרות POST כדי לשלוח מטען ייעודי לחיפוש או גוף של מסנן.
        • גוף הבקשה: בבקשות מסוג POST, צריך לספק את מטען הנתונים בפורמט JSON. אפשר להטמיע משתנים דינמיים של נקודות ביקורת, כמו {"limit": 100, "start_time": "{{.last_timestamp}}"}.
      2. מספר בקשות מקסימלי לדקה: מזינים את המספר המקסימלי של בקשות לשליחה לדקה. זוהי הגבלה של קצב יצירת הבקשות בצד הלקוח, כדי לעמוד במגבלות של קצב יצירת הבקשות של ספקי API (ברירת מחדל: 5 בקשות לדקה = בקשה אחת כל 12 שניות). ההגדרה הזו מונעת חריגה מהמכסה במהלך חלוקה לעמודים של כמה דפים.
      3. אופציונלי: בקטע Custom headers (כותרות בהתאמה אישית), מגדירים את Header name (שם הכותרת) ואת Value (הערך), ואז לוחצים על Add (הוספה) כדי להגדיר כותרות HTTP מיוחדות שנדרשות על ידי ה-API של היעד (לדוגמה, Content-Type: application/json, Accept: application/json).
      4. אופציונלי: בקטע פרמטרים של שאילתות, מגדירים את המפתח ואת הערך, ואז לוחצים על הוספה כדי לציין מסננים או אפשרויות נוספים שמצורפים למחרוזת השאילתה של כתובת ה-URL (לדוגמה, count=1000, status=active) או לקשור משתני תבנית דינמיים (לדוגמה, start={{.last_run_time}}).
      5. בקטע אסטרטגיית חלוקה לדפים: בוחרים את מנגנון החלוקה לדפים שנדרש ל-API של הצד השלישי כדי לטפל במערכי תוצאות מרובי דפים, ואז מגדירים את השדות הנדרשים:
        • ללא: אחזור נתונים בבקשה יחידה ללא חלוקה לדפים.
        • עימוד באמצעות אסימונים: שימוש באסימונים (מפתחות בהתאמה אישית) כדי להגיע לדף הבא. מזינים את נתיב ה-JSON של אסימון הדף הבא (לדוגמה, meta.next_cursor) ואת שם פרמטר השאילתה של חלוקת האסימון לדפים (לדוגמה, cursor).
        • קישור לדפים הבאים: כדי לקבל נתונים נוספים, צריך לעקוב אחרי כתובות ה-URL שמופיעות בתשובה. מזינים את נתיב ה-JSON של הקישור לדף הבא (לדוגמה, links.next או @odata.nextLink).
        • החלוקה לדפים עם היסט: דילוג על מספר מסוים של רשומות כדי לקבל את הקבוצה הבאה. מזינים את שם הפרמטר של השאילתה של ההיסט (לדוגמה, offset).
        • מספור דפים: מעבר למספר הדף הבא ברצף. מזינים את שם הפרמטר של השאילתה של מספר הדף (לדוגמה, page).
      6. בקטע Checkpointing, מגדירים את ההגדרות שמאפשרות למחבר לזכור איפה הוא הפסיק בין מחזורי סקר חוזרים:
        • שיטה: בוחרים אחת מהשיטות הבאות ומגדירים את השדות הנדרשים:
          • ללא: אחזור של כל הנתונים הזמינים בלי מעקב אחר ההתקדמות לאורך המחזורים.
          • חותמת הזמן האחרונה: מעקב אחרי חותמת הזמן של הרשומה החדשה ביותר. מזינים את נתיב ה-JSON של ערך נקודת הבדיקה (לדוגמה, timestamp או event_time) ואת משתנה נקודת הבדיקה (לדוגמה, last_run_time, שמופיע בהמשך הסקרים כ-{{.last_run_time}}).
          • הרישום האחרון: מעקב אחרי מזהה הרשומה הגבוה ביותר כדי לאחזר רק רשומות חדשות. מזינים את נתיב ה-JSON של ערך נקודת הבדיקה (לדוגמה, id או event_id) ואת משתנה נקודת הבדיקה (לדוגמה, last_id, שמופיע כ-{{.last_id}}).
          • אסימון איטרטור: משתמשים באסימוני המשך מתמשכים שמסופקים על ידי ה-API. מזינים את נתיב ה-JSON של ערך נקודת הבדיקה ואת משתנה נקודת הבדיקה (לדוגמה, iterator_token, שמופיע כ-{{.iterator_token}}).
    2. חילוץ נתונים (הגשר): מגדירים את הפרטים הבאים:
      • נתיב JSON של מזהה הפריט: השדה הספציפי בתגובת ההורה שמזהה באופן ייחודי ישות נפרדת (לדוגמה, id או zone_id). המחבר מחלץ את המזהה הזה מכל פריט במערך ההורה.
      • שם משתנה בתבנית: מציינים שם משתנה מותאם אישית שיכיל את המזהה שחולץ (לדוגמה, zone_id). בממשק המשתמש מוצג תג דינמי: Use {{.zone_id}} in your child request below (צריך להשתמש ב-{{.zone_id}} בבקשת הצאצא שבהמשך).
    3. בקשת צאצא (פרטים): מגדירים את נקודת הקצה שמחזירה יומנים מפורטים לכל פריט:
      1. בקטע נקודת קצה ל-API, מגדירים את הפרמטרים הבאים כדי להגדיר את המסלול הטכני ואת קצב השליחה של הבקשה:
        • נתיב נקודת הקצה: נתיב ה-API הספציפי שמצורף לכתובת ה-URL הבסיסית (לדוגמה, /client/v4/zones/{{.zone_id}}/logs/received). הנתיב הזה מגדיר את משאב הטלמטריה המדויק שאליו מתבצעת השאילתה.
        • שיטת HTTP: בוחרים באפשרות GET כדי לאחזר נתונים באמצעות פרמטרים של שאילתת כתובת URL, או באפשרות POST כדי לשלוח מטען ייעודי לחיפוש או גוף של מסנן.
        • גוף הבקשה: בבקשות מסוג POST, צריך לספק את מטען הנתונים בפורמט JSON. אפשר להטמיע משתנים דינמיים של נקודות ביקורת, כמו {"limit": 100, "start_time": "{{.last_timestamp}}"}.
      2. מספר בקשות מקסימלי לדקה: מזינים את המספר המקסימלי של בקשות לשליחה לדקה. זוהי הגבלה של קצב יצירת הבקשות בצד הלקוח, כדי לעמוד במגבלות של קצב יצירת הבקשות של ספקי API (ברירת מחדל: 5 בקשות לדקה = בקשה אחת כל 12 שניות). ההגדרה הזו מונעת חריגה מהמכסה במהלך חלוקה לעמודים של כמה דפים.
      3. אופציונלי: בקטע Custom headers (כותרות בהתאמה אישית), מגדירים את Header name (שם הכותרת) ואת Value (הערך), ואז לוחצים על Add (הוספה) כדי להגדיר כותרות HTTP מיוחדות שנדרשות על ידי ה-API של היעד (לדוגמה, Content-Type: application/json, Accept: application/json).
      4. אופציונלי: בקטע פרמטרים של שאילתות, מגדירים את המפתח ואת הערך, ואז לוחצים על הוספה כדי לציין מסננים או אפשרויות נוספים שמצורפים למחרוזת השאילתה של כתובת ה-URL (לדוגמה, count=1000, status=active) או לקשור משתני תבנית דינמיים (לדוגמה, start={{.last_run_time}}).
      5. בקטע אסטרטגיית חלוקה לדפים: בוחרים את מנגנון החלוקה לדפים שנדרש ל-API של הצד השלישי כדי לטפל במערכי תוצאות מרובי דפים, ואז מגדירים את השדות הנדרשים:
        • ללא: אחזור נתונים בבקשה יחידה ללא חלוקה לדפים.
        • עימוד באמצעות אסימונים: שימוש באסימונים (מפתחות בהתאמה אישית) כדי להגיע לדף הבא. מזינים את נתיב ה-JSON של אסימון הדף הבא (לדוגמה, meta.next_cursor) ואת שם פרמטר השאילתה של חלוקת האסימון לדפים (לדוגמה, cursor).
        • קישור לדפים הבאים: כדי לקבל נתונים נוספים, צריך לעקוב אחרי כתובות ה-URL שמופיעות בתשובה. מזינים את נתיב ה-JSON של הקישור לדף הבא (לדוגמה, links.next או @odata.nextLink).
        • החלוקה לדפים עם היסט: דילוג על מספר מסוים של רשומות כדי לקבל את הקבוצה הבאה. מזינים את שם הפרמטר של השאילתה של ההיסט (לדוגמה, offset).
        • מספור דפים: מעבר למספר הדף הבא ברצף. מזינים את שם הפרמטר של השאילתה של מספר הדף (לדוגמה, page).
      6. בקטע Checkpointing, מגדירים את ההגדרות שמאפשרות למחבר לזכור איפה הוא הפסיק בין מחזורי סקר חוזרים:
        • שיטה: בוחרים אחת מהשיטות הבאות ומגדירים את השדות הנדרשים:
          • ללא: אחזור של כל הנתונים הזמינים בלי מעקב אחר ההתקדמות לאורך המחזורים.
          • חותמת הזמן האחרונה: מעקב אחרי חותמת הזמן של הרשומה החדשה ביותר. מזינים את נתיב ה-JSON של ערך נקודת הבדיקה (לדוגמה, timestamp או event_time) ואת משתנה נקודת הבדיקה (לדוגמה, last_run_time, שמופיע בהמשך הסקרים כ-{{.last_run_time}}).

  13. מגדירים את ההגדרות הבאות בקטע תזמון ותוויות:

    • תדירות הבדיקה: בוחרים מרווח זמן סטנדרטי (לדוגמה, 5m, 1h).
    • מרחב שמות: תג ארגוני אופציונלי.
    • ‫Ingestion Labels: צמדי מפתח/ערך ל-Data RBAC.

  14. לוחצים על שליחה. ‫Google SecOps מבצעת בדיקה אוטומטית של אימות פרטי הכניסה ונקודות הקצה. אם האימות מצליח, מתחיל תהליך של שליחת בקשות לשרת כדי לבדוק אם יש עדכונים בפיד.

הגדרה לדוגמה 1: אירועים ביומן הביקורות של 1Password (מודל API רגיל (סדרתי))

ההגדרה הבאה בפורמט JSON היא דוגמה למודל של Standard API (Sequential), עם יצירת נקודות עצירה מבוססות-סמן עבור 1Password:

{
  "base_url": "https://events.1password.com",
  "polling_frequency": 15,
  "header_auth": {
    "header_key_values": [
      {
        "key": "Authorization",
        "value": "Bearer <SECRET_STORED_IN_SECRET_MANAGER>"
      }
    ]
  },
  "primary_request": {
    "request_settings": {
      "endpoint_path": "/api/v1/auditevents",
      "http_method": "POST",
      
      "request_body": "{\"limit\": 1000, \"start_time\": \"{{.last_run_time}}\"}",
      
      "custom_headers": [
        {
          "key": "Content-Type",
          "value": "application/json"
        }
      ],
      "max_requests_per_minute": 5
    },
    "pagination_strategy": {
      "token": {
        "next_page_token_json_path": "additional_items_url",
        "query_param": "cursor"
      }
    },
    "checkpointing": {
      "latest_timestamp_strategy": {
        "checkpoint_value_path": "timestamp",
        "checkpoint_variable": "last_run_time"
      }
    },
    "response_mapping": {
      "target_data_path": ["items"]
    }
  }
}

דוגמה קונקרטית להגדרה 2: טלמטריה של אזור Cloudflare (מודל רשימה ופרטים (הורה-צאצא))

ההגדרה הבאה בפורמט JSON מציגה מודל של רשימה ופרטים (הורה-צאצא) fan-out עבור Cloudflare:

{
 "base_url": "https://api.cloudflare.com",
 "polling_frequency": 30,
 "header_auth": {
   "header_key_values": [
     {
       "key": "Authorization",
       "value": "Bearer <SECRET_STORED_IN_SECRET_MANAGER>"
     }
   ]
 },

 "primary_request": {
   "request_settings": {
     "endpoint_path": "/client/v4/zones",
     "http_method": "GET"
   },
   "response_mapping": {
     "target_data_path": ["result"]
   },
   "pagination_strategy": {
     "none": {}
   },
   "checkpointing": {
     "none_strategy": {}
   },
   "dependent_requests_config": {
     "item_id_json_path": "id",
     "item_id_variable": "zone_id",
     "dependent_requests": [
       {
         "request_settings": {
           "endpoint_path": "/client/v4/zones/{{.zone_id}}/logs/received",
           "http_method": "GET",
           "query_parameters": [
             {
               "key": "start",
               "value": "{{.last_run_time}}"
             },
             {
               "key": "count",
               "value": "1000"
             }
           ],
           "max_requests_per_minute": 5
         },

         "pagination_strategy": {
           "none": {}
         },
         "checkpointing": {
           "latest_timestamp_strategy": {
             "checkpoint_value_path": "EdgeStartTimestamp",
             "checkpoint_variable": "last_run_time"
           }
         },
         "response_mapping": {
           "target_data_path": []
         }
       }
     ]
   }
 }
}

שיטות מומלצות לשימוש ב-Custom API

  • הנחיות לגבי תדירות השליחה של בקשות:
    • מתחילים עם מרווחי זמן מתונים בין בדיקות: מגדירים את מרווח הזמן הראשוני בין בדיקות ל-15 דקות או ל-30 דקות עבור נקודות קצה עם נפח גבוה, כדי לבחון את התנהגות המכסה של ספק ה-API לפני שמקצרים את מרווח הזמן ל-5 דקות.
    • אופטימיזציה ל-fan-out בנפח גבוה: בפידים מסוג Parent-Child (List & Detail) שבהם מתגלים עשרות או מאות משאבים, מומלץ מאוד להגדיר את תדירות הדגימה ל-30 עד 60 דקות כדי לאפשר לכל משימות הצאצא להסתיים בצורה חלקה לפני שמתחיל מחזור הגילוי הבא.
  • אימות נתיבי ההטמעה: לפני שמגדירים את נקודות הבדיקה של המצב, צריך להשתמש בתיעוד של הספק או בכלי בדיקה של API כדי לוודא מהו שם השדה המדויק ב-JSON של חותמות הזמן.
  • פירוק של ממשקי API עם כמה צאצאים: אם API של צד שלישי דורש אחזור של התראות ויומני ביקורת עבור רשימת משתמשים אחת, צריך ליצור שני פידים נפרדים עם צאצא יחיד (אחד להתראות ואחד ליומני ביקורת) כדי לשמור על בידוד אופטימלי.

אמצעי הגנה להגבלת קצב של יצירת בקשות או ויסות של נתוני בקשות

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

  • הגדרת קצב בקשות (הגבלת קצב): בקשות HTTP יוצאות מוגבלות אוטומטית כדי למנוע חריגה ממגבלות הקצב של הספק. קצב ההצגה שמוגדר כברירת מחדל הוא 5 בקשות לדקה (בקשה אחת כל 12 שניות). אפשר לשנות את ההגדרה הזו לכל נקודת קצה באמצעות השדה בקשות מקסימליות לדקה בהגדרות של נקודת הקצה, כדי להתאים למכסות ה-API שפורסמו על ידי הספק.
  • מגבלת בקשות של צאצאים: בפידים מסוג הורה-צאצא (רשימה ופרטים), בקשת גילוי יכולה לשלוח עד 500 בקשות צאצאים לכל מחזור בדיקה.
  • עומק של פיצול לרוחב ברמה אחת: המחבר אוכף באופן קפדני עומק מקסימלי של פיצול לרוחב ברמה אחת (גילוי של חשבון הורה ← פרטים של חשבון צאצא). אין תמיכה בבקשות תלויות מקוננות (קריאות לנכד).
  • גודל מטען ייעודי (payload) מקסימלי לתגובה: הגודל המקסימלי של תגובת HTTP לכל בקשה או דף הוא 50 MB. אם API שלא מחולק לדפים מחזיר תגובה שגודלה עולה על 50 MB, האחזור ייכשל עם שגיאה של מיצוי משאבים. כדי למנוע את זה, תמיד צריך להגדיר פרמטרים של שאילתות חלוקה לדפים (כמו limit או page_size) כדי לאחזר רשומות בקבוצות קטנות יותר.
  • השהיה אוטומטית של HTTP 429: אם API של ספק חיצוני מגיב עם HTTP 429 (יותר מדי בקשות), Google SecOps מתעד באופן אוטומטי את הסטטוס ומתחיל תקופת השהיה אקספוננציאלית, ומשהה את ביצוע המשימה עד שהמכסה של הספק מתחדשת.

הגבלות מותאמות אישית על ממשקי API

כשמתכננים את נתיבי ההטמעה, חשוב לזכור שלסוג הפיד Custom API יש את המגבלות הבאות:

  • תמיכה ב-JSON בלבד: נתמכות רק תגובות של API בפורמט JSON. אין תמיכה בפורמטים אחרים כמו XML,‏ CSV,‏ Parquet ו-Avro.
  • אין חתימה דינמית על בקשות: אין תמיכה בממשקי API שנדרשות בהם חתימות קריפטוגרפיות דינמיות לכל בקשה (לדוגמה, AWS SigV4,‏ Akamai או Oracle OCI).
  • אין תמיכה באימות רב-שלבי: לא ניתן להשתמש בממשקי API שדורשים קריאה ראשונית של התחברות באמצעות תוכנה כדי להחליף את פרטי הכניסה בטוקן סשן זמני (כמו Saviynt) לפני שליחת בקשות.
  • אין WebSockets או קליטת נתונים מסוג Push: פידים של API מותאם אישית תומכים בסקר משיכה רגיל של HTTPS. אין תמיכה בחיבורי סטרימינג קבועים (WebSockets) וב-Webhooks נכנסים.
  • ללא TLS בו-זמני (mTLS): האימות חייב להתבסס על מפתחות API, אימות בסיסי או פרטי כניסה סטנדרטיים של לקוח OAuth 2.0. אין תמיכה בלחיצות ידיים של אישורים מצד הלקוח.

פתרון בעיות בפידים מותאמים אישית ב-API

כדי לחקור שגיאות בפידים של Custom API ב-Logs Explorer ב-Cloud Logging, משתמשים בשאילתות הבאות:

resource.type="gce_instance" OR resource.type="generic_task"
jsonPayload.service="gopher"
jsonPayload.feed_id="FEED_ID"

מחליפים את FEED_ID במזהה העדכון.

כדי לסנן במיוחד בקשות HTTP שנכשלו, משתמשים בשאילתה הבאה:

jsonPayload.service="gopher"
jsonPayload.feed_id="FEED_ID"
jsonPayload.http_status_code >= 400

מחליפים את FEED_ID במזהה העדכון.

פתרון בעיות נפוצות

תיאור הבעיה / השגיאה שורש הבעיה פתרון
‫HTTP 401 Unauthorized / HTTP 403 Forbidden מפתח ה-API, הסיסמה או פרטי הכניסה ל-OAuth לא תקינים או שתוקף שלהם פג. עורכים את הפיד, מזינים מחדש פרטי כניסה תקינים ולוחצים על שליחה.
שגיאת HTTP 404 תבנית שגויה של כתובת URL בסיסית או של נתיב נקודת קצה. בודקים את נקודת הקצה במאמרי העזרה של ה-API של הספק. חשוב לוודא שכתובת הבסיס מסתיימת בצורה תקינה ושנתיב נקודת הקצה מתחיל ב-/.
HTTP 429 Too Many Requests הייתה חריגה מהגבלות הקצב של יצירת בקשות ל-API של הספק. להגדיל את תדירות הבדיקה או להקטין את הפרמטר limit בפרמטרים של השאילתה.
שגיאה בחילוץ JSON (הנתיב items_path ריק) חוסר התאמה בנתיב ההגדרה של התגובה. בודקים את מבנה המטען הייעודי (payload) של תגובת ה-API ומעדכנים את נתיב ה-JSON של נתוני היעד.
הטמעת נתונים כפולים חותמת הזמן של הגדרת המצב או הנתיב של כלי לחילוץ מזהים לא תקינים. בודקים את שם השדה של רשומת היומן לחותמת זמן ומעדכנים את נתיב המחלץ.

ניהול פידים

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

בדף פידים יש כמה כלים שיעזרו לכם להתמצא ברשימת הפידים שהגדרתם ולארגן אותה:

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

  • מסנן: לוחצים על סמל המסנן כדי לצמצם את הרשימה לפי מאפייני פיד ספציפיים.

  • הורדת קובץ CSV: לוחצים על הורדה כקובץ CSV כדי לייצא את רשימת הפידים הנוכחית לקובץ CSV.

  • עימוד: אפשר להשתמש בפקדי העימוד כדי:

    • משנים את מספר השורות בכל דף.

    • כדי לעבור בין הדפים של הפידים, משתמשים בכרטיסיות של הדפים ובחיצים.

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

צפייה בפידים שהוגדרו

בדף פידים מוצגים כל הפידים שהגדרתם.

  1. עוברים אל SIEM Settings > Feeds (הגדרות SIEM > פידים). בדף הראשי מוצגים כל הפידים שהגדרתם.
  2. מעבירים את הסמן מעל כל שורה כדי להציג את התפריט more_vert אפשרויות נוספות.
  3. בתפריט, אפשר לראות את פרטי הפיד, לערוך, להשבית או למחוק את הפיד.

מעקב אחר סטטוס הפיד

אפשר לעקוב אחרי הסטטוס של הפיד בדף פידים הראשוני, שבו הפידים יכולים לקבל את הסטטוסים הבאים:

  • פעיל: הפיד מוגדר ומוכן להעברת נתונים לחשבון Google SecOps.
  • InProgress: מערכת Google SecOps מנסה לשלוף נתונים מהצד השלישי שהוגדר.
  • הושלם: הפיד הזה אחזר את הנתונים בהצלחה.
  • הועבר לארכיון: הפיד מושבת.

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

עריכה של פידים קיימים

בדף פידים אפשר לערוך פיד קיים באופן הבא:

  1. מציבים את הסמן מעל פיד קיים ולוחצים על more_vert בעמודה השמאלית.

  2. לוחצים על עריכת הפיד. עכשיו אפשר לשנות את פרמטרי הקלט של הפיד ולשלוח אותו מחדש ל-Google SecOps, שינסה להשתמש בפיד המעודכן.

הפעלה (המשך) והשבתה (השהיה) של פידים

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

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

בדף פידים אפשר להפעיל (להמשיך) או להשבית (להשהות) כל אחד מהפידים הקיימים:

  1. מציבים את הסמן מעל פיד קיים ולוחצים על more_vert בעמודה השמאלית.

  2. אופציונלי: לוחצים על המתג הפיד מופעל כדי להפעיל את הפיד.

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

שחזור נתונים כשמפעילים מחדש פידים (אפשרות למילוי חוסרים)

היכולת של Google SecOps למלא נתונים חסרים תלויה בסוג הפיד שלכם: פיד מבוסס-משיכה (נתמך) או פיד מבוסס-דחיפה (לא אפשרי).

פידים מבוססי-משיכה

באמצעות הפידים האלה, Google SecOps שולף נתונים ממקורות חיצוניים. פידים מסוג Pull כוללים:

  • קטגוריות של אחסון בענן, כמו Amazon S3,‏ Google Cloud Storage, ‏ Azure Blob Storage
  • שרתי SFTP

  • ממשקי API של צד שלישי, כמו Microsoft 365,‏ Okta ו-Proofpoint

    כשמפעילים מחדש פידים מבוססי-משיכה, Google SecOps יכול לאחזר נתונים שנוצרו בזמן שהפיד היה מושבת.

פידים מבוססי-דחיפה

באמצעות הפידים האלה, מערכות חיצוניות 'דוחפות' נתונים אל Google SecOps. פידים מסוג Push כוללים:

  • תגובות לפעולה מאתר אחר (webhook) ב-HTTPS
  • Google Cloud Pub/Sub
  • Amazon Kinesis Data Firehose
  • העברה ישירה של נתונים באמצעות API או סוכן, כמו Bindplane

‫Google SecOps לא יכולה להפעיל באופן אוטומטי השלמת חוסר בנתונים מפידים מבוססי-דחיפה. בזמן שהפיד מושבת והמערכת שלכם דוחפת נתונים, Google SecOps שולח שגיאה מסוג HTTP 403 Forbidden או שגיאה כללית מסוג 4xx.

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

שיקולים לגבי מילוי חוסרים (backfill)

  • מגבלות של מערכת המקור: כמות הנתונים ההיסטוריים ש-Google SecOps יכולה למלא מפידים מבוססי-משיכה מוגבלת על ידי משך הזמן שבו מערכת המקור שומרת את הנתונים ומה ש-API שלה מאפשר. לדוגמה, חלק מממשקי ה-API מספקים גישה רק לנתונים מ-7 הימים האחרונים.
  • מאגר זמני של Google SecOps: כדי לאפשר שחזור אוטומטי, המאגר הזמני הפנימי של Google SecOps להזנות מבוססות-משיכה מחזיק נתונים למשך עד 90 ימים, ולאחר מכן הנתונים נמחקים.
  • הגבלות על דיירים: יכול להיות שיהיו הגבלות על מילוי חוסרים בנתונים ישנים יותר בדיירים שלא משלמים, כמו הוכחות קונספט.
  • מכסות של הכנסת נתונים: כדי לא להשפיע על הכנסת נתונים בזמן אמת, נתוני מילוי חוזר מעובדים בעדיפות נמוכה יותר מנתונים בזמן אמת. גם השלמת חוסר בנתונים (data backfill) מבוססת-משיכה מוגבלת בקצב, בדרך כלל לשליש (33%) ממגבלת ההעברה המהירה של הדייר (tenant) לכל סוג יומן. כך אפשר לוודא שפידים קריטיים מבוססי-דחיפה, כמו סוכני EDR, לא יושפעו לרעה.
  • הגבלת קצב דינמית: אם המילוי החוזר צורך את כל מכסת המשיכה הזמינה, ההטמעה מושהית למשך שארית מרווח חמש הדקות, ומתחדשת באופן אוטומטי כשהמרווח מתחיל מחדש.
  • אחסון בענן: אפשר להשתמש בהגדרות הפיד כדי לשלוט במילוי החסר, למשל מסננים לקבצים חדשים או מעודכנים, או מסננים של טווח תאריכים, כמו 'הגיל המקסימלי של הקובץ'.
  • מצבור גדול של נתונים שלא נשלחו: אם מצבור גדול של נתונים שלא נשלחו מפיד מבוסס-משיכה גורם לבעיות אחרי הפעלה מחדש, אפשר לפנות לתמיכה של Google כדי לנקות את המצבור. המשמעות היא שהפיד יתחיל להזין רק נתונים חדשים מעכשיו והלאה, והנתונים שהוחמצו לא יתווספו בדיעבד.
  • עריכת פידים מושבתים: כל שינוי בהגדרות של פיד מושבת יחול ברגע שהפיד יופעל מחדש.

מחיקת פידים

בדף פידים אפשר גם למחוק פיד קיים:

  1. מציבים את הסמן מעל פיד קיים ולוחצים על more_vert בעמודה השמאלית.

  2. לוחצים על מחיקת פיד. נפתח החלון DELETE FEED (מחיקת פיד). כדי למחוק את הפיד באופן סופי, לוחצים על כן, למחוק.

בפידים של API בהתאמה אישית, מופיעה תיבת דו-שיח עם תיבת סימון אופציונלית: מחיקת נתונים ממתינים בפיגור:

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

שליטה בקצב ההטמעה

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

כדי לבקש להגדיל את מגבלת הקצב, אפשר לפנות אל Cloud Customer Care.

פתרון בעיות בפידים שההעלאה שלהם נכשלה

בדף פידים, אפשר לראות פרטים כמו סוג המקור, סוג היומן, מזהה הפיד והסטטוס של הפידים הקיימים, באופן הבא:

  1. מציבים את הסמן מעל פיד קיים ולוחצים על more_vert בעמודה השמאלית.

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

אם הפיד נכשל, הפרטים כוללים את סיבת השגיאה ושלבים לתיקון שלה.

בטבלה שגיאות במקור ובקליטה מפורטות הודעות שגיאה שאולי יופיעו כשעובדים עם פידים של נתונים.

כדי לנתח את הפעילות בפיד ולפתור בעיות, אפשר לעיין ביומנים ב-Cloud Logging. אפשר לעיין במאמר בנושא ניתוח פעילות הפיד באמצעות Cloud Logging.

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