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

נתמך ב:

Google secops SIEM

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

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

לפני שמגדירים פיד נתונים ב-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
פריסת קבצים	לא ZIP	פחות מ-5GB	משתנה בהתאם למספר הקבצים	‫10GB (לא דחוס)
פריסת קבצים	מיקוד	-	משתנה בהתאם למספר הקבצים	‫4GB (לא דחוס)

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

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

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

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

ההשפעה של שינוי פרויקט 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 (פרימיום)

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

הגדרה של רשימת היתרים לכתובות IP

כש-Google SecOps שולף נתונים מ-S3, מ-SQS, מ-Azure ומממשקי API של צד שלישי, התשתית של Google מתחברת יוצאת למאגר של הלקוח או לממשק ה-API של הצד השלישי.

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

• פידים בגרסה 2 (S3_V2, ‏ SQS_V2, ‏ Azure_Blobstore_V2): הפידים האלה משתמשים רק ב- Google Cloud Storage Transfer Service‏ (STS) כדי לשלוף נתונים מאחסון של לקוחות. צריך להוסיף לרשימת ההיתרים את טווחי כתובות ה-IP של STS: ‏ ipranges.json.
• ממשקי API של צד שלישי: נדרש goog.json.
• פידים מדור קודם (S3, ‏ Azure_Blobstore): נדרשים טווחי כתובות IP ייעודיים. לקבלת מידע נוסף, אפשר לפנות לתמיכה של Google SecOps.
• ‫Azure Event Hub: נדרשים טווחי כתובות IP ספציפיים לאזור. מידע נוסף זמין במאמר הגדרת אבטחת רשת (אופציונלי) במאמר יצירת פיד של Azure Event Hub.

הערה: Google SecOps לא יכולה להבטיח שכל הפידים יגיעו באופן בלעדי מכתובות IP בהתאם לאזור שצוין.

מכיוון שטווחי כתובות ה-IP של שירותי Google משתנים באופן דינמי, Google ממליצה להגדיר את חומת האש כך שתאחזר ותנתח את הפידים באופן הבא:

• פידים בגרסה 2 (S3_V2, ‏ SQS_V2, ‏ Azure_Blobstore_V2): העברת הנתונים מתבצעת באופן בלעדי על ידי עובדים של Storage Transfer Service. צריך רק לאחזר ולנתח את הקובץ ipranges.json מדי פעם.
• פידים מדור קודם (S3, ‏ SQS, ‏ Azure_Blobstore, ‏ Azure Event Hub) וממשקי API של צד שלישי: החיבורים האלה נוצרים מהתשתית של Google. אתם צריכים רק לאחזר ולנתח את הקבצים goog.json ו-cloud.json מדי פעם.

הגדרת הפידים

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

הוספת פיד

שימו לב: החל מ-15 באפריל 2026, מסגרת המחברים בגרסה 1 ל-Cloud Storage, ל-Amazon S3, ל-Amazon SQS ול-Azure Blob Storage תצא משימוש. מומלץ להשתמש במסגרת המחברים מגרסה 2, שמשתמשת ב-Google Cloud Storage Transfer Service (STS) להעברה כמעט בזמן אמת. מידע נוסף זמין במאמרים שדרוג פידים של נתונים ב-Cloud Storage למסגרת המחברים מגרסה 2 והוצאה משימוש של תכונות.

כדי להוסיף פיד לחשבון 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 (גרסה 2)
   • ‫Amazon SQS (הוצא משימוש)
   • ‫Amazon SQS (גרסה 2)
   • ‫Azure Blob Storage (הוצא משימוש)
   • ‫Azure Blob Storage (V2)
   • Custom API
   • Google Cloud Pub/Sub
   • ‫Cloud Storage (הוצא משימוש)
   • Cloud Storage (גרסה 2)
   • 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, בוחרים את סוג היומן שמתאים ליומנים שרוצים להעביר. היומנים הזמינים משתנים בהתאם לסוג המקור שבחרתם קודם.

   הערה: עבור סוג היומן AWS CLOUDTRAIL, צריך לוודא שהיומנים הם בפורמט JSON וששם הקובץ הוא קובץ JSON (לא דחוס) או קובץ JSON GZipped (דחוס).

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

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

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

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

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

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

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. לוחצים על יצירת פיד.

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

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

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

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

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

