פריסת סוכן Bindplane לאיסוף

נתמך ב:

במסמך הזה מוסבר על Bindplane ל-Google Security Operations.

‫Bindplane הוא צינור טלמטריה שיכול לאסוף, לחדד ולייצא יומנים מכל מקור אל Google SecOps.

‫Bindplane מציעה שתי מהדורות שמתאימות במיוחד ל-Google.

‫Bindplane כולל את הרכיבים העיקריים הבאים:

  • Bindplane collector. סוכן קוד פתוח שמבוסס על OpenTelemetry ‏ (OTel) Collector. הוא אוסף יומנים ממקורות שונים, כולל יומני אירועים של Microsoft Windows, ושולח אותם ל-Google SecOps. אפשר להתקין את האוספים במקום או בענן.

    הרכיב הזה נקרא גם Bindplane Distribution for OpenTelemetry (BDOT) Collector,‏ bindplane agent,‏ collection agent,‏ collector או agent.

  • ‫Bindplane Server. פלטפורמה מקיפה ומאוחדת לניהול פריסות של OTel Collector. הפריסות האלה יכולות להיות ב-Google SecOps וב- Google Cloud. הרבה לקוחות של Google SecOps משתמשים ב-Bindplane Server, אבל השימוש בו הוא אופציונלי. אפשר להריץ את Bindplane Server באופן מקומי או בענן Bindplane. מידע נוסף על השרת זמין במאמר שרת Bindplane.

    הרכיב הזה נקרא גם מסוף הניהול של צינור הנתונים (OP) של Bindplane Observability או מסוף הניהול של Bindplane.

מהדורות Google של Bindplane

יש שתי מהדורות של Bindplane שמתאימות במיוחד ל-Google: ‏ Bindplane (Google Edition) ו-Bindplane Enterprise (Google Edition).

‫Bindplane (מהדורת Google)

‫Bindplane (מהדורת Google) מסופק לכל לקוחות Google SecOps.

אתם יכולים להשתמש ב-Bindplane (מהדורת Google) בניהול עצמי בענן Bindplane.

כדי להתחיל להתקין את Bindplane (מהדורת Google) ולארח אותו בעצמכם, או כדי ליצור את המפתח שלכם לשרת Bindplane מקומי, אפשר לעיין במאמר בנושא Bindplane (מהדורת Google).

‫Bindplane Enterprise (מהדורת Google) – ללקוחות Google SecOps Enterprise Plus

‫Bindplane Enterprise (מהדורת Google) כלול במינוי Google SecOps Enterprise Plus.

מומלץ להשתמש ב-Bindplane Enterprise (מהדורת Google) לפריסות רחבות היקף.

כדי לקבל את מפתח הרישיון של Bindplane Enterprise (מהדורת Google), צריך לפנות לצוות של חשבון Google.

מהדורות Google של Bindplane – הבדלים

בטבלה הבאה מפורטים ההבדלים בין מהדורות Google של Bindplane:

