‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

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

נתמך ב:

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	‫2GB
מודלים של נתונים	XML / JSON	פחות מ-1GB	פחות מ-10 דקות	‫2GB
מודלים של נתונים	XLS / XLSX	פחות מ-50MB	~דקה אחת	50MB
מיזוג קבצים	הכול	פחות מ-1GB	משתנה בהתאם למספר הקבצים	100GB
חילוץ קבצים	לא ZIP	פחות מ-5GB	משתנה בהתאם למספר הקבצים	‫10GB (לא דחוס)
פריסת קבצים	מיקוד	-	משתנה בהתאם למספר הקבצים	‫4GB (לא דחוס)

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

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

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

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

אם אתם מעדכנים את 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.

פעולות נדרשות מצד הלקוחות

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

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

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

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

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

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

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

מכיוון שטווחי כתובות ה-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 הגדירה לחשבון שלכם, כולל פידי הנתונים שהגדרתם.

הוספת פיד

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

בתפריט של Google SecOps, בוחרים באפשרות SIEM Settings ‏> Feeds.
לוחצים על הוספת פיד חדש.
בדף הבא, לוחצים על הגדרת פיד יחיד. הערה: השלב הזה לא רלוונטי ללקוחות שמשתמשים בפלטפורמה העצמאית של Google SecOps SIEM.
מוסיפים שם לפיד.
ברשימה סוג המקור, בוחרים את סוג המקור לייבוא נתונים אל Google SecOps. אפשר לבחור מבין סוגי מקורות הפיד הבאים:
- Amazon Data Firehose
- ‫Amazon S3 (יצא משימוש)
- ‫Amazon S3 (גרסה 2)
- ‫Amazon SQS (יצא משימוש)
- Amazon SQS (V2)
- 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 (V2), צריך לתת ל-Google SecOps הרשאות מפורשות למחוק הודעות מהתור של Amazon SQS.
- כשמשתמשים בפידים של Amazon SQS (הוצא משימוש), צריך לוודא שרק פיד אחד צורך הודעות מהתור. הודעות שנקראו על ידי אפליקציה או פיד אחרים לא נכללות בפיד הנוכחי.
- אפשר להשתמש ב-Amazon SQS (הוצא משימוש) כסוג מקור הפיד רק ליומנים בקטגוריות של Amazon S3.
ברשימה Log type, בוחרים את סוג היומן שמתאים ליומנים שרוצים להטמיע. היומנים הזמינים משתנים בהתאם לסוג המקור שבחרתם קודם.

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

אם בוחרים באפשרות Cloud Storage כסוג המקור, משתמשים באפשרות Get service account כדי לקבל חשבון שירות ייחודי. דוגמה להגדרת פיד ב-Google Cloud Storage
לוחצים על הבא.
מציינים את הפרמטרים הנדרשים בכרטיסייה Input Parameters (פרמטרים של קלט). האפשרויות שמוצגות כאן משתנות בהתאם למקור ולסוג היומן שנבחרו בכרטיסייה Set Properties. כדי לקבל מידע נוסף על מה שצריך לספק, מעבירים את הסמן מעל סמל סימן השאלה של כל שדה.
אופציונלי: אפשר לציין מרחב שמות בכרטיסייה הגדרת מאפיינים. מידע נוסף על מרחבי שמות זמין במאמר עבודה עם מרחבי שמות של נכסים.
לוחצים על הבא.
בודקים את הגדרות הפיד החדשות בכרטיסייה סיום.
לוחצים על שליחה. ‫Google SecOps משלים בדיקת אימות של הפיד החדש. אם הפיד עובר את הבדיקה, נוצר שם בשביל הפיד, הוא נשלח אל Google SecOps, ו-Google SecOps מתחילה לנסות לאחזר נתונים.

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

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

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

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

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

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

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

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

שדה	תיאור
`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`.

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

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

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

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

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

