תיקון שגיאות ב-Security Command Center

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

לפני שמתחילים

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

בדיקת הממצאים במסוף Google Cloud

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

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

כדי לעיין בממצאים במסוף Google Cloud :

  1. נכנסים לדף Findings ב-Security Command Center במסוף Google Cloud .

    כניסה לדף Findings

  2. בוחרים את Google Cloud הפרויקט או הארגון.
  3. בקטע Quick filters, בקטע המשנה Source display name, בוחרים באפשרות Security Command Center. תוצאות השאילתה של הממצאים מתעדכנות כך שיוצגו רק הממצאים מהמקור הזה.
  4. כדי לראות את הפרטים של ממצא ספציפי, לוחצים על שם הממצא בעמודה קטגוריה. נפתחת חלונית הפרטים של הממצא ומוצגת הכרטיסייה סיכום.
  5. בכרטיסייה סיכום, בודקים את פרטי הממצא, כולל מידע על מה שזוהה, המשאב המושפע ושלבים שאפשר לבצע כדי לפתור את הבעיה (אם יש כאלה).
  6. אופציונלי: כדי לראות את הגדרת ה-JSON המלאה של הממצא, לוחצים על הכרטיסייה JSON.

השבתה של שגיאות SCC אחרי תיקון

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

מידע על תדירות הסריקה של ממצא SCC error זמין בסיכום הממצא בגלאי שגיאות.

תיקון שגיאות ב-SCC

בקטע הזה מופיעות הוראות לתיקון כל השגיאות ב-SCC.

API disabled

שם הקטגוריה ב-API: API_DISABLED

אחד מהשירותים הבאים מושבת בפרויקט:

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

כדי לפתור את הבעיה, מבצעים את השלבים הבאים:

  1. בודקים את הממצא כדי לדעת איזה API מושבת.

  2. מפעילים את ה-API:

מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה

APS no resource value configs match any resources

שם הקטגוריה ב-API: APS_NO_RESOURCE_VALUE_CONFIGS_MATCH_ANY_RESOURCES

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

יכול להיות שההגדרות של ערכי המשאבים לא יתאימו לאף משאב מהסיבות הבאות, שמפורטות בתיאור הממצא במסוףGoogle Cloud :

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

כדי לפתור את הבעיה, מבצעים את השלבים הבאים:

  1. עוברים לדף Attack path simulation בהגדרות של Security Command Center:

    כניסה לדף Settings

  2. בוחרים את הארגון. הדף Attack path simulation נפתח עם ההגדרות הקיימות.

  3. בעמודה Resource value ברשימה Resource value configurations, בודקים אם יש ערכים של None.

  4. לכל הגדרה שצוין בה None, מבצעים את הפעולות הבאות:

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

  5. אם הבעיה לא נובעת ממפרט None רחב מדי, צריך לבצע את הפעולות הבאות:

    1. לוחצים על השמות של כל ההגדרות שבהן מצוין הערך HIGH,‏ MEDIUM או LOW כדי להציג את המפרטים של מאפייני המשאב.
    2. בודקים את ההגדרות ועורכים אותן לפי הצורך כדי לתקן את ההיקף, סוג המשאב, התג או התווית כך שיתאימו למשאבים הרצויים.

  6. במקרה הצורך, יוצרים הגדרה חדשה של ערך משאב.

השינויים יחולו על הסימולציה הבאה של נתיב התקיפה.

מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה

APS resource value assignment limit exceeded

שם הקטגוריה ב-API: APS_RESOURCE_VALUE_ASSIGNMENT_LIMIT_EXCEEDED

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

כדי לפתור את הבעיה הזו, אפשר לנסות את הפעולות הבאות:

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

  • יוצרים הגדרה של ערך משאב שמקצה ערך משאב של NONE לקבוצת משנה של המשאבים שצוינו בהגדרה אחרת.

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

  • צריך לצמצם את ההגדרה של מאפיין המשאב של ההיקף בהגדרת ערך המשאב.

  • מחיקת הגדרות של ערכי משאבים שמקצות ערך של LOW.

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

מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה

CIEM service account missing permissions