נושא או תכונה ‫Bindplane (מהדורת Google) ‫Bindplane Enterprise (מהדורת Google)
עלות כלול במינוי ללא עלות נוספת לכל הלקוחות של Google SecOps כלול בחינם ללקוחות Google SecOps Enterprise Plus
תכנון מסלול/יעדים ‫Google בלבד, כולל Google SecOps,‏ Cloud Logging,‏ BigQuery ו-Cloud Storage דרך Google SecOps ‫Google, כולל 12 חודשים של ניתוב ליעד שאינו של Google למעבר ל-SIEM
סינון מסנן בסיסי עם ביטוי רגולרי מעבדים לסינון מתקדם (לדוגמה, סינון לפי תנאי, שדה, חומרה וכו'), צמצום נתונים, דגימת יומנים, ביטול כפילויות
עריכה לא רלוונטי אנונימיזציה של פרטים אישיים מזהים (PII)
טרנספורמציה הוספת שדה, העברת שדה, ניתוח נתונים (KV, ‏ JSON, ‏ CSV, ‏ XML, חותמת זמן, ניתוח באמצעות ביטוי רגולרי), שינוי שם של שדה, מפריד אירועים התוכנית כוללת את כל היכולות שנתמכות ב-Bindplane (מהדורת Google) בנוסף למחיקת שדה, מחיקת ערכים ריקים ומיזוג
תכונות כלליות ברמת הפלטפורמה שער (נתונים מצטברים מאוספי נתונים), אוספי נתונים של Bindplane, שרת Bindplane (שכבת ניהול של Bindplane) באתר או באירוח בענן, כל המקורות, מעקב שקט אחרי מארחים באמצעות מעבד Google SecOps, תור מתמשך, העשרה של טלמטריה, זמינות גבוהה, RBAC, שני ממשקי ה-API להטמעת נתונים של Google SecOps נתמכים, הסתרת פרטי הכניסה, ניהול מתקדם של ציוד, כולל קיבוץ של אוספי נתונים, הקצאה דינמית של סוגי יומנים כל היכולות שנתמכות ב-Bindplane (מהדורת Google)

ארכיטקטורה של Bindplane Collector

‫Bindplane משתמש ב-BDOT Collector – שנקרא באופן כללי collector – כדי לתקנן את ניהול הטלמטריה באמצעות Open Agent Management Protocol‏ (OpAMP). אפשר גם ליצור ולנהל הפצות מותאמות אישית של OpenTelemetry Collector באמצעות Bindplane.

הכלי לאיסוף נתונים יכול לפעול ב-Linux או ב-Docker כשרת אינטרנט קל משקל ללא תלות חיצונית.

מידע נוסף על ארכיטקטורת הפריסה של Bindplane OpenTelemetry collectors זמין במאמר Deployment.

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

מקבצי נתונים שולחים יומנים למקבץ נתונים שפועל כשער

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

מאסף שפועל כשער משתמש באותו קובץ בינארי כמו כל המאספים האחרים.

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

מקבצי נתונים שולחים יומנים למקבץ נתונים שפועל כשער

המאספים שולחים יומנים ישירות אל Google SecOps ingestion API

בתרשים הבא מוצגים כלי איסוף ששולחים יומנים ישירות אל Google SecOps Ingestion API:

המאספים שולחים יומנים ישירות אל Google SecOps ingestion API

המאגדים שולחים יומנים ישירות אל Cloud Logging

בתרשים הבא מוצג תהליך שבו כלי איסוף שולחים יומנים ישירות אל Cloud Logging:

המאגדים שולחים יומנים ישירות אל Cloud Logging

מאגרי מידע שולחים יומנים לכמה יעדים

הדיאגרמה הבאה מציגה Collector-ים ששולחים יומנים לכמה יעדים:

הכלי לאיסוף נתונים שולח יומנים לכמה יעדים

שרת Bindplane

התכונות העיקריות של שרת Bindplane:

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

‫Bindplane מציע אפשרויות פריסה בענן ובמקום. מידע נוסף זמין במאמר בנושא שימוש בשרת Bindplane.

דרישות והמלצות טכניות

בקטע הזה מפורטות הדרישות הטכניות וההמלצות להתקנה ולהפעלה של Bindplane עם Google SecOps.

דרישות רוחב הפס

‫Bindplane שומר על חיבורים לרשת עבור:

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

הדרישות לקישוריות

כברירת מחדל, Bindplane מאזין ביציאה 3001. אפשר להגדיר את היציאה הזו.

היציאה של Bindplane משמשת ל:

  • פקודות ושליטה ב-Collector באמצעות OpAMP ‏ (WebSocket)
  • בקשות למדידת קצב העברת הנתונים של האוסף (בקשת HTTP POST)
  • משתמשים בדפדפן וב-CLI‏ (HTTP ו-WebSocket)

למאגרי המידע צריכה להיות אפשרות ליזום חיבורים ל-Bindplane for OpAMP‏ (WebSocket) ולמדידות של קצב העברת הנתונים (HTTP).

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

דרישות טכניות כלליות של Bindplane collector

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

דרישות המשאבים של אוספים

דרישות המשאבים של Bindplane משתנות בהתאם למספר האוספים המנוהלים. ככל שמספר האוספים המנוהלים גדל, כך גדלים גם השימוש במעבד (CPU), בזיכרון, בנפח הנתונים בדיסק, ב-IOPS וברשת.

הטבלה הבאה מציגה את הגודל של המעבד, הזיכרון וקיבולת האחסון:

מספר כלי האיסוף צמתים של Bindplane עמידות בפני תקלות ליבות CPU זיכרון מסד נתונים
1-‎100 1 לא רלוונטי 2 ‫4GB bbolt
‫100-25,000 1 לא רלוונטי 4 ‫16GB postgres
‫1-60,000 3 1 2 8 GB postgres
‫60,001-125,000 5 1 2 8 GB postgres
125,001-250,000 10 2 2 8 GB postgres

תכנון ההתקנה והפריסה

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

שיקולים לגבי הרחבה ועמידות בפני תקלות

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

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

חישוב מספר האוספים שצריך

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

Telemetry throughput Logs/second Collectors
‫5GB/m 250,000 2
‫‎10 GB/m 500,000 3
‫20GB/m 1,000,000 5
‫100GB/m ‫5,000,000 25

הקצאת יתר של צי ה-Collectors לצורך סובלנות לתקלות

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

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

הפחתת עומס של תקורה של עיבוד

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

שיטות מומלצות לשימוש במצב שער

כשמפעילים את כלי האיסוף של Bindplane במצב שער, מומלץ לתכנן את הפריסה לפי השיטות המומלצות הבאות:

  • מציבים לפחות שני אוספים מאחורי מאזן עומסים.
  • לכל מאסף צריכים להיות לפחות שני ליבות.
  • לכל מאסף צריך להיות זיכרון בנפח של 8GB לפחות.
  • לכל מאסף צריך להיות נפח אחסון של 60GB לשימוש בתור מתמשך.

שימוש במאזן עומסים כשצריך

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

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

אפשר להשתמש בכלי Bindplane Collector עם מגוון רחב של מאזני עומסים.

מידע נוסף זמין במאמר בנושא הגדרת מאזן עומסים.

יציאות ופרוטוקולים של איזון עומסים

כברירת מחדל, Bindplane מאזין ביציאה 3001.

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

  • פרוטוקולי העברה של TCP/UDP
  • פרוטוקולי אפליקציה HTTP ו-gRPC

התאמת גודל של איזון עומסים

כדי להשיג את סבילות התקלות המקסימלית, כל צומת של Bindplane צריך לנהל עד 30,000 אוספים. כל אוסף פותח שני חיבורים ל-Bindplane (אחד לניהול מרחוק של OpAMP ואחד לפרסום מדדי תפוקה). ההגבלה הזו עוזרת לוודא שלא תחרגו ממגבלת החיבורים של כ-65,535 לכל מופע של שרת עורפי, שמוטלת על ידי רוב מאזני העומסים.

אם בארגון יש 100,000 אוספים, גודל אשכול של שלוש לא יספיק. כל צומת יהיה אחראי לכ-33,000 אוספים, שמתורגמים ל-66,000 חיבורי TCP לכל מופע של Bindplane. המצב הזה מחמיר אם צומת אחד מושבת לצורך תחזוקה, כי כל מופע Bindplane שנותר ינהל 50,000 אוספים, או 100,000 חיבורי TCP.

שיטות מומלצות לקביעת הגודל של איזון העומסים

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

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

    • פרוטוקולי העברה של TCP/UDP
    • פרוטוקולי אפליקציה HTTP ו-gRPC

מידע נוסף זמין במאמר בנושא חוסן של כלי האיסוף.

איזון עומסים לפי סוג המקור

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

  • OTLP
  • Syslog
  • TCP/UDP
  • Splunk HEC
  • Fluent Forward

שימוש במצב זמינות גבוהה בסביבות ייצור

אפשר לפרוס מופע של Bindplane בהגדרה של מופע יחיד או כמה מופעים במקביל. לפריסות בסביבת הייצור שדורשות זמינות גבוהה (HA) וחוסן (resilience), מומלץ להשתמש במודל פריסה של כמה מופעים במקביל (HA).

כש-Bindplane מנהל יותר מ-25,000 אוספים, מומלץ להפעיל את Bindplane במצב זמינות גבוהה (HA).

מידע על זמינות גבוהה ב-Bindplane זמין במאמר זמינות גבוהה.

חישוב מספר ה-Collectors ושרתי Bindplane לזמינות גבוהה

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

לוקחים את המספר הכולל של מופעי Bindplane ומפחיתים ממנו את המספר המקסימלי של צמתים שצפויים להיות לא זמינים בגלל תחזוקה. חשוב לוודא שכל צומת לא מנהל יותר מ-30,0�אלף אוספים במהלך הפסקת פעולה של צומת.

‫Postgres for HA

‫Postgres היא דרישה מוקדמת כשמפעילים את Bindplane במצב HA.

‫Prometheus ל-HA

נדרש Prometheus כשמפעילים את Bindplane במצב HA.

מידע נוסף זמין במאמר בנושא Prometheus.

אוטובוס אירועים לזמינות גבוהה

‫Bindplane משתמש באפיק אירועים כדי לתקשר בין רכיבים בתוך Bindplane. כשמפעילים את Bindplane במצב HA, אפשר להשתמש באפיק האירועים כדי לשלוח אירועים בין שרתי Bindplane.

מידע נוסף זמין במאמר בנושא Event Bus.

שימוש בפריסה של מופע יחיד לסביבת בדיקה או להוכחת היתכנות

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

מידע נוסף זמין במאמר בנושא מופע יחיד.

בידוד פרטי הכניסה של ה-Backend

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

הגדרת חומת אש לנתבי האוספים

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

חומת האש צריכה לאפשר לתנועת HTTP להגיע אל Bindplane ביציאה שהוגדרה.

אימות ההגדרות של חומת האש (Ingestion API)

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

סוג החיבור יעד יציאה
TCP malachiteingestion-pa.googleapis.com 443
TCP asia-northeast1-malachiteingestion-pa.googleapis.com 443
TCP asia-south1-malachiteingestion-pa.googleapis.com 443
TCP asia-southeast1-malachiteingestion-pa.googleapis.com 443
TCP australia-southeast1-malachiteingestion-pa.googleapis.com 443
TCP europe-malachiteingestion-pa.googleapis.com 443
TCP europe-west2-malachiteingestion-pa.googleapis.com 443
TCP europe-west3-malachiteingestion-pa.googleapis.com 443
TCP europe-west6-malachiteingestion-pa.googleapis.com 443
TCP europe-west12-malachiteingestion-pa.googleapis.com 443
TCP me-central1-malachiteingestion-pa.googleapis.com 443
TCP me-central2-malachiteingestion-pa.googleapis.com 443
TCP me-west1-malachiteingestion-pa.googleapis.com 443
TCP northamerica-northeast2-malachiteingestion-pa.googleapis.com 443
TCP accounts.google.com 443
TCP oauth2.googleapis.com 443

דרישות מוקדמות להטמעה של Google SecOps באמצעות Bindplane

בקטע הזה מפורטים התנאים המוקדמים שנדרשים להעברת נתונים ל-Google SecOps באמצעות Bindplane, במיוחד כשמשתמשים ב-Chronicle Ingestion API.

דרישות הרשת ל-Chronicle API ‏ (HTTPS)

כשמשתמשים ב-Bindplane עם Chronicle Ingestion API, שמשתמש ב-HTTPS, צריך לוודא שההגדרות של הרשת ושל חומת האש מאפשרות חיבורים יוצאים לנקודות הקצה של Chronicle API.

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

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

  • הוספה לרשימת ההיתרים על בסיס דומיין: מומלץ להגדיר את חומת האש כך שתאפשר תנועת HTTPS (יציאה 443) יוצאת לכל הדומיין *.chronicle.googleapis.com.
  • נקודות קצה אזוריות: צריך להגדיר את Bindplane כך שישתמש בנקודת הקצה האזורית המתאימה למופע Google SecOps שלכם, כמו us-chronicle.googleapis.com,‏ europe-chronicle.googleapis.com וכו'. רשימה מלאה של נקודות קצה אזוריות זמינה במסמכי התיעוד בנושא מעבר מ-SIEM API מדור קודם ל-Chronicle API.
  • עדכונים אוטומטיים של כתובות IP: אם אי אפשר להשתמש ברשימת היתרים שמבוססת על דומיין, צריך להטמיע מערכת אוטומטית לאחזור ולעדכון תקופתי של טווחי כתובות ה-IP שמשויכים ל-*.chronicle.googleapis.com. אפשר לקבל את טווחי כתובות ה-IP הנוכחיים של Google APIs מהקבצים goog.json ו-cloud.json, כמו שמתואר במאמרי העזרה כתובות IP של Google. הטמעת מערכת לעדכון דינמי של כללי חומת האש על סמך המקורות האלה.

שימוש ב-PostgreSQL לפריסות בסביבת ייצור

‫Postgres נדרש לפריסות של Bindplane בסביבת ייצור.

‫Postgres היא דרישה מוקדמת להפעלת Bindplane במצב HA.

מספר ליבות ה-CPU והזיכרון הזמין בדרך כלל מגבילים את הביצועים של קצה העורף של אחסון PostgreSQL. מומלץ לגבות את האחסון של PostgreSQL באמצעות אחסון עם זמן אחזור נמוך וקצב העברת נתונים גבוה, כמו כונני מצב מוצק (SSD).

מספר כלי האיסוף ליבות CPU זיכרון
‫1-60,000 4 ‫16GB
‫60,001-125,000 8 32 GB
125,001-250,000 16 ‫64GB

מידע נוסף זמין במאמרים הבאים:

הטמעה של אימות מתאים

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

שימוש בשרת Bindplane

רוב הלקוחות של Google SecOps משתמשים בשרת Bindplane, אבל השימוש בו הוא אופציונלי. אם אתם מתקינים את שרת Bindplane, אתם צריכים גישה אל storage.googleapis.com. אם מתקינים רק מאסף, לא נדרשת גישה כזו.

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

שימוש בשרת Bindplane Cloud

‫Bindplane Cloud זמין ללקוחות Google.

כניסה למהדורת Google

לכל בעיה שקשורה ל-Bindplane Cloud Server, אפשר לפנות אל התמיכה של Bindplane. לבעיות שקשורות ל-Bindplane Server מקומי, אפשר לפנות לתמיכה של Google SecOps.

שימוש בשרת Bindplane ב- Google Cloud

מידע על הפעלת שרת Bindplane ב- Google Cloudזמין במאמר Bindplane Enterprise Edition.

שימוש בשרת Bindplane מקומי

השימוש בשרת Bindplane המקומי כפוף Google Cloud לתנאים ולהגבלות הקיימים.

התקנת השרת המקומי ב-Linux

אפשר להתקין את שרת Bindplane המקומי ב-Linux באמצעות הפעלת סקריפט (מומלץ) או הורדה של קובץ בינארי והתקנה ידנית. מידע נוסף זמין במאמר בנושא התקנת Bindplane Server.

כדי להתקין את שרת Bindplane המקומי ב-Linux באמצעות סקריפט:

  1. מריצים את הסקריפט הזה:

    curl -fsSlL https://downloads.bindplane.com/bindplane/latest/install-linux.sh -o install-linux.sh && bash install-linux.sh --init && rm install-linux.sh

  2. פועלים לפי ההוראות שמנחות אתכם בתהליך עד לאתחול השרת.

כדי להתקין את שרת Bindplane המקומי ב-Linux באמצעות קובץ בינארי:

  1. מורידים אחד מהקבצים הבאים:

  2. מעדכנים את קובץ התצורה לפי ההוראות במאמר הגדרת Bindplane Server.

מהדורות Linux נתמכות:
  • ‫Red Hat, ‏ Centos, ‏ Oracle Linux 7, ‏ 8, ‏ 9
  • ‫Debian 11 ו-12
  • ‫Ubuntu LTS 20.04 ו-22.04
  • ‫SUSE Linux 12 ו-15
  • ‫Alma ו-Rocky Linux

מידע נוסף זמין במאמרים הבאים:

פריסות מקומיות של Docker

מידע נוסף זמין במאמר בנושא התקנת Bindplane Server.

אפשר למצוא קובצי אימג' של קונטיינרים של Docker ב-Bindplane במיקומים הבאים:

  • ‫GitHub packages: ghcr.io/observiq/Bindplane-ee
  • מאגר ארטיפקטים של Google: us-central1-docker.pkg.dev/observiq-containers/bindplane/bindplane-ee
  • ‫Docker hub: observiq/bindplane-ee

תמונות קונטיינרים מתויגות בגרסת הפרסום: לדוגמה, לפרסום v1.35.0 יהיה התג observiq/bindplane-ee:1.35.0.

התקנת כלי האיסוף Bindplane

בקטע הזה מוסבר איך להתקין את Bindplane Collector ל-Google SecOps במערכות שונות.

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

מידע על התקנת ה-Collector (כלומר, סוכן OTel) זמין במאמר Bindplane OTel Collector.

אפשר גם לעיין במסמכי התיעוד של GitHub בנושא bindplane-otel-collector.

כדי להתקין את כלי האיסוף, צריך:

  • קובץ אימות להעברה ב-Google SecOps

    כדי להוריד את קובץ האימות:

    1. פותחים את מסוף Google SecOps.
    2. עוברים אל SIEM Settings (הגדרות SIEM) > Collection Agent (סוכן איסוף).
    3. מורידים את קובץ האימות להטמעת נתונים ב-Google SecOps. השלב הבא תלוי בשיטת ההעברה:
      • ‫gRPC: משתמשים בקובץ האימות שהורדתם.
      • ‫HTTPS: יוצרים חשבון שירות ב Google Cloud פרויקט שמקושר ל-Google SecOps ומקצים לו את התפקיד Chronicle Editor.

  • מספר הלקוח ב-Google SecOps

    כדי למצוא את מספר הלקוח:

    1. פותחים את מסוף Google SecOps.
    2. עוברים אל SIEM Settings (הגדרות SIEM) > Profile (פרופיל).
    3. מעתיקים את מזהה הלקוח מהקטע פרטי הארגון.

  • ‫Windows 2012 SP2 ואילך או מארח Linux עם systemd

  • קישוריות לאינטרנט

  • גישה ל-GitHub

כלים לפריסה

בקטע הזה מתוארים כלי הפריסה של Bindplane.

GitOps

פריסת משאבי Bindplane באמצעות מודל GitOps, שכולל את הפעולות הבאות:

  • אימות ב-Bindplane
  • Bindplane CLI
  • גישה לרשת
  • שילוב עם מאגר ב-GitHub ועם פעולות GitHub
  • ייצוא של משאבים קיימים
  • ניהול ערכים רגישים
  • הגדרת תהליך עבודה של GitHub Action
  • הוראות מפורטות להתחייבות להגדרות ולבדיקה שלהן, להפעלת השקות אוטומטיות ולעדכון משאבים באמצעות עריכות ישירות או שיטת הייצוא של ממשק המשתמש
  • עדכון ערכים רגישים ושימוש ב-RBAC

מידע נוסף זמין במאמר בנושא GitOps.

Ansible

מידע על פריסת Bindplane באמצעות Ansible זמין במאמר bindplane-agent-ansible.

Bindplane CLI

מידע נוסף על Bindplane CLI זמין במאמר בנושא GitOps.

Terraform

במאמר Bindplane Provider מוסבר איך משתמשים ב-Terraform כדי להגדיר את המשאבים של Bindplane.

‏Kubernetes

כדי לקבל מידע על Kubernetes עם Bindplane, אפשר לעיין במאמרים הבאים:

התקנה של Bindplane Collector ב-Windows

כדי להתקין את Bindplane Collector ב-Windows, מריצים את פקודת PowerShell הבאה:

msiexec /i "https://github.com/observIQ/bindplane-agent/releases/latest/download/observiq-otel-collector.msi" /quiet

לחלופין, כדי להתקין באמצעות אשף ההתקנה, מורידים את קובץ ההתקנה העדכני ל-Windows. אחרי שמורידים את קובץ ההתקנה, פותחים את אשף ההתקנה ופועלים לפי ההוראות כדי להגדיר ולהתקין את Bindplane Collector.

מידע נוסף על התקנת כלי האיסוף Bindplane ב-Windows זמין במאמר התקנה ב-Windows.

התקנת Bindplane Collector ב-Linux

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

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

sudo sh -c "$(curl -fsSlL https://github.com/observiq/bindplane-agent/releases/latest/download/install_unix.sh)" install_unix.sh

התקנה מחבילה מקומית

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

sudo sh -c "$(curl -fsSlL https://github.com/observiq/bindplane-agent/releases/latest/download/install_unix.sh)" install_unix.sh -f path_to_package

התקנה של RPM

מורידים את חבילת ה-RPM לארכיטקטורה שלכם מדף הגרסאות ומתקינים את החבילה באמצעות rpm. בדוגמה הבאה מוסבר איך להתקין את חבילת amd64:

sudo rpm -U ./observiq-otel-collector_v${VERSION}_linux_amd64.rpm
sudo systemctl enable --now observiq-otel-collector

מחליפים את VERSION בגרסה של החבילה שהורדתם.

התקנת DEB

מורידים את חבילת ה-DEB לארכיטקטורה שלכם מדף הגרסאות ומתקינים את החבילה באמצעות dpkg. בדוגמה הבאה מוסבר איך להתקין את חבילת amd64:

sudo dpkg -i --force-overwrite ./observiq-otel-collector_v${VERSION}_linux_amd64.deb
sudo systemctl enable --now observiq-otel-collector

מחליפים את VERSION בגרסה של החבילה שהורדתם.

הגדרת כלי האיסוף Bindplane

אחרי שמתקינים את האוסף, שירות observiq-otel-collector פועל ומוכן להגדרה.

אפשר להגדיר את האוסף באופן ידני או באמצעות שרת Bindplane.

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

קובץ התצורה של OTel Collector

ב-Linux, קובץ ההגדרות של כלי האיסוף נמצא במיקום /opt/observiq-otel-collector/config.yaml.

שירות ויומנים של OTel Collector

כברירת מחדל, נתוני האיסוף נרשמים ביומן C:\Program Files\observIQ OpenTelemetry Collector\log\collector.log.

יומן השגיאות הרגיל של תהליך האיסוף נמצא בכתובת C:\Program Files\observIQ OpenTelemetry Collector\log\observiq_collector.err.

ב-Linux, כדי להציג יומנים מהכלי לאיסוף נתונים, מריצים את הפקודה sudo tail -F /opt/observiq-otel-collector/log/collector.log.

פקודות נפוצות של שירות OTel Collector ב-Linux:

  • כדי להפסיק את שירות ה-OTel Collector, מריצים את הפקודה sudo systemctl stop observiq-otel-collector.

  • כדי להפעיל את שירות OTel Collector, מריצים את הפקודה sudo systemctl start observiq-otel-collector.

  • כדי להפעיל מחדש את שירות ה-OTel Collector, מריצים את הפקודה sudo systemctl restart observiq-otel-collector.

  • כדי להפעיל את שירות ה-OTel Collector בהפעלה, מריצים את הפקודה sudo systemctl enable observiq-otel-collector.

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

כשמשנים את ההגדרות, צריך להפעיל מחדש את שירות האיסוף כדי שהשינויים בהגדרות ייכנסו לתוקף (sudo systemctl restart observiq-otel-collector).

שימוש בקובץ תצורה לדוגמה שמוגדר כברירת מחדל

כברירת מחדל, קובץ התצורה של האוסף נמצא במיקום C:\Program Files\observIQ OpenTelemetry Collector\config.yaml.

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

  • פותחים את מסוף Google SecOps ועוברים אל SIEM Settings (הגדרות SIEM) > Collection Agent (סוכן איסוף).

מתאימים אישית את שני הקטעים הבאים בקובץ התצורה:

  • מקבל: מציין אילו יומנים האוסף צריך לאסוף ולשלוח ל-Google SecOps.
  • ‫Exporter: מציין את היעד שאליו האוסף שולח את היומנים. יש תמיכה בפורמטים הבאים של ייצוא:
    • ‫Google SecOps exporter: שולח יומנים ישירות אל Google SecOps ingestion API.
    • Google SecOps forwarder exporter: שולח יומנים ל-Google SecOps forwarder.
    • Cloud Logging exporter: שולח יומנים אל (Cloud Logging).

בכלי הייצוא, מבצעים את ההתאמות האישיות הבאות:

  • ‫customer_id: מספר הלקוח שלכם ב-Google SecOps.
  • ‫endpoint: נקודת הקצה האזורית של Google SecOps.

  • ‫creds: טוקן האימות.

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

  • ‫log_type: סוג היומן. מומלץ לבחור באפשרות WINDOWS_DNS בתור סוג היומן.

  • ‫ingestion_labels: תוויות הטמעה. התוויות האלה מזהות את היומנים ב-Google SecOps.

  • ‫namespace: מרחב שמות אופציונלי.

    לכל סוג יומן צריך להגדיר כלי לייצוא.

דוגמאות להגדרות של איסוף יומנים

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

שליחת אירועים של Windows ו-sysmon ישירות אל Google SecOps

מגדירים את הפרמטרים האלה בדוגמה:

הגדרה לדוגמה:

receivers:
  windowseventlog/sysmon:
    channel: Microsoft-Windows-Sysmon/Operational
    raw: true
  windowseventlog/security:
    channel: security
    raw: true
  windowseventlog/application:
    channel: application
    raw: true
  windowseventlog/system:
    channel: system
    raw: true

processors:
  batch:

exporters:
  chronicle/sysmon:
    endpoint: malachiteingestion-pa.googleapis.com
    creds: '{
  "type": "service_account",
  "project_id": "malachite-projectname",
  "private_key_id": "abcdefghijklmnopqrstuvwxyz123456789",
  "private_key": "-----BEGIN PRIVATE KEY-----abcdefg-----END PRIVATE KEY-----\n",
  "client_email": "account@malachite-projectname.iam.gserviceaccount.com",
  "client_id": "123456789123456789",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://oauth2.googleapis.com/token",
  "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
  "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/account%40malachite-projectname.iam.gserviceaccount.com",
  "universe_domain": "googleapis.com"
}' 
    log_type: 'WINDOWS_SYSMON'
    override_log_type: false
    raw_log_field: body
    customer_id: 'dddddddd-dddd-dddd-dddd-dddddddddddd'
  chronicle/winevtlog:
    endpoint: malachiteingestion-pa.googleapis.com
    creds: '{
  "type": "service_account",
  "project_id": "malachite-projectname",
  "private_key_id": "abcdefghijklmnopqrstuvwxyz123456789",
  "private_key": "-----BEGIN PRIVATE KEY-----abcdefg-----END PRIVATE KEY-----\n",
  "client_email": "account@malachite-projectname.iam.gserviceaccount.com",
  "client_id": "123456789123456789",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://oauth2.googleapis.com/token",
  "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
  "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/account%40malachite-projectname.iam.gserviceaccount.com",
  "universe_domain": "googleapis.com"
}'
    log_type: 'WINEVTLOG'
    override_log_type: false
    raw_log_field: body
    customer_id: 'dddddddd-dddd-dddd-dddd-dddddddddddd'