בשדה SOURCE DELETION OPTION (אפשרות למחיקת מקור) מוצגות האפשרויות הבאות לגבי סוגי מקורות נתונים נתמכים, כולל Cloud Storage:
- לא למחוק קבצים אף פעם
- מחיקת קבצים שהועברו ותיקיות ריקות
- מחיקת קבצים שהועברו
ב-Microsoft Azure Blob Storage‏ (AZURE_BLOBSTORE) אי אפשר למחוק קובצי מקור. בשדה SOURCE DELETION OPTION, בוחרים רק באפשרות Never delete files.
במקורות הפיד הבאים ("feedSourceType"): GOOGLE_CLOUD_STORAGE_V2,‏ GOOGLE_CLOUD_STORAGE_EVENT_DRIVEN, AMAZON_S3_V2,‏ AMAZON_SQS_V2 ו-AZURE_BLOBSTORE_V2, השדה SOURCE DELETION OPTION מציע שתי אפשרויות:
- אף פעם: אף פעם לא נמחקים קבצים אחרי העברה.
- ‫ON_SUCCESS: מחיקה של כל הקבצים והספריות הריקות אחרי ההעברה.

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

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

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

בתפריט Google SecOps, בוחרים באפשרות הגדרות ואז לוחצים על פידים.
לוחצים על הוספת פיד חדש.
בדף הבא, לוחצים על הגדרת פיד יחיד. השלב הזה לא רלוונטי אם אתם משתמשים בפלטפורמה העצמאית של Google SecOps SIEM.
בוחרים באפשרות Cloud Storage v2 בשדה Source Type.
בוחרים את סוג היומן. לדוגמה, כדי ליצור פיד ליומני ביקורת של Google Kubernetes Engine, בוחרים באפשרות Google Kubernetes Engine audit logs (יומני ביקורת של Google Kubernetes Engine) בתור Log Type (סוג יומן).
לוחצים על Get service account. ב-Google SecOps יש חשבון שירות ייחודי שמשמש להטמעת נתונים. אפשר גם לקבל את חשבון השירות הזה באופן פרוגרמטי באמצעות ה-API. מידע נוסף זמין במאמר אחזור חשבון שירות.
אופציונלי: מגדירים את חשבון השירות. מידע נוסף זמין במאמר בנושא הענקת גישה לחשבון השירות של Google SecOps.
לוחצים על הבא.
בהתאם להגדרות של Cloud Storage שיצרתם, מציינים ערכים בשדות הבאים:
- URI של קטגוריית אחסון
  
  הערה: אפשר להשתמש בתו כללי לחיפוש כדי להתאים שם של ספרייה שלמה. לדוגמה, gs://cs-myprod/*/more-data הוא תקין (כאשר * מחליף את השם המלא של רמת ספרייה אחת).
  הערה: בסוגי פידים מבוססי-אירועים של Cloud Storage, צריך להגדיר מינוי ל-Pub/Sub בשביל Cloud Storage, כפי שמתואר בקטע הגדרת Pub/Sub.
- אפשרות למחיקת מקור
כדי ללמוד עוד על איך מגדירים קטגוריות של Cloud Storage, ראו יצירת קטגוריות.

הערה: פידים של קטגוריות ב-Cloud Storage לא פועלים עם שמות של תיקיות ריקות.
לוחצים על הבא ואז על שליחה.

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

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

