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

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

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

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

פריט	השבתת הגישה ליציאה טורית של VM
תיאור	כדי להשבית את הגישה ליציאות טוריות, מגדירים את האילוץ compute.disableSerialPortAccess במדיניות הארגון. כדי למנוע ערוץ גישה שעוקף את כללי חומת האש ואמצעי בקרת אבטחה אחרים ברשת, כדאי להשבית את הגישה ליציאה טורית במכונות וירטואליות ב-Compute Engine. המסוף הטורי האינטראקטיבי מיועד בעיקר לפתרון בעיות במקרה חירום, אבל אם משאירים אותו מופעל, אפשר ליצור דלת אחורית קבועה שהתוקפים יכולים לכוון אליה. השבתת הגישה ליציאה טורית עוזרת לאכוף מצב אבטחה מקיף, כי היא מחייבת שכל הגישה האדמיניסטרטיבית תתבצע דרך נתיבים סטנדרטיים שנבדקים, כמו SSH. כדי להגן על הנתיבים האלה, אפשר להפעיל ניהול זהויות והרשאות גישה (IAM) ושרת proxy לאימות זהויות (IAP).
מידע קשור	השבתת גישה אינטראקטיבית למסוף הטורי באמצעות שירות מדיניות הארגון
מזהה פריט	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 וניטור התקינות הם חלק מתהליך ברירת המחדל של יצירת מכונת VM. כדי לוודא שהמכונות הווירטואליות מופעלות רק עם קוד מהימן שלא עבר שינוי, אפשר להשתמש במאפיינים של 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 list מגדיר את קבוצת המכונות הווירטואליות ב-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 כדי לבצע אימות מאובטח ל- Google Cloud APIs מעומסי עבודה של Google Kubernetes Engine ‏ (GKE). איחוד זהויות של עומסי עבודה ל-GKE מספק חלופה פשוטה ובטוחה יותר לשימוש במפתחות של חשבונות שירות.
מידע קשור	אימות ל- Google Cloud APIs מעומסי עבודה ב-GKE
מזהה פריט	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

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

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