תיקון ממצאים של Security Health Analytics

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

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

תיקון בעיות ב-Security Health Analytics

בקטע הזה מפורטות הוראות לתיקון כל הממצאים של Security Health Analytics.

כדי למצוא סוגים שממופים לאמות המידה של CIS, ההנחיות לתיקון מגיעות מ-Center for Internet Security ‏ (CIS), אלא אם צוין אחרת. מידע נוסף זמין במאמר גלאים ותאימות.

השבתה אוטומטית של ממצאים

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

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

אל תשתמשו בהשתקה כדי להסתיר ממצאים שתוקנו במשאבים קיימים. אם הבעיה חוזרת ו-Security Health Analytics משחזר את מצב הממצא, יכול להיות שלא תראו את הממצא שהופעל מחדש, כי ממצאים שהושתקו לא נכללים בשאילתות ממצאים שמציינות NOT mute="MUTED", כמו שאילתת הממצאים שמוגדרת כברירת מחדל.ACTIVE

מידע על מרווחי הסריקה זמין במאמר בנושא סוגי סריקות ב-Security Health Analytics.

Access Transparency disabled

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

יומני Access Transparency מתעדים מקרים שבהם Google Cloud עובדים ניגשים לפרויקטים בארגון כדי לספק תמיכה. הפעלת Access Transparency כדי לתעד מי ניגש למידע שלכם, מתי ולמה. Google Cloud מידע נוסף זמין במאמר בנושא שקיפות גישה.

כדי להפעיל את Access Transparency בפרויקט, הפרויקט צריך להיות משויך לחשבון לחיוב.

התפקידים הנדרשים

כדי לקבל את ההרשאות שדרושות לביצוע המשימה הזו, צריך לבקש מהאדמין להקצות לכם את תפקיד ה-IAM אדמין של Access Transparency (roles/axt.admin) ברמת הארגון. מידע נוסף על הקצאת תפקידים מופיע במאמר ניהול הגישה.

התפקיד המוגדר מראש הזה כולל את ההרשאות axt.labels.get ו-axt.labels.set, שנדרשות לביצוע המשימה הזו. יכול להיות שתוכלו לקבל את ההרשאות האלה גם באמצעות תפקיד בהתאמה אישית או תפקידים מוגדרים מראש אחרים.

שלבים לפתרון

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

1. בדיקת ההרשאות ברמת הארגון:

   1. נכנסים לדף Identity and Access Management במסוףGoogle Cloud .

      כניסה לדף 'ניהול הזהויות והרשאות הגישה'

   2. אם מוצגת בקשה לעשות זאת, בוחרים את הארגון בתפריט הבחירה Google Cloud .

2. בוחרים פרויקט כלשהו בארגון באמצעות התפריט. Google Cloud

   התכונה Access Transparency מוגדרת בדף Google Cloud הפרויקט, אבל היא מופעלת לכל הארגון.

3. עוברים לדף IAM & Admin > Settings.

4. לוחצים על הפעלת Access Transparency.

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

AlloyDB auto backup disabled

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

באשכול AlloyDB ל-PostgreSQL לא מופעלים גיבויים אוטומטיים.

כדי למנוע אובדן נתונים, מומלץ להפעיל גיבויים אוטומטיים לאשכול. מידע נוסף זמין במאמר בנושא הגדרה של גיבויים אוטומטיים נוספים.

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

1. עוברים לדף האשכולות של AlloyDB ל-PostgreSQL במסוףGoogle Cloud .

   מעבר לאשכולות של AlloyDB ל-PostgreSQL

2. לוחצים על אשכול בעמודה שם המשאב.

3. לוחצים על הגנה על נתונים.

4. בקטע Automated backup policy (מדיניות גיבוי אוטומטי), לוחצים על Edit (עריכה) בשורה Automated backups (גיבויים אוטומטיים).

5. מסמנים את התיבה גיבוי אוטומטי.

6. לוחצים על עדכון.

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

AlloyDB backups disabled

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

באשכול AlloyDB ל-PostgreSQL לא מופעלים גיבויים אוטומטיים או רציפים.

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

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

1. עוברים לדף האשכולות של AlloyDB ל-PostgreSQL במסוףGoogle Cloud .

   מעבר לאשכולות של AlloyDB ל-PostgreSQL

2. בעמודה Resource Name (שם המשאב), לוחצים על שם האשכול שזוהה בממצא.

3. לוחצים על הגנה על נתונים.

4. מגדירים מדיניות גיבוי.

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

AlloyDB CMEK disabled

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

ב-AlloyDB cluster לא נעשה שימוש במפתחות הצפנה בניהול הלקוח (CMEK).

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

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

1. עוברים לדף האשכולות של AlloyDB ל-PostgreSQL במסוףGoogle Cloud .

   מעבר לאשכולות של AlloyDB ל-PostgreSQL

2. בעמודה Resource Name (שם המשאב), לוחצים על שם האשכול שזוהה בממצא.

3. לוחצים על יצירת גיבוי. מגדירים מזהה לגיבוי.

4. לוחצים על יצירה.

5. בקטע גיבוי/שחזור, לוחצים על שחזור לצד הערך של מזהה הגיבוי שבחרתם.

6. מגדירים מזהה אשכול ורשת חדשים.

7. לוחצים על אפשרויות מתקדמות להצפנה. בוחרים את ה-CMEK שרוצים להצפין איתו את האשכול החדש.

8. לוחצים על שחזור.

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

AlloyDB log min error statement severity

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

במכונת AlloyDB ל-PostgreSQL לא מוגדרת האפשרות log_min_error_statementdatabase flag עם הערך error או ערך מומלץ אחר.

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

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

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

1. עוברים לדף האשכולות של AlloyDB ל-PostgreSQL במסוףGoogle Cloud .

   מעבר לאשכולות של AlloyDB ל-PostgreSQL

2. לוחצים על האשכול בעמודה שם המשאב.

3. בקטע Instances in your cluster (מופעים באשכול), לוחצים על Edit (עריכה) ליד המופע.

4. לוחצים על אפשרויות הגדרה מתקדמות.

5. בקטע Flags, מגדירים את דגל מסד הנתונים log_min_error_statement עם אחד מהערכים המומלצים הבאים, בהתאם למדיניות הרישום ביומן של הארגון.

   • debug5
   • debug4
   • debug3
   • debug2
   • debug1
   • info
   • notice
   • warning
   • error

6. לוחצים על עדכון המופע.

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

AlloyDB log min messages

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

במכונת AlloyDB ל-PostgreSQL לא מוגדרת לפחות warning האפשרות log_min_messagesdatabase.

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

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

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

1. עוברים לדף האשכולות של AlloyDB ל-PostgreSQL במסוףGoogle Cloud .

   מעבר לאשכולות של AlloyDB ל-PostgreSQL

2. לוחצים על האשכול בעמודה שם המשאב.

3. בקטע Instances in your cluster (מופעים באשכול), לוחצים על Edit (עריכה) ליד המופע.

4. לוחצים על אפשרויות הגדרה מתקדמות.

5. בקטע Flags, מגדירים את דגל מסד הנתונים log_min_messages עם אחד מהערכים המומלצים הבאים, בהתאם למדיניות הרישום ביומן של הארגון.

   • debug5
   • debug4
   • debug3
   • debug2
   • debug1
   • info
   • notice
   • warning

6. לוחצים על עדכון המופע.

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

AlloyDB log error verbosity

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

במכונת AlloyDB ל-PostgreSQL, האפשרות log_error_verbosity database לא מוגדרת לערך default או לערך אחר פחות מגביל.

הדגל log_error_verbosity קובע את רמת הפירוט בהודעות שנרשמות ביומן. ככל שהפירוט גבוה יותר, כך יותר פרטים נרשמים בהודעות. מומלץ להגדיר את הדגל הזה לערך default או לערך אחר פחות מגביל.

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

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

1. עוברים לדף האשכולות של AlloyDB ל-PostgreSQL במסוףGoogle Cloud .

   מעבר לאשכולות של AlloyDB ל-PostgreSQL

2. לוחצים על האשכול בעמודה שם המשאב.

3. בקטע Instances in your cluster (מופעים באשכול), לוחצים על Edit (עריכה) ליד המופע.

4. לוחצים על אפשרויות הגדרה מתקדמות.

5. בקטע Flags, מגדירים את דגל מסד הנתונים log_error_verbosity עם אחד מהערכים המומלצים הבאים, בהתאם למדיניות הרישום ביומן של הארגון.

   • default
   • verbose

6. לוחצים על עדכון המופע.

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

AlloyDB Public IP

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

למכונת מסד נתונים של AlloyDB ל-PostgreSQL יש כתובת IP ציבורית.

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

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

1. עוברים לדף האשכולות של AlloyDB ל-PostgreSQL במסוףGoogle Cloud .

   מעבר לאשכולות של AlloyDB ל-PostgreSQL

2. בעמודה Resource Name (שם המשאב), לוחצים על שם האשכול שזוהה בממצא.

3. בקטע Instances in your cluster (מופעים באשכול), לוחצים על Edit (עריכה) ליד המופע.

4. בקטע קישוריות, מבטלים את הסימון בתיבה הפעלת IP ציבורי.

5. לוחצים על עדכון המופע.

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

AlloyDB SSL not enforced

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

במכונת מסד נתונים של AlloyDB ל-PostgreSQL לא נדרש שכל החיבורים הנכנסים ישתמשו ב-SSL.

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

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

1. עוברים לדף האשכולות של AlloyDB ל-PostgreSQL במסוףGoogle Cloud .

   מעבר לאשכולות של AlloyDB ל-PostgreSQL

2. בעמודה Resource Name (שם המשאב), לוחצים על שם האשכול שזוהה בממצא.

3. בקטע Instances in your cluster (מופעים באשכול), לוחצים על Edit (עריכה) ליד המופע.

4. בקטע Network Security (אבטחת רשת), לוחצים על התיבה Require SSL Encryption (דרישה להצפנת SSL).

5. לוחצים על עדכון המופע.

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

Admin service account

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

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

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

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

   כניסה למדיניות IAM

2. לכל חשבון משתמש שזוהה בממצא:

   1. לצד חשבון המשתמש לוחצים על edit Edit principal.
   2. כדי להסיר הרשאות, לוחצים על delete מחיקת התפקיד לצד התפקיד.
   3. לוחצים על Save.

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

Alpha cluster enabled

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

תכונות של אשכול אלפא מופעלות באשכול Google Kubernetes Engine ‏ (GKE).

אשכולות אלפא מאפשרים למשתמשים מוקדמים להתנסות בעומסי עבודה שמשתמשים בתכונות חדשות לפני שהן מושקות לקהל הרחב. באשכולות אלפא כל התכונות של GKE API מופעלות, אבל הם לא מכוסים על ידי הסכם רמת השירות (SLA) של GKE, הם לא מקבלים עדכוני אבטחה, השדרוג האוטומטי של הצמתים והתיקון האוטומטי של הצמתים מושבתים בהם, ואי אפשר לשדרג אותם. בכל מקרה הם יימחקו באופן אוטומטי לאחר 30 ימים.

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

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

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

   מעבר אל Kubernetes clusters

2. לוחצים על יצירה.

3. לצד סוג האשכול שרוצים ליצור, לוחצים על הגדרה.

4. בכרטיסייה Features (תכונות), מוודאים שהאפשרות Enable Kubernetes alpha features in this cluster (הפעלת תכונות אלפא של Kubernetes באשכול הזה) מושבתת.

5. לוחצים על יצירה.

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

7. כדי למחוק את האשכול המקורי, אפשר לעיין במאמר בנושא מחיקת אשכול.

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

API key APIs unrestricted

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

יש מפתחות API שנעשה בהם שימוש רחב מדי.

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

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

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

   מעבר אל מפתחות API

2. לכל מפתח API:

   1. בקטע API keys, בשורה של כל מפתח API שרוצים להגביל את השימוש בו, לוחצים על more_vert Actions.
   2. בתפריט פעולות, לוחצים על עריכת מפתח API. ייפתח הדף עריכת מפתח API.
   3. בקטע API restrictions, בוחרים באפשרות Restrict APIs. מופיע התפריט הנפתח בחירת ממשקי API.
   4. ברשימה הנפתחת Select APIs (בחירת ממשקי API), בוחרים את ממשקי ה-API שרוצים לאפשר.
   5. לוחצים על Save. יכול להיות שיחלפו עד 5 דקות עד שההגדרות ייכנסו לתוקף.

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

API key apps unrestricted

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

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

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

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

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

   מעבר אל מפתחות API

2. לכל מפתח API:

   1. בקטע API keys, בשורה של כל מפתח API שרוצים להגביל את האפליקציות שמשתמשות בו, לוחצים על more_vert Actions.
   2. בתפריט פעולות, לוחצים על עריכת מפתח API. ייפתח הדף עריכת מפתח API.
   3. בדף Edit API key, בקטע Application restrictions, בוחרים קטגוריית הגבלה. אפשר להגדיר הגבלה אחת על אפליקציה לכל מפתח.
   4. בשדה Add an item שמופיע כשבוחרים הגבלה, לוחצים על Add an item כדי להוסיף הגבלות בהתאם לצרכים של האפליקציה.
   5. כשמסיימים להוסיף פריטים, לוחצים על סיום.
   6. לוחצים על Save.

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

API key exists

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

בפרויקט נעשה שימוש במפתחות API במקום באימות רגיל.

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

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

1. מוודאים שהאפליקציות מוגדרות עם שיטת אימות חלופית.

2. נכנסים לדף API credentials במסוף Google Cloud .

   לדף API credentials

3. בקטע API keys, בשורה של כל מפתח API שרוצים למחוק, לוחצים על more_vert Actions.

4. בתפריט Actions (פעולות), לוחצים על Delete API key (מחיקת מפתח API).

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

API key not rotated

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

לא בוצע סבב מפתחות של מפתח API במשך יותר מ-90 יום.

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

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

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

   מעבר אל מפתחות API

2. לכל מפתח API:

   1. בקטע API keys, בשורה של כל מפתח API שרוצים לסובב, לוחצים על more_vert Actions.
   2. בתפריט פעולות, לוחצים על עריכת מפתח API. ייפתח הדף עריכת מפתח API.
   3. בדף Edit API key, אם התאריך בשדה Creation date הוא מלפני יותר מ-90 יום, לוחצים על refresh Rotate key. המערכת יוצרת מפתח חדש.
   4. אפשר לשנות את השם של מפתח ה-API.
   5. לוחצים על יצירה.
   6. מעדכנים את האפליקציות כדי שישתמשו במפתח החדש.
   7. אחרי שמעדכנים את האפליקציות, חוזרים לדף עריכת מפתח API ולוחצים על מחיקת המפתח הקודם כדי למחוק את המפתח הישן. המפתח הישן לא יימחק באופן אוטומטי.

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

Audit config not monitored

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

המדדים וההתראות ביומן לא מוגדרים למעקב אחרי שינויים בהגדרות הביקורת.

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

העלויות של Cloud Monitoring יכולות להיות משמעותיות, בהתאם לכמות המידע. כדי להבין את השימוש בשירות ואת העלויות שלו, אפשר לעיין במחירון של Google Cloud Observability.

אם הפעלתם את Security Command Center Premium ברמת הפרויקט, הממצא הזה זמין רק אם מסלול Standard-legacy מופעל בארגון האב.

כדי לתקן שגיאות בממצא הזה, צריך ליצור מדדים, אם יש צורך, ומדיניות התראות:

יצירת מדד

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

   מעבר אל 'מדדים מבוססי-יומנים'

2. לוחצים על יצירת מדד.

3. בקטע סוג המדד, בוחרים באפשרות מונה.

4. בקטע פרטים:

   1. מגדירים שם של מדד יומן.
   2. מוסיפים תיאור.
   3. מגדירים את Units (יחידות) לערך 1.

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

     protoPayload.methodName="SetIamPolicy"
     AND protoPayload.serviceData.policyDelta.auditConfigDeltas:*

6. לוחצים על יצירת מדד. יוצג אישור.

יצירת מדיניות התראות

1. נכנסים לדף Log-based Metrics במסוף Google Cloud :

   כניסה אל מדדים מבוססי-יומנים

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

2. בקטע מדדים שהוגדרו על ידי המשתמש, בוחרים את המדד שיצרתם בקטע הקודם.

3. לוחצים על סמל האפשרויות הנוספות more_vert ואז על יצירת התראה ממדד.

   תיבת הדו-שיח תנאי חדש תיפתח עם אפשרויות המדד והמרת הנתונים שאוכלסו מראש.

4. לוחצים על הבא.
   1. בודקים את ההגדרות שמולאו מראש. אולי תרצו לשנות את ערך הסף.
   2. לוחצים על שם התנאי ומזינים שם לתנאי.
5. לוחצים על הבא.

6. כדי להוסיף התראות למדיניות ההתראות, לוחצים על ערוצי התראות. בתיבת הדו-שיח, בוחרים ערוץ התראות אחד או יותר מהתפריט ולוחצים על אישור.

   כדי לקבל התראה כשאירועים נפתחים ונסגרים, מסמנים את התיבה Notify on incident closure. כברירת מחדל, ההתראות נשלחות רק כשנפתחים אירועים.

7. אופציונלי: מעדכנים את משך הזמן עד לסגירה אוטומטית של אירוע. השדה הזה קובע מתי מערכת Monitoring סוגרת אירועים בהיעדר נתונים של מדדים.
8. אופציונלי: לוחצים על תיעוד, ואז מוסיפים את המידע שרוצים לכלול בהודעת ההתראה.
9. לוחצים על שם ההתראה ומזינים שם למדיניות ההתראה.
10. לוחצים על יצירת מדיניות.

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

Audit logging disabled

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

הממצא הזה לא זמין להפעלות ברמת הפרויקט.

יומן הביקורת מושבת עבור שירות אחד או יותר Google Cloud , או שחשבון משתמש אחד או יותר פטורים מרישום ביומן הביקורת של הגישה לנתונים.

כדאי להפעיל את Cloud Logging לכל השירותים כדי לעקוב אחרי כל פעילות האדמין, גישת קריאה וגישת כתיבה לנתוני המשתמשים. בהתאם לכמות המידע, העלויות של Cloud Logging יכולות להיות משמעותיות. כדי להבין את השימוש שלכם בשירות ואת העלות שלו, אפשר לעיין במחירון של Google Cloud Observability.

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

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

1. נכנסים לדף Data Access audit logs default configuration במסוףGoogle Cloud .

   מעבר להגדרת ברירת המחדל

2. בכרטיסייה Log types (סוגי יומנים), מפעילים את רישום יומני הביקורת של גישה לנתונים בהגדרת ברירת המחדל:

   1. בוחרים באפשרויות קריאת נתוני אדמין, קריאת נתונים וכתיבת נתונים.
   2. לוחצים על Save.

3. בכרטיסייה Exempted principals (גורמים מוחרגים), מסירים את כל המשתמשים המוחרגים מהגדרת ברירת המחדל:

   1. כדי להסיר כל אחד מהגורמים ברשימה, לוחצים על delete מחיקה לצד כל שם.
   2. לוחצים על Save.

4. עוברים לדף יומני ביקורת.

   כניסה ליומני ביקורת

5. מסירים את כל הגורמים המורשים שפטורים מביקורת מההגדרות של יומן הביקורת של גישה לנתונים בשירותים השונים.

   1. בקטע Data access audit logs configuration (הגדרת יומני ביקורת לגבי גישה לנתונים), לוחצים על כל שירות שמוצג בו חשבון משתמש שמוחרג. נפתחת חלונית הגדרות של יומן הביקורת של השירות.
   2. בכרטיסייה Exempted principals (חשבונות ראשיים שמוחרגים), מסירים את כל החשבונות הראשיים שמוחרגים על ידי לחיצה על delete Delete (מחיקה) לצד כל שם.
   3. לוחצים על Save.

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

Auto backup disabled

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

גיבויים אוטומטיים לא מופעלים במסד נתונים של Cloud SQL.

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

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

1. נכנסים לדף Instances של Cloud SQL במסוף Google Cloud .

   כניסה לדף Instances

2. לוחצים על שם המכונה.

3. לוחצים על גיבויים.

4. לצד הגדרות, לוחצים על edit עריכה.

5. מסמנים את התיבה גיבויים אוטומטיים יומיים.

6. אופציונלי: בתיבה מספר הימים מזינים את מספר הימים שבהם רוצים לשמור את הגיבויים.

7. אופציונלי: ברשימה חלון גיבוי, בוחרים את חלון הזמן שבו יתבצעו הגיבויים.

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

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

Auto repair disabled

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

התכונה לתיקון אוטומטי של אשכולות Google Kubernetes Engine ‏ (GKE), ששומרת על מצב תקין של הצמתים, מושבתת.

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

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

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

   מעבר אל Kubernetes clusters

2. לוחצים על הכרטיסייה Nodes.

3. לכל מאגר צמתים:

   1. לוחצים על שם מאגר הצמתים כדי לעבור לדף הפרטים שלו.
   2. לוחצים על edit עריכה.
   3. בקטע ניהול, בוחרים באפשרות הפעלת תיקון אוטומטי.
   4. לוחצים על Save.

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

Auto upgrade disabled

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

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

מידע נוסף זמין במאמר בנושא שדרוג אוטומטי של צמתים.

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

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

   מעבר אל Kubernetes clusters

2. ברשימת האשכולות, לוחצים על שם האשכול.

3. לוחצים על הכרטיסייה Nodes.

4. לכל מאגר צמתים:

   1. לוחצים על שם מאגר הצמתים כדי לעבור לדף הפרטים שלו.
   2. לוחצים על edit עריכה.
   3. בקטע ניהול, בוחרים באפשרות הפעלת שדרוג אוטומטי.
   4. לוחצים על Save.

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

BigQuery table CMEK disabled

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

טבלה ב-BigQuery לא מוגדרת לשימוש במפתח הצפנה בניהול הלקוח (CMEK).

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

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

1. יצירת טבלה שמוגנת על ידי Cloud Key Management Service
2. מעתיקים את הטבלה לטבלה החדשה עם ההצפנה באמצעות מפתח משל לקוח.
3. מוחקים את הטבלה המקורית.

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

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

Binary authorization disabled

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

‫Binary Authorization מושבת באשכול GKE.

‫Binary Authorization כולל תכונה אופציונלית שמגנה על אבטחת שרשרת האספקה בכך שהיא מאפשרת פריסה באשכול רק של תמונות קונטיינר שנחתמו על ידי רשויות מהימנות במהלך תהליך הפיתוח. אכיפה של פריסה מבוססת-חתימה מאפשרת לכם לשלוט יותר בסביבת הקונטיינרים, ולוודא שרק תמונות מאומתות יכולות להיפרס.

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

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

   מעבר אל Kubernetes clusters

2. בקטע Security, לוחצים על edit Edit בשורה Binary Authorization.

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

3. בתיבת הדו-שיח, בוחרים באפשרות Binary Authorization.

4. לוחצים על שמירת השינויים.

5. עוברים לדף ההגדרה של Binary Authorization.

   מעבר אל Binary Authorization

6. מוודאים שהוגדרה מדיניות שמחייבת שימוש בבודקים, ושהכלל שמוגדר כברירת מחדל בפרויקט לא מוגדר להתרת כל התמונות. מידע נוסף מופיע במאמר בנושא הגדרה ל-GKE.

   כדי לוודא שתמונות שמפירות את המדיניות יוכלו להיפרס וההפרות יתועדו ביומני הביקורת של Cloud, אפשר להפעיל את מצב הרצה יבשה.

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

Bucket CMEK disabled

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

קטגוריה לא מוצפנת באמצעות מפתחות הצפנה בניהול הלקוח (CMEK).

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

כדי לפתור את הבעיה הזו, צריך להשתמש ב-CMEK עם bucket. אפשר לעשות את זה לפי ההוראות במאמר שימוש במפתחות הצפנה בניהול הלקוח. שימוש ב-CMEK כרוך בעלויות נוספות שקשורות ל-Cloud KMS.

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

Bucket IAM not monitored

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

מדדי היומנים וההתראות לא מוגדרים למעקב אחרי שינויים בהרשאות IAM ב-Cloud Storage.

מעקב אחרי שינויים בהרשאות של קטגוריות ב-Cloud Storage עוזר לזהות משתמשים עם הרשאות מוגזמות או פעילות חשודה. מידע נוסף מופיע במאמר סקירה כללית של מדדים שמבוססים על יומנים.

העלויות של Cloud Monitoring יכולות להיות משמעותיות, בהתאם לכמות המידע. כדי להבין את השימוש בשירות ואת העלויות שלו, אפשר לעיין במחירון של Google Cloud Observability.

אם הפעלתם את Security Command Center Premium ברמת הפרויקט, הממצא הזה זמין רק אם מסלול Standard-legacy מופעל בארגון האב.

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

יצירת מדד

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

   מעבר אל 'מדדים מבוססי-יומנים'

2. לוחצים על יצירת מדד.

3. בקטע סוג המדד, בוחרים באפשרות מונה.

4. בקטע פרטים:

   1. מגדירים שם של מדד יומן.
   2. מוסיפים תיאור.
   3. מגדירים את Units (יחידות) לערך 1.

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

     resource.type=gcs_bucket
     AND protoPayload.methodName="storage.setIamPermissions"