service:
  pipelines:
    logs/sysmon:
      receivers: [windowseventlog/sysmon]
      processors: [batch]
      exporters: [chronicle/sysmon]
    logs/winevtlog:
      receivers: 
        - windowseventlog/security
        - windowseventlog/application
        - windowseventlog/system
      processors: [batch]
      exporters: [chronicle/winevtlog]

שליחת אירועי Windows ו-syslog ישירות אל Google SecOps

מגדירים את הפרמטרים האלה בדוגמה:

הגדרה לדוגמה:

receivers:
    tcplog:
      listen_address: "0.0.0.0:54525"
    windowseventlog/source0__application:
        attributes:
            log_type: windows_event.application
        channel: application
        max_reads: 100
        poll_interval: 1s
        raw: true
        start_at: end
    windowseventlog/source0__security:
        attributes:
            log_type: windows_event.security
        channel: security
        max_reads: 100
        poll_interval: 1s
        raw: true
        start_at: end
    windowseventlog/source0__system:
        attributes:
            log_type: windows_event.system
        channel: system
        max_reads: 100
        poll_interval: 1s
        raw: true
        start_at: end
exporters:
    chronicle/chronicle_w_labels:
        compression: gzip
        creds: '{ json blob for creds }'
        customer_id: <customer_id>
        endpoint: malachiteingestion-pa.googleapis.com
        ingestion_labels:
            env: dev
        log_type: <applicable_log_type>
        namespace: testNamespace
        raw_log_field: body
