ניתוח יומני אבטחה ב-Google Cloud

Last reviewed 2025-10-08 UTC

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

במדריך הזה נסביר איך לבצע את הפעולות הבאות:

• מפעילים את היומנים כדי לנתח אותם.
• אפשר להפנות את היומנים האלה ליעד יחיד בהתאם לבחירה שלכם בכלי לניתוח אבטחה, כמו Observability Analytics,‏ BigQuery,‏ Google Security Operations או טכנולוגיה של צד שלישי לניהול מידע ואירועים בתחום האבטחה (SIEM).
• אפשר לנתח את היומנים האלה כדי לבדוק את השימוש בענן ולזהות איומים פוטנציאליים על הנתונים ועומסי העבודה, באמצעות שאילתות לדוגמה מתוך הפרויקט Community Security Analytics (CSA).

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

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

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

התרשים מתחיל עם מקורות נתוני האבטחה הבאים: יומנים מ-Cloud Logging, שינויים בנכסים מ-Cloud Asset Inventory וממצאים בנושא אבטחה מ-Security Command Center. לאחר מכן, התרשים מראה את מקורות נתוני האבטחה האלה מנותבים לכלי לניתוח אבטחה לפי בחירתכם: Observability Analytics ב-Cloud Logging,‏ BigQuery,‏ Google Security Operations או SIEM של צד שלישי. לבסוף, התרשים מראה שימוש בשאילתות CSA עם כלי הניתוח כדי לנתח את נתוני האבטחה שנאספו.

תהליך עבודה לניתוח יומני אבטחה

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

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

  כדי לעזור לכם להעריך יומנים מבחינת הנראות והכיסוי של זיהוי האיומים שהם מספקים, המדריך הזה כולל כלי להיקף היומנים. הכלי הזה ממפה כל יומן לטקטיקות ולטכניקות רלוונטיות של איומים במטריצת MITRE ATT&CK®‎ לארגונים. הכלי גם ממפה כללים של Event Threat Detection ב-Security Command Center ליומנים שהם מסתמכים עליהם. אתם יכולים להשתמש בכלי להיקף היומנים כדי להעריך יומנים בלי קשר לכלי הניתוח שבו אתם משתמשים.

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

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

• ניתוח יומנים: אחרי שמעבירים את היומנים לכלי ניתוח, השלב הבא הוא לנתח את היומנים האלה כדי לזהות איומי אבטחה פוטנציאליים. האופן שבו מנתחים את היומנים תלוי בכלי הניתוח שבו משתמשים. אם אתם משתמשים ב-Observability Analytics או ב-BigQuery, אתם יכולים לנתח את היומנים באמצעות שאילתות SQL. אם אתם משתמשים ב-Google Security Operations, אתם יכולים לנתח את היומנים באמצעות כללי YARA-L. אם אתם משתמשים בכלי SIEM של צד שלישי, אתם צריכים להשתמש בשפת השאילתות שצוינה בכלי הזה.

  במדריך הזה תמצאו שאילתות SQL שתוכלו להשתמש בהן כדי לנתח את היומנים ב-Observability Analytics או ב-BigQuery. שאילתות ה-SQL שמופיעות במדריך הזה מגיעות מהפרויקט Community Security Analytics (CSA). ‫CSA הוא קבוצה של ניתוחי אבטחה בסיסיים בקוד פתוח, שנועדו לספק לכם בסיס של שאילתות וכללים מוכנים מראש שתוכלו לעשות בהם שימוש חוזר כדי להתחיל לנתח את היומנים שלכם ב- Google Cloud .

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

הפעלת יומנים

תהליך ההפעלה של יומנים כולל את השלבים הבאים:

1. כדי לזהות את היומנים שאתם צריכים, תוכלו להשתמש בכלי להיקף היומן שמופיע במדריך הזה.
2. רושמים את מסנן היומנים שנוצר על ידי הכלי להגדרת היקף היומנים, כדי להשתמש בו בהמשך כשמגדירים את sink ביומן.
3. מפעילים את רישום היומנים לכל סוג יומן או שירות שזוהו. Google Cloud יכול להיות שבהתאם לשירות, תצטרכו גם להפעיל את יומני הביקורת המתאימים לגבי גישה לנתונים, כמו שמפורט בהמשך הקטע הזה.

זיהוי יומנים באמצעות הכלי להגדרת היקף היומן

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

• טקטיקות וטכניקות של איומים שאפשר לעקוב אחריהן באמצעות היומן הזה.
• הפרות תאימות ל-CIS Google Cloud Computing Platform שאפשר לזהות ביומן הזה.
• Event Threat Detection rules that rely on that log.

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

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

• כדי לבחור או להסיר יומן בכלי להגדרת היקף היומן, לוחצים על המתג לצד שם היומן.
• כדי לבחור או להסיר את כל היומנים, לוחצים על המתג לצד הכותרת סוג היומן.
• כדי לראות אילו טכניקות של MITRE ATT&CK אפשר לנטר באמצעות כל סוג של יומן, לוחצים על ליד הכותרת MITRE ATT&CK tactics and techniques.

כלי להגדרת היקף היומן

הקלטת מסנן היומן

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

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

3. ב-Cloud Shell, יוצרים משתנה כדי לשמור את מסנן היומן:

   export LOG_FILTER='LOG_FILTER'
   

   מחליפים את LOG_FILTER בקוד של מסנן היומן.

הפעלה של יומנים ספציפיים לפלטפורמה

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

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

כדי להפעיל רישום ביומן עבור יומן פלטפורמה ספציפי:

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

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

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

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

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

• ‫ADMIN_READ: רשומות של פעולות לקריאת מטא-נתונים או פרטי הגדרה.
• ‫DATA_READ: רשומות של פעולות לקריאת פרטים שהמשתמשים סיפקו.
• ‫DATA_WRITE: רשומות של פעולות שבהן נכתבים נתונים שהמשתמשים סיפקו.

שימו לב שאי אפשר להגדיר את הרישום של פעולות ADMIN_WRITE, שהן פעולות שבהן נכתב מידע במטא-נתונים או בהגדרות. הפעולות של ADMIN_WRITE כלולות ביומני הביקורת Admin Activity מ-Cloud Audit Logs, ולכן אי אפשר להשבית אותן.

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

ניהול הנפח של יומני הביקורת Data Access

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

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

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

  פרויקט	ביטוי סינון של יומן
  החרגה של כל היומנים מפרויקט נתון	NOT logName =~ "^projects/PROJECT_ID"

• מתן עדיפות לקבוצת משנה של פעולות גישה לנתונים, כמו ADMIN_READ,‏ DATA_READ או DATA_WRITE, עבור קבוצה מינימלית של פעולות מתועדות. לדוגמה, שירותים מסוימים כמו Cloud DNS כותבים את כל שלושת סוגי הפעולות, אבל אתם יכולים להפעיל רישום ביומן רק לפעולות ADMIN_READ. אחרי שמגדירים אחת או יותר מ-3 הפעולות האלה של גישה לנתונים, יכול להיות שתרצו להחריג פעולות ספציפיות שכוללות נפח גדול במיוחד. אפשר להחריג את הפעולות האלה שיוצרות נפח גבוה של נתונים על ידי שינוי של מסנן היומן של יעד הנתונים. לדוגמה, אתם מחליטים להפעיל רישום מלא ביומני הביקורת Data Access, כולל פעולות DATA_READ בשירותי אחסון קריטיים מסוימים. כדי להחריג במצב הזה פעולות קריאה ספציפיות של נתונים עם נפח תנועה גבוה, אפשר להוסיף את ביטויי המסנן המומלצים הבאים של יומן הרישום למסנן יומן הרישום של יעד הנתונים:

  שירות	ביטוי סינון של יומן
  אי הכללה של יומנים בנפח גבוה מ-Cloud Storage	NOT (resource.type="gcs_bucket" AND (protoPayload.methodName="storage.buckets.get" OR protoPayload.methodName="storage.buckets.list"))
  החרגת יומנים בכמות גדולה מ-Cloud SQL	NOT (resource.type="cloudsql_database" AND protoPayload.request.cmd="select")

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

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

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

דוגמה להגדרת יומן ביקורת Data Access

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

רמה	שירותים	סוגים של יומני ביקורת של גישה לנתונים	טקטיקות MITRE ATT&CK
שירותי אימות והרשאה	‫IAM שרת proxy לאימות זהויות (IAP)^1 Cloud KMS Secret Manager מנהל המשאבים	ADMIN_READ DATA_READ	גילוי גישה לפרטי כניסה הסלמת הרשאות
שירותי אחסון	‫BigQuery (מופעל כברירת מחדל) Cloud Storage^1, 2	DATA_READ DATA_WRITE	איסוף העברה
שירותי תשתית	‫Compute Engine מדיניות הארגון	ADMIN_READ	Discovery

¹ הפעלה של יומני ביקורת של גישה לנתונים ב-IAP או ב-Cloud Storage יכולה ליצור נפחים גדולים של יומנים אם יש תנועה גבוהה למשאבי אינטרנט שמוגנים על ידי IAP או לאובייקטים ב-Cloud Storage.

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

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