6. לוחצים על יצירת מדד. יוצג אישור.

יצירת מדיניות התראות

1. נכנסים לדף Log-based Metrics במסוף Google Cloud :

   כניסה אל מדדים מבוססי-יומנים

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

2. בקטע מדדים שהוגדרו על ידי המשתמש, בוחרים את המדד שיצרתם בקטע הקודם.

3. לוחצים על סמל האפשרויות הנוספות more_vert ואז על יצירת התראה ממדד.

   תיבת הדו-שיח תנאי חדש תיפתח עם אפשרויות המדד והמרת הנתונים שאוכלסו מראש.

4. לוחצים על הבא.
   1. בודקים את ההגדרות שמולאו מראש. אולי תרצו לשנות את ערך הסף.
   2. לוחצים על שם התנאי ומזינים שם לתנאי.
5. לוחצים על הבא.

6. כדי להוסיף התראות למדיניות ההתראות, לוחצים על ערוצי התראות. בתיבת הדו-שיח, בוחרים ערוץ התראות אחד או יותר מהתפריט ולוחצים על אישור.

   כדי לקבל התראה כשאירועים נפתחים ונסגרים, מסמנים את התיבה Notify on incident closure. כברירת מחדל, ההתראות נשלחות רק כשנפתחים אירועים.

7. אופציונלי: מעדכנים את משך הזמן עד לסגירה אוטומטית של אירוע. השדה הזה קובע מתי מערכת Monitoring סוגרת אירועים בהיעדר נתונים של מדדים.
8. אופציונלי: לוחצים על תיעוד, ואז מוסיפים את המידע שרוצים לכלול בהודעת ההתראה.
9. לוחצים על שם ההתראה ומזינים שם למדיניות ההתראה.
10. לוחצים על יצירת מדיניות.

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

Bucket logging disabled

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

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

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

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

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

Bucket policy only disabled

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

הגישה האחידה ברמת הקטגוריה, שנקראה בעבר 'מדיניות הקטגוריה בלבד', לא מוגדרת.

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

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

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

   כניסה אל Cloud Storage browser

2. ברשימת הקטגוריות, לוחצים על השם של הקטגוריה הרצויה.

3. לוחצים על הכרטיסייה Configuration.

4. בקטע Permissions, בשורה של בקרת גישה, לוחצים על edit Edit access control model.

5. בתיבת הדו-שיח, בוחרים באפשרות Uniform.

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

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

Cloud Asset API disabled

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

שירות מאגר משאבי ענן לא מופעל בפרויקט.

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

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

   לדף API Library

2. חיפוש של Cloud Asset Inventory.

3. בוחרים את התוצאה של שירות Cloud Asset API.

4. מוודאים שההגדרה API Enabled מוצגת.

Cluster logging disabled

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

הרישום ביומן לא מופעל באשכול GKE.

כדי לחקור בעיות אבטחה ולעקוב אחרי השימוש, צריך להפעיל את Cloud Logging באשכולות.

בהתאם לכמות המידע, העלויות של Cloud Logging יכולות להיות משמעותיות. כדי להבין את השימוש שלכם בשירות ואת העלות שלו, אפשר לעיין במחירון של Google Cloud Observability.

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

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

   מעבר אל Kubernetes clusters

2. בוחרים את האשכול שמופיע בתוצאת החיפוש של Security Health Analytics.

3. לוחצים על edit עריכה.

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

4. ברשימה הנפתחת Legacy Stackdriver Logging (רישום ביומן בגרסה הקודמת של Stackdriver) או Stackdriver Kubernetes Engine Monitoring (מעקב ב-Stackdriver אחרי Kubernetes Engine), בוחרים באפשרות Enabled (מופעל).

   האפשרויות האלה לא תואמות. חשוב להשתמש רק ב-Stackdriver Kubernetes Engine Monitoring, או ב-Legacy Stackdriver Logging עם Legacy Stackdriver Monitoring.

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

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

Cluster monitoring disabled

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

המעקב מושבת באשכולות GKE.

כדי לחקור בעיות אבטחה ולעקוב אחרי השימוש, מומלץ להפעיל את Cloud Monitoring באשכולות.

העלויות של Cloud Monitoring יכולות להיות משמעותיות, בהתאם לכמות המידע. כדי להבין את השימוש בשירות ואת העלויות שלו, אפשר לעיין במחירון של Google Cloud Observability.

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

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

   מעבר אל Kubernetes clusters

2. בוחרים את האשכול שמופיע בתוצאת החיפוש של Security Health Analytics.

3. לוחצים על edit עריכה.

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

4. ברשימה הנפתחת Legacy Stackdriver Monitoring או Stackdriver Kubernetes Engine Monitoring, בוחרים באפשרות Enabled.

   האפשרויות האלה לא תואמות. חשוב לוודא שאתם משתמשים רק ב-Stackdriver Kubernetes Engine Monitoring, או ב-Legacy Stackdriver Monitoring עם Legacy Stackdriver Logging.

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

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

Cluster private Google access disabled

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

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

הגישה הפרטית ל-Google מאפשרת למכונות וירטואליות (VM) עם כתובות IP פנימיות פרטיות בלבד להגיע לכתובות ה-IP הציבוריות של שירותים וממשקי API של Google. מידע נוסף זמין במאמר בנושא הגדרת גישה פרטית של Google.

אם הפעלתם את Security Command Center Premium ברמת הפרויקט, הממצא הזה זמין רק אם מסלול Standard-legacy מופעל בארגון האב.

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

1. נכנסים לדף Virtual Private Cloud networks במסוף Google Cloud .

   עוברים אל רשתות VPC

2. ברשימת הרשתות, לוחצים על שם הרשת הרצויה.

3. בדף פרטי רשת VPC, לוחצים על הכרטיסייה Subnets.

4. ברשימת רשתות המשנה, לוחצים על שם רשת המשנה שמשויכת לאשכול Kubernetes בממצא.

5. בדף פרטי רשת המשנה, לוחצים על edit עריכה.

6. בקטע גישה פרטית ל-Google, בוחרים באפשרות מופעל.

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

8. כדי להסיר כתובות IP ציבוריות (חיצוניות) ממכונות וירטואליות שתעבורת הנתונים החיצונית היחידה שלהן היא ל-Google APIs, אפשר לעיין במאמר בנושא ביטול ההקצאה של כתובת IP חיצונית סטטית.

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

Cluster secrets encryption disabled

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

ההצפנה של סודות בשכבת האפליקציה מושבתת באשכול GKE.

הצפנת סודות בשכבת האפליקציה מבטיחה שהסודות של GKE יוצפנו באמצעות מפתחות Cloud KMS. התכונה מספקת שכבת אבטחה נוספת לנתונים רגישים, כמו סודות שהוגדרו על ידי המשתמש וסודות שנדרשים להפעלת האשכול, כמו מפתחות של חשבונות שירות, שכולם מאוחסנים ב-etcd.

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

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

   מעבר למפתחות Cloud KMS

2. בודקים את מפתחות האפליקציה או יוצרים מפתח להצפנת מסד נתונים (DEK). מידע נוסף זמין במאמר יצירת מפתח Cloud KMS.

3. עוברים לדף Kubernetes clusters.

   מעבר אל Kubernetes clusters

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

5. בקטע אבטחה, בשדה הצפנת סודות בשכבת האפליקציה, לוחצים על edit עריכת הצפנת סודות בשכבת האפליקציה.

6. מסמנים את תיבת הסימון הפעלת הצפנה של סודות בשכבת האפליקציה ואז בוחרים את מפתח ה-DEK שיצרתם.

7. לוחצים על שמירת השינויים.

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

Cluster shielded nodes disabled

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

לא מופעלים צמתים מוגנים של GKE באשכול.

בלי צמתים מוגנים של GKE, תוקפים יכולים לנצל נקודת חולשה ב-Pod כדי להשיג פרטי כניסה של bootstrap ולהתחזות לצמתים באשכול. נקודת החולשה הזו יכולה לאפשר לתוקפים לגשת לסודות של האשכול.

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

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

   מעבר אל Kubernetes clusters

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

3. בקטע Security, בשדה Shielded GKE nodes, לוחצים על edit Edit Shielded GKE nodes.

4. מסמנים את תיבת הסימון הפעלת צומתי GKE מוגנים.

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

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

Compute project wide SSH keys allowed

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

נעשה שימוש במפתחות SSH ברמת הפרויקט, שמאפשרים כניסה לכל המופעים בפרויקט.

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

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

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

   כניסה לדף VM instances

2. ברשימת המקרים, לוחצים על שם המקרה בתוצאת החיפוש.

3. בדף פרטי מופע ה-VM, לוחצים על edit עריכה.

4. בקטע SSH Keys (מפתחות SSH), בוחרים באפשרות Block project-wide SSH keys (חסימת מפתחות SSH ברמת הפרויקט).

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

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

Compute Secure Boot disabled

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

במכונה וירטואלית מוגנת לא מופעל אתחול מאובטח.

שימוש באתחול מאובטח עוזר להגן על המכונות הווירטואליות מפני ערכות כלים לגישה לרמת הבסיס (rootkit) ומפני ערכות כלים לאתחול (bootkit). ב-Compute Engine, האפשרות Secure Boot לא מופעלת כברירת מחדל כי יש מנהלי התקנים לא חתומים ותוכנות ברמה נמוכה שלא תואמים לה. אם המכונה הווירטואלית לא משתמשת בתוכנה לא תואמת והיא מופעלת עם הפעלה מאובטחת, Google ממליצה להשתמש בהפעלה מאובטחת. אם אתם משתמשים במודולים של צד שלישי עם מנהלי התקנים של Nvidia, ודאו שהם תואמים לאתחול מאובטח לפני שתפעילו אותו.

מידע נוסף זמין במאמר בנושא אתחול מאובטח.

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

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

   כניסה לדף VM instances

2. ברשימת המקרים, לוחצים על שם המקרה בתוצאת החיפוש.

3. בדף פרטי המכונה הווירטואלית, לוחצים על stop הפסקה.

4. אחרי שהמופע מפסיק, לוחצים על edit עריכה.

5. בקטע מכונה וירטואלית מוגנת, בוחרים באפשרות Turn on Secure Boot (הפעלה מאובטחת).

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

7. לוחצים על play_arrow התחלה כדי להפעיל את המופע.

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

Compute serial ports enabled

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

היציאות הטוריות מופעלות עבור מופע, ומאפשרות חיבורים למסוף הטורי של המופע.

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

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

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

   כניסה לדף VM instances

2. ברשימת המקרים, לוחצים על שם המקרה בתוצאת החיפוש.

3. בדף פרטי מופע ה-VM, לוחצים על edit עריכה.

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

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

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

Confidential Computing disabled

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

לא מופעלת במכונה של Compute Engine טכנולוגיית Confidential Computing.

‫Confidential Computing מוסיף עמוד תווך שלישי לסיפור ההצפנה מקצה לקצה, על ידי הצפנת הנתונים בזמן השימוש. עם סביבות הביצוע החסויות שמוצעות על ידי Confidential Computing ו-AMD Secure Encrypted Virtualization ‏(SEV),‏ Google Cloud שומר על קוד רגיש ונתונים אחרים מוצפנים בזיכרון במהלך העיבוד.

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

מידע נוסף זמין במאמר מכונות וירטואליות ו-Compute Engine חסויים.

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

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

   כניסה לדף VM instances

2. ברשימת המקרים, לוחצים על שם המקרה בתוצאת החיפוש.

3. בדף פרטי מכונה וירטואלית, לוחצים על delete מחיקה.

4. יצירת מכונה וירטואלית חסויה באמצעות מסוף Google Cloud

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

COS not used

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

המכונות הווירטואליות ב-Compute Engine לא משתמשות ב-Container-Optimized OS, שנועדה להריץ קונטיינרים ב-Docker באופן מאובטח. Google Cloud

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

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

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

   מעבר אל Kubernetes clusters

2. ברשימת האשכולות, לוחצים על שם האשכול בממצא.

3. לוחצים על הכרטיסייה Nodes.

4. לכל מאגר צמתים:

   1. לוחצים על שם מאגר הצמתים כדי לעבור לדף הפרטים שלו.
   2. לוחצים על edit עריכה .
   3. בקטע Nodes -> Image type (צמתים -> סוג תמונה), לוחצים על Change (שינוי).
   4. בוחרים באפשרות מערכת הפעלה שמותאמת לקונטיינרים ולוחצים על שינוי.
   5. לוחצים על Save.

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

Custom role not monitored

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

מדדים והתראות ביומן לא מוגדרים למעקב אחרי שינויים בתפקידים בהתאמה אישית.

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

העלויות של Cloud Monitoring יכולות להיות משמעותיות, בהתאם לכמות המידע. כדי להבין את השימוש בשירות ואת העלויות שלו, אפשר לעיין במחירון של Google Cloud Observability.

אם הפעלתם את Security Command Center Premium ברמת הפרויקט, הממצא הזה זמין רק אם מסלול Standard-legacy מופעל בארגון האב.

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

יצירת מדד

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

   מעבר אל 'מדדים מבוססי-יומנים'

2. לוחצים על יצירת מדד.

3. בקטע סוג המדד, בוחרים באפשרות מונה.

4. בקטע פרטים:

   1. מגדירים שם של מדד יומן.
   2. מוסיפים תיאור.
   3. מגדירים את Units (יחידות) לערך 1.

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

     resource.type="iam_role"
     AND (protoPayload.methodName="google.iam.admin.v1.CreateRole"
     OR protoPayload.methodName="google.iam.admin.v1.DeleteRole"
     OR protoPayload.methodName="google.iam.admin.v1.UpdateRole")

6. לוחצים על יצירת מדד. יוצג אישור.

יצירת מדיניות התראות

1. נכנסים לדף Log-based Metrics במסוף Google Cloud :

   כניסה אל מדדים מבוססי-יומנים

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

2. בקטע מדדים שהוגדרו על ידי המשתמש, בוחרים את המדד שיצרתם בקטע הקודם.

3. לוחצים על סמל האפשרויות הנוספות more_vert ואז על יצירת התראה ממדד.

   תיבת הדו-שיח תנאי חדש תיפתח עם אפשרויות המדד והמרת הנתונים שאוכלסו מראש.

4. לוחצים על הבא.
   1. בודקים את ההגדרות שמולאו מראש. אולי תרצו לשנות את ערך הסף.
   2. לוחצים על שם התנאי ומזינים שם לתנאי.
5. לוחצים על הבא.

6. כדי להוסיף התראות למדיניות ההתראות, לוחצים על ערוצי התראות. בתיבת הדו-שיח, בוחרים ערוץ התראות אחד או יותר מהתפריט ולוחצים על אישור.

   כדי לקבל התראה כשאירועים נפתחים ונסגרים, מסמנים את התיבה Notify on incident closure. כברירת מחדל, ההתראות נשלחות רק כשנפתחים אירועים.

7. אופציונלי: מעדכנים את משך הזמן עד לסגירה אוטומטית של אירוע. השדה הזה קובע מתי מערכת Monitoring סוגרת אירועים בהיעדר נתונים של מדדים.
8. אופציונלי: לוחצים על תיעוד, ואז מוסיפים את המידע שרוצים לכלול בהודעת ההתראה.
9. לוחצים על שם ההתראה ומזינים שם למדיניות ההתראה.
10. לוחצים על יצירת מדיניות.

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

Dataproc CMEK disabled

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

נוצר אשכול Dataproc ללא הגדרת הצפנה של CMEK. ב-CMEK, המפתחות שאתם יוצרים ומנהלים ב-Cloud Key Management Service עוטפים את המפתחות שבהם Google Cloud משתמש כדי להצפין את הנתונים שלכם, וכך אתם מקבלים יותר שליטה על הגישה לנתונים.

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

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

   מעבר אל 'אשכולות Dataproc'

2. בוחרים את הפרויקט ולוחצים על Create Cluster (יצירת אשכול).

3. בקטע Manage security (ניהול אבטחה), לוחצים על Encryption (הצפנה) ובוחרים באפשרות Customer-managed key (מפתח בניהול הלקוח).

4. בוחרים מפתח בניהול הלקוח מהרשימה.

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

5. מוודאים שלמפתח ה-KMS שנבחר הוקצה התפקיד Cloud KMS CryptoKey Encrypter/Decrypter לחשבון השירות של אשכול Dataproc ("serviceAccount:service-project_number@compute-system.iam.gserviceaccount.com").

6. אחרי שיוצרים את האשכול, מעבירים את כל עומסי העבודה מהאשכול הישן לאשכול החדש.

7. עוברים אל Dataproc clusters ובוחרים את הפרויקט.

8. בוחרים את האשכול הישן ולוחצים על delete מחיקת האשכול.

9. חוזרים על כל השלבים שלמעלה בשביל אשכולות Dataproc אחרים שזמינים בפרויקט שנבחר.

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

Dataproc image outdated

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

נוצר אשכול Dataproc באמצעות גרסת תמונה של Dataproc שהושפעה מפרצות אבטחה בכלי Apache Log4j 2‏ (CVE-2021-44228 ו-CVE-2021-45046).

הכלי הזה לאיתור פגיעויות בודק אם השדה softwareConfig.imageVersion במאפיין config של Cluster מכיל אחת מהגרסאות המושפעות הבאות:

• גרסאות תמונה מוקדמות יותר מ-1.3.95.
• גרסאות משנה של אימג'ים שקודמות לגרסאות 1.4.77,‏ 1.5.53 ו-2.0.27.

אפשר לשנות ידנית את מספר הגרסה של תמונת Dataproc מותאמת אישית. כדאי להביא בחשבון את התרחישים הבאים:

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

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

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

Dataset CMEK disabled

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

מערך נתונים ב-BigQuery לא מוגדר לשימוש במפתח הצפנה בניהול הלקוח (CMEK) כברירת מחדל.

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

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

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

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

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

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

Default network

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

רשת ברירת המחדל קיימת בפרויקט.

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

אם הפעלתם את Security Command Center Premium ברמת הפרויקט, הממצא הזה זמין רק אם מסלול Standard-legacy מופעל בארגון האב.

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

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

   מעבר לרשתות VPC

2. ברשימת הרשתות, לוחצים על שם רשת ברירת המחדל.

3. בדף VPC network details (פרטי רשת VPC), לוחצים על delete Delete VPC Network (מחיקת רשת VPC).

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

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

Default service account used

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

מכונה של Compute Engine מוגדרת לשימוש בחשבון השירות שמוגדר כברירת מחדל.

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

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

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

   כניסה לדף VM instances

2. בוחרים את המופע שקשור לממצא של Security Health Analytics.

3. בדף Instance details שנטען, לוחצים על ‎stop Stop.

4. אחרי שהמופע מפסיק, לוחצים על edit עריכה.

5. בקטע Service Account, בוחרים חשבון שירות שאינו חשבון השירות שמוגדר כברירת מחדל ב-Compute Engine. יכול להיות שתצטרכו קודם ליצור חשבון שירות חדש. במאמר בקרת גישה מוסבר בהרחבה על תפקידים והרשאות ב-IAM.

6. לוחצים על Save. ההגדרה החדשה מופיעה בדף Instance details.

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

Disk CMEK disabled

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

הדיסקים במכונה הווירטואלית הזו לא מוצפנים באמצעות מפתחות הצפנה בניהול הלקוח (CMEK).

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

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

1. נכנסים לדף Compute Engine disks במסוףGoogle Cloud .

   לפתיחת הדף Disks ב-Compute Engine

2. ברשימת הדיסקים, לוחצים על שם הדיסק שמצוין בממצא.

3. בדף Manage disk (ניהול הדיסק), לוחצים על Delete (מחיקה) delete.

4. כדי ליצור דיסק אחסון מתמיד (persistent disk) חדש עם CMEK מופעל, אפשר לעיין במאמר בנושא הצפנה של דיסק אחסון מתמיד (persistent disk) חדש עם מפתחות משלכם. השימוש ב-CMEK כרוך בעלויות נוספות שקשורות ל-Cloud KMS.

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

Disk CSEK disabled

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

הדיסקים במכונה הווירטואלית הזו לא מוצפנים באמצעות מפתחות הצפנה באספקת הלקוח (CSEK). דיסקים של מכונות וירטואליות קריטיות צריכים להיות מוצפנים באמצעות CSEK.

אם אתם מספקים מפתחות הצפנה משלכם, Compute Engine משתמש במפתח שלכם כדי להגן על המפתחות שנוצרו על ידי Google ומשמשים להצפנה ולפענוח של הנתונים. מידע נוסף זמין במאמר בנושא מפתחות הצפנה באספקת הלקוח (CSEK). שימוש ב-CSEK כרוך בעלויות נוספות שקשורות ל-Cloud KMS.

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

מחיקה ויצירה של דיסק

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

1. נכנסים לדף Compute Engine disks במסוףGoogle Cloud .

   לפתיחת הדף Disks ב-Compute Engine

2. ברשימת הדיסקים, לוחצים על שם הדיסק שמצוין בממצא.

3. בדף Manage disk (ניהול הדיסק), לוחצים על Delete (מחיקה) delete.

4. כדי ליצור דיסק חדש עם CSEK מופעל, אפשר לעיין במאמר בנושא הצפנת דיסקים באמצעות מפתחות הצפנה באספקת הלקוח.

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

הפעלת הגלאי

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

   כניסה לדף 'נכסים'

2. בקטע Resource type בחלונית Quick filters, בוחרים באפשרות compute.Disk.

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

   החלונית Results מתעדכנת ומוצגים בה רק מקרים של סוג המשאב compute.Disk.

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

4. בתיבת הדו-שיח, לוחצים על הוספת סימון.

5. בשדה key, מזינים enforce_customer_supplied_disk_encryption_keys, ובשדה value, מזינים true.

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

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

DNS logging disabled

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

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

בהתאם לכמות המידע, עלויות הרישום ביומן של Cloud DNS יכולות להיות משמעותיות. כדי להבין את השימוש בשירות ואת העלות שלו, אפשר לעיין במאמר תמחור של Google Cloud Observability: ‏Cloud Logging.

אם הפעלתם את Security Command Center Premium ברמת הפרויקט, הממצא הזה זמין רק אם מסלול Standard-legacy מופעל בארגון האב.

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

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

   מעבר לרשתות VPC

2. ברשימת הרשתות, לוחצים על השם של רשת ה-VPC.

3. יוצרים מדיניות חדשה לשרת (אם היא לא קיימת) או עורכים מדיניות קיימת:

   • אם ברשת אין מדיניות של שרת DNS, צריך לבצע את השלבים הבאים:

     1. לוחצים על edit עריכה.
     2. בשדה מדיניות שרת DNS, לוחצים על יצירת מדיניות שרת חדשה.
     3. מזינים שם למדיניות השרת החדשה.
     4. מגדירים את Logs (יומנים) למצב On (מופעל).
     5. לוחצים על Save.

   • אם ברשת יש מדיניות של שרת DNS, מבצעים את השלבים הבאים:

     1. בשדה DNS server policy (מדיניות שרת DNS), לוחצים על שם מדיניות ה-DNS.
     2. לוחצים על edit עריכת המדיניות.
     3. מגדירים את Logs (יומנים) למצב On (מופעל).
     4. לוחצים על Save.

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

DNSSEC disabled

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

תוספי אבטחה של DNS‏ (DNSSEC) מושבתים באזורי Cloud DNS.

‫DNSSEC מאמת תגובות DNS ומצמצם סיכונים, כמו חטיפת DNS והתקפות מסוג 'אדם באמצע', על ידי חתימה קריפטוגרפית של רשומות DNS. מומלץ להפעיל DNSSEC. מידע נוסף זמין במאמר סקירה כללית על תוספי אבטחה של DNS‏ (DNSSEC).

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

1. עוברים לדף Cloud DNS במסוף Google Cloud .

   מעבר לרשתות Cloud DNS

2. מאתרים את השורה עם תחום ה-DNS שמצוין בממצא.

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

4. קוראים את תיבת הדו-שיח שמופיעה. אם מרוצים מהתוצאה, לוחצים על הפעלה.

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

Effectively Anonymous Users Granted GKE Cluster Access

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

מישהו יצר קשירת RBAC שמפנה לאחד מהמשתמשים או הקבוצות הבאים:

• system:anonymous
• system:authenticated
• system:unauthenticated

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

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

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

שדות מוגבלים

• subjects[*].name

ערכים מותרים

• כל הקבוצות, המשתמשים או חשבונות השירות שלא כוללים את system:anonymous, ‏system:authenticated או system:unauthenticated.

Egress deny rule not set

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

לא מוגדר כלל לחסימת תעבורה יוצאת בחומת אש.

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

אם הפעלתם את Security Command Center Premium ברמת הפרויקט, הממצא הזה זמין רק אם מסלול Standard-legacy מופעל בארגון האב.

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

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

   עוברים אל Firewall

2. לוחצים על יצירת כלל לחומת האש.

3. נותנים לחומת האש שם, ואפשר גם להוסיף תיאור.

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

5. בקטע פעולה בהתאמה, בוחרים באפשרות דחייה.

