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

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

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

כדי לצפות בממצאים או לערוך אותם, וכדי לגשת למשאבים או לשנות אותם, אתם צריכים תפקידים מתאימים בניהול הזהויות והרשאות הגישה (IAM). Google Cloud אם נתקלתם בשגיאות הרשאה כשניסיתם לגשת ל-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. מגדירים את צמד המפתח/ערך של Ingestion label (תווית ההטמעה) לערכים 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. מגדירים את חסימת הכלל אל:
    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. אם בקרת הכניסה פועלת, אבל היא דוחה את הפריסה של אובייקט Container Threat Detection 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. מקצים לחשבון השירות את התפקיד Container Threat Detection Service Agent (סוכן שירות של זיהוי איומים בקונטיינר) (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. בשדה Resource path (נתיב המשאב), מעתיקים את מזהה הפרויקט.

  2. מקבלים את מזהה מדיניות הגישה ואת השם של היקף ה-Service Control:

    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 הוא השם של service perimeter – לדוגמה, vpc_sc_misconfigured.

        השם המלא של המשאב של service perimeter

    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) שמעניק גישה לפרויקט

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

בשלבים הבאים יוצרים כלל תעבורת נתונים נכנסת (ingress) בגבולות גזרה לשירות שזיהיתם בשלב 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. לוחצים על 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), בוחרים באפשרות All operations (כל הפעולות) או בוחרים שירותים ספציפיים שבהם מופיעות הפרות של VPC Service Controls.
  5. לוחצים על Save.

gcloud

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

    gcloud config set billing/quota_project QUOTA_PROJECT_ID

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

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

    - ingressFrom:
    identities:
    - serviceAccount:service-org-ORGANIZATION_ID@security-center-api.iam.gserviceaccount.com
    sources:
    - accessLevel: '*'
  ingressTo:
    operations:
    - serviceName: '*'
    resources:
    - '*'

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

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

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

    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 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