service:
    pipelines:
        logs/source0__chronicle_w_labels-0:
            receivers:
                - windowseventlog/source0__system
                - windowseventlog/source0__application
                - windowseventlog/source0__security
            exporters:
                - chronicle/chronicle_w_labels
        logs/source1__chronicle_w_labels-0:
            receivers:
                - tcplog
            exporters:
                - chronicle/chronicle_w_labels

שליחת אירועים של Windows ו-syslog למעביר של Google SecOps

מגדירים את הפרמטרים האלה בדוגמה:

הגדרה לדוגמה:

receivers:
tcplog:
    listen_address: "0.0.0.0:54525"
    windowseventlog/source0__application:
        attributes:
            log_type: windows_event.application
        channel: application
        max_reads: 100
        poll_interval: 1s
        raw: true
        start_at: end
    windowseventlog/source0__security:
        attributes:
            log_type: windows_event.security
        channel: security
        max_reads: 100
        poll_interval: 1s
        raw: true
        start_at: end
    windowseventlog/source0__system:
        attributes:
            log_type: windows_event.system
        channel: system
        max_reads: 100
        poll_interval: 1s
        raw: true
        start_at: end
exporters:
    chronicleforwarder/forwarder:
        export_type: syslog
        raw_log_field: body
        syslog:
            endpoint: 127.0.0.1:10514
            transport: udp
