ארכיטקטורה וזרימות נתונים ב-Google SecOps

נתמך ב:

Google SecOps

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

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

במסמך הזה מתוארת ארכיטקטורת ה-Google SecOps וזרימות הנתונים, כולל הטמעה, נורמליזציה של UDM, זיהוי איומים ב-YARA-L ותגובה אוטומטית.

שילוב של מודיעין, ניתוח ותגובה

‫Google SecOps מאחד יכולות של פעולות אבטחה שהיו נפרדות בעבר. הפלטפורמה משלבת ניתוח SIEM ותזמור, אוטומציה ותגובה (SOAR) לאבטחה. בנוסף, הוא מטמיע מודיעין איומי סייבר מ-Google Threat Intelligence ומ-VirusTotal, יחד עם יכולות מבוססות-AI גנרטיבי שמבוססות על Gemini, ישירות בתהליכי עבודה של חקירה וזיהוי.

סקירה כללית על ארכיטקטורת הפלטפורמה

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

ההקשר של המערכת

‫Google SecOps משמש כמישור הפעלה מרכזי לסביבת האבטחה שלכם, ומנהל נתונים בשלושה שלבים עיקריים:

• קלט: קליטת נתוני טלמטריה מסביבות היברידיות, כולל כלי איסוף מקומיים (כמו BindPlane agent), ממשקי API של ספקי שירותי ענן ומחברים ישירים של תוכנה כשירות (SaaS) מצד שלישי.
• ליבת העיבוד: מבצעת נרמול של טלמטריה גולמית לסכימת UDM מובנית, מעריכה אירועים באמצעות מנוע הזיהוי YARA-L ומתזמנת תהליכי עבודה באמצעות מנוע ניהול המקרים של SOAR.
• תפוקות: מספקת לאנליסטים מודיעין אבטחה פרקטי ותובנות ממיון ראשוני מבוסס-AI, ובמקביל שולחת פקודות אוטומטיות לבידוד חולשות בחזרה לסביבות היעד באמצעות ממשקי API וסוכנים מרוחקים.

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

היתרונות של התשתית

יתרון מרכזי בארכיטקטורה של Google SecOps הוא מודל אחסון הנתונים בשימוש נפוץ (hot storage) המאוחד. בארכיטקטורות מדור קודם, נתוני טלמטריה ישנים מועברים לאחסון נתונים בשימוש נדיר (cold storage), מה שמאט את השאילתות או מחייב הפעלה ידנית של אחזור נתונים. לעומת זאת, ב-Google SecOps כל הטלמטריה שנקלטת נשמרת במצב פעיל שאפשר לחפש בו באינדקס למשך עד 12 חודשים. העיצוב הזה מאפשר להריץ שאילתות על נתונים היסטוריים של שנה שלמה באותה רמת ביצועים כמו שאילתות על נתונים מהשעה האחרונה.

פייפליין של איסוף נתונים ונרמול

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

ארכיטקטורה של אוסף

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

• מקבצי נתונים: מקבצי נתונים מבוססי-סוכן (כמו סוכן BindPlane או סוכני OpenTelemetry) שנפרסים ברשתות מקומיות כדי לצבור נתוני syslog ונתוני מנות. המאגרי נתונים של כלי האיסוף מאחסנים את נתוני הטלמטריה באופן זמני, דוחסים אותם ומצפינים אותם בשכבת התעבורה (TLS) לפני שהם מועברים ל-Google SecOps.
• ממשקי API להטמעת נתונים: נקודות קצה ל-API בארכיטקטורת REST שמטמיעות נתוני טלמטריה מובנים ולא מובנים משירותי ענן, מאפליקציות בהתאמה אישית ומפייפליינים בלי שרת (serverless).
• שילובים עם צד שלישי: מחברים מובנים מבוססי-משיכה שמחלצים יומנים, התראות ונתוני ספריות ישירות מפלטפורמות SaaS חיצוניות ומממשקי API בענן (כמו Microsoft 365 או Microsoft Entra ID).

תהליך של צינור לאיסוף ולהכנה של נתונים

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

סקירה כללית על סכימת Unified Data Model

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

ארכיטקטורת סכימת UDM

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

