הנחיות בנושא תשתית

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

הנחיות בסיסיות

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

פריט	השבתת הגישה ליציאה טורית של VM
תיאור	כדי להשבית את הגישה ליציאות טוריות, מגדירים את האילוץ compute.disableSerialPortAccess במדיניות הארגון. כדי למנוע ערוץ גישה שעוקף את כללי חומת האש ואמצעי בקרת אבטחה אחרים ברשת, כדאי להשבית את הגישה ליציאה טורית במכונות וירטואליות ב-Compute Engine. המסוף הטורי האינטראקטיבי מיועד בעיקר לפתרון בעיות במקרה חירום, אבל אם משאירים אותו מופעל, אפשר ליצור דלת אחורית קבועה שהתוקפים יכולים לכוון אליה. השבתת הגישה ליציאה טורית עוזרת לאכוף אסטרטגיית אבטחה מקיפה, כי היא מחייבת שכל הגישה האדמיניסטרטיבית תתבצע דרך נתיבים סטנדרטיים שנבדקים, כמו SSH. כדי להגן על הנתיבים האלה, אפשר להפעיל ניהול זהויות והרשאות גישה (IAM) ושרת proxy לאימות זהויות (IAP).
מידע קשור	השבתת גישה אינטראקטיבית למסוף הטורי באמצעות Organization Policy Service
מזהה פריט	MVSP-CO-1.24
מיפוי	אמצעי בקרה קשורים בתקן NIST-800-53: AC-3 הגדרות שקשורות לפרופיל CRI: PR.AC-3.1

פריט	השבתה של IPv6 אלא אם נדרש
תיאור	משביתים את היצירה של רשת משנה חיצונית של IPv6, אלא אם נדרש אחרת. כדי לצמצם את שטח הפנים של המתקפה, כדאי להשבית את IPv6 במערכות וברשתות שבהן הוא לא מנוהל באופן פעיל או לא נדרש. בארגונים רבים יש אמצעי בקרה וניטור מתקדמים לאבטחת IPv4, אבל יכול להיות שהכלים וכללי המדיניות שלהם לא מתאימים ל-IPv6, ולכן הם עלולים להיות חשופים לאיומים. הפעלת רשת עם תמיכה בשני הפרוטוקולים גם מוסיפה מורכבות תפעולית, ומחייבת הגדרות ספציפיות ומומחיות כדי לנהל ולפתור בעיות בצורה יעילה. לכן, אם אין לכם סיבה עסקית ברורה להשתמש ב-IPv6, השבתה שלו יכולה לפשט את הסביבה שלכם ולהבטיח שכל התנועה תסונן באופן עקבי באמצעות אסטרטגיית האבטחה הקיימת שלכם ב-IPv4.
מידע קשור	תמיכה ב-IPv6 ב- Google Cloud
מזהה פריט	MVSP-CO-1.25
מיפוי	אמצעי בקרה קשורים בתקן NIST-800-53: CM-7 הגדרות שקשורות לפרופיל CRI: PR.PT-3.1 אמצעי בקרה ב-Compliance Manager: הגדרת מדיניות הארגון 'השבתת השימוש ב-IPv6 חיצוני ב-VPC'

פריט	הפעלת תכונות של מכונות וירטואליות מוגנות
תיאור	מפעילים את המודול הווירטואלי של פלטפורמת האבטחה המהימנה (vTPM) ואת מאפייני ניטור התקינות של המכונות הווירטואליות המוגנות עבור המכונות שלכם. מאפייני ה-vTPM וניטור התקינות הם חלק מתהליך ברירת המחדל של יצירת מכונות וירטואליות. כדי לוודא שהמכונות הווירטואליות מופעלות רק עם קוד מהימן שלא עבר שינוי, אפשר להשתמש במאפיינים של vTPM וניטור התקינות של מכונות וירטואליות מוגנות. ה-vTPM מספק מעבד קריפטוגרפי וירטואלי ומאובטח שיוצר ומאחסן מדידות קריפטוגרפיות של כל רצף האתחול, מקושחת ה-UEFI ועד לדרייברים של ליבת המערכת. לאחר מכן, המערכת משווה באופן רציף את המדידות האלה של זמן הריצה לנתוני בסיס תקינים שנקבעו כשנוצר ה-VM. התכונות האלה מספקות שרשרת אמון שניתנת לאימות, ומציגות התראה באופן אוטומטי או מבצעות פעולה אם הן מזהות שינויים זדוניים, כמו אלה שנובעים מ-bootkit או מ-rootkit. התכונות של מכונות וירטואליות מוגנות עוזרות לשמור על השלמות של עומס העבודה מהרגע שהמופע מופעל.
מידע קשור	סקירה כללית על מכונות וירטואליות מוגנות
מזהה פריט	MVSP-CO-1.28
מיפוי	אמצעי בקרה קשורים בתקן NIST-800-53: SI-7 הגדרות שקשורות לפרופיל CRI: PR.DS-6.1 אמצעי בקרה ב-Compliance Manager: הפעלת מכונה וירטואלית מוגנת למכונות של Compute Engine