service:
    pipelines:
        logs/source0__forwarder-0:
            receivers:
                - windowseventlog/source0__system
                - windowseventlog/source0__application
                - windowseventlog/source0__security
            exporters:
                - chronicleforwarder/forwarder
        logs/source1__forwarder-0:
            receivers:
                - tcplog
            exporters:
                - chronicleforwarder/forwarder

שליחת syslog ישירות אל Google SecOps

מגדירים את הפרמטרים האלה בדוגמה:

הגדרה לדוגמה:

receivers:
  tcplog:
    listen_address: "0.0.0.0:54525"

exporters:
    chronicle/chronicle_w_labels:
        compression: gzip
        creds: '{ json blob for creds }'
        customer_id: <customer_id>
        endpoint: malachiteingestion-pa.googleapis.com
        ingestion_labels:
            env: dev
        log_type: <applicable_log_type>
        namespace: testNamespace
        raw_log_field: body
service:
    pipelines:
        logs/source0__chronicle_w_labels-0:
            receivers:
                - tcplog
            exporters:
                - chronicle/chronicle_w_labels

איסוף אירועים של Windows מרחוק ושליחה שלהם ישירות ל-Google SecOps

מגדירים את הפרמטרים האלה בדוגמה:

  • windowseventlogreceiver
    • username
    • password
    • server
  • chronicleexporter
    • namespace
    • ingestion_labels
    • log_type
    • customer_id
    • creds

