תיקון שגיאות ב-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. בקטע מסננים מהירים, בקטע המשנה השם המוצג של המקור, בוחרים באפשרות Security Command Center. תוצאות השאילתה של הממצאים מתעדכנות כך שיוצגו רק הממצאים מהמקור הזה.
  4. כדי לראות את הפרטים של ממצא ספציפי, לוחצים על שם הממצא בעמודה Category (קטגוריה). חלונית הפרטים של הממצא נפתחת ומוצגת בה הכרטיסייה סיכום.
  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 Console כדי להטמיע יומנים של 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. אם בקר בקרת הכניסה פועל, אבל הוא דוחה את הפריסה של אובייקט DaemonSet של זיהוי איומים בקונטיינר, צריך להגדיר את בקר בקרת הכניסה כך שיאפשר לסוכן השירות של זיהוי איומים בקונטיינר לנהל אובייקטים במרחב השמות kube-system.

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

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

אישור התיקון

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

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

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

  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