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

נתמך ב:

Google SecOps SIEM

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

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

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

• 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. הגדרת גיל הקובץ המקסימלי: כשמגדירים את הפידים החדשים, מגדירים את גיל הקובץ המקסימלי לשעתיים בערך לפני שהתחיל העדכון של BYOP. הזמן הזה מאפשר מעבר חלק.

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

   הערה: זה לא חל על פידים שבהם האפשרות מחיקה אחרי העברה מופעלת.

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

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

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

• הגדרות SIEM‏ > פידים (רגיל)
• Content Hub > Content Packs (פרימיום)

הערה: אם אתם משתמשים בפלטפורמת SIEM עצמאית, לא תהיה לכם גישה ל-Content Hub. כדי לשדרג, פנו לנציג 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): העברת הנתונים מתבצעת רק על ידי ה-workers של 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 הוצאה משימוש. אנחנו ממליצים להשתמש ב-framework של המחבר בגרסה 2, שמשתמש ב-Google Cloud Storage Transfer Service (STS) להטמעה כמעט בזמן אמת. מידע נוסף זמין במאמרים שדרוג פידים של נתונים באחסון בענן למסגרת המחברים בגרסה 2 והוצאה משימוש של תכונות.

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

1. בתפריט של Google SecOps, בוחרים באפשרות SIEM Settings‏ >‏ Feeds.

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

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

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

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

   • Amazon Data Firehose
   • Amazon S3 (יצא משימוש)
   • Amazon S3 (V2)
   • Amazon SQS (יצא משימוש)
   • Amazon SQS (V2)
   • Azure Blob Storage (יצא משימוש)
   • Azure Blob Storage (V2)
   • API בהתאמה אישית
   • Google Cloud Pub/Sub
   • Cloud Storage (הוצא משימוש)
   • Cloud Storage (V2)
   • Cloud Storage מבוסס-אירועים
   • API של צד שלישי
   • Webhook

   חשוב לדעת:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• ב-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: מחיקת כל הקבצים והספריות הריקות אחרי ההעברה.

סינון אובייקטים לפי תחילית בפידים של STS

הערה: סינון מבוסס-קידומת באמצעות השדה Include prefixes‏ (include_prefixes) נמצא בתצוגה מקדימה מוגבלת, וצריך להוסיף את הדייר (tenant) שלכם לרשימת ההיתרים. כדי להפעיל את התכונה הזו (enable_feed_include_prefixes) בדייר, פנו ל Google Cloud צוות ניהול החשבון, למנהל החשבונות הטכני (TAM) או ל-Cloud Customer Care. אם הדייר לא נמצא ברשימת ההיתרים, שמירת פיד עם קידומות תחזיר שגיאה. פרטים נוספים זמינים במאמר שגיאה: Generic::failed_precondition: include_prefixes is not enabled for this customer.

השדה Include prefixes (include_prefixes) מסנן אובייקטים של אחסון שמועברים על ידי Storage Transfer Service ‏(STS) לפני ההטמעה, על סמך קידומות של מפתחות אובייקטים. הערכים שתציינו בשדה הזה יועברו ישירות ל-STS ObjectConditions.include_prefixes.

סוגי מקורות נתמכים של פיד STS

אפשר להשתמש בסינון לפי קידומת בסוגים הבאים של מקורות פיד ב-STS‏ (feedSourceType):

• ‫Cloud Storage (V2) (GOOGLE_CLOUD_STORAGE_V2) ו-Cloud Storage Event Driven (GOOGLE_CLOUD_STORAGE_EVENT_DRIVEN)
• ‫Amazon S3 (V2) (AMAZON_S3_V2) ו-Amazon SQS (V2) (AMAZON_SQS_V2)
• ‫Azure Blob Storage (V2) (AZURE_BLOBSTORE_V2) ו-Azure Blob Storage Event Driven (AZURE_BLOBSTORE_EVENT_DRIVEN)

כללי תחביר ואימות של קידומות

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