הגדרה לדוגמה:

receivers:
    windowseventlog/system:
        channel: system
        max_reads: 100
        start_at: end
        poll_interval: 10s
        raw: true
        remote:
            username: "username"
            password: "password"
            server: "remote-server"
    windowseventlog/application:
        channel: application
        max_reads: 100
        start_at: end
        poll_interval: 10s
        raw: true
        remote:
            username: "username"
            password: "password"
            server: "server-ip"
    windowseventlog/security:
        channel: security
        max_reads: 100
        start_at: end
        poll_interval: 10s
        raw: true
        remote:
            username: "username"
            password: "password"
            server: "server-ip"
exporters:
    chronicle/chronicle_w_labels:
        compression: gzip
        creds: '{ json blob for creds }'
        customer_id: <customer_id>
        endpoint: malachiteingestion-pa.googleapis.com
        ingestion_labels:
            env: dev
        log_type: WINEVTLOG
        namespace: testNamespace
        raw_log_field: body
service:
    pipelines:
        logs/source0__chronicle_w_labels-0:
            receivers:
                - windowseventlog/system
                - windowseventlog/application
                - windowseventlog/security
            exporters:
                - chronicle/chronicle_w_labels

שליחת נתונים ל-Cloud Logging

מגדירים את הפרמטר credentials_file בדוגמה.