• בשדה 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 או בזמן אמת).

הערה: אם אתם משתמשים ב-VPC Service Controls, תוכלו לקרוא מידע נוסף במאמר הגדרת VPC Service Controls ל-Google SecOps.

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

הערה: אם אתם משתמשים במדיניות הארגון Domain Restricted Sharing ב- Google Cloud, הקפידו להוסיף את מזהה הלקוח של Google SecOps‏ C02h8e9nw לרשימת ההיתרים.

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 מספק חשבון שירות ייחודי שמשמש להזנת נתונים. לחלופין, אפשר לקבל את חשבון השירות הזה באופן פרוגרמטי באמצעות ה-API. מידע נוסף זמין במאמר אחזור חשבון שירות.
7. אופציונלי: מגדירים את חשבון השירות. מידע נוסף זמין במאמר בנושא הענקת גישה לחשבון השירות של Google SecOps.
8. לוחצים על הבא.

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

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

     הערה: אפשר להשתמש בתו כללי לחיפוש כדי להתאים שם של ספרייה שלמה. לדוגמה, gs://cs-myprod/*/more-data הוא שם תקין (כאשר * מחליף את השם המלא של רמה אחת של ספרייה).
     הערה: כדי להגדיר סוגים של פידים מבוססי-אירועים ב-Cloud Storage, צריך להגדיר מינוי ל-Pub/Sub בשביל Cloud Storage, כמו שמתואר במאמר הגדרת Pub/Sub.

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

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

   הערה: פידים של קטגוריות ב-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. לדוגמה, Storage Object Viewer (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 (גרסה 2)
• ‫Amazon SQS (גרסה 2)
• ‫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 של המחשבים של הנציגים לרשימת כתובות ה-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 צריך להיות בפרויקט Google Cloud שלכם שמקושר ל-Google SecOps כדי שהמינוי יאומת. הוא משתמש באסימון JWT מחשבון השירות שלכם לצורך אימות. פרטים נוספים זמינים במאמר אימות למינויי Push.

יצירת פיד מסוג 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) של הודעות Push ופריסת מטען ייעודי (payload) של הודעות Push לכתיבת מטא-נתונים של הודעות.

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

הגדרה של פיד 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 שירותים.

  הערה: אם הגודל של הבקשה או המגבלות של QPS מוגדרים נמוך מדי, יכול להיות שיהיו עיכובים בהעברה של קבוצות נתונים שנשלחות דרך פידים של Webhook. נקודת הקצה של HTTPS push תומכת בגודל בקשה מקסימלי של 4 MB לכל בקשה ובקצב העברת נתונים מקסימלי של 15 K QPS לכל מופע של Google SecOps.

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

1. יוצרים פיד של תגובה לפעולה מאתר אחר (webhook) מסוג HTTPS ומעתיקים את כתובת נקודת הקצה ואת המפתח הסודי.
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 מותאם אישית

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

הערה: יכול להיות שהתכונה הזו לא תהיה זמינה לכל הלקוחות בכל האזורים. אי אפשר לנהל תכונות שנכללות בתוכנית Private Preview בדף Public Preview Manager בפלטפורמת Google SecOps.