כניסה לדף Buckets
נותנים לחשבון השירות גישה לאובייקטים הרלוונטיים ב-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 כחשבון משתמש בקטגוריה, ולתת לו את התפקיד אדמין של אובייקטים ב-Cloud Storage (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. אם בוחרים באפשרות לעולם לא, צריך להקצות את התפקיד קריאה בקטגוריה באחסון מדור קודם:
      - ‫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.
      - יצירת אובייקטים של אחסון (roles/storage.objectCreator) אם ההעברה היא למערכת קבצים.
    2. נותנים את אחד מהתפקידים הבאים:
      - ‫Storage Legacy Bucket Writer (roles/storage.legacyBucketWriter) אם נדרשת הרשאת מחיקת אובייקטים.
      - קריאה בקטגוריה באחסון מדור קודם (roles/storage.legacyBucketReader) אם לא נדרשת הרשאה למחיקת אובייקטים.

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

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

‫Amazon S3 (גרסה 2)
Amazon SQS (V2)
‫Azure Blob Storage (V2)

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

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

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

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

במאמר כתובות IP לדומיינים שמוגדרים כברירת מחדל מופיע סקריפט Python לדוגמה שמחלץ טווחי כתובות IP מקובץ JSON.
משווים את טווח כתובות ה-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 שמשמשים את ה-workers של STS לרשימת כתובות ה-IP המותרות.
  
  כדי להוסיף את הטווחים האלה ככתובות IP מותרות, פועלים לפי ההוראות במאמר Configure Azure Storage firewalls and virtual networks.

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

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

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

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

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

ציון כתובת ה-URL של נקודת הקצה

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

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

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

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

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

יצירת פיד Amazon Data Firehose

בתפריט של Google SecOps, לוחצים על Settings ואז על Feeds.
לוחצים על הוספה.
בשדה שם הפיד, מזינים שם לפיד.
ברשימה סוג המקור, בוחרים באפשרות Amazon Data Firehose.
בוחרים את סוג היומן. לדוגמה, כדי ליצור פיד ל-Open Cybersecurity Schema Framework, בוחרים באפשרות Open Cybersecurity Schema Framework (OCSF)‎ בתור Log type.
לוחצים על הבא.
אופציונלי: מציינים ערכים לפרמטרים הבאים של הקלט:
- תו מפריד לפיצול: התו שמשמש להפרדה בין שורות ביומן. אפשר להשתמש רק ב-\n.
- מרחב השמות של הנכס: מרחב השמות של הנכס.
- תוויות להוספה: התווית שתתווסף לאירועים מהפיד הזה.
לוחצים על הבא.
בודקים את ההגדרות של הפיד החדש במסך סיום ולוחצים על שליחה.
לוחצים על יצירת מפתח סודי כדי ליצור מפתח סודי לאימות הפיד הזה.
מעתיקים ושומרים את המפתח הסודי, כי לא תוכלו לראות אותו שוב. אפשר ליצור מחדש מפתח סודי, אבל יצירה מחדש של המפתח הסודי מבטלת את התוקף של המפתח הסודי הקודם.
בכרטיסייה פרטים, מעתיקים את כתובת ה-URL של נקודת הקצה של הפיד מהשדה פרטי נקודת הקצה. תצטרכו את כתובת ה-URL של נקודת הקצה הזו כשמציינים את הגדרות היעד של זרם ההעברה ב-Amazon Data Firehose.
אופציונלי: לוחצים על המתג הפיד מופעל כדי להשבית את הפיד. הפיד מופעל כברירת מחדל.
לוחצים על סיום.

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

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

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

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

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

מוסיפים את מפתח ה-API לכתובת ה-URL של נקודת הקצה של הפיד, ומציינים את כתובת ה-URL הזו ככתובת ה-URL של נקודת הקצה של ה-HTTP בפורמט הבא:
```
  ENDPOINT_URL?key=API_KEY
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫ENDPOINT_URL: כתובת ה-URL של נקודת הקצה של הפיד.
- ‫API_KEY: מפתח ה-API לאימות ב-Google SecOps.
במקום מפתח הגישה, מציינים את המפתח הסודי שקיבלתם כשיצרתם את הפיד של Amazon Data Firehose.

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

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

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

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

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

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

בתפריט Google SecOps, בוחרים באפשרות הגדרות ואז לוחצים על פידים.
לוחצים על הוספה.
בשדה שם הפיד, מזינים שם לפיד.
ברשימה סוג המקור, בוחרים באפשרות Webhook.
בוחרים את סוג היומן. לדוגמה, כדי ליצור פיד ל-Open Cybersecurity Schema Framework, בוחרים באפשרות Open Cybersecurity Schema Framework (OCSF)‎ בתור Log type.
לוחצים על הבא.
אופציונלי: מציינים ערכים לפרמטרים הבאים של הקלט:
- תו מפריד לפיצול: התו המפריד שמשמש להפרדה בין שורות ביומן. אפשר להשתמש רק ב-\n.
- מרחב השמות של הנכס: מרחב השמות של הנכס.
- תוויות להוספה: התווית שתתווסף לאירועים מהפיד הזה.
לוחצים על הבא.
בודקים את ההגדרות של הפיד החדש במסך סיום ולוחצים על שליחה.
לוחצים על יצירת מפתח סודי כדי ליצור מפתח סודי לאימות הפיד הזה.
מעתיקים ושומרים את המפתח הסודי, כי לא תוכלו לראות אותו שוב. אפשר ליצור מחדש מפתח סודי, אבל יצירה מחדש של המפתח הסודי מבטלת את התוקף של המפתח הסודי הקודם.
בכרטיסייה Details (פרטים), מעתיקים את כתובת ה-URL של נקודת הקצה של הפיד מהשדה Endpoint Information (פרטי נקודת הקצה). צריך לציין את כתובת ה-URL של נקודת הקצה הזו באפליקציית הלקוח.
אופציונלי: לוחצים על המתג הפיד מופעל כדי להשבית את הפיד. הפיד מופעל כברירת מחדל.
לוחצים על סיום.

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

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

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

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

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

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

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

עוברים אל SIEM Settings (הגדרות SIEM) > Feeds (פידים).
לוחצים על הוספת פיד חדש.
לוחצים על הגדרת פיד יחיד.
בשדה שם הפיד, מזינים שם תיאורי ייחודי (לדוגמה, 1Password-Audit-Events).
ברשימה סוג המקור, בוחרים באפשרות API בהתאמה אישית.
ברשימה Log type (סוג היומן), בוחרים את סוג היומן של Google SecOps.
לוחצים על הבא.
בקטע הגדרות כלליות, קובעים את ההגדרות הבאות:
- כתובת URL בסיסית: מזינים את המארח הראשי (לדוגמה, https://events.1password.com). הכתובת חייבת להתחיל ב-https://. אל תוסיפו נתיבי משנה או לוכסנים בסוף הכתובת.
- תדירות הבדיקה: מציינים באיזו תדירות הפלטפורמה בודקת את ה-API כדי לראות אם יש טלמטריה חדשה, בדקות. הטווח הנתמך: 5 עד 2,880 דקות (ברירת מחדל: 15 דקות). בפידים של Standard API (Sequential)‎, פרק הזמן הסטנדרטי הוא 10-15 דקות. בפידים של List & Detail (Parent-Child)‎, מומלץ להגדיר פרק זמן של 30-60 דקות כדי לאפשר ביצוע מלא של משימות fan-out בלי חפיפה.
בקטע אימות, בוחרים אחת משיטות האימות הנתמכות ומגדירים את השדות הנדרשים:
- אימות בסיסי: מזינים את שם המשתמש (זהות חשבון ה-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).
בוחרים את מודל המחבר שבו משתמש ה-API בהתאמה אישית:
- ‫Standard API (Sequential): תהליך ליניארי של שליחת בקשות, שבו כל בקשה מתבססת ישירות על המצב של הבקשה הקודמת. במודל הזה, הסקר הבא משתמש בסמן, באסימון או בחותמת זמן שחולצו מהסקר הקודם כדי לאחזר רק נתונים חדשים. צריך לבחור בכרטיס הזה כשהספק מספק נקודת קצה שמחזירה ישירות רשומות של אירועי טלמטריה (לדוגמה, 1Password,‏ Okta,‏ SentinelOne,‏ GitHub או Slack).
- רשימה ופרטים (הורה-צאצא): תהליך גילוי בשתי רמות. הפיד מבצע קריאה ראשונית (parent) כדי לאחזר רשימה של משאבים או אובייקטים (לדוגמה, רשימה של מזהי משתמשים או אזורים). לאחר מכן, הפיד יוצר באופן אוטומטי קריאות המשך תלויות (צאצא) כדי לאחזר נתוני טלמטריה מפורטים לכל משאב ספציפי שזוהה. בוחרים את הכרטיס הזה אם ה-API של הספק דורש תבנית גילוי דו-שכבתית: קודם שולחים קריאה לנקודת קצה כדי לאחזר רשימה דינמית של ישויות (לדוגמה, אזורים, חשבונות, פרויקטים, מכשירים), ואז מבצעים בקשות פרטים נוספות לכל ישות כדי לאחזר טלמטריה (לדוגמה, Cloudflare,‏ AWS CloudWatch או Tenable).
הערה: שני המודלים משתמשים בנקודות ביקורת, תהליך לניהול מצבים ששולף ומאחסן את חותמת הזמן או המזהה הגבוהים ביותר מסקר, כדי להמשיך את ההטמעה במחזור הבא בלי לפספס יומנים או ליצור נתונים כפולים.
אם בחרתם באפשרות Standard API (Sequential)‎, בצעו את הפעולות הבאות:
1. בקטע API endpoint (נקודת קצה ל-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 ברמת הבסיס (לדוגמה, [{...}, {...}]), משאירים את השדה הזה ריק לחלוטין ([]).
אם בחרתם באפשרות רשימה ופרטים (הורה-צאצא), פועלים באופן הבא:
1. בקשת הורה (גילוי): מגדירים את נקודת הקצה שמחזירה רשימה של פריטים:
  1. בקטע API endpoint (נקודת קצה ל-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. אופציונלי: בקטע פרמטרים של שאילתה, מגדירים את Key ו-Value, ואז לוחצים על Add כדי לציין מסננים או אפשרויות נוספים שמצורפים למחרוזת השאילתה של כתובת ה-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. אופציונלי: בקטע פרמטרים של שאילתה, מגדירים את Key ו-Value, ואז לוחצים על Add כדי לציין מסננים או אפשרויות נוספים שמצורפים למחרוזת השאילתה של כתובת ה-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}}).
קובעים את ההגדרות הבאות בקטע תזמון ותוויות:
- תדירות הבדיקה: בוחרים מרווח זמן סטנדרטי (לדוגמה, 5m, 1h).
- מרחב שמות: תג ארגוני אופציונלי.
- ‫Ingestion Labels: צמדי מפתח/ערך ל-Data RBAC.
לוחצים על שליחה. מערכת Google SecOps מבצעת בדיקה אוטומטית לאימות של פרטי הכניסה ונקודת הקצה. אם האימות מצליח, מתחיל תהליך של שליחת בקשות לפיד.

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

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

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

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

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

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

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

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

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

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

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

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

קצב בקשות שניתן להגדרה (הגבלת קצב של יצירת בקשות): קצב בקשות ה-HTTP היוצאות מוגדר באופן אוטומטי כדי למנוע חריגה ממגבלות הקצב של הספק. קצב ברירת המחדל הוא 5 בקשות לדקה (בקשה אחת כל 12 שניות). אפשר לשנות את ההגדרה הזו לכל נקודת קצה באמצעות השדה מספר הבקשות המקסימלי לדקה בהגדרות של נקודת הקצה, כדי להתאים אותה למכסות ה-API שפורסמו על ידי הספק.
מגבלת בקשות של ילדים: בפידים מסוג Parent-Child (List & Detail), בקשת גילוי יכולה לשלוח עד 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.
עימוד: אפשר להשתמש באמצעי הבקרה של העימוד כדי:
- משנים את מספר השורות בדף.
- כדי לעבור בין דפי הפידים, משתמשים בכרטיסיות הדפים ובחיצים.
הזמן האחרון שבו בוצע רענון: חותמת הזמן מראה מתי רשימת הפידים עודכנה לאחרונה.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

קטגוריות של אחסון בענן, כמו Amazon S3,‏ Google Cloud Storage, ‏ Azure Blob Storage
שרתי SFTP
ממשקי API של צד שלישי, כמו Microsoft 365,‏ Okta ו-Proofpoint

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

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

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

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

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

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

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

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

מחיקת פידים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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