תיקון שגיאות ב-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 Console כדי להטמיע יומנים של AWS CloudTrail. מגדירים את צמד המפתח/ערך של Ingestion label (תווית ההטמעה) לערכים CIEM ו-TRUE.

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

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

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

    כדי להגדיר פיד, אפשר לעיין במאמר Configure feed in Google Security Operations to ingest AWS logs (הגדרת פיד ב-Google Security Operations לצורך הטמעה של יומני AWS) במסמכי התיעוד של Google SecOps.

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

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

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

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 ו-Admission Controllers.

אישור התיקון

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

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

    כניסה לדף Kubernetes workloads

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

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

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

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

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

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

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

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

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

    1. בקטע Resources > Projects (משאבים > פרויקטים), בוחרים באפשרות All projects (כל הפרויקטים) או בוחרים את הפרויקט שצוין בתוצאת הסריקה.
    2. בקטע Operations or IAM roles (פעולות או תפקידי IAM), בוחרים באפשרות All operations (כל הפעולות) או בוחרים שירותים ספציפיים שבהם מופיעות הפרות של VPC Service Controls.
  10. לוחצים על 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