• שירותי אימות והרשאה: בשביל רמת השירותים הזו, מומלץ לבצע ביקורת על כל הפעולות של גישה לנתונים. רמת הביקורת הזו עוזרת לכם לעקוב אחרי הגישה למפתחות רגישים, לסיסמאות ולמדיניות IAM. מעקב אחרי הגישה הזו יכול לעזור לכם לזהות טקטיקות של MITRE ATT&CK כמו גילוי, גישה לפרטי כניסה והעלאת רמת ההרשאות.
• שירותי אחסון: בשירותים ברמה הזו, מומלץ לבצע ביקורת על פעולות גישה לנתונים שכוללות פרטים שהמשתמשים סיפקו. רמת הביקורת הזו עוזרת לכם לעקוב אחרי הגישה לנתונים הרגישים והחשובים שלכם. מעקב אחרי הגישה הזו יכול לעזור לכם לזהות טקטיקות של MITRE ATT&CK כמו איסוף וזליגת מידע שמופעלות נגד הנתונים שלכם.
• שירותי תשתית: בשירותים ברמה הזו, מומלץ לבצע ביקורת על פעולות גישה לנתונים שכוללות מטא-נתונים או מידע על הגדרות. רמת הביקורת הזו עוזרת לעקוב אחרי סריקה של הגדרות התשתית. מעקב אחרי הגישה הזו יכול לעזור לכם לזהות טקטיקות של MITRE ATT&CK כמו גילוי של עומסי העבודה שלכם.

יומני ניתוב

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

בתרשים מוצגות אפשרויות הניתוב הבאות:

• אם אתם משתמשים ב-Observability Analytics, אתם צריכים אובייקט נצבר מסוג sink כדי לצבור את היומנים מכל הארגון שלכם בדלי אחד של Cloud Logging. Google Cloud

• אם אתם משתמשים ב-BigQuery, אתם צריכים מאגר נתונים מסוג sink מצטבר כדי לצבור את היומנים מכל הארגון שלכם ב- Google Cloud למערך נתונים יחיד ב-BigQuery.

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

• אם אתם משתמשים ב-BigQuery או במערכת SIEM של צד שלישי, או אם אתם רוצים לייצא קבוצה מורחבת של יומנים ל-Google Security Operations, בתרשים מוצג שנדרש שלב נוסף בין הפעלת היומנים לבין ניתוח שלהם. השלב הנוסף הזה כולל הגדרה של מאגר נתונים (sink) מצטבר שמנתב את היומנים שנבחרו בצורה מתאימה. אם אתם משתמשים ב-BigQuery, יעד כזה הוא כל מה שאתם צריכים כדי לנתב את היומנים ל-BigQuery. אם אתם משתמשים ב-SIEM של צד שלישי, אתם צריכים לוודא שהיעד יצבור את היומנים שנבחרו ב-Pub/Sub או ב-Cloud Storage לפני שניתן יהיה למשוך את היומנים אל כלי הניתוח שלכם.

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

אפשרויות הניתוב אל Google Security Operations ואל מערכת SIEM של צד שלישי לא מוסברות במדריך הזה. עם זאת, בקטעים הבאים מפורטים השלבים לניתוב יומנים אל Observability Analytics או אל BigQuery:

1. הגדרת יעד יחיד
2. יוצרים sink ביומן צבירה.
3. מעניקים גישה ליעד.
4. מגדירים הרשאת קריאה ליעד.
5. מוודאים שהיומנים מנותבים ליעד.

הגדרת יעד יחיד

ניתוח נתוני ניראות

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

1. פותחים את Google Cloud המסוף ב Google Cloud פרויקט שרוצים לצבור בו את היומנים.

   כניסה למסוף Google Cloud

2. בטרמינל של Cloud Shell, מריצים את הפקודה gcloud הבאה כדי ליצור קטגוריה ביומן:

   gcloud logging buckets create BUCKET_NAME \
     --location=BUCKET_LOCATION \
     --project=PROJECT_ID
   

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

   • ‫PROJECT_ID: המזהה של Google Cloud הפרויקט שבו יאוחסנו היומנים המצטברים.
   • ‫BUCKET_NAME: השם של מאגר ה-Logging החדש.

   • ‫BUCKET_LOCATION: המיקום הגיאוגרפי של קטגוריית היומנים החדשה. המיקומים הנתמכים הם global,‏ us או eu. מידע נוסף על אזורי האחסון האלה זמין במאמר בנושא אזורים נתמכים. אם לא מציינים מיקום, נעשה שימוש באזור global, כלומר היומנים יכולים להיות ממוקמים פיזית בכל אחד מהאזורים.

     הערה: אחרי שיוצרים את הקטגוריה, אי אפשר לשנות את האזור שלה.

3. מוודאים שהקטגוריה נוצרה:

   gcloud logging buckets list --project=PROJECT_ID
   

4. (אופציונלי) מגדירים את תקופת השמירה של היומנים בקטגוריה. בדוגמה הבאה, משך השמירה של היומנים שמאוחסנים בקטגוריה הוארך ל-365 ימים:

   gcloud logging buckets update BUCKET_NAME \
     --location=BUCKET_LOCATION \
     --project=PROJECT_ID \
     --retention-days=365
   

5. כדי לשדרג את הדלי החדש לשימוש ב-Observability Analytics, פועלים לפי השלבים האלה.

BigQuery

1. פותחים את Google Cloud המסוף ב Google Cloud פרויקט שרוצים לצבור בו את היומנים.

   כניסה למסוף Google Cloud

2. במסוף Cloud Shell, מריצים את הפקודה bq mk הבאה כדי ליצור מערך נתונים:

   bq --location=DATASET_LOCATION mk \
       --dataset \
       --default_partition_expiration=PARTITION_EXPIRATION \
       PROJECT_ID:DATASET_ID
   

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

   • ‫PROJECT_ID: המזהה של Google Cloud הפרויקט שבו יאוחסנו היומנים המצטברים.
   • ‫DATASET_ID: המזהה של מערך הנתונים החדש ב-BigQuery.

   • DATASET_LOCATION: המיקום הגיאוגרפי של מערך הנתונים. אחרי שיוצרים את מערך הנתונים, אי אפשר לשנות את המיקום.

     הערה: אם בוחרים באפשרות EU או באזור שמבוסס על האיחוד האירופי למיקום של מערך הנתונים, נתוני הלקוחות העיקריים של BigQuery מאוחסנים באיחוד האירופי. נתוני הלקוחות העיקריים ב-BigQuery מוגדרים בתנאים הספציפיים לשירות.

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

     שיטה מומלצת: מגדירים את מאפיין ברירת המחדל של תפוגת המחיצה של מערך הנתונים בהתאם לדרישות שלכם לגבי שמירת יומנים, כדי שיומנים ישנים יותר יתיישנו ויפוג תוקפם. אפשר לעשות את זה במהלך יצירת מערך הנתונים או אחריו. כך תוכלו לשמור יומנים למשך הזמן שאתם צריכים, תוך הגבלת הגודל הכולל של אחסון היומנים והעלות הנלווית. אם יש לכם דרישות מפורטות יותר לגבי שמירת נתונים על סמך סוג היומן, אתם יכולים לבטל את ההגדרה של המאפיין הזה ברמת הטבלה אחרי ש-sink ביומן התחיל להעביר יומנים וליצור את הטבלאות המקבילות עם החלוקה למחיצות. לדוגמה, יכול להיות שתצטרכו לשמור נתונים של Cloud Audit Logs למשך שלוש שנים, אבל נתונים של VPC Flow Logs ויומנים של כללי חומת אש יישמרו רק למשך 90 יום. אם לא מגדירים תאריך תפוגה של מחיצות כברירת מחדל ברמת מערך הנתונים, ולא מגדירים תאריך תפוגה של מחיצות כשיוצרים את הטבלה, המחיצות אף פעם לא יפוגו

יצירת sink ביומן מצטבר

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

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

ניתוח נתוני ניראות

1. במסוף Cloud Shell, מריצים את הפקודה gcloud הבאה כדי ליצור מאגר נתונים משולב ברמת הארגון:

   gcloud logging sinks create SINK_NAME \
     logging.googleapis.com/projects/PROJECT_ID/locations/BUCKET_LOCATION/buckets/BUCKET_NAME \
     --log-filter="LOG_FILTER" \
     --organization=ORGANIZATION_ID \
     --include-children
   

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

   • ‫SINK_NAME: השם של יעד העברת היומנים.
   • ‫PROJECT_ID: המזהה של Google Cloud הפרויקט שבו יאוחסנו היומנים המצטברים.
   • ‫BUCKET_LOCATION: המיקום של קטגוריית ה-Logging שיצרתם לאחסון יומנים.
   • ‫BUCKET_NAME: השם של מאגר הנתונים של Logging שיצרתם לאחסון יומנים.
   • ‫LOG_FILTER: מסנן היומן ששמרתם מכלי ההיקף של היומן.
   • ‫ORGANIZATION_ID: מזהה המשאב של הארגון.

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