שם הקטגוריה ב-API: CIEM_SERVICE_ACCOUNT_MISSING_PERMISSIONS

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

כדי לפתור את הבעיה הזו, צריך לשחזר את תפקידי ה-IAM הנדרשים בחשבון השירות של CIEM:

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

    כניסה לדף IAM

  2. בוחרים את חשבון השירות של הארגון ב-CIEM. המזהה של חשבון השירות הוא כתובת אימייל בפורמט הבא:

    service-org-ORGANIZATION_ID@gcp-sa-ciem.iam.gserviceaccount.com

    מחליפים את ORGANIZATION_ID במזהה המספרי של הארגון.

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

  3. מקצים לחשבון השירות את התפקיד CIEM Service Agent (סוכן שירות CIEM) ‏(roles/ciem.serviceAgent). אם אתם משתמשים בתפקידים בהתאמה אישית, ודאו שהם כוללים את ההרשאות הבאות:

    • cloudasset.assets.exportResource
    • cloudasset.assets.exportIamPolicy

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

CIEM AWS CloudTrail configuration error

שם הקטגוריה ב-API: AWS_CLOUDTRAIL_CONFIGURATION_ERROR

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

יכולות להיות שלוש סיבות אפשריות לממצא הזה:

  • פיד חסר של AWS CloudTrail

    כדי לפתור את הבעיה, צריך ליצור ולהגדיר פיד במסוף Security Operations כדי להטמיע יומנים של AWS CloudTrail. מגדירים את צמד המפתח/ערך של תווית ההטמעה לערכים CIEM ו-TRUE.

    הוראות ליצירת פיד זמינות במאמר יצירת הפיד במסמכי התיעוד של Google SecOps.

  • שגיאות בהגדרת הפיד

    מוודאים שהגדרתם את הפיד בצורה נכונה.

    כדי להגדיר פיד, אפשר לעיין במאמר הגדרת פיד ב-Google Security Operations להטמעה של יומני AWS במסמכי התיעוד של Google SecOps.

  • ההגדרה של AWS CloudTrail לא הושלמה

    כדי לפתור את הבעיה, צריך להגדיר את קטגוריית S3 בהגדרות של AWS CloudTrail כך שיתועדו בה גם אירועי נתונים וגם אירועי ניהול מכל חשבונות AWS שבהם מתכוונים להשתמש ב-CIEM.

    הוראות להגדרה של CloudTrail מופיעות במאמר Configure AWS CloudTrail (or other service) (הגדרה של AWS CloudTrail (או שירות אחר)) במאמרי העזרה של Google SecOps.

External Exposure VPC Service Controls Restriction

שם הקטגוריה ב-API: EXTERNAL_EXPOSURE_VPC_SC_RESTRICTION

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

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

  • לארגונים או לתיקיות:

    service-RESOURCE_KEYWORD-RESOURCE_ID@gcp-sa-ee-hpsa.iam.gserviceaccount.com

  • לפרויקטים:

    service-project-PROJECT_NUMBER@gcp-sa-ee.iam.gserviceaccount.com

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

  • ‫RESOURCE_KEYWORD: מילת המפתח org או folder
  • ‫RESOURCE_ID: מזהה הארגון או מזהה התיקייה
  • ‫PROJECT_NUMBER: מספר הפרויקט

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

כדי לפתור את הממצא הזה, צריך להוסיף כלל כניסה לגבולות גזרה לשירות החוסם:

  1. נכנסים לדף VPC Service Controls במסוף Google Cloud .
  2. בוחרים את מדיניות חסימת הגישה ואת גבולות הגזרה לשירות.
  3. לוחצים על עריכה ואז על מדיניות כניסה.
  4. לוחצים על הוספת כלל תנועה נכנסת ומגדירים את הבלוק מאת:
    1. בקטע זהות, בוחרים באפשרות זהויות וקבוצות נבחרות.
    2. מזינים את כתובת האימייל של חשבון השירות של External Exposure.
    3. בשדה מקור, בוחרים באפשרות כל המקורות.
  5. מגדירים את החסימה של הכלל To:
    1. בקטע Project, בוחרים באפשרות All projects או בוחרים את הפרויקט הספציפי שמופיע בתוצאת הסריקה.
    2. בקטע Operations or IAM roles (פעולות או תפקידים ב-IAM), בוחרים באפשרות All operations (כל הפעולות).
  6. לוחצים על Save.