• בלי לוכסנים בהתחלה: הקידומות הן ביחס לקטגוריה או לשורש של מאגר הנתונים, ואסור שהן יתחילו בלוכסן (/). לדוגמה, צריך להזין logs/audit/ במקום /logs/audit/.
• לוכסנים בסוף לעומת התאמה חלקית: לוכסנים בסוף קובעים אם התחילית תואמת רק לאובייקטים בתיקייה ספציפית או לכל מפתח אובייקט שמתחיל בתחילית:
  • עם קו נטוי בסוף: קידומת שמסתיימת ב-/ (לדוגמה, logs/app/) מגבילה את ההתאמות רק לאובייקטים שבתוך התיקייה הזו. כדי להגדיר את ההיקף ברמת הספרייה, צריך להוסיף לוכסן בסוף.
  • בלי לוכסן בסוף: תחילית בלי / בסוף (לדוגמה, logs/app) תואמת לכל אובייקט שמתחיל במחרוזת הזו, כולל logs/app_old/ ו-logs/application/.
• תלות באותיות רישיות: הקידומות של מפתחות האובייקטים תלויות באותיות רישיות.
• אין תווים כלליים לחיפוש או ביטויים רגולריים: אין תמיכה בהתאמה לתבנית. תווים כמו * ו-? נחשבים לתווים מילוליים.
• אין ערכים ריקים: רשומות קידומת נפרדות לא יכולות להיות ריקות או להכיל רק רווחים לבנים. כדי להטמיע את כל הקטגוריה או המאגר, משאירים את השדה Include prefixes ריק.
• מרחבי שמות נפרדים שלא חופפים: קידומת לא יכולה להיות קידומת של קידומת אחרת באותה רשימה. לדוגמה, ["logs/", "logs/audit/"] לא תקין, אבל קידומות אחיות כמו ["logs/audit/", "logs/vpc/"] תקינות.
• מגבלות: פיד תומך בעד 1,000 קידומות. האורך המקסימלי של כל תחילית הוא 1,024 בייטים בקידוד UTF-8, והיא לא יכולה להכיל תווי חזרה לתחילת השורה (\r) או תווי שורה חדשה (\n).

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

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

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

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

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

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

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

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

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

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

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

   איך יוצרים קטגוריות ב-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). אפשר לעשות את זה רק אם לא הפעלתם הרשאות גישה מאוחדות ברמת הקטגוריה (UBLA).
     5. לוחצים על Save.

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

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

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

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

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

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

       2. מקצים אחד מהתפקידים הבאים, בהתאם לאפשרות שנבחרה ב-Source Deletion Option. אם בוחרים באפשרות On Success, צריך להקצות את התפקיד Storage Legacy Bucket Writer. אם בחרתם באפשרות Never, צריך להקצות את התפקיד Storage Legacy Bucket Reader:

          • כתיבה בקטגוריה באחסון מדור קודם (roles/storage.legacyBucketWriter) אם נדרשת הרשאה למחיקת אובייקטים.
          • קריאה בקטגוריה באחסון מדור קודם (roles/storage.legacyBucketReader) אם לא נדרשת הרשאה למחיקת אובייקטים.

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

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

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

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

          • כתיבה בקטגוריה באחסון מדור קודם (roles/storage.legacyBucketWriter) אם נדרשת הרשאה למחיקת אובייקטים.
          • קריאה בקטגוריה באחסון מדור קודם (roles/storage.legacyBucketReader) אם לא נדרשת הרשאה למחיקת אובייקטים.

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

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

• 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.

   • ב-Amazon S3

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

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

     הערה: אם אתם משתמשים בסוכנים במקום בהעברה ללא סוכנים, הוסיפו את כתובות ה-IP של מכונות הסוכנים לרשימת כתובות ה-IP המורשות.

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

   • ב-Azure Storage

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

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

     כדי להוסיף את הטווחים האלה ככתובות IP מותרות, פועלים לפי ההוראות במאמר Configure Azure Storage firewalls and virtual networks.

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

כדי להגדיר פיד Pub/Sub בדחיפה:

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