2. מוודאים שיעד הנתונים נוצר:

   gcloud logging sinks list --organization=ORGANIZATION_ID
   

3. מקבלים את השם של חשבון השירות שמשויך למאגר שיצרתם:

   gcloud logging sinks describe SINK_NAME --organization=ORGANIZATION_ID
   

   הפלט אמור להיראות כך:

   writerIdentity: serviceAccount:[e-mail]`
   

4. מעתיקים את המחרוזת כולה של writerIdentity שמתחילה ב-serviceAccount:. המזהה הזה הוא חשבון השירות של יעד הניקוז. עד שתעניקו לחשבון השירות הזה הרשאת כתיבה לדלי היומנים, ניתוב היומנים מיעד הניקוז הזה ייכשל. בקטע הבא מוסבר איך מעניקים הרשאת כתיבה לזהות הכותב של יעד הניקוז.

BigQuery

1. במסוף Cloud Shell, מריצים את הפקודה gcloud הבאה כדי ליצור מאגר נתונים מאוחד ברמת הארגון:

   gcloud logging sinks create SINK_NAME \
     bigquery.googleapis.com/projects/PROJECT_ID/datasets/DATASET_ID \
     --log-filter="LOG_FILTER" \
     --organization=ORGANIZATION_ID \
     --use-partitioned-tables \
     --include-children
   

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

   • ‫SINK_NAME: השם של יעד העברת היומנים.
   • ‫PROJECT_ID: המזהה של Google Cloud הפרויקט שאליו רוצים לצבור את היומנים.
   • ‫DATASET_ID: המזהה של מערך הנתונים ב-BigQuery שיצרתם.
   • ‫LOG_FILTER: מסנן היומן ששמרתם מכלי ההיקף של היומן.
   • ‫ORGANIZATION_ID: מזהה המשאב של הארגון.

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

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

2. מוודאים שיעד הנתונים נוצר:

   gcloud logging sinks list --organization=ORGANIZATION_ID
   

3. מקבלים את השם של חשבון השירות שמשויך למאגר שיצרתם:

   gcloud logging sinks describe SINK_NAME --organization=ORGANIZATION_ID
   

   הפלט אמור להיראות כך:

   writerIdentity: serviceAccount:[e-mail]`
   

4. מעתיקים את המחרוזת כולה של writerIdentity שמתחילה ב-serviceAccount:. המזהה הזה הוא חשבון השירות של יעד הניקוז. עד שתעניקו לחשבון השירות הזה הרשאת כתיבה למערך הנתונים של BigQuery, ניתוב היומנים מיעד הניקוז הזה ייכשל. בקטע הבא מוסבר איך מעניקים הרשאת כתיבה לזהות הכותב של יעד הניקוז.

הענקת גישה למאגר

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

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

ניתוח נתוני ניראות

כדי להוסיף את ההרשאות לחשבון השירות של יעד הנתונים:

1. במסוף Google Cloud , נכנסים לדף IAM:

   כניסה לדף IAM

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

3. לוחצים על Grant access.

4. בשדה New principals, מזינים את חשבון השירות של יעד הסינק בלי הקידומת serviceAccount:. חשוב לזכור שהזהות הזו מגיעה מהשדה writerIdentity שאחזרתם בקטע הקודם אחרי שיצרתם את יעד הסינק.

5. בתפריט הנפתח Select a role, בוחרים באפשרות Logs Bucket Writer.

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

7. מזינים שם ותיאור לתנאי.

8. בתפריט הנפתח Condition type בוחרים באפשרות Resource > Name.

9. בתפריט הנפתח Operator, בוחרים באפשרות Ends with.

10. בשדה Value, מזינים את המיקום והשם של ה-bucket באופן הבא:

    locations/BUCKET_LOCATION/buckets/BUCKET_NAME
    

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

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

BigQuery

כדי להוסיף את ההרשאות לחשבון השירות של יעד הנתונים:

1. במסוף Google Cloud , עוברים אל BigQuery:

   כניסה ל-BigQuery

2. פותחים את מערך הנתונים ב-BigQuery שיצרתם לאחסון מרכזי של יומנים.

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

4. בחלונית הצדדית Dataset Permissions (הרשאות לערכת הנתונים), לוחצים על Add Principal (הוספת ישות).

5. בשדה New principals, מזינים את חשבון השירות של יעד הסינק בלי הקידומת serviceAccount:. חשוב לזכור שהזהות הזו מגיעה מהשדה writerIdentity שאחזרתם בקטע הקודם אחרי שיצרתם את יעד הסינק.

6. בתפריט הנפתח תפקיד, בוחרים באפשרות BigQuery Data Editor.

7. לוחצים על Save.

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

הגדרת הרשאת קריאה ליעד

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

ניתוח נתוני ניראות

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

1. במסוף Google Cloud , נכנסים לדף IAM:

   כניסה לדף IAM

   מוודאים שבחרתם את Google Cloud הפרויקט שבו אתם משתמשים כדי לצבור את היומנים.

2. לוחצים על הוספה.

3. בשדה New principal, מוסיפים את חשבון האימייל.

4. בתפריט הנפתח Select a role, בוחרים באפשרות Logs Views Accessor.

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

   1. לוחצים על הוספת תנאי.

   2. מזינים שם ותיאור לתנאי.

   3. בתפריט הנפתח Condition type בוחרים באפשרות Resource > Name.

   4. בתפריט הנפתח Operator, בוחרים באפשרות Ends with.

   5. בשדה Value, מזינים את המיקום והשם של מאגר הנתונים, ואת תצוגת ברירת המחדל של היומן _AllLogs באופן הבא:

      locations/BUCKET_LOCATION/buckets/BUCKET_NAME/views/_AllLogs
      

      הערה: Cloud Logging יוצר באופן אוטומטי את התצוגה _AllLogs לכל קטגוריה ביומן, שבה מוצגים כל היומנים בקטגוריה ביומן. כדי לקבל שליטה מדויקת יותר ביומנים שאפשר לראות ולשאול לגביהם שאילתות בקטגוריה של היומנים, אפשר ליצור ולהשתמש בתצוגת יומנים בהתאמה אישית במקום ב-_AllLogs.

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

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

BigQuery

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

איך מוודאים שהיומנים מנותבים ליעד

ניתוח נתוני ניראות

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

1. נכנסים לדף Observability Analytics במסוף Google Cloud :

   מעבר אל Observability Analytics

   מוודאים שבחרתם את Google Cloud הפרויקט שבו אתם משתמשים כדי לצבור את היומנים.

2. לוחצים על הכרטיסייה Log Views (יומני צפיות).

3. מרחיבים את תצוגות היומן מתחת לקטגוריה ביומן שיצרתם (כלומר BUCKET_NAME) אם היא לא מורחבת כבר.

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

   

5. לצד _AllLogs, לוחצים על שאילתה . פעולה זו מאכלסת את העורך Query בשאילתת SQL לדוגמה לאחזור רשומות ביומן שהועברו לאחרונה.

6. לוחצים על Run query כדי לראות את רשומות היומן שהועברו לאחרונה.

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

BigQuery

כשמעבירים יומנים למערך נתונים ב-BigQuery,‏ Cloud Logging יוצר טבלאות ב-BigQuery כדי לאחסן את רשומות היומן, כמו שמוצג בצילום המסך הבא:

צילום המסך מראה איך Cloud Logging נותן שם לכל טבלה ב-BigQuery על סמך השם של היומן שאליו שייך רשומה ביומן. לדוגמה, הטבלה cloudaudit_googleapis_com_data_access שמוצגת בצילום המסך מכילה יומני ביקורת של גישה לנתונים, שמזהה היומן שלהם הוא cloudaudit.googleapis.com%2Fdata_access. בנוסף לשם שניתן לכל טבלה על סמך רשומת היומן המתאימה, כל טבלה מחולקת גם למחיצות על סמך חותמות הזמן של כל רשומת יומן.

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

הערה: גם יומני פעילות האדמין וגם יומני הגישה לנתונים נטענים ל-BigQuery, ושדה רשומת היומן protoPayload שלהם משנה את השם ל-protoPayload_auditlog ב-BigQuery. מידע נוסף על המרות סכימה שמתבצעות על ידי Cloud Logging לפני הכתיבה ל-BigQuery זמין במאמר שדות ביומני ביקורת מיוצאים.

ניתוח יומנים

אתם יכולים להריץ מגוון רחב של שאילתות על יומני הביקורת ויומני הפלטפורמה. ברשימה הבאה מופיעות שאלות לדוגמה בנושא אבטחה, שאולי תרצו לשאול לגבי היומנים שלכם. לכל שאלה ברשימה הזו יש שתי גרסאות של שאילתת CSA תואמת: אחת לשימוש עם Observability Analytics ואחת לשימוש עם BigQuery. צריך להשתמש בגרסת השאילתה שתואמת ליעד של ה-sink שהגדרתם קודם.

ניתוח נתוני ניראות