• מטא-נתונים: הקשר לגבי אירוע היומן עצמו, כולל חותמת הזמן של האירוע, זמן ההטמעה, שם המוצר של הספק וסוג האירוע.
• הגורם העיקרי: הישות הפועלת שהתחילה את הפעילות (כמו המשתמש המקורי, המארח, כתובת ה-IP או התהליך).
• יעד: הישות שהפעילות משפיעה עליה ישירות (למשל קובץ היעד, מארח היעד או חשבון המשתמש).
• מקור, מתווך וצופה: משתתפים משניים ברשת (כמו שרתי proxy להעברה, חומות אש או קפיצות ניתוב) שמעורבים בעסקה.
• רשת: מאפייני פרוטוקול רשת וארטיפקטים של טרנזקציות (כולל פרוטוקולי אפליקציות, שאילתות DNS ופרטים של בקשות HTTP).
• תוצאת האבטחה: התוצאה של הפעולה או חומרת הבעיה שדווחו על ידי מכשיר האבטחה (למשל ALLOWED, BLOCKED או QUARANTINED).
• תוספים: שדות מותאמים אישית וצמדים של מפתח/ערך שספציפיים לספק מסוים ולא נכללים בסכימה הבסיסית הרגילה. פרטים על מיפוי הגדרות ופיתוח מנתח מופיעים במאמרים הגדרת מנתחים מותאמים אישית ושדות חשובים ב-UDM.

דיאגרמת מחלקות של UDM

התרשים הבא מציג תוכנית מבנית של UDM.

ארכיטקטורת החיפוש

‫Google SecOps מספקת מנגנוני חיפוש מתקדמים שמותאמים לתהליכי עבודה שונים של חקירה. אתם יכולים לשלוח שאילתות על טלמטריה מנורמלת באחסון נתונים בשימוש נפוץ (hot storage), לבצע התאמת תבניות ליומנים גולמיים שלא עברו ניתוח או לחפש נתוני מקרים מובְנים. הנחיות לאופטימיזציה זמינות במאמר שיטות מומלצות לחיפוש ב-UDM.

בטבלה הבאה מפורטות היכולות העיקריות של החיפוש שזמינות בפלטפורמה:

סוג החיפוש	פונקציה ארכיטקטונית
חיפוש ב-UDM	מנוע החיפוש המובנה הראשי שמבצע שאילתות על אירועי UDM שעברו נורמליזציה ונוספו לאינדקס בחלון הפעיל של 12 חודשים. הוא מאפשר סינון, צבירה ומתאם של נתונים בכמה שדות ממקורות שונים של יומנים.
סריקת יומן גולמי	סריקה של מחרוזות הטקסט המקוריות שלא עברו ניתוח ביומנים שהועברו. היכולת הזו תומכת בביטויים רגולריים (regex) ובחיפושים של מחרוזות משנה של ארטיפקטים ופרמטרים מותאמים אישית שלא ממופים לתחביר ספציפי של UDM.
חיפוש בשפה טבעית	הוא משתמש ב-Gemini AI כדי לתרגם שאלות בשפה טבעית ישירות לתחביר רשמי של חיפוש UDM, וכך מאיץ את תהליכי העבודה של כתיבת שאילתות וחקירה.
חיפוש תיקים	מנוע חיפוש ייעודי בשכבת התגובה שמבצע שאילתות בתיקי חקירה, בהתראות, בתוכניות פעולה ובמטא-נתונים של ישויות עם הערות במסד הנתונים של SOAR.

זיהוי איומים והתמודדות עם איומים

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

ארכיטקטורת משפך הזיהוי

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

1. קליטה ונרמול: יומנים גולמיים נקלטים באופן רציף ומעוצבים במבני אירועים סטנדרטיים של UDM.
2. העשרה: המערכת מעשירה את האירועים באופן דינמי באמצעות מיפויים של שמות חלופיים, נתוני נכסים הקשריים ומודיעין איומי סייבר גלובלי ממקורות כמו Google Threat Intelligence.
3. הערכת זיהוי: מנוע YARA-L 2.0 עם שמירת מצב מעריך אירועים מועשרים בהשוואה לכללי התנהגות ואיומים בחלונות זמן מורחבים. הנחיות לאופטימיזציה של כללים מפורטות במאמר בנושא שיטות מומלצות ל-YARA-L.
4. תעדוף וקיבוץ: זיהויים תואמים מצטברים להתראות, מקבלים ציוני סיכון דינמיים ומקובצים למקרים מאוחדים.

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

תיקון אוטומטי ולולאת משוב

צינור הזיהוי והתגובה משלב הערכת כללים עם שמירת מצב, עם טריאז' ובידוד אוטומטיים:

