---
title: "רשימת בדיקה להקשחת אבטחה ב־GCP | Snow Tree"
url: "https://www.snow-tree.com/he/gcp-security-hardening/"
---

תשתית GCP מאובטחת

# רשימת בדיקה להקשחת אבטחה ב־GCP לצוותים קטנים ובינוניים

קו בסיס מעשי לצוותים שמריצים עומסי עבודה בייצור ב־Google Cloud בלי מחלקת אבטחה ייעודית. התחילו במקומות שבהם הכי קל לצמצם את הנתיבים הסבירים ביותר לאירוע חמור.

## בעמוד הזה

1. [נתיבי איום נפוצים ב־GCP](https://www.snow-tree.com/he/#threat-paths)
2. [זהות וגישה](https://www.snow-tree.com/he/#identity)
3. [רשת וקצה](https://www.snow-tree.com/he/#network)
4. [נתונים וסודות](https://www.snow-tree.com/he/#data)
5. [הקשחת GKE](https://www.snow-tree.com/he/#gke)
6. [זיהוי והתאוששות](https://www.snow-tree.com/he/#detection)
7. [רשימת בדיקה מתועדפת ל־30, 60 ו־90 יום](https://www.snow-tree.com/he/#checklist)
8. [הפניות רשמיות](https://www.snow-tree.com/he/#references)

## נתיבי איום נפוצים ב־GCP

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

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

## זהות וגישה

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

### הגדירו במפורש את גבולות המשאבים

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

### הקצו את התפקיד המינימלי בהיקף המצומצם ביותר

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

### הסירו פרטי כניסה ארוכי טווח

השתמשו ב־Workload Identity Federation for GKE כדי שפודים יקבלו פרטי כניסה קצרי טווח בלי מפתחות מיוצאים של חשבונות שירות. חסמו יצירה והעלאה של מפתחות באמצעות מדיניות ארגון ככל האפשר, נהלו מלאי של כל המפתחות שנותרו והגדירו התראות על שינויי IAM בסיכון גבוה ב־Cloud Audit Logs.

## רשת וקצה

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

### התחילו מחסימה והוסיפו נתיבים מוגדרים במפורש

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

### שמרו על צמתים ועל מישורי בקרה פרטיים

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

### פרסמו רק שירותים ציבוריים שנבחרו במכוון

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

## נתונים וסודות

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

### מנעו גישה ציבורית בשוגג

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

### הרחיקו סודות מאימג'ים ומקוד המקור

אחסנו פרטי כניסה ב־Secret Manager והעניקו גישה לזהות ספציפית של עומס עבודה ולגרסה ספציפית של הסוד. החליפו סודות באופן מתוכנן, הימנעו מהעתקתם ל־Git או לאימג'ים של קונטיינרים, ואל תתייחסו ל־Kubernetes Secrets רגילים כאל גבול הגנה שלם.

### בדקו שחזור, לא רק יצירת גיבויים

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

## הקשחת GKE

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

### הפכו את מרחבי השמות לחוזה הבידוד

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

### אשרו רק אימג'ים ותצורות שאתם סומכים עליהם

אכפו את תקן Pod Security ברמה המוגבלת או כללי Policy Controller מקבילים. פרסו אימג'ים לפי digest בלתי ניתן לשינוי, סרקו אותם לאיתור פגיעויות, השתמשו ב־Binary Authorization כשמקור האימג' חשוב, ודחו גישה לא צפויה למארח, הסלמת הרשאות וקישורי cluster-admin.

### הסירו הרשאות מיותרות מהקונטיינרים

הריצו כמשתמש שאינו root, הסירו יכולות Linux (capabilities), השתמשו במערכת קבצי שורש לקריאה בלבד ככל האפשר, והחילו את פרופיל RuntimeDefault של seccomp. אל תעגנו את אסימון חשבון השירות ללא צורך, הימנעו מקונטיינרים בהרשאות מורחבות וממרחבי שמות של המארח, צמצמו למינימום את חשבון השירות של הצמתים, והשתמשו ב־Shielded Nodes יחד עם Container-Optimized OS.

## זיהוי והתאוששות

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

### אספו את הראיות שתצטרכו

שמרו את Cloud Audit Logs ואת יומני המערכת ועומסי העבודה של GKE ביעד מרכזי, עם תקופת שמירה שמתאימה לצורכי החקירה שלכם. הפעילו יומני ביקורת של גישה לנתונים (Data Access) באופן סלקטיבי לנתונים רגישים, הגבילו את הגישה ליומנים ותעדו שינויים ניהוליים ב־IAM, בחומת האש, באחסון ובתצורת האשכול.

### הגדירו התראות על שינויים בעלי משמעות אבטחתית

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

### תרגלו את התגובה

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

## רשימת בדיקה מתועדפת ל־30, 60 ו־90 יום

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

### ימים 1 עד 30: חסמו את הנתיבים הברורים

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

### ימים 31 עד 60: הפכו את קו הבסיס לניתן לחזרה

העבירו את תצורת הרשת, הזהויות ועומסי העבודה לתשתית כקוד שעוברת סקירה ולאספקה ב־GitOps. אמצו את Workload Identity, צמתים פרטיים, Pod Security ברמה המוגבלת, בדיקות לאימג'ים מהימנים, יומנים מרוכזים והתראות על השינויים החשובים ביותר.

### ימים 61 עד 90: הוכיחו ושמרו על הרמה לאורך זמן

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

השתמשו ברשימת הבדיקה הזו כנקודת פתיחה. Snow Tree יכולה ליישם את קו הבסיס במסגרת תפעול פלטפורמה מנוהלת או התקשרות ייעוץ ממוקדת.

[פלטפורמה מנוהלת](https://www.snow-tree.com/he/managed-platform/) [ייעוץ](https://www.snow-tree.com/he/consulting/)

## הפניות רשמיות

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

- [Google Cloud: שיטות מומלצות להקשחת אשכול ה־GKE שלכם](https://docs.cloud.google.com/kubernetes-engine/docs/how-to/hardening-your-cluster)
- [Google Cloud: שיטות מומלצות לאבטחת GKE](https://docs.cloud.google.com/docs/security/gke-security-bps)

פלטפורמה מנוהלת

## תנו ל־Snow Tree לבנות, לארח ולהפעיל את התוכנה.

[התחלת פרויקט](mailto:support+snow-tree-platform-1-issue-@gitlab.snow-tree.com?subject=Snow%20Tree%20project)