הערה: פיד ה-push של Pub/Sub צריך להיות בפרויקט Google Cloud שמקושר ל-Google SecOps כדי שהמינוי יאומת. הוא משתמש באסימון JWT מחשבון השירות שלכם לצורך אימות. למידע נוסף, ראו אימות למינויי דחיפה.

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

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

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

אחרי שיוצרים פיד דחיפה של Pub/Sub, מציינים את כתובת ה-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, לוחצים על Settings ואז על Feeds.
2. לוחצים על הוספה.
3. בשדה שם הפיד, מזינים שם לפיד.
4. ברשימה Source type, בוחרים באפשרות Amazon Data Firehose.
5. בוחרים את סוג היומן. לדוגמה, כדי ליצור פיד ל-Open Cybersecurity Schema Framework, בוחרים באפשרות Open Cybersecurity Schema Framework (OCSF)‎ בתור Log type.
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.
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 תומכת בגודל בקשה מקסימלי של 4MB לכל בקשה, ובקצב העברת נתונים מקסימלי של 15,000 שאילתות לשנייה לכל מכונה של Google SecOps.

כדי להגדיר פיד של תגובה לפעולה מאתר אחר (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, לוחצים על Settings ואז על Feeds.
2. לוחצים על הוספה.
3. בשדה שם הפיד, מזינים שם לפיד.
4. ברשימה Source type, בוחרים באפשרות Webhook.
5. בוחרים את סוג היומן. לדוגמה, כדי ליצור פיד ל-Open Cybersecurity Schema Framework, בוחרים באפשרות Open Cybersecurity Schema Framework (OCSF)‎ בתור Log type.
6. לוחצים על הבא.
7. אופציונלי: מציינים ערכים לפרמטרים הבאים של הקלט:
   • תו מפריד לפיצול: התו שמשמש להפרדה בין שורות ביומן. אפשר להשתמש רק ב-\n.
   • מרחב השמות של הנכס: מרחב השמות של הנכס.
   • תוויות הטמעה: התווית שתתווסף לאירועים מהפיד הזה.
8. לוחצים על הבא.
9. בודקים את הגדרות הפיד החדש במסך סיום ולוחצים על שליחה.
10. לוחצים על יצירת מפתח סודי כדי ליצור מפתח סודי לאימות הפיד הזה.
11. מעתיקים ושומרים את המפתח הסודי, כי אי אפשר לראות אותו שוב. אפשר ליצור מפתח סודי חדש, אבל יצירה מחדש של המפתח הסודי הופכת את המפתח הסודי הקודם למיושן.

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

    זהירות: כשמגדירים את אפליקציית הלקוח, צריך להדביק את כתובת ה-URL המלאה של נקודת הקצה שהועתקה מהשדה Endpoint Information (שמסתיים ב-:importPushLogs). אל תדביקו את כתובת ה-URL הגנרית של מסוף Google SecOps, כי זה יגרום לשגיאות HTTP 404 Not Found.

    

    איור 1. מידע על נקודת הקצה של פיד ה-webhook

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

14. לוחצים על סיום.

יצירת מפתח API לפיד ה-Webhook

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

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

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

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

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

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

• שילוב מהיר: אפשר להוסיף מקורות טלמטריה חדשים תוך דקות באמצעות אשף מודרך, בלי לחכות לעדכונים בקצה העורפי.
• נקודות ביקורת עם שמירת מצב: כדי למנוע כפילויות בנתונים ויומנים חסרים במחזורי הסקרים.
• הסתעפות הורה-צאצא: תמיכה בתהליכי עבודה של גילוי בשתי רמות, כמו הצגת רשימת משאבים ואחזור הטלמטריה שמשויכת אליהם.
• עמידות אוטומטית והגבלת קצב של יצירת בקשות: מונעת הגבלת קצב של יצירת בקשות על ידי הספק וניצול של המכסות. כדי להבטיח הטמעה אמינה ורציפה, הפיד של ה-API המותאם אישית מטפל באופן אוטומטי בתגובות HTTP 429 באמצעות השהיה מעריכית לפני ניסיון חוזר (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. לוחצים על הגדרת פיד יחיד.
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. בקטע Authentication, בוחרים באחת משיטות האימות הנתמכות ומגדירים את שדות החובה:

   • אימות בסיסי: מזינים את שם המשתמש (הזהות של חשבון ה-API) ואת הסוד (כלומר, הסיסמה הסודית או הטוקן).
   • ‫OAuth 2.0 Client Credentials: אימות באמצעות תהליך OAuth 2.0 Client Credentials Grant. מערכת 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 (Sequential): תהליך דגימה לינארי שבו כל דגימה מתבססת ישירות על המצב של הדגימה הקודמת. במודל הזה, הסקר הבא משתמש בסמן, באסימון או בחותמת זמן שחולצו מהסקר הקודם כדי לאחזר רק נתונים חדשים. צריך לבחור בכרטיס הזה כשהספק מספק נקודת קצה שמחזירה ישירות רשומות של אירועי טלמטריה (לדוגמה, 1Password,‏ Okta,‏ SentinelOne,‏ GitHub או Slack).
    • רשימה ופרטים (הורה-צאצא): תהליך גילוי דו-שלבי. הפיד מבצע קריאה ראשונית (הורה) כדי לאחזר רשימה של משאבים או אובייקטים (לדוגמה, רשימה של מזהי משתמשים או אזורים). לאחר מכן, הפיד יוצר באופן אוטומטי קריאות המשך תלויות (צאצא) כדי לאחזר נתוני טלמטריה מפורטים לכל משאב ספציפי שזוהה. בוחרים בכרטיס הזה כש-API של הספק דורש דפוס גילוי דו-שלבי: קודם שולחים קריאה לנקודת קצה (endpoint) כדי לאחזר רשימה דינמית של ישויות (לדוגמה, אזורים, חשבונות, פרויקטים, מכשירים), ואז מבצעים בקשות המשך לקבלת פרטים לכל ישות כדי לאחזר נתוני טלמטריה (לדוגמה, Cloudflare,‏ AWS CloudWatch או Tenable).
    הערה: שני המודלים משתמשים בנקודות ביקורת, תהליך לניהול מצבים ששולף ומאחסן את חותמת הזמן או המזהה הגבוהים ביותר מסקר כדי להמשיך את ההטמעה במחזור הבא בלי לפספס יומנים או ליצור נתונים כפולים.

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

    1. בקטע נקודת קצה ל-API, מגדירים את הפרמטרים הבאים כדי לקבוע את המסלול הטכני ואת קצב הבקשות:
       • נתיב נקודת הקצה: נתיב ה-API הספציפי שמצורף לכתובת ה-URL הבסיסית (לדוגמה, /api/v1/auditevents). הוא מגדיר את משאב הטלמטריה המדויק לשאילתה.
       • שיטת HTTP: בוחרים באפשרות GET כדי לאחזר נתונים באמצעות פרמטרים של שאילתה של כתובת URL, או באפשרות POST כדי לשלוח מטען ייעודי (payload) של חיפוש או גוף של מסנן.
    2. גוף הבקשה: בבקשות POST, צריך לספק את המטען הייעודי (payload) של נתוני ה-JSON. אפשר להטמיע משתנים דינמיים של נקודות ציון, כמו {"limit": 100, "start_time": "{{.last_timestamp}}"}.
    3. מספר הבקשות המקסימלי לדקה: מזינים את מספר הבקשות המקסימלי שאפשר לשלוח בדקה. זהו מגביל קצב בצד הלקוח כדי לעמוד במגבלות הקצב של ה-API של הספק (ברירת המחדל: 5 RPM = בקשה אחת כל 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, מגדירים את הפרמטרים הבאים כדי לקבוע את המסלול הטכני ואת קצב הבקשות:
          • נתיב נקודת הקצה: נתיב ה-API הספציפי שמתווסף לכתובת ה-URL הבסיסית (לדוגמה, /api/v1/auditevents). הנתיב הזה מגדיר את משאב הטלמטריה המדויק שרוצים לשלוח אליו שאילתה.
          • שיטת HTTP: בוחרים באפשרות GET כדי לאחזר נתונים באמצעות פרמטרים של שאילתה של כתובת URL, או באפשרות POST כדי לשלוח מטען ייעודי (payload) של חיפוש או גוף של מסנן.
          • גוף הבקשה: בבקשות POST, צריך לספק את המטען הייעודי (payload) של נתוני ה-JSON. אפשר להטמיע משתנים דינמיים של נקודות ציון, כמו {"limit": 100, "start_time": "{{.last_timestamp}}"}.
       2. מספר הבקשות המקסימלי לדקה: מזינים את מספר הבקשות המקסימלי שאפשר לשלוח בדקה. זהו מגביל קצב בצד הלקוח כדי לעמוד במגבלות הקצב של ה-API של הספק (ברירת המחדל: 5 RPM = בקשה אחת כל 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, מגדירים את הפרמטרים הבאים כדי לקבוע את המסלול הטכני ואת קצב הבקשות:
          • נתיב נקודת הקצה: נתיב ה-API הספציפי שמתווסף לכתובת ה-URL הבסיסית (לדוגמה, /client/v4/zones/{{.zone_id}}/logs/received). הנתיב הזה מגדיר את משאב הטלמטריה המדויק שרוצים לשלוח אליו שאילתה.
          • שיטת HTTP: בוחרים באפשרות GET כדי לאחזר נתונים באמצעות פרמטרים של שאילתה של כתובת URL, או באפשרות POST כדי לשלוח מטען ייעודי (payload) של חיפוש או גוף של מסנן.
          • גוף הבקשה: בבקשות POST, צריך לספק את המטען הייעודי (payload) של נתוני ה-JSON. אפשר להטמיע משתנים דינמיים של נקודות ציון, כמו {"limit": 100, "start_time": "{{.last_timestamp}}"}.
       2. מספר הבקשות המקסימלי לדקה: מזינים את מספר הבקשות המקסימלי שאפשר לשלוח בדקה. זהו מגביל קצב בצד הלקוח כדי לעמוד במגבלות הקצב של ה-API של הספק (ברירת המחדל: 5 RPM = בקשה אחת כל 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 מדגימה מודל של רשימה ופרטים (הורה-צאצא) ל-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) בנפח גבוה: בפידים של הורה-צאצא (רשימה ופרטים) שמגלים עשרות או מאות משאבים, Google ממליצה מאוד להגדיר את תדירות הסקרים ל-30 עד 60 דקות כדי לאפשר לכל משימות הצאצאים להסתיים בצורה נקייה לפני שמתחיל מחזור הגילוי הבא.
• אימות נתיבי הטמעת הנתונים: לפני שמגדירים את נקודות הבדיקה של המצב, משתמשים בתיעוד של הספק או בכלים לבדיקת API כדי לוודא את השם המדויק של שדה ה-JSON של חותמות הזמן.
• פירוק ממשקי API עם כמה צאצאים: אם ממשק API של צד שלישי דורש אחזור של התראות וגם יומני ביקורת לרשימת משתמשים אחת, צריך ליצור שני פידים נפרדים עם צאצא אחד (אחד להתראות ואחד ליומני ביקורת) כדי לשמור על בידוד אופטימלי.

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

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

• קצב בקשות שניתן להגדרה (הגבלת קצב של יצירת בקשות): בקשות HTTP יוצאות מנוהלות באופן אוטומטי כדי למנוע חריגה ממגבלות הקצב של הספק. קצב ברירת המחדל הוא 5 בקשות לדקה (בקשה אחת כל 12 שניות). אתם יכולים לשנות את ההגדרה הזו לכל נקודת קצה באמצעות השדה מספר הבקשות המקסימלי לדקה בהגדרות של נקודת הקצה, כדי להתאים אותה למכסות ה-API שפורסמו על ידי הספק.
• תקרת בקשות צאצא: בפידים מסוג הורה-צאצא (רשימה ופרטים), בקשת גילוי יכולה לשלוח עד 500 בקשות צאצא לכל מחזור דגימה.
• עומק פיצול ברמה אחת: המחבר אוכף בקפדנות עומק פיצול מקסימלי של רמה אחת (גילוי הורה ← פרטי צאצא). אין תמיכה בבקשות תלויות בתצוגת עץ (קריאות לנכדים).
• תקרת הגודל של המטען הייעודי (payload) של התגובה: הגודל המקסימלי המותר של תגובת HTTP לכל בקשה או דף הוא 50MB. אם API ללא חלוקה לדפים מחזיר תגובה שחורגת מ-50MB, השליפה תיכשל ותופיע הודעת שגיאה על מיצוי המשאבים. כדי למנוע את זה, תמיד צריך להגדיר פרמטרים של שאילתות חלוקה לדפים (כמו 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) ובוובהוקים נכנסים.
• ללא Mutual TLS ‏(mTLS): האימות חייב להתבסס על מפתחות API, אימות בסיסי או פרטי כניסה רגילים של לקוח OAuth 2.0. אין תמיכה בלחיצות יד של אישורים מצד הלקוח.

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

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

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 אין הרשאה / HTTP 403 אסור	מפתח ה-API, הסיסמה או פרטי הכניסה ל-OAuth לא תקינים או שפג התוקף שלהם.	עורכים את הפיד, מזינים מחדש פרטי כניסה תקינים ולוחצים על שליחה.
שגיאת HTTP 404 (לא נמצא)	תבנית שגויה של כתובת ה-URL הבסיסית או של נתיב נקודת הקצה.	בודקים את נקודת הקצה (endpoint) במאמרי העזרה של ה-API של הספק. חשוב לוודא שכתובת ה-URL הבסיסית מסתיימת בצורה נקייה, ושהנתיב של נקודת הקצה מתחיל ב-/.
‫HTTP 429 Too Many Requests	חרגתם ממגבלות הקצב של יצירת בקשות ל-API של הספק.	מגדילים את תדירות הסקרים או מקטינים את הפרמטר limit בפרמטרים של השאילתה.
שגיאה בחילוץ JSON (השדה items_path ריק)	חוסר התאמה בנתיב של הגדרת התגובה.	צריך לאמת את מבנה המטען הייעודי (payload) של התגובה מה-API ולעדכן את נתיב ה-JSON של נתוני היעד.
הטמעת נתונים כפולים	חותמת הזמן של הגדרת המצב או הנתיב של מחלץ המזהים לא תקינים.	בודקים את שם השדה של רשומת היומן כדי למצוא את חותמת הזמן, ומעדכנים את נתיב החילוץ.

ניהול פידים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• פעיל: הפיד מוגדר ומוכן להטמעת נתונים בחשבון Google SecOps.

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

• InProgress: מערכת Google SecOps מנסה לשלוף נתונים מהצד השלישי שהוגדר.

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

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

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

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

עריכת פידים קיימים

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

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. פידים בדחיפה כוללים:

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

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

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

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

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

מחיקת פידים

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

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

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

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

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

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

שליטה בקצב הטמעת הנתונים

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

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

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

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

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

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

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

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

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

• שגיאה בתהליך Generic::failed_precondition:

  שגיאה: Generic::failed_precondition: include_prefixes is not enabled for this customer

  השגיאה הזו מתרחשת כששומרים פיד STS עם ערכים בשדה Include prefixes (include_prefixes), אבל הדייר (tenant) שלכם ב-Google SecOps לא נמצא ברשימת ההיתרים לסינון מבוסס-קידומת.

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

  1. מסירים את כל הקידומות מהשדה הכללת קידומות (include_prefixes) ושומרים שוב את הפיד כדי להטמיע את כל הקטגוריה או המאגר.
  2. כדי לבקש גישה לתכונה include_prefixes (enable_feed_include_prefixes) בדייר (tenant) שלכם, פנו ל Google Cloud צוות ניהול החשבון, למנהל החשבונות הטכני (TAM) או לCloud Customer Care. מידע נוסף זמין במאמר סינון אובייקטים לפי קידומת בפידים של STS.

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