6. בתפריט הנפתח יעדים, בוחרים באפשרות כל המופעים ברשת.

7. בתפריט הנפתח Destination filter (מסנן יעד), בוחרים באפשרות IP ranges (טווח כתובות IP) ואז מקלידים 0.0.0.0/0 בתיבה Destination IP ranges (טווח כתובות IP של היעד).

8. בקטע Protocols and ports (פרוטוקולים ויציאות), בוחרים באפשרות Deny all (דחיית הכול).

9. לוחצים על השבתת הכלל ואז, בקטע אכיפה, בוחרים באפשרות מופעל.

10. לוחצים על יצירה.

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

Essential contacts not configured

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

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

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

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

   כניסה לדף Essential Contacts

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

3. לוחצים על +הוספת איש קשר. נפתחת החלונית הוספת איש קשר.

4. מקלידים את כתובת האימייל של איש הקשר בשדות Email ו-Confirm Email.

5. בקטע Notification categories בוחרים את הקטגוריות של ההתראות שרוצים שאיש הקשר יקבל. מוודאים שכתובות האימייל המתאימות מוגדרות לכל אחת מקטגוריות ההתראות הבאות:

   1. משפטי
   2. אבטחה
   3. השעיה
   4. טכני

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

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

Firewall not monitored

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

מדדים ונתוני התראות ביומן לא מוגדרים למעקב אחרי שינויים בכללי חומת האש של רשת VPC.

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

העלויות של Cloud Monitoring יכולות להיות משמעותיות, בהתאם לכמות המידע. כדי להבין את השימוש בשירות ואת העלויות שלו, אפשר לעיין במחירון של Google Cloud Observability.

אם הפעלתם את Security Command Center Premium ברמת הפרויקט, הממצא הזה זמין רק אם מסלול Standard-legacy מופעל בארגון האב.

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

יצירת מדד

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

   מעבר אל 'מדדים מבוססי-יומנים'

2. לוחצים על יצירת מדד.

3. בקטע סוג המדד, בוחרים באפשרות מונה.

4. בקטע פרטים:

   1. מגדירים שם של מדד יומן.
   2. מוסיפים תיאור.
   3. מגדירים את Units (יחידות) לערך 1.

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

     resource.type="gce_firewall_rule"
     AND (protoPayload.methodName:"compute.firewalls.insert"
     OR protoPayload.methodName:"compute.firewalls.patch"
     OR protoPayload.methodName:"compute.firewalls.delete")

6. לוחצים על יצירת מדד. יוצג אישור.

יצירת מדיניות התראות

1. נכנסים לדף Log-based Metrics במסוף Google Cloud :

   כניסה אל מדדים מבוססי-יומנים

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

2. בקטע מדדים שהוגדרו על ידי המשתמש, בוחרים את המדד שיצרתם בקטע הקודם.

3. לוחצים על סמל האפשרויות הנוספות more_vert ואז על יצירת התראה ממדד.

   תיבת הדו-שיח תנאי חדש תיפתח עם אפשרויות המדד והמרת הנתונים שאוכלסו מראש.

4. לוחצים על הבא.
   1. בודקים את ההגדרות שמולאו מראש. אולי תרצו לשנות את ערך הסף.
   2. לוחצים על שם התנאי ומזינים שם לתנאי.
5. לוחצים על הבא.

6. כדי להוסיף התראות למדיניות ההתראות, לוחצים על ערוצי התראות. בתיבת הדו-שיח, בוחרים ערוץ התראות אחד או יותר מהתפריט ולוחצים על אישור.

   כדי לקבל התראה כשאירועים נפתחים ונסגרים, מסמנים את התיבה Notify on incident closure. כברירת מחדל, ההתראות נשלחות רק כשנפתחים אירועים.

7. אופציונלי: מעדכנים את משך הזמן עד לסגירה אוטומטית של אירוע. השדה הזה קובע מתי מערכת Monitoring סוגרת אירועים בהיעדר נתונים של מדדים.
8. אופציונלי: לוחצים על תיעוד, ואז מוסיפים את המידע שרוצים לכלול בהודעת ההתראה.
9. לוחצים על שם ההתראה ומזינים שם למדיניות ההתראה.
10. לוחצים על יצירת מדיניות.

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

Firewall rule logging disabled

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

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

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

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

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

   כניסה לדף Firewall

2. ברשימת כללי חומת האש, לוחצים על השם של כלל חומת האש הרצוי.

3. לוחצים על edit עריכה.

4. בקטע Logs, בוחרים באפשרות On.

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

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

Flow logs disabled

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

יש רשת משנה של VPC שיומני הזרימה שלה מושבתים.

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

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

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

   מעבר לרשתות VPC

2. ברשימת הרשתות, לוחצים על שם הרשת הרצויה.

3. בדף פרטי רשת VPC, לוחצים על הכרטיסייה Subnets.

4. ברשימת רשתות המשנה, לוחצים על השם של רשת המשנה שמצוין בממצא.

5. בדף פרטי רשת המשנה, לוחצים על edit עריכה.

6. בקטע יומני זרימה, בוחרים באפשרות מופעל.

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

Flow logs settings not recommended

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

בהגדרות של רשת משנה ברשת VPC, השירות VPC Flow Logs מושבת או שלא מוגדר בהתאם להמלצות של CIS Benchmark 1.3. ‫VPC Flow Logs מתעד דגימה של זרימות נתונים ברשת שנשלחות ממופעי מכונות וירטואליות ומתקבלות בהם, וניתן להשתמש בו כדי לזהות איומים.

מידע נוסף על VPC Flow Logs ועל העלות שלהם זמין במאמר שימוש ב-VPC Flow Logs.

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

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

   מעבר לרשתות VPC

2. ברשימת הרשתות, לוחצים על שם הרשת.

3. בדף פרטי רשת VPC, לוחצים על הכרטיסייה Subnets.

4. ברשימת רשתות המשנה, לוחצים על השם של רשת המשנה שמצוין בממצא.

5. בדף פרטי רשת המשנה, לוחצים על edit עריכה.

6. בקטע יומני זרימה, בוחרים באפשרות מופעל.

   1. אופציונלי: כדי לשנות את הגדרת היומנים, לוחצים על הלחצן Configure logs כדי להרחיב את הכרטיסייה. ההגדרות המומלצות של CIS Benchmarks:
      1. מגדירים את מרווח הצבירה ל-5 שניות.
      2. בתיבת הסימון Additional fields, בוחרים באפשרות Include metadata.
      3. מגדירים את קצב הדגימה ל-100%.
      4. לוחצים על הלחצן שמירה.

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

Full API access

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

מכונה של Compute Engine מוגדרת לשימוש בחשבון השירות שמוגדר כברירת מחדל עם גישה מלאה לכל Google Cloud ממשקי ה-API.

יכול להיות שמופע שהוגדר עם חשבון השירות שמוגדר כברירת מחדל ועם היקף הגישה ל-API שהוגדר למתן גישה מלאה לכל ממשקי Cloud API יאפשר למשתמשים לבצע פעולות או קריאות ל-API שאין להם הרשאות IAM לגביהן. מידע נוסף מופיע במאמר בנושא חשבון שירות שמוגדר כברירת מחדל ב-Compute Engine.

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

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

   כניסה לדף VM instances

2. ברשימת המקרים, לוחצים על שם המקרה בתוצאת החיפוש.

3. אם המופע פועל, לוחצים על stop Stop (עצירה).

4. כשהמופע מופסק, לוחצים על edit עריכה.

5. בקטע Security and access (אבטחה וגישה), בקטע Service accounts (חשבונות שירות), בוחרים באפשרות Compute Engine default service account (חשבון שירות שמוגדר כברירת מחדל ב-Compute Engine).

6. בקטע Access scopes, בוחרים באפשרות Allow default access או באפשרות Set access for each API. ההגדרה הזו מגבילה את ממשקי ה-API שאפשר לגשת אליהם מכל תהליך או עומס עבודה שמשתמש בחשבון השירות שמוגדר כברירת מחדל במכונה הווירטואלית.

7. אם בחרתם באפשרות Set access for each API, מבצעים את הפעולות הבאות:

   • משביתים את Cloud Platform על ידי הגדרת הערך ללא.
   • מפעילים את ממשקי ה-API הספציפיים שחשבון השירות שמוגדר כברירת מחדל במכונה הווירטואלית צריך גישה אליהם.

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

9. לוחצים על play_arrow Start (התחלה) כדי להפעיל את המכונה.

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

HTTP load balancer

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

מכונה של Compute Engine משתמשת במאזן עומסים שמוגדר להשתמש ב-proxy ל-HTTP עם יעד במקום ב-proxy ל-HTTPS עם יעד.

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

אם הפעלתם את Security Command Center Premium ברמת הפרויקט, הממצא הזה זמין רק אם מסלול Standard-legacy מופעל בארגון האב.

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

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

   מעבר אל Target proxies

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

3. לוחצים על הקישור שמתחת למפת URL.

4. לוחצים על edit עריכה.

5. לוחצים על Frontend configuration.

6. מוחקים את כל ההגדרות של Frontend IP ויציאות שמאפשרות תעבורת HTTP, ויוצרים הגדרות חדשות שמאפשרות תעבורת HTTPS.

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

Instance OS login disabled

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

התכונה OS Login מושבתת במכונה הזו ב-Compute Engine.

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

אם הפעלתם את Security Command Center Premium ברמת הפרויקט, הממצא הזה זמין רק אם מסלול Standard-legacy מופעל בארגון האב.

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

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

   כניסה לדף VM instances

2. ברשימת המקרים, לוחצים על שם המקרה בתוצאת החיפוש.

3. בדף Instance details (פרטי המכונה) שנטען, לוחצים על stop Stop (עצירה).

4. אחרי שהמופע מפסיק, לוחצים על edit עריכה.

5. בקטע מטא-נתונים בהתאמה אישית, מוודאים שהפריט עם המפתח enable-oslogin מכיל את הערך TRUE.

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

7. לוחצים על play_arrow Start (התחלה) כדי להפעיל את המכונה.

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

Integrity monitoring disabled

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

המעקב אחר שלמות האפליקציה מושבת באשכול GKE.

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

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

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

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

   מעבר אל Kubernetes clusters

2. לוחצים על שם האשכול בממצא.

3. לוחצים על הוספת מאגר צמתים.

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

5. לוחצים על יצירה.

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

7. אחרי העברת עומסי העבודה, מוחקים את מאגר הצמתים המקורי שלא תואם.

   1. בדף Kubernetes cluster (אשכול Kubernetes), בתפריט Node pools (מאגרי צמתים), לוחצים על השם של מאגר הצמתים שרוצים למחוק.
   2. לוחצים על הסרת מאגר צמתים.

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

Intranode visibility disabled

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

החשיפה בתוך הצומת מושבתת באשכול GKE.

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

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

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

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

   מעבר אל Kubernetes clusters

2. בקטע Networking, בשורה Intranode visibility, לוחצים על edit Edit intranode visibility.

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

3. בתיבת הדו-שיח, בוחרים באפשרות הפעלת חשיפה בתוך הצומת.

4. לוחצים על שמירת השינויים.

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

IP alias disabled

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

נוצר אשכול GKE עם השבתה של טווחי כתובות IP חלופיות.

כשמפעילים טווחי כתובות IP של כינויים, אשכולות GKE מקצים כתובות IP מבלוק CIDR ידוע, כך שהאשכול ניתן להרחבה ופועל בצורה טובה יותר עם מוצרים וישויות של Google Cloud . מידע נוסף מופיע במאמר סקירה כללית על טווחים של כתובות IP של כינויים.

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

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

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

   מעבר אל Kubernetes clusters

2. לוחצים על יצירה.

3. בחלונית הניווט, בקטע Cluster, לוחצים על Networking.

4. בקטע אפשרויות מתקדמות של רשת, בוחרים באפשרות הפעלה של ניתוב תעבורה מקורי ב-VPC (שימוש בכתובת IP עם כינוי).

5. לוחצים על יצירה.

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

IP forwarding enabled

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

העברת IP מופעלת במכונות ב-Compute Engine.

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

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

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

   כניסה לדף VM instances

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

3. לוחצים על delete מחיקה.

4. בוחרים באפשרות Create Instance (יצירת מכונה) כדי ליצור מכונה חדשה שתחליף את המכונה שמחקתם.

5. כדי לוודא שהעברת כתובות IP מושבתת, לוחצים על ניהול, דיסקים, רשתות, מפתחות SSH ואז על רשתות.

6. בקטע Network interfaces, לוחצים על edit Edit.

7. בקטע העברת כתובות IP, בתפריט הנפתח, מוודאים שהאפשרות מושבת מסומנת.

8. מציינים פרמטרים אחרים של המופע ולוחצים על יצירה. מידע נוסף זמין במאמר יצירה והפעלה של מכונה וירטואלית.

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

KMS key not rotated

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

לא מוגדרת רוטציה במפתח הצפנה של Cloud KMS.

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

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

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

   מעבר למפתחות Cloud KMS

2. לוחצים על השם של אוסף המפתחות שמצוין בתוצאת החיפוש.

3. לוחצים על שם המפתח שמצוין בתוצאה.

4. לוחצים על עריכת תקופת הרוטציה.

5. מגדירים את תקופת הרוטציה ל-90 ימים לכל היותר.

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

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

KMS project has owner

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

למשתמש יש הרשאות roles/Owner בפרויקט שיש בו מפתחות קריפטוגרפיים. מידע נוסף זמין במאמר בנושא הרשאות ותפקידים.

אם הפעלתם את Security Command Center Premium ברמת הפרויקט, הממצא הזה זמין רק אם מסלול Standard-legacy מופעל בארגון האב.

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

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

   כניסה לדף IAM

2. אם צריך, בוחרים את הפרויקט בתוצאת החיפוש.

3. לכל חשבון משתמש שהוקצה לו התפקיד בעלים:

   1. לוחצים על edit עריכה.
   2. בחלונית Edit permissions, ליד התפקיד Owner, לוחצים על delete Delete.
   3. לוחצים על Save.

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

KMS public key

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

מפתח הצפנה או אוסף מפתחות של Cloud KMS הם ציבוריים וכל אחד באינטרנט יכול לגשת אליהם. מידע נוסף זמין במאמר שימוש ב-IAM עם Cloud KMS.

כדי לפתור את הממצא הזה, אם הוא קשור ל-CryptoKey:

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

   מפתחות קריפטוגרפיים

2. בקטע Name, בוחרים את אוסף המפתחות שמכיל את המפתח הקריפטוגרפי שקשור לממצא של Security Health Analytics.

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

4. אם חלונית המידע לא מוצגת, לוחצים על הלחצן הצגת חלונית המידע.

5. משתמשים בתיבת הסינון שלפני Role / Principal כדי לחפש את החשבונות allUsers ו-allAuthenticatedUsers, ולוחצים על delete Delete כדי להסיר את הגישה של החשבונות האלה.

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

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

   מפתחות קריפטוגרפיים

2. מוצאים את השורה עם מחזיק המפתחות בתוצאה ובוחרים את תיבת הסימון.

3. אם חלונית המידע לא מוצגת, לוחצים על הלחצן הצגת חלונית המידע.

4. משתמשים בתיבת הסינון שלפני Role / Principal כדי לחפש את החשבונות allUsers ו-allAuthenticatedUsers, ולוחצים על delete Delete כדי להסיר את הגישה של החשבונות האלה.

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

KMS role separation

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

הממצא הזה לא זמין להפעלות ברמת הפרויקט.

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

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

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

   כניסה לדף IAM

2. לכל חשבון ראשי שמופיע בממצא, מבצעים את הפעולות הבאות:

   1. כדי לבדוק אם התפקיד הועבר בירושה מתיקייה או ממשאב ארגוני, מסתכלים בעמודה העברה בירושה. אם העמודה מכילה קישור למשאב אב, לוחצים על הקישור כדי לעבור לדף IAM של משאב האב.
   2. לוחצים על edit עריכה לצד העיקרון.
   3. כדי להסיר הרשאות, לוחצים על delete מחיקה לצד אדמין של Cloud KMS. אם רוצים להסיר את כל ההרשאות של הגורם המורשה, לוחצים על מחיקה לצד כל ההרשאות האחרות.

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

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

Legacy authorization enabled

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

ההרשאה מדור קודם מופעלת באשכולות GKE.

ב-Kubernetes, בקרת גישה מבוססת-תפקידים (RBAC) מאפשרת להגדיר תפקידים עם כללים שמכילים קבוצה של הרשאות, ולהעניק הרשאות ברמת האשכול וברמת מרחב השמות. התכונה הזו מספקת אבטחה טובה יותר כי היא מוודאת שלמשתמשים יש גישה רק למשאבים ספציפיים. כדאי להשבית את בקרת הגישה מבוססת-המאפיינים (ABAC) מדור קודם.

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

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

   מעבר אל Kubernetes clusters

2. בוחרים את האשכול שמופיע בתוצאת החיפוש של Security Health Analytics.

3. לוחצים על edit עריכה.

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

4. ברשימה הנפתחת Legacy Authorization (הרשאה מדור קודם), בוחרים באפשרות Disabled (מושבת).

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

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

Legacy metadata enabled

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

מטא-נתונים מדור קודם מופעלים באשכולות GKE.

שרת המטא-נתונים של מכונות VM ב-Compute Engine חושף נקודות קצה מדור קודם /0.1/ ו-/v1beta1/ שלא אוכפות כותרות של שאילתות מטא-נתונים. זו תכונה בממשקי /v1/ API שמקשה על תוקף פוטנציאלי לאחזר מטא-נתונים של מופע. אלא אם יש צורך בכך, מומלץ להשבית את ממשקי ה-API מדור קודם /0.1/ ו-/v1beta1/.

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

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

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

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

Legacy network

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

קיימת רשת מדור קודם בפרויקט.

לא מומלץ להשתמש ברשתות מדור קודם כי הרבה אמצעי אבטחה חדשים לא נתמכים ברשתות מדור קודם. Google Cloud במקום זאת, משתמשים ברשתות VPC. מידע נוסף זמין במאמר בנושא רשתות מדור קודם.

אם הפעלתם את Security Command Center Premium ברמת הפרויקט, הממצא הזה זמין רק אם מסלול Standard-legacy מופעל בארגון האב.

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

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

   מעבר לרשתות VPC

2. כדי ליצור רשת חדשה שאינה מדור קודם, לוחצים על יצירת רשת.

3. חוזרים לדף רשתות VPC.

4. ברשימת הרשתות, לוחצים על legacy_network.

5. בדף VPC network details (פרטי רשת VPC), לוחצים על delete Delete VPC Network (מחיקת רשת VPC).

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

Load balancer logging disabled

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

הרישום ביומן מושבת בשירות הקצה העורפי במאזן עומסים.

הפעלת הרישום ביומן של מאזן עומסים מאפשרת לכם לראות את תעבורת הרשת של HTTP(S) באפליקציות האינטרנט שלכם. מידע נוסף זמין במאמר בנושא מאזן עומסים.

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

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

   כניסה ל-Cloud Load Balancing

2. לוחצים על השם של מאזן העומסים.

3. לוחצים על edit עריכה.

4. לוחצים על Backend configuration.

5. בדף Backend configuration, לוחצים על edit Edit.

6. בקטע Logging, בוחרים באפשרות Enable logging ובוחרים את קצב הדגימה המתאים ביותר לפרויקט.

7. כדי לסיים את העריכה של שירות לקצה העורפי, לוחצים על עדכון.

8. כדי לסיים את העריכה של מאזן העומסים, לוחצים על עדכון.

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

Locked retention policy not set

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

לא מוגדרת מדיניות שמירת נתונים נעולה ליומנים.

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

אם הפעלתם את Security Command Center Premium ברמת הפרויקט, הממצא הזה זמין רק אם מסלול Standard-legacy מופעל בארגון האב.

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

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

   כניסה לדף Storage Browser

2. בוחרים את הקטגוריה שמופיעה בתוצאה של Security Health Analytics.

3. בדף Bucket details, לוחצים על הכרטיסייה Retention.

4. אם לא הוגדרה מדיניות שמירת נתונים, לוחצים על Set Retention Policy (הגדרת מדיניות שמירת נתונים).

5. מזינים תקופת שמירה.

6. לוחצים על Save. מדיניות שמירת הנתונים מוצגת בכרטיסייה שמירה.

7. לוחצים על נעילה כדי לוודא שתקופת השמירה לא תקוצר או תוסר.

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

Log not exported

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

לא הוגדר משאב עם sink מתאים ביומן.

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

אם הפעלתם את Security Command Center Premium ברמת הפרויקט, הממצא הזה זמין רק אם מסלול Standard-legacy מופעל בארגון האב.

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

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

   מעבר אל Log Router

2. לוחצים על Create Sink.

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

4. לוחצים על Create Sink.

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

Master authorized networks disabled

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

האפשרות 'רשתות מורשות במישור הבקרה' לא מופעלת באשכולות GKE.

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

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

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

   מעבר אל Kubernetes clusters

2. בוחרים את האשכול שמופיע בתוצאת החיפוש של Security Health Analytics.

3. לוחצים על edit עריכה.

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

4. ברשימה הנפתחת Control Plane Authorized Networks, בוחרים באפשרות Enabled.

5. לוחצים על הוספה של חברת ביטוח.

6. מציינים את הרשתות המורשות שבהן רוצים להשתמש.

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

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

MFA not enforced

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

הממצא הזה לא זמין להפעלות ברמת הפרויקט.

האימות הרב-שלבי, ובמיוחד האימות הדו-שלבי (2SV), מושבת אצל חלק מהמשתמשים בארגון.

אימות רב-שלבי (MFA) משמש להגנה על חשבונות מפני גישה לא מורשית, והוא הכלי החשוב ביותר להגנה על הארגון מפני פריצה לפרטי הכניסה. מידע נוסף זמין במאמר הגנה על העסק באמצעות אימות דו-שלבי.

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

1. עוברים לדף מסוף Admin במסוף Google Cloud .

   כניסה למסוף Admin

2. אכיפה של אימות דו-שלבי בכל היחידות הארגוניות.

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

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

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

• כדי למנוע את ההפעלה של הממצא הזה שוב, מוסיפים לנכס את סימן האבטחה allow_mfa_not_enforced עם הערך true.
• כדי להתעלם מהפרות פוטנציאליות ביחידות ארגוניות ספציפיות, מוסיפים את הסימן excluded_orgunits לאמצעי הבקרה עם רשימה של נתיבי יחידות ארגוניות שמופרדים בפסיקים בשדה value. לדוגמה: excluded_orgunits:/people/vendors/vendorA,/people/contractors/contractorA.

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

Network not monitored

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

מדדים ונתוני התראות ביומן לא מוגדרים למעקב אחרי שינויים ברשת VPC.

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

העלויות של Cloud Monitoring יכולות להיות משמעותיות, בהתאם לכמות המידע. כדי להבין את השימוש בשירות ואת העלויות שלו, אפשר לעיין במחירון של Google Cloud Observability.

אם הפעלתם את Security Command Center Premium ברמת הפרויקט, הממצא הזה זמין רק אם מסלול Standard-legacy מופעל בארגון האב.

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

יצירת מדד

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

   מעבר אל 'מדדים מבוססי-יומנים'

2. לוחצים על יצירת מדד.

3. בקטע סוג המדד, בוחרים באפשרות מונה.

4. בקטע פרטים:

   1. מגדירים שם של מדד יומן.
   2. מוסיפים תיאור.
   3. מגדירים את Units (יחידות) לערך 1.

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

     resource.type="gce_network"
     AND (protoPayload.methodName:"compute.networks.insert"
     OR protoPayload.methodName:"compute.networks.patch"
     OR protoPayload.methodName:"compute.networks.delete"
     OR protoPayload.methodName:"compute.networks.removePeering"
     OR protoPayload.methodName:"compute.networks.addPeering")

6. לוחצים על יצירת מדד. יוצג אישור.

יצירת מדיניות התראות

1. נכנסים לדף Log-based Metrics במסוף Google Cloud :

   כניסה אל מדדים מבוססי-יומנים

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

2. בקטע מדדים שהוגדרו על ידי המשתמש, בוחרים את המדד שיצרתם בקטע הקודם.

3. לוחצים על סמל האפשרויות הנוספות more_vert ואז על יצירת התראה ממדד.

   תיבת הדו-שיח תנאי חדש תיפתח עם אפשרויות המדד והמרת הנתונים שאוכלסו מראש.

4. לוחצים על הבא.
   1. בודקים את ההגדרות שמולאו מראש. אולי תרצו לשנות את ערך הסף.
   2. לוחצים על שם התנאי ומזינים שם לתנאי.
5. לוחצים על הבא.

6. כדי להוסיף התראות למדיניות ההתראות, לוחצים על ערוצי התראות. בתיבת הדו-שיח, בוחרים ערוץ התראות אחד או יותר מהתפריט ולוחצים על אישור.

   כדי לקבל התראה כשאירועים נפתחים ונסגרים, מסמנים את התיבה Notify on incident closure. כברירת מחדל, ההתראות נשלחות רק כשנפתחים אירועים.