הגדרה לדוגמה:

exporters:
  googlecloud:
    credentials_file: /opt/observiq-otel-collector/credentials.json

שליחת שאילתות למסד נתונים של SQL ושליחת התוצאות ל-Google SecOps

מגדירים את הפרמטרים האלה בדוגמה:

הגדרה לדוגמה:

receivers:
  sqlquery/source0:
    datasource: host=localhost port=5432 user=postgres password=s3cr3t sslmode=disable
    driver: postgres
    queries:
      - logs:
          - body_column: log_body
        sql: select * from my_logs where log_id > $$1
        tracking_column: log_id
        tracking_start_value: "10000"
processors:
  transform/source0_processor0__logs:
    error_mode: ignore
    log_statements:
      - context: log
        statements:
          - set(attributes["chronicle_log_type"], "POSTGRESQL") where true
exporters:
  chronicle/chronicle_sql:
    compression: gzip
    creds: '{
  "type": "service_account",
  "project_id": "malachite-projectname",
  "private_key_id": "abcdefghijklmnopqrstuvwxyz123456789",
  "private_key": "-----BEGIN PRIVATE KEY-----abcdefg-----END PRIVATE KEY-----\n",
  "client_email": "account@malachite-projectname.iam.gserviceaccount.com",
  "client_id": "123456789123456789",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://oauth2.googleapis.com/token",
  "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
  "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/account%40malachite-projectname.iam.gserviceaccount.com",
  "universe_domain": "googleapis.com"
}' 
    customer_id: customer_id
    endpoint: malachiteingestion-pa.googleapis.com
    log_type: POSTGRESQL
    namespace: null
    raw_log_field: body
    retry_on_failure:
      enabled: false
    sending_queue:
      enabled: false