1. הערכה מתמשכת: הוספנו לזרמי הטלמטריה של UDM את מנוע הזיהוי YARA-L 2.0 עם שמירת מצב.
2. יצירת אירוע וטריאז מבוסס-AI: כשמתקיים תנאי של כלל, Google SecOps יוצר התראה ופותח אירוע. סוכן לבדיקת פניות ולחקירה מבוסס-AI מבצע חיפושים דינמיים ובדיקות של מודיעין איומי סייבר כדי להעריך את הממצאים.
3. הפעלה אוטומטית של תוכנית פעולה: אם תהליך הטריאז' של ה-AI מאשר שמדובר בתוצאה חיובית אמיתית, הפלטפורמה מפעילה תוכניות פעולה אוטומטיות לתגובה (למשל, בידוד של נקודת קצה או השעיה של חשבון משתמש באמצעות סוכנים מרוחקים). אם הפנייה מסווגת כחיובי כוזב, היא נסגרת באופן אוטומטי.
4. התאמה מתמשכת: תוצאות התיקון וההכרעות של אנליסטים מועברות בחזרה כדי לשפר את ספי הזיהוי ולצמצם את מספר התוצאות החיוביות הכוזבות בעתיד.

שכבת זיהוי איומים

מנוע YARA-L 2.0 מעריך טלמטריה נכנסת של UDM באמצעות צינור סטרימינג רב-שלבי כדי לזהות חריגות התנהגותיות ודפוסי תקיפה מרובי-אירועים בחלונות זמן מורחבים. אפשר גם ליצור ולשפר כללי YARA-L באמצעות Gemini.

מחזור החיים של העיבוד של כל כלל YARA-L כולל חמישה שלבי הערכה נפרדים:

1. הטמעה (Ingest): אירועי UDM מועשרים מוזנים לצינור עיבוד הנתונים של הערכת הזיהוי בזמן אמת.
2. סינון (Filter): המערכת מעריכה את האירועים הנכנסים בהתאם לקריטריונים של האירועים שמוגדרים בכלל (בקטע events). אירועים שלא תואמים נמחקים, ואירועים תואמים עוברים להערכה עם שמירת מצב.
3. התאמת חלונות (Window): אירועים תואמים מקובצים לפי מפתחות קורלציה שצוינו, בתוך חלון זמן מוגדר (החל משניות ועד 12 חודשים). המנוע עוקב אחרי כמה טיימרים במקביל עם שמירת מצב (TimerStart עד TimerEnd) ככל שהאירועים מצטברים.
4. הערכת התנאים (Condition): כשחלון ההתאמה נסגר או מופעל, המנוע מעריך את דרישות הסף ואת הביטויים המתמטיים שמוגדרים בקטע condition של הכלל (כמו ספירת אירועים, ספי נפרדים או הצלבות נתונים).
5. הפעלה (Trigger): אם התנאי מחזיר את הערך True, המנוע יוצר זיהוי, מפעיל התראה ופותח או מעדכן כרטיס תמיכה בשכבת התגובה. אם הערך הוא False, המצב נמחק בלי להפעיל התראה.

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

הדיאגרמה הבאה ממחישה את מחזור החיים של הרצת כלל.

ארכיטקטורת התגובה והרצה מרחוק

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

תזמור, אוטומציה וחקירה

שכבת התגובה כוללת כלים ייעודיים שנועדו לייעל את תהליכי העבודה של מרכז האבטחה (SOC) בתחומים של חקירה, ניהול בקשות תמיכה ואוטומציה של Playbook:

• ניהול בקשות תמיכה: קיבוץ התראות קשורות לבקשות תמיכה מאוחדות, מיון וסינון של תורים לטיפול באירועים, הקצאת משימות ושיתוף פעולה בחקירות עם מעקב מלא אחר ביקורות.
• ‫Playbook designer: כלי ליצירת Playbook לתגובה אוטומטית באמצעות בד ציור ויזואלי ללא קוד, עם פעולות שילוב מוכנות מראש.
• סביבת פיתוח משולבת (IDE): אפשר להשתמש בIDE המובנה מבוסס-הקוד כדי לכתוב סקריפטים מותאמים אישית ב-Python, לשנות שילובי פעולות קיימים ולנפות באגים בתהליכי עבודה מורכבים של אוטומציה.
• תצוגות חקירה וכלי חקירת גרפים: המחשה של נתיבי התקפה ויחסי ישויות באמצעות תצוגות חקירה מבוססות-גרפים. סיכומי ישויות ייעודיים (כמו תצוגות של נכס, כתובת IP, גיבוב, דומיין ומשתמש) מציגים באופן מיידי אירועים רלוונטיים בציר הזמן.
• מרכזי בקרה ודיווח: אפשר לעקוב אחרי מדדים תפעוליים של SOC, עומס העבודה של האנליסטים והזמן הממוצע לתגובה (MTTR) באמצעות מרכזי בקרה מוכנים מראש או ווידג'טים של דוחות בהתאמה אישית.