פידים של 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 (הגדרות SIEM) > Feeds (פידים).
2. לוחצים על הוספת פיד חדש.
3. לוחצים על Configure a single feed (הגדרת פיד יחיד).
4. בשדה שם הפיד, מזינים שם תיאורי ייחודי (לדוגמה, 1Password-Audit-Events).
5. ברשימה סוג המקור, בוחרים באפשרות Custom API (API בהתאמה אישית).
6. ברשימה Log type (סוג היומן), בוחרים את סוג היומן של Google SecOps.
7. לוחצים על הבא.

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

   • כתובת URL בסיסית: מזינים את המארח הראשי (לדוגמה, https://events.1password.com). הכתובת חייבת להתחיל ב-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>).
   הערה: כל פרטי הכניסה שמוזנים כאן מוסתרים אוטומטית במהלך ההזנה ומוצפנים בצורה מאובטחת ב-Secret Manager, עם תמיכה אופציונלית במפתחות הצפנה בניהול הלקוח (CMEK).

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

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

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

    1. בקטע API endpoint (נקודת קצה ל-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 של נתוני היעד: מזינים את הנתיב המדויק במטען הייעודי (payload) של תגובת ה-API שבו נמצאת רשימת רשומות היומן של היעד. למערכים שעטופים באובייקט (לדוגמה, {"items": [...]}), מזינים items. אם ה-API מחזיר ישירות מערך JSON ברמת הבסיס (לדוגמה, [{...}, {...}]), משאירים את השדה הזה ריק לחלוטין ([]).

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

    1. בקשת הורה (Discovery): מגדירים את נקודת הקצה שמחזירה רשימה של פריטים:
       1. בקטע API endpoint (נקודת קצה ל-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 (צריך להשתמש ב- בבקשת הצאצא שבהמשך).
    3. בקשת צאצא (פרטים): מגדירים את נקודת הקצה שמחזירה יומנים מפורטים לכל פריט:
       1. בקטע API endpoint (נקודת קצה ל-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 (מודל Standard API (Sequential))

ההגדרה הבאה בפורמט 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": []
         }
       }
     ]
   }
 }
}

שיטות מומלצות לשימוש ב-API בהתאמה אישית

• הנחיות לגבי תדירות השליחה של בקשות:
  • מתחילים עם מרווחי זמן מתונים בין בדיקות: מגדירים את מרווח הזמן הראשוני בין בדיקות ל-15 דקות או ל-30 דקות עבור נקודות קצה עם נפח גבוה, כדי לבחון את התנהגות מכסת ה-API של הספק לפני שמקצרים את מרווח הזמן ל-5 דקות.
  • אופטימיזציה ל-fan-out בכמות גדולה: אם אתם משתמשים בפידים מסוג Parent-Child (List & Detail) כדי לגלות עשרות או מאות מקורות, מומלץ מאוד להגדיר את Polling frequency ל-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 של הספק. חשוב לוודא שכתובת ה-URL הבסיסית מסתיימת בצורה תקינה ושנתיב נקודת הקצה מתחיל ב-/.
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 מנסה לשלוף נתונים מהצד השלישי שהוגדר.
• הושלם: הפיד הזה אחזר את הנתונים בהצלחה.
• הועבר לארכיון: הפיד מושבת.

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

  הערה: בעמודה הפעולה האחרונה שהצליחה בדף פידים מוצג התאריך והשעה שבהם בוצע אחזור נתונים בהצלחה מהפיד. בפיד חדש, השדה הזה ריק. פידים מסוג Push, כמו Webhook ו- Google Cloud pubsub, לא מאכלסים את העמודה הזו. לפידים מסוג Push אין לוח זמנים, כלומר הנתונים מגיעים כשהם נשלחים. בפידים של Amazon SQS‏ (V2), העמודה Last succeeded on (ההפעלה האחרונה שהסתיימה בהצלחה) מייצגת את חותמת הזמן של העדכון הפעיל. העדכונים בעמודה הזו מוגבלים ויכול להיות עיכוב של עד 15 דקות.

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

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

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

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

   הערה: בפידים קיימים מופיע [לא הוגדר] כשם הפיד בדף פידים. עורכים את הפיד כדי להוסיף לו שם.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

פידים מבוססי-Push

באמצעות הפידים האלה, מערכות חיצוניות 'דוחפות' נתונים אל 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. כדי למחוק את הפיד באופן סופי, לוחצים על כן, אני רוצה למחוק אותו.

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

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

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

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

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

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

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

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

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

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

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

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

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

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