לפני שמשתמשים באחת משאילתות ה-SQL שבהמשך, מחליפים את MY_PROJECT_ID במזהה של פרויקט Google Cloud שבו יצרתם את קטגוריית יומני הרישום (כלומר PROJECT_ID)), ואת MY_DATASET_ID באזור ובשם של קטגוריית יומני הרישום (כלומר BUCKET_LOCATION.BUCKET_NAME).

מעבר אל Observability Analytics

BigQuery

לפני שמשתמשים באחת משאילתות ה-SQL שבהמשך, צריך להחליף את MY_PROJECT_ID במזהה של פרויקט Google Cloud שבו יצרתם את מערך הנתונים ב-BigQuery (כלומר PROJECT_ID)), ואת MY_DATASET_ID בשם של מערך הנתונים הזה (כלומר DATASET_ID).

כניסה ל-BigQuery

1. שאלות לגבי כניסה וגישה
   • האם Google Workspace מסמנת ניסיונות כניסה חשודים?
   • האם יש ניסיונות כניסה כושלים מוגזמים מזהות משתמש כלשהי?
   • האם היו ניסיונות גישה שהפרו את VPC Service Controls?
   • האם היו ניסיונות גישה שהפרו את אמצעי בקרת הגישה של שרת Proxy לאימות זהויות (IAP)?
2. שאלות לגבי שינויים בהרשאות
   • האם יש משתמשים שהוספו לקבוצות עם הרשאות גבוהות?
   • האם הוענקו הרשאות לחשבון שירות?
   • האם יש חשבונות שירות או מפתחות שנוצרו על ידי זהות לא מאושרת?
   • האם משתמש כלשהו נוסף למדיניות IAM רגישה (או הוסר ממנה)?
3. שאלות לגבי פעילות הקצאת הרשאות
   • האם בוצעו שינויים בהגדרות הרישום ביומן?
   • האם יש יומני זרימה של VPC שהושבתו?
   • האם היו שינויים במספר חריג של כללי חומת אש בשבוע האחרון?
   • האם נמחקו מכונות וירטואליות בשבוע האחרון?
4. שאלות לגבי השימוש בעומסי עבודה
   • האם היה שימוש חריג ב-API על ידי משתמש כלשהו בשבוע האחרון?
   • מהו השימוש בהתאמה אוטומטית לעומס לכל יום בחודש האחרון?
5. שאלות לגבי גישה לנתונים
   • אילו משתמשים ניגשו לנתונים בתדירות הכי גבוהה בשבוע האחרון?
   • אילו משתמשים ניגשו לנתונים בטבלה 'חשבונות' בחודש שעבר?
   • אילו טבלאות נגישות בתדירות הכי גבוהה, ומי ניגש אליהן?
   • מהן 10 השאילתות המובילות ב-BigQuery בשבוע האחרון?
   • מה הפעולות הנפוצות ביותר שתועדו ביומן הגישה לנתונים בחודש האחרון?
6. שאלות בנושא אבטחת רשת
   • האם יש חיבורים מכתובת IP חדשה לרשת משנה ספציפית?
   • האם חיבורים נחסמו על ידי Google Cloud Armor?
   • האם Cloud IDS זיהה וירוס או תוכנה זדונית ברמת חומרה גבוהה?
   • מהם הדומיינים המובילים ברשת ה-VPC שלכם שמתבצעות לגביהם שאילתות ב-Cloud DNS?

שאלות בנושא כניסה וגישה

השאילתות לדוגמה האלה מבצעות ניתוח כדי לזהות ניסיונות התחברות חשודים או ניסיונות גישה ראשוניים לסביבה שלכם ב- Google Cloud .

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

האם יש ניסיון כניסה חשוד שסומן על ידי Google Workspace?

השאילתה הבאה מזהה ניסיונות התחברות חשודים שסומנו על ידי Google Workspace, על ידי חיפוש ביומני Cloud Identity שמהווים חלק מביקורת על התחברויות ל-Google Workspace. ניסיונות הכניסה האלה יכולים להיות ממסוף Google Cloud , ממסוף Admin או מ-CLI של gcloud.

ניתוח נתוני ניראות

SELECT
  timestamp,
  proto_payload.audit_log.authentication_info.principal_email,
  proto_payload.audit_log.request_metadata.caller_ip,
  proto_payload.audit_log.method_name, parameter
FROM `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`,
  UNNEST(JSON_QUERY_ARRAY(proto_payload.audit_log.metadata.event[0].parameter)) AS parameter
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 60 DAY)
  AND proto_payload.audit_log IS NOT NULL
  AND proto_payload.audit_log.service_name = "login.googleapis.com"
  AND proto_payload.audit_log.method_name = "google.login.LoginService.loginSuccess"
  AND JSON_VALUE(parameter.name) = "is_suspicious"
  AND JSON_VALUE(parameter.boolValue) = "true"

BigQuery

SELECT
  timestamp,
  protopayload_auditlog.authenticationInfo.principalEmail,
  protopayload_auditlog.requestMetadata.callerIp,
  protopayload_auditlog.methodName
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_data_access`,
  UNNEST(JSON_QUERY_ARRAY(protopayload_auditlog.metadataJson, '$.event[0].parameter')) AS parameter
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 60 DAY)
  AND protopayload_auditlog.metadataJson IS NOT NULL
  AND protopayload_auditlog.serviceName = "login.googleapis.com"
  AND protopayload_auditlog.methodName = "google.login.LoginService.loginSuccess"
  AND JSON_VALUE(parameter, '$.name') = "is_suspicious"
  AND JSON_VALUE(parameter, '$.boolValue') = "true"

האם יש ניסיונות כניסה כושלים רבים מדי מזהות משתמש כלשהי?

באמצעות חיפוש ביומנים של Cloud Identity שמהווים חלק מביקורת על התחברות ל-Google Workspace, השאילתה הבאה מזהה משתמשים שחוו שלוש או יותר כשלים רצופים בהתחברות במהלך 24 השעות האחרונות.

ניתוח נתוני ניראות

SELECT
  proto_payload.audit_log.authentication_info.principal_email,
  MIN(timestamp) AS earliest,
  MAX(timestamp) AS latest,
  count(*) AS attempts
FROM `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY)
  AND proto_payload.audit_log.service_name = "login.googleapis.com"
  AND proto_payload.audit_log.method_name = "google.login.LoginService.loginFailure"
GROUP BY
  1
HAVING
  attempts >= 3

BigQuery

SELECT
  protopayload_auditlog.authenticationInfo.principalEmail,
  MIN(timestamp) AS earliest,
  MAX(timestamp) AS latest,
  count(*) AS attempts
FROM
 `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_data_access`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY)
  AND protopayload_auditlog.serviceName="login.googleapis.com"
  AND protopayload_auditlog.methodName="google.login.LoginService.loginFailure"
GROUP BY
  1
HAVING
  attempts >= 3

האם היו ניסיונות גישה שהפרו את VPC Service Controls?

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

ניתוח נתוני ניראות

SELECT
  timestamp,
  log_name,
  proto_payload.audit_log.authentication_info.principal_email,
  proto_payload.audit_log.request_metadata.caller_ip,
  proto_payload.audit_log.method_name,
  proto_payload.audit_log.service_name,
  JSON_VALUE(proto_payload.audit_log.metadata.violationReason) as violationReason, 
  IF(JSON_VALUE(proto_payload.audit_log.metadata.ingressViolations) IS NULL, 'ingress', 'egress') AS violationType,
  COALESCE(
    JSON_VALUE(proto_payload.audit_log.metadata.ingressViolations[0].targetResource),
    JSON_VALUE(proto_payload.audit_log.metadata.egressViolations[0].targetResource)
  ) AS  targetResource,
  COALESCE(
    JSON_VALUE(proto_payload.audit_log.metadata.ingressViolations[0].servicePerimeter),
    JSON_VALUE(proto_payload.audit_log.metadata.egressViolations[0].servicePerimeter)
  ) AS  servicePerimeter
FROM `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND proto_payload.audit_log IS NOT NULL
  AND JSON_VALUE(proto_payload.audit_log.metadata, '$."@type"') = 'type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata'
ORDER BY
  timestamp DESC
LIMIT 1000

BigQuery

SELECT
  timestamp,
  protopayload_auditlog.authenticationInfo.principalEmail,
  protopayload_auditlog.requestMetadata.callerIp,
  protopayload_auditlog.methodName,
  protopayload_auditlog.serviceName,
  JSON_VALUE(protopayload_auditlog.metadataJson, '$.violationReason') as violationReason, 
  IF(JSON_VALUE(protopayload_auditlog.metadataJson, '$.ingressViolations') IS NULL, 'ingress', 'egress') AS violationType,
  COALESCE(
    JSON_VALUE(protopayload_auditlog.metadataJson, '$.ingressViolations[0].targetResource'),
    JSON_VALUE(protopayload_auditlog.metadataJson, '$.egressViolations[0].targetResource')
  ) AS  targetResource,
  COALESCE(
    JSON_VALUE(protopayload_auditlog.metadataJson, '$.ingressViolations[0].servicePerimeter'),
    JSON_VALUE(protopayload_auditlog.metadataJson, '$.egressViolations[0].servicePerimeter')
  ) AS  servicePerimeter
FROM
 `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_policy`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 400 DAY)
  AND JSON_VALUE(protopayload_auditlog.metadataJson, '$."@type"') = 'type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata'
ORDER BY
  timestamp DESC
LIMIT 1000

האם היו ניסיונות גישה שהפרו את בקרת הגישה של IAP?

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

ניתוח נתוני ניראות

SELECT
  timestamp,
  http_request.remote_ip,
  http_request.request_method,
  http_request.status,
  JSON_VALUE(resource.labels.backend_service_name) AS backend_service_name,
  http_request.request_url
FROM `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND resource.type="http_load_balancer"
  AND JSON_VALUE(json_payload.statusDetails) = "handled_by_identity_aware_proxy"
