פריסת סוכן 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 server.

    הרכיב הזה נקרא גם מסוף הניהול של צינור הנתונים (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 ו-Google Unified Security‏ (GUS)

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

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

הורדת מפתח הרישיון של Bindplane Enterprise

לקוחות Google SecOps Enterprise Plus ו-GUS יכולים להוריד את מפתח הרישיון של Bindplane Enterprise (מהדורת Google) ישירות ממסוף הפלטפורמה:

  1. במסוף Google SecOps, עוברים אל SIEM Settings (הגדרות SIEM) > Collection Agents (סוכני איסוף).
  2. בכרטיס Bindplane License (רישיון Bindplane), לוחצים על Download License (הורדת רישיון) כדי לשמור את קובץ מפתח הרישיון.
  3. מחילים את מפתח הרישיון שהורד על ההתקנה של Bindplane Server. פרטים נוספים מופיעים במאמר בנושא החלת רישיון Bindplane.

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

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

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

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

שרת Bindplane

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

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

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

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

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

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

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

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

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

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

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

  • שליטה בפקודות של כלי האיסוף באמצעות 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 ‫8GB postgres
‫60,001-125,000 5 1 2 ‫8GB postgres
‫125,001-250,000 10 2 2 ‫8GB postgres

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

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

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

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

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

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

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

Telemetry throughput Logs/second אספנים
‫5GB/m 250,000 2
‫‎10 GB/m 500,000 3
‫20GB לחודש 1,000,000 5
‫100GB/m ‫5,000,000 25

הקצאת יתר של צי ה-Collectors כדי להבטיח עמידות בפני תקלות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

‫Postgres ל-HA

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

‫Prometheus לזמינות גבוהה

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

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

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

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

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

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

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

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

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

מספר ליבות המעבד והזיכרון הזמין בדרך כלל מגבילים את הביצועים של מערכות אחסון קצה עורפיות של 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 Use Case Demos ולבחור באפשרות Google SecOps Configuration.

שימוש בשרת 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 Collector

בקטע הזה מוסבר איך להתקין את 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 בגרסה של החבילה שהורדתם.

הגדרת ה-collector של Bindplane

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

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

אם אתם מגדירים את האוסף באופן ידני, אתם צריכים לעדכן את הפרמטרים של רכיב ה-exporter כדי לוודא שהאוסף מאומת ב-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: שולח יומנים ישירות אל Google SecOps API לצריכת נתונים.
    • Google SecOps forwarder exporter: שולח יומנים ל-Google SecOps forwarder.
    • ייצוא ל-Cloud Logging: שולח יומנים ל-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)

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

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

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

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

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

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

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

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

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

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

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

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

שילוב של Bindplane עם Splunk

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

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

מידע נוסף על שילובים של Bindplane עם כלי איסוף של צד שלישי זמין במאמר חיבור של כלי איסוף אחרים של OpenTelemetry באמצעות התוסף OpAMP.

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

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

למידע על שימוש ב-Bindplane לצורך מעקב שקט אחרי מארחים:

שדרוג Bindplane ב-Linux

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

מעקב אחר Bindplane

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

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

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

מסמכי תיעוד נוספים

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

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