אופטימיזציה של נפח ההטמעה

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

המדריך מיועד למהנדסי אבטחה, לאנליסטים של Google SecOps ולאדמינים של הענן שמנהלים את ההטמעה של יומנים ב-Google SecOps.

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

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

חשוב לוודא שיש לכם את הפריטים הבאים:

  • תפקיד בניהול זהויות והרשאות גישה (IAM): או התפקיד המוגדר מראש Admin של Chronicle API‏ (roles/chronicle.admin) או תפקיד בהתאמה אישית שכולל אחת מההרשאות הבאות:
    • chronicle.logProcessingPipelines.*
    • chronicle.logTypes.get
    • chronicle.logTypes.list
    • chronicle.feeds.get
    • chronicle.feeds.list
    • chronicle.logs.list
  • גרסת Bindplane: נדרשת גרסה 1.96.4 ואילך של מסוף Bindplane Server.
  • ב-Bindplane Cloud, יש תמיכה באיחוד שירותי אימות הזהויות של עומסי עבודה (WIF) לצורך אימות. פריסות של Bindplane באירוח עצמי דורשות פרטי כניסה של מפתח JSON לחשבון שירות.
  • גישה ל-Bindplane Management Console או לממשקי ה-API של צינור הנתונים של Google SecOps כדי להגדיר את צמתי העיבוד.
  • מזהים את השדות, סוגי היומנים והתנאים המדויקים שנדרשים להגדרת מעבדי סינון, שינוי וצנזור להפחתת נפח.
  • מגדירים את מקורות הנתונים של צינור עיבוד הנתונים בהתאם לסוגים הספציפיים של יומנים, למזהי האוספים (במקורות של Bindplane) או לשמות הפידים (בפידים של נתונים) שמשויכים לשיטות ההטמעה.
  • אם אתם מבצעים הטמעה של Google Cloud יומנים, אתם צריכים להגדיר את המסננים הנדרשים לייצוא של Logging כדי להטמיע סינון במעלה הזרם, וכך לחסוך בעלויות ככל האפשר לפני שהנתונים מגיעים לצינור SecOps.
  • הסבר על נתוני היומן:
    • זיהוי יומנים עם נפח גבוה או ערך נמוך: ניתוח מדדי ההטמעה הנוכחיים כדי לזהות אילו סוגים ומקורות של יומנים תורמים הכי הרבה לנפח ולעלות. מידע נוסף מופיע במאמר סקירה כללית על מדדי הטמעה.
    • קובעים את קריטריוני הסינון: קובעים את השדות, הערכים, הדפוסים (regex) או התנאים הספציפיים שמזהים באופן מהימן את היומנים שצריך להשליך, לשנות או להסתיר.
    • הכירו את שיטות ההטמעה שלכם: חשוב להבין איך כל מקור יומן יעד נטמע (ישיר, Bindplane, פיד, API), כי זה משפיע על אופן ההגדרה של זרם הפייפליין.

מונחים חשובים

  • צינורות לעיבוד נתונים: יכולת שמשמשת לסינון, לשינוי ולעריכה של נתוני יומן כשהם מגיעים, לפני שהם נשמרים ומאונדקסים.
  • סינון: היכולת העיקרית לאופטימיזציה של נפח הנתונים, שבאמצעותה מגדירים תנאים להשמטה סלקטיבית של אירועים שלא נדרשים לניתוח אבטחה.
  • שינוי: יכולת שמשמשת לשינוי פורמטים של יומנים כדי לשפר את השימושיות, למשל הסרת שמות דומיין שמוגדרים במלואם (FQDN) או מחיקת שדות מפורטים באירועים.
  • Redact: אפשרות להסתיר או להסיר לחלוטין מידע רגיש מיומנים לפני שהם נשמרים, כדי לעזור בשמירה על תאימות ופרטיות.
  • סוכן Bindplane: שיטה להוספת יומנים שנאספו ממערכות מקומיות או ממערכות ענן אחרות.
  • פידים: שיטה להטמעת נתונים שמגיעים ממקורות כמו Cloud Storage,‏ Amazon S3 או ממשקי API של צד שלישי.
  • ממשקי API להטמעה: שיטה לשליחת נתוני יומן מותאמים אישית, שמאפשרת סינון בצד השרת באמצעות צינורות לעיבוד נתונים.
  • סינון במעלה הזרם: השיטה המומלצת היא סינון של יומני Google Cloud הרישום במקור באמצעות מסנני ייצוא של Logging, כדי לחסוך בעלויות בצורה אופטימלית.
  • Streams: זרם נתונים ספציפי, שמוגדר לפי סוג היומן ומקור ההטמעה (כמו פיד או API), ומשמש כקלט לצינור לעיבוד נתונים.
  • צומת עיבוד: רכיב בצינור עיבוד נתונים שמכיל מעבד אחד או יותר (פעולות סינון, שינוי או הסתרה) שמבצעים שינויים בנתונים באופן עקבי.
  • יעד: נקודת הקצה של צינור עיבוד הנתונים, בדרך כלל מופע Google SecOps שאליו נשלחים נתונים מעובדים לצורך הטמעה וניתוח סופיים.