service:
  pipelines:
    logs/source0_chronicle_sql-0:
      receivers:
        - sqlquery/source0
      processors:
        - transform/source0_processor0__logs
      exporters:
        - chronicle/chronicle_sql

הסרת יומנים שתואמים לביטוי רגולרי

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

כדי להשליך יומנים שתואמים לביטוי רגולרי, מוסיפים מעבד מסוג filter/drop-matching-logs-to-Chronicle להגדרה. המעבד הזה משתמש בפונקציה IsMatch כדי להעריך את גוף היומן ביחס לביטוי הרגולרי. אם הפונקציה מחזירה true, היומן מושמט.

הגדרת הדוגמה הבאה משמיטה יומנים שמכילים את המחרוזות <EventID>10</EventID> או <EventID>4799</EventID> בגוף היומן.

אתם יכולים להתאים אישית את הביטוי הרגולרי כך שיתאים לכל תבנית שאתם צריכים. הפונקציה IsMatch משתמשת בתחביר של ביטויים רגולריים מסוג RE2.

הגדרה לדוגמה:

processors:
    filter/drop-matching-logs-to-Chronicle:
        error_mode: ignore
        logs:
            log_record:
                - (IsMatch(body, "<EventID>10</EventID>")) or (IsMatch(body, "<EventID>4799</EventID>"))

בדוגמה הבאה, המעבד מתווסף לצינור העיבוד באותה הגדרה:

service:
  pipelines:
    logs/winevtlog:
      receivers: 
        - windowseventlog/security
        - windowseventlog/application
        - windowseventlog/system
      processors: 
      - filter/drop-matching-logs-to-Chronicle # Add this line
      - batch
      exporters: [chronicle/winevtlog]

תפעול ותחזוקה של Bindplane

בקטע הזה מתוארות פעולות שגרתיות של תפעול ותחזוקה.

אימות הגדרת OTel

כדי ללמוד איך לאמת את ההגדרה של Bindplane OTel, אפשר לעיין במאמר בנושא OTelBin.

עדכוני גרסה של כלי האיסוף

‫Bindplane יכול לבצע בדיקה חוזרת של bindplane-otel-collector/releases כדי לזהות גרסאות חדשות של כלי האיסוף. התכונה הזו היא אופציונלית.

כדי להשבית את הסקר ב-GitHub, צריך להגדיר את agentVersions.syncInterval ל-0 בהגדרות של Bindplane:

agentVersions:
syncInterval: 0

גיבוי ותוכנית התאוששות מאסון (DR)

מידע על גיבוי ותוכנית התאוששות מאסון באמצעות Bindplane זמין במאמר משאבי Bindplane.

גיבוי ותוכנית התאוששות מאסון (DR) ב-PostgreSQL

מידע על גיבוי ושחזור מאסון ב-PostgreSQL באמצעות Bindplane זמין במסמכי PostgreSQL.

גיבוי ותוכנית התאוששות מאסון (DR) ב-BBolt

מידע על גיבוי ותוכנית התאוששות מאסון (DR) ב-BBolt (יצא משימוש) באמצעות Bindplane זמין במסמכי BBolt Store.

חוסן וניסיון חוזר

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

מידע נוסף זמין במאמר בנושא חוסן של כלי האיסוף.

הפחתת נפח היומן באמצעות מסנן החומרה

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

שילובים של Bindplane עם אוספים של צד שלישי

למרות ש-Bindplane יעיל יותר כשמשתמשים ב-collector של Bindplane לאיסוף בקצה הרשת, ברוב המקרים אפשר להשתמש ב-Bindplane במסגרת התשתית הקיימת. לדוגמה, אם אתם כבר משתמשים ב-Fluent Bit או ב-Splunk Universal Forwarders, אתם יכולים להמשיך לעשות זאת.

שילוב של Bindplane עם Splunk

כדי לקבל מידע על Splunk עם Bindplane, אפשר לעיין במאמרים הבאים:

שילובים של Bindplane עם כלי איסוף אחרים של צד שלישי

מידע נוסף על שילובים של Bindplane עם כלי איסוף של צד שלישי זמין במאמר Connecting Other OpenTelemetry Collectors Using the OpAMP Extension.

ניטור שקט של מארחים

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

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

שדרוג Bindplane ב-Linux

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

מעקב אחרי Bindplane

מידע נוסף על מעקב אחרי Bindplane זמין במאמר מעקב אחרי Bindplane.

מעקב אחרי Kubernetes ב-Bindplane

מידע על מעקב אחר Kubernetes ב-Bindplane זמין במאמר מעקב אחר Kubernetes.

מסמכים נוספים

מידע נוסף על Bindplane (לשעבר observIQ) זמין במקורות המידע הבאים:

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