פריט	שימוש ב-GKE Autopilot
תיאור	שימוש באשכולות Autopilot של Google Kubernetes Engine‏ (GKE). אשכולות Autopilot מציעים אמצעי אבטחה חזקים, עם הרבה שיטות מומלצות לאבטחת קונטיינרים או GKE שמופעלות כברירת מחדל.
מידע קשור	סקירה כללית על GKE Autopilot
מזהה פריט	MVSP-CO-1.29
מיפוי	אמצעי בקרה קשורים בתקן NIST-800-53: CM-2 הגדרות שקשורות לפרופיל CRI: PR.IP-1.1

פריט	שימוש בחשבונות עם הרשאות מינימליות לאשכולות ולצמתים של GKE
תיאור	מומלץ להשתמש בחשבונות שירות של ניהול זהויות והרשאות גישה (IAM) עם הרשאות מינימליות לאשכולות ולצמתים של Google Kubernetes Engine‏ (GKE). הגישה למישור הבקרה של GKE מוגבלת לנקודת קצה אחת שמבוססת על DNS. הטמעה של הרשאות מינימליות מפחיתה באופן משמעותי את שטח ההתקפה, בלי שצריך להשתמש בכללי חומת אש נוספים או במארחי באסטיון.
מידע קשור	הקשחת האבטחה באשכול
מזהה פריט	MVSP-CO-1.30
מיפוי	אמצעי בקרה קשורים בתקן NIST-800-53: AC-6 הגדרות שקשורות לפרופיל CRI: PR.AC-4.1 אמצעי בקרה ב-Compliance Manager: שימוש בחשבונות שירות עם הרשאות מינימליות באשכולות GKE

פריט	הגבלת הגישה למישור הבקרה
תיאור	כברירת מחדל, למישורי הבקרה ולצמתים של אשכולות Google Kubernetes Engine‏ (GKE) יש כתובות ניתוב באינטרנט שאפשר לגשת אליהן מכל כתובת IP. הגבלת הגישה לרשת למישור הבקרה באמצעות נקודת קצה (endpoint) מבוססת-DNS ויצירת אשכולות פרטיים. רמת הבקרה היא מרכז הניהול של אשכול Kubernetes, וחשיפתה לאינטרנט הופכת אותה למטרה עיקרית לתוקפים. ההגדרה הזו הופכת את מישור הבקרה לפרטי ומסירה אותו מהאינטרנט. הגבלת הגישה למישור הבקרה עוזרת לוודא שרק מכשירים מהימנים ברשת הפרטית של הארגון יכולים לנהל את האשכול, וכך מצמצמת באופן משמעותי את הסיכון למתקפה חיצונית.
מידע קשור	איך פועלות רשתות מורשות התאמה אישית של בידוד הרשת ב-GKE יצירת אשכול פרטי
מזהה פריט	MVSP-CO-1.31
מיפוי	אמצעי בקרה קשורים בתקן NIST-800-53: SC-7 הגדרות שקשורות לפרופיל CRI: PR.AC-3.1