ORDER BY
  timestamp DESC

BigQuery

SELECT
  timestamp,
  httpRequest.remoteIp,
  httpRequest.requestMethod,
  httpRequest.status,
  resource.labels.backend_service_name,
  httpRequest.requestUrl,
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].requests`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND resource.type="http_load_balancer"
  AND jsonpayload_type_loadbalancerlogentry.statusdetails = "handled_by_identity_aware_proxy"
ORDER BY
  timestamp DESC

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

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

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

האם יש משתמשים שנוספו לקבוצות עם הרשאות גבוהות?

השאילתה הבאה מזהה משתמשים שנוספו לאחת מהקבוצות עם הרשאות גבוהות שמפורטות בשאילתה, על ידי ניתוח יומני הביקורת של Google Workspace Admin Audit. משתמשים בביטוי הרגולרי בשאילתה כדי להגדיר אילו קבוצות (כמו [e-mail] או [e-mail]) רוצים לעקוב. יכול להיות שתוצאות של שאילתות יצביעו על העלאת הרשאות זדונית או לא מכוונת.

ניתוח נתוני ניראות

SELECT
  timestamp,
  proto_payload.audit_log.authentication_info.principal_email,
  proto_payload.audit_log.method_name,
  proto_payload.audit_log.resource_name,
  (SELECT JSON_VALUE(x.value)
   FROM UNNEST(JSON_QUERY_ARRAY(proto_payload.audit_log.metadata.event[0].parameter)) AS x
   WHERE JSON_VALUE(x.name) = "USER_EMAIL") AS user_email,
  (SELECT JSON_VALUE(x.value)
   FROM UNNEST(JSON_QUERY_ARRAY(proto_payload.audit_log.metadata.event[0].parameter)) AS x
   WHERE JSON_VALUE(x.name) = "GROUP_EMAIL") AS group_email,
FROM `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 120 DAY)
  AND proto_payload.audit_log.service_name = "admin.googleapis.com"
  AND proto_payload.audit_log.method_name = "google.admin.AdminService.addGroupMember"
  AND EXISTS(
    SELECT * FROM UNNEST(JSON_QUERY_ARRAY(proto_payload.audit_log.metadata.event[0].parameter)) AS x
    WHERE
      JSON_VALUE(x.name) = "GROUP_EMAIL"
      AND REGEXP_CONTAINS(JSON_VALUE(x.value), r'(admin|prod).*') -- Update regexp with other sensitive groups if applicable
  )

BigQuery

SELECT
  timestamp,
  protopayload_auditlog.authenticationInfo.principalEmail,
  protopayload_auditlog.methodName,
  protopayload_auditlog.resourceName,
  (SELECT JSON_VALUE(x, '$.value')
   FROM UNNEST(JSON_QUERY_ARRAY(protopayload_auditlog.metadataJson, '$.event[0].parameter')) AS x
   WHERE JSON_VALUE(x, '$.name') = "USER_EMAIL") AS userEmail,
  (SELECT JSON_VALUE(x, '$.value')
   FROM UNNEST(JSON_QUERY_ARRAY(protopayload_auditlog.metadataJson, '$.event[0].parameter')) AS x
   WHERE JSON_VALUE(x, '$.name') = "GROUP_EMAIL") AS groupEmail,
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_activity`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 120 DAY)
  AND protopayload_auditlog.serviceName = "admin.googleapis.com"
  AND protopayload_auditlog.methodName = "google.admin.AdminService.addGroupMember"
  AND EXISTS(
    SELECT * FROM UNNEST(JSON_QUERY_ARRAY(protopayload_auditlog.metadataJson, '$.event[0].parameter')) AS x
    WHERE
      JSON_VALUE(x, '$.name') = 'GROUP_EMAIL'
      AND REGEXP_CONTAINS(JSON_VALUE(x, '$.value'), r'(admin|prod).*') -- Update regexp with other sensitive groups if applicable
  )

האם יש הרשאות שניתנו לחשבון שירות?

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

ניתוח נתוני ניראות

SELECT
  timestamp,
  proto_payload.audit_log.authentication_info.principal_email as grantor,
  JSON_VALUE(bindingDelta.member) as grantee,
  JSON_VALUE(bindingDelta.role) as role,
  proto_payload.audit_log.resource_name,
  proto_payload.audit_log.method_name
FROM
  `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`,
  UNNEST(JSON_QUERY_ARRAY(proto_payload.audit_log.service_data.policyDelta.bindingDeltas)) AS bindingDelta
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 400 DAY)
  -- AND log_id = "cloudaudit.googleapis.com/activity"
  AND (
    (resource.type = "service_account"
    AND proto_payload.audit_log.method_name LIKE "google.iam.admin.%.SetIAMPolicy")
    OR
    (resource.type IN ("project", "folder", "organization")
    AND proto_payload.audit_log.method_name = "SetIamPolicy"
    AND JSON_VALUE(bindingDelta.role) LIKE "roles/iam.serviceAccount%")
  )
  AND JSON_VALUE(bindingDelta.action) = "ADD"
  -- Principal (grantee) exclusions
  AND JSON_VALUE(bindingDelta.member) NOT LIKE "[e-mail]"
ORDER BY
  timestamp DESC

BigQuery

SELECT
  timestamp,
  protopayload_auditlog.authenticationInfo.principalEmail as grantor,
  bindingDelta.member as grantee,
  bindingDelta.role,
  protopayload_auditlog.resourceName,
  protopayload_auditlog.methodName,
FROM
  `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_activity`,
  UNNEST(protopayload_auditlog.servicedata_v1_iam.policyDelta.bindingDeltas) AS bindingDelta
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 180 DAY)
  AND (
    (resource.type = "service_account"
    AND protopayload_auditlog.methodName LIKE "google.iam.admin.%.SetIAMPolicy")
    OR
    (resource.type IN ("project", "folder", "organization")
    AND protopayload_auditlog.methodName = "SetIamPolicy"
    AND bindingDelta.role LIKE "roles/iam.serviceAccount%")
  )
  AND bindingDelta.action = 'ADD'
  -- Principal (grantee) exclusions
  AND bindingDelta.member NOT LIKE "[e-mail]"
ORDER BY
  timestamp DESC

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

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

ניתוח נתוני ניראות

SELECT
  timestamp,
  proto_payload.audit_log.authentication_info.principal_email,
  proto_payload.audit_log.method_name,
  proto_payload.audit_log.resource_name,
  JSON_VALUE(proto_payload.audit_log.response.email) as service_account_email
FROM
  `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND resource.type="service_account"
  AND proto_payload.audit_log.method_name LIKE "%CreateServiceAccount%"
  AND proto_payload.audit_log.authentication_info.principal_email NOT LIKE "%.gserviceaccount.com"

BigQuery

SELECT
  timestamp,
  protopayload_auditlog.authenticationInfo.principalEmail,
  protopayload_auditlog.methodName,
  protopayload_auditlog.resourceName,
  JSON_VALUE(protopayload_auditlog.responseJson, "$.email") as serviceAccountEmail
FROM
  `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_activity`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 180 DAY)
  AND resource.type="service_account"
  AND protopayload_auditlog.methodName LIKE "%CreateServiceAccount%"
  AND protopayload_auditlog.authenticationInfo.principalEmail NOT LIKE "%.gserviceaccount.com"

האם משתמש כלשהו נוסף למדיניות IAM רגישה (או הוסר ממנה)?

על ידי חיפוש ביומני הביקורת של פעילות האדמין, השאילתה הבאה מזהה כל שינוי גישה של משתמש או קבוצה למשאב מאובטח באמצעות IAP, כמו שירות קצה עורפי של Compute Engine. השאילתה הבאה מחפשת את כל עדכוני מדיניות IAM עבור משאבי IAP שכוללים את תפקיד ה-IAM‏ roles/iap.httpsResourceAccessor. התפקיד הזה מספק הרשאות גישה למשאב HTTPS או לשירות הקצה העורפי. כל תוצאות שאילתה עשויות להצביע על ניסיונות לעקוף את אמצעי ההגנה של שירות קצה עורפי שעשוי להיות חשוף לאינטרנט.

ניתוח נתוני ניראות