GKE service account missing permissions

שם הקטגוריה ב-API: GKE_SERVICE_ACCOUNT_MISSING_PERMISSIONS

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

כדי לפתור את הבעיה הזו, צריך לשחזר את חשבון השירות שמוגדר כברירת מחדל ב-GKE ולוודא שלחשבון השירות יש את התפקיד סוכן שירות של Kubernetes Engine (roles/container.serviceAgent).

מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה

KTD blocked by admission controller

שם הקטגוריה ב-API: KTD_BLOCKED_BY_ADMISSION_CONTROLLER

אי אפשר להפעיל את התכונה זיהוי איומים בקונטיינר באשכול כי בקר קבלה של צד שלישי מונע את הפריסה של אובייקט Kubernetes DaemonSet הנדרש.

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

בדיקת בקרת הכניסה

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

  1. בתיאור הממצא בפרטי הממצא ב Google Cloud מסוף, בודקים את הודעת השגיאה שכלולה מ-Kubernetes. הודעת השגיאה של Kubernetes צריכה להיות דומה להודעה הבאה:

    generic::failed_precondition: incompatible admission webhook:
admission webhook "example.webhook.sh" denied the request:
[example-constraint] you must provide labels: {"example-required-label"}.

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

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

    לסוכן השירות של זיהוי איומים בקונטיינר צריכה להיות אפשרות לנהל אובייקטים ספציפיים של Kubernetes.

מידע נוסף על השימוש בבקרי הרשאות עם זיהוי איומים בקונטיינר זמין במאמר PodSecurityPolicy ובקרי הרשאות.

אישור התיקון

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

  1. נכנסים לדף Workloads של Kubernetes Engine במסוף.

    מעבר לעומסי עבודה ב-Kubernetes

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

  3. בדף Workloads, מסננים את עומסי העבודה לפי שם האשכול.

  4. מחפשים את עומס העבודה container-watcher. אם container-watcher מופיע והסטטוס שלו הוא OK, התכונה 'זיהוי איומים בקונטיינר' פעילה.

KTD image pull failure

שם הקטגוריה ב-API: KTD_IMAGE_PULL_FAILURE

אי אפשר להפעיל את התכונה'זיהוי איומים במאגר' באשכול כי אי אפשר למשוך (להוריד) תמונת מאגר נדרשת מ-gcr.io, מארח התמונות של Container Registry.

יכולות להיות כמה סיבות לכך ששליפה או הורדה של קובץ אימג' של קונטיינר נכשלות.

כדאי לבדוק את הדברים הבאים:

  • מוודאים שהגדרות ה-VPC, ה-DNS או חומת האש לא חוסמות גישה לרשת מהאשכול למארח התמונות gcr.io.
  • אם האשכול פרטי, צריך לוודא שגישה פרטית ל-Google מופעלת כדי לאפשר גישה למארח התמונות gcr.io.
  • אם הגדרות הרשת והגישה הפרטית ל-Google לא גורמות לכשל, אפשר לעיין במסמכי פתרון הבעיות של GKE בנושא שגיאות ImagePullBackOff ו-ErrImagePull.

מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה

KTD service account missing permissions

שם הקטגוריה ב-API: KTD_SERVICE_ACCOUNT_MISSING_PERMISSIONS

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

כדי לפתור את הבעיה, מבצעים את השלבים הבאים:

  1. מקצים לחשבון השירות את התפקיד סוכן שירות של זיהוי איומים בקונטיינר (roles/containerthreatdetection.serviceAgent). מידע נוסף זמין במאמר הקצאת תפקיד יחיד.

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

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

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

מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה

Misconfigured Cloud Logging Export

שם הקטגוריה ב-API: MISCONFIGURED_CLOUD_LOGGING_EXPORT

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

כדי לפתור את הבעיה הזו, אפשר לבצע אחת מהפעולות הבאות:

מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה

VPC Service Controls Restriction

שם הקטגוריה ב-API: VPC_SC_RESTRICTION

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

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