7. אופציונלי: מעדכנים את משך הזמן עד לסגירה אוטומטית של אירוע. השדה הזה קובע מתי מערכת Monitoring סוגרת אירועים בהיעדר נתונים של מדדים.
8. אופציונלי: לוחצים על תיעוד, ואז מוסיפים את המידע שרוצים לכלול בהודעת ההתראה.
9. לוחצים על שם ההתראה ומזינים שם למדיניות ההתראה.
10. לוחצים על יצירת מדיניות.

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

Network policy disabled

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

מדיניות הרשת מושבתת באשכולות GKE.

כברירת מחדל, התקשורת בין הפודים פתוחה. תקשורת פתוחה מאפשרת ל-pods להתחבר ישירות בין צמתים, עם או בלי תרגום כתובות רשת (NAT). משאב NetworkPolicy הוא כמו חומת אש ברמת הפוד שמגבילה את החיבורים בין הפודים, אלא אם משאב NetworkPolicy מאפשר את החיבור באופן מפורש. איך מגדירים מדיניות רשת

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

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

   מעבר אל Kubernetes clusters

2. לוחצים על שם האשכול שמופיע בתוצאת הבדיקה של Security Health Analytics.

3. בקטע Networking, בשורה Calico Kubernetes Network policy, לוחצים על edit Edit.

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

4. בתיבת הדו-שיח, בוחרים באפשרות הפעלה של מדיניות רשת Calico Kubernetes למישור הבקרה והפעלה של מדיניות רשת Calico Kubernetes לצמתים.

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

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

Nodepool boot CMEK disabled

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

דיסקים של אתחול במאגר הצמתים הזה לא מוצפנים באמצעות מפתחות הצפנה בניהול הלקוח (CMEK). ‫CMEK מאפשר למשתמש להגדיר את מפתחות ההצפנה שמוגדרים כברירת מחדל לדיסקים של אתחול במאגר צמתים.

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

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

   מעבר אל Kubernetes clusters

2. ברשימת האשכולות, לוחצים על שם האשכול בממצא.

3. לוחצים על הכרטיסייה Nodes.

4. לכל מאגר צמתים מסוג default-pool, לוחצים על delete מחיקה.

5. כשמופיעה בקשה לאישור, לוחצים על מחיקה.

6. כדי ליצור מאגרי צמתים חדשים באמצעות CMEK, אפשר לעיין במאמר בנושא שימוש במפתחות הצפנה בניהול הלקוח (CMEK). השימוש ב-CMEK כרוך בעלויות נוספות שקשורות ל-Cloud KMS.

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

Nodepool secure boot disabled

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

ההפעלה המאובטחת מושבתת באשכול GKE.

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

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

אחרי שמקצים מאגר צמתים, אי אפשר לעדכן אותו כדי להפעיל את האתחול המאובטח. צריך ליצור מאגר צמתים חדש עם Secure Boot (אתחול מאובטח) מופעל.

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

   מעבר אל Kubernetes clusters

2. לוחצים על שם האשכול בממצא.

3. לוחצים על הוספת מאגר צמתים.

4. בתפריט Node pools, מבצעים את הפעולות הבאות:

   1. לוחצים על השם של מאגר הצמתים החדש כדי להרחיב את הכרטיסייה.
   2. בוחרים באפשרות אבטחה, ואז בקטע אפשרויות מוגנות בוחרים באפשרות הפעלת אתחול מאובטח.
   3. לוחצים על יצירה.
   4. כדי להעביר את עומסי העבודה ממאגרי הצמתים הקיימים שלא עומדים בדרישות למאגרי הצמתים החדשים, אפשר לעיין במאמר בנושא העברת עומסי עבודה לסוגים שונים של מכונות.
   5. אחרי העברת עומסי העבודה, מוחקים את מאגר הצמתים המקורי שלא תואם.

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

Non org IAM member

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

למשתמש מחוץ לארגון או לפרויקט יש הרשאות IAM בפרויקט או בארגון. מידע נוסף על הרשאות ב-IAM

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

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

   כניסה לדף IAM

2. מסמנים את התיבה לצד משתמשים מחוץ לארגון או לפרויקט.

3. לוחצים על הסרה.

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

Object versioning disabled

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

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

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

אם הפעלתם את Security Command Center Premium ברמת הפרויקט, הממצא הזה זמין רק אם מסלול Standard-legacy מופעל בארגון האב.

כדי לתקן את הממצא הזה, משתמשים בדגל --versioning בפקודה gcloud storage buckets update עם הערך המתאים:

    gcloud storage buckets update gs://finding.assetDisplayName --versioning

מחליפים את finding.assetDisplayName בשם הקטגוריה הרלוונטית.

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

Open Cassandra port

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

כללי חומת אש שמאפשרים לכל כתובת IP להתחבר ליציאות של Cassandra עלולים לחשוף את שירותי Cassandra שלכם לתוקפים. מידע נוסף זמין במאמר סקירה כללית על כללים של חומת אש ב-VPC.

היציאות של שירות Cassandra הן:

• TCP - 7000, 7001, 7199, 8888, 9042, 9160, 61620, 61621

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

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

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

   כניסה לדף Firewall

2. ברשימת כללי חומת האש, לוחצים על שם כלל חומת האש בתוצאת הסריקה.

3. לוחצים על edit עריכה.

4. בקטע Source IP ranges (טווחי כתובות ה-IP של המקור), מוחקים את 0.0.0.0/0.

5. מוסיפים כתובות IP ספציפיות או טווחי כתובות IP שרוצים לאפשר להם להתחבר למופע.

6. מוסיפים פרוטוקולים ויציאות ספציפיים שרוצים לפתוח במופע.

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

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

Open ciscosecure websm port

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

כללי חומת אש שמאפשרים לכל כתובת IP להתחבר ליציאות של CiscoSecure/WebSM עלולים לחשוף את שירותי CiscoSecure/WebSM שלכם לתוקפים. מידע נוסף זמין במאמר סקירה כללית על כללים של חומת אש ב-VPC.

יציאות השירות של CiscoSecure/WebSM הן:

• TCP - 9090

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

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

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

   כניסה לדף Firewall

2. ברשימת כללי חומת האש, לוחצים על שם כלל חומת האש בתוצאת הסריקה.

3. לוחצים על edit עריכה.

4. בקטע Source IP ranges (טווחי כתובות ה-IP של המקור), מוחקים את 0.0.0.0/0.

5. מוסיפים כתובות IP ספציפיות או טווחי כתובות IP שרוצים לאפשר להם להתחבר למופע.

6. מוסיפים פרוטוקולים ויציאות ספציפיים שרוצים לפתוח במופע.

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

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

Open directory services port

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

כללי חומת אש שמאפשרים לכל כתובת IP להתחבר ליציאות של Directory עלולים לחשוף את שירותי Directory שלכם לתוקפים. מידע נוסף זמין במאמר סקירה כללית על כללים של חומת אש ב-VPC.

היציאות של שירות הספרייה הן:

• TCP - 445
• UDP - 445

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

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

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

   כניסה לדף Firewall

2. ברשימת כללי חומת האש, לוחצים על שם כלל חומת האש בתוצאת הסריקה.

3. לוחצים על edit עריכה.

4. בקטע Source IP ranges (טווחי כתובות ה-IP של המקור), מוחקים את 0.0.0.0/0.

5. מוסיפים כתובות IP ספציפיות או טווחי כתובות IP שרוצים לאפשר להם להתחבר למופע.

6. מוסיפים פרוטוקולים ויציאות ספציפיים שרוצים לפתוח במופע.

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

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

Open DNS port

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

כללי חומת אש שמאפשרים לכל כתובת IP להתחבר ליציאות DNS עלולים לחשוף את שירותי ה-DNS שלכם לתוקפים. מידע נוסף זמין במאמר סקירה כללית על כללים של חומת אש ב-VPC.

יציאות שירות ה-DNS הן:

• TCP - 53
• UDP - 53

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

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

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

   כניסה לדף Firewall

2. ברשימת כללי חומת האש, לוחצים על שם כלל חומת האש בתוצאת הסריקה.

3. לוחצים על edit עריכה.

4. בקטע Source IP ranges (טווחי כתובות ה-IP של המקור), מוחקים את 0.0.0.0/0.

5. מוסיפים כתובות IP ספציפיות או טווחי כתובות IP שרוצים לאפשר להם להתחבר למופע.

6. מוסיפים פרוטוקולים ויציאות ספציפיים שרוצים לפתוח במופע.

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

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

Open Elasticsearch port

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

כללי חומת אש שמאפשרים לכל כתובת IP להתחבר ליציאות של Elasticsearch עלולים לחשוף את שירותי Elasticsearch שלכם לתוקפים. מידע נוסף זמין במאמר סקירה כללית על כללים של חומת אש ב-VPC.

יציאות שירות Elasticsearch הן:

• TCP - 9200, 9300

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

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

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

   כניסה לדף Firewall

2. ברשימת כללי חומת האש, לוחצים על שם כלל חומת האש בתוצאת הסריקה.

3. לוחצים על edit עריכה.

4. בקטע Source IP ranges (טווחי כתובות ה-IP של המקור), מוחקים את 0.0.0.0/0.

5. מוסיפים כתובות IP ספציפיות או טווחי כתובות IP שרוצים לאפשר להם להתחבר למופע.

6. מוסיפים פרוטוקולים ויציאות ספציפיים שרוצים לפתוח במופע.

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

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

Open firewall

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

כללי חומת אש שמאפשרים חיבורים מכל כתובות ה-IP, כמו 0.0.0.0/0, או מכל היציאות, עלולים לחשוף משאבים להתקפות ממקורות לא מכוונים. צריך להסיר את הכללים האלה או להגדיר אותם במפורש לטווחי כתובות ה-IP או ליציאות המקוריות המיועדות. לדוגמה, באפליקציות שמיועדות לציבור, כדאי להגביל את היציאות המותרות לאלה שנדרשות לאפליקציה, כמו 80 ו-443. אם האפליקציה שלכם צריכה לאפשר חיבורים מכל כתובות ה-IP או היציאות, כדאי להוסיף את הנכס לרשימת ההיתרים. מידע נוסף על עדכון הכללים של חומת האש

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

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

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

   מעבר לכללי חומת אש

2. לוחצים על כלל חומת האש שמופיע בממצא של Security Health Analytics, ואז לוחצים על edit עריכה.

3. בקטע טווחי כתובות IP של מקורות, עורכים את ערכי ה-IP כדי להגביל את טווח כתובות ה-IP המותרות.

4. בקטע Protocols and ports [פרוטוקולים ויציאות], בוחרים באפשרות Specified protocols and ports [פרוטוקולים ויציאות שצוינו], בוחרים את הפרוטוקולים המותרים ומזינים את היציאות המותרות.

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

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

Open FTP port

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

כללי חומת אש שמאפשרים לכל כתובת IP להתחבר ליציאות FTP עלולים לחשוף את שירותי ה-FTP שלכם לתוקפים. מידע נוסף זמין במאמר סקירה כללית על כללים של חומת אש ב-VPC.

יציאות שירות ה-FTP הן:

• TCP - 21

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

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

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

   כניסה לדף Firewall

2. ברשימת כללי חומת האש, לוחצים על שם כלל חומת האש בתוצאת הסריקה.

3. לוחצים על edit עריכה.

4. בקטע Source IP ranges (טווחי כתובות ה-IP של המקור), מוחקים את 0.0.0.0/0.

5. מוסיפים כתובות IP ספציפיות או טווחי כתובות IP שרוצים לאפשר להם להתחבר למופע.

6. מוסיפים פרוטוקולים ויציאות ספציפיים שרוצים לפתוח במופע.

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

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

Open group IAM member

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

אחד או יותר מהגורמים שיש להם גישה לארגון, לפרויקט או לתיקייה הם חשבונות של קבוצות Google שאפשר להצטרף אליהם בלי אישור.

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

אם משתמשים בחשבון פתוח של קבוצות Google כישות מורשית בקשירת IAM, כל אחד יכול לרשת את התפקיד המשויך פשוט על ידי הצטרפות לקבוצה באופן ישיר או עקיף (דרך תת-קבוצה). מומלץ לבטל את התפקידים של הקבוצות הפתוחות או להגביל את הגישה לקבוצות האלה.

כדי לטפל בבעיה הזו, מבצעים אחת מהפעולות הבאות.

הסרת הקבוצה ממדיניות ה-IAM

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

   כניסה לדף IAM

2. אם צריך, בוחרים את הפרויקט, התיקייה או הארגון בתוצאת החיפוש.

3. ביטול התפקיד של כל קבוצה פתוחה שזוהתה בממצא.

הגבלת הגישה לקבוצות הפתוחות

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

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

Open HTTP port

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

כללי חומת אש שמאפשרים לכל כתובת IP להתחבר ליציאות HTTP עלולים לחשוף את שירותי ה-HTTP שלכם לתוקפים. מידע נוסף זמין במאמר סקירה כללית על כללים של חומת אש ב-VPC.

יציאות שירות ה-HTTP הן:

• TCP - 80

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

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

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

   כניסה לדף Firewall

2. ברשימת כללי חומת האש, לוחצים על שם כלל חומת האש בתוצאת הסריקה.

3. לוחצים על edit עריכה.

4. בקטע Source IP ranges (טווחי כתובות ה-IP של המקור), מוחקים את 0.0.0.0/0.

5. מוסיפים כתובות IP ספציפיות או טווחי כתובות IP שרוצים לאפשר להם להתחבר למופע.

6. מוסיפים פרוטוקולים ויציאות ספציפיים שרוצים לפתוח במופע.

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

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

Open LDAP port

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

כללי חומת אש שמאפשרים לכל כתובת IP להתחבר ליציאות LDAP עלולים לחשוף את שירותי ה-LDAP שלכם לתוקפים. מידע נוסף זמין במאמר סקירה כללית על כללים של חומת אש ב-VPC.

היציאות של שירות ה-LDAP הן:

• TCP - 389, 636
• UDP - 389

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

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

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

   כניסה לדף Firewall

2. ברשימת כללי חומת האש, לוחצים על שם כלל חומת האש בתוצאת הסריקה.

3. לוחצים על edit עריכה.

4. בקטע Source IP ranges (טווחי כתובות ה-IP של המקור), מוחקים את 0.0.0.0/0.

5. מוסיפים כתובות IP ספציפיות או טווחי כתובות IP שרוצים לאפשר להם להתחבר למופע.

6. מוסיפים פרוטוקולים ויציאות ספציפיים שרוצים לפתוח במופע.

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

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

Open Memcached port

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

כללי חומת אש שמאפשרים לכל כתובת IP להתחבר ליציאות של Memcached עלולים לחשוף את שירותי Memcached שלכם לתוקפים. מידע נוסף זמין במאמר סקירה כללית על כללים של חומת אש ב-VPC.

יציאות השירות של Memcached הן:

• TCP - 11211, 11214, 11215
• UDP - 11211, 11214, 11215

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

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

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

   כניסה לדף Firewall

2. ברשימת כללי חומת האש, לוחצים על שם כלל חומת האש בתוצאת הסריקה.

3. לוחצים על edit עריכה.

4. בקטע Source IP ranges (טווחי כתובות ה-IP של המקור), מוחקים את 0.0.0.0/0.

5. מוסיפים כתובות IP ספציפיות או טווחי כתובות IP שרוצים לאפשר להם להתחבר למופע.

6. מוסיפים פרוטוקולים ויציאות ספציפיים שרוצים לפתוח במופע.

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

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

Open MongoDB port

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

כללי חומת אש שמאפשרים לכל כתובת IP להתחבר ליציאות של MongoDB עלולים לחשוף את שירותי MongoDB שלכם לתוקפים. מידע נוסף זמין במאמר סקירה כללית על כללים של חומת אש ב-VPC.

יציאות השירות של MongoDB הן:

• TCP - 27017, 27018, 27019

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

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

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

   כניסה לדף Firewall

2. ברשימת כללי חומת האש, לוחצים על שם כלל חומת האש בתוצאת הסריקה.

3. לוחצים על edit עריכה.

4. בקטע Source IP ranges (טווחי כתובות ה-IP של המקור), מוחקים את 0.0.0.0/0.

5. מוסיפים כתובות IP ספציפיות או טווחי כתובות IP שרוצים לאפשר להם להתחבר למופע.

6. מוסיפים פרוטוקולים ויציאות ספציפיים שרוצים לפתוח במופע.

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

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

Open MySQL port

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

כללי חומת אש שמאפשרים לכל כתובת IP להתחבר ליציאות של MySQL עלולים לחשוף את שירותי MySQL שלכם לתוקפים. מידע נוסף זמין במאמר סקירה כללית על כללים של חומת אש ב-VPC.

יציאות השירות של MySQL הן:

• TCP - 3306

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

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

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

   כניסה לדף Firewall

2. ברשימת כללי חומת האש, לוחצים על שם כלל חומת האש בתוצאת הסריקה.

3. לוחצים על edit עריכה.

4. בקטע Source IP ranges (טווחי כתובות ה-IP של המקור), מוחקים את 0.0.0.0/0.

5. מוסיפים כתובות IP ספציפיות או טווחי כתובות IP שרוצים לאפשר להם להתחבר למופע.

6. מוסיפים פרוטוקולים ויציאות ספציפיים שרוצים לפתוח במופע.

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

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

Open NetBIOS port