SELECT
  timestamp,
  proto_payload.audit_log.authentication_info.principal_email,
  resource.type,
  proto_payload.audit_log.resource_name,
  JSON_VALUE(binding, '$.role') as role,
  JSON_VALUE_ARRAY(binding, '$.members') as members
FROM
  `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`,
  UNNEST(JSON_QUERY_ARRAY(proto_payload.audit_log.response, '$.bindings')) AS binding
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  -- AND log_id = "cloudaudit.googleapis.com/activity"
  AND proto_payload.audit_log.service_name = "iap.googleapis.com"
  AND proto_payload.audit_log.method_name LIKE "%.IdentityAwareProxyAdminService.SetIamPolicy"
  AND JSON_VALUE(binding, '$.role') = "roles/iap.httpsResourceAccessor"
ORDER BY
  timestamp DESC

BigQuery

SELECT
  timestamp,
  protopayload_auditlog.authenticationInfo.principalEmail,
  resource.type,
  protopayload_auditlog.resourceName,
  JSON_VALUE(binding, '$.role') as role,
  JSON_VALUE_ARRAY(binding, '$.members') as members
FROM
  `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_activity`,
  UNNEST(JSON_QUERY_ARRAY(protopayload_auditlog.responseJson, '$.bindings')) AS binding
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 400 DAY)
  AND protopayload_auditlog.serviceName = "iap.googleapis.com"
  AND protopayload_auditlog.methodName LIKE "%.IdentityAwareProxyAdminService.SetIamPolicy"
  AND JSON_VALUE(binding, '$.role') = "roles/iap.httpsResourceAccessor"
ORDER BY
  timestamp DESC

שאלות לגבי פעולות הקצאת הרשאות

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

האם בוצעו שינויים בהגדרות הרישום ביומן?

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

ניתוח נתוני ניראות

SELECT
  receive_timestamp, timestamp AS eventTimestamp,
  proto_payload.audit_log.request_metadata.caller_ip,
  proto_payload.audit_log.authentication_info.principal_email, 
  proto_payload.audit_log.resource_name,
  proto_payload.audit_log.method_name
FROM 
  `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  proto_payload.audit_log.service_name = "logging.googleapis.com"
  AND log_id = "cloudaudit.googleapis.com/activity"

BigQuery

SELECT
  receiveTimestamp, timestamp AS eventTimestamp,
  protopayload_auditlog.requestMetadata.callerIp,
  protopayload_auditlog.authenticationInfo.principalEmail, 
  protopayload_auditlog.resourceName,
  protopayload_auditlog.methodName
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_activity`
WHERE
  protopayload_auditlog.serviceName = "logging.googleapis.com"

האם יש יומני זרימה של VPC שמושבתים באופן פעיל?

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

ניתוח נתוני ניראות

SELECT
  receive_timestamp, timestamp AS eventTimestamp,
  proto_payload.audit_log.request_metadata.caller_ip,
  proto_payload.audit_log.authentication_info.principal_email, 
  proto_payload.audit_log.resource_name,
  proto_payload.audit_log.method_name
FROM 
  `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  proto_payload.audit_log.method_name = "v1.compute.subnetworks.patch" 
  AND (
    JSON_VALUE(proto_payload.audit_log.request, "$.logConfig.enable") = "false"
    OR JSON_VALUE(proto_payload.audit_log.request, "$.enableFlowLogs") = "false"
  )

BigQuery

SELECT
  receiveTimestamp, timestamp AS eventTimestamp,
  protopayload_auditlog.requestMetadata.callerIp,
  protopayload_auditlog.authenticationInfo.principalEmail, 
  protopayload_auditlog.resourceName,
  protopayload_auditlog.methodName
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_activity`
WHERE
protopayload_auditlog.methodName = "v1.compute.subnetworks.patch" 
AND JSON_VALUE(protopayload_auditlog.requestJson, "$.logConfig.enable") = "false"

האם חל שינוי במספר גבוה באופן חריג של כללי חומת האש בשבוע האחרון?

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

ניתוח נתוני ניראות

SELECT
  *
FROM (
  SELECT
    *,
    AVG(counter) OVER (
      ORDER BY day
      ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING) AS avg,
    STDDEV(counter) OVER (
      ORDER BY day
      ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING) AS stddev,
    COUNT(*) OVER (
      RANGE BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) AS numSamples
  FROM (
    SELECT
      EXTRACT(DATE FROM timestamp) AS day,
      ARRAY_AGG(DISTINCT proto_payload.audit_log.method_name IGNORE NULLS) AS actions,
      ARRAY_AGG(DISTINCT proto_payload.audit_log.authentication_info.principal_email IGNORE NULLS) AS actors,
      COUNT(*) AS counter
    FROM `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
    WHERE
      timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 90 DAY)
      AND proto_payload.audit_log.method_name LIKE "v1.compute.firewalls.%"
      AND proto_payload.audit_log.method_name NOT IN ("v1.compute.firewalls.list", "v1.compute.firewalls.get")
    GROUP BY
      day
  )
)
WHERE
  counter > avg + 2 * stddev
  AND day >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY) 
ORDER BY
  counter DESC

BigQuery

SELECT
  *,
  AVG(counter) OVER (
    ORDER BY day
    ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING) AS avg,
  STDDEV(counter) OVER (
    ORDER BY day
    ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING) AS stddev,
  COUNT(*) OVER (
    RANGE BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) AS numSamples
FROM (
  SELECT
    EXTRACT(DATE FROM timestamp) AS day,
    ARRAY_AGG(DISTINCT protopayload_auditlog.methodName IGNORE NULLS) AS actions,
    ARRAY_AGG(DISTINCT protopayload_auditlog.authenticationInfo.principalEmail IGNORE NULLS) AS actors,
    COUNT(*) AS counter
  FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_activity`
  WHERE
    timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 90 DAY)
    AND protopayload_auditlog.methodName LIKE "v1.compute.firewalls.%"
    AND protopayload_auditlog.methodName NOT IN ("v1.compute.firewalls.list", "v1.compute.firewalls.get")
  GROUP BY
    day
)
WHERE TRUE
QUALIFY
  counter > avg + 2 * stddev
  AND day >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY) 
ORDER BY
  counter DESC

האם נמחקו מכונות וירטואליות בשבוע האחרון?

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

ניתוח נתוני ניראות

SELECT
  timestamp,
  JSON_VALUE(resource.labels.instance_id) AS instance_id,
  proto_payload.audit_log.authentication_info.principal_email, 
  proto_payload.audit_log.resource_name,
  proto_payload.audit_log.method_name
FROM 
  `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  resource.type = "gce_instance"
  AND proto_payload.audit_log.method_name = "v1.compute.instances.delete"
  AND operation.first IS TRUE
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
ORDER BY
  timestamp desc,
  instance_id
LIMIT
  1000

BigQuery

SELECT
  timestamp,
  resource.labels.instance_id,
  protopayload_auditlog.authenticationInfo.principalEmail,
  protopayload_auditlog.resourceName,
  protopayload_auditlog.methodName
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_activity`
WHERE
  resource.type = "gce_instance"
  AND protopayload_auditlog.methodName = "v1.compute.instances.delete"
  AND operation.first IS TRUE
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
ORDER BY
  timestamp desc,
  resource.labels.instance_id
LIMIT
  1000

שאלות לגבי שימוש בעומסי עבודה

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

האם היה שימוש חריג ב-API על ידי זהות משתמש כלשהי בשבוע האחרון?

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

ניתוח נתוני ניראות

SELECT
  *
FROM (
  SELECT
    *,
    AVG(counter) OVER (
      PARTITION BY principal_email
      ORDER BY day
      ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING) AS avg,
    STDDEV(counter) OVER (
      PARTITION BY principal_email
      ORDER BY day
      ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING) AS stddev,
    COUNT(*) OVER (
      PARTITION BY principal_email
      RANGE BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) AS numSamples
  FROM (
    SELECT
      proto_payload.audit_log.authentication_info.principal_email,
      EXTRACT(DATE FROM timestamp) AS day,
      ARRAY_AGG(DISTINCT proto_payload.audit_log.method_name IGNORE NULLS) AS actions,
      COUNT(*) AS counter
    FROM `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
    WHERE
      timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 60 DAY)
      AND proto_payload.audit_log.authentication_info.principal_email IS NOT NULL
      AND proto_payload.audit_log.method_name NOT LIKE "storage.%.get"
      AND proto_payload.audit_log.method_name NOT LIKE "v1.compute.%.list"
      AND proto_payload.audit_log.method_name NOT LIKE "beta.compute.%.list"
    GROUP BY
      proto_payload.audit_log.authentication_info.principal_email,
      day
  )
)
WHERE
  counter > avg + 3 * stddev
  AND day >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY) 
ORDER BY
  counter DESC

BigQuery

SELECT
  *,
  AVG(counter) OVER (
    PARTITION BY principalEmail
    ORDER BY day
    ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING) AS avg,
  STDDEV(counter) OVER (
    PARTITION BY principalEmail
    ORDER BY day
    ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING) AS stddev,
  COUNT(*) OVER (
    PARTITION BY principalEmail
    RANGE BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) AS numSamples
FROM (
  SELECT
    protopayload_auditlog.authenticationInfo.principalEmail,
    EXTRACT(DATE FROM timestamp) AS day,
    ARRAY_AGG(DISTINCT protopayload_auditlog.methodName IGNORE NULLS) AS actions,
    COUNT(*) AS counter
  FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_*`
  WHERE
    timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 60 DAY)
    AND protopayload_auditlog.authenticationInfo.principalEmail IS NOT NULL
    AND protopayload_auditlog.methodName NOT LIKE "storage.%.get"
    AND protopayload_auditlog.methodName NOT LIKE "v1.compute.%.list"
    AND protopayload_auditlog.methodName NOT LIKE "beta.compute.%.list"
  GROUP BY
    protopayload_auditlog.authenticationInfo.principalEmail,
    day
)
WHERE TRUE
QUALIFY
  counter > avg + 3 * stddev
  AND day >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY) 