פריט	שימוש במערכת הפעלה שמותאמת לקונטיינרים עם זמן ריצה של containerd
תיאור	שימוש במערכת הפעלה שמותאמת לקונטיינרים כדי להטמיע מערכת הפעלה מנוהלת לקונטיינרים עם אבטחה משופרת. מערכות הפעלה לשימוש כללי כוללות הרבה תוכניות נוספות שלא נדרשות להפעלת קונטיינרים, ולכן הן יוצרות יעד גדול יותר ומיותר לתוקפים. מערכת הפעלה שמותאמת לקונטיינרים היא מערכת הפעלה מינימלית ומוגבלת, שמצמצמת באופן משמעותי את שטח הפנים הזה להתקפה, כי היא כוללת רק את מה שנדרש. בנוסף, מערכת הפעלה שמותאמת לקונטיינרים היא מערכת הפעלה מנוהלת, ולכן Google מחילה עליה באופן אוטומטי תיקוני אבטחה. כך אפשר לוודא שנקודות חולשה קריטיות יתוקנו, וגם לצמצם את עומס העבודה התפעולי. תמונה שכוללת מערכת הפעלה שמותאמת לקונטיינרים עם containerd‏ (cos_containerd) מכילה את containerd כזמן הריצה הראשי של הקונטיינר שמשולב ישירות עם Kubernetes. ‏containerd הוא רכיב הליבה של זמן הריצה של Docker, והוא מיועד לספק פונקציונליות ליבה של קונטיינרים לממשק זמן הריצה של הקונטיינרים (CRI) של Kubernetes. הוא פשוט בהרבה מ-Docker daemon המלא, ולכן שטח הפנים שלו להתקפה קטן יותר.
מידע קשור	סקירה כללית על מערכת הפעלה שמותאמת לקונטיינרים
מזהה פריט	MVSP-CO-1.41
מיפוי	אמצעי בקרה קשורים בתקן NIST-800-53: CM-7 SC-7 SC-38 SI-2 SI-7 הגדרות שקשורות לפרופיל CRI: PR.PT-3.1 אמצעי בקרה ב-Compliance Manager: דרישה של מערכת הפעלה שמותאמת לקונטיינרים עבור אשכול GKE

הנחיות לרמה בינונית

אחרי שמטמיעים את ההנחיות הבסיסיות, מטמיעים את ההנחיות הבאות בנוגע לתשתית.

פריט	אכיפת OS Login במכונות וירטואליות
תיאור	אם אתם מאפשרים למפתחים לגשת למשאבי Compute Engine באמצעות SSH, כדאי להגדיר OS Login עם אימות דו-שלבי. כדי להשתמש ב-OS Login לניהול מפתחות SSH באמצעות כללי מדיניות של ניהול זהויות והרשאות גישה (IAM), צריך להגדיר את האילוץ של מדיניות הארגון compute.requireOsLogin. שירות OS Login מרכז את הגישה למכונות הווירטואליות על ידי קישור הרשאות SSH לזהות Google של המשתמש ולתפקידים ב-IAM, וכך מבטל את הצורך לנהל מפתחות SSH נפרדים בכל מכונה. קישור הרשאות SSH לזהות של משתמש הוא חיוני לאבטחה, כי הסרה של תפקיד IAM של משתמש מבטלת באופן מיידי את הגישה שלו לכל המקרים, וכך מונעת כניסה לא מורשית מחשבונות לא פעילים. המערכת מפשטת את ניהול המפתחות כדי למנוע התפשטות של מפתחות, ומספקת נתיב ביקורת ברור ומרכזי לכל אירועי הכניסה ביומני הביקורת של Cloud. בנוסף, OS Login מאפשר לאכוף אימות דו-שלבי, וכך להוסיף שכבת הגנה חשובה מפני גניבה של מפתחות SSH ופרטי כניסה. התכונה הזו חוסמת תוקף עם אסימוני OAuth שנפרצו, אבל בלי סיסמה או מפתח אבטחה.
מידע קשור	הגדרת OS Login
מזהה פריט	MVSP-CO-1.26
מיפוי	אמצעי בקרה קשורים בתקן NIST-800-53: AC-2 הגדרות שקשורות לפרופיל CRI: PR.AC-1.1 אמצעי בקרה ב-Compliance Manager: הפעלת OS Login