ארכיטקטורת רכיבים של SOAR

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

ארכיטקטורה של סוכן מרוחק

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

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

1. הפעלת משימה: כשפעולה ב-Playbook דורשת ביצוע מקומי, Google SecOps מפרסם את ההוראה בתור מאובטח של מפרסם שמתארח ב- Google Cloud.
2. תשאול אסינכרוני: הסוכן המרוחק שנפרס בסביבה הפרטית שלכם מתשאל באופן רציף את תור ההודעות של השרת המפרסם דרך חיבור יוצא מוצפן ב-TLS.
3. ביצוע מקומי: כשמאחזרים הוראה למשימה, הסוכן המרוחק מבצע את הפעולה הנדרשת באופן מקומי מול כלי אבטחה פנימיים או נקודות קצה ברשת (למשל השבתת חשבון או חסימת יציאה בחומת אש).
4. דיווח על סטטוס: בסיום הפעולה, הסוכן המרוחק מחזיר את סטטוס הפעולה ויומני הביצוע לתור של בעל התוכן הדיגיטלי באמצעות TLS, שם הם מאוחזרים ומוצגים בתצוגת המקרה של SOAR.

אבטחה, תאימות ואחריות משותפת

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

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

‫Google SecOps יורש את תכנון האבטחה הבסיסי, את יכולות המחשוב ואת ארכיטקטורת האחסון של Google Cloud התשתית. במודל הזה:

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

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

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

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

מסגרות נתמכות של עמידה בדרישות רגולטוריות:

• ‫FedRAMP: רמות השפעה בינונית וגבוהה (FEDRAMP_MODERATE, FEDRAMP_HIGH)
• רמות ההשפעה של משרד ההגנה האמריקאי: IL4 ו-IL5 (IL4_AND_IL5)
• תחום הבריאות והפיננסים: HIPAA ו-PCI DSS‏ (HIPAA, PCI_DSS)

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

מיקום אחסון הנתונים ושקיפות הגישה

‫Google SecOps אוכף בידוד לוגי קפדני של דיירים ותומך ב-Access Transparency כדי לתת לכם שליטה ניתנת לאימות ושקיפות של ביקורת על גישת נתונים אדמיניסטרטיבית.

חבילות נתמכות של אבטחת מידע ומיקום נתונים:

• מפתחות הצפנה בניהול הלקוח (CMEK): שליטה במפתחות וניהול שלהם שמשמשים להצפנת נתונים במנוחה (CMEK_V1).
• מיקום אחסון נתונים מתקדם: אפשר לאכוף גבולות אזוריים למיקום אחסון נתונים ואמצעי בקרה לגישת אדמינים (DRZ_ADVANCED).
• VPC Service Controls: בעזרת VPC Service Controls (VPC-SC) תוכלו להגדיר גבולות גזרה מאובטחים ומותאמים אישית מסביב למשאבי האבטחה בענן.

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

ערימת האבטחה בת ארבע השכבות:

1. שכבת אמצעי הבקרה של הלקוח בנושא אבטחה: אמצעי הבקרה האדמיניסטרטיביים ברמה הגבוהה ביותר, כולל בקרת גישה המבוססת על תפקידים (RBAC) שמנוהלת באמצעות ניהול זהויות והרשאות גישה (IAM), מפתחות הצפנה בניהול הלקוח (CMEK) ומדיניות אזורית בנושא מיקום אחסון הנתונים.
2. שכבת אבטחה של הפלטפורמה: בידוד לוגי של הדיירים, הצפנה כברירת מחדל של נתונים במצב מנוחה ובזמן העברה (TLS), ורישום ביומן ביקורת של Access Transparency.
3. שכבת התשתית של Google: תשתית ליבה של מחשוב ואחסון, כולל ניהול אשכולות Borg, אחסון מבוזר של Colossus ומסדי נתונים גלובליים של Spanner.
4. שכבת אבטחה פיזית: אבטחה בסיסית שנתמכת על ידי מרכזי נתונים ארגוניים של Google, אמצעי בקרה ביומטריים רב-שלביים ושבבי אבטחה מותאמים אישית של Titan (roots of trust).

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

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