שם הקטגוריה ב-API: ‏ `OPEN_NETBIOS_PORT

כללי חומת אש שמאפשרים לכל כתובת IP להתחבר ליציאות NetBIOS עלולים לחשוף את שירותי NetBIOS שלכם לתוקפים. מידע נוסף זמין במאמר סקירה כללית על כללים של חומת אש ב-VPC.

יציאות השירות של NetBIOS הן:

• TCP - 137, 138, 139
• UDP - 137, 138, 139

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

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

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

   כניסה לדף Firewall

2. ברשימת כללי חומת האש, לוחצים על שם כלל חומת האש בתוצאת הסריקה.

3. לוחצים על edit עריכה.

4. בקטע Source IP ranges (טווחי כתובות ה-IP של המקור), מוחקים את 0.0.0.0/0.

5. מוסיפים כתובות IP ספציפיות או טווחי כתובות IP שרוצים לאפשר להם להתחבר למופע.

6. מוסיפים פרוטוקולים ויציאות ספציפיים שרוצים לפתוח במופע.

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

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

Open OracleDB port

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

כללי חומת אש שמאפשרים לכל כתובת IP להתחבר ליציאות של OracleDB עלולים לחשוף את שירותי OracleDB שלכם לתוקפים. מידע נוסף זמין במאמר סקירה כללית על כללים של חומת אש ב-VPC.

יציאות שירות OracleDB הן:

• TCP - 1521, 2483, 2484
• UDP - 2483, 2484

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

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

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

   כניסה לדף Firewall

2. ברשימת כללי חומת האש, לוחצים על שם כלל חומת האש בתוצאת הסריקה.

3. לוחצים על edit עריכה.

4. בקטע Source IP ranges (טווחי כתובות ה-IP של המקור), מוחקים את 0.0.0.0/0.

5. מוסיפים כתובות IP ספציפיות או טווחי כתובות IP שרוצים לאפשר להם להתחבר למופע.

6. מוסיפים פרוטוקולים ויציאות ספציפיים שרוצים לפתוח במופע.

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

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

Open POP3 port

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

כללי חומת אש שמאפשרים לכל כתובת IP להתחבר ליציאות POP3 עלולים לחשוף את שירותי POP3 שלכם לתוקפים. מידע נוסף זמין במאמר סקירה כללית על כללים של חומת אש ב-VPC.

יציאות שירות POP3 הן:

• TCP - 110

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

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

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

   כניסה לדף Firewall

2. ברשימת כללי חומת האש, לוחצים על שם כלל חומת האש בתוצאת הסריקה.

3. לוחצים על edit עריכה.

4. בקטע Source IP ranges (טווחי כתובות ה-IP של המקור), מוחקים את 0.0.0.0/0.

5. מוסיפים כתובות IP ספציפיות או טווחי כתובות IP שרוצים לאפשר להם להתחבר למופע.

6. מוסיפים פרוטוקולים ויציאות ספציפיים שרוצים לפתוח במופע.

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

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

Open PostgreSQL port

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

כללי חומת אש שמאפשרים לכל כתובת IP להתחבר ליציאות של PostgreSQL עלולים לחשוף את שירותי PostgreSQL שלכם לתוקפים. מידע נוסף זמין במאמר סקירה כללית על כללים של חומת אש ב-VPC.

יציאות השירות של PostgreSQL הן:

• TCP - 5432
• UDP - 5432

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

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

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

   כניסה לדף Firewall

2. ברשימת כללי חומת האש, לוחצים על שם כלל חומת האש בתוצאת הסריקה.

3. לוחצים על edit עריכה.

4. בקטע Source IP ranges (טווחי כתובות ה-IP של המקור), מוחקים את 0.0.0.0/0.

5. מוסיפים כתובות IP ספציפיות או טווחי כתובות IP שרוצים לאפשר להם להתחבר למופע.

6. מוסיפים פרוטוקולים ויציאות ספציפיים שרוצים לפתוח במופע.

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

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

Open RDP port

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

כללי חומת אש שמאפשרים לכל כתובת IP להתחבר ליציאות RDP עלולים לחשוף את שירותי ה-RDP שלכם לתוקפים. מידע נוסף זמין במאמר סקירה כללית על כללים של חומת אש ב-VPC.

יציאות שירות ה-RDP הן:

• TCP - 3389
• UDP - 3389

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

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

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

   כניסה לדף Firewall

2. ברשימת כללי חומת האש, לוחצים על שם כלל חומת האש בתוצאת הסריקה.

3. לוחצים על edit עריכה.

4. בקטע Source IP ranges (טווחי כתובות ה-IP של המקור), מוחקים את 0.0.0.0/0.

5. מוסיפים כתובות IP ספציפיות או טווחי כתובות IP שרוצים לאפשר להם להתחבר למופע.

6. מוסיפים פרוטוקולים ויציאות ספציפיים שרוצים לפתוח במופע.

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

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

Open Redis port

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

כללי חומת אש שמאפשרים לכל כתובת IP להתחבר ליציאות של Redis עלולים לחשוף את שירותי Redis שלכם לתוקפים. מידע נוסף זמין במאמר סקירה כללית על כללים של חומת אש ב-VPC.

יציאות שירות Redis הן:

• TCP - 6379

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

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

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

   כניסה לדף Firewall

2. ברשימת כללי חומת האש, לוחצים על שם כלל חומת האש בתוצאת הסריקה.

3. לוחצים על edit עריכה.

4. בקטע Source IP ranges (טווחי כתובות ה-IP של המקור), מוחקים את 0.0.0.0/0.

5. מוסיפים כתובות IP ספציפיות או טווחי כתובות IP שרוצים לאפשר להם להתחבר למופע.

6. מוסיפים פרוטוקולים ויציאות ספציפיים שרוצים לפתוח במופע.

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

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

Open SMTP port

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

כללי חומת אש שמאפשרים לכל כתובת IP להתחבר ליציאות SMTP עלולים לחשוף את שירותי ה-SMTP שלכם לתוקפים. מידע נוסף זמין במאמר סקירה כללית על כללים של חומת אש ב-VPC.

יציאות שירות ה-SMTP הן:

• TCP - 25

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

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

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

   כניסה לדף Firewall

2. ברשימת כללי חומת האש, לוחצים על שם כלל חומת האש בתוצאת הסריקה.

3. לוחצים על edit עריכה.

4. בקטע Source IP ranges (טווחי כתובות ה-IP של המקור), מוחקים את 0.0.0.0/0.

5. מוסיפים כתובות IP ספציפיות או טווחי כתובות IP שרוצים לאפשר להם להתחבר למופע.

6. מוסיפים פרוטוקולים ויציאות ספציפיים שרוצים לפתוח במופע.

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

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

Open SSH port

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

כללי חומת אש שמאפשרים לכל כתובת IP להתחבר ליציאות SSH עלולים לחשוף את שירותי ה-SSH שלכם לתוקפים. מידע נוסף זמין במאמר סקירה כללית על כללים של חומת אש ב-VPC.

יציאות שירות ה-SSH הן:

• SCTP - 22
• TCP - 22

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

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

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

   כניסה לדף Firewall

2. ברשימת כללי חומת האש, לוחצים על שם כלל חומת האש בתוצאת הסריקה.

3. לוחצים על edit עריכה.

4. בקטע Source IP ranges (טווחי כתובות ה-IP של המקור), מוחקים את 0.0.0.0/0.

5. מוסיפים כתובות IP ספציפיות או טווחי כתובות IP שרוצים לאפשר להם להתחבר למופע.

6. מוסיפים פרוטוקולים ויציאות ספציפיים שרוצים לפתוח במופע.

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

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

Open Telnet port

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

כללי חומת אש שמאפשרים לכל כתובת IP להתחבר ליציאות Telnet עלולים לחשוף את שירותי Telnet שלכם לתוקפים. מידע נוסף זמין במאמר סקירה כללית על כללים של חומת אש ב-VPC.

יציאות השירות של Telnet הן:

• TCP - 23

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

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

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

   כניסה לדף Firewall

2. ברשימת כללי חומת האש, לוחצים על שם כלל חומת האש בתוצאת הסריקה.

3. לוחצים על edit עריכה.

4. בקטע Source IP ranges (טווחי כתובות ה-IP של המקור), מוחקים את 0.0.0.0/0.

5. מוסיפים כתובות IP ספציפיות או טווחי כתובות IP שרוצים לאפשר להם להתחבר למופע.

6. מוסיפים פרוטוקולים ויציאות ספציפיים שרוצים לפתוח במופע.

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

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

Org policy Confidential VM policy

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

משאב של Compute Engine לא עומד בדרישות של מדיניות הארגון constraints/compute.restrictNonConfidentialComputing. מידע נוסף על האילוץ הזה של מדיניות הארגון זמין במאמר בנושא אכיפת אילוצים של מדיניות הארגון.

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

אם הפעלתם את Security Command Center Premium ברמת הפרויקט, הממצא הזה זמין רק אם מסלול Standard-legacy מופעל בארגון האב.

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

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

   כניסה לדף VM instances

2. ברשימת המקרים, לוחצים על שם המקרה בתוצאת החיפוש.

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

4. אם מכונת ה-VM דורשת מכונת VM חסויה, לוחצים על delete מחיקה.

5. כדי ליצור מכונה וירטואלית חדשה עם Confidential VM מופעל, אפשר לעיין במאמר מדריך למתחילים: יצירת מכונה וירטואלית מסוג Confidential VM.

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

Org policy location restriction

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

האילוץ gcp.resourceLocations של מדיניות הארגון מאפשר להגביל את יצירת המשאבים החדשים לאזורי Cloud שתבחרו. מידע נוסף זמין במאמר בנושא הגבלת מיקומי משאבים.

אם הפעלתם את Security Command Center Premium ברמת הפרויקט, הממצא הזה זמין רק אם מסלול Standard-legacy מופעל בארגון האב.

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

גלאי ORG_POLICY_LOCATION_RESTRICTION מכסה הרבה סוגים של משאבים וההוראות לתיקון שונות לכל משאב. הגישה הכללית לתיקון הפרות שקשורות למיקום כוללת את הפעולות הבאות:

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

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

שיקולים נוספים

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

משאבים מנוהלים

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

משאבים בשימוש

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

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

OS login disabled

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

התכונה OS Login מושבתת במכונות של Compute Engine בפרויקט הזה.

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

אם הפעלתם את Security Command Center Premium ברמת הפרויקט, הממצא הזה זמין רק אם מסלול Standard-legacy מופעל בארגון האב.

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

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

   מעבר אל Metadata

2. לוחצים על עריכה ואז על הוספת פריט.

3. מוסיפים פריט עם המפתח enable-oslogin והערך TRUE.

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

Over privileged account

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

צומת GKE משתמש בצומת שירות ברירת המחדל של Compute Engine, שיש לו גישה רחבה כברירת מחדל, ויכול להיות שיש לו הרשאות יתר להרצת אשכול GKE.

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

פועלים לפי ההוראות לשימוש בחשבונות שירות של Google עם הרשאות מינימליות.

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

Over privileged scopes

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

לחשבון שירות של צומת יש היקפי גישה רחבים.

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

כדי לטפל בבעיה הזו, פועלים לפי ההוראות לשימוש בחשבונות שירות של Google עם הרשאות מינימליות.

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

Over privileged service account user

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

למשתמש יש את התפקידים iam.serviceAccountUser או iam.serviceAccountTokenCreator ברמת הפרויקט, התיקייה או הארגון, ולא ברמת חשבון שירות ספציפי.

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

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

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

   כניסה לדף IAM

2. אם צריך, בוחרים את הפרויקט, התיקייה או הארגון בתוצאת החיפוש.

3. לכל חשבון ראשי שהוקצה לו roles/iam.serviceAccountUser או roles/iam.serviceAccountTokenCreator, מבצעים את הפעולות הבאות:

   1. לוחצים על edit עריכה.
   2. בחלונית Edit permissions, ליד התפקידים, לוחצים על delete Delete.
   3. לוחצים על Save.

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

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

Owner not monitored

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

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

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

העלויות של Cloud Monitoring יכולות להיות משמעותיות, בהתאם לכמות המידע. כדי להבין את השימוש בשירות ואת העלויות שלו, אפשר לעיין במחירון של Google Cloud Observability.

אם הפעלתם את Security Command Center Premium ברמת הפרויקט, הממצא הזה זמין רק אם מסלול Standard-legacy מופעל בארגון האב.

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

יצירת מדד

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

   מעבר אל 'מדדים מבוססי-יומנים'

2. לוחצים על יצירת מדד.

3. בקטע סוג המדד, בוחרים באפשרות מונה.

4. בקטע פרטים:

   1. מגדירים שם של מדד יומן.
   2. מוסיפים תיאור.
   3. מגדירים את Units (יחידות) לערך 1.

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

     (protoPayload.serviceName="cloudresourcemanager.googleapis.com")
     AND (ProjectOwnership OR projectOwnerInvitee)
     OR (protoPayload.serviceData.policyDelta.bindingDeltas.action="REMOVE"
     AND protoPayload.serviceData.policyDelta.bindingDeltas.role="roles/owner")
     OR (protoPayload.serviceData.policyDelta.bindingDeltas.action="ADD"
     AND protoPayload.serviceData.policyDelta.bindingDeltas.role="roles/owner")

6. לוחצים על יצירת מדד. יוצג אישור.

יצירת מדיניות התראות

1. נכנסים לדף Log-based Metrics במסוף Google Cloud :

   כניסה אל מדדים מבוססי-יומנים

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

2. בקטע מדדים שהוגדרו על ידי המשתמש, בוחרים את המדד שיצרתם בקטע הקודם.

3. לוחצים על סמל האפשרויות הנוספות more_vert ואז על יצירת התראה ממדד.

   תיבת הדו-שיח תנאי חדש תיפתח עם אפשרויות המדד והמרת הנתונים שאוכלסו מראש.

4. לוחצים על הבא.
   1. בודקים את ההגדרות שמולאו מראש. אולי תרצו לשנות את ערך הסף.
   2. לוחצים על שם התנאי ומזינים שם לתנאי.
5. לוחצים על הבא.

6. כדי להוסיף התראות למדיניות ההתראות, לוחצים על ערוצי התראות. בתיבת הדו-שיח, בוחרים ערוץ התראות אחד או יותר מהתפריט ולוחצים על אישור.

   כדי לקבל התראה כשאירועים נפתחים ונסגרים, מסמנים את התיבה Notify on incident closure. כברירת מחדל, ההתראות נשלחות רק כשנפתחים אירועים.

7. אופציונלי: מעדכנים את משך הזמן עד לסגירה אוטומטית של אירוע. השדה הזה קובע מתי מערכת Monitoring סוגרת אירועים בהיעדר נתונים של מדדים.
8. אופציונלי: לוחצים על תיעוד, ואז מוסיפים את המידע שרוצים לכלול בהודעת ההתראה.
9. לוחצים על שם ההתראה ומזינים שם למדיניות ההתראה.
10. לוחצים על יצירת מדיניות.

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

Pod security policy disabled

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

האפשרות PodSecurityPolicy מושבתת באשכול GKE.

‫PodSecurityPolicy הוא משאב של בקרת כניסה שמאמת בקשות ליצירה ולעדכון של pods באשכול. אשכולות לא יקבלו פודים שלא עומדים בתנאים שמוגדרים ב-PodSecurityPolicy.

אם הפעלתם את Security Command Center Premium ברמת הפרויקט, הממצא הזה זמין רק אם מסלול Standard-legacy מופעל בארגון האב.

כדי לתקן את הממצא הזה, צריך להגדיר את PodSecurityPolicies ולאשר אותו, ולהפעיל את בקר PodSecurityPolicy. הוראות מפורטות מופיעות במאמר בנושא שימוש ב-PodSecurityPolicies.

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

Primitive roles used

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

למשתמש יש אחד מהתפקידים הבסיסיים הבאים ב-IAM: ‏ roles/owner,‏ roles/editor או roles/viewer. ההרשאות של התפקידים האלה רחבות מדי, ולכן לא מומלץ להשתמש בהם. במקום זאת, צריך להקצות אותם רק לכל פרויקט.

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

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

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

   כניסה למדיניות IAM

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

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

Private cluster disabled

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

באשכול GKE, האפשרות 'אשכול פרטי' מושבתת.

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

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

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

   מעבר אל Kubernetes clusters

2. לוחצים על יצירת אשכול.

3. בתפריט הניווט, בקטע Cluster, בוחרים באפשרות Networking.

4. בוחרים את כפתור הבחירה אשכול פרטי.

5. בקטע Advanced networking options (אפשרויות מתקדמות של רשת), מסמנים את תיבת הסימון Enable VPC-native traffic routing (uses alias IP) (הפעלה של ניתוב תנועה מקורי ב-VPC (שימוש בכתובת IP עם כינוי)).

6. לוחצים על יצירה.

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

Private Google access disabled

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

יש רשתות משנה פרטיות ללא גישה לממשקי Google API ציבוריים.

הגישה הפרטית ל-Google מאפשרת למכונות וירטואליות עם כתובות IP פנימיות (פרטיות) בלבד להגיע לכתובות ה-IP הציבוריות של שירותים וממשקי Google API.

מידע נוסף זמין במאמר בנושא הגדרת גישה פרטית של Google.

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

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

   מעבר לרשתות VPC

2. ברשימת הרשתות, לוחצים על שם הרשת הרצויה.

3. בדף פרטי רשת VPC, לוחצים על הכרטיסייה Subnets.

4. ברשימת רשתות המשנה, לוחצים על שם רשת המשנה שמשויכת לאשכול Kubernetes בממצא.

5. בדף פרטי רשת המשנה, לוחצים על edit עריכה.

6. בקטע גישה פרטית ל-Google, בוחרים באפשרות מופעל.

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

8. כדי להסיר כתובות IP ציבוריות (חיצוניות) ממכונות וירטואליות שתעבורת הנתונים החיצונית היחידה שלהן היא ל-Google APIs, אפשר לעיין במאמר בנושא ביטול ההקצאה של כתובת IP חיצונית סטטית.

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

Public bucket ACL

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

הקטגוריה היא ציבורית וכל אחד באינטרנט יכול לגשת אליה.

סקירה כללית על בקרת גישה

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

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

   כניסה לדף Storage Browser

2. בוחרים את הקטגוריה שמופיעה בתוצאה של Security Health Analytics.

3. בדף Bucket details, לוחצים על הכרטיסייה Permissions.

4. לצד תצוגה לפי, לוחצים על תפקידים.

5. בתיבה Filter, מחפשים את allUsers ואת allAuthenticatedUsers.

6. לוחצים על delete מחיקה כדי להסיר את כל ההרשאות ב-IAM שניתנו ל-allUsers ול-allAuthenticatedUsers.

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

Public Compute image

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

תמונת Compute Engine היא ציבורית וכל אחד באינטרנט יכול לגשת אליה. allUsers מייצג כל אחד באינטרנט ו-allAuthenticatedUsers מייצג כל אחד שאומת באמצעות חשבון Google. אף אחד מהם לא מוגבל למשתמשים בארגון שלכם.

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

מידע נוסף על בקרת גישה

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

1. נכנסים לדף התמונות של Compute Engine במסוףGoogle Cloud .

   מעבר לקובצי אימג' של Compute Engine

2. מסמנים את התיבה לצד התמונה public-image ולוחצים על הצגת חלונית המידע.

3. בתיבה Filter, מחפשים את חשבונות המשתמש allUsers ו-allAuthenticatedUsers.

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

5. כדי להסיר משתמש מתפקיד, לוחצים על delete מחיקה.

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

Public dataset

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

מערך נתונים ב-BigQuery הוא ציבורי וכל אחד באינטרנט יכול לגשת אליו. הגורם הראשי ב-IAM‏ allUsers מייצג כל אחד באינטרנט, והגורם הראשי allAuthenticatedUsers מייצג כל מי שמחובר לשירות של Google. אף אחד מהם לא מוגבל למשתמשים בארגון שלכם.

מידע נוסף מופיע במאמר בנושא שליטה בגישה למערכי נתונים.

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

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

   מעבר למערך נתונים ב-BigQuery

2. ברשימת מערכי הנתונים, לוחצים על שם מערך הנתונים שזוהה בממצא. החלונית Dataset info תיפתח.

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

4. בתפריט הנפתח, לוחצים על הרשאות.

5. בחלונית Dataset Permissions (הרשאות של מערך נתונים), מזינים allUsers ו-allAuthenticatedUsers ומסירים את הגישה לחשבונות הראשיים האלה.

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

Public IP address

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

למכונה של Compute Engine יש כתובת IP ציבורית.

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

מידע נוסף זמין במאמר חיבור מאובטח למופעי מכונות וירטואליות.

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

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

   כניסה לדף VM instances

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

3. לוחצים על edit עריכה.

4. לכל ממשק בקטע Network interfaces, לוחצים על edit Edit ומגדירים את כתובת IP חיצונית לערך None.

5. לוחצים על סיום ואז על שמירה.

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

Public log bucket

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

הממצא הזה לא זמין להפעלות ברמת הפרויקט.

מאגר אחסון הוא ציבורי ומשמש כ-sink ביומן, כלומר כל אחד באינטרנט יכול לגשת ליומנים שמאוחסנים במאגר הזה. allUsers מייצג כל אחד באינטרנט ו-allAuthenticatedUsers מייצג כל מי שמחובר לשירות Google. אף אחד מהם לא מוגבל למשתמשים בארגון שלכם.

סקירה כללית על בקרת גישה

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

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

   כניסה אל Cloud Storage browser

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

3. לוחצים על הכרטיסייה Permissions.

4. מסירים את allUsers ואת allAuthenticatedUsers מרשימת הגורמים המורשים.

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

Public SQL instance

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

המכונה של SQL כוללת את 0.0.0.0/0 כרשת מורשית. המשמעות של המקרה הזה היא שכל לקוח IPv4 יכול לעבור את חומת האש בין רשתות ולנסות להתחבר למופע שלכם, כולל לקוחות שאולי לא התכוונתם לאפשר להם להתחבר. הלקוחות עדיין צריכים פרטי כניסה תקינים כדי להתחבר בהצלחה למופע שלכם.

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

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

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

   כניסה לדף Cloud SQL Instances

2. בוחרים את המופע שמופיע בתוצאה של Security Health Analytics.

3. לוחצים על edit עריכה.

4. בחלונית הניווט, לוחצים על Connections (קישורים).

5. בקטע Authorized networks, מוחקים את 0.0.0.0/0 ומוסיפים כתובות IP ספציפיות או טווחי כתובות IP שרוצים לאפשר להם להתחבר למופע.

6. לוחצים על סיום ואז על שמירה.

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

Pubsub CMEK disabled

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

נושא Pub/Sub לא מוצפן באמצעות מפתחות הצפנה בניהול הלקוח (CMEK).

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

כדי לתקן את הממצא הזה, צריך למחוק את הנושא הקיים וליצור נושא חדש:

1. נכנסים לדף Topics של Pub/Sub במסוף Google Cloud .

   לדף Topics

2. אם צריך, בוחרים את הפרויקט שמכיל את נושא ה-Pub/Sub.

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

4. כדי ליצור נושא חדש ב-Pub/Sub עם CMEK מופעל, אפשר לעיין במאמר שימוש במפתחות הצפנה בניהול הלקוח. השימוש ב-CMEK כרוך בעלויות נוספות שקשורות ל-Cloud KMS.

5. פרסום ממצאים או נתונים אחרים בנושא Pub/Sub עם הפעלת CMEK.

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

Route not monitored

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

מדדים והתראות ביומן לא מוגדרים למעקב אחרי שינויים בנתיב של רשת VPC.

‫Google Cloud routes הם יעדים ודילוגים שמגדירים את הנתיב שבו תנועת הרשת עוברת ממופע של מכונה וירטואלית לכתובת IP של יעד. מעקב אחרי שינויים בטבלאות ניתוב יכול לעזור לכם לוודא שכל התנועה ב-VPC עוברת בנתיב הצפוי.

מידע נוסף מופיע במאמר סקירה כללית של מדדים שמבוססים על יומנים.

העלויות של Cloud Monitoring יכולות להיות משמעותיות, בהתאם לכמות המידע. כדי להבין את השימוש בשירות ואת העלויות שלו, אפשר לעיין במחירון של Google Cloud Observability.

אם הפעלתם את Security Command Center Premium ברמת הפרויקט, הממצא הזה זמין רק אם מסלול Standard-legacy מופעל בארגון האב.

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

יצירת מדד

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

   מעבר אל 'מדדים מבוססי-יומנים'

2. לוחצים על יצירת מדד.

3. בקטע סוג המדד, בוחרים באפשרות מונה.

4. בקטע פרטים:

   1. מגדירים שם של מדד יומן.
   2. מוסיפים תיאור.
   3. מגדירים את Units (יחידות) לערך 1.

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

     resource.type="gce_route"
     AND (protoPayload.methodName:"compute.routes.delete"
     OR protoPayload.methodName:"compute.routes.insert")

6. לוחצים על יצירת מדד. יוצג אישור.

יצירת מדיניות התראות

1. נכנסים לדף Log-based Metrics במסוף Google Cloud :

   כניסה אל מדדים מבוססי-יומנים

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

2. בקטע מדדים שהוגדרו על ידי המשתמש, בוחרים את המדד שיצרתם בקטע הקודם.

3. לוחצים על סמל האפשרויות הנוספות more_vert ואז על יצירת התראה ממדד.

   תיבת הדו-שיח תנאי חדש תיפתח עם אפשרויות המדד והמרת הנתונים שאוכלסו מראש.

4. לוחצים על הבא.
   1. בודקים את ההגדרות שמולאו מראש. אולי תרצו לשנות את ערך הסף.
   2. לוחצים על שם התנאי ומזינים שם לתנאי.
5. לוחצים על הבא.

6. כדי להוסיף התראות למדיניות ההתראות, לוחצים על ערוצי התראות. בתיבת הדו-שיח, בוחרים ערוץ התראות אחד או יותר מהתפריט ולוחצים על אישור.

   כדי לקבל התראה כשאירועים נפתחים ונסגרים, מסמנים את התיבה Notify on incident closure. כברירת מחדל, ההתראות נשלחות רק כשנפתחים אירועים.

7. אופציונלי: מעדכנים את משך הזמן עד לסגירה אוטומטית של אירוע. השדה הזה קובע מתי מערכת Monitoring סוגרת אירועים בהיעדר נתונים של מדדים.
8. אופציונלי: לוחצים על תיעוד, ואז מוסיפים את המידע שרוצים לכלול בהודעת ההתראה.
9. לוחצים על שם ההתראה ומזינים שם למדיניות ההתראה.
10. לוחצים על יצירת מדיניות.

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

Redis role used on org

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

הממצא הזה לא זמין להפעלות ברמת הפרויקט.

תפקיד IAM של Redis מוקצה ברמת הארגון או התיקייה.

צריך להקצות את תפקידי ה-IAM הבאים של Redis רק ברמת הפרויקט, ולא ברמת הארגון או התיקייה:

• roles/redis.admin
• roles/redis.viewer
• roles/redis.editor

מידע נוסף זמין במאמר בקרת גישה והרשאות.

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

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

   כניסה למדיניות IAM

2. מסירים את תפקידי ה-IAM של Redis שמצוינים בממצא ומוסיפים אותם בפרויקטים הספציפיים במקום זאת.

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

Release channel disabled

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

אף אשכול GKE לא רשום לערוץ הפצה.

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

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

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

   מעבר אל Kubernetes clusters

2. בקטע Cluster basics (הגדרות בסיסיות של אשכול), לוחצים על edit Upgrade cluster master version (שדרוג הגרסה הראשית של האשכול) בשורה Release channel (ערוץ הפצה).

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

3. בתיבת הדו-שיח, בוחרים באפשרות ערוץ הפצה, ואז בוחרים את ערוץ ההפצה שאליו רוצים להירשם.

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

4. לוחצים על שמירת השינויים.

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

RSASHA1 for signing

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

‫RSASHA1 משמש לחתימת מפתחות באזורי Cloud DNS. האלגוריתם שמשמש לחתימת המפתח לא יכול להיות חלש.

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

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

Service account key not rotated

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

הממצא הזה לא זמין להפעלות ברמת הפרויקט.

לא בוצע רוטציה של מפתח לחשבון שירות בניהול משתמש במשך יותר מ-90 ימים.

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

אם יצרתם בעצמכם את זוג המפתחות הציבוריים/הפרטיים, אחסנתם את המפתח הפרטי במודול אבטחת חומרה (HSM) והעליתם את המפתח הציבורי ל-Google, יכול להיות שלא תצטרכו לבצע רוטציה של המפתח כל 90 יום. במקום זאת, אפשר לבצע רוטציה למפתח אם חושדים שהוא נפרץ.

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

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

   לדף Service accounts

2. אם צריך, בוחרים את הפרויקט שמצוין בתוצאת החיפוש.

3. ברשימת חשבונות השירות, מחפשים את חשבון השירות שמופיע בתוצאה.

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

5. כדי להשבית את המפתח, פועלים לפי ההוראות במאמר השבתת מפתח לחשבון שירות.

6. אופציונלי: אחרי שמוודאים שהמפתח כבר לא בשימוש, מוחקים את המפתח של חשבון השירות.

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

Service account role separation

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

הממצא הזה לא זמין להפעלות ברמת הפרויקט.

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

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

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

   כניסה לדף IAM

2. לכל חשבון ראשי שמופיע בממצא, מבצעים את הפעולות הבאות:

   1. כדי לבדוק אם התפקיד הועבר בירושה מתיקייה או ממשאב ארגוני, מסתכלים בעמודה העברה בירושה. אם העמודה מכילה קישור למשאב אב, לוחצים על הקישור כדי לעבור לדף IAM של משאב האב.
   2. לוחצים על edit עריכה לצד העיקרון.
   3. כדי להסיר הרשאות, לוחצים על delete מחיקה לצד אדמין של חשבון שירות. אם רוצים להסיר את כל ההרשאות של חשבון השירות, לוחצים על מחיקה לצד כל ההרשאות האחרות.

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

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

Shielded VM disabled

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

התכונה 'מכונה וירטואלית מוגנת' מושבתת במכונה הזו ב-Compute Engine.

מכונות וירטואליות מוגנות הן מכונות וירטואליות ב- Google Cloud שעברו חיזוק באמצעות קבוצה של אמצעי אבטחה שעוזרים להגן מפני ערכות rootkit ו-bootkit. מכונות וירטואליות מוגנות עוזרות לוודא שמנהל האתחול והקושחה חתומים ומאומתים. מידע נוסף על מכונה וירטואלית מוגנת

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

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

   כניסה לדף VM instances

2. בוחרים את המופע שקשור לממצא של Security Health Analytics.

3. בדף Instance details (פרטי המכונה) שנטען, לוחצים על stop Stop (עצירה).

4. אחרי שהמופע מפסיק, לוחצים על edit עריכה.

5. בקטע מכונה וירטואלית מוגנת, מעבירים את המתגים Turn on vTPM ו-Turn on Integrity Monitoring למצב מופעל כדי להפעיל את מכונה וירטואלית מוגנת.

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

7. לוחצים על Save. ההגדרה החדשה מופיעה בדף Instance details.

8. לוחצים על play_arrow Start (התחלה) כדי להפעיל את המכונה.

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

SQL CMEK disabled

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

מופע של מסד נתונים מסוג SQL לא משתמש במפתחות הצפנה בניהול הלקוח (CMEK).

בעזרת CMEK, המפתחות שאתם יוצרים ומנהלים ב-Cloud KMS עוטפים את המפתחות שבהם Google משתמשת כדי להצפין את הנתונים שלכם, וכך אתם מקבלים יותר שליטה על הגישה לנתונים. מידע נוסף זמין במאמרי הסקירה הכללית של CMEK למוצר שלכם: Cloud SQL ל-MySQL, Cloud SQL ל-PostgreSQL או Cloud SQL ל-SQL Server. השימוש ב-CMEK כרוך בעלויות נוספות שקשורות ל-Cloud KMS.

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

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

   כניסה לדף Cloud SQL Instances

2. בוחרים את המופע שמופיע בתוצאה של Security Health Analytics.

3. לוחצים על delete מחיקה.

4. כדי ליצור מכונה חדשה עם CMEK מופעל, פועלים לפי ההוראות להגדרת CMEK למוצר:

   1. ‫Cloud SQL ל-MySQL
   2. Cloud SQL ל-PostgreSQL
   3. ‫Cloud SQL ל-SQL Server

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

SQL contained database authentication

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

במופע של מסד נתונים ב-Cloud SQL ל-SQL Server, הדגל של מסד הנתונים contained database authentication לא מוגדר לערך Off.

הדגל contained database authentication קובע אם אפשר ליצור או לצרף מסדי נתונים עצמאיים למנוע מסד הנתונים. מסד נתונים מוכלל כולל את כל ההגדרות ומטא-הנתונים שנדרשים להגדרת מסד הנתונים, ואין לו תלות בהגדרות של מופע מנוע מסד הנתונים שבו מסד הנתונים מותקן.

לא מומלץ להפעיל את הדגל הזה מהסיבות הבאות:

• המשתמשים יכולים להתחבר למסד הנתונים בלי אימות ברמת מנוע מסד הנתונים.
• בידוד מסד הנתונים ממנוע מסד הנתונים מאפשר להעביר את מסד הנתונים למופע אחר של SQL Server.

מסדי נתונים עצמאיים חשופים לאיומים ייחודיים שצריך להבין ולצמצם אותם על ידי מנהלי מנוע מסד הנתונים של SQL Server. רוב האיומים נובעים מתהליך האימות USER WITH PASSWORD, שמעביר את גבולות האימות מרמת מנוע מסד הנתונים לרמת מסד הנתונים.

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

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

   כניסה לדף Cloud SQL Instances

2. בוחרים את המופע שמופיע בתוצאה של Security Health Analytics.

3. לוחצים על edit עריכה.

4. בקטע Database flags (דגלים של מסד הנתונים), מגדירים את דגל מסד הנתונים contained database authentication (אימות של מסד נתונים מוכל) עם הערך Off (מושבת).

5. לוחצים על Save. ההגדרה החדשה מופיעה בדף Instance overview.

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

SQL cross DB ownership chaining

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

בדוגמה הזו, בדגל מסד הנתונים cross db ownership chaining של מופע מסד הנתונים של Cloud SQL ל-SQL Server מוגדר הערך Off.

הדגל cross db ownership chaining מאפשר לכם לשלוט בשרשור בעלות בין מסדי נתונים ברמת מסד הנתונים, או לאפשר שרשור בעלות בין מסדי נתונים לכל ההצהרות של מסד הנתונים.

לא מומלץ להפעיל את הדגל הזה אלא אם כל מסדי הנתונים שמארח מופע SQL Server משתתפים בשרשור בעלות בין מסדי נתונים, ואתם מודעים להשלכות האבטחה של ההגדרה הזו.

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

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

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

   כניסה לדף Cloud SQL Instances

2. בוחרים את המופע שמופיע בתוצאה של Security Health Analytics.

3. לוחצים על edit עריכה.

4. בקטע Database flags (דגלים של מסד הנתונים), מגדירים את דגל מסד הנתונים cross db ownership chaining (שרשור של בעלות על מסד נתונים) עם הערך Off (מושבת).

5. לוחצים על Save. ההגדרה החדשה מופיעה בדף Instance overview.

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

SQL external scripts enabled

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

במופע של מסד נתונים ב-Cloud SQL ל-SQL Server, הדגל של מסד הנתונים external scripts enabled מוגדר לערך Off.

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

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

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

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

   כניסה לדף Cloud SQL Instances

2. בוחרים את המופע שמופיע בתוצאה של Security Health Analytics.

3. לוחצים על edit עריכה.

4. בקטע Database flags (דגלים של מסד הנתונים), מגדירים את הדגל של מסד הנתונים external scripts enabled (הפעלת סקריפטים חיצוניים) עם הערך Off (מושבת).

5. לוחצים על Save. ההגדרה החדשה מופיעה בדף Instance overview.

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

SQL instance not monitored

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

הממצא הזה לא זמין להפעלות ברמת הפרויקט.

מדדים והתראות ביומן לא מוגדרים למעקב אחרי שינויים בהגדרות של מופע Cloud SQL.

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

מידע נוסף מופיע במאמר סקירה כללית של מדדים שמבוססים על יומנים.

העלויות של Cloud Monitoring יכולות להיות משמעותיות, בהתאם לכמות המידע. כדי להבין את השימוש בשירות ואת העלויות שלו, אפשר לעיין במחירון של Google Cloud Observability.

אם הפעלתם את Security Command Center Premium ברמת הפרויקט, הממצא הזה זמין רק אם מסלול Standard-legacy מופעל בארגון האב.

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

יצירת מדד

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

   מעבר אל 'מדדים מבוססי-יומנים'

2. לוחצים על יצירת מדד.

3. בקטע סוג המדד, בוחרים באפשרות מונה.

4. בקטע פרטים:

   1. מגדירים שם של מדד יומן.
   2. מוסיפים תיאור.
   3. מגדירים את Units (יחידות) לערך 1.

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

     protoPayload.methodName="cloudsql.instances.update"
     OR protoPayload.methodName="cloudsql.instances.create"
     OR protoPayload.methodName="cloudsql.instances.delete"

6. לוחצים על יצירת מדד. יוצג אישור.

יצירת מדיניות התראות

1. נכנסים לדף Log-based Metrics במסוף Google Cloud :

   כניסה אל מדדים מבוססי-יומנים

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

2. בקטע מדדים שהוגדרו על ידי המשתמש, בוחרים את המדד שיצרתם בקטע הקודם.

3. לוחצים על סמל האפשרויות הנוספות more_vert ואז על יצירת התראה ממדד.

   תיבת הדו-שיח תנאי חדש תיפתח עם אפשרויות המדד והמרת הנתונים שאוכלסו מראש.

4. לוחצים על הבא.
   1. בודקים את ההגדרות שמולאו מראש. אולי תרצו לשנות את ערך הסף.
   2. לוחצים על שם התנאי ומזינים שם לתנאי.
5. לוחצים על הבא.

6. כדי להוסיף התראות למדיניות ההתראות, לוחצים על ערוצי התראות. בתיבת הדו-שיח, בוחרים ערוץ התראות אחד או יותר מהתפריט ולוחצים על אישור.

   כדי לקבל התראה כשאירועים נפתחים ונסגרים, מסמנים את התיבה Notify on incident closure. כברירת מחדל, ההתראות נשלחות רק כשנפתחים אירועים.

7. אופציונלי: מעדכנים את משך הזמן עד לסגירה אוטומטית של אירוע. השדה הזה קובע מתי מערכת Monitoring סוגרת אירועים בהיעדר נתונים של מדדים.
8. אופציונלי: לוחצים על תיעוד, ואז מוסיפים את המידע שרוצים לכלול בהודעת ההתראה.
9. לוחצים על שם ההתראה ומזינים שם למדיניות ההתראה.
10. לוחצים על יצירת מדיניות.

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

SQL local infile

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

במופע של מסד נתונים ב-Cloud SQL ל-MySQL, הדגל local_infile של מסד הנתונים לא מוגדר לערך Off. בגלל בעיות אבטחה שקשורות לדגל local_infile, צריך להשבית אותו. מידע נוסף זמין במאמר בנושא הגדרת דגלים של מסד נתונים.

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

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

   כניסה לדף Cloud SQL Instances

2. בוחרים את המופע שמופיע בתוצאה של Security Health Analytics.

3. לוחצים על edit עריכה.

4. בקטע Database flags (דגלים של מסד הנתונים), מגדירים את הדגל local_infile של מסד הנתונים עם הערך Off (מושבת).

5. לוחצים על Save. ההגדרה החדשה מופיעה בדף Instance overview.

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

SQL log checkpoints disabled

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

במכונת מסד נתונים של Cloud SQL ל-PostgreSQL, האפשרות log_checkpoints לא מוגדרת כ-On.

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

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

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

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

   כניסה לדף Cloud SQL Instances

2. בוחרים את המופע שמופיע בתוצאה של Security Health Analytics.

3. לוחצים על edit עריכה.

4. בקטע Database flags [דגלים של מסד הנתונים], מגדירים את הדגל log_checkpoints של מסד הנתונים עם הערך On [מופעל].

5. לוחצים על Save. ההגדרה החדשה מופיעה בדף Instance overview.

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

SQL log connections disabled

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

במכונת מסד נתונים של Cloud SQL ל-PostgreSQL, האפשרות log_connections לא מוגדרת כ-On.

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

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

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

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

   כניסה לדף Cloud SQL Instances

2. בוחרים את המופע שמופיע בתוצאה של Security Health Analytics.

3. לוחצים על edit עריכה.

4. בקטע Database flags (דגלים של מסד הנתונים), מגדירים את הדגל log_connections של מסד הנתונים עם הערך On (מופעל).

5. לוחצים על Save. ההגדרה החדשה מופיעה בדף Instance overview.

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

SQL log disconnections disabled

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

במכונת מסד נתונים של Cloud SQL ל-PostgreSQL, האפשרות log_disconnections לא מוגדרת כ-On.

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

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

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

   כניסה לדף Cloud SQL Instances

2. בוחרים את המופע שמופיע בתוצאה של Security Health Analytics.

3. לוחצים על edit עריכה.

4. בקטע Database flags (דגלים של מסד הנתונים), מגדירים את דגל מסד הנתונים log_disconnections עם הערך On (מופעל).

5. לוחצים על Save. ההגדרה החדשה מופיעה בדף Instance overview.

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

SQL log duration disabled

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

במכונת מסד נתונים ב-Cloud SQL ל-PostgreSQL, האפשרות log_duration לא מוגדרת כ-On.

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

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

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

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

   כניסה לדף Cloud SQL Instances

2. בוחרים את המופע שמופיע בתוצאה של Security Health Analytics.

3. לוחצים על edit עריכה.

4. בקטע Database flags (דגלים של מסד הנתונים), מגדירים את הדגל log_duration של מסד הנתונים למצב On (מופעל).

5. לוחצים על Save. ההגדרה החדשה מופיעה בדף Instance overview.

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

SQL log error verbosity

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

במופע מסד נתונים של Cloud SQL ל-PostgreSQL, האפשרות log_error_verbosity לא מוגדרת כ-default או כ-verbose.

הדגל log_error_verbosity קובע את רמת הפירוט בהודעות שמתועדות ביומן. ככל שהפירוט גבוה יותר, כך יותר פרטים נרשמים בהודעות. מומלץ להגדיר את הדגל הזה לערך default או verbose.

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

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

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

   כניסה לדף Cloud SQL Instances

2. בוחרים את המופע שמופיע בתוצאה של Security Health Analytics.

3. לוחצים על edit עריכה.

4. בקטע Database flags (דגלים של מסד הנתונים), מגדירים את הדגל log_error_verbosity של מסד הנתונים לערך default (ברירת מחדל) או verbose (מפורט).

5. לוחצים על Save. ההגדרה החדשה מופיעה בדף Instance overview.

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

SQL log lock waits disabled

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

במכונת מסד נתונים של Cloud SQL ל-PostgreSQL, האפשרות log_lock_waits לא מוגדרת כ-On.

הפעלת ההגדרה log_lock_waits יוצרת רשומות ביומן כשההמתנה של הסשן להשגת נעילה נמשכת יותר מהזמן של deadlock_timeout. היומנים עוזרים לקבוע אם ההמתנה לנעילה גורמת לביצועים ירודים.

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

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

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

   כניסה לדף Cloud SQL Instances

2. בוחרים את המופע שמופיע בתוצאה של Security Health Analytics.

3. לוחצים על edit עריכה.

4. בקטע Database flags (דגלים של מסד הנתונים), מגדירים את הדגל log_lock_waits של מסד הנתונים עם הערך On (מופעל).

5. לוחצים על Save. ההגדרה החדשה מופיעה בדף Instance overview.

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

SQL log min duration statement enabled

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

הערך של הדגל log_min_duration_statement במסד הנתונים של Cloud SQL ל-PostgreSQL לא מוגדר ל-‎-1.

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

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

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

   כניסה לדף Cloud SQL Instances

2. בוחרים את המופע שמופיע בתוצאה של Security Health Analytics.

3. לוחצים על edit עריכה.

4. בקטע Database flags (דגלים של מסד הנתונים), מגדירים את הדגל log_min_duration_statement של מסד הנתונים עם הערך ‎-1.

5. לוחצים על Save. ההגדרה החדשה מופיעה בדף Instance overview.

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

SQL log min error statement

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

לא הוגדר כראוי בדגל מסד הנתונים log_min_error_statement במכונת מסד נתונים של Cloud SQL ל-PostgreSQL.

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

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

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

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

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

   כניסה לדף Cloud SQL Instances

2. בוחרים את המופע שמופיע בתוצאה של Security Health Analytics.

3. לוחצים על edit עריכה.

4. בקטע Database flags (דגלים של מסד הנתונים), מגדירים את הדגל log_min_error_statement של מסד הנתונים עם אחד מהערכים המומלצים הבאים, בהתאם למדיניות הרישום ביומן של הארגון.

   • debug5
   • debug4
   • debug3
   • debug2
   • debug1
   • info
   • notice
   • warning
   • error

5. לוחצים על Save. ההגדרה החדשה מופיעה בדף Instance overview.

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

SQL log min error statement severity

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

לא הוגדר כראוי בדגל מסד הנתונים log_min_error_statement במכונת מסד נתונים של Cloud SQL ל-PostgreSQL.

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

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

מומלץ להגדיר את הדגל הזה לערך error או לערך מחמיר יותר.

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

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

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

   כניסה לדף Cloud SQL Instances

2. בוחרים את המופע שמופיע בתוצאה של Security Health Analytics.

3. לוחצים על edit עריכה.

4. בקטע Database flags (דגלים של מסד הנתונים), מגדירים את הדגל log_min_error_statement של מסד הנתונים עם אחד מהערכים המומלצים הבאים, בהתאם למדיניות הרישום ביומן של הארגון.

   • error
   • log
   • fatal
   • panic

5. לוחצים על Save. ההגדרה החדשה מופיעה בדף Instance overview.

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

SQL log min messages

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

במופע של מסד נתונים ב-Cloud SQL ל-PostgreSQL, האפשרות log_min_messages לא מוגדרת לפחות לערך warning.

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

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

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

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

   כניסה לדף Cloud SQL Instances

2. בוחרים את המופע שמופיע בתוצאה של Security Health Analytics.

3. לוחצים על edit עריכה.

4. בקטע Database flags, מגדירים את דגל מסד הנתונים log_min_messages עם אחד מהערכים המומלצים הבאים, בהתאם למדיניות הרישום ביומן של הארגון.

   • debug5
   • debug4
   • debug3
   • debug2
   • debug1
   • info
   • notice
   • warning

5. לוחצים על Save. ההגדרה החדשה מופיעה בדף Instance overview.

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

SQL log executor stats enabled

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

במופע של מסד נתונים ב-Cloud SQL ל-PostgreSQL, הדגל log_executor_stats לא מוגדר לערך Off.

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

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

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

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

   כניסה לדף Cloud SQL Instances

2. בוחרים את המופע שמופיע בתוצאה של Security Health Analytics.

3. לוחצים על edit עריכה.

4. בקטע Database flags (דגלים של מסד הנתונים), מגדירים את הדגל log_executor_stats של מסד הנתונים למצב Off (מושבת).

5. לוחצים על Save. ההגדרה החדשה מופיעה בדף Instance overview.

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

SQL log hostname enabled

שם הקטגוריה ב-API: ‏ `SQL_LOG_HOSTNAME_ENABLED