ORDER BY
  counter DESC

מהו השימוש בהתאמה אוטומטית לעומס לכל יום בחודש האחרון?

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

ניתוח נתוני ניראות

SELECT
  TIMESTAMP_TRUNC(timestamp, DAY) AS day,
  proto_payload.audit_log.method_name,
  COUNT(*) AS counter
FROM
   `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  resource.type = "gce_instance_group_manager"
  AND log_id = "cloudaudit.googleapis.com/activity"
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY
  1, 2
ORDER BY
  1, 2

BigQuery

SELECT
  TIMESTAMP_TRUNC(timestamp, DAY) AS day,
  protopayload_auditlog.methodName AS methodName,
  COUNT(*) AS counter
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_activity`
WHERE
  resource.type = "gce_instance_group_manager"
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY
  1, 2
ORDER BY
  1, 2

שאלות בנושא גישה לנתונים

השאילתות לדוגמה האלה מבצעות ניתוח כדי להבין מי ניגש לנתונים ב- Google Cloudאו משנה אותם.

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

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

ניתוח נתוני ניראות

SELECT
  proto_payload.audit_log.authentication_info.principal_email,
  COUNT(*) AS COUNTER
FROM 
   `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  (proto_payload.audit_log.method_name = "google.cloud.bigquery.v2.JobService.InsertJob" OR
   proto_payload.audit_log.method_name = "google.cloud.bigquery.v2.JobService.Query")
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
  AND log_id = "cloudaudit.googleapis.com/data_access"
GROUP BY
  1
ORDER BY
  2 desc, 1
LIMIT
  100

BigQuery

SELECT
  protopayload_auditlog.authenticationInfo.principalEmail,
  COUNT(*) AS COUNTER
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_data_access`
WHERE
  (protopayload_auditlog.methodName = "google.cloud.bigquery.v2.JobService.InsertJob" OR
   protopayload_auditlog.methodName = "google.cloud.bigquery.v2.JobService.Query")
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
GROUP BY
  1
ORDER BY
  2 desc, 1
LIMIT
  100

אילו משתמשים ניגשו לנתונים בטבלה 'חשבונות' בחודש שעבר?

השאילתה הבאה משתמשת ביומני ביקורת של גישה לנתונים כדי למצוא את זהויות המשתמשים ששלחו הכי הרבה שאילתות לטבלה מסוימת accounts בחודש האחרון. בנוסף למחזיקי המקום MY_DATASET_ID ו-MY_PROJECT_ID של יעד הייצוא של BigQuery, השאילתה הבאה משתמשת במחזיקי המקום DATASET_ID ו-PROJECT_ID. צריך להחליף את מחזיקי המקום DATASET_ID ו-PROJECT_ID כדי לציין את טבלת היעד שהגישה אליה מנותחת, כמו הטבלה accounts בדוגמה הזו.

ניתוח נתוני ניראות

SELECT
  proto_payload.audit_log.authentication_info.principal_email,
  COUNT(*) AS COUNTER
FROM 
  `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`,
  UNNEST(proto_payload.audit_log.authorization_info) authorization_info
WHERE
  (proto_payload.audit_log.method_name = "google.cloud.bigquery.v2.JobService.InsertJob" OR
   proto_payload.audit_log.method_name = "google.cloud.bigquery.v2.JobService.Query")
  AND authorization_info.permission = "bigquery.tables.getData"
  AND authorization_info.resource = "projects/[PROJECT_ID]/datasets/[DATASET_ID]/tables/accounts"
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY
  1
ORDER BY
  2 desc, 1
LIMIT
  100

BigQuery

SELECT
  protopayload_auditlog.authenticationInfo.principalEmail,
  COUNT(*) AS COUNTER
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_data_access`,
  UNNEST(protopayload_auditlog.authorizationInfo) authorizationInfo
WHERE
  (protopayload_auditlog.methodName = "google.cloud.bigquery.v2.JobService.InsertJob" OR
   protopayload_auditlog.methodName = "google.cloud.bigquery.v2.JobService.Query")
  AND authorizationInfo.permission = "bigquery.tables.getData"
  AND authorizationInfo.resource = "projects/[PROJECT_ID]/datasets/[DATASET_ID]/tables/accounts"
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY
  1
ORDER BY
  2 desc, 1
LIMIT
  100

אילו טבלאות נגישות בתדירות הכי גבוהה, ומי ניגש אליהן?

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

ניתוח נתוני ניראות

SELECT
  proto_payload.audit_log.resource_name,
  proto_payload.audit_log.authentication_info.principal_email,
  COUNTIF(JSON_VALUE(proto_payload.audit_log.metadata, "$.tableDataRead") IS NOT NULL) AS dataReadEvents,
  COUNTIF(JSON_VALUE(proto_payload.audit_log.metadata, "$.tableDataChange") IS NOT NULL) AS dataChangeEvents,
  COUNT(*) AS totalEvents
FROM 
  `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  STARTS_WITH(resource.type, 'bigquery') IS TRUE
  AND (JSON_VALUE(proto_payload.audit_log.metadata, "$.tableDataRead") IS NOT NULL
    OR JSON_VALUE(proto_payload.audit_log.metadata, "$.tableDataChange") IS NOT NULL)
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY
  1, 2
ORDER BY
  5 DESC, 1, 2
LIMIT 1000

BigQuery

SELECT
  protopayload_auditlog.resourceName,
  protopayload_auditlog.authenticationInfo.principalEmail,
  COUNTIF(JSON_EXTRACT(protopayload_auditlog.metadataJson, "$.tableDataRead") IS NOT NULL) AS dataReadEvents,
  COUNTIF(JSON_EXTRACT(protopayload_auditlog.metadataJson, "$.tableDataChange") IS NOT NULL) AS dataChangeEvents,
  COUNT(*) AS totalEvents
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_data_access`
WHERE
  STARTS_WITH(resource.type, 'bigquery') IS TRUE
  AND (JSON_EXTRACT(protopayload_auditlog.metadataJson, "$.tableDataRead") IS NOT NULL
    OR JSON_EXTRACT(protopayload_auditlog.metadataJson, "$.tableDataChange") IS NOT NULL)
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY
  1, 2
ORDER BY
  5 DESC, 1, 2
LIMIT 1000

מהן 10 השאילתות המובילות ב-BigQuery בשבוע האחרון?

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

ניתוח נתוני ניראות

SELECT
  COALESCE(
   JSON_VALUE(proto_payload.audit_log.metadata, "$.jobChange.job.jobConfig.queryConfig.query"),
   JSON_VALUE(proto_payload.audit_log.metadata, "$.jobInsertion.job.jobConfig.queryConfig.query")) as query,
  STRING_AGG(DISTINCT proto_payload.audit_log.authentication_info.principal_email, ',') as users,
  ANY_VALUE(COALESCE(
   JSON_EXTRACT_ARRAY(proto_payload.audit_log.metadata, "$.jobChange.job.jobStats.queryStats.referencedTables"),
   JSON_EXTRACT_ARRAY(proto_payload.audit_log.metadata, "$.jobInsertion.job.jobStats.queryStats.referencedTables"))) as tables,
  COUNT(*) AS counter
FROM 
  `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  (resource.type = 'bigquery_project' OR resource.type = 'bigquery_dataset')
  AND operation.last IS TRUE
  AND (JSON_VALUE(proto_payload.audit_log.metadata, "$.jobChange") IS NOT NULL
    OR JSON_VALUE(proto_payload.audit_log.metadata, "$.jobInsertion") IS NOT NULL)
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
GROUP BY
  query
ORDER BY
  counter DESC
LIMIT 10

BigQuery