service-RESOURCE_KEYWORD-RESOURCE_ID@security-center-api.iam.gserviceaccount.com

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

  • ‫RESOURCE_KEYWORD: מילת המפתח org או project, בהתאם למשאב שבבעלותו חשבון השירות

  • ‫RESOURCE_ID: אחת מהאפשרויות הבאות:

    • מזהה הארגון אם חשבון השירות הוא בבעלות הארגון
    • מספר הפרויקט אם חשבון השירות הוא בבעלות פרויקט

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

כדי לפתור את הבעיה הזו, פועלים לפי השלבים הבאים.

שלב 1: קובעים אילו גבולות גזרה לשירות חוסמים את Security Health Analytics

  1. מקבלים את המזהה הייחודי של VPC Service Controls ואת מזהה הפרויקט שמשויך לממצא:

    1. כדי לראות את פרטי הממצא, לוחצים על שם הקטגוריה שלו.
    2. בשדה Description (תיאור), מעתיקים את המזהה הייחודי של VPC Service Controls – לדוגמה, 5e4GI409D6BTWfOp_6C-uSwmTpOQWcmW82sfZW9VIdRhGO5pXyCJPQ.
    3. בשדה נתיב המשאב, מעתיקים את מזהה הפרויקט.

  2. מקבלים את מזהה מדיניות הגישה ואת השם של גבולות גזרה לשירות:

    1. נכנסים לדף Logs Explorer במסוף Google Cloud .

      כניסה לדף Logs Explorer

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

    3. בתיבת החיפוש, מזינים את המזהה הייחודי של השגיאה.

      חיפוש לפי מזהה ייחודי (UID) של שגיאה

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

    4. לוחצים על השגיאה שמופיעה.

    5. לוחצים על הרחבת שדות מקוננים.

    6. מעתיקים את הערך של השדה servicePerimeterName. הערך הוא בפורמט הבא:

      accessPolicies/ACCESS_POLICY/servicePerimeters/SERVICE_PERIMETER

      בדוגמה הזו, שם המשאב המלא של גבולות גזרה לשירות הוא accessPolicies/540107806624/servicePerimeters/vpc_sc_misconfigured.

      • ‫ACCESS_POLICY הוא מזהה מדיניות הגישה, לדוגמה 540107806624.

      • ‫SERVICE_PERIMETER הוא השם של גבולות הגזרה לשירות – לדוגמה, vpc_sc_misconfigured.

        השם המלא של המשאב של גבולות הגזרה לשירות

    7. כדי לקבל את השם לתצוגה שמתאים למזהה מדיניות הגישה, משתמשים ב-CLI של gcloud.

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

      gcloud access-context-manager policies list \
    --organization ORGANIZATION_ID

      מחליפים את ORGANIZATION_ID במזהה המספרי של הארגון.

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

      NAME          ORGANIZATION  SCOPES                 TITLE           ETAG
540107806624  549441802605                         default policy  2a9a7e30cbc14371
352948212018  549441802605  projects/393598488212  another_policy  d7b47a9ecebd4659

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

שלב 2: יצירת כללים לתעבורת נתונים נכנסת (ingress) ויוצאת (egress) שמעניקים גישה

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

בשלבים הבאים יוצרים כללים לתעבורת נתונים נכנסת ויוצאת בגבולות הגזרה לשירות שזוהו בשלב 1.

המסוף

  1. נכנסים לדף VPC Service Controls במסוף Google Cloud .

    מעבר אל VPC Service Controls

  2. בוחרים את הארגון.

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

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

  4. לוחצים על השם של גבולות גזרה לשירות שרוצים לעדכן.

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

    accessPolicies/ACCESS_POLICY_ID/servicePerimeters/SERVICE_PERIMETER_NAME
  5. לוחצים על עריכה.

