שלבים לפתרון בעיות

בהמשך מפורטים שלבים לפתרון בעיות שיכולים לעזור לכם אם אתם נתקלים בבעיות הבאות במהלך השימוש ב-Security Command Center.

הפעלת Security Command Center נכשלת

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

  • לפני שמנסים להפעיל את Security Command Center, צריך לוודא שנכנסים לחשבון שנמצא בדומיין מותר.
  • אם אתם משתמשים בחשבון שירות @*.gserviceaccount.com, אתם צריכים להוסיף את חשבון השירות כזהות בקבוצה בדומיין מורשה.

הנכסים ב-Security Command Center לא מתעדכנים

אם אתם משתמשים ב-VPC Service Controls, אפשר לגלות ולעדכן נכסים ב-Security Command Center רק אם מעניקים גישה לחשבון השירות של Security Command Center.

כדי להפעיל את התכונה 'גילוי נכסים', צריך להעניק גישה לחשבון השירות של Security Command Center. כך חשבון השירות יכול להשלים את איתור הנכסים ולהציג אותם במסוף Google Cloud . השם של חשבון השירות הוא בפורמט service-org-organization-id@security-center-api.iam.gserviceaccount.com.

צפייה בממצאים ובנכסים, עריכה, יצירה ועדכון שלהם

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

התראות חסרות או שהגיעו באיחור

במקרים מסוימים, יכול להיות שההתראות לא יגיעו, יבוטלו או יתעכבו:

  • יכול להיות שאין ממצאים שתואמים למסננים בNotificationConfig. כדי לבדוק את ההתראות, משתמשים ב-Security Command Center API כדי ליצור ממצא.
  • לחשבון השירות של Security Command Center צריך להיות התפקיד securitycenter.notificationServiceAgent בנושא Pub/Sub. השם של חשבון השירות הוא בפורמט service-organization-id@gcp-sa-scc-notification.iam.gserviceaccount.com.
    • אם תסירו את התפקיד, פרסום ההתראות יושבת.
    • אם מסירים את התפקיד ואז מעניקים אותו שוב, ההתראות מתעכבות.
  • אם תמחקו את נושא ה-Pub/Sub ותיצרו אותו מחדש, ההתראות יימחקו.

External Exposure

בקטעים הבאים מתוארים שלבים לפתרון בעיות שיכולים לעזור לכם אם אתם נתקלים בבעיות או בתעבורת נתונים בלתי צפויה שקשורה ל-External Exposure.

עליות חדות ביומני הבקשות של 403 Forbidden מ-TsunamiSecurityScanner

אתם מבחינים בעליות חדות ולא צפויות ביומני הבקשות של HTTP 403 Forbidden או HTTP 401 Unauthorized בנקודות הקצה שפונות לציבור, כמו Cloud Run,‏ Google Kubernetes Engine‏ (GKE) או Cloud Load Balancing, עם סוכן המשתמש TsunamiSecurityScanner.

מטרה

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

אם נקודות הקצה או השירותים שלכם אוכפים בקרת גישה, כמו אימות של ניהול זהויות והרשאות גישה (IAM), שרת proxy לאימות זהויות (IAP) או מדיניות אבטחה של Google Cloud Armor, נקודות הקצה דוחות בקשות סורק לא מאומתות. הדחיות האלה יוצרות תגובת יומן HTTP 403 Forbidden או HTTP 401 Unauthorized. ההתנהגות הזו צפויה ומציינת שאמצעי הבקרה של האבטחה חוסמים גישה לא מאומתת.

אבחון ופתרון

כדי לאבחן ולפתור עליות חדות ביומני בקשות HTTP 403 Forbidden או HTTP 401 Unauthorized מ-TsunamiSecurityScanner, פועלים לפי השלבים הבאים:

  1. כדי לוודא שיומני בקשות ה-HTTP 403 מגיעים מהסורק, מריצים את השאילתה הבאה בדף Logs Explorer:

    httpRequest.userAgent="TsunamiSecurityScanner" AND httpRequest.status=403

  2. מוודאים שהשירותים שנסרקו נמצאים בפרויקטים שבהם התכונה 'External Exposure' פעילה. מידע נוסף על האופן שבו תנועת נתונים של סורקים מופיעה ביומנים זמין במאמר בנושא זיהוי תנועת נתונים של סורקים ביומנים.

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

    NOT httpRequest.userAgent="TsunamiSecurityScanner"

Web Security Scanner

בקטע הזה מפורטים שלבים לפתרון בעיות שיכולים לעזור לכם אם נתקלתם בבעיות בשימוש ב-Web Security Scanner.

שגיאות סריקה ב-Compute Engine וב-GKE

אם כתובת ה-URL של הסריקה מוגדרת בצורה שגויה, Web Security Scanner דוחה אותה. הסיבות האפשריות לדחייה:

כתובת ה-URL כוללת כתובת IP זמנית

מסמנים את כתובת ה-IP הזו כסטטית:

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

כתובת ה-URL ממופה לכתובת IP שגויה

כדי לפתור את הממצא הזה, צריך לעיין בהוראות של שירות רשם ה-DNS.

כתובת ה-URL ממופה לכתובת IP זמנית של אותה מכונה וירטואלית

מסמנים את כתובת ה-IP הזו כסטטית.

כתובת ה-URL ממופה לכתובת IP שמורה

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

כתובת ה-URL ממופה ליותר מכתובת IP אחת

מוודאים שכל כתובות ה-IP שממופות לכתובת ה-URL הזו שמורות לאותו פרויקט. אם יש לפחות כתובת IP אחת שלא שמורה לאותו פרויקט, הפעולה Scan Create או Edit או Update תיכשל.

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

מידע נוסף על שגיאות ב-Security Command Center