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

Last reviewed 2025-10-08 UTC

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

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

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

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

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

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

התרשים מתחיל עם מקורות הנתונים הבאים בנושא אבטחה: יומנים מ-Cloud Logging, שינויים בנכסים ממאגר משאבי ענן וממצאים בנושא אבטחה מ-Security Command Center. בתרשים מוצגים מקורות נתוני האבטחה האלה שמנותבים לכלי לניתוח אבטחה שתבחרו: Log 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 ליומנים שהם מסתמכים עליהם. אתם יכולים להשתמש בכלי להגדרת היקף היומן כדי להעריך יומנים בלי קשר לכלי הניתוח שבו אתם משתמשים.

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

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

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

  במדריך הזה תמצאו שאילתות SQL שתוכלו להשתמש בהן כדי לנתח את היומנים ב-Log 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.

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

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

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

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

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

   export LOG_FILTER='LOG_FILTER'
   

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

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

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

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

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

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, אפשר גם להגדיר אילו סוגים של פעולות יתועדו. יש שלושה סוגים של יומני ביקורת Data Access:

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

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

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

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

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

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

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

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

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

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

דוגמה להגדרת יומן ביקורת של גישה לנתונים

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

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

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

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

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

יומני ניתוב

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

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

• אם אתם משתמשים ב-Log Analytics, אתם צריכים aggregated 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, הדיאגרמה מראה שנדרש שלב נוסף בין הפעלת היומנים לבין ניתוח שלהם. השלב הנוסף הזה כולל הגדרה של מאגר נתונים משולב שמנתב את היומנים שנבחרו בצורה מתאימה. אם אתם משתמשים ב-BigQuery, זהו יעד ההעברה היחיד שאתם צריכים כדי להעביר את היומנים ל-BigQuery. אם אתם משתמשים ב-SIEM של צד שלישי, אתם צריכים לוודא שהיעד יצבור את היומנים שנבחרו ב-Pub/Sub או ב-Cloud Storage לפני שתוכלו למשוך את היומנים לכלי הניתוח שלכם.

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

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

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

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

Log Analytics

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

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

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

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

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

Log Analytics

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

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

Log Analytics

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

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, מזינים את המיקום והשם של דלי האחסון באופן הבא:

    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 כדי לנהל את ההרשאות ולתת גישה לפי הצורך.

Log Analytics

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

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, צריך לפעול לפי השלבים שבקטע Granting access to a dataset (מתן גישה למערך נתונים) במאמר בנושא BigQuery.

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

Log Analytics

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

1. במסוף Google Cloud , עוברים לדף Log Analytics:

   מעבר אל Log Analytics

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

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

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

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

   

5. לצד _AllLogs, לוחצים על שאילתה . פעולה זו מאכלסת את Query editor בשאילתת 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 תואמת: אחת לשימוש ב-Log Analytics ואחת לשימוש ב-BigQuery. משתמשים בגרסת השאילתה שתואמת ליעד של מאגר הנתונים שקבעתם קודם.

Log Analytics

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

מעבר אל Log 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?
   • מהם הדומיינים המובילים שמתבצעות לגביהם שאילתות ב-Cloud DNS מרשת ה-VPC?

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

השאילתות לדוגמה האלה מבצעות ניתוח כדי לזהות ניסיונות התחברות חשודים או ניסיונות גישה ראשוניים לסביבה שלכם ב- 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.

Log Analytics

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 השעות האחרונות.

Log Analytics

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?

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

Log Analytics

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. תוצאות של שאילתות עשויות להצביע על ניסיון גישה ראשוני או על ניסיון ניצול של פגיעות.

Log Analytics

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]) רוצים לעקוב. יכול להיות שתוצאות של שאילתות יצביעו על העלאת הרשאות זדונית או לא מכוונת.

Log Analytics

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

Log Analytics

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

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

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

Log Analytics

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 או לשירות לקצה העורפי. תוצאות של שאילתות עשויות להצביע על ניסיונות לעקוף את אמצעי ההגנה של שירות קצה עורפי שעשוי להיות חשוף לאינטרנט.

Log Analytics

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

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

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

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

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

Log Analytics

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 שמושבתים באופן פעיל?

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

Log Analytics

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

Log Analytics

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

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

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

Log Analytics

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

Log Analytics

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

Log Analytics

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 בשבוע האחרון.

Log Analytics

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 מסוימת בחודש האחרון. בנוסף לערכי ה-placeholder‏ MY_DATASET_ID ו-MY_PROJECT_ID של יעד הייצוא ב-BigQuery, בשאילתה הבאה נעשה שימוש בערכי ה-placeholder‏ DATASET_ID ו-PROJECT_ID. צריך להחליף את ה-placeholders‏ DATASET_ID ו-PROJECT_ID כדי לציין את טבלת היעד שהגישה אליה מנותחת, כמו הטבלה accounts בדוגמה הזו.

Log Analytics

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

Log Analytics

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 בשבוע האחרון?

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

Log Analytics

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 הפעולות הכי נפוצות שנרשמו בחודש האחרון.

Log Analytics

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.

Log Analytics

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

Log Analytics

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.

Log Analytics

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 שלכם, כמו שמתואר בהוראות שמופיעות בקישור הפעלה בכלי להגדרת היקף היומן.

Log Analytics

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 Cloud של יומנים אל Google Security Operations.

• ייצוא Google Cloud נתוני אבטחה למערכת SIEM

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