הוספת כלל לתעבורת נתונים יוצאת

  1. לוחצים על Egress policy.
  2. לוחצים על הוספת כלל ליציאה.

  3. בקטע מאת, מגדירים את הפרטים הבאים:

    1. בקטע זהויות > זהות, בוחרים באפשרות בחירת זהויות וקבוצות.
    2. לוחצים על הוספת זהויות.

    3. מזינים את כתובת האימייל שמזהה את סוכן השירות של Cloud Security Command Center. הכתובת הזו היא בפורמט הבא: 

      service-org-ORGANIZATION_ID@security-center-api.iam.gserviceaccount.com

      מחליפים את ORGANIZATION_ID במזהה הארגון.

    4. בוחרים את סוכן השירות או לוחצים על ENTER, ואז לוחצים על הוספת זהויות.

  4. בקטע To (אל), מגדירים את הפרטים הבאים:

    1. בקטע Resources > Projects (משאבים > פרויקטים), בוחרים באפשרות All projects (כל הפרויקטים) או בוחרים את הפרויקט שצוין בממצא.
    2. בקטע Operations or IAM roles (פעולות או תפקידי IAM), בוחרים באפשרות Select operations (בחירת פעולות).

    3. לוחצים על הוספת פעולות ומוסיפים את הפעולות הבאות:

      • מוסיפים את השירות bigquery.googleapis.com.
        1. לוחצים על כל השיטות.
        2. לוחצים על הוספת כל האמצעים.
      • מוסיפים את השירות binaryauthorization.googleapis.com.
        1. לוחצים על כל השיטות.
        2. לוחצים על הוספת כל האמצעים.
      • מוסיפים את השירות cloudkms.googleapis.com.
        1. לוחצים על כל השיטות.
        2. לוחצים על הוספת כל האמצעים.
      • מוסיפים את השירות logging.googleapis.com.
        1. לוחצים על כל השיטות.
        2. לוחצים על הוספת כל האמצעים.
      • מוסיפים את השירות monitoring.googleapis.com.
        1. לוחצים על כל השיטות.
        2. לוחצים על הוספת כל האמצעים.
      • מוסיפים את השירות cloudresourcemanager.googleapis.com.
        1. לוחצים על כל השיטות.
        2. לוחצים על הוספת כל האמצעים.
      • מוסיפים את השירות storage.googleapis.com.
        1. לוחצים על כל השיטות.
        2. לוחצים על הוספת כל האמצעים.
      • מוסיפים את השירות compute.googleapis.com.
        1. לוחצים על כל השיטות.
        2. לוחצים על הוספת כל האמצעים.
      • מוסיפים את השירות iam.googleapis.com.
        1. לוחצים על כל השיטות.
        2. לוחצים על הוספת כל האמצעים.
      • מוסיפים את השירות container.googleapis.com.
        1. לוחצים על כל השיטות.
        2. לוחצים על הוספת כל האמצעים.

הוספת כלל לכניסת תנועה

  1. לוחצים על Ingress policy (מדיניות כניסה).
  2. לוחצים על הוספת כלל תעבורה נכנסת.

  3. בקטע מאת, מגדירים את הפרטים הבאים:

    1. בקטע זהויות > זהות, בוחרים באפשרות בחירת זהויות וקבוצות.
    2. לוחצים על הוספת זהויות.

    3. מזינים את כתובת האימייל שמזהה את סוכן השירות של Cloud Security Command Center. הכתובת הזו היא בפורמט הבא: 

      service-org-ORGANIZATION_ID@security-center-api.iam.gserviceaccount.com

      מחליפים את ORGANIZATION_ID במזהה הארגון.

    4. בוחרים את סוכן השירות או לוחצים על ENTER, ואז לוחצים על הוספת זהויות.

  4. בקטע To (אל), מגדירים את הפרטים הבאים:

    1. בקטע Resources > Projects (משאבים > פרויקטים), בוחרים באפשרות All projects (כל הפרויקטים) או בוחרים את הפרויקט שצוין בממצא.
    2. בקטע Operations or IAM roles (פעולות או תפקידי IAM), בוחרים באפשרות Select operations (בחירת פעולות).

    3. לוחצים על הוספת פעולות ומוסיפים את הפעולות הבאות:

      • מוסיפים את השירות bigquery.googleapis.com.
        1. לוחצים על כל השיטות.
        2. לוחצים על הוספת כל האמצעים.
      • מוסיפים את השירות binaryauthorization.googleapis.com.
        1. לוחצים על כל השיטות.
        2. לוחצים על הוספת כל האמצעים.
      • מוסיפים את השירות cloudkms.googleapis.com.
        1. לוחצים על כל השיטות.
        2. לוחצים על הוספת כל האמצעים.
      • מוסיפים את השירות logging.googleapis.com.
        1. לוחצים על כל השיטות.
        2. לוחצים על הוספת כל האמצעים.
      • מוסיפים את השירות monitoring.googleapis.com.
        1. לוחצים על כל השיטות.
        2. לוחצים על הוספת כל האמצעים.
      • מוסיפים את השירות cloudresourcemanager.googleapis.com.
        1. לוחצים על כל השיטות.
        2. לוחצים על הוספת כל האמצעים.
      • מוסיפים את השירות storage.googleapis.com.
        1. לוחצים על כל השיטות.
        2. לוחצים על הוספת כל האמצעים.
      • מוסיפים את השירות compute.googleapis.com.
        1. לוחצים על כל השיטות.
        2. לוחצים על הוספת כל האמצעים.
      • מוסיפים את השירות iam.googleapis.com.
        1. לוחצים על כל השיטות.
        2. לוחצים על הוספת כל האמצעים.
      • מוסיפים את השירות container.googleapis.com.
        1. לוחצים על כל השיטות.
        2. לוחצים על הוספת כל האמצעים.
  5. לוחצים על Save.