במופע של מסד נתונים ב-Cloud SQL ל-PostgreSQL, הדגל log_hostname של מסד הנתונים לא מוגדר לערך Off.

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

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

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

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

   כניסה לדף Cloud SQL Instances

2. בוחרים את המופע שמופיע בתוצאה של Security Health Analytics.

3. לוחצים על edit עריכה.

4. בקטע Database flags (דגלים של מסד הנתונים), מגדירים את הדגל log_hostname של מסד הנתונים למצב Off (מושבת).

5. לוחצים על Save. ההגדרה החדשה מופיעה בדף Instance overview.

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

SQL log parser stats enabled

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

במופע של מסד נתונים ב-Cloud SQL ל-PostgreSQL, האפשרות log_parser_stats לא מוגדרת כOff.

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

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

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

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

   כניסה לדף Cloud SQL Instances

2. בוחרים את המופע שמופיע בתוצאה של Security Health Analytics.

3. לוחצים על edit עריכה.

4. בקטע Database flags (דגלים של מסד הנתונים), מגדירים את הדגל log_parser_stats של מסד הנתונים למצב Off (מושבת).

5. לוחצים על Save. ההגדרה החדשה מופיעה בדף Instance overview.

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

SQL log planner stats enabled

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

במופע של מסד נתונים ב-Cloud SQL ל-PostgreSQL, הדגל log_planner_stats של מסד הנתונים לא מוגדר לערך Off.

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

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

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

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

   כניסה לדף Cloud SQL Instances

2. בוחרים את המופע שמופיע בתוצאה של Security Health Analytics.

3. לוחצים על edit עריכה.

4. בקטע Database flags (דגלים של מסד הנתונים), מגדירים את הדגל log_planner_stats של מסד הנתונים למצב Off (מושבת).

5. לוחצים על Save. ההגדרה החדשה מופיעה בדף Instance overview.

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

SQL log statement

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

במופע מסד נתונים של Cloud SQL ל-PostgreSQL, הדגל log_statement לא מוגדר לערך ddl.

הערך של הדגל הזה קובע אילו הצהרות SQL נרשמות ביומן. רישום ביומן עוזר לפתור בעיות תפעוליות ומאפשר ניתוח פורנזי. אם הדגל הזה לא מוגדר לערך הנכון, יכול להיות שמידע רלוונטי ידלג או יוסתר ביותר מדי הודעות. מומלץ להשתמש בערך ddl (כל ההצהרות להגדרת נתונים), אלא אם מדיניות הרישום ביומן של הארגון שלכם קובעת אחרת.

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

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

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

   כניסה לדף Cloud SQL Instances

2. בוחרים את המופע שמופיע בתוצאה של Security Health Analytics.

3. לוחצים על edit עריכה.

4. בקטע Database flags, מגדירים את דגל מסד הנתונים log_statement לערך ddl.

5. לוחצים על Save. ההגדרה החדשה מופיעה בדף Instance overview.

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

SQL log statement stats enabled

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

במופע של מסד נתונים ב-Cloud SQL ל-PostgreSQL, הדגל log_statement_stats לא מוגדר לערך Off.

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

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

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

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

   כניסה לדף Cloud SQL Instances

2. בוחרים את המופע שמופיע בתוצאה של Security Health Analytics.

3. לוחצים על edit עריכה.

4. בקטע Database flags (דגלים של מסד הנתונים), מגדירים את הדגל log_statement_stats של מסד הנתונים למצב Off (מושבת).

5. לוחצים על Save. ההגדרה החדשה מופיעה בדף Instance overview.

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

SQL log temp files

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

במכונת מסד נתונים של Cloud SQL ל-PostgreSQL, הדגל log_temp_files של מסד הנתונים לא מוגדר לערך 0.

אפשר ליצור קבצים זמניים למיון, לגיבוב ולתוצאות זמניות של שאילתות. הגדרת הדגל log_temp_files לערך 0 גורמת לרישום ביומן של כל המידע על הקבצים הזמניים. רישום ביומן של כל הקבצים הזמניים שימושי לזיהוי בעיות פוטנציאליות בביצועים. מידע נוסף זמין במאמר הגדרת דגלים של מסד נתונים.

כדי לפתור את הבעיה, מבצעים את השלבים הבאים:

1. נכנסים לדף Cloud SQL Instances במסוף Google Cloud .

   כניסה לדף Cloud SQL Instances

2. בוחרים את המופע שמופיע בתוצאה של Security Health Analytics.

3. לוחצים על edit עריכה.

4. בקטע Database flags (דגלים של מסד הנתונים), מגדירים את הדגל log_temp_files של מסד הנתונים עם הערך 0.

5. לוחצים על Save. ההגדרה החדשה מופיעה בדף Instance overview.

read_more מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה.

SQL no root password

שם הקטגוריה ב-API: SQL_NO_ROOT_PASSWORD

לא מוגדרת סיסמה לחשבון הבסיס במופע של מסד נתונים של MySQL. מומלץ להוסיף סיסמה למופע של מסד הנתונים MySQL. מידע נוסף זמין במאמר בנושא משתמשי MySQL.

כדי לפתור את הבעיה, מבצעים את השלבים הבאים:

1. נכנסים לדף Cloud SQL Instances במסוףGoogle Cloud .

   כניסה לדף Cloud SQL Instances

2. בוחרים את המופע שמופיע בתוצאה של Security Health Analytics.

3. בדף Instance details שנטען, בוחרים בכרטיסייה Users.

4. לצד המשתמש root, לוחצים על סמל האפשרויות הנוספות , ואז בוחרים באפשרות שינוי סיסמה.

5. מזינים סיסמה חדשה וחזקה ולוחצים על אישור.

read_more מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה.

SQL public IP

שם הקטגוריה ב-API: SQL_PUBLIC_IP

למסד נתונים ב-Cloud SQL יש כתובת IP ציבורית.

כדי לצמצם את שטח הפנים של הארגון להתקפות, למסדי נתונים של Cloud SQL לא צריכות להיות כתובות IP ציבוריות. כתובות IP פרטיות מספקות אבטחת רשת משופרת וזמן אחזור נמוך יותר לאפליקציה.

כדי לפתור את הבעיה, מבצעים את השלבים הבאים:

1. נכנסים לדף Cloud SQL Instances במסוף Google Cloud .

   כניסה לדף Cloud SQL Instances

2. בוחרים את המופע שמופיע בתוצאה של Security Health Analytics.

3. בתפריט הצד שמימין, לוחצים על Connections (חיבורים).

4. לוחצים על הכרטיסייה Networking (רשת) ומבטלים את הסימון של התיבה Public IP (כתובת IP ציבורית).

5. אם המכונה לא מוגדרת כבר לשימוש בכתובת IP פרטית, אפשר לעיין במאמר בנושא הגדרת כתובת IP פרטית למכונה קיימת.

6. לוחצים על Save.

read_more מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה.

SQL remote access enabled

שם הקטגוריה ב-API: SQL_REMOTE_ACCESS_ENABLED

במופע של מסד נתונים ב-Cloud SQL ל-SQL Server, הדגל של מסד הנתונים remote access מוגדר לערך Off.

כשההגדרה הזו מופעלת, היא מעניקה הרשאה להפעיל פרוצדורות מאוחסנות מקומיות משרתים מרוחקים או פרוצדורות מאוחסנות מרוחקות מהשרת המקומי. גורמים זדוניים יכולים לנצל לרעה את הפונקציונליות הזו כדי להפעיל התקפת מניעת שירות (DoS) על שרתים מרוחקים, על ידי העברת עיבוד השאילתות ליעד. כדי למנוע שימוש לרעה, מומלץ להשבית את ההגדרה הזו.

מידע נוסף זמין במאמר בנושא הגדרת דגלים של מסד נתונים.

כדי לפתור את הבעיה, מבצעים את השלבים הבאים:

1. נכנסים לדף Cloud SQL Instances במסוףGoogle Cloud .

   כניסה לדף Cloud SQL Instances

2. בוחרים את המופע שמופיע בתוצאה של Security Health Analytics.

3. לוחצים על edit עריכה.

4. בקטע Flags (דגלים), מגדירים את remote access (גישה מרחוק) לOff (מושבת).

5. לוחצים על Save. ההגדרה החדשה מופיעה בדף Instance overview.

read_more מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה.

SQL skip show database disabled

שם הקטגוריה ב-API: SQL_SKIP_SHOW_DATABASE_DISABLED

במכונת מסד נתונים של Cloud SQL ל-MySQL, הדגל skip_show_database של מסד הנתונים לא מוגדר לערך On.

כשהדגל הזה מופעל, משתמשים לא יכולים להשתמש בהצהרה SHOW DATABASES אם אין להם את ההרשאה SHOW DATABASES. אם בוחרים בהגדרה הזו, משתמשים שלא קיבלו הרשאה מפורשת לא יכולים לראות מסדי נתונים ששייכים למשתמשים אחרים. מומלץ להפעיל את הדגל הזה.

מידע נוסף זמין במאמר בנושא הגדרת דגלים של מסד נתונים.

כדי לפתור את הבעיה, מבצעים את השלבים הבאים:

1. נכנסים לדף Cloud SQL Instances במסוףGoogle Cloud .

   כניסה לדף Cloud SQL Instances

2. בוחרים את המופע שמופיע בתוצאה של Security Health Analytics.

3. לוחצים על edit עריכה.

4. בקטע Flags, מגדירים את האפשרות skip_show_database למצב On.

5. לוחצים על Save. ההגדרה החדשה מופיעה בדף Instance overview.

read_more מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה.

SQL trace flag 3625

שם הקטגוריה ב-API: SQL_TRACE_FLAG_3625

במופע של מסד נתונים ב-Cloud SQL ל-SQL Server, האפשרות 3625 (trace flag) לא מוגדרת כOn.

הדגל הזה מגביל את כמות המידע שמוחזר למשתמשים שלא חברים בתפקיד השרת הקבוע sysadmin, על ידי מיסוך הפרמטרים של חלק מהודעות השגיאה באמצעות כוכביות (******). כדי למנוע חשיפה של מידע רגיש, מומלץ להפעיל את הדגל הזה.

מידע נוסף זמין במאמר בנושא הגדרת דגלים של מסד נתונים.

כדי לפתור את הבעיה, מבצעים את השלבים הבאים:

1. נכנסים לדף Cloud SQL Instances במסוףGoogle Cloud .

   כניסה לדף Cloud SQL Instances

2. בוחרים את המופע שמופיע בתוצאה של Security Health Analytics.

3. לוחצים על edit עריכה.

4. בקטע Database flags, מגדירים את 3625 למצב On.