פריט	הגבלת כתובות IP חיצוניות במכונות וירטואליות
תיאור	אלא אם יש צורך בכך, מומלץ למנוע יצירה של מכונות Compute Engine עם כתובות IP ציבוריות. אילוץ הרשימה compute.vmExternalIpAccess מגדיר את קבוצת המכונות הווירטואליות של Compute Engine שיכולות להיות להן כתובות IP חיצוניות. כדי לצמצם באופן משמעותי את החשיפה של מכונות Compute Engine לאינטרנט, אפשר למנוע מהן לקבל כתובות IP חיצוניות. כל מופע עם כתובת IP חיצונית ניתן לגילוי מיידי והופך למטרה ישירה לסריקות אוטומטיות, להתקפות ברוט פורס ולניסיונות לנצל נקודות חולשה. במקום זאת, אפשר לדרוש מהמופעים להשתמש בכתובות IP פרטיות ולנהל את הגישה באמצעות נתיבים מבוקרים, מאומתים ומתועדים, כמו מנהרת שרת proxy לאימות זהויות (IAP) או שרת באסטיון. הגישה הזו של דחייה כברירת מחדל היא שיטה מומלצת בסיסית לאבטחה, שעוזרת למזער את שטח הפנים להתקפה ולאכוף גישת אפס אמון ברשת. המגבלה הזו לא חלה רטרואקטיבית.
מידע קשור	הגבלת כתובות IP חיצוניות למקרים ספציפיים
מזהה פריט	MVSP-CO-1.27
מיפוי	אמצעי בקרה קשורים בתקן NIST-800-53: SC-7 SC-8 הגדרות שקשורות לפרופיל CRI: PR.AC-5.1 PR.AC-5.2 PR.DS-2.1 PR.DS-2.2 PR.DS-5.1 PR.PT-4.1 DE.CM-1.1 DE.CM-1.2 DE.CM-1.3 DE.CM-1.4 אמצעי בקרה ב-Compliance Manager: הגבלת כתובות IP חיצוניות למכונות וירטואליות ספציפיות

פריט	שימוש באיחוד שירותי אימות הזהות של עומסי עבודה ב-GKE
תיאור	אתם יכולים להשתמש באיחוד זהויות של עומסי עבודה ל-GKE כדי לבצע אימות מאובטח ל-API מתוך עומסי עבודה של Google Kubernetes Engine ‏ (GKE). Google Cloud איחוד זהויות של עומסי עבודה ל-GKE מספק חלופה פשוטה ובטוחה יותר לשימוש במפתחות של חשבונות שירות.
מידע קשור	אימות ל-APIs מעומסי עבודה ב-GKE Google Cloud
מזהה פריט	MVSP-CO-1.32
מיפוי	אמצעי בקרה קשורים בתקן NIST-800-53: IA-2 הגדרות שקשורות לפרופיל CRI: PR.AC-1.1 אמצעי בקרה ב-Compliance Manager: הפעלת איחוד זהויות של עומסי עבודה ל-GKE באשכולות

פריט	שימוש בצומתי GKE פרטיים
תיאור	כדי לצמצם את החשיפה לאינטרנט, יוצרים צמתים פרטיים. צמתים פרטיים של Google Kubernetes Engine‏ (GKE) עוזרים לצמצם את החשיפה לאינטרנט, כי הם מבטיחים שלצמתי GKE לא תהיה כתובת IP ציבורית.
מידע קשור	התאמה אישית של בידוד הרשת ב-GKE
מזהה פריט	MVSP-CO-1.33
מיפוי	אמצעי בקרה קשורים בתקן NIST-800-53: SC-7 הגדרות שקשורות לפרופיל CRI: PR.AC-3.1 אמצעי בקרה ב-Compliance Manager: הפעלת אשכולות פרטיים ב-GKE

פריט	שימוש בקבוצות Google ל-RBAC
תיאור	אפשר להשתמש בקבוצות Google לבקרת גישה מבוססת-תפקידים (RBAC). כך תוכלו גם לשלב את קבוצות Google עם שיטות הניהול הקיימות של חשבונות המשתמשים, כמו ביטול הגישה כשמישהו עוזב את הארגון. קבוצות Google ל-RBAC עוזרות לנהל ביעילות את הגישה לאשכול באמצעות ניהול זהויות והרשאות גישה (IAM) וקבוצות Google, ומתאימות לרוב הארגונים שמשתמשים בקבוצות Google.
מידע קשור	הגדרת קבוצות Google ל-RBAC
מזהה פריט	MVSP-CO-1.34
מיפוי	אמצעי בקרה קשורים בתקן NIST-800-53: AC-2 הגדרות שקשורות לפרופיל CRI: PR.AC-1.1 אמצעי בקרה ב-Compliance Manager: שימוש בקבוצות Google ל-RBAC ב-Kubernetes

הנחיות לרמה מתקדמת

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

פריט	הפעלת GKE Sandbox
תיאור	אתם יכולים להשתמש ב-GKE Sandbox כדי לספק שכבת אבטחה נוספת שתעזור למנוע מקוד לא מהימן להשפיע על ליבת המארח בצמתים של אשכול Google Kubernetes Engine‏ (GKE). GKE Sandbox משפר את הבידוד של עומסי עבודה לא מהימנים או רגישים, ומספק שכבת הגנה נוספת מפני מתקפות של פירצה בקונטיינר.
מידע קשור	GKE Sandbox
מזהה פריט	MVSP-CO-1.35
מיפוי	אמצעי בקרה קשורים בתקן NIST-800-53: SC-39 הגדרות שקשורות לפרופיל CRI: PR.DS-1.1 אמצעי בקרה ב-Compliance Manager: דרישה ל-GKE Sandbox באשכולות GKE