gcloud

  1. אם עדיין לא הגדרתם פרויקט מכסת מכסות, צריך להגדיר אותו. בוחרים פרויקט שמופעל בו Access Context Manager API. 

    gcloud config set billing/quota_project QUOTA_PROJECT_ID

    מחליפים את QUOTA_PROJECT_ID במזהה הפרויקט שבו רוצים להשתמש לחיוב ולמכסה.

  2. יוצרים קובץ בשם egress-rule.yaml עם התוכן הבא:

    - egressFrom:
    identities:
    - serviceAccount:service-org-ORGANIZATION_ID@security-center-api.iam.gserviceaccount.com
  egressTo:
    operations:
    - serviceName: bigquery.googleapis.com
      methodSelectors:
      - method: '*'
    - serviceName: binaryauthorization.googleapis.com
      methodSelectors:
      - method: '*'
    - serviceName: cloudkms.googleapis.com
      methodSelectors:
      - method: '*'
    - serviceName: logging.googleapis.com
      methodSelectors:
      - method: '*'
    - serviceName: monitoring.googleapis.com
      methodSelectors:
      - method: '*'
    - serviceName: cloudresourcemanager.googleapis.com
      methodSelectors:
      - method: '*'
    - serviceName: storage.googleapis.com
      methodSelectors:
      - method: '*'
    - serviceName: compute.googleapis.com
      methodSelectors:
      - method: '*'
    - serviceName: iam.googleapis.com
      methodSelectors:
      - method: '*'
    - serviceName: container.googleapis.com
      methodSelectors:
      - method: '*'
    resources:
    - '*'

    לחלופין, אפשר להשתמש ב-operations כדי לציין את השירותים שבהם מופיעות הפרות של VPC Service Controls, וב-resources כדי לציין את הפרויקט שהופיע בתוצאה.

    מחליפים את ORGANIZATION_ID במזהה הארגון.

  3. יוצרים קובץ בשם ingress-rule.yaml עם התוכן הבא:

    - ingressFrom:
    identities:
    - serviceAccount:service-org-ORGANIZATION_ID@security-center-api.iam.gserviceaccount.com
    sources:
    - accessLevel: '*'
  ingressTo:
    operations:
    - serviceName: bigquery.googleapis.com
      methodSelectors:
      - method: '*'
    - serviceName: binaryauthorization.googleapis.com
      methodSelectors:
      - method: '*'
    - serviceName: cloudkms.googleapis.com
      methodSelectors:
      - method: '*'
    - serviceName: logging.googleapis.com
      methodSelectors:
      - method: '*'
    - serviceName: monitoring.googleapis.com
      methodSelectors:
      - method: '*'
    - serviceName: cloudresourcemanager.googleapis.com
      methodSelectors:
      - method: '*'
    - serviceName: storage.googleapis.com
      methodSelectors:
      - method: '*'
    - serviceName: compute.googleapis.com
      methodSelectors:
      - method: '*'
    - serviceName: iam.googleapis.com
      methodSelectors:
      - method: '*'
    - serviceName: container.googleapis.com
      methodSelectors:
      - method: '*'
    resources:
    - '*'

    לחלופין, אפשר להשתמש ב-operations כדי לציין את השירותים שבהם מופיעות הפרות של VPC Service Controls, וב-resources כדי לציין את הפרויקט שהופיע בתוצאה.

    מחליפים את ORGANIZATION_ID במזהה הארגון.

  4. מוסיפים את כלל היציאה להיקף:

    gcloud access-context-manager perimeters update PERIMETER_NAME \
    --set-egress-policies=egress-rule.yaml

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

    • ‫PERIMETER_NAME: שם ההיקף. לדוגמה, accessPolicies/1234567890/servicePerimeters/example_perimeter.

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

      accessPolicies/ACCESS_POLICY_ID/servicePerimeters/SERVICE_PERIMETER_NAME

  5. מוסיפים את כלל הכניסה להיקף:

    gcloud access-context-manager perimeters update PERIMETER_NAME \
    --set-ingress-policies=ingress-rule.yaml

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

    • ‫PERIMETER_NAME: שם ההיקף. לדוגמה, accessPolicies/1234567890/servicePerimeters/example_perimeter.

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

      accessPolicies/ACCESS_POLICY_ID/servicePerimeters/SERVICE_PERIMETER_NAME