5. לוחצים על Save. ההגדרה החדשה מופיעה בדף Instance overview.

read_more מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה.

SQL user connections configured

שם הקטגוריה ב-API: SQL_USER_CONNECTIONS_CONFIGURED

במופע של מסד נתונים ב-Cloud SQL ל-SQL Server מוגדר הדגל user connections של מסד הנתונים.

האפשרות user connections מציינת את המספר המקסימלי של חיבורי משתמשים בו-זמנית שמותרים במופע של SQL Server. מכיוון שמדובר באפשרות דינמית (הגדרה עצמית), שרת SQL מתאים את המספר המקסימלי של חיבורי משתמשים באופן אוטומטי לפי הצורך, עד הערך המקסימלי המותר. ערך ברירת המחדל הוא 0, כלומר מותרים עד 32,767 חיבורים של משתמשים. לכן, אנחנו לא ממליצים להגדיר את דגל מסד הנתונים user connections.

מידע נוסף זמין במאמר בנושא הגדרת דגלים של מסד נתונים.

כדי לפתור את הבעיה, מבצעים את השלבים הבאים:

1. נכנסים לדף Cloud SQL Instances במסוףGoogle Cloud .

   כניסה לדף Cloud SQL Instances

2. בוחרים את המופע שמופיע בתוצאה של Security Health Analytics.

3. לוחצים על edit עריכה.

4. בקטע Database flags (דגלים של מסד הנתונים), לצד user connections (חיבורי משתמשים), לוחצים על delete Delete (מחיקה).

5. לוחצים על Save. ההגדרה החדשה מופיעה בדף Instance overview.

read_more מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה.

SQL user options configured

שם הקטגוריה ב-API: SQL_USER_OPTIONS_CONFIGURED

מוגדר דגל מסד הנתונים user options במכונת מסד נתונים של Cloud SQL ל-SQL Server.

ההגדרה הזו מבטלת את ערכי ברירת המחדל הגלובליים של אפשרויות ה-SET עבור כל המשתמשים. יכול להיות שמשתמשים ואפליקציות יניחו שאפשרויות ברירת המחדל של מסד הנתונים SET נמצאות בשימוש, ולכן הגדרת אפשרויות המשתמש עלולה לגרום לתוצאות לא צפויות. לכן, אנחנו לא ממליצים להגדיר את דגל מסד הנתונים user options.

מידע נוסף זמין במאמר בנושא הגדרת דגלים של מסד נתונים.

כדי לפתור את הבעיה, מבצעים את השלבים הבאים:

1. נכנסים לדף Cloud SQL Instances במסוףGoogle Cloud .

   כניסה לדף Cloud SQL Instances

2. בוחרים את המופע שמופיע בתוצאה של Security Health Analytics.

3. לוחצים על edit עריכה.

4. בקטע Database flags (דגלים של מסד הנתונים), לצד user options (אפשרויות משתמש), לוחצים על delete Delete (מחיקה).

5. לוחצים על Save. ההגדרה החדשה מופיעה בדף Instance overview.

read_more מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה.

SQL weak root password

שם הקטגוריה ב-API: SQL_WEAK_ROOT_PASSWORD

במופע של מסד נתונים של MySQL מוגדרת סיסמה חלשה לחשבון הבסיס. מומלץ להגדיר סיסמה חזקה למופע. מידע נוסף זמין במאמר בנושא משתמשי MySQL.

כדי לפתור את הבעיה, מבצעים את השלבים הבאים:

1. נכנסים לדף Cloud SQL Instances במסוף Google Cloud .

   כניסה לדף Cloud SQL Instances

2. בוחרים את המופע שמופיע בתוצאה של Security Health Analytics.

3. בדף Instance details שנטען, בוחרים בכרטיסייה Users.

4. לצד המשתמש root, לוחצים על סמל האפשרויות הנוספות , ואז בוחרים באפשרות שינוי סיסמה.

5. מזינים סיסמה חדשה וחזקה ולוחצים על אישור.

read_more מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה.

SSL not enforced

שם הקטגוריה ב-API: SSL_NOT_ENFORCED

לא נדרש שכל החיבורים הנכנסים למכונת מסד נתונים ב-Cloud SQL יהיו מוצפנים באמצעות SSL.

כדי למנוע דליפה של מידע אישי רגיש בזמן העברה דרך תקשורת לא מוצפנת, כל החיבורים הנכנסים למופע של מסד הנתונים SQL צריכים להשתמש ב-SSL. מידע נוסף על הגדרת SSL/TLS

כדי לתקן את הממצא הזה, צריך לאפשר רק חיבורי SSL למופעי SQL:

1. נכנסים לדף Cloud SQL Instances במסוף Google Cloud .

   כניסה לדף Cloud SQL Instances

2. בוחרים את המופע שמופיע בתוצאה של Security Health Analytics.

3. בכרטיסייה Connections (חיבורים), לוחצים על Allow only SSL connections (אפשר רק חיבורי SSL) או על Require trusted client certificates (נדרשים אישורי לקוח מהימנים). מידע נוסף זמין במאמר בנושא החלת הצפנה באמצעות SSL/TLS.

4. אם בחרתם באפשרות דרישת אישורי לקוח מהימנים, צריך ליצור אישור לקוח חדש. מידע נוסף זמין במאמר בנושא יצירת אישור לקוח חדש.

read_more מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה.

Too many KMS users

שם הקטגוריה ב-API: TOO_MANY_KMS_USERS

הגבלת מספר המשתמשים העיקריים שיכולים להשתמש במפתחות קריפטוגרפיים לשלושה. התפקידים המוגדרים מראש הבאים מעניקים הרשאות להצפנה, לפענוח או לחתימה של נתונים באמצעות מפתחות קריפטוגרפיים:

• roles/owner
• roles/cloudkms.cryptoKeyEncrypterDecrypter
• roles/cloudkms.cryptoKeyEncrypter
• roles/cloudkms.cryptoKeyDecrypter
• roles/cloudkms.signer
• roles/cloudkms.signerVerifier

מידע נוסף זמין במאמר בנושא הרשאות ותפקידים.

אם הפעלתם את Security Command Center Premium ברמת הפרויקט, הממצא הזה זמין רק אם מסלול Standard-legacy מופעל בארגון האב.

כדי לפתור את הבעיה, מבצעים את השלבים הבאים:

1. נכנסים לדף Cloud KMS keys במסוף Google Cloud .

   עוברים אל מפתחות Cloud KMS

2. לוחצים על השם של אוסף המפתחות שמצוין בתוצאת החיפוש.

3. לוחצים על שם המפתח שמצוין בתוצאה.

4. מסמנים את התיבה לצד הגרסה הראשית ולוחצים על הצגת חלונית המידע.

5. מצמצמים את מספר הגורמים שיש להם הרשאות להצפנה, לפענוח או לחתימה של נתונים לשלושה או פחות. כדי לבטל הרשאות, לוחצים על delete מחיקה לצד כל חשבון ראשי.

read_more מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה.

Unconfirmed AppArmor profile

שם הקטגוריה ב-API: GKE_APP_ARMOR

אפשר להגדיר קונטיינר באופן מפורש כך שלא יוגבל על ידי AppArmor. כך מוודאים שלא מוחל פרופיל AppArmor על הקונטיינר, ולכן הוא לא מוגבל על ידי פרופיל. השבתה של אמצעי בקרה למניעת סיכונים מגבירה את הסיכון לפירצה בקונטיינר.

כדי לפתור את הבעיה, מבצעים את השלבים הבאים בעומסי העבודה המושפעים:

1. פותחים את המניפסט של כל עומס עבודה מושפע.
2. מגדירים את השדות המוגבלים הבאים לאחד מהערכים המותרים.

שדות מוגבלים

• metadata.annotations["container.apparmor.security.beta.kubernetes.io/*"]

ערכים מותרים

• FALSE

User managed service account key

שם הקטגוריה ב-API: USER_MANAGED_SERVICE_ACCOUNT_KEY

משתמש מנהל מפתח של חשבון שירות. מפתחות של חשבונות שירות מהווים סיכון אבטחה אם לא מנהלים אותם בצורה נכונה. כשזה אפשרי, מומלץ לבחור שיטה מאובטחת יותר ממפתחות של חשבונות שירות. אם אתם מוכרחים לבצע אימות באמצעות מפתח של חשבון שירות, באחריותכם לאבטח את המפתח הפרטי ולבצע פעולות אחרות שמתוארות במאמר שיטות מומלצות לניהול מפתחות לחשבונות שירות. אם אתם לא יכולים ליצור מפתח לחשבון שירות, יכול להיות שהיצירה של מפתחות לחשבון שירות מושבתת בארגון שלכם. מידע נוסף מופיע במאמר בנושא ניהול משאבי ארגון שמוגדרים כמאובטחים כברירת מחדל.

אם קיבלתם את המפתח של חשבון השירות ממקור חיצוני, אתם צריכים לאמת אותו לפני השימוש. מידע נוסף זמין במאמר בנושא דרישות אבטחה לפרטי כניסה ממקור חיצוני.

כדי לפתור את הבעיה, מבצעים את השלבים הבאים:

1. נכנסים לדף Service Accounts במסוף Google Cloud .

   לדף Service accounts

2. אם צריך, בוחרים את הפרויקט שמצוין בתוצאת החיפוש.

3. אם מפתחות של חשבונות שירות בניהול משתמש לא נמצאים בשימוש באף אפליקציה, מוחקים אותם.

read_more מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה.

Weak SSL policy

שם הקטגוריה ב-API: WEAK_SSL_POLICY

במופע של Compute Engine מוגדרת מדיניות SSL חלשה או נעשה שימוש במדיניות SSL שמוגדרת כברירת מחדל ב- Google Cloudעם גרסת TLS שקטנה מ-1.2.

מאזני עומסים של HTTPS ושל שרת proxy של SSL משתמשים במדיניות SSL כדי לקבוע את הפרוטוקול ואת חבילות ההצפנה שמשמשים בחיבורי TLS שנוצרים בין משתמשים לבין האינטרנט. החיבורים האלה מצפינים נתונים רגישים כדי למנוע גישה של האזנות זדוניות. מדיניות SSL חלשה מאפשרת ללקוחות שמשתמשים בגרסאות מיושנות של TLS להתחבר עם סט אלגוריתמים להצפנה (cipher suite) או פרוטוקול פחות מאובטחים. רשימה של סטים מומלצים ומיושנים של אלגוריתמים להצפנה זמינה בדף הפרמטרים של TLS ב-iana.org.

אם הפעלתם את Security Command Center Premium ברמת הפרויקט, הממצא הזה זמין רק אם מסלול Standard-legacy מופעל בארגון האב.

שלבי התיקון של הממצא הזה משתנים בהתאם לגורם שהפעיל אותו. יכול להיות שהגורם הוא שימוש במדיניות SSL שמוגדרת כברירת מחדל ב- Google Cloud או במדיניות SSL שמאפשרת סט אלגוריתמים להצפנה (cipher suite) חלש או גרסת TLS מינימלית שקטנה מ-1.2. פועלים לפי התהליך שמתאים לטריגר של הממצא.

תיקון של מדיניות SSL שמוגדרת כברירת מחדל Google Cloud

1. נכנסים לדף Target proxies במסוף Google Cloud .

   מעבר אל Target proxies

2. מחפשים את שרת ה-proxy של היעד שמצוין בממצא ורושמים את כללי ההעברה בעמודה בשימוש על ידי.

3. כדי ליצור מדיניות SSL חדשה, אפשר לעיין במאמר בנושא שימוש במדיניות SSL. במדיניות צריך להיות פרופיל מודרני או מוגבל וגרסת TLS מינימלית של 1.2.

4. כדי להשתמש בפרופיל Custom , צריך לוודא שחבילות ההצפנה הבאות מושבתות:

   • TLS_RSA_WITH_AES_128_GCM_SHA256
   • TLS_RSA_WITH_AES_256_GCM_SHA384
   • TLS_RSA_WITH_AES_128_CBC_SHA
   • TLS_RSA_WITH_AES_256_CBC_SHA
   • TLS_RSA_WITH_3DES_EDE_CBC_SHA

5. מחילים את מדיניות ה-SSL על כל כלל העברה שרשמתם קודם.

תיקון שגיאות של סט אלגוריתמים להצפנה (cipher suite) חלש או גרסת TLS נמוכה

1. נכנסים לדף SSL policies במסוף Google Cloud .

   מעבר למדיניות SSL

2. מחפשים את מאזן העומסים שמצוין בעמודה בשימוש על ידי.

3. לוחצים מתחת לשם המדיניות.

4. לוחצים על edit עריכה.

5. משנים את גרסת TLS מינימלית ל-TLS 1.2 ואת פרופיל ל-Modern או ל-Restricted.

6. כדי להשתמש בפרופיל Custom, צריך לוודא שחבילות ההצפנה הבאות מושבתות:

   • TLS_RSA_WITH_AES_128_GCM_SHA256
   • TLS_RSA_WITH_AES_256_GCM_SHA384
   • TLS_RSA_WITH_AES_128_CBC_SHA
   • TLS_RSA_WITH_AES_256_CBC_SHA
   • TLS_RSA_WITH_3DES_EDE_CBC_SHA

7. לוחצים על Save.

read_more מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה.

Web UI enabled

שם הקטגוריה ב-API: WEB_UI_ENABLED

ממשק האינטרנט (מרכז הבקרה) של GKE מופעל.

חשבונות שירות ב-Kubernetes עם הרשאות גבוהות מגבים את ממשק האינטרנט של Kubernetes. אם חשבון השירות נפרץ, אפשר לנצל אותו לרעה. אם אתם כבר משתמשים במסוף Google Cloud , ממשק האינטרנט של Kubernetes מרחיב את שטח הפנים של המתקפה שלא לצורך. מידע נוסף על השבתת ממשק האינטרנט של Kubernetes

כדי לפתור את הבעיה הזו, צריך להשבית את ממשק האינטרנט של Kubernetes:

1. נכנסים לדף Kubernetes clusters במסוף Google Cloud .

   מעבר אל Kubernetes clusters

2. לוחצים על שם האשכול שמופיע בתוצאת הבדיקה של Security Health Analytics.

3. לוחצים על edit עריכה.

   אם חלו שינויים בהגדרת האשכול לאחרונה, יכול להיות שהלחצן 'עריכה' יהיה מושבת. אם אתם לא מצליחים לערוך את הגדרות האשכול, כדאי להמתין כמה דקות ולנסות שוב.

4. לוחצים על תוספים. הקטע יורחב ויוצגו בו התוספים הזמינים.

5. ברשימה הנפתחת Kubernetes dashboard, בוחרים באפשרות Disabled (מושבת).

6. לוחצים על Save.

read_more מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה.

Workload Identity disabled

שם הקטגוריה ב-API: WORKLOAD_IDENTITY_DISABLED

איחוד זהויות של עומסי עבודה ל-GKE מושבת באשכול GKE.

איחוד זהויות של עומסי עבודה ל-GKE הוא הדרך המומלצת לגשת לשירותיGoogle Cloud מתוך GKE, כי הוא מציע מאפייני אבטחה וניהול משופרים. הפעלת התכונה מאפשרת להשתמש במדיניות IAM כדי להעניק לעומסי עבודה של Kubernetes באשכול GKE גישה לממשקי API ספציפיים של Google Cloud בלי להצטרך להגדיר את הגישה באופן ידני או להשתמש בשיטות פחות מאובטחות כמו קובצי מפתחות של חשבונות שירות.

כדי לפתור את הבעיה, אפשר לעיין במאמר בנושא אימות ל-APIs Google Cloud מעומסי עבודה ב-GKE.

read_more מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה.

תיקון של הגדרות שגויות ב-AWS

AWS Cloud Shell Full Access Restricted

שם הקטגוריה ב-API: ACCESS_AWSCLOUDSHELLFULLACCESS_RESTRICTED

‫AWS CloudShell היא דרך נוחה להריץ פקודות CLI בשירותי AWS. מדיניות IAM מנוהלת (AWSCloudShellFullAccess) מספקת גישה מלאה ל-CloudShell, שמאפשרת העלאה והורדה של קבצים בין המערכת המקומית של המשתמש לבין סביבת CloudShell. בסביבת Cloud Shell, למשתמש יש הרשאות sudo והוא יכול לגשת לאינטרנט. לכן אפשר להתקין תוכנה להעברת קבצים (לדוגמה) ולהעביר נתונים מ-CloudShell לשרתים חיצוניים באינטרנט.

read_more מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה.

Access Keys Rotated Every 90 Days or Less

שם הקטגוריה ב-API: ACCESS_KEYS_ROTATED_90_DAYS_LESS

מפתחות גישה מורכבים ממזהה מפתח גישה וממפתח גישה סודי, שמשמשים לחתימה על בקשות תוכנתיות ששולחים ל-AWS. משתמשי AWS צריכים מפתחות גישה משלהם כדי לבצע קריאות תוכנה ל-AWS מ-AWS Command Line Interface (‏AWS CLI),‏ Tools for Windows PowerShell,‏ AWS SDKs או קריאות HTTP ישירות באמצעות ממשקי ה-API לשירותי AWS נפרדים. מומלץ לבצע רוטציה של כל מפתחות הגישה באופן קבוע.

aws iam create-access-key

aws iam get-access-key-last-used

aws iam update-access-key

aws iam delete-access-key

read_more מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה.

All Expired Ssl Tls Certificates Stored Aws Iam Removed

שם הקטגוריה ב-API: ALL_EXPIRED_SSL_TLS_CERTIFICATES_STORED_AWS_IAM_REMOVED

כדי להפעיל חיבורי HTTPS לאתר או לאפליקציה ב-AWS, צריך אישור שרת SSL/TLS. אתם יכולים להשתמש ב-ACM או ב-IAM כדי לאחסן ולפרוס אישורי שרת.
משתמשים ב-IAM כמנהל אישורים רק כשצריך לתמוך בחיבורי HTTPS באזור שלא נתמך על ידי ACM. מערכת IAM מצפינה באופן מאובטח את המפתחות הפרטיים שלכם ומאחסנת את הגרסה המוצפנת באחסון אישורי ה-SSL של IAM. ‫IAM תומך בפריסת אישורי שרת בכל האזורים, אבל אתם צריכים לקבל את האישור מספק חיצוני כדי להשתמש בו ב-AWS. אי אפשר להעלות אישור ACM ל-IAM. בנוסף, אי אפשר לנהל את האישורים דרך מסוף IAM.

aws iam delete-server-certificate --server-certificate-name <CERTIFICATE_NAME>

read_more מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה.

Autoscaling Group Elb Healthcheck Required

שם הקטגוריה ב-API: AUTOSCALING_GROUP_ELB_HEALTHCHECK_REQUIRED

הבדיקה הזו בודקת אם קבוצות ה-Auto Scaling שמשויכות למאזן עומסים משתמשות בבדיקות תקינות של Elastic Load Balancing.

כך אפשר לוודא שהקבוצה תוכל לקבוע את תקינות המופע על סמך בדיקות נוספות שסופקו על ידי מאזן העומסים. שימוש בבדיקות תקינות של Elastic Load Balancing יכול לעזור לתמוך בזמינות של אפליקציות שמשתמשות בקבוצות של EC2 Auto Scaling.

read_more מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה.

Auto Minor Version Upgrade Feature Enabled Rds Instances

שם הקטגוריה ב-API: AUTO_MINOR_VERSION_UPGRADE_FEATURE_ENABLED_RDS_INSTANCES

כדי לקבל שדרוגים אוטומטיים של גרסאות משניות של המנוע במהלך חלון זמן לתחזוקה שצוין, צריך לוודא שהדגל Auto Minor Version Upgrade (שדרוג אוטומטי של גרסה משנית) מופעל במכונות של מסד הנתונים של RDS. כך, מופעי RDS יכולים לקבל את התכונות החדשות, תיקוני הבאגים ותיקוני האבטחה למנועי מסדי הנתונים שלהם.

aws rds describe-db-instances --region <regionName> --query 'DBInstances[*].DBInstanceIdentifier'

aws rds modify-db-instance --region <regionName> --db-instance-identifier <dbInstanceIdentifier> --auto-minor-version-upgrade --apply-immediately

aws rds describe-db-instances --region <regionName> --db-instance-identifier <dbInstanceIdentifier> --query 'DBInstances[*].AutoMinorVersionUpgrade'

read_more מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה.

Aws Config Enabled All Regions

שם הקטגוריה ב-API: AWS_CONFIG_ENABLED_ALL_REGIONS

‫AWS Config הוא שירות אינטרנט שמבצע ניהול תצורה של משאבי AWS נתמכים בחשבון שלכם, ומספק לכם קובצי יומן. המידע שתועד כולל את פריט ההגדרה (משאב AWS), את הקשרים בין פריטי ההגדרה (משאבי AWS) ואת כל שינויי ההגדרה בין המשאבים. מומלץ להפעיל את AWS Config בכל האזורים.

aws configservice put-configuration-recorder --configuration-recorder name=default,roleARN=arn:aws:iam::012345678912:role/myConfigRole --recording-group allSupported=true,includeGlobalResourceTypes=true

{
 "name": "default",
 "s3BucketName": "my-config-bucket",
 "snsTopicARN": "arn:aws:sns:us-east-1:012345678912:my-config-notice",
 "configSnapshotDeliveryProperties": {
 "deliveryFrequency": "Twelve_Hours"
 }
}

aws configservice put-delivery-channel --delivery-channel file://deliveryChannel.json

aws configservice start-configuration-recorder --configuration-recorder-name default

read_more מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה.

Aws Security Hub Enabled

שם הקטגוריה ב-API: AWS_SECURITY_HUB_ENABLED

מרכז האבטחה אוסף נתוני אבטחה מחשבונות, משירותים וממוצרים נתמכים של שותפי צד שלישי ב-AWS, ועוזר לכם לנתח את מגמות האבטחה ולזהות את בעיות האבטחה שהכי חשוב לטפל בהן. כשמפעילים את Security Hub, הוא מתחיל לצרוך, לצבור, לארגן ולתעדף ממצאים משירותי AWS שהפעלתם, כמו Amazon GuardDuty,‏ Amazon Inspector ו-Amazon Macie. אפשר גם להפעיל שילובים עם מוצרי אבטחה של שותפי AWS.

aws securityhub enable-security-hub --enable-default-standards

aws securityhub enable-security-hub --no-enable-default-standards

read_more מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה.

Cloudtrail Logs Encrypted Rest Using Kms Cmks

שם הקטגוריה ב-API: CLOUDTRAIL_LOGS_ENCRYPTED_REST_USING_KMS_CMKS

‫AWS CloudTrail הוא שירות אינטרנט שמתעד קריאות ל-AWS API עבור חשבון, ומאפשר למשתמשים ולמשאבים לגשת ליומנים האלה בהתאם למדיניות IAM. ‫AWS Key Management Service‏ (KMS) הוא שירות מנוהל שעוזר ליצור ולשלוט במפתחות ההצפנה שמשמשים להצפנת נתוני החשבון, ומשתמש במודולים של אבטחה לחומרה (HSM) כדי להגן על האבטחה של מפתחות ההצפנה. אפשר להגדיר את יומני CloudTrail כך שישתמשו בהצפנה בצד השרת (SSE) ובמפתחות מאסטר (CMK) שנוצרו על ידי לקוחות KMS, כדי להגן על יומני CloudTrail. מומלץ להגדיר את CloudTrail לשימוש ב-SSE-KMS.

aws cloudtrail update-trail --name <trail_name> --kms-id <cloudtrail_kms_key>
aws kms put-key-policy --key-id <cloudtrail_kms_key> --policy <cloudtrail_kms_key_policy>

read_more מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה.

Cloudtrail Log File Validation Enabled

שם הקטגוריה ב-API: CLOUDTRAIL_LOG_FILE_VALIDATION_ENABLED

באימות של קובץ יומן CloudTrail נוצר קובץ תקציר חתום דיגיטלית שמכיל גיבוב של כל יומן ש-CloudTrail כותב ל-S3. אפשר להשתמש בקובצי התקציר האלה כדי לקבוע אם קובץ יומן השתנה, נמחק או לא השתנה אחרי ש-CloudTrail העביר את היומן. מומלץ להפעיל אימות קבצים בכל CloudTrail.

aws cloudtrail update-trail --name <trail_name> --enable-log-file-validation

aws cloudtrail validate-logs --trail-arn <trail_arn> --start-time <start_time> --end-time <end_time>

read_more מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה.

Cloudtrail Trails Integrated Cloudwatch Logs

שם הקטגוריה ב-API: CLOUDTRAIL_TRAILS_INTEGRATED_CLOUDWATCH_LOGS

