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