מידע נוסף זמין במאמר בנושא כללי כניסה ויציאה.

שירותים ש-Security Health Analytics קורא להם

כדי לפעול בצורה תקינה, ל-Security Health Analytics נדרשת גישה ל- Google Cloud API של השירותים שהיא סורקת, וגם לשירותי תשתית ליבה. בהתאם להגדרה שלכם, יכול להיות שתצטרכו לאפשר תעבורת נתונים נכנסת (ingress) או יוצאת (egress) לשירותים הבאים בגבולות הגזרה של VPC Service Controls:

  • ‫BigQuery API‏ (bigquery.googleapis.com)
  • ‫Binary Authorization API ‏ (binaryauthorization.googleapis.com)
  • Cloud Key Management Service API ‏ (cloudkms.googleapis.com)
  • Cloud Logging API (logging.googleapis.com)
  • Cloud Monitoring API ‏ (monitoring.googleapis.com)
  • Cloud Resource Manager API‏ (cloudresourcemanager.googleapis.com)
  • Cloud Storage API (storage.googleapis.com)
  • ‫Compute Engine API ‏ (compute.googleapis.com)
  • ‫Identity and Access Management API‏ (iam.googleapis.com)
  • ‫Kubernetes Engine API ‏ (container.googleapis.com)

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

מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה

Security Command Center service account missing permissions

שם הקטגוריה ב-API: SCC_SERVICE_ACCOUNT_MISSING_PERMISSIONS

לסוכן השירות של Security Command Center חסרות ההרשאות שנדרשות כדי שהשירות יפעל כמו שצריך.

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

service-RESOURCE_KEYWORD-RESOURCE_ID@security-center-api.iam.gserviceaccount.com

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

  • ‫RESOURCE_KEYWORD: מילת המפתח org או project, בהתאם למשאב שבבעלותו חשבון השירות

  • ‫RESOURCE_ID: אחת מהאפשרויות הבאות:

    • מזהה הארגון אם חשבון השירות הוא בבעלות הארגון
    • מספר הפרויקט אם חשבון השירות הוא בבעלות פרויקט

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

כדי לפתור את הבעיה, מבצעים את השלבים הבאים:

  1. מקצים לחשבון השירות את התפקיד 'סוכן שירות של Security Center' (roles/securitycenter.serviceAgent).

    מידע נוסף זמין במאמר הקצאת תפקיד יחיד.

    אפשרות אחרת היא להשתמש בתפקיד בהתאמה אישית, אבל צריך לוודא שיש לו את ההרשאות שכלולות בתפקיד Security Center Service Agent.

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

מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה

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

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