‫AWS CloudTrail הוא שירות אינטרנט שמתעד קריאות ל-AWS API שבוצעו בחשבון AWS נתון. המידע שנרשם כולל את הזהות של מי שקורא ל-API, את השעה שבה בוצעה הקריאה ל-API, את כתובת ה-IP של המקור של מי שקורא ל-API, את פרמטרים הבקשה ואת רכיבי התגובה שמוחזרים על ידי שירות AWS. ‫CloudTrail משתמש ב-Amazon S3 לאחסון ולמסירת קובצי יומן, כך שקובצי היומן מאוחסנים בצורה עמידה. בנוסף לתיעוד יומני CloudTrail בדליקת S3 שצוינה לצורך ניתוח לטווח ארוך, אפשר לבצע ניתוח בזמן אמת על ידי הגדרת CloudTrail לשליחת יומנים ל-CloudWatch Logs. אם הפעלתם את המעקב בכל האזורים בחשבון, CloudTrail שולח קובצי יומן מכל האזורים האלה לקבוצת יומנים של CloudWatch Logs. מומלץ לשלוח את יומני CloudTrail אל CloudWatch Logs.

הערה: המטרה של ההמלצה הזו היא לוודא שהפעילות בחשבון AWS מתועדת, מפוקחת ומופעלות לגביה התראות מתאימות. יומני CloudWatch הם דרך מקורית לעשות את זה באמצעות שירותי AWS, אבל אפשר גם להשתמש בפתרון חלופי.

aws cloudtrail update-trail --name <trail_name> --cloudwatch-logs-log-group-arn <cloudtrail_log_group_arn> --cloudwatch-logs-role-arn <cloudtrail_cloudwatchLogs_role_arn>

read_more מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה.

Cloudwatch Alarm Action Check

שם הקטגוריה ב-API: CLOUDWATCH_ALARM_ACTION_CHECK

הבדיקה הזו בודקת אם מוגדרות פעולות ב-Amazon Cloudwatch כשמתרחש מעבר של התראה בין המצבים OK,‏ ALARM ו-INSUFFICIENT_DATA.

הגדרת פעולות למצב ALARM בהתראות של Amazon CloudWatch חשובה מאוד להפעלת תגובה מיידית כשמדדים שנמצאים במעקב חורגים מספי ערך הסף.
היא מאפשרת לפתור בעיות במהירות, מצמצמת את זמן ההשבתה ומאפשרת תיקון אוטומטי, כך שהמערכת תקינה ולא יתרחשו הפסקות שירות.

לכל התראה יש לפחות פעולה אחת.
לכל התראות יש פעולה אחת לפחות כשההתראה עוברת למצב INSUFFICIENT_DATA מכל מצב אחר.
(אופציונלי) לאזעקות יש לפחות פעולה אחת כשהאזעקה עוברת למצב 'OK' מכל מצב אחר.

read_more מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה.

Cloudwatch Log Group Encrypted

שם הקטגוריה ב-API: CLOUDWATCH_LOG_GROUP_ENCRYPTED

הבדיקה הזו מוודאת שיומני CloudWatch מוגדרים עם KMS.

הנתונים של קבוצת היומנים תמיד מוצפנים ב-CloudWatch Logs. כברירת מחדל, CloudWatch Logs משתמש בהצפנה בצד השרת עבור נתוני היומן באחסון. אפשרות אחרת היא להשתמש ב-AWS Key Management Service (שירות ניהול מפתחות) להצפנה הזו. אם כן, ההצפנה מתבצעת באמצעות מפתח AWS KMS. ההצפנה באמצעות AWS KMS מופעלת ברמת קבוצת היומנים, על ידי שיוך מפתח KMS לקבוצת יומנים, בזמן שיוצרים את קבוצת היומנים או אחרי שהיא נוצרת.

מידע נוסף זמין במאמר הצפנת נתוני יומן ב-CloudWatch Logs באמצעות AWS שירות ניהול מפתחות (KMS) במדריך למשתמש של Amazon CloudWatch.

read_more מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה.

CloudTrail CloudWatch Logs Enabled

שם הקטגוריה ב-API: CLOUD_TRAIL_CLOUD_WATCH_LOGS_ENABLED

הבקרה הזו בודקת אם מסלולי CloudTrail מוגדרים לשליחת יומנים ל-CloudWatch Logs. הבדיקה נכשלת אם המאפיין CloudWatchLogsLogGroupArn של ה-trail ריק.

‫CloudTrail מתעד קריאות ל-AWS API שמתבצעות בחשבון נתון. המידע שתועד כולל את הפרטים הבאים:

• הזהות של מי שקורא ל-API
• השעה של הקריאה ל-API
• כתובת ה-IP של המקור של מבצע הקריאה ל-API
• הפרמטרים של הבקשה
• רכיבי התגובה שמוחזרים על ידי שירות AWS

‫CloudTrail משתמש ב-Amazon S3 לאחסון ולמסירה של קובצי יומן. אפשר לתעד יומנים של CloudTrail בקטגוריית S3 שצוינה לצורך ניתוח לטווח ארוך. כדי לבצע ניתוח בזמן אמת, אפשר להגדיר את CloudTrail כך שישלח יומנים אל CloudWatch Logs.

אם הפעלתם את המעקב בכל האזורים בחשבון, CloudTrail שולח קובצי יומן מכל האזורים האלה לקבוצת יומנים של CloudWatch Logs.

ב-Security Hub מומלץ לשלוח יומני CloudTrail אל CloudWatch Logs. ההמלצה הזו נועדה להבטיח שהפעילות בחשבון תתועד, תנוטר ותיבדק בצורה מתאימה. אתם יכולים להשתמש ב-CloudWatch Logs כדי להגדיר את זה בשירותי AWS. ההמלצה הזו לא מונעת שימוש בפתרון אחר.

שליחת יומנים של CloudTrail אל CloudWatch Logs מאפשרת תיעוד פעילות בזמן אמת ופעילות היסטורית על סמך משתמש, API, משאב וכתובת IP. אתם יכולים להשתמש בגישה הזו כדי להגדיר התראות על פעילות חריגה או רגישה בחשבון.

כדי לשלב את CloudTrail עם CloudWatch Logs, אפשר לעיין במאמר שליחת אירועים אל CloudWatch Logs במדריך למשתמש של AWS CloudTrail.

read_more מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה.

No AWS Credentials in CodeBuild Project Environment Variables

שם הקטגוריה ב-API: CODEBUILD_PROJECT_ENVVAR_AWSCRED_CHECK

הבדיקה הזו מוודאת שהפרויקט מכיל את משתני הסביבה AWS_ACCESS_KEY_ID ו-AWS_SECRET_ACCESS_KEY.

אסור לאחסן את פרטי הכניסה לאימות AWS_ACCESS_KEY_ID וAWS_SECRET_ACCESS_KEY בטקסט פשוט, כי זה עלול להוביל לחשיפת נתונים לא מכוונת ולגישה לא מורשית.

כדי להסיר משתני סביבה מפרויקט CodeBuild, אפשר לעיין במאמר שינוי ההגדרות של פרויקט build ב-AWS CodeBuild במדריך למשתמש של AWS CodeBuild. מוודאים שלא נבחרו משתני סביבה.

אפשר לאחסן משתני סביבה עם ערכים רגישים ב-AWS Systems Manager Parameter Store או ב-AWS Secrets Manager, ואז לאחזר אותם ממפרט הבנייה. הוראות מפורטות מופיעות בתיבה עם הכיתוב 'חשוב' בקטע Environment במדריך למשתמש של AWS CodeBuild.

read_more מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה.

Codebuild Project Source Repo Url Check

שם הקטגוריה ב-API: CODEBUILD_PROJECT_SOURCE_REPO_URL_CHECK

הבדיקה הזו בודקת אם כתובת ה-URL של מאגר המקור של Bitbucket בפרויקט AWS CodeBuild מכילה טוקנים של גישה אישית או שם משתמש וסיסמה. הבדיקה נכשלת אם כתובת ה-URL של מאגר המקור ב-Bitbucket מכילה טוקנים של גישה אישית או שם משתמש וסיסמה.

אסור לאחסן או לשדר פרטי כניסה בטקסט לא מוצפן, או להציג אותם בכתובת ה-URL של מאגר המקור. במקום להשתמש בטוקנים אישיים לגישה או בפרטי כניסה, צריך לגשת לספק המקור ב-CodeBuild ולשנות את כתובת ה-URL של מאגר המקור כך שתכלול רק את הנתיב למיקום המאגר ב-Bitbucket. שימוש באסימוני גישה אישיים או בפרטי כניסה עלול לגרום לחשיפת נתונים לא מכוונת או לגישה לא מורשית.

אפשר לעדכן את פרויקט CodeBuild כך שישתמש ב-OAuth.

כדי להסיר אימות בסיסי / טוקן גישה אישי (GitHub) ממקור הפרויקט ב-CodeBuild

1. פותחים את מסוף CodeBuild בכתובת https://console.aws.amazon.com/codebuild/.
2. בוחרים את פרויקט ה-build שמכיל את טוקני הגישה האישיים או את שם המשתמש והסיסמה.
3. בתפריט 'עריכה', בוחרים באפשרות 'מקור'.
4. בוחרים באפשרות 'התנתקות מ-GitHub / Bitbucket'.
5. בוחרים באפשרות Connect using OAuth (התחברות באמצעות OAuth) ואז באפשרות Connect to GitHub / Bitbucket (התחברות אל GitHub / Bitbucket).
6. כשמוצגת בקשה, מאשרים את הפעולה לפי הצורך.
7. במקרה הצורך, מגדירים מחדש את כתובת ה-URL של המאגר והגדרות נוספות.
8. בוחרים באפשרות 'עדכון המקור'.

מידע נוסף זמין במאמר דוגמאות לתרחישי שימוש ב-CodeBuild במדריך למשתמש של AWS CodeBuild.

read_more מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה.

Credentials Unused 45 Days Greater Disabled

שם הקטגוריה ב-API: CREDENTIALS_UNUSED_45_DAYS_GREATER_DISABLED

משתמשי AWS IAM יכולים לגשת למשאבי AWS באמצעות סוגים שונים של פרטי כניסה, כמו סיסמאות או מפתחות גישה. מומלץ להשבית או להסיר את כל פרטי הכניסה שלא נעשה בהם שימוש במשך 45 ימים או יותר.

read_more מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה.

Default Security Group Vpc Restricts All Traffic

שם הקטגוריה ב-API: DEFAULT_SECURITY_GROUP_VPC_RESTRICTS_ALL_TRAFFIC

ל-VPC יש קבוצת אבטחה שמוגדרת כברירת מחדל, שההגדרות הראשוניות שלה מונעות את כל התעבורה הנכנסת, מאפשרות את כל התעבורה היוצאת ומאפשרות את כל התעבורה בין מופעים שמוקצים לקבוצת האבטחה. אם לא מציינים קבוצת אבטחה כשמפעילים מופע, המופע מוקצה אוטומטית לקבוצת האבטחה שמוגדרת כברירת המחדל. קבוצות אבטחה מספקות סינון עם שמירת מצב של תנועה ברשת נכנסת/יוצאת למשאבי AWS. מומלץ להגביל את כל התנועה בקבוצת האבטחה שמוגדרת כברירת מחדל.

צריך לעדכן את קבוצת האבטחה שמוגדרת כברירת מחדל בכל אזור ברשת ה-VPC שמוגדרת כברירת מחדל, כדי לעמוד בדרישות. כל רשתות ה-VPC החדשות שייווצרו יכללו באופן אוטומטי קבוצת אבטחה שמוגדרת כברירת מחדל, ויהיה צורך לבצע פעולות לתיקון כדי לעמוד בהמלצה הזו.

הערה: כשמיישמים את ההמלצה הזו, רישום של תנועת נתונים ב-VPC הוא כלי חשוב לקביעת הגישה המינימלית לפורטים שנדרשת למערכות כדי לפעול בצורה תקינה, כי הוא יכול לרשום את כל קבלות החבילות והדחיות שמתרחשות בקבוצות האבטחה הנוכחיות. השיטה הזו מפחיתה באופן משמעותי את המכשול העיקרי בהנדסת הרשאות מינימליות – גילוי היציאות המינימליות שנדרשות למערכות בסביבה. גם אם לא תאמצו את ההמלצה בנושא רישום ביומן של תנועת נתונים ב-VPC כצעד אבטחה קבוע, כדאי להשתמש בה במהלך תקופת הגילוי והתכנון של קבוצות אבטחה עם הרשאות מינימליות.

חברים בקבוצת אבטחה

כדי להטמיע את המצב שנקבע:

1. זיהוי משאבי AWS שקיימים בקבוצת האבטחה שמוגדרת כברירת מחדל
2. יצירה של קבוצת אבטחה עם הרשאות מינימליות למשאבים האלה
3. ממקמים את המשאבים בקבוצות האבטחה האלה
4. מסירים את המשאבים שמצוינים בסעיף 1 מקבוצת האבטחה שמוגדרת כברירת מחדל

מצב קבוצת האבטחה

1. מתחברים למסוף הניהול של AWS בכתובת https://console.aws.amazon.com/vpc/home
2. חוזרים על השלבים הבאים לכל רשת VPC – כולל רשת ה-VPC שמוגדרת כברירת מחדל בכל אזור AWS:
3. בחלונית הימנית, לוחצים על Security Groups.
4. לכל קבוצת אבטחה שמוגדרת כברירת מחדל, מבצעים את הפעולות הבאות:
5. בוחרים את קבוצת האבטחה default.
6. לוחצים על הכרטיסייה Inbound Rules.
7. הסרת כל הכללים לשיחות נכנסות
8. לוחצים על הכרטיסייה Outbound Rules.
9. הסרת כל כללי התעבורה היוצאת

מומלץ:

קבוצות IAM מאפשרות לערוך את השדה 'שם'. אחרי שמתקנים את כללי קבוצות ברירת המחדל בכל רשתות ה-VPC בכל האזורים, עורכים את השדה הזה ומוסיפים טקסט כמו 'אין להשתמש. אל תוסיפו כללים"

read_more מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה.

Dms Replication Not Public

שם הקטגוריה ב-API: DMS_REPLICATION_NOT_PUBLIC

בודקת אם מופעי השכפול של AWS DMS הם ציבוריים. לשם כך, המערכת בודקת את הערך של השדה PubliclyAccessible.

למופע שכפול פרטי יש כתובת IP פרטית שאי אפשר לגשת אליה מחוץ לרשת השכפול. למכונת השכפול צריכה להיות כתובת IP פרטית אם מסדי הנתונים של המקור והיעד נמצאים באותה רשת. הרשת צריכה להיות מחוברת גם ל-VPC של מופע הרפליקציה באמצעות VPN,‏ AWS Direct Connect או קישור בין רשתות VPC שכנות. מידע נוסף על מופעי שכפול ציבוריים ופרטיים זמין במאמר Public and private replication instances במדריך למשתמש של AWS Database Migration Service.

כדאי גם לוודא שהגישה להגדרות של מופע AWS DMS מוגבלת למשתמשים מורשים בלבד. כדי לעשות זאת, מגבילים את הרשאות ה-IAM של המשתמשים לשינוי ההגדרות והמשאבים של AWS DMS.

אי אפשר לשנות את הגדרת הגישה הציבורית של מופע שכפול של DMS אחרי שיוצרים אותו. כדי לשנות את הגדרת הגישה הציבורית, צריך למחוק את המופע הנוכחי ואז ליצור אותו מחדש. לא בוחרים באפשרות 'נגיש לכולם'.

read_more מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה.

Do Setup Access Keys During Initial User Setup All Iam Users Console

שם הקטגוריה ב-API: DO_SETUP_ACCESS_KEYS_DURING_INITIAL_USER_SETUP_ALL_IAM_USERS_CONSOLE

במסוף AWS, כשיוצרים משתמש IAM חדש, ברירת המחדל היא שתיבות הסימון לא מסומנות. כשיוצרים את פרטי הכניסה של משתמש IAM, צריך לקבוע את סוג הגישה שנדרש לו.

גישה באמצעות תוכנה: יכול להיות שמשתמש IAM יצטרך לבצע קריאות ל-API, להשתמש ב-AWS CLI או להשתמש ב-Tools for Windows PowerShell. במקרה כזה, צריך ליצור מפתח גישה (מזהה מפתח גישה ומפתח גישה סודי) עבור המשתמש.

גישה למסוף הניהול של AWS: אם המשתמש צריך לגשת למסוף הניהול של AWS, צריך ליצור סיסמה בשבילו.

aws iam delete-access-key --access-key-id <access-key-id-listed> --user-name <users-name>

read_more מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה.

Dynamodb Autoscaling Enabled

שם הקטגוריה ב-API: DYNAMODB_AUTOSCALING_ENABLED

הבדיקה הזו נועדה לוודא שאפשר להגדיל את קיבולת הקריאה והכתיבה של טבלה ב-Amazon DynamoDB לפי הצורך. הבדיקה הזו עוברת אם הטבלה משתמשת במצב קיבולת לפי דרישה או במצב הקצאה עם קנה מידה אוטומטי מוגדר. התאמת הקיבולת לביקוש מאפשרת להימנע מחריגות של ויסות נתונים (throttle), וכך לשמור על הזמינות של האפליקציות.

הטבלאות של DynamoDB במצב קיבולת לפי דרישה מוגבלות רק על ידי מכסות ברירת המחדל של DynamoDB לתפוקה של טבלאות. כדי להגדיל את המכסות האלה, אפשר להגיש כרטיס תמיכה דרך התמיכה של AWS.

טבלאות DynamoDB במצב מוקצה עם התאמה אוטומטית לעומס משנות את קיבולת התפוקה המוקצית באופן דינמי בתגובה לדפוסי תנועה. מידע נוסף על הגבלת קצב הבקשות ב-DynamoDB זמין במאמר Request throttling and burst capacity (הגבלת קצב הבקשות וקיבולת פרץ) במדריך למפתחים של Amazon DynamoDB.

הוראות מפורטות להפעלת התאמה אוטומטית לעומס של DynamoDB בטבלאות קיימות במצב קיבולת זמינות במאמר הפעלת התאמה אוטומטית לעומס של DynamoDB בטבלאות קיימות במדריך למפתחים של Amazon DynamoDB.

read_more מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה.

Dynamodb In Backup Plan

שם הקטגוריה ב-API: DYNAMODB_IN_BACKUP_PLAN

הבקרה הזו בודקת אם טבלת DynamoDB מכוסה על ידי תוכנית גיבוי. הבקרות נכשלות אם טבלת DynamoDB לא נכללת בתוכנית גיבוי. הבקרה הזו מעריכה רק טבלאות של DynamoDB שנמצאות במצב ACTIVE.

גיבויים עוזרים לכם להתאושש מהר יותר מאירוע אבטחה. הם גם מחזקים את החוסן של המערכות שלכם. הכללת טבלאות של DynamoDB בתוכנית גיבוי עוזרת להגן על הנתונים מפני אובדן או מחיקה לא מכוונים.

כדי להוסיף טבלת DynamoDB לתוכנית גיבוי של AWS Backup, אפשר לעיין במאמר הקצאת משאבים לתוכנית גיבוי במדריך למפתחים של AWS Backup.

read_more מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה.

Dynamodb Pitr Enabled

שם הקטגוריה ב-API: DYNAMODB_PITR_ENABLED

שחזור מערכת מנקודה מסוימת בזמן (PITR) הוא אחד מהמנגנונים שזמינים לגיבוי טבלאות DynamoDB.

גיבוי לנקודת זמן מסוימת נשמר למשך 35 ימים. אם אתם צריכים תקופת שמירה ארוכה יותר, תוכלו לעיין במאמר הגדרת גיבויים מתוזמנים ל-Amazon DynamoDB באמצעות AWS Backup בתיעוד של AWS.

resource "aws_dynamodb_table" "example" {
  # ... other configuration ...
  point_in_time_recovery {
    enabled = true
  }
}

aws dynamodb update-continuous-backups \
  --table-name "GameScoresOnDemand" \
  --point-in-time-recovery-specification "PointInTimeRecoveryEnabled=true"

read_more מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה.

Dynamodb Table Encrypted Kms

שם הקטגוריה ב-API: DYNAMODB_TABLE_ENCRYPTED_KMS

הבדיקה קובעת אם כל טבלאות DynamoDB מוצפנות באמצעות מפתח KMS בניהול לקוח (לא ברירת המחדל).

resource "aws_kms_key" "dynamodb_encryption" {
  description         = "Used for DynamoDB encryption configuration"
  enable_key_rotation = true
}

resource "aws_dynamodb_table" "example" {
  # ... other configuration ...
  server_side_encryption {
    enabled     = true
    kms_key_arn = aws_kms_key.dynamodb_encryption.arn
  }
}

aws dynamodb update-table \
  --table-name <value> \
  --sse-specification "Enabled=true,SSEType=KMS,KMSMasterKeyId=<kms_key_arn>"

read_more מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה.

Ebs Optimized Instance

שם הקטגוריה ב-API: EBS_OPTIMIZED_INSTANCE

בודק אם האופטימיזציה של EBS מופעלת במופעי EC2 שאפשר לבצע בהם אופטימיזציה של EBS

הוראות להגדרת מופע שעבר אופטימיזציה ל-EBS מופיעות במאמר Amazon EBS–optimized instances במדריך למשתמש של Amazon EC2.

read_more מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה.

Ebs Snapshot Public Restorable Check

שם הקטגוריה ב-API: EBS_SNAPSHOT_PUBLIC_RESTORABLE_CHECK

הבדיקה קובעת אם תמונות המצב של Amazon Elastic Block Store הן לא ציבוריות. הבדיקה נכשלת אם כל אחד יכול לשחזר תמונות מצב של Amazon EBS.

תמונות מצב של EBS משמשות לגיבוי הנתונים בכרכים של EBS ב-Amazon S3 בנקודת זמן ספציפית. אפשר להשתמש בתמונות המצב כדי לשחזר מצבים קודמים של נפחי EBS. בדרך כלל לא מקובל לשתף צילום מסך עם הציבור. בדרך כלל ההחלטה לשתף תמונה של מצב המערכת באופן ציבורי מתקבלת בטעות או ללא הבנה מלאה של ההשלכות. הבדיקה הזו עוזרת לוודא שכל השיתופים האלה תוכננו מראש ונעשו בכוונה.

read_more מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה.

Ebs Volume Encryption Enabled All Regions

שם הקטגוריה ב-API: EBS_VOLUME_ENCRYPTION_ENABLED_ALL_REGIONS

שירות Elastic Compute Cloud‏ (EC2) תומך בהצפנה במנוחה כשמשתמשים בשירות Elastic Block Store‏ (EBS). ההצפנה מושבתת כברירת מחדל, אבל יש תמיכה בהפעלת הצפנה כשיוצרים נפח אחסון של EBS.

aws --region <region> ec2 enable-ebs-encryption-by-default

read_more מידע על הנכסים הנתמכים והגדרות הסריקה של סוג הממצא הזה.

Ec2 Instances In Vpc

שם הקטגוריה ב-API: EC2_INSTANCES_IN_VPC

‫Amazon VPC מספקת פונקציונליות אבטחה רחבה יותר מ-EC2 Classic. מומלץ שכל הצמתים יהיו שייכים ל-Amazon VPC.

  resource "aws_vpc" "example_vpc" {
    cidr_block = "10.0.0.0/16"
  }

  resource "aws_subnet" "example_public_subnet" {
    vpc_id            = aws_vpc.example_vpc.id
    cidr_block        = "10.0.1.0/24"
    availability_zone = "1a"
  }

  resource "aws_internet_gateway" "example_igw" {
    vpc_id = aws_vpc.example_vpc.id
  }

  resource "aws_key_pair" "example_key" {
    key_name   = "web-instance-key"
    public_key = "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQD3F6tyPEFEzV0LX3X8BsXdMsQz1x2cEikKDEY0aIj41qgxMCP/iteneqXSIFZBp5vizPvaoIR3Um9xK7PGoW8giupGn+EPuxIA4cDM4vzOqOkiMPhz5XK0whEjkVzTo4+S0puvDZuwIsdiW9mxhJc7tgBNL0cYlWSYVkz4G/fslNfRPW5mYAM49f4fhtxPb5ok4Q2Lg9dPKVHO/Bgeu5woMc7RY0p1ej6D4CKFE6lymSDJpW0YHX/wqE9+cfEauh7xZcG0q9t2ta6F6fmX0agvpFyZo8aFbXeUBr7osSCJNgvavWbM/06niWrOvYX2xwWdhXmXSrbX8ZbabVohBK41 email@example.com"
  }

  resource "aws_security_group" "web_sg" {
    name   = "http and ssh"
    vpc_id = aws_vpc.some_custom_vpc.id

    ingress {
      from_port   = 80
      to_port     = 80
      protocol    = "tcp"
      cidr_blocks = ["0.0.0.0/0"]
    }

    ingress {
      from_port   = 22
      to_port     = 22
      protocol    = "tcp"
      cidr_blocks = ["0.0.0.0/0"]
    }

    egress {
      from_port   = 0
      to_port     = 0
      protocol    = -1
      cidr_blocks = ["0.0.0.0/0"]
    }
  }

  resource "aws_instance" "web" {
    ami                    = <ami_id>
    instance_type          = <instance_flavor>
    key_name               = aws_key_pair.example_key.name
    monitoring             = true
    subnet_id              = aws_subnet.example_public_subnet.id
    vpc_security_group_ids = [aws_security_group.web_sg.id]
    metadata_options {
      http_tokens = "required"
    }
  }