SELECT
  COALESCE(
   JSON_EXTRACT_SCALAR(protopayload_auditlog.metadataJson, "$.jobChange.job.jobConfig.queryConfig.query"),
   JSON_EXTRACT_SCALAR(protopayload_auditlog.metadataJson, "$.jobInsertion.job.jobConfig.queryConfig.query")) as query,
  STRING_AGG(DISTINCT protopayload_auditlog.authenticationInfo.principalEmail, ',') as users,
  ANY_VALUE(COALESCE(
   JSON_EXTRACT_ARRAY(protopayload_auditlog.metadataJson, "$.jobChange.job.jobStats.queryStats.referencedTables"),
   JSON_EXTRACT_ARRAY(protopayload_auditlog.metadataJson, "$.jobInsertion.job.jobStats.queryStats.referencedTables"))) as tables,
  COUNT(*) AS counter
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_data_access`
WHERE
  (resource.type = 'bigquery_project' OR resource.type = 'bigquery_dataset')
  AND operation.last IS TRUE
  AND (JSON_EXTRACT(protopayload_auditlog.metadataJson, "$.jobChange") IS NOT NULL
    OR JSON_EXTRACT(protopayload_auditlog.metadataJson, "$.jobInsertion") IS NOT NULL)
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
GROUP BY
  query
ORDER BY
  counter DESC
LIMIT 10

מהן הפעולות הנפוצות ביותר שתועדו ביומן הגישה לנתונים בחודש האחרון?

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

ניתוח נתוני ניראות

SELECT
  proto_payload.audit_log.method_name,
  proto_payload.audit_log.service_name,
  resource.type,
  COUNT(*) AS counter
FROM `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND log_id="cloudaudit.googleapis.com/data_access"
GROUP BY
  proto_payload.audit_log.method_name,
  proto_payload.audit_log.service_name,
  resource.type
ORDER BY
  counter DESC
LIMIT 100

BigQuery

SELECT
  protopayload_auditlog.methodName,
  protopayload_auditlog.serviceName,
  resource.type,
  COUNT(*) AS counter
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_data_access`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY
  protopayload_auditlog.methodName,
  protopayload_auditlog.serviceName,
  resource.type
ORDER BY
  counter DESC
LIMIT 100

שאלות בנושא אבטחת רשת

שאילתות לדוגמה שמבצעות ניתוח של פעילות הרשת ב- Google Cloud.

האם יש חיבורים מכתובת IP חדשה לרשת משנה ספציפית?

השאילתה הבאה מזהה חיבורים מכל כתובת IP חדשה של מקור לרשת משנה נתונה, על ידי ניתוח יומני זרימה של VPC. בדוגמה הזו, כתובת IP של מקור נחשבת חדשה אם היא נראתה בפעם הראשונה ב-24 השעות האחרונות בחלון מבט לאחור של 60 יום. מומלץ להשתמש בשאילתה הזו ולכוונן אותה ברשת משנה שנכללת בהיקף של דרישת תאימות מסוימת, כמו PCI.

ניתוח נתוני ניראות

SELECT
  JSON_VALUE(json_payload.connection.src_ip) as src_ip,
  -- TIMESTAMP supports up to 6 digits of fractional precision, so drop any more digits to avoid parse errors
  MIN(TIMESTAMP(REGEXP_REPLACE(JSON_VALUE(json_payload.start_time), r'\.(\d{0,6})\d+(Z)?$', '.\\1\\2'))) AS firstInstance,
  MAX(TIMESTAMP(REGEXP_REPLACE(JSON_VALUE(json_payload.start_time), r'\.(\d{0,6})\d+(Z)?$', '.\\1\\2'))) AS lastInstance,
  ARRAY_AGG(DISTINCT JSON_VALUE(resource.labels.subnetwork_name)) as subnetNames,
  ARRAY_AGG(DISTINCT JSON_VALUE(json_payload.dest_instance.vm_name)) as vmNames,
  COUNT(*) numSamples
FROM `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 60 DAY)
  AND JSON_VALUE(json_payload.reporter) = 'DEST'
  AND JSON_VALUE(resource.labels.subnetwork_name) IN ('prod-customer-data')
GROUP BY
  src_ip
HAVING firstInstance >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY)
ORDER BY
  lastInstance DESC,
  numSamples DESC

BigQuery

SELECT
  jsonPayload.connection.src_ip as src_ip,
  -- TIMESTAMP supports up to 6 digits of fractional precision, so drop any more digits to avoid parse errors
  MIN(TIMESTAMP(REGEXP_REPLACE(jsonPayload.start_time, r'\.(\d{0,6})\d+(Z)?$', '.\\1\\2'))) AS firstInstance,
  MAX(TIMESTAMP(REGEXP_REPLACE(jsonPayload.start_time, r'\.(\d{0,6})\d+(Z)?$', '.\\1\\2'))) AS lastInstance,
  ARRAY_AGG(DISTINCT resource.labels.subnetwork_name) as subnetNames,
  ARRAY_AGG(DISTINCT jsonPayload.dest_instance.vm_name) as vmNames,
  COUNT(*) numSamples
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].compute_googleapis_com_vpc_flows`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 60 DAY)
  AND jsonPayload.reporter = 'DEST'
  AND resource.labels.subnetwork_name IN ('prod-customer-data')
GROUP BY
  src_ip
HAVING firstInstance >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY)
ORDER BY
  lastInstance DESC,
  numSamples DESC

האם יש חיבורים שנחסמו על ידי Google Cloud Armor?

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

ניתוח נתוני ניראות

SELECT
  timestamp,
  http_request.remote_ip,
  http_request.request_method,
  http_request.status,
  JSON_VALUE(json_payload.enforcedSecurityPolicy.name) AS security_policy_name,
  JSON_VALUE(resource.labels.backend_service_name) AS backend_service_name,
  http_request.request_url,
FROM `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND resource.type="http_load_balancer"
  AND JSON_VALUE(json_payload.statusDetails) = "denied_by_security_policy"
ORDER BY
  timestamp DESC

BigQuery

SELECT
  timestamp,
  httpRequest.remoteIp,
  httpRequest.requestMethod,
  httpRequest.status,
  jsonpayload_type_loadbalancerlogentry.enforcedsecuritypolicy.name,
  resource.labels.backend_service_name,
  httpRequest.requestUrl,
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].requests`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND resource.type="http_load_balancer"
  AND jsonpayload_type_loadbalancerlogentry.statusdetails = "denied_by_security_policy"
ORDER BY
  timestamp DESC

האם זוהו ב-Cloud IDS וירוסים או תוכנות זדוניות ברמת חומרה גבוהה?

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

ניתוח נתוני ניראות

SELECT
  JSON_VALUE(json_payload.alert_time) AS alert_time,
  JSON_VALUE(json_payload.name) AS name,
  JSON_VALUE(json_payload.details) AS details,
  JSON_VALUE(json_payload.application) AS application,
  JSON_VALUE(json_payload.uri_or_filename) AS uri_or_filename,
  JSON_VALUE(json_payload.ip_protocol) AS ip_protocol,
FROM `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND resource.type="ids.googleapis.com/Endpoint"
  AND JSON_VALUE(json_payload.alert_severity) IN ("HIGH", "CRITICAL")
  AND JSON_VALUE(json_payload.type) = "virus"
ORDER BY 
  timestamp DESC

BigQuery

SELECT
  jsonPayload.alert_time,
  jsonPayload.name,
  jsonPayload.details,
  jsonPayload.application,
  jsonPayload.uri_or_filename,
  jsonPayload.ip_protocol
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].ids_googleapis_com_threat`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND resource.type="ids.googleapis.com/Endpoint"
  AND jsonPayload.alert_severity IN ("HIGH", "CRITICAL")
  AND jsonPayload.type = "virus"
ORDER BY 
  timestamp DESC

מהם הדומיינים המובילים ברשת ה-VPC שלכם שנשלחו אליהם שאילתות ב-Cloud DNS?

השאילתה הבאה מציגה רשימה של 10 הדומיינים המובילים שנשלחו אליהם שאילתות ב-Cloud DNS מרשתות ה-VPC שלכם ב-60 הימים האחרונים. השאילתה הזו מניחה שהפעלתם את רישום היומנים של Cloud DNS עבור רשתות ה-VPC שלכם, כמו שמתואר בהוראות שמופיעות בקישור הפעלה בכלי להגדרת היקף היומנים.

ניתוח נתוני ניראות

SELECT
  JSON_VALUE(json_payload.queryName) AS query_name,
  COUNT(*) AS total_queries
FROM
  `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 60 DAY)
  AND log_id="dns.googleapis.com/dns_queries"
GROUP BY
  query_name
ORDER BY
  total_queries DESC
LIMIT
  10

BigQuery

SELECT
 jsonPayload.queryname AS query_name,
 COUNT(*) AS total_queries
FROM
 `[MY_PROJECT_ID].[MY_DATASET_ID].dns_googleapis_com_dns_queries`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 60 DAY)
GROUP BY
 query_name
ORDER BY
 total_queries DESC
LIMIT
 10

המאמרים הבאים

• כך מעבירים יומנים מ- Google Cloud ל-Splunk.

• איך מעבירים יומנים ל-Google Security Operations Google Cloud

• כדאי להעמיק את הקריאה ולהכיר דוגמאות לארכיטקטורות, תרשימים ושיטות מומלצות בנושאי Google Cloud. כל אלה זמינים במרכז הארכיטקטורה של Cloud.