שימוש בצינורות עיבוד נתונים לאופטימיזציה

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

יכולות עיקריות

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

התאמה אוניברסלית

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

  • יומנים מובנים ב-Google Cloud
  • יומנים שנאספו באמצעות סוכן Bindplane
  • נתונים שמיובאים באמצעות פידים
  • יומנים בהתאמה אישית שנשלחים דרך ממשקי ה-API של ההטמעה

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

הטמעה של סינון באמצעות צינורות עיבוד נתונים

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

אפשר להגדיר ולנהל צינורות לעיבוד נתונים דרך מסוף הניהול של Bindplane או באמצעות ממשקי ה-API הציבוריים של Google SecOps Data Pipeline. הם מאפשרים להגדיר זרמי נתונים (קלט), להגדיר צמתי מעבד (Filter,‏ Transform,‏ Redact) ולנהל את הפריסה של צינור עיבוד הנתונים.

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

שלב 2: הגדרת המעבדים לסינון

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

  • תנאים: הערכה של שדות או מאפיינים בנתוני היומן.
  • ביטויים רגולריים: התאמת תבניות בהודעת היומן הגולמית.
  • דוגמה ל-OTTL: דוגמה להתבטאות היא set(attributes["labels.myLabel.value"], "myValue").

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

שלב 3: אסטרטגיות סינון ספציפיות לשיטה

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

Google Cloud logs

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

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

Bindplane Agent

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

פידים של נתונים

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

שיטות להעברת נתונים באמצעות Chronicle API

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

שיטות מומלצות

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

אימות ובדיקה

  • בדיקה: מומלץ לבדוק את המסננים בסביבה שאינה סביבת ייצור או עם קבוצת משנה קטנה של נתונים.
  • אימות מסננים: אפשר להשתמש בתכונות הבדיקה בכלי לעריכת צינורות הנתונים ב-Bindplane Console. כך תוכלו להזין יומנים לדוגמה ולראות את הפלט אחרי החלת המעבדים, כדי לוודא שהמסננים פועלים כמצופה.
  • מעקב אחר ההטמעה: אחרי פריסת צינורות עיבוד הנתונים, כדאי לעקוב אחר לוחות הבקרה של ההטמעה ב-Google SecOps כדי לראות את ההשפעה על נפח הנתונים והעלויות. מידע נוסף מופיע במאמר סקירה כללית על מדדי הטמעה.
  • הצגת ההגדרות: אפשר לראות את כל ההגדרות בממשק המשתמש של Google SecOps בקטע SIEM Settings > Data Processing (הגדרות SIEM > עיבוד נתונים).
  • ניהול חיצוני: אתם יכולים לחפש הגדרות וללחוץ על Open in Bindplane (פתיחה ב-Bindplane) כדי לעבור ישירות למסוף Bindplane לניהול מתקדם.

מגבלות

  • מגבלות שירות: ביצועים עלולים להיפגע או להיות כפופים למגבלות אם יש ביטויים רגולריים מורכבים מדי או מספר גדול של מעבדים לכל צינור עיבוד נתונים. כדאי לעיין במגבלות של Google SecOps במגבלות השירות.
  • חבילות Google SecOps: חשוב להכיר את התכונות והיכולות בחבילת Google SecOps שלכם. מידע נוסף זמין במאמר בנושא חבילות Google SecOps.
  • אפשרות שימוש חוזר: למרות שצינור עיבוד הנתונים לפריסה הוא כלי רב עוצמה, יכול להיות שאי אפשר יהיה להשתמש בתצורה שלו עבור סוג יומן או מקור אחד גם עבור סוג יומן או מקור אחר בלי לבצע שינויים.
  • ‫Maximum Processors: (מספר המעבדים המקסימלי): אפשר להגדיר עד 10 מעבדים לכל צינור.
  • ביצועים של ביטויים רגולריים: מומלץ להימנע מהתאמה מוגזמת של ביטויים רגולריים, כי היא עלולה לגרום לפריסה או ליצירה של צינור עיבוד נתונים להיכשל בגלל פסק זמן. מומלץ לנתח את הנתונים ל-JSON ולסנן לפי שדות ספציפיים.
  • הגבלה על שיוך של זרם: אפשר ליצור צינורות שונים עבור פידים שונים מאותו סוג יומן, אבל אי אפשר לשייך את אותה הגדרה של זרם (למשל, אותו פיד או אותו סוג יומן כללי) ליותר מצינור פעיל אחד. הגדרת סוג יומן לכל שיטות ההטמעה פועלת כהגדרה כללית ומונעת הגדרה של צינורות אחרים לפידים ספציפיים של סוג היומן הזה.

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