פריט	אכיפה של Binary Authorization
תיאור	כדאי להשתמש ב-Binary Authorization כדי לוודא שקובצי אימג' מהימנים נפרסים ב-Google Kubernetes Engine‏ (GKE) וב-Cloud Run. Binary Authorization עוזר לוודא שאפשר לפרוס באשכולות רק קובצי אימג' מאומתים ומהימנים של קונטיינרים, וכך מחזק את האבטחה של שרשרת האספקה של התוכנה.
מידע קשור	סקירה כללית של Binary Authorization
מזהה פריט	MVSP-CO-1.36
מיפוי	אמצעי בקרה קשורים בתקן NIST-800-53: SI-7 הגדרות שקשורות לפרופיל CRI: PR.DS-6.1 אמצעי בקרה ב-Compliance Manager: דרישה ל-Binary Authorization באשכול

פריט	שימוש בצמתים סודיים של Google Kubernetes Engine
תיאור	משתמשים ב-Confidential GKE Nodes כדי לאכוף הצפנה של נתונים בשימוש בצמתים ובעומסי העבודה. צמתים חסויים של GKE עוזרים לאבטח עומסי עבודה רגישים מאוד על ידי הצפנת נתונים בשימוש באמצעות Confidential Computing.
מידע קשור	הצפנת נתונים בשימוש בעומסי עבודה באמצעות Confidential GKE Nodes
מזהה פריט	MVSP-CO-1.37
מיפוי	אמצעי בקרה קשורים בתקן NIST-800-53: SC-28 הגדרות שקשורות לפרופיל CRI: PR.DS-1.1

פריט	הפעלת רשות אישורים בהתאמה אישית ב-GKE
תיאור	הפעלת רשויות אישורים משלכם כדי לנהל מפתחות ב-Google Kubernetes Engine‏ (GKE). שימוש ברשויות אישורים משלכם מאפשר שליטה רבה יותר בפעולות קריפטוגרפיות. כדי לבקש גישה לתכונה הזו, צריך לפנות לצוות ניהול החשבון של Google Cloud .
מידע קשור	הפעלת רשויות אישורים ומפתחות משלכם ב-GKE
מזהה פריט	MVSP-CO-1.38
מיפוי	אמצעי בקרה קשורים בתקן NIST-800-53: SC-12 הגדרות שקשורות לפרופיל CRI: PR.DS-1.1

פריט	הצפנת סודות של Kubernetes באמצעות Cloud KMS
תיאור	הצפנה של סודות ב-Kubernetes במצב מנוחה באמצעות מפתחות מנוהלים של Cloud Key Management Service‏ (Cloud KMS). שירות Cloud KMS מספק שכבת אבטחה נוספת לנתוני etcd, ומאפשר להצפין סודות של Kubernetes באמצעות מפתח שנמצא בבעלותכם ובניהולכם.
מידע קשור	הצפנת סודות בשכבת האפליקציה
מזהה פריט	MVSP-CO-1.39
מיפוי	אמצעי בקרה קשורים בתקן NIST-800-53: SC-28 הגדרות שקשורות לפרופיל CRI: PR.DS-1.1 אמצעי בקרה ב-Compliance Manager: הפעלת הצפנה באשכולות GKE

פריט	שימוש ב-CMEK לדיסקים של אתחול הצמתים
תיאור	שימוש במפתחות הצפנה בניהול הלקוח (CMEK) להצפנת דיסק האתחול של הצומת. מפתחות CMEK מאפשרים לכם להצפין את דיסק האתחול של צומת Kubernetes באמצעות מפתח שבבעלותכם ובניהולכם.
מידע קשור	שימוש בדיסקים להפעלה של צמתים שמוגנים באמצעות CMEK
מזהה פריט	MVSP-CO-1.40
מיפוי	אמצעי בקרה קשורים בתקן NIST-800-53: SC-28 הגדרות שקשורות לפרופיל CRI: PR.DS-1.1 אמצעי בקרה ב-Compliance Manager: הפעלת CMEK בדיסקים של אתחול מאגר הצמתים ב-GKE

המאמרים הבאים

• הנחיות להגנה על נתונים
• סקירה כללית של פלטפורמה מאובטחת